If a vulnerability scores higher than the cut-off point (5 in our case), it must be further eval- uated. Initial triage is just a first filter to help differentiate nonvulnerabilities from vulnera- bilities but, when that is done, you must delve deeper into the vulnerability. A deeper under- standing of the vulnerability can help you determine the affected devices/systems/applica- tions and devise workarounds and understand triggers and consequences.
In some cases, the outcome of a detailed evaluation might be to reclassify the vulnerabili- ty as a low severity or even a nonvulnerability. One such example is a Cisco Security Notice on Internet Key Exchange (http://www.cisco.com/warp/public/707/cisco-sn- 20030422-ike.html). When Cisco PSIRT received the initial report it claimed that it is possible to brute force the preshared password used during Phase 1 of establishing an IPsec connection. Base score for this issue was either 5.4 (if high complexity is assumed) or 7.1 (for medium complexity) and, according to the score, this is a moderate to severe vulnerability. The reason why it was not treated a vulnerability is that detailed analysis uncovered that this particular attack scenario had been considered during development of the IKE protocol and the risk associated with it was deemed acceptable. As a result of this, the reporter was advised to bring the issue to the attention of IETF together with the reasons why the risk might have changed since the IPsec protocol was created.
In almost all cases, detailed evaluation includes the creation of an exploit. Exploits are not mandatory to prove the presence of the vulnerability but are useful because they can be incorporated into test suites to prevent reoccurrence of the same vulnerability. To some extent, the presence of an exploit can be counterproductive because it can con- strain people when thinking about vulnerability—both during the investigation and cor- rection. In both instances, there is a tendency that the exploit is the ultimate proof if the device is vulnerable (or not). People tend to focus on the exploit instead of on the under- lying root cause; it is not uncommon to overlook that the slightly modified attack can still trigger the vulnerability.
Remedy Production
After vulnerability is confirmed and a detailed analysis performed, a remedy can be pro- duced. Recall that a remedy is not only a fix (for example, a change in the source code or the configuration) but the process of producing the remedy also includes regression test- ing, packaging in a form suitable for distribution, and testing its installation. Depending on the number of different software releases supported, this step can take a variable amount of time to perform. It can be done quickly for a small number of software releases, or it can take considerable time if many software releases must be updated. Also, the code change itself can range from simple (changing < to <= or simple array checking) to com- plex changes in a protocol design, as was the case with TLS Renegotiation vulnerability. Depending on a vendor, producing the fix can be performed by the people on the product security team or by the software developers. In the former case, the argument is that the product security team is the expert in security and that it can produce a remedy of higher quality. This limits the number of people who know the technical details of the
vulnerability, thus limiting the risk of a leak. The argument for the latter case is that soft- ware developers know their code the best and can produce a remedy much faster than someone who does not work on it every day. Having someone with less knowledge about the overall code modify the source code increases the potential for product instability and adverse side effects. Apart from technical reasons for and against each of the approaches, you need to consider one more thing. Mandating that the product security team produce remedies will increase the size of the team, whereas surrendering the remedy production to developers will enable the product security team to stay small. There is no "right" or "wrong" approach for this but only different avenues to achieve the same goal.
Ideally, remedies for all vulnerabilities will be produced immediately. In practice, given limited resources, the vendor must decide which vulnerabilities will be dealt with first and which ones can wait. Two components influence this decision: the base CVSS score and whether the vulnerability is reported by an external researcher.
As previously said, the base CVSS score describes intrinsic technical characteristics of the vulnerability and, all things being the same, the vulnerability with the higher base score should be handled first. What can modify this decision is who knows about the vulnerability. If it is reported by an external researcher, or there is credible evidence that details are known outside the vendor, the urgency with which the vulnerability should be dealt with can increase. The priority of the vulnerability remains the same (that is, it did not became any worse from a technical perspective) but the vendor might decide to deal with it before some other vulnerabilities of the same, or even slightly higher, priority (severity). One of the reasons for an urgency increase is that external knowledge increas- es the chance of an information leak and exploitation. Another reason is that an external research would like to present the findings at some of the conferences that then intro- duce a hard deadline. If possible, a vendor should work with the researcher to meet the conference deadline. That effort can help establish the vendor's good reputation and make researchers willing to work with the vendor in the future.
What is important to emphasize is that external knowledge can influence the urgency with which the vulnerability is dealt with only if the vulnerability itself is of a certain severity and taking into account what other vulnerabilities are currently being handled. A low-severity vulnerability does not deserve to be handled before a high-severity one, no matter who knows about it.
You might wonder why a vendor would not take into account where and how the product is used when prioritizing work on a vulnerability. The short answer is that the vendor, gen- erally speaking, does not know where products are used. Here are a few examples to illustrate this. A Linksys wireless access point can usually be found in a home environ- ment but can also be used in a nuclear power plant. The same switch can be deployed in a medium-sized organization and a Boeing 787 airplane. A CRS-1 router can be found only in large installations, but that can be a stock exchange or a massive multiplayer online role-playing game data center. Unless a vendor is specialized in a niche product, it is not easy to determine where and for what purpose it is used. If a vendor would have only two products, such as a child's toy robot and hospital radiation machine, it would be natural to prioritize vulnerabilities in the radiation machine over the toy. However, in most cases, the distinction between products is much less pronounced.