Reader Comment – 09-08-13 – ‘Risk’ vs ‘risk’ Management

Russell Thomas, developer of the Ten Dimensions of Cyber Security Performance that I’ve discussed earlier, has posted a very short comment on this week’s blog post about Ralph Langner’s critique of the Cybersecurity Framework. Actually, Russell’s comment was a link to a very lengthy (even by my standards) blog post about Ralph’s general criticism of cyber risk management. It is readily apparent that Ralph and Russell approach cybersecurity from two completely different backgrounds, but they both bring valuable ideas to the discussion of risk management to which the control system community should pay close attention.

Anyone that is seriously interested in the theoretical basis for cybersecurity risk management needs to follow Russell’s blog, Exploring Possibility Space. Russell is an innovative thinker and draws upon a number of academic disciplines in formulating his ideas. There is a tendency to slip into academic speak from time to time, but his ideas are certainly worth the effort to wade through that jargon when it arises.

I highly recommend that anyone seriously invested in cybersecurity risk management should read Russell’s post about Ralph’s approach to risk management. I’ll try to hit the highlights here.

Empirical Justification

Russell points out that both he and Ralph agree that there is little empirical justification for what Russell calls “Little ‘r’ risk” (see his post on ‘risk vs Risk’) management. Ralph sees this as a reason to ignore formal risk management techniques. Russell sees this as a reason to extend the study of Risk management so that there is a useful theoretical basis for developing and evaluating risk management techniques.

This is the classic argument between theoreticians and technicians in any newly developing field. In the short run Ralph’s arguments are certainly justifiable, but in the longer run it will be folks like Russell who will provide us with a solid basis for securing the cyber enterprise, particularly on the control system side. That is if Ralph and his compatriots can cobble together a relatively effective cybersecurity program that prevents catastrophic attacks in the meantime.

Practical Feasibility

Again Russell and Ralph mainly agree that the currently accepted theories on probabilistic risk are lacking in practical applications. Again, Ralph sees this as a reason to eschew the study of probabilistic risk management for work on actual applications. Russell’s approach is to change the way we look at probabilistic risk management to make it more practical. He provides one of his papers, “How Bad is it? – A Branching Activity Model to Estimate the Impact of Information Security Breaches”, as an example of the new types of research that are expanding the usefulness of the technique.

Once again, I think that these two have more in common that it initially appears. I would love to see these two on a panel discussing this topic (Dale or Joe please note the suggestion). An effective melding of their viewpoints would be very beneficial to the cybersecurity enterprise.

Langner Criticizes Cybersecurity Framework

Ralph Langner, of specific Stuxnet fame and a recognized control system security expert, has an interesting post on his corporate blog about the general ineffectiveness of the proposed Cybersecurity Framework and his own detailed proposal for an industrial control system security framework; Robust ICS Planning and Evaluation (RIPE). A review of RIPE will have to wait for a time when I have more time available to closely read the 12 page document, but his comments about the proposed NIST Framework deserve immediate attention.

Unpredictability

Ralph makes an important point early in his post when he states that “a fundamental problem of the CSF is that it is not a method that, if applied properly, would lead to predictable results”. The reason for that is clearly because the Framework is not, at its base, a document about cybersecurity, but rather a political document. It effectively transfers political risk from the Federal Government to facility owners. It allows the government to politically assign blame for a successful cyber-attack to the corporate victim.

As we saw after the fall of the Twin Towers the US public, and to a lesser extent, the business community, clearly placed the blame for the success of the attacks on the government’s inability to ‘connect the dots’ and intercept the attackers before they got to the aircraft. Little or no mention was made about the poor security posture of the airlines that allowed the attackers to take weapons onto the airplanes or to take control of the cockpits once they were on the aircraft.

The airlines security failures were seen as a lesser problem because no one could have foreseen that the aircraft would be used as weapons because no one had done so before. Ralph points out in his RIPE paper that this is a predictable application of ‘risk-based’ reasoning. He notes that:

“Cyber attacks against industrial control system installations are extremely rare, making it appear like a waste of company resources to protect against them. The generally accepted policy is to accept the risk and only after having seen a significant successful attack at home within the same industry, then figure out how to protect.” (pg 1)

Since industry has effectively killed every attempt to write actual cybersecurity legislation that could require industry to take even the most rudimentary positive protective actions, it has become necessary for the government to protect itself from future claims of blame for successful cyber-attacks on those industries.

Risk Management

One of the reasons that the airlines had such a poor security posture, even after three decades of successful terrorist hijackings, was that they had done a cost benefit analysis of the hijack risks. It was clear, in a corporate sense, that the monetary and public relations costs of adequate security was much higher that the relatively rare loss of an aircraft and its passengers. We still see this today, even after the events of 2001, in the complaints about the costs and inconveniences associated with TSA and its airport screening measures.

One of the reasons that the airlines were not held to account for the failure of the risk assessments was that there was never a public accounting of those decisions. The Framework will change that for high-risk critical infrastructure organizations. The Tier process that I described in an earlier post and Ralph takes to task in his post is clearly an attempt to make management make a recordable statement about their risk management decisions; a statement that will clearly be able to assign responsibility for poor (in hind sight) decisions that led up to a successful cyber-attack.

The remainder of the Framework will clearly show that the government did its part in helping the devastated target to secure their computer systems against outside attack. But the Tier process will allow the feds to show that management decisions were reasons that the cyber-defenses were not up to the task of protecting critical infrastructure from attack. It is all about CYA.

Stuxnet Secrets

Ralph Langner has an interesting post on his blog that discusses his recent interview conducted by Dale Peterson over at DigitalBond. In his own blog post, Ralph makes an interesting claim about why the DHS ICS-CERT people have not been more forthcoming about the research that they have conducted on the Stuxnet malware; he says the reason is that the information is classified. In fact, he says the fact that it is classified is, itself, classified. He says the reason that everything is so classified is that disclosing the classification of the research “would be evidence for US participation in Stuxnet.”

Now I have gone back and re-read Ralph’s words a number of times and he doesn’t ever really say that the ICS-CERT people had anything to do with the development of the Stuxnet worm, just that their post-release research is classified. I don’t know how Ralph reaches this conclusion, he doesn’t say.

Classified Information

Before I go any further lets talk a little about classified information in general. First there are a number of different reasons that something might be classified. Generally speaking information is classified because the release of the information could jeopardize National Security.

The reason for that can be quite apparent, for example codes used to transmit classified information must be kept classified. Failure to do so could result in someone being able to decode the information. Most often, the encrypting keys are classified, but the general method of applying the keys may be less critical.

The military used to use (and may still use) an authentication table to allow individuals to prove they were the good guys when transmitting information in the clear. How the authentication table was used was not classified; it was taught to every solider in basic training. The actual tables that changed every day were, however, classified.

Now other types of information are even more sensitive. The very existence of the information is vital to national security. The classic example from World War II is the development of the atomic bomb. The very existence of the Manhattan Project was a carefully protected secret. Now once the first weapon was deployed against Japan, the existence of the program was no longer classified; that loud noise, fire, smoke and destruction were just too hard to plausibly deny. The methods of making the modern counterparts of those weapons remains classified today, but not the existence of the weapons programs themselves.

Now if it was a nation-state that developed the Stuxnet malware (suspected but not known or proven) then they would have a very real national security reason for hiding that development. Even after it was deployed, it would be in their best interest for their involvement to remain classified. It would make it harder for some targeted entity to demand reparations, apologies or even seek retribution for the ‘dastardly sneak attack’

ICS-CERT and a Stuxnet Secret

I don’t have any contacts at ICS-CERT so there is no way for me to know how true this claim of Ralph’s is. If I were to ask them as a blogger/reporter, I know what answer they would be required to tell me if they did do classified research (which I would suspect that they might). They would be required to say something to the effect of the classic ‘we can neither confirm nor deny’. Anyone that has handled classified information knows the reason for that answer, but let me lay it out, by looking at the possibilities.

It’s not classified: if the facility does do classified work it can not confirm that something is not classified when asked a question like this. If they do and the same question is asked about a later project that is classified the inability to say that the second project is not classified becomes confirmation that it is classified. Even if the facility does not currently do classified work the potential for doing classified work in the future would require the ‘neither confirm nor deny’ response.

SIDE NOTE: They could of course lie, but lying is almost always counter-productive. It is almost always discovered and the lie is ultimately more damaging than revealing the classified information. Besides, few people can really lie effectively.

It’s classified: the development of a cyber weapon directed at critical control systems would certainly be classified and you never confirm or deny the existence of such classified weapon systems in development. Once deployed a country would want to deny that it had that capability to avoid retaliation. One would disclose the existence of such weapons that rely on a certain amount of stealth capability only after their existence was widely known and clearly traced back to the attacker. Then you just try to keep the details of the weapon system secret.

With cyber warfare becoming ‘the obvious next battlefield’, everyone must assume that the ICS-CERT people are or will be looking at either the development of control system cyber weapons and/or defeating such weapons. Even if they were just working on defensive measures, I would keep that information classified. The delineation between offensive and defensive capabilities in advance technology weapons is very hard to define. And any properly paranoid enemy would have to assume that a defensive lab was actually producing weapons; and that would require their work on a similar weapon.

Alternative Explanation for Secrecy

There is a very plausible alternative reason for a lab like ICS-CERT to keep their research on Stuxnet unpublicized. As Ralph himself has so clearly pointed out, the Stuxnet work has pointed out a couple of major vulnerabilities in the Siemens control systems, and in fact, any control system using modern PLCs. More importantly, Ralph has pointed out that there is currently no real way of preventing exploits of these vulnerabilities if access can be gained to the control system.

Now, if ICS-CERT has located additional vulnerabilities in their research into the Stuxnet malware they have long maintained that they would not disclose such vulnerabilities until they had a chance to work with the vender to come up with a counter to that vulnerability. This is done to protect the control system community against the ‘bad guys’ from using those uncorrected vulnerabilities against systems that could not be protected. They have also said that they would not violate that non-disclosure rule unless there was found to be exploit code available in the public domain or in use in the wild.

Even with people like Ralph and Symantec describing the attack code in Stuxnet, ICS-CERT could use this internal non-disclosure policy to justify not talking about those vulnerabilities beyond the generalities that it has posted on their web site. Again, they would be concentrating on working with venders like Siemens to figure out a way to defend against the vulnerabilities. Once those advanced mitigation/prevention strategies were developed, we would expect full disclosure of the vulnerability as well as the fix.

The CERT non-disclosure policy is not the same as the information being classified though the practical effect may be the same, at least initially. It is no where near as bureaucratic as the security classification procedures. The managers at CERT can, under this policy, change the disclosure status of a particular vulnerability with a simple verbal order. A bureaucratic declassification procedure is not required.

Non-disclosure or Classified?

So which is it? Is a nondisclosure policy directive or security classification preventing the ICS-CERT lab from disclosing the results of its investigation into the Stuxnet malware. Or is it simply a matter of a less than competent investigation not revealing anything worth discussing (as some writers have suggested).

Personally, I seriously doubt the latter; I have no data to support that, it is just my opinion. Similarly I have no data available to weigh in definitively on either of the other two alternatives. I would like to think that it is simply the non-disclosure issue controlling the current situation. There are too many problems with Stuxnet as a weapon for me to want to suspect that the ICS-CERT people had anything to do with cooking it up.

Of course I have been forced to use too much poorly designed military equipment to say that we couldn’t have designed and deployed Stuxnet. I would just like to think that a research organization that we have to rely on helping us to protect our control systems would do a better job of designing a stealthy attack program. It’s not necessarily a rational desire on my part, but it is there.

SCADA Exploit Vulnerabilities

Readers of this blog will have noted that I have been writing more often about identified vulnerabilities in various industrial control systems and even the existence of published exploits to use those vulnerabilities to attack such control systems. Earlier this week I did a posting about the Stuxnet man-in-the-middle attacks that Ralph Langner has identified. On Wednesday Ralph posted a new entry into his blog that builds on the dangers identified in that attack methodology.

Not Patchable

One important point that Ralph continues to make is that we should not be expecting a ‘patch’ from Siemens to ‘correct’ the vulnerabilities used by Stuxnet. He points out that these vulnerabilities are “regular product features that you find in the majority of these systems, regardless of vendor [emphasis added]”. To eliminate these potential attack points is not going to just require a revision of the Siemens soft ware, but also a complete reworking of the programming for each of the millions of controllers currently in place in manufacturing facilities around the world.

It is not realistic to suppose that the multitude of controllers currently in use will be re-worked to avoid the attack techniques that Stuxnet utilized. I’m not sure about future PLC’s (I’ll leave that discussion to the engineers and security professionals), but it is just not practical to make such radical changes to all of the devices currently in the field. It cannot be done piece meal, it will require a simultaneous reload of all control software and PLC firmware in a facility to minimize the risk of compatibility issues. This would make for a very long turnaround time, with extensive (expensive) pre-installation testing and post-installation trouble shooting. Even then, subsequent process problems will be almost inevitable.

Not Limited to Stuxnet

Ralph makes the point that the two attack modes he describes in his Stuxnet analysis blogs are not limited to being used by Stuxnet (they could be carried by other attack vectors) nor are they limited to being applied to just Siemens controlled systems. Since the attacks actually takes aim at the PLC’s not the Siemens work stations, any industrial control system that utilizes programmable logic controllers could be attacked using these two modes.

One of the things that Ralph doesn’t explicitly state in his blog, yet is clearly implicated by his discussion, is that any vulnerability in control systems that allows an attacker to gain system access to allow code injection to the controllers would allow for a Stuxnet like attack on those systems. Ralph does note that the “development tools to aid in the [code injection technique] development are [available] in the wild”.

The hard work has been done. Now all it takes is a reasonably technically proficient person with the necessary intent to launch the next attack on industrial control systems. An attacker without any process knowledge could launch an attack that could randomly disrupt control system operations to the extent that facility shutdown would be required. An attacker with basic process knowledge (from a disgruntled, or cash strapped insider for instance) could cause worst case process upsets resulting in catastrophic failures of processes and/or equipment that could seriously affect the neighboring community.