Keynote Address by Dr. Arden Bement
Director, National Institute of Standards & Technology
At the NSF Workshop on
Critical Infrastructure Protection for SCADA & IT
October 20, 2003
Thank you and good morning. I'm very pleased to have the opportunity to address what I feel is an extremely timely and important workshop.
I'd like to particularly thank Representative Gutknecht. As a Vice Chairman of the House Science Committee Gil Gutknecht conducts direct oversight for all non-defense federal scientific research and development, ensuring that federal S&T tax dollars are being spent wisely and efficiently.
So in a sense he's a senior member of my board of directors.
During his tenure on the Science Committee, Representative Gutknecht has gained an expertise about many scientific topics from quantum physics, information technology, biometrics and nanotechnology, to the more arcane topic of standards. All of interest to NIST.
Even though standards may not excite many folks back in Washington, Gil Gutknecht understands their importance to our nation's economic infrastructure and the overall health of our economy. We at NIST truly do appreciate his hard work and efforts on behalf the scientific community, and especially NIST. I, and the staff at NIST, consider him a very good friend of NIST.
I was tempted to open up my remarks this morning with a dramatic statement about how the Northeast power blackout last August represented a "wake-up call" to all of us concerned with critical infrastructure protection.
It's true that we have not yet seen a full analysis of just how the worst blackout in the history of the power grid happened. And it's extremely unlikely, of course, that it was the result of a deliberate and malicious act.
But the very fact itself -- an out-of-control cascade of events that left eight states and part of Canada and some 50 million people without electric power -- is a compelling illustration (were it not too dark to see it) of how far we have to go in hardening one of our most critical infrastructures.
As I say, I was tempted to go with the old "wake-up call" metaphor, but I realized that most of the people in this room would recognize that August, 2003, was a wake-up call only if you had somehow managed to sleep through all the others.
In fact, we've had any number of wake-up calls. Some of them were official, including:
- The 1997 report Critical Foundations: Protecting America's Infrastructures prepared by the President's Commission on Critical Infrastructure Protection.
- 1998, the signing of Presidential Decision Directive 63 calling for a national strategy to protect America's critical infrastructures, particularly its cyber-systems, and creating the Critical Infrastructure Assurance Office; and
- Executive Order 13231 of October 2001 on Critical Infrastructure Protection in the Information Age.
Other wake-up calls were less official but perhaps just as telling. I'm sure you all can provide your own lists.
They might include that incident in the Spring of 2001 when hackers broke into computer systems of CAL-ISO, California's primary electric power grid operator and apparently were not discovered for 17 days.
Those intruders apparently didn't get close to interfering with CAL-ISO's SCADA systems that control their portion of the grid, but that wasn't the case a year earlier in Australia when Vitek Boden exploited a wireless link to a SCADA system for the Maroochy Shire sewage control system and over four months dumped millions of gallons of sewage into Maroochy waterways.
Or let me read you this short interview excerpt. It was published last December in Mechanical Engineering by writer Alan Brown. Mr. Brown is quoting security consultant Paul Blomgren, who was hired to assesses SCADA vulnerabilities at a large southwestern power utility with about four million customers: "Our people drove to a remote substation. Without leaving their vehicle, they noticed a wireless network antenna. They plugged in their wireless LAN cards, fired up their notebook computers, and connected to the system within five minutes because it wasn't using passwords. "Within 10 minutes, they had mapped every piece of equipment in the facility. Within 15 minutes, they mapped every piece of equipment in the operational control network. Within 20 minutes, they were talking to the business network and had pulled off several business reports. They never even left the vehicle."
These incidents and many others demonstrate the vulnerability of far too many of our critical infrastructure control systems. And as we all know too well since September 11, 2001, there are people in the world who would be only too happy to use those vulnerabilities in the most harmful ways possible.
So what's to be done? There is, dare I say it, a vital role here for measurements and standards.
The root of the problem in critical infrastructure control systems is a large legacy of hardware and software that was designed with two thoughts in mind: performance and reliability.
Security, by and large, was not on the list. But now it must be.
We need to be able to retrofit the systems we have to provide the necessary level of security -- but without compromising performance and reliability.
And we need to design for the future. We need control hardware and software that has system protection and security built in from the beginning.
These are not easy tasks, and to make matters worse, they probably should have been done by, oh, say last week. New technologies are emerging, technologies that make ever increasing use of the Internet and common commercial operating systems with all the security issues that implies.
There is a critical need for new or revised standards to address control system security,
There is a critical need for design guidelines and standards to address the need for interoperability, redundancy, and security.
There is a critical need for control system testbeds to validate new approaches to security.
And there is the constant challenge of the high-tech standards process -- the need to reduce the time to develop consensus and arrive at useful standards balanced against the need to ensure that the process does not prematurely choke off new innovations and emerging technologies.
At NIST we know something about measurements, testbeds and standards, so I want to outline for you some of current work to meet these challenges.
One of our most significant efforts is our work with the American National Standards Institute on homeland security standards.
In July of last year the National Strategy for Homeland Security identified the need for standards to support homeland security and emergency preparedness. As a direct response to that, last February ANSI announced the formation of a Homeland Security Standards Panel.
The HSSP is co-chaired by NIST's Mary Saunders, Chief of our Standards Services Division, and Dan Bart, the Senior Vice President for Standards and Special Projects of the Telecommunications Industry Association.
The purpose of the panel is not itself to develop standards but rather to provide a common forum to facilitate cooperation between the public and private sectors on the many homeland security standards solutions that have been developed, are underway, have been proposed, or will be proposed by a vast array of standards-setting bodies.
The Panel, needless to stay, works very closely with the new Department of Homeland Security.
Participation on the HSSP is open to all interested organizations they need not be a member of ANSI. Over 150 organizations, including private-sector standards development organizations, government agencies, and private companies already have joined. An interim steering committee has been formed, and the first full meeting of the panel was held at NIST last June.
A set of priority standards areas has been identified, including emergency communications, risk assessment, training for first responders, cybersecurity and biometrics. Critical sectors include energy, water, power and telecommunications. The first HSSP workshop, on Biometrics, was also held at NIST just last month, and additional workshops are planned.
We also are applying our measurement skills to immediate problems in securing SCADA systems. There are hundreds of thousands of legacy systems in the field. Vendors are beginning to offer retrofit cryptographic modules that can be inserted in the SCADA communications link to increase security.
The problem, of course, is that many SCADA control loops have very strict timing requirements, particularly in power system applications. Vendors and their customers need to be assured that inserting the cryptographic modules in the loop will not degrade performance or introduce instabilities.
To help meet this need, this past spring the NIST Electronics and Electrical Engineering Laboratory, working with representatives from the gas and electric power industries, developed a prototype testbed to measure the timing parameters of SCADA encryption modules. The new testbed provides techniques to measure the latency and jitter of commercial encryption modules designed for both TCP/IP and RS 232 communications channels, and provides the information required by a proposed American Gas Association test method.
That same lab is also developing a database of standards and guideline publications that have a bearing on SCADA security -- either those that may be impacted by security issues or those that can be part of the solution. At last count the EEEL database listed 198 standards and 160 publications. As a measure of the task before us, by the way, probably more than half of those fall in that first category of things that could be affected -- or need to be changed -- to improve security.
Another joint effort that NIST has helped to form is the Process Control Security Requirements Forum. The PCSRF was inspired by the work done by NIST and the National Security Agency to develop the ISO 15408 Common Criteria for IT Security Evaluation.
The goal of PCSRF is to adopt the Common Criteria methodology to develop Protection Profiles for process control. The forum has produced a security capabilities profile that analyzes industrial control system architectures, including analysis of threats and vulnerabilities and specifies security capabilities that are required in a secure industrial process control system.
Ultimately the forum will produce Common Criteria compliant security profiles that can be used as the basis for specifying security requirements for process control systems.
The forum has about 300 registered members, including major systems vendors, industrial users, and federal agencies.
As a support to the forum's activities, NIST's Manufacturing Engineering Laboratory has developed two Process Control Security Testbeds. Based on typical SCADA equipment and controllers widely used in the process-control industry, the NIST testbeds provides an industrial setting in which to validate standards for process control security and to develop performance- and conformance test methods.
We have a model water distribution facility as a testbed for continuous process control systems, and -- just to keep to the water theme -- a model water bottling facility to test discrete manufacturing control systems.
We're working closely with EPRI, the International Institute of Electrical and Electronics Engineers, the International Electrotechnical Commission, and the Instrumentation Systems and Automation Society in these efforts.
An important and often overlooked segment of process controls are the building automation and control systems used for heating, ventilating and air conditioning, fire alarm systems, lighting control systems, access control, elevators, and the like.
These increasingly are being integrated with each other and with IT networks over wide area networks, and in the near future, buildings will exchange information directly with utility providers, service companies, and emergency response organizations. Without proper security, the potential for malicious havoc is awe-inspiring. Our Building and Fire research Laboratory has a three-pronged effort to protect integrated building systems and services.
NIST had earlier worked with ASHRAE, the American Society of Heating, Refrigeration and Air-Conditioning Engineers, to develop BACNet, a data communication protocol for Building Automation and Control Networks that is now a U.S. standard -- ASHRAE SSPC 135. We're now working with ASHRAE to extend the BACNet standard to provide secure information transfer between the control of integrated building systems and services.
We also have developed a Virtual Cybernetic Building Testbed, combining real commercial building control products with simulated building systems, to study the interactions of these systems and to develop appropriate security techniques. And for a real-world sanity check, we are working with the General Services Administration, the State of Iowa, and the Architect of the Capitol to implement security features in real-life, large-scale BACnet systems.
Of course the key challenge and the key opportunity in protecting critical infrastructure control systems is the increasing use in those systems of commercial information networks, internet protocol communications, and mass-market operating systems like Unix and Microsoft Windows.
The issues of IT security and control system security are becoming ever more enmeshed. As a result the NIST Information Technology Laboratory researchers are among our frontline troops in this effort.
ITL is helping to provide security for the IT infrastructure in areas ranging from the Advanced Encryption Standard, digital signatures, and public key infrastructure to biometrics and computer forensics.
Two particularly relevant activities that you may be aware of are the Cryptographic Module Validation Program and the National Information Assurance Partnership or NIAP.
The Cryptographic Module Validation Program was created by NIST and the Communications Security Establishment of the Government of Canada in 1995. It offers validation testing for cryptographic modules to ensure that cryptography is correctly and securely implemented. Private sector laboratories, accredited by NIST, perform the testing.
NIAP, a collaboration between NIST and the National Security Agency going back to 1997 promotes the development of technically sound security requirements for IT products and systems and appropriate metrics for evaluating them.
The healthcare sector and the telecommunications industry, among others, have developed security specifications in collaboration with NIAP, and the Process Control Security Requirements Forum that I mentioned earlier works under the aegis of NIAP.
If you're a systems vendor, you should know that to date, fourteen countries recognize results from the NIAP-sponsored IT security testing program as part of an international mutual recognition arrangement recently negotiated by the federal government. This reduces the costs of testing to U.S. companies and the barriers to their acceptance in foreign countries.
I haven't touched on every relevant NIST project by any means, but I hope I've managed to give you an idea of the breadth and depth of our commitment top critical infrastructure protection.
Before I close, I'd just like to get up on the soapbox for a minute.
The notion that SCADA systems are highly customized, highly technical, and therefore the guys in the black hats won't be able to figure them out is something Eric Byres of the British Columbia Institute of Technology calls the "Myth of Obscurity."
Forget it. SCADA documents have been recovered from al Qaeda safe houses in Afghanistan. An estimated 60 to 70 percent of all industrial security breaches are carried out by someone on the inside. There is no security through obscurity.
And there are steps that can de done right away that too often are overlooked.
- Creating at least a basic security policy, which should include shutting down or protecting backdoor modems.
- Changing the default passwords, for heaven's sake.
- Paying attention to the logs! Having a process that checks them for anomalous events.
- Getting the facilities IT people to talk to the operations people on a regular basis. Too many problems arise because the people who understand security and the people who understand operations don't understand each other.
- And making good use of the standards that are in place.
I began by referring to last summer's catastrophic power blackout in the Northeast. What you may not know is that attempts to reconstruct exactly what happened leading up to that failure have been hampered by the fact that the power companies and transmission companies apparently did not synchronize their event recording computers to the NIST national time standard.
They logged the same events, but at different times depending on which system created the log. I invite you to look at the official transcripts of the Midwest ISO control center communications for that afternoon. The top of each page states "Times noted in transcript are 7 minutes ahead of MISO Network System Time."
Seven minutes! Now I know my reaction is colored by the fact that I work for NIST, but seven minutes! That's not even a bad joke.
Accurate time stamps are invaluable for fault detection and event recording. And it's not as if the solution were difficult or costly. NIST has been working with the power industry on timing for at least 30 years, and has repeatedly pointed out solutions which are relatively inexpensive and relatively simple to implement.
One of the earliest NIST publications on precision timing for the electric power industry was "Industrial Time Service Study" in 1986. That study outlined the wide range of timing technology solutions available to the industry at that time. Since then, even more solutions at even lower prices have become available, largely through GPS and other satellite systems.
I can't begin to guess why they haven't been implemented.
So my charge to you all is to keep hammering away at the theme that infrastructure security and protection is important. It's important now. And we must all fight the temptation of complacency and work together to get the job done.
I know that's been said time and again, but let's face it, the French novelist Andre Gide nailed it when he wrote, "Everything that can be said has been said, but we have to say it again because no one was listening."