vulnerability management

October 22, 2009

Yesterday, Rapid7 announced the acquisition of Metasploit. Two other examples of an open source project being transformed into a commercial enterprise in the area of vulnerabilities, exploits, and detection signatures (all of them are closely related) come to mind – the other two that I’m thinking of Nessus/Tenable and Snort/Sourcefire. The model seems makes sense for technologies around security vulnerabilities.

In all three cases, a technology was created and a community was formed (worldwide in all three cases). The community contributed their knowledge to the project. While some of this knowledge went to the development of the software, much more went into the development of the vulnerability (or signature or exploit) libraries. Beyond the initial creation of the libraries, the community continued to contribute. Thousands of people (perhaps even larger but I don’t think anyone really knows) were continually on the lookout for security vulnerabilities or new exploits. These same people then either notified the community about the issue or they created a vulnerability check, signature, or exploit and contributed it to the project. For the commercialized products, there still must be a QA/QC testing process to make sure the check/exploit/signatures works and does not cause problems when it is deployed.

Now compare that model to a really smart person (or team of people) that starts a commercial company in this same area. In order to get things going, the team must build the software and do all of the research needed to create the vulnerability checks, signatures, or exploits. That is a lot of work and given the number of products already on the market, there is a lot of catch up to do. Once the initial work has been done, the company will need to maintain an expert research team to keep creating the vulnerability checks, signatures, or exploits. The really good teams are not small – they will need people with expertise in a number of different areas – and they are not cheap. An interesting point is that many teams maintain contact with the open source communities and trade information. There are certainly examples of companies that have successfully created a product and maintained a world class team. However, there are also examples of companies trying to get started and failing.

It is hard to beat a large community when it comes to identifying potential problems (even if additional help is needed to commercialize what has been identified) so perhaps the area of vulnerabilities, exploits, and signatures is well served by the open source model. What do you think?

September 11, 2008

To hear the media tell it, the recent disclosure of a vulnerability in a popular Supervisory Control and Data Acquisition (SCADA) product means the end of life as we know it. One article uses the headline “Gas Refineries at Defcon 1 as SCADA Exploit Goes Wild.” There are vulnerabilities in SCADA systems…who knew?

Well, we should all have figured it out a while ago (computer systems are used in SCADA networks after all) and I think many people did. Is there any reason to think that SCADA systems would not have vulnerabilities in them?

SCADA systems are used for process control in manufacturing and utilities. They are used to control refineries, power plants, factories, and other highly complex environments. In most cases, the SCADA systems are isolated from the organization’s internal network. The reason for this is obvious – there are serious negative consequences associated with a failure of a SCADA system. SCADA networks themselves also tend to be soft on the inside with few internal controls in place. When serious negative consequences (such as death, serious injury, or the complete failure of the enterprise) are involved, people tend to take precautions. There are business reasons why some connections between the SCADA environment and the organization’s internal network might occur – reporting, control and maintenance, etc. – and organizations have built these connects as required. In most cases, the organization also puts controls in place to limit the access into the SCADA network. These controls might include terminal servers that break the direct connection between the user’s desktop and the SCADA management servers.

Let’s get back to the vulnerability for a minute. Is the vulnerability bad? It does seem like it. The description that I found on the Internet (by Kevin Finisterre) indicates that exploitation of the vulnerability will provide the attacker with a “command prompt with the privileges of the currently running Citect process.” That does seem pretty serious.

However, from an overall risk perspective, we also need to look at the compensating controls (Controls that prevent direct connection to the SCADA network and the SCADA system). Compensating controls will vary from organization to organization so while the vulnerability is very serious, the risk to a particular organization may be less so if the compensating controls are really in place and functioning. The other thing to consider is how to implement the patch to the SCADA system. Since the SCADA system itself is so sensitive, I would be uncomfortable just patching the system without testing the patch. There might also be limitations on when the patch can be applied due to how the system is used (should the SCADA system be patched while the plant is running?).

As with many stories about vulnerabilities and exploits, the situation is serious and we need to do something about it but we need to understand all of the risks involved.