Saturday, February 12, 2011

Symantec Updates Stuxnet Dossier

Yesterday Symantec published version 1.4 of their “W32 Stuxnet Dossier”. A blog entry explains that there were essentially two new items included in the updated version (and Symantec intends to continue updating their report as they continue to come up with new data on the attack). First they were able to time track the infection and track it back to five specific initial attack vectors. Second they confirmed much of the work that Ralph Langner has reported on the 417 attack code (without reaching any conclusions about the specific target because the code was ‘disabled’).

Tracking the Infection

Certainly the most valuable part of this new information is the information Symantec was able to provide on how the worm was physically spread from the initial attack vectors. They are in a unique position to conduct this portion of the research because they possess 3,280 distinct copies of the virus from the wild representing 3 separate variants of the worm. This combined with the fact that Stuxnet records system data (including time stamp and IP address) every time that it infects a new host and Symantec can provide a good picture of how the attack proceeded.

Symantec has been able to show that there were five separate organizations that were used as initial attack vectors, what Symantec misleadingly calls targets. All five of these initial vector organizations, Symantec reports, have a presence in Iran. Apparently an infected USB drive was introduced into these organizations as a way of pointing the worm at its intended target without risking the actual presence of the author’s agents in Iran.

In its discussion of the spread of the worm the Dossier authors make a point of noting that the worm had a designed-in self-limiter, after infecting three separate computers the infection from that particular device shut down. Looking at the cluster diagrams on page 9 of the Dossier it does not seem as if any single attack-vector organization was infected more than twice by the initial device on each attack wave.

While this may simply be a data anomaly due to the small sample size, it seems unlikely with ten separate infections. It seems more likely that the agents carrying the infected USB drive were under instructions to limit their infection to just two computers to reduce the likelihood of their being detected.

The other interesting thing from these diagrams is that it does not appear that there is any cross linking between the infection trees. We can clearly see from the diagrams that within an infected zone there are a number of places where a single computer is linked to multiple sources, as we would expect from an increasingly networked world. It is not clear whether Symantec just failed to note cross infections from the initial attack vectors, or if these infections were actually isolated from each other.

The Reason for the Tracking Data

While Symantec is to be commended for putting this data together, it seems obvious that the virus designers put this tracking tool into the worm for a reason. If they were able to collect this data from infected computers (which they certainly were until the identified command and control link was shut down) they were able to paint a very complete picture of how their attack spread. This would certainly be valuable information to design subsequent attacks.

With that in mind I would like to suggest that clearly identified C&C computer that was shut down relatively soon after Stuxnet was identified was not the only method by which the originators planned to get information back from Stuxnet infected computers. If I were designing this system I would have seeded the operational area with a network of communications nodes.

Given the information sharing design of the Stuxnet worm, each time an infected computer talked with another computer on its network it would drop an updated copy of its infection history into the new computer. If a separate virus were designed to set up a very specific bot network, one designed to ‘listen for’ a new set of Stuxnet infection histories and report that history back to a separate command and control computer, the Stuxnet authors could keep receiving updated information on the progress of the spread of the virus. It would also allow them to map the optimal path to link to any particular infected computer.

In the infection on a targeted computer (or attached PLC’s) were not completely cleared, then a subsequent Stuxnet-like virus would be more easily targeted at those systems. Such an attack could be very directed without the collateral exposure that led to the discovery of Stuxnet. And with the spread of Stuxnet far and wide across the world, the attack would not necessarily have to be limited to Iranian nuclear facilities or even against just targets in Iran.

This bot network would be very hard to detect since it would be operationally limited to a very small set of instructions. Unless one knew exactly what to look for this network could exist for years before it was discovered. In fact, if the designers were particularly devious, they would set up at least a couple of separate bot networks to allow for one or more to be detected and remediated without loosing contact with their tools.

Identifying Stuxnet Source

With the source tracking data that Symantec has, it would seem to be a relatively simple investigation to determine who carried the infected USB drive into the attack vectors. Symantec obviously does not list the real identity of these initial targets, but they must certainly have that data. An intelligence or law enforcement organization should be able to take that data, conduct the appropriate investigation and determine who was likely to have carried the USB drive. Will this happen? I doubt it.

Friday, February 11, 2011

LEAPS.TV CFATS Program

Earlier today I sent of the last of my contribution to the “Chemical Facility Anti-Terrorism Standards Overview for Law Enforcement” training program that will be shown on LEAPS.TV next week (Wednesday, February 16th at 1:00 pm EST). This has been my first detailed foray into on-line education development and it is now in the hands of the post-production crew at LEAPS.TV.

I’ve done a wide variety of training development over the years and just last year did some content work for a computer based training program. This was different though. I did the typical content development, the voice recording, and some of the audio editing (a new experience). We’ll have to wait until Wednesday to see if Jim Cavanagh and his team at LEAPS.TV can make me sound respectable.

This program arose out of a discussion with Jim that started after I did a blog posting on a Suspicious Activity Reporting training program done by LEAPS.TV. Jim read the comments that I left on his site after I completed the training, checked out my blog and contacted me to thank me for my review. One thing led to another and Jim asked if I would be interested in doing a CFATS introduction for law enforcement personnel. The rest will be history on Wednesday afternoon (and it will be available for on-line viewing starting on the 17th).

The program is designed to give local law enforcement personnel a brief introduction to CFATS and a brief overview of some of the things they will need to take into account when planning for a counter-terrorism tactical response at a CFATS facility. Since almost all facilities will rely on law enforcement personnel to provide a tactical response to a terrorist attack on their facility, I thought that a program like this would be helpful to that community.

If this goes over well, Jim has talked to me about doing a series of more detailed programs getting into some of the things that police forces will have to understand to provide an appropriate response. I would address some issues like chemical safety, hazcom, CVI.

Anyway, if you know some police personnel that might have to respond at a CFATS facility, please point them at this class. It is free of charge (registration required) and arrangements can be made to receive continuing education credits for watching the course (and a taking an on-line test; that’s what I delivered today). The run time for this will be somewhere around 30 to 40 minutes (the final edit hasn’t been done yet).

If you get a chance watch this program, please let me know what you think. I’m thick skinned and I really do want this to work out. I think the underpaid law enforcement folks that we trust to protect us everyday could use this type of training if they work around chemical facilities. Please, help me to make this a worthwhile training program.

Cyber Forensics Clearinghouse ICR

Today the DHS Science and Technology Directorate published a 60-day information collection request (ICR) notice in the Federal Register for a new information sharing program that S&T is planning on establishing to aid in the expansion of computer forensics techniques.

The ICR would allow the CyberForensics Electronic Technology Clearinghouse (CyberFETCH) program to collect personal information that would be used to “determine the authenticity and suitability of the practitioner requesting access” (76 FR 7871). Once properly vetted the ‘practioner’ would be authorized secure access to the CyberFETCH clearing house that allows “users to share information, best practices and lessons learned within a secure collaborative environment”.

Public comments on this ICR are being solicited by S&T and should be submitted by April 12, 2011. Comments can be submitted via the Federal eRulemaking Portal (www.regulations.gov; Docket Number DHS-2011-0004).

DHS ICS-CERT Advisory on Night Dragon

Yesterday the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) published an advisory giving a brief overview of the McAfee Night Dragon Report. This ‘Night Dragon’ (the McAfee code name) cyber attack on multiple companies in the oil and gas sector was mainly an IT system cyber espionage attack; ICS-CERT notes that data was also collected from SCADA systems.

There is an article on CNET.com that provides a better narrative about the long term operation that apparently originated from China and ICS-CERT was kind enough to give the link to the McAfee white paper about this attack. While both of those sources are worth reading, this Advisory provides a brief and concise description of the indicators of the various parts of the attack code that would allow a cyber security team to determine if their systems were similarly attacked.

There is nothing in these reports that indicates that ICS attacks did anything more than collect information from the affected control systems. However, we now know (thanks to analysis of the Stuxnet worm) that the types of information collected from SCADA systems might allow a targeted Stuxnet-like attack on those systems. More importantly, this attack methodology would apparently allow an attacker to gain the ICS system access necessary to initiate a Stuxnet-like attack.

The scariest thing about Night Dragon is not the extent of the attack, but the fact that this apparently very successful attack used no new vulnerabilities, technology or techniques. The use of spear phishing attacks to compromise VPN accounts should be of special concern to ICS security managers. It is obvious that ICS users with authorized remote access via VPN need to have recurrent training on identification and avoidance of spear fishing attacks.

Thursday, February 10, 2011

S 275 Introduced – Pipeline Safety

Last week Sen. Lautenberg (D, NJ) introduced S 275, the Pipeline Transportation Safety Improvement Act of 2011. While this bill has many of the same provisions found in S 234 (that I blogged about earlier) there are additional requirements in this bill, some of which address deficiencies I noted in my earlier blog.

Hazard Communications

Lautenberg’s bill {§8(a)(2)}would require PHMSA to publish (presumably on its web site, but that is not an absolute requirement) emergency response plans (with SSI information redacted/removed) that are currently required to be developed. No, it doesn’t address the problems with ERPs that I identified last year.

Incident Reporting

The legislation does require {§11(1)} the Secretary of Transportation to develop rules requiring pipeline operators to notify state and local officials when a leak or rupture occurs. It also requires the review of current procedures for coordinated notification through the National Response Center {§11(2)}.

A Permanent GPS Timing Outage?

Remember the late alerts from DHS ICS-CERT last month (see my posts of 01-25-11 and 01-26-11) about the tests being conducted by the Air Force that might (but it turned out not really) affect the timing signals for certain SCADA devices? Well, according to an article at AVWeb.com there might be an even more serious problem when a new 4G Broadband Network by LightSquared goes online later this year.

According to the article, the GPS industry claims that the L Band frequencies approved by the FCC for the LightSquared project (1525 MHz—1559 MHz) are very close to the frequencies being used by the GPS system (1559—1610 MHz). Apparently at least one GPS device (a Garmin 430) looses its GPS fix within about 5 miles of a 4G transmitter on the nearby approved frequencies.

LightSquared reportedly disputes the potential of problems with ‘properly filtered’ GPS devices, but is required by the FCC to test devices against their actual transmission system. That testing is supposed to be done by the end of June. Nothing in the article indicates that there are any plans for testing ICS devices that use GPS signals for timing purposes.

Hmmm. It would sure be nice to hear that ICS-CERT was getting involved in this testing issue before the end of June. Or, are we going to have to wait to see an ICS-CERT alert that there are reported problems with ICS outages because of unidentified transmitters near facilities?

Once again this is a demonstration of the potential problems that arise when someone develops an unauthorized (not illegal, just not specifically authorized) usage of a ‘free’ resource like the GPS timing signal. Since no one (read FCC) officially knows of the usage, they are under no requirement to take that usage into account when making official decisions affecting that resource.

As the RF spectrum is getting more and more crowded because of the new communications devices being used, how many more frequency interference issues will be affecting ICS devices? Have all of these devices been ‘properly filtered’ to avoid interference from transmitters on nearby frequencies? Has anyone bothered to do the necessary testing to determine how much of a problem this could be?

Wednesday, February 9, 2011

Remote Monitoring Equipment of Rail Tank Cars

SECURITY WARNING: If you are reading this blog in Washington State you may want to close this blog without reading further. It discloses information from the Washington State Fusion Center that is clearly marked unclassified, but not to be disseminated to the public. Sorry about that…

Late last month the Washington State Fusion Center (WSFC) published a bulletin (a copy can be found on my site) regarding the report of a suspicious device on a chlorine railcar. It turns out that the device wasn’t a terrorist IED, but rather a Remote Monitoring Equipment (RME) device; an electronic transponder used to track railcars, particularly hazmat railcars. The bulletin shows a picture of a little metal box (complete with what appears to be a small radio antenna) sitting on top of the rail car.

Clearly the personnel at the local rail yard were not familiar with the device and reported it to their local fire department. Those rail workers are to be commended on their reporting of, what was to them, a suspicious device on a chlorine rail car. This is one of the instances when a suspicious activity report (SAR) turned out not to be so suspicious once it was investigated. I just hope they weren’t made fun of once it was determined what the device actually was.

WSFC is to be commended for their rapid turn-around of this information. The original incident was reported on January 22nd and the Bulletin was published on January 26th. Considering that the incident happened on a Saturday and some fairly detailed research was done on the various RME’s currently in use, this is a very quick response; KUDOS. I hope that DHS (TSA in particular since they regulate freight rail security) picked up on this report and spread it throughout the rail security community.

Now the Problem

I really get a bit miffed when the government tries to restrict access to information that is clearly necessary to properly do ones job. This is a perfect case in point. At the bottom of each page of this bulletin (almost certainly on the bottom of all WSFC bulletins) we find:

“NOTE: This information is the property of the Washington State Fusion Center and may be distributed to federal, state, tribal, or local government law enforcement officials and EMS/fire personnel with a legitimate need-to-know. Further distribution without Washington State Fusion Center authorization is prohibited. Precautions should be taken to ensure this information is stored and/or destroyed in a manner that precludes unauthorized access.”
Clearly this information needs to be communicated to all personnel (mostly outside of the government) that are required to conduct security inspections of railcars. This includes train crews, rail yard workers, shippers and receivers; all people specifically denied access without specific approval of WSFC. Will the individual names have to be submitted and vetted? Why? All of the information (other than the sanitized initial SAR) is readily available on the internet.

Now, I really doubt that anyone at WSFC really considers this information to be sensitive. I suspect that their bulletins are automatically printed with this as part of the standard footer. That certainly would make it easier to ensure that truly sensitive (but unclassified) information is appropriately marked. Unfortunately that type process requires the releasing official to make an effort to remove the marking from a document.

This makes it almost certain that the marking will not be removed. After all, in most security professional’s minds it is better to over-classify than to let sensitive information slip out of control. That way you don’t give the enemy any advantage…. Besides, what harm could it do?

What could have happened with the initial SAR if it had gone to a police station that was concerned about a potential terrorist attack on that chlorine rail car, a police station that did not receive/see this bulletin? An initial investigation would find an unidentified box with an apparent radio receiver on top of a TIH rail car. If a bomb squad was called in the unidentified, but sealed metal box would be assumed to be a bomb equipped with anti-tamper devices (to a hammer everything looks like a nail). The box is going to be ‘disrupted’ and everyone involved is going to look foolish when it turns out to be nothing. So much for any future SARS from that rail yard.

On the other hand, if this document is widely distributed to those people that would be expected to come into contact with these railcars, they could conduct the appropriate inspection of the device to locate the identification tag. After verifying the identification information, the device could essentially be ignored. If there were discrepancies in the identification information, further investigation would be warranted.

So TSA, how about producing your own version of this bulletin and get it distributed to all fusion centers and all rail security officers. That way we can insure that this information gets in the hands of those that really need it, even if they aren’t in the govmint.
 
/* Use this with templates/template-twocol.html */