Sunday, May 11, 2008

Home » Unfettered

Unfettered

Electric Power 2008– is NERC CIP compliance a game?

I just returned from participating on a panel session at Electric Power 2008 in Baltimore. Electric Power 2008 is focused on electric power generation (not transmission and distribution). Consequently, it was fascinating to hear what the generation attendees felt about security and the NERC CIPs as well as to see what the next generation of power generation technologies would look like with respect to cyber.

I thought there were three important points made during the panel session:
- Cyber is real and needs to be addressed. One utility experienced three cyber-related plant trips that resulted in significant costs
- According to a retired security manager at NSA, the NERC CIPs are not adequate and simply trying to meet compliance and not actual security is not acceptable to protect the critical infrastructure
- One of the attendees noted that his plants are not considered critical cyber assets so he was at a loss at what could he do.

Some generation managers considered NERC CIP compliance a “game” to remove assets from CIP-002 without realizing they were shooting themselves in the foot by not addressing the reliability threat. Specifically, at a meeting of plant managers, one manager of a very large coal-fired power plant was charged to ensure his plant was not considered a critical cyber asset. Another plant manager whose plant had black start capability and therefore deemed a critical cyber asset by CIP-002 considered it cost-effective to remove its black start capability.  In both cases, the plant managers didn’t consider the potential cyber threat to reliability. They only thought about the cost of NERC CIP compliance, and possible fines, if their facilities were considered critical cyber assets. This same thought process occurs with transmission managers as they unplug their IP connections thinking that will exclude them from the NERC CIPs. This approach does exclude them from the NERC CIPs as currently written. However, it also eliminates the productivity improvements IP was implemented to bring as well as maintains the potential cyber vulnerabilities of serial and other non-IP connections. This thought process of generation and transmission managers defeats the intent of the need to secure the critical infrastructure.

Informal discussions with two DCS suppliers found they felt they were secure. However, in one case, a recent factory acceptance test (FAT) had no testing for security. In a second instance with another vendor, the vendor claimed his system was secure and the utility agreed. However, when I contacted the utility engineer, he said the vendor was not addressing specific vulnerabilities. Seems like a disconnect doesn’t it?

Finally, there is a great need for senior management buy-in that security is important for reliability and the bottom line, not for the sake of compliance. We are hoping to find a few senior executives willing to carry that message.
Joe Weiss

Comments (0)

Giving the Black Hats the keys to the store…

Training the Bad Guys

Dale Peterson’s April 22nd blog had the following: “Jason Larsen’s presentation on SCADA and Control System hacking from Blackhat Federal 08 is now available.”

There has been a prevailing view that control systems are secure because they are so arcane and obscure. However, the area of “SCADA Security” is making its way into the mainstream community, and worse, the hacking community.

As long as four years ago, presentations were being made at “Black Hat” (hacker) conferences on “SCADA security”. Some of these presentations may not have been technically accurate, but they have spurred interest in the subject by individuals we would rather not be involved. In fact, about three years ago, SAIC gave a presentation at a Black Hat Conference on how to hack control systems. What made this presentation unique and scary was that it provided bit-by-bit instructions on how to hack specific control system protocols.

I personally have worked with Jason on vulnerability assessments when he was at INL and with the initial control system cyber attack demonstration at INL in 2004. Jason is very knowledgeable. 

Consequently, when I found out he had given a presentation at Black Hat, I was extremely concerned. What’s more, Jason is scheduled to give two training classes on hacking PLCs at Black Hat in Las Vegas in August.

When I asked him why, his answer was they were interested.

Of course they are. Wouldn’t a bank robber want to know how to rob a bank? But just because they are interested is not an excuse to train the “bad guys.” 

You can’t legislate ethics, but common sense should prevail.

Joe Weiss

Comments (2)

How can your database be in two places at once when it ain’t anywhere at all?

Dueling Databases

In Fridays’ edition of DigitalBond’s blog, databases are mentioned.

“Dueling Incident Databases. Joe Weiss has his personal incident database. Wurldtech recently announced their new Delphi vulnerability database. Now Automation World reports that Eric Byres will be resurrecting the BCIT Industrial Security Incident Database thanks to some new funding source.”

I will not go into the issues of why there are multiple databases or how best to pool resources. However, I will provide my thoughts on the need for incident databases.

- I strongly believe one of the biggest reasons why so little is being done to secure industrial control systems is the lack of perceived need since there are so few cases that have been reported (Australia and Davis-Besse).

Consequently, control system cyber security is treated as the second coming of Y2K – nothing happened, it was simply a ruse for consultants and vendors to make money.

There needs to be a business case and the only way I know of making a business case is to show that it is real and has had significant economic impact.

- I strongly believe most people still view cyber security in the traditional IT form- “the 12-year old pimply-faced hacker concocting new Microsoft viruses or worms.” 

Control system cyber incidents are much more prevalent that many believe and most are unintentional. They are simply not recognized as cyber incidents. There needs to be a better definition of “cyber” that reflects what can happen to control systems.

- Existing IT databases and reporting do not address control systems.

Consequently, several years ago, DOE tasked CERT/CC and KEMA (myself and Bob Webb) to perform a scoping study for establishing a CERT for Control Systems.

It was recognized that private industry would not provide input to the government and consequently, it was strongly recommended that a CERT/CC, not US CERT be augmented with control system expertise.

This was not followed and consequently there is very little reporting of control system incidents.

- I strongly believe you can’t develop solutions if you don’t know the problems you are trying to solve.

Since there are so few publicly identified cases, most “solutions” for control systems are based on IT problems, not control systems. Specifically, they do not address legacy/field devices.

In fact, many of the solutions being touted as fixes can, and have, actually exacerbated control system reliability. Additionally, you can’t have “best practices” when you don’t know the problems you are trying to prevent.

- Following 9/11, there was a march to “connect the dots”. That is, with all of the disparate information, why couldn’t we tell what was going to happen.

Without an incident database and experts to review the incidents, it is not possible to determine if there are patterns occurring.
It became evident to me as Marshall Abrams of MITRE and I worked on the Bellingham pipe break that there were other control system cyber incidents of a similar nature.

Additionally, when I was at a process control systems users group meeting last week, I mentioned the Browns Ferry broadcast storm. That brought a reply from one of the attendees that he had a similar that resulted in a local blackout. I believe there are underlying patterns but they have not been adequately researched.
 
- The risk equation is frequency times consequence. Today, it is not possible to prudently assign values to either. An incident database can help.

Joe Weiss

Comments (0)

ACS Conference tells it like it is for cybersecurity

Applied Control Solutions, LLC
For Immediate Release
Contact: Joe Weiss
(408) 253-7934 or joe.weiss@realtimeacs.com.
Cyber Security Conference Focusing on Potential Causes, Prevention of Recent Power Blackouts and Plant Shutdowns (Trips)
August 4-7, 2008 – Burr Ridge, IL

Applied Control Solutions, LLC announces the eighth in a series of conferences focused on cyber vulnerabilities of industrial control systems, August 4-7, 2008, in the southwest Chicago suburb of Burr Ridge, IL. This conference is sponsored by Control magazine, and www.controlglobal.com, where the Joe Weiss Unfettered blog is hosted.

Due to recent cyber-related blackouts and plant trips, along with the five year anniversary of the Northeast Blackout, potential cyber-related incidents and their prevention are now the main focus of the Conference agenda. The focus of cyber security has been on traditional cyber security including passwords, firewalls, and compliance, not system reliability. Reliability of industrial facilities (power plants, substations, chemical plants, refineries, water systems, pipelines, etc.) has focused on control system challenges, not cyber vulnerabilities. This Conference addresses the intersection of control system vulnerabilities and reliability of industrial control systems and processes.

Presentations and focus of the Conference include:

• The recent Florida cascading outage shines a bright spotlight on cyber security of relays, switches and other remotely accessible field devices. A session will be devoted to inherent cyber vulnerabilities of these devices, lack of appropriate logging, and the associated IEEE standards efforts to protect these devices.

• A recent nuclear plant automatic shutdown, resulting from a software change, brings up new questions concerning the unintended consequences of workstation and PLC reboots. With IT security, NERC CIP, NEI-0404, and other regulation pushing to expeditiously patch control system workstations, attendees will discuss if the proposed “cures” are “worse than the disease,” along with broad implications and potential solutions. Possible explanations for previously unexplained “trips” in fossil, chemical, and other process plants will also be explored.

• End-users will discuss impacts and issues unique to the application of firewalls for control system networks.

• IT practices that have impacted control systems will be discussed, including Microsoft’s recent disclosure about Excel calculation errors, unintended consequences of patching control system workstations, and scanning of control system networks.

• Case histories of control system cyber events, control system cyber security forensics (or lack thereof), demonstrated control system cyber security technologies, control system cyber security R&D, and status of government efforts on control system cyber security will be explored. This will include cyber security regulations and best practices for nuclear power plants.

• Control system hacking demonstrations will be conducted. There will be demonstrations of hacking control systems, using actual control system devices, not emulations. One demonstration will be the hack of a typical process controls safety system. The attack will traverse a firewall, causing a fault in both a typical controller and safety system without any indication at the HMI (operator displays) until it is too late (i.e., the process under control fails in a non-fail safe condition).

This Conference has application for utility and other industrial end-users, regulatory, university, and business professionals responsible for, or dealing with, control system security, IT security, and control system operations and maintenance.

Applied Control Solutions, LLC has more than 35 years of experience in developing, implementing, maintaining, and securing industrial control systems for multiple industries. Additionally, Applied Control Solutions personnel have supported government and university efforts in modernizing and securing control systems and providing training on how to secure and optimize these systems.

The Conference will be held at Marriott Burr Ridge, Burr Ridge, IL. Cost to attend is $800 for US government and university personnel and $1495 for others.

For further information, contact Joe Weiss at joe.weiss@realtimeacs.com or see www.realtimeacs.com 
 

Comments (0)

Lightbulbs Slowing Going on over Control System “Cyber Incidents”

I had a meeting Wednesday morning with an IEEE standards committee on cyber security of substation devices. Following that, Marshall Abrams from MITRE and I gave a presentation at RSA, which is billed as the world’s largest cyber security conference. I then gave a presentation at a major control system users’ group meeting. There were several other presentations at RSA on the subject of “SCADA security.” In one of the panel sessions, there was a discussion about media hype and how it is hurting the process by jading management. Following that concern, a presentation was made about how easy it was to hack the grid. It certainly succeeded in getting media hype on an approach that is dubious at best in terms of doing any damage to control systems.

As to the three meetings I attended, the reactions at all three were remarkably similar. To start with, there was a lack of appreciation of how real the problem really was. There was also a lack of understanding by the IT community of the uniquenesses of these systems and why solutions need to be tailored to these systems. More importantly, the “light started going on” with several knowledgeable control system engineers as what was actually meant by the term “cyber incident.” Once it was explained that a cyber incident means an impact on confidentiality, integrity or availability, and not just an intentional attack, several people came forward to say they had experienced problems (cyber incidents) resulting in system downtime in substations, power plants and chemical plants.

My database is increasing and the need for discussions on preventing these types of events is growing more urgent. Consequently, there will be significant discussions on actual cases at the August Cyber Security Conference in Chicago.

Comments (0)

Now It’s Official

The following report by Ryan Singel appeared at Wired.com yesterday.

April 09, 2008
 On June 10, 1999, a 16-inch diameter steel pipeline operated by the now-defunct Olympic Pipeline Co. ruptured near Bellingham, Washington, flooding two local creeks with 237,000 gallons of gasoline. The gas ignited into a mile-and-a-half river of fire that claimed the lives of two 10-year-old boys and an 18-year-old man, and injured eight others.

Wednesday, computer-security experts who recently re-examined the Bellingham incident called its victims the first verified human casualities of a control-system computer incident.

For the complete story, click here. 

We’ve known all along something like this was bound to happen, but sometimes you hate to be right.  

Comments (0)

What’s Missing?

I have been involved in hosting a conference on control system cybersecurity for seven years. It has always been held with a focus on and with the perspective of a control systems engineer. Several events have “opened my eyes” to what seems to be missing:
* Design issues. The control system infrastructure is analog. Industry is upgrading to digital, but the infrastructure, as well as the design philosophy, remains analog. This has led to significantly more complex systems with significantly more complex interactions with unexpected consequences.
* Complex interactions. Several control system unintentional cyber events were caused or exacerbated by the complex interactions of systems that were not addressed in the design process or by adequate procedures.
* Standards and regulations. Standards and regulations are being proposed for control system cybersecurity focusing on the more traditional cyber threats from the Internet, IP and Windows. As mentioned, the recommendations to meet those threats have contributed to some of the control system cyber incidents.

These issues led to an epiphany about control system cybersecurity conferences and other cybersecurity and reliability conferences in general. The focus of cybersecurity has been on traditional cybersecurity including passwords, firewalls and compliance, not system reliability. This is where most cybersecurity conferences focus. Conferences on reliability of industrial facilities (power plants, substations, chemical plants, refineries, water systems, pipelines, etc.) focus on control system challenges, not cyber vulnerabilities. There is a need to address the very complex intersection of control system vulnerabilities and reliability of industrial control systems and processes. This is the August Applied Control Solutions Conference is about – what and how can we recognize the complex interactions between the older analog infrastructure as it collides with the new digital world.

As an aside, Marshall Abrams from MITRE and I will be giving a presentation tomorrow at RSA, which is billed as the world’s largest cybersecurity conference. It will be fascinating to experience the interaction of this major IT security conference on a presentation of control system cyber events. I am then scheduled to give a presentation at a major control system users’ group meeting. It will be interesting to see the reactions between these two vastly different audiences. I will provide my reactions later this week.

Comments (0)

Why Aren’t Solutions Addressing Problems?

I read about, or attend, government programs, industry programs, and industry conferences that purport to have solutions for “SCADA security”. All I can do is shrug my shoulders.  There are several fundamental issues that have not yet been addressed:

- There is still a dreadful lack of understanding about legacy field devices (non-Windows-based systems). Recently, the following question was posed on the SCADAsecurity listserver: “what is unique about SCADA security?” I find it incredible that someone would be asking that question on that specific listserver at this time and even more incredible were some of the answers.

- There is no information sharing, or even solid understanding, about actual control system cyber incidents.

- We are still learning. Systems today are complex and getting more so. The law of unintended consequences keeps recurring with unexpected results. I thought NIST SP800-53 was the most comprehensive programmatic approach available and would address existing case histories. However, the latest incidents show SP800-53 also needs to be extended.

- There is no “connecting the dots.” One of the lessons learned from 9-11 was to understand how seemingly independent events could be connected. I have identified over 90 cases (and growing) of control system cyber incidents. A cursory look shows there are some similarities. There needs to be a more comprehensive assessment to determine if there are patterns in either intentional or unintentional events that can lead to improvements in policies, programs, and/or technologies.

- Many of the “SCADA security” solutions are repackaged IT solutions – another VPN, another firewall, etc. Again, that word crops up – “assume”. These solutions assume that the data entering the VPN is trusted – it isn’t. There are only two technologies that I am aware of that are trying to address this issue.

Hardware:
- There has been one public demonstration of an exploitation of a control system vulnerability that has actually destroyed equipment – Aurora. Prior, to the disclosure one company developed a hardware fix – in this case the Cooper REID relay. This problem was deemed so important the Electric Sector ISAC issued an Advisory (not a requirement) and sent it to other industries. Since there did not appear to be a push by the electric industry to address the Advisory, a Congressional hearing was held with follow-up FERC questions. To this day, very few utilities have bought the fix, and no one that I am aware of has implemented it. Why????

Software:
- Through DHS’ LOGIIC program, there have been several software solutions for “protecting” oil/gas control systems. One aspect of the solution is to identify potential cyber attacks by using a powerful software event correlation engine. Generally, legacy control systems have no forensics for cyber and it is still not clear to me we know the spectrum of control system cyber attack signatures. The lack of control system cyber forensics has been abundantly clear as we try to do retrospective analyses of control system cyber incidents.

Programs:
- The electric industry has developed the NERC CIPs to “protect” the bulk electric grid from cyber events. Since the publication of the NERC CIPs, I am aware of two major blackouts in the US that were cyber-related that were outside the scope of the NERC CIPs. The NERC CIPS also would not have addressed a cyber-related major blackout that occurred prior to the issuance of the NERC CIPs.
- The nuclear industry has developed NEI-0404 to protect nuclear plants from cyber events. There have been two nuclear plants that have scrammed (shutdown) because of cyber-related issues. Similar to the limitations of the NERC CIPs, NEI-0404 wouldn’t have addressed either of those two nuclear plant events.

Education:
There are very few (I don’t want to say zero) college courses dedicated to control system cyber security, particularly the technical issues. There is also a yawning gap in the academic community between control system expertise and computer science expertise. Efforts by Livermore National Laboratory to develop course material for control system cyber security focus on policy not technology. The University of Illinois will be holding a Summer School session funded by NSF entitled: “Cyber Security for Process Control Systems.” The course is focused on electric power systems with no focus on power generation. Yet, the term “Process Control” is reflective of generation not T&D. And what about all the other “process industries?” Don’t they deserve equal time in a course about process control systems?

Even control system cyber security procurement guidelines are affected. The procurement guidelines need to address relevant control system issues that have been demonstrated to affect control system reliability and availability. So far, I do not believe this to be the case.

Joe Weiss
 

Comments (0)

Nuclear plant cyber security has a ways to go

As a nuclear engineer who has worked inside and outside of the nuclear industry, I have my thoughts on why nuclear plants are so far behind non-nuclear facilities in securing control systems. I spent 5 years managing the EPRI Nuclear Plant Instrumentation and Diagnostics Program. Even though EPRI’s purview is R&D, I did not do “bleeding edge” research on new instrumentation and controls technologies because it would not be useable in nuclear plants until demonstrated elsewhere. I then spent 5 years managing the EPRI Fossil Plant Instrumentation & Controls Program. Here, I was able to do “bleeding edge” research in instrumentation, controls, and communications (I received 2 patents on instrumentation and controls technologies). What became obvious to me was non-nuclear facilities would implement new technologies such as Internet access and modern telecommunications if they thought it would be financially prudent while nuclear plants could not implement new technologies until it was well-proven elsewhere. This means the non-nuclear community has vastly more experience and expertise than the nuclear community in cyber security. Yet, the nuclear community refuses to take advantage of these resources. Why???

The prevailing wisdom is that nuclear plants are isolated and not connected or interconnected. At least for some nuclear plants, that is simply not true! I personally know of many nuclear plants with remote connectivity to and from their nuclear plant networks. One interesting case was mentioned at the Applied Control Solutions Conference in Knoxville last August by a representative from a nuclear utility. He mentioned they installed firewalls between their nuclear plant networks and Corporate network because their nuclear plant networks were infecting the Corporate network with malware, not the other way around.

Commercial nuclear plants have several interesting aspects:
1) Nuclear plants have been viewed as being isolated and immune to cyber events. However, there have been several documented cases where nuclear plants have experienced cyber events. Several other cyber events have occurred that have not resulted in reactor scrams or other “unusual events” and so are not documented.
2) Because all “unusual events” result in some form of NRC notification, it is possible to glean information from nuclear plant events that would not be available from non-nuclear plants.
3) In most cases, nuclear plant personnel have not participated in non-nuclear control system cyber activities such as ISA S99. As mentioned above, this has kept the nuclear industry from obtaining the relevant valuable expertise and experience from others.
4) The nuclear industry guidance for cyber security (NEI-0404) was developed primarily from an IT perspective and is also primarily a programmatic document that does not address the unique aspects of control systems. Similar to the NERC CIPs, NEI-0404 would not have prevented many of the cyber events that have occurred. Moreover, some of the guidance in NEI-0404 potentially could have either caused or exacerbated some of the cyber events that have already occurred.

Other specific details about nuclear plants and cyber security include:

- In the November 2007 issue of Power, there are two articles on nuclear plant networks- “Plantwide Data Networks Leverage Digital Technology to the Max” and “Upgrade your BWR Recirc Pumps with Adjustable Speed Drives”. Both tout the value of advanced communication networks and neither addresses the cyber security vulnerabilities they open. In the first, it is suggested that the plantwide data network (PDN) include process control (DCS, PLCs, etc) and plant communications (public address, radios, cell phones, pagers, etc). It is also suggested that process monitoring, operator support, plant security (physical), and supplemental monitoring/testing be included. These are all good ideas (ironically, 10-15 years ago before cyber security was an issue, I was writing papers and sponsoring research at EPRI encouraging this approach), but they need to include cyber security considerations in which the article is essentially silent. The second article on BWR recirculation pumps going to variable speed drives seems to ignore the Browns Ferry 3 broadcast storm experience. Variable speed drives are definitely provide a productivity improvement and networking the drives are a good idea, but ….you still need to address the cyber component you just opened.

- November 2007, EPRI issued Technical Report 1015087, “Instrumentation and Control Strategies for Plant-Wide and Fleet-Wide Cost Reduction”. The report states: “Coordinated improvements to shared communications and computing infrastructure, plant processes, and organization…”. This statement almost cries out that cyber security will be an issue. The report simply says to consider cyber, not what to do.

- The December 2007 issue of Nuclear News references an IAEA nuclear security technical guidance document. Section 1.3 of the document, “Computer Security at Nuclear Facilities” states: “The protection of the computer systems at nuclear facilities can, in principle, be achieved using the same methods and tools that have been developed within the computer community…”.  This statement is at best misleading. Control systems are composed of an HMI that may be Windows-based and field devices that are not. Traditional business IT security can be applied to the Windows-based HMI. However, for field devices, business IT security (policies, procedures, technologies, and testing) often is NOT appropriate. Several recent nuclear plant cyber events would not have been prevented by traditional IT security. Moreover, they could have been CAUSED by applying inappropriate IT security techniques.

The recent nuclear plant cyber incident resulted in an automatic scram from settings that closed valves. The cause is not one that has been considered by many and could also explain previously unexplained trips in fossil plants, chemical plants, and other process facilities. To prevent events like this from happening, it will require developing appropriate design criteria, appropriate policies and procedures, and most of all the need to have control system domain expertise as part of the cyber team.  What is also interesting about this event is that none of the existing cyber monitoring would have detected the event. Additionally, certain IT practices such as automatic patch management could CAUSE an event like this given the “right” conditions and plant design. As a result of the wide-ranging (non-nuclear) implications of this recent event, we will dedicate a session at the August Control System Cyber Security Conference in Chicago to this event.

One other interesting aspect of nuclear plant cyber security is the gap in regulations for grid reliability and continuity of nuclear power. NRC is responsible for nuclear plant safety, not continuity of nuclear power. Since nuclear power makes up about 20% of US electric power generation and each nuclear plant represents a large portion of local generation, loss of nuclear power generation can, and has, had a significant impact on grid reliability (see Northeast Outage and recent Florida outage). NRC was involved in the Browns Ferry event not because of the broadcast storm, but because the operator chose to shut the plant down. If the operator would have chosen not to shut the plant down, NRC would not have been notified, yet the grid would still have experienced the loss of more than 700 megawatts. This could easily affect grid stability and reliability. Consequently, there is a need to either develop new standards or include nuclear plant continuity of power in existing cyber security standards for grid reliability.

Joe Weiss

Comments (1)

KYFHO: Why IT needs to keep its distance from control systems or learn how to do it right

Why IT needs to keep its distance from control systems

Several actual events and tests have shed new light on why IT needs to understand the issues with control systems before things go uncontrollably wrong. That is, control systems (Operations) coordination and leadership is absolutely required before those networks are touched in any direct or indirect manner. Additionally, it is also important for IT to recognize that control system cyber vulnerabilities can be different than IT cyber vulnerabilities. I have been working with MITRE and NIST to demonstrate the benefits of utilizing NIST SP800-53 rather than the NERC CIPs, NEI-0404, etc. We are doing this by taking actual control system cyber incidents and identifying the NIST SP800-53 controls that were violated that allowed the events to occur and how applying the appropriate NIST SP800-53 controls could have prevented the events. One of the most interesting parts of this effort is the selection of the cyber incidents we are analyzing - all caused substantial equipment, environmental, and/or financial impacts (including deaths in one case) and were NOT caused by either Microsoft or the Internet.

Specific issues with IT recommendations for control systems:
1) Anti-Virus
- Various control system workstations and PCs have been shutdown by newer versions of AntiVirus software because they require more computing resources than are available to many older control system workstations.
- NIST performed testing on impacts of AntiVirus definition updates on typical control system processors. The testing demonstrated that depending on the speed and loading of the processors that virus definition updates would create a 2-6 minute denial of service.

2) Patch Management for control system workstations
- Control systems often use commercial operating systems such as Windows. However, the version of Windows that are used are often customized by the control system supplier so that the Windows version being used is actually a “Honeywell”, “ABB”, “GE”, “Siemens”, “Areva”, etc version of Windows. This makes the control systems version of Windows different. Consequently, when the Slammer worm hit several years ago, one of the major control system suppliers had to issue a notice to their customers that the Slammer worm may impact the system, but the Microsoft patch WOULD compromise the system.
- There was an article in the March 20th edition of Information Week with the headline: “Excel 2003 Patch Causes Calculation Errors”. Excel is embedded in many control system applications. The potential impact of Excel calculation errors in control system applications is appalling to consider, especially since the errors occur when realtime data is entered into Excel. “The error shows up if a patched version of Excel is linked to a real-time data source through macros built with Visual Basic for Applications, according to Microsoft.” Does this application of Excel sound familiar?
- There has been at least one case where testing for patch upgrades led to system downtime. In this case, the patch was tested in the lab but without checking for impacts on software licensing keys.  In the field, the fix erased the licensing keys resulting in system downtime until the keys could be reset.
- Recently, a nuclear plant was scrammed (automatically shut down) from full power operation stemming from a reboot of a workstation. Patch management causes workstation reboots. The unintended consequences of workstation or PC reboots have not been adequately accounted for in control system applications.

3) Vulnerability assessments
Often, there is an erroneous assumption that vulnerability assessments mean network scans (either passive or active). There are two problems with this assumption:
- Without “walking down a system”, there is no accurate knowledge of what is actually installed in the field. For example, I have yet to meet with an end-user that knew what modems were actually installed and connected in the field.
- Active and even passive scans have shut down many control system networks or worse, actually damaged control system hardware (hackers should be that good). There are VERY FEW people that understand how far to go in scanning control system networks. This could be a fruitful area for the national labs in teaching people how to do this very delicate operation.

Applying SANS, NERC CIP, NEI-0404, ISO-17799, ISO-27001, and other IT-related guidance to control systems without an understanding of the impacts on system performance is not only imprudent, it can be dangerous to the systems and potentially to the public! 

Joe Weiss

Comments (1)

Search Posts

May 2008
M T W T F S S
« Apr    
 1234
567891011
12131415161718
19202122232425
262728293031  

Unfettered is
powered by WordPress.

Pages (9): [1] 2 3 4 Next ... Last »