Introduction
I've been supporting, writing, or leading IDP signatures for over 12 years now. In that time, our team has grown and evolved to continually improve IDP for our customers who've come to trust us to provide them the signatures they need when they need them most.
Our customer base is a diverse group with wildly ranging, often conflicting, needs. Some require white-hot performance, while others require iron-clad protection. Most, I've found however, are somewhere in-between.
And due to some unique endpoint challenges (industrial control, SCADA, manufacturing, etc.), some customers require a large back-catalog of protections from what most would consider legacy threats. These customers benefit from our vast store of over 15 years of signature development. Others need only what's currently relevant and otherwise just needs the packets to flow. These customers need a quick and easy way to sort through that same large library of signatures to find only the ones that are relevant to them. Providing protection for these diverse customers is both a challenge and a privilege.
Recommended Signatures
The good news is, there is a basic foundation of security that nearly all can agree on. This essential level of protection is what our team "Recommends" all customers start with. We encourage our customers to consider the Recommended signatures as bare-minimum that they can then build on as their local security requirements dictate.
Our criteria for "Recommended" status, in a nutshell, is that the signature should be protecting the customer from threats that are:
- Current - Less than 1 year old for client issues and less than 3 years old for server issues
- Relevant - Vulnerabilities we would expect to see on our customer's networks
- Reliable - Recommended signatures are as accurate as we can make them, with the least performance impact possible.
We also take into consideration a variety of factors outlined in industry-standard threat evaluation systems such as CVSS and OWASP, as well as taking into consideration severity ratings from the vulnerable vendors themselves. Finally, we consider the reported level of access, how difficult it is to exploit, and how widely the software is deployed.
Armed with all of this metadata about a particular issue, our security experts render a decision as to which signatures are currently "Recommended".
Signatures are regularly reviewed using this criteria and under the right circumstances might eventually be removed from 'Recommended" status. Does this mean we "don't recommend" them? Far from it! We continuously test, review, and improve our signature base, regardless of status. Customers desiring a stronger level of protection are encouraged to add additional signatures to their policies within the limits of their performance requirements.
But why do we write the signatures we do?
Signature Writing
Our team has always been customer-focused, and so we do our best to tailor what signatures we write to address the concerns our customers have with their network. We use a variety of both open and closed information sources to obtain vulnerability information that is then used to make signatures.
Our customers' focus tends to be on Enterprise software products from companies such as Microsoft (especially "Microsoft Tuesday" releases), Adobe, Apple, Oracle, Hewlett Packard, IBM, Novel, Google, VMWare/EMC, RedHat and other commercial packages, but also on common open-source software from Ubuntu, Apache, Mozilla, ISC, OpenSSH, OpenSSL, Digium, and more.
We try to avoid specific malware signatures as these are typically "one-off" signatures and are very temporal - they are "here today, gone tomorrow". When they exploit known vulnerabilities, we do our best to cover those vulnerabilities instead of the specific method any one virus may try - this gives us overall more effective coverage with less effort - a win-win.
But specific vulnerabilities in specific products is only part of the solution. We get our best "bang for the buck" by covering obviously malicious activity as generally as possible (while still avoiding false positives, naturally). These behavioral signatures include coverage for malicious activities such as: SQL Injection, Cross-Site Scripting (XSS), Brute-Force Password Guessing, Known Shellcode Encoders, Evasion and Obfuscation behavior, and other network shenanigans.
Having these generic signatures allows us to protect customers from vulnerabilities before they are known ("Zero Day" protection) and also alleviates the load (both on the IDP as well as our team) from having vulnerability-specific signatures.
Signature Severity
As for the severity levels we set, our goal is to protect customers from attack, so our perspective for severity is from one of "What would happen if this vulnerability was successfully exploited?". Using that as our focus, we use the following guidelines:
Critical:
- Remote "Privileged User" (Root/System/Administrator) Code Execution
Major/High:
- Remote User Code Execution
- System Denial of Service (BSOD/Guru Meditation/Hang/Reboot)
- Data Manipulation (SQL Injection, etc.)
- Obvious Hacker Activity
Minor/Medium:
- Probable Hacker Activity
- System Credentials Information Disclosure
Warning/Low:
- Other Information Disclosure
- Unusual, Potentially Malicious Activity
- Blatant RFC Violations (overlong headers, etc.)
Informational/Info:
- All Other Activity
- Strict RFC Checks
Similar to how we decide whether to recommend a signature or not, these can vary depending on the specific vulnerability details. Financial record data manipulation is obviously more critical than nonessential data, and so the severity could be moved up or down as a result.
Conclusion
Our team strives to make our customers happy and secure. We're always doing our best to address customer concerns and security issues as timely as possible.
We don't know what we don't know, of course, and so as a result we always accept customer requests for coverage of things we're currently not. We won't always be able to cover things, but we love to hear from customers to find out what they want.
Please contact your local Juniper Sales Team or JTAC for any coverage concerns you may have, and your requests will make their way to our team where we will give them all consideration available. We always appreciate technical details or packet captures if you have them to provide.
We appreciate the trust you place in our team by buying and using IDP-enabled systems.
Thank you for being a Juniper-Protected customer!