Comment from Charles Perine
Time: August 28, 2008, 7:56 pm

Personally I have always favored site search in google. In the search box type site:yourdomain.com along with your search term or combine it with a filetype search. Go see what kind of information your website is leaking.

site:yourdomain.com filetype:doc confidential
site:yourdomain.com filetype:doc internal

Comment from Landon Lewis
Time: August 29, 2008, 2:53 am

And then google alerts.. automation and alerting when a file accidentally gets put on the internet instead of the intranet portal.

Comment from Jake Brodsky
Time: August 29, 2008, 8:11 am

You touch upon a problem that isn’t easily dealt with. Classifications aside, the amount of public information out there which can be used against a utility is daunting.

The problem gets even worse when you consider what a “threat” a malicious person could be with popular street level and aerial view software from Microsoft or Google.

As for the presentation itself, I’ve seen it. I don’t understand why the authors felt it warranted FOUO status in the first place. Nevertheless, I’m concerned about the circumstances in which FOUO data was compromised.

Comment from Julian Rrushi
Time: August 29, 2008, 10:07 am

—–BEGIN PGP SIGNED MESSAGE—–
Hash: SHA1

In addition to conducting site search, one could refer to qualitative and quantitative sources developed upon careful site searches. Some 2 or 3 years ago I came across a (probably) conference discussion that mentioned a PhD dissertation in which a doctoral candidate had managed to reproduce correctly a part of the electric power grid. While I’m faithful to realism and practicality in research, as Kevin wrote above, discretion is urged in the propagation of technically sensitive information.

—–BEGIN PGP SIGNATURE—–
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIuAJE3JhHvEZ9fsERAj1lAJ9FVK6L5QqhSHYgqEQaTeOaRamD4wCfSgzJ
4i7/LZY5FCsponDPaj5PCoA=
=ZRgy
—–END PGP SIGNATURE—–

Comment from Ralph Langner
Time: September 1, 2008, 7:02 am

“once a document goes online the damage is done”

I really can’t see how telling people that some controllers’ firmware can be updated via the network could cause damage. My only concern is about trivial vulnerabilities such as this getting classified — given that the reference to an official DHS document is correct, which nobody seems to have checked so far.

Other than that, Kevin, you are essentially advocating security by obscurity here — preventing damage by keeping some information off the Internet.

Comment from Kevin Lackey
Time: September 2, 2008, 11:16 am

Ralph,
While not trying to advocate “security through obscurity” (as I have oft pointed out that such does not work) I am trying to raise awareness in regards to with whom an organization shares critical information. Basically a restatement of the old adage to “practice safe hex”.

If you have a big hole in your security do you broadcast it to the world? As this is the second time I have seen this FOUO marked document leaked, I would advocate that DHS may need to review its process and procedures regarding how they share documents with industry and educating industry in how to handle/disseminate said documents. This same encouragement can be applied to any business/organization in handling their confidential documents.

As once such a piece of information is circulating it is impossible to contain.

As to the damage, I don’t think you have fully considered the ramifications of such an attack. Though seemingly trivial, in environments without adequate firewall rules and other mitigations this vector could be devastating.

Comment from Ralph Langner
Time: September 2, 2008, 3:44 pm

Kevin, I must admit that I still don’t see devastating damage around the corner. The firmware upload feature opens just one other possibility for DoS. The big risk with controllers, however, is process manipulation. This can hardly be done via firmware upload, but it can easily be done by using the controller’s command protocol, be it Modbus, Ethernet/IP or whatever proprietary stuff. — I could make more sense out of the alleged DHS advisory if it would cover any undocumented controller port. I could make even more sense out of an advisory that educates the general public not to network controllers without properly configured firewalls.

Comment from Kevin Lackey
Time: September 2, 2008, 4:36 pm

As the document in question is still available online (via yahoo chache and liquidmatrix), I will comment to the following extent.

Imagine the following. Some malicious virus/worm author creates a worm that can infect PC hosts via several known Linux and Windows exploits and that seeks to spread itself as quickly as possible. To this worm add the capability to scan for known field device ports and push firmware exploits at field devices that effectively turn the field devices into bricks. Bricks that have to be repaired or replaced by the manufacturer. What is impact?

Depends on;
*What is the stock of replacement field devices?
*How long is the turn around time for repair?
*How many device were broken?

Among other variables.

The potential for destruction in field devices is fairly large, if there were (quite possible, but not sure on the exact numbers) a small replacement stock and a high turn around time, the impact on infrastructure could be enormous as the worm makes the rounds through various improperly protected networks.

The question then becomes, do such poorly protected networks exist? Well as field devices don’t authenticate, and no checksum is performed on the firmware, and the push can be initiated from upstream, you are depending on the other mitigations for security. Experience from the results of on site assessments shows that this is not the case (inroads exist into the control system environment). Thus while not technically a huge deal, the potential for impact is high.

Comment from Ralph Langner
Time: September 3, 2008, 4:33 am

Kevin, the weak point in your line of reasoning is “firmware exploits”. Where do those come from? Probably from some engineer formerly working for a vendor. Well, probably not. Engineering staff for these products is VERY small, thereby limiting the number of suspects to a hand full. The firmware exploit would work only with one specific model, and it is not even guaranteed that the device can’t be reloaded afterwards. All in all, slim chances for a very limited DoS attack with a high risk of having the Feds knocking on your door the week after.

On the other hand, if your malware writer would simply use “standard” good old Modbus or OPC, he would have a good chance of hitting hard with physical damage on a much larger installation base, while not being easily identified, as even the most lazy attacker can learn how to (ab)use Modbus and/or OPC.

The malware scenario is very reasonable, but I believe (predict) it will materialize different from what you suggest.

Comment from Kevin Lackey
Time: September 3, 2008, 12:53 pm

Ralph,
the firmware DOS exploit is extremely simple to create and effects a majority of field devices. All you need to create one for a specific field device is a copy of the latest firmware revision (or even any old one for that matter) for that device, a hex editor and a little (very little) ingenuity. This is why this vector has been labeled FOUO. It is simple to produce and effects the majority of devices, its potential for impact is large. No specific understanding of the firmware is necessary to turn a field device into a brick. You don’t need to be an engineer with experience on the firmware.