Lack of Imagination and Attack Progression
I was a little late catching it, but Richard Bejtlich made a post titled “First They Came for Bandwidth…” over on his TaoSecurity blog last week that is worth reading. He argues that one of the problems with being in a defensive position with regard to security is a tendency toward lack of imagination, uses the Ukranian hacker stock market fraud story as a case in point, and then discusses a progression of attacks.
I think there are some observations from his post that apply well to the control system world:
1.) We aren’t always able to visualize how an attack can happen. This is especially true in our industry. Even though we are rapidly coming out of the realm of obscurity (see number 3 on the “Top Ten SCADA Security Stories in 2007”), we still have a difficult time visualizing how our systems could be attacked.
2.) We aren’t always able to visualize why an attack would happen. Bejtlich’s post challenges us to confront the fact that just because we do not see a motivation for an attack, doesn’t mean that one doesn’t exist.
3.) The progression time line is very poignant. The progression itself is not breaking news but it highlights why we must be diligent. Bejtlick writes:
“Overall I see a progression like the following. (I thought I posted this before but I cannot find it!)
* First they came for bandwidth… These are attacks on availability, executed via denial of service attacks starting in the mid 1990’s and monetized later via extortion.
* Next they came for secrets… These are attacks on confidentiality, executed via disclosure of sensitive data starting in the late 1990’s and monetized as personally identifiable information and accounts for sale in the underground.
* Now they are coming to make a difference… These are attacks on integrity, executed by degrading information starting at the beginning of this decade. These attacks will manifest as changes to trusted data such that those alterations benefit the party making the change. This sort of attack undermines the trustworthiness of data.”
When attackers wanted bandwidth, they weren’t going to find it in an isolated control network segment. And in most control systems, there is nothing incredibly secret about what is happening. Making a difference, or impact, however, is something that is possibile with control system attacks — be it in perception only or in reality.
Author: Jason Holcomb
Posted: February 22nd, 2008 under Big Picture.
Comments: 10
Comments
Comment from Jake Brodsky
Time: February 22, 2008, 5:33 pm
I saw that article earlier today, and then I saw Joe Weiss’s comment on Statistical Risk determination in Unfettered. My response there and here is the same:
If you’re looking for the broad picture, you can learn something from a statistical analysis. However, if you’re looking for specific information about security, due to the relatively small community here, this becomes an exercise very similar to the Heisenburg Uncertainty principle (http://en.wikipedia.org/wiki/Uncertainty_principle). You end up generating more and more statistics about fewer and fewer incidents until you really don’t know where you stand or where you’re going.
The bottom line is that we have to think ahead of where the security risks are going to hit an ICS. We have to be ready for them, not closing the barn doors after the horses have already left.
Comment from Ralph Langner
Time: February 23, 2008, 3:56 pm
“Sophisticated intruders are unpredictable”, says Bejtlich. Well, maybe. My question is, how many sophisticated intruders are out there, and how many of those would see any business in messing with SCADA.
While you are calculating… it’s not hard to figure that the number of users that accidentaly misconfigure PLCs, DCSs and so forth on a weekly basis, thereby causing millions of $ damage, is roughly three or four magnitudes greater than those super smart attackers.
Why are we in this business — for the thrill, or for preventing damage? Let’s do the dirty work at hand, and only then let’s care about the genious hackers that are screwed up enough to waste their skills on technologically obsolete SCADA installations.
Comment from Jake Brodsky
Time: February 23, 2008, 6:36 pm
Ralph, I’m in this business because I enjoy seeing my software and hardware make REALLY BIG things work. 
As for misconfigured devices and bugs in programs, now you’re touching on programming language design and control system narrative description texts. It might be worth studying these things to reduce errors, but that’s not the same thing in my mind as patching bugs to prevent unauthorized attacks.
Comment from Ralph Langner
Time: February 24, 2008, 4:23 pm
Jake, here is my point. Bugs and the ability to execute unauthorized control systems access are not exploited by attackers. The quoted sophisticated attackers would simply use those wide open doors that many of us know about — they would exploit features, not bugs. And while we are waiting for a big, sophisticated SCADA attack materializing, millions of damage are done by the ordinary control room person or maintenance guy that does something wrong with no bad intent.
If you ask me, I’m not in the business to prevent attacks. I’m there to prevent damage, and I don’t care at first hand if the cause of such damage is an evil attacker or a misconfigured switch. And after several years in the business, I’m getting tired of all the cyber terrorist and SCADA hacker talk with almost zero evidence to it, and production loss worth millions of dollars every month due to accidental stuff, but our SCADA security folks don’t care because it’s not done intentionally by some bad guy. No offense, Jake, but I believe that those of us who are obsessed with attackers, cyber terrorism, and hackers have lost focus. (The blame doesn’t apply to Jason, I’m just thinking that his between-the-lines message is misleading.)
Comment from DDH
Time: February 24, 2008, 5:08 pm
I’m a controls guy and not a security guy but I have been self-learning about security issues, including cyber-security threats. What occurs to me is that as nations competes against nations in this globally connected world, there may be a lot to gained by manipulating your enemies data. For example, manipulated data in the biopharma industry can considerably slow the release of manufacturered product. Manipulated clinical trial data could have huge impact on a companies ability to receive regulatory approval and thus deliver a block-buster medicine to the market place.
I’m afraid I see the need for an entire portfolio of security measures as being very important to help ensure business continuity.
Comment from Jake Brodsky
Time: February 24, 2008, 7:27 pm
Ralph, you and I are discussing different elements of any good security policy. And it is the reason why we don’t offer just one solution, but a cafeteria of solutions for experts to pick and choose from.
Tolerance of an attack is good, as are broad defenses. These are essentially orthogonal approaches.
Comment from Joe Weiss
Time: February 24, 2008, 10:17 pm
My comments to Jason’s three observations follow:
1.) A good example of not being able to visualize how an attack can happen is the Aurora demonstration.
2.) We aren’t always able to visualize why an attack would happen is also very true in the industrial controls community.
3.) The progression time line is very poignant.
* First they came for bandwidth… There has been at least one case where a bandwidth attack resulted in unintended consequences – opening and closing electric breaker switches (not publicly reported).
* Next they came for secrets… Probably true, but hard to get anyone to confirm.
* Now they are coming to make a difference…Attacks undermining the trustworthiness of data has been demonstrated by the National Labs and will be demonstrated again at the August Control System Cyber Security Conference.
JoeWeiss
Comment from Ralph Langner
Time: February 25, 2008, 5:09 am
Jake, I’m not advocating to ignore the threat from malicious attackers. I’m just saying that in view of the undeveloped state of industrial security that we’re presently in, it makes some sense to focus on the problems at hand, and take care of other, more thrilling threats later. If our measure for success is preventing damage, I advocate to give priority to those threats that account for the bulk of incidents, and therefore, of factual damage. Those are the the non-intentional threats, like technical malfunction, accidental misconfiguration, and random malware. It’s just a gut feeling, but I think that only half the people who are working on strategies against malicious attackers would devote their efforts to the less thrilling every-day incidents, the incident rate would be much lower. It occurs to me that many in the community have simply lost focus. Just look at how much is written about the Vitek Boden case, most of which nonsense because the authors didn’t even bother to check the facts. Fact is that old Vitek caused 7,000 dollars worth of damage. Now compare this to the multi-million dollar damage from the 2005 DaimlerChrysler malware incident.
Comment from Ron Southworth
Time: February 25, 2008, 6:11 pm
Ralph I have no problem with your message, just your arguement is flawed and only because of your example using VB.
Baseed on publicly reported data, the bill to the utility (this impacts on the rate payers of the community effected) was considerably more than a mere 7k. The cost to the utility in responding to his activity alone was over $200,000.00AU. (Source MWS and a very conservative reported amount I assure you)
His fines and EPA’s court costs awarded againsst him alone were more than $7000.00.
Environmental harm was limited, not because of his activity but because of some very dedicated utility employees. Are you dismissing the harm caused to the environment, some areas have still not returned to their original condition prior to the spill. Even minor sewerage spills (100kl) can cause adverse effects to the environment
The reason much is written about the case is because it is one of the few publicly recorded incidents. How many organisations want the adverse publicity?
I think Ralph there is a balance between what you and Jake are both saying, that needs to be considered. I don’t think that the industry is focussing too much in these parts at least on the lower risk potential threats.
Comment from Rob Lewis
Time: February 27, 2008, 2:11 pm
@DDH
All that is really needed is the ability to rank kernel recognizable objects for integrity.(BIBA) The need to do this for field devices comes to mind immediately, or any information sharing/secure-hand offs where non-repudiation and trusted information is required.
Ranking code higher than administrators for integrity can provide tamper proof audit trails, and protection against accidental “deliberate” data dumps, protection against evil admins, or honest ones that have been compromised, and in reality, pretty well anyone can be compromised.
With a little good timing we may be able to attend and demonstrate these capabilities at Joe’s show this year.
Write a comment