Showing posts with label Process control systems. Show all posts
Showing posts with label Process control systems. Show all posts

Wednesday, February 06, 2008

The 2008 S4 Scada security conference


We recently atteded the S4 conference in Miami, USA, facilitated by Dale Peterson and the good people of Digital Bond. 

S4 is the SCADA Security Scientific Symphosium, a yearly event held in the end of january.

S4 is a rather small and intimate event that makes you feel that you are on the first row in the conference room and at the same time really have first hand access to the worlds technical expertise to the professionals in the SCADA Security arena. It is amazing to realize that there are only a few handful of people qualifying for that title.


The symposium had eight invited speakers, some very good, some less scientific or relevant. Both keynote speakers where really good. Day one Steve Lipner the Microsoft’s Senior Director of Security Engineering Strategy gave a talk on security with regards to systems and software development. If only SCADA vendors and other in the automation business would start to work according to this methods, things would certainly look a lot better.

Day two, Dave Aitel described the way a serious security researcher or a skilled attacker works when he (she?) reverse engineers executable code and proprietary and unpublished communications protocols. I just hope that this is the eye opener that many people really need. They all should know Shannons maxim and the Kerckhoff principle. The enemy knows the system. And the security should really depend on other factors that obscurity.

One of the better speakers with a really interesting topic, security in wireless systems, was Denis Foo Kune (depicted above) of Honeywell Research. His talk on ISA 100, Zigbee, WLAN and radio systems security was really nice.



For those of you not attending the symphosium, now there is a new opportunity for you to order the conference proceedings from Digital Bond.

According to Dale, Digital Bond plan to run S4 2009 again. The same dates and the same place. Mark your calendars.

Monday, May 28, 2007

The Browns Ferry incident

The reactor of an Alabama Nuclear Power Plant, Browns Ferry, Unit 3, was shutdown on August 19, 2006 as a result of a failure of a device, a special type of PLC. Whats interesting with this shutdown, is that the report of the incident actually pinpoint IT related errors, i.e. network overload, as the root cause. The report state that there was an Ethernet network installed that was to blame. This is the really, really interesting part. In a Nuclear plant, there should not be a design or implementation that could fail like this.

The incident log here and a full report from the Nuclear Regulatory Commission, NRC is available here.

As a result of this incident, the Committee on Homeland Security Committee Chairman Bennie G. Thompson (D-MS) and Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology Chairman James R. Langevin (D-RI) sent a letter to Dale E. Klein, Chairman of the U.S. Nuclear Regulatory Commission regarding the Cybersecurity at the nation’s nuclear power plants. One interesting excerpt of the letter is the following:


We have deep reservations about the NRC’s hesitation to conduct a special investigation into this incident. First, although NRC regulations only specify cyber requirements for safety systems, it is clear from the Notice that the disruption of a non-safety system can impact a plant’s safety systems. The manual scram by the operators was the only reason that the excessive network traffic in this incident did not trigger a scram by the plant’s safety systems. It is clear, therefore, that a nuclear plant’s safety systems are directly impacted by the security of its non-safety systems; a weakness or vulnerability in the non-safety network can disrupt operations and trigger a safety system shutdown.


The letter ends with seven important cybersecurity questions that the Comittee require the NRC is answering.

The details on this incident is still very scarce, with lot of interpretations by different journalists, experts, and others. We'll probably see over time what really was the source of the problem. The SCADA security bloggers at DigitalBond have several more interesting comments on the incident.

Friday, October 13, 2006

Process control networks and critical information infrastructure

Security in the societys information infrastructure or critical base infrastructure is a major concern these days. The reasons for this is, among other things:
  • The trend is that events that happens in the physical domain (e.g. sabotage, obstruction) also starts to happen in the electronical (often called "cyber") domain.
  • Many systems where designed long ago according to simple functional requirements, not to withstand a modern (potentially) hostile IT environment.
  • There is many people looking for new hot topics in the information security market....

    Anyway, this article can serve as a simple starting point for this topic

    The helpful people at UK's National Infrastructure Security Co-ordination Centre NISCC has produced quite some information in this area including best practise documents, architecture and design recommendations, etc.

    A good place to get fresh information on embedded systems security, process control systems security, etc. is the SCADA Security Blog hosted by Digital Bond. Not only do they have some nice information, they've also produced a number of tools that might be useful. Cisco's Critical Infrastructure Group (CIAG) is another interesting place with some information.

    SANS recently held a webcast on Cyber Attacks Against SCADA and Control Systems. Eric Byer talked about "his" ISID database on published incidents or attacks against process control systems and the sponsor Symantec talked some on their pen tests against process control systems. I have several problems with the ISID database:
  • The researchers draw a number of conclusions from a statistically limited number of incidents
  • The lack of publicly available information. I can live with fact that some data is hidden to protect the participating organizations, but the basic stuff - such as the definitions of "accidents", "incidents", etc, should be available for the
    data to be usable.
    I also have problems with not beeing able to get the research articles they've written on the subject.
    I've tried to get some info from Eric and others at BCIT. So far all I've got is bounced mail....

    DHS have released a report on the CyberStorm excercise, a large scale excercise with simulated attacks on critical infrastructure components. It describes, among other things, how important it is to get communication (oral, human communication) and trust working between involved parties during a crisis situation. In a context where you have a mix of govermental bodies, commercial entities and other organisations without established and trustworthy channels this might be a major problem. The excercise was done in the US, but I'd say that the conclusion is general and would be apropriate to most contries in the event of an attack against the critical infrastructure.

    Other, older, reports and documents of interest include:
  • The GOA has also released an interesting report called CRITICAL
    INFRASTRUCTURE PROTECTION -DHS Leadership Needed to Enhance Cybersecurity
    .
  • National infrastructure advisory council report on prioritizing cyber vulnerabilities