Today the Transportation Security Administration published their 30-day information collection request (ICR) renewal notice to authorize their continued collection of information to support their Sensitive Security Information (SSI) Threat Assessment program. As I noted in an earlier blog the threat assessment is conducted when a party in a civil proceeding in Federal Court seeks access to SSI information for preparation of that party’s case (including providing access for expert witnesses, consultants or court reporters as required).
Public comments are requested on this ICR. They must be submitted to the Office of Management and Budget (OMB) by November 15, 2010. Submissions may be emailed to oira_submission@omb.eop.gov or faxed to (202) 395-6974, attention to Desk Officer, DHS/TSA.
Friday, October 15, 2010
Emergency Response Planning – Communications
Earlier this week I proposed a new structure for Federally mandated emergency response planning for regulated industries like natural gas and hazardous material pipelines. I suggested that FEMA should be the agency that would be responsible for the coordination of emergency response planning between the regulated private entity and the potentially responding Federal, State and local response agencies. FEMA would have offices at county, State and regional levels to effect this coordination. I would like to take a look at how that might work, starting today with communications requirements.
Current Pipeline ERP Requirements
Currently 49 CFR 192.615 establishes the requirements for emergency response planning for natural gas and other hazardous material (except oil and fuel) pipeline operators. It specifically lists {§192.615(a)(3)} four types of incidents that must be addressed in the ERP:
The ERP required in this regulation outlines what the operator would do in the event of one of these incidents occurring. With the exception of the first and last incident, the only real response required from the pipeline operator is to shut down the flow through the pipeline. In the two remaining incidents leak detection and pipeline repair are the types of actions that most people would expect pipeline operators to include in their emergency response plan.
The problem is that things like emergency evacuations, fire fighting, emergency medical care and police services are not in the purview of the pipeline operator, but would form the largest part of any emergency response plan. The current regulation only requires the pipeline operator to provide a liaison to the agencies that would conduct that emergency response planning. There are no requirements for communications in the current emergency planning regulations.
Routine Communication Requirements
Under the proposed ERP program each pipeline operator would be required to provide details about the location of transmission pipelines, large volume distribution pipelines and above ground pipeline facilities to each affected 911 operation. The information would be provided in a format compatible with the geospatial information system (GIS) used in the 911 operation.
Pipeline operators would be required to provide all 911 facilities supporting areas that any of their pipeline traverses with a 24-hour emergency contact number. Pipeline operators with distribution pipelines would be required to provide each customer with the same 24-hour emergency contact number. For high-risk or high-consequence pipelines there would be a requirement for a dedicated line between the operator’s control room and each affected 911 facility.
Pipeline operators with transmission (as opposed to distribution) pipelines in populated areas would be required to notify all property owners within a reasonable distance of the pipeline of the location of that pipeline and the 24-hour emergency contact number for that operator’s control room. Notification would be by mail and would include a brochure that would describe emergency actions people should take in the event of a distribution pipeline leak, fire near the pipeline, or regionally likely natural catastrophe (earthquake, hurricane, tornado, etc).
The notification would include provisions for the property owner to register as an ‘at risk’ facility (hospital, nursing home, school, daycare, or person with restricted mobility) that might need special assistance in the event of a pipeline incident. The notification would also provide for registration of property owners in an emergency notification program that would allow for the operator to contact affected property owners by phone, email or text message in the event of an emergency.
Pipeline operators would be required to provide 24 hour emergency contact information to the County, State and any regional FEMA Emergency Response Coordinator (ERC) that could be affected by an incident associated with one of their pipelines. They would also be responsible for identifying an emergency response liaison officer that would be responsible for working with the affected FEMA ERCs. The operators would be required to provide the appropriate FEMA ERC with all of the information provided to local 911 facilities as well as a list of all self-identified at risk facilities in the area covered by that FEMA ERC.
Emergency Communication Requirements
In the event of any of the emergency situations listed in §192.615(a)(3) (and we would add loss of pipeline pressure and pipeline over-pressure incidents to the list), which ever party (pipeline operator or 911 service) received notification of the incident would immediately notify the other. The 911 service would be responsible for notifying the FEMA ERC. The emergency communications protocols established in the appropriate emergency response plan would be established.
Pipeline personnel designated as emergency response personnel would be required to communicate with the 911 dispatch by radio when they were activated as part of an ERP. Pipeline service personnel supporting emergency response personnel would be required to maintain communications with the pipeline control room (or designated pipeline emergency response center) and the supervisor of the pipeline emergency response personnel.
Once an incident command post was established, the pipeline operator would be required to provide a communications team to the command post that would allow for communications with all pipeline personnel working in the area and maintaining direct communications between the command post and the operator’s control room. The operator’s liaison and the county FEMA ERC would be expected to be at the command post to provide assistance and information to the incident commander. The FEMA ERC would establish communications with State, regional and national response facilities.
Communications Exercises
To ensure that the communications protocols established in this requirement actually work, there would be a requirement for routine communications exercises. Facilities with a required dedicated line to 911 services would be required to do (and document) a daily check of that line with a separate daily check initiated by the 911 service. All of the remaining pipeline control rooms would be required to document a weekly contact check with each of their supported 911 services.
Every vehicle owned by a pipeline operator that could be required to maintain communications with 911 dispatches in the event of a pipeline incident would be required to conduct a weekly communications check with each 911 dispatch to which it might be required to communicate. Whenever possible, that check should be made from within the covered area of the 911 service.
On a monthly basis the pipeline operator would verify communications with those people registered as wanting to be notified in the event of an emergency. The communication will be clearly identified as a test and would request an acknowledgement of receipt of the test message.
On an annual basis each covered pipeline operator would be required to report the communications exercises to the appropriate county FEMA ERC. In the event of any failure in communications with an 911 service or 911 dispatch, the report would include a description of the corrective action taken and the amount of time that the communication channel was known to be non-functional.
Other Regulated Industries
Many of the requirements for pipeline emergency response communications will be unique to that industry due to the nature of their distribution system and the continuous flow of hazardous materials through their lines. Other regulated industries would have similar requirements tailored to the nature and distribution of the risk associated with that facility.
Railroads for instance would be required to notify each FEMA ERC that had routes used to transport ‘rail security sensitive materials’ of the type hazardous materials included in that designation that were shipped on line as a designated route “posing the least overall safety and security risk” under the PHMSA rail routing rule. They would also be required to establish similar communications protocols with 911 services along those routes.
High-risk chemical facilities and RMP-covered facilities would be required to notify the affected FEMA ERCs and establish liaisons with the affected county FEMA ERC. Facilities would be required to provide mail notification to all property owners within the affected area described in the appropriate regulations. All covered facilities would be required to maintain communications with the local 911 service with Tier 1 and 2 CFATS facilities being required to maintain dedicated lines.
Detailed communications standards similar to those described above for the pipeline operations could be developed for any facility that the Federal government decided merited requiring the maintenance of an emergency response plan. The guiding principal would be that the private entity posing the risk would be required to notify the local FEMA ERC of the risk and establish an ERP liaison with the FEMA ERC. Provisions for emergency communications, and testing of those communications protocols, between the private entity and the local 911 service would be a necessary part of any ERP.
Current Pipeline ERP Requirements
Currently 49 CFR 192.615 establishes the requirements for emergency response planning for natural gas and other hazardous material (except oil and fuel) pipeline operators. It specifically lists {§192.615(a)(3)} four types of incidents that must be addressed in the ERP:
• Gas detected inside or near a building.Interestingly there is no requirement for pipeline operators to address a loss of pipeline pressure in their plan. This is the one indication that the operator would have in their system that there was a potentially dangerous leak. Nor is there a requirement to address an overpressure situation. Three of the remaining incidents listed would require that an outside agency contact the pipeline operator to initiate their response.
• Fire located near or directly involving a pipeline facility.
• Explosion occurring near or directly involving a pipeline facility.
• Natural disaster.
The ERP required in this regulation outlines what the operator would do in the event of one of these incidents occurring. With the exception of the first and last incident, the only real response required from the pipeline operator is to shut down the flow through the pipeline. In the two remaining incidents leak detection and pipeline repair are the types of actions that most people would expect pipeline operators to include in their emergency response plan.
The problem is that things like emergency evacuations, fire fighting, emergency medical care and police services are not in the purview of the pipeline operator, but would form the largest part of any emergency response plan. The current regulation only requires the pipeline operator to provide a liaison to the agencies that would conduct that emergency response planning. There are no requirements for communications in the current emergency planning regulations.
Routine Communication Requirements
Under the proposed ERP program each pipeline operator would be required to provide details about the location of transmission pipelines, large volume distribution pipelines and above ground pipeline facilities to each affected 911 operation. The information would be provided in a format compatible with the geospatial information system (GIS) used in the 911 operation.
Pipeline operators would be required to provide all 911 facilities supporting areas that any of their pipeline traverses with a 24-hour emergency contact number. Pipeline operators with distribution pipelines would be required to provide each customer with the same 24-hour emergency contact number. For high-risk or high-consequence pipelines there would be a requirement for a dedicated line between the operator’s control room and each affected 911 facility.
Pipeline operators with transmission (as opposed to distribution) pipelines in populated areas would be required to notify all property owners within a reasonable distance of the pipeline of the location of that pipeline and the 24-hour emergency contact number for that operator’s control room. Notification would be by mail and would include a brochure that would describe emergency actions people should take in the event of a distribution pipeline leak, fire near the pipeline, or regionally likely natural catastrophe (earthquake, hurricane, tornado, etc).
The notification would include provisions for the property owner to register as an ‘at risk’ facility (hospital, nursing home, school, daycare, or person with restricted mobility) that might need special assistance in the event of a pipeline incident. The notification would also provide for registration of property owners in an emergency notification program that would allow for the operator to contact affected property owners by phone, email or text message in the event of an emergency.
Pipeline operators would be required to provide 24 hour emergency contact information to the County, State and any regional FEMA Emergency Response Coordinator (ERC) that could be affected by an incident associated with one of their pipelines. They would also be responsible for identifying an emergency response liaison officer that would be responsible for working with the affected FEMA ERCs. The operators would be required to provide the appropriate FEMA ERC with all of the information provided to local 911 facilities as well as a list of all self-identified at risk facilities in the area covered by that FEMA ERC.
Emergency Communication Requirements
In the event of any of the emergency situations listed in §192.615(a)(3) (and we would add loss of pipeline pressure and pipeline over-pressure incidents to the list), which ever party (pipeline operator or 911 service) received notification of the incident would immediately notify the other. The 911 service would be responsible for notifying the FEMA ERC. The emergency communications protocols established in the appropriate emergency response plan would be established.
Pipeline personnel designated as emergency response personnel would be required to communicate with the 911 dispatch by radio when they were activated as part of an ERP. Pipeline service personnel supporting emergency response personnel would be required to maintain communications with the pipeline control room (or designated pipeline emergency response center) and the supervisor of the pipeline emergency response personnel.
Once an incident command post was established, the pipeline operator would be required to provide a communications team to the command post that would allow for communications with all pipeline personnel working in the area and maintaining direct communications between the command post and the operator’s control room. The operator’s liaison and the county FEMA ERC would be expected to be at the command post to provide assistance and information to the incident commander. The FEMA ERC would establish communications with State, regional and national response facilities.
Communications Exercises
To ensure that the communications protocols established in this requirement actually work, there would be a requirement for routine communications exercises. Facilities with a required dedicated line to 911 services would be required to do (and document) a daily check of that line with a separate daily check initiated by the 911 service. All of the remaining pipeline control rooms would be required to document a weekly contact check with each of their supported 911 services.
Every vehicle owned by a pipeline operator that could be required to maintain communications with 911 dispatches in the event of a pipeline incident would be required to conduct a weekly communications check with each 911 dispatch to which it might be required to communicate. Whenever possible, that check should be made from within the covered area of the 911 service.
On a monthly basis the pipeline operator would verify communications with those people registered as wanting to be notified in the event of an emergency. The communication will be clearly identified as a test and would request an acknowledgement of receipt of the test message.
On an annual basis each covered pipeline operator would be required to report the communications exercises to the appropriate county FEMA ERC. In the event of any failure in communications with an 911 service or 911 dispatch, the report would include a description of the corrective action taken and the amount of time that the communication channel was known to be non-functional.
Other Regulated Industries
Many of the requirements for pipeline emergency response communications will be unique to that industry due to the nature of their distribution system and the continuous flow of hazardous materials through their lines. Other regulated industries would have similar requirements tailored to the nature and distribution of the risk associated with that facility.
Railroads for instance would be required to notify each FEMA ERC that had routes used to transport ‘rail security sensitive materials’ of the type hazardous materials included in that designation that were shipped on line as a designated route “posing the least overall safety and security risk” under the PHMSA rail routing rule. They would also be required to establish similar communications protocols with 911 services along those routes.
High-risk chemical facilities and RMP-covered facilities would be required to notify the affected FEMA ERCs and establish liaisons with the affected county FEMA ERC. Facilities would be required to provide mail notification to all property owners within the affected area described in the appropriate regulations. All covered facilities would be required to maintain communications with the local 911 service with Tier 1 and 2 CFATS facilities being required to maintain dedicated lines.
Detailed communications standards similar to those described above for the pipeline operations could be developed for any facility that the Federal government decided merited requiring the maintenance of an emergency response plan. The guiding principal would be that the private entity posing the risk would be required to notify the local FEMA ERC of the risk and establish an ERP liaison with the FEMA ERC. Provisions for emergency communications, and testing of those communications protocols, between the private entity and the local 911 service would be a necessary part of any ERP.
Thursday, October 14, 2010
HR 6351 Introduced 09-29-10
Well, the last of the bills that I was watching for from the last days before the election recess was finally published on the GPO web site. The only one that was of any significance to the chemical security committee was HR 6351, the Strengthening Cybersecurity for Critical Infrastructure Act, introduced by Rep. Langevin (D, RI). This is one of the shorter cybersecurity bills introduced in this session, but it is one that will, if passed, have potential impact on the chemical security community.
There are two basic provisions of this bill. First it makes DHS the lead agency for cybersecurity matters related to critical infrastructure information systems, including those owned or operated by the Federal Government. Second it creates the National Office for Cyberspace in the Executive Office of the President and establishes a Director to head that office. This office would have authority to coordinate interagency cybersecurity matters related to critical infrastructure information systems.
The unique thing about this bill is that it specifically deals with industrial control systems. It defines ‘critical infrastructure information systems’ as “the electronic information and communications systems, software, and assets that control, protect, process, transmit, receive, program, or store information in any form, including data, voice, and video, relied upon by critical infrastructure, industrial control systems” {§2(1)}.
The specific authority given to the Secretary is rather vague, providing authority for the “creation, verification, and enforcement of measures with respect to the protection of critical information infrastructure” {§3(a)}. It provides the Secretary with the authority to conduct “such audits as are necessary to ensure that appropriate measures are taken to secure critical information infrastructure” {§3(a)(1)}, to issue subpoenas as “necessary to determine compliance with Federal regulatory requirements for securing critical information infrastructure” {§3(a)(2)}, and to require other sector specific Federal regulatory agencies to conduct compliance audits {§3(a)(3)}.
The bill was referred to the House Homeland Security and the House Oversight and Government Reform Committees and Langevin is not on either Committee. In the shortened and intense lame-duck session after the election this bill is unlikely to be acted upon by either Committee. In the unlikely event this makes it to the House floor and passes (passing would be likely), it would be most unlikely (almost impossible) to make it out of committee in time for consideration by the Senate before the final adjournment of the 111th Congress.
Rep. Langevin appears likely to be re-elected next month, so we might expect to see this legislation re-submitted in January.
There are two basic provisions of this bill. First it makes DHS the lead agency for cybersecurity matters related to critical infrastructure information systems, including those owned or operated by the Federal Government. Second it creates the National Office for Cyberspace in the Executive Office of the President and establishes a Director to head that office. This office would have authority to coordinate interagency cybersecurity matters related to critical infrastructure information systems.
The unique thing about this bill is that it specifically deals with industrial control systems. It defines ‘critical infrastructure information systems’ as “the electronic information and communications systems, software, and assets that control, protect, process, transmit, receive, program, or store information in any form, including data, voice, and video, relied upon by critical infrastructure, industrial control systems” {§2(1)}.
The specific authority given to the Secretary is rather vague, providing authority for the “creation, verification, and enforcement of measures with respect to the protection of critical information infrastructure” {§3(a)}. It provides the Secretary with the authority to conduct “such audits as are necessary to ensure that appropriate measures are taken to secure critical information infrastructure” {§3(a)(1)}, to issue subpoenas as “necessary to determine compliance with Federal regulatory requirements for securing critical information infrastructure” {§3(a)(2)}, and to require other sector specific Federal regulatory agencies to conduct compliance audits {§3(a)(3)}.
The bill was referred to the House Homeland Security and the House Oversight and Government Reform Committees and Langevin is not on either Committee. In the shortened and intense lame-duck session after the election this bill is unlikely to be acted upon by either Committee. In the unlikely event this makes it to the House floor and passes (passing would be likely), it would be most unlikely (almost impossible) to make it out of committee in time for consideration by the Senate before the final adjournment of the 111th Congress.
Rep. Langevin appears likely to be re-elected next month, so we might expect to see this legislation re-submitted in January.
Cyber Security Evaluation Tool
In yesterday’s blog about the 2010 Water Security Congress I noted that a presenter had mentioned an ICS security assessment program conducted by DHS ICS-CERT. Today I would like to take a brief look at this program offered by the Control Systems Security Program of DHS-CERT.
According to the available fact sheet the Cyber Security Evaluation Tool (CSET) is a computer based question and answer tool that “provides users with a systematic and repeatable approach for assessing the cyber security posture of their industrial control system networks”. The tool takes the facility supplied answers to questions about their control systems, facility IT systems and associated procedures and provides “a prioritized list of recommendations for improving the cybersecurity posture of an organization’s ICS or enterprise network”.
DHS provides facilities two different options for completing this voluntary program. Facilities can request a DVD copy of the program and conduct the evaluation on their own or they can conduct the evaluation using on-site ICS-CERT assistance. Organizations with a stronger computer support staff will probably want to use the DVD option.
The program helps facilities evaluate their cyber security program against a variety of established standards with the facility picking which standard best applies to their operation. Standards include:
According to the available fact sheet the Cyber Security Evaluation Tool (CSET) is a computer based question and answer tool that “provides users with a systematic and repeatable approach for assessing the cyber security posture of their industrial control system networks”. The tool takes the facility supplied answers to questions about their control systems, facility IT systems and associated procedures and provides “a prioritized list of recommendations for improving the cybersecurity posture of an organization’s ICS or enterprise network”.
DHS provides facilities two different options for completing this voluntary program. Facilities can request a DVD copy of the program and conduct the evaluation on their own or they can conduct the evaluation using on-site ICS-CERT assistance. Organizations with a stronger computer support staff will probably want to use the DVD option.
The program helps facilities evaluate their cyber security program against a variety of established standards with the facility picking which standard best applies to their operation. Standards include:
• National Institute of Standards and Technology (NIST),Will this help facilities with their CFATS cyber security requirements? Since there are no specifically delineated requirements for a cyber security system under CFATS, that is a hard question to answer. I think that a tool like this will help facilities identify current security issues and provide suggestions on how to deal with them. Having used this system to identify and correct system shortcomings certainly would provide a good basis for justifying a facility’s program to inspectors.
• North American Electric Reliability Corporation (NERC),
• International Organization for Standardization (ISO), and
• U.S. Department of Defense (DoD).
Wednesday, October 13, 2010
Water Security Congress
On Monday, the ASDWA Security Notes Blog posted information on last month’s 2010 Water Security Congress conducted by the American Water Works Association (AWWA). While most of this meeting was focused on security issues that did not specifically deal with chemical issues at water facilities, there were a couple of presentations that might be of interest to the general chemical security community. For readers from the water community may want to look at the general AWWA page on the meeting.
Water ISAC
There was an interesting presentation made by Aaron Levy discussing the Water Sector Information Sharing and Analysis Center (WaterISAC) that he heads. This is an organization run by the Water Sector Coordinating Council, part of the National Infrastructure Protection Program. It provides an information sharing environment for all sorts of water sector protection activities including a secure portal for sharing intelligence information. I have not seen a comparable organization coming out of the Chemical Sector Coordinating Council.
One of the interesting issues raised in Levy’s presentation is the problem of financially-motivated vandalism. Water facilities have a security issue that is much more prevalent than terrorist attacks, the theft of metal (pipe and wire) from their extended facilities; a problem aggravated by the poor economy.
Stuxnet was briefly addressed in the presentation both as a threat to water system control systems, but also as a threat to the electrical power supply critical to the operations of these systems. This is an issue that should also be of concern to chemical facility operators.
I want to take an opportunity to commend Mr. Levy for the format of his presentation file. Most presenters provide copies of the presentation slides for these type files. The WaterISAC presentation not only includes the slides, but the notes that he used in his presentation. This provides a lot more information and provides more of a flavor of the actual presentation. Still not as good as a video file, but Levy is to be commended for taking this innovative step.
Utility Security
This presentation by John W. McLaughlin, from Jacobs-JJG (engineering firm), looks at the switch from security being a counter-terrorism matter to a more inclusive ‘all-hazards’ approach. He notes that many utilities do not see themselves as a terrorist target and may see counter-terrorism measures as a diversion of funds that could be better spent elsewhere.
He notes the enlarged focus of security at the national level is now looking beyond just the possibility of terrorist attacks and is addressing all sorts of security issues. A major new focus at the national level is ‘resiliency’, the ability to get the water system up and running after an attack, vandalism, systems failures, or natural disaster.
This discussion about the need for resiliency is certainly an increasingly important focus at DHS. Prevention of production disruptions from all causes is important, but resilient facilities recognize that all disruptions cannot be prevented. I’ve noted for some time in this blog that recognition of the practical inability to prevent all terrorist attacks requires planning for emergency response to deal with resulting chemical releases, fires and explosions. Resiliency looks even beyond that, at what happens after the emergency response is done.
While chemical facility management certainly has an interest in getting their facility back on line, they don’t have the same urgency in this matter that public utilities have. An off-line chemical facility will not typically cause life changing problems for all of their neighbors and customers. A shutdown water plant, on the other hand, adversely affects the entire community until it gets back on-line.
Water and CFATS
Bryon O. Elwell, from ABS Consulting, provided an overview of both the current CFATS regulations and the pending legislation in Congress that might affect security operations at water and waste-water treatment facilities. The information in the slides was well put together, especially the summary data on S 3598, the Secure Water Facilities Act.
Elwell presented some facts that I haven’t seen pulled together before. He noted (slide 18) that there were 1,200 waste water treatment plants that had more than 2,500 lbs (CFATS SQT for Chlorine) of Chlorine gas on-site and 1,700 water treatment plants that were covered by EPA’s risk management plan rules (and presumably would be covered by CFATS rules). He also provided (slides 19 and 20) a more complete listing of water treatment chemicals that are DHS chemicals of interest (COI) than I have seen to date.
Water Cyber Security
I was pleased to see that there were three separate presentations on control system cyber security (CSCS) matters; all of them should be reviewed by any organization with an automated industrial control system. The first was by Candace Chan-Sands, from EMA, Inc. who’s presentation looked at the DHS ICS-CERT Cyber Security Evaluation Tool (CSET). This is a service provided by DHS ICS-CERT to evaluate the security environment for a facility’s control system. Some how I have overlooked this service listed on the ICS-CERT web site; I’ll cover this in more detail in a separate blog post.
The second presentation was by W. Michael Sutton, an engineer with Malcolm Pirnie Inc. He looked at both the development of the ISA-99 cyber security standards under development. He pointed the audience at ANSI/ISA-99.02.01-2009, the Security for Industrial Automation and Control Systems: Establishing an Industrial Automation and Control Systems Security Program, published in 2009. He did not provide a link to the ANSI site for obtaining the document; here it is. He also provided a brief look at control system design and technologies available to help secure cyber assets.
The third cyber-security presentation was made by Jeff Mills, from Coalfire, an IT Audit and Compliance Management firm. This is a pretty good, if high-level, review of the control system security problem, but it does not address the peculiar ICS issues with implementing many IT security measures. There is, however, a very good description (slide 25) of general control system security measures that would apply to any facility using ICS systems.
Posting Presentations
I always appreciate it when organizations like the AWWA post their presentations on-line. I don’t have the travel budget to get to these meetings and there is a wealth of good information presented at meetings like this. Most people in the public water supply industry have similar budget constraints making the posting of these presentations a valuable service to the industry. I would like to make my standard presentation recommendation to AWWA; next year, how about providing videos of the presentations on-line.
Personal Complaint Warning: I am always upset when an organization posts .PDF documents with excessive security settings. Why would anyone be concerned about someone copying and pasting from the document. It makes the job of reviewers like myself that much more difficult. This is especially true when the document includes URL’s, its bad enough that the listed URL’s were not live links, but then they were protected against copying. What a PAIN! Please re-think your document security policy.
Water ISAC
There was an interesting presentation made by Aaron Levy discussing the Water Sector Information Sharing and Analysis Center (WaterISAC) that he heads. This is an organization run by the Water Sector Coordinating Council, part of the National Infrastructure Protection Program. It provides an information sharing environment for all sorts of water sector protection activities including a secure portal for sharing intelligence information. I have not seen a comparable organization coming out of the Chemical Sector Coordinating Council.
One of the interesting issues raised in Levy’s presentation is the problem of financially-motivated vandalism. Water facilities have a security issue that is much more prevalent than terrorist attacks, the theft of metal (pipe and wire) from their extended facilities; a problem aggravated by the poor economy.
Stuxnet was briefly addressed in the presentation both as a threat to water system control systems, but also as a threat to the electrical power supply critical to the operations of these systems. This is an issue that should also be of concern to chemical facility operators.
I want to take an opportunity to commend Mr. Levy for the format of his presentation file. Most presenters provide copies of the presentation slides for these type files. The WaterISAC presentation not only includes the slides, but the notes that he used in his presentation. This provides a lot more information and provides more of a flavor of the actual presentation. Still not as good as a video file, but Levy is to be commended for taking this innovative step.
Utility Security
This presentation by John W. McLaughlin, from Jacobs-JJG (engineering firm), looks at the switch from security being a counter-terrorism matter to a more inclusive ‘all-hazards’ approach. He notes that many utilities do not see themselves as a terrorist target and may see counter-terrorism measures as a diversion of funds that could be better spent elsewhere.
He notes the enlarged focus of security at the national level is now looking beyond just the possibility of terrorist attacks and is addressing all sorts of security issues. A major new focus at the national level is ‘resiliency’, the ability to get the water system up and running after an attack, vandalism, systems failures, or natural disaster.
This discussion about the need for resiliency is certainly an increasingly important focus at DHS. Prevention of production disruptions from all causes is important, but resilient facilities recognize that all disruptions cannot be prevented. I’ve noted for some time in this blog that recognition of the practical inability to prevent all terrorist attacks requires planning for emergency response to deal with resulting chemical releases, fires and explosions. Resiliency looks even beyond that, at what happens after the emergency response is done.
While chemical facility management certainly has an interest in getting their facility back on line, they don’t have the same urgency in this matter that public utilities have. An off-line chemical facility will not typically cause life changing problems for all of their neighbors and customers. A shutdown water plant, on the other hand, adversely affects the entire community until it gets back on-line.
Water and CFATS
Bryon O. Elwell, from ABS Consulting, provided an overview of both the current CFATS regulations and the pending legislation in Congress that might affect security operations at water and waste-water treatment facilities. The information in the slides was well put together, especially the summary data on S 3598, the Secure Water Facilities Act.
Elwell presented some facts that I haven’t seen pulled together before. He noted (slide 18) that there were 1,200 waste water treatment plants that had more than 2,500 lbs (CFATS SQT for Chlorine) of Chlorine gas on-site and 1,700 water treatment plants that were covered by EPA’s risk management plan rules (and presumably would be covered by CFATS rules). He also provided (slides 19 and 20) a more complete listing of water treatment chemicals that are DHS chemicals of interest (COI) than I have seen to date.
Water Cyber Security
I was pleased to see that there were three separate presentations on control system cyber security (CSCS) matters; all of them should be reviewed by any organization with an automated industrial control system. The first was by Candace Chan-Sands, from EMA, Inc. who’s presentation looked at the DHS ICS-CERT Cyber Security Evaluation Tool (CSET). This is a service provided by DHS ICS-CERT to evaluate the security environment for a facility’s control system. Some how I have overlooked this service listed on the ICS-CERT web site; I’ll cover this in more detail in a separate blog post.
The second presentation was by W. Michael Sutton, an engineer with Malcolm Pirnie Inc. He looked at both the development of the ISA-99 cyber security standards under development. He pointed the audience at ANSI/ISA-99.02.01-2009, the Security for Industrial Automation and Control Systems: Establishing an Industrial Automation and Control Systems Security Program, published in 2009. He did not provide a link to the ANSI site for obtaining the document; here it is. He also provided a brief look at control system design and technologies available to help secure cyber assets.
The third cyber-security presentation was made by Jeff Mills, from Coalfire, an IT Audit and Compliance Management firm. This is a pretty good, if high-level, review of the control system security problem, but it does not address the peculiar ICS issues with implementing many IT security measures. There is, however, a very good description (slide 25) of general control system security measures that would apply to any facility using ICS systems.
Posting Presentations
I always appreciate it when organizations like the AWWA post their presentations on-line. I don’t have the travel budget to get to these meetings and there is a wealth of good information presented at meetings like this. Most people in the public water supply industry have similar budget constraints making the posting of these presentations a valuable service to the industry. I would like to make my standard presentation recommendation to AWWA; next year, how about providing videos of the presentations on-line.
Personal Complaint Warning: I am always upset when an organization posts .PDF documents with excessive security settings. Why would anyone be concerned about someone copying and pasting from the document. It makes the job of reviewers like myself that much more difficult. This is especially true when the document includes URL’s, its bad enough that the listed URL’s were not live links, but then they were protected against copying. What a PAIN! Please re-think your document security policy.
Tuesday, October 12, 2010
S 3866 Introduced 9-29-10
As Congress prepared to depart Washington to start their lengthy campaign recess a large number of bills were introduced in both houses. Slowly but surely copies of these bills are making there way to the Government Printing Office (GPO) so we can see what these bills actually contain. There are five bills (including this one) that I think may be of interest to the chemical security community. As they are published I will report on them.
On September 29th Senators Carper (D, DE) and Brown (R, MA) introduced S 3866, the Aviation Security Innovation & Reform Act of 2010. It aims to standardize training for the Transportation Security Officers (TSO) working for TSA and to establish an Office of Behavior Analysis in the Transportation Security Administration. Neither of these objectives appears to have any direct impact on issues of concern to the chemical security community (except in our role as travelers).
The only reason that I am addressing this here is that this legislation would tend to perpetuate the failure to distinguish between the responsibilities of TSOs working as screeners at airports and those working on Visible Intermodal Prevention and Response (VIPR) teams and those working enforcement of freight railroad security measures.
For example §2 of the bill would update 49 USC 44935(g)(1) to require the DHS Assistant Secretary in charge of TSA to develop and implement a training program that “to the maximum extent practicable, ensures that the training received by Transportation Security Officers [emphasis added] is standardized”. It then goes on to specify position specific tasks that would require special training including: “up-to-date technical training in document fraud identification” {§44935(g)(2)(d)} and equipment-specific training {§44935(g)(3)}. No mention is made of surface security tasks.
Congress and TSA must acknowledge the inherent difference between the jobs of airport screening, VIPR teams, freight security (both truck and rail), and pipeline security inspectors as well as the relative importance of the much smaller surface security workforce. Until they do so surface transportation security will continue to be short changed. I hope that it won’t take an attack on a chlorine railcar or a gasoline tank wagon to get Congress and DHS to recognize that surface transportation security is just as important as securing air transportation.
On September 29th Senators Carper (D, DE) and Brown (R, MA) introduced S 3866, the Aviation Security Innovation & Reform Act of 2010. It aims to standardize training for the Transportation Security Officers (TSO) working for TSA and to establish an Office of Behavior Analysis in the Transportation Security Administration. Neither of these objectives appears to have any direct impact on issues of concern to the chemical security community (except in our role as travelers).
The only reason that I am addressing this here is that this legislation would tend to perpetuate the failure to distinguish between the responsibilities of TSOs working as screeners at airports and those working on Visible Intermodal Prevention and Response (VIPR) teams and those working enforcement of freight railroad security measures.
For example §2 of the bill would update 49 USC 44935(g)(1) to require the DHS Assistant Secretary in charge of TSA to develop and implement a training program that “to the maximum extent practicable, ensures that the training received by Transportation Security Officers [emphasis added] is standardized”. It then goes on to specify position specific tasks that would require special training including: “up-to-date technical training in document fraud identification” {§44935(g)(2)(d)} and equipment-specific training {§44935(g)(3)}. No mention is made of surface security tasks.
Congress and TSA must acknowledge the inherent difference between the jobs of airport screening, VIPR teams, freight security (both truck and rail), and pipeline security inspectors as well as the relative importance of the much smaller surface security workforce. Until they do so surface transportation security will continue to be short changed. I hope that it won’t take an attack on a chlorine railcar or a gasoline tank wagon to get Congress and DHS to recognize that surface transportation security is just as important as securing air transportation.
Monday, October 11, 2010
Non-Iranian Stuxnet Targets
Much has been made of the targeting of the Stuxnet worm. The way the worm was constructed it appears by all accounts to target a specific installation with specific Siemens software and a particular hardware configuration. If you are not operating an Iranian uranium processing facility, the popular wisdom is that Stuxnet is nothing more than a minor inconvenience.
There are problems with that assessment. If this was a cyber attack by a nation-state on the weapons program of another nation-state it really seems to be a very poorly directed attack. A covert cyber attack needs to remain covert. If it is discovered, the process upsets can easily be corrected, the computer systems purged of the weaponized worm and the weapons program will proceed with tighter attention to cyber security issues. A publicly identified cyber weapon will delay, but not stop the weapons program; too much time and effort for such a minor effect.
The prolific propagation of Stuxnet is a result of a deliberate design process. The weapon was designed to move through computer systems and networks through a wide variety mechanisms ranging from human intervention (USB drive) to a unique peer-to-peer network updating system. More than anything else it seems to search for computers running either of two Siemens’ software systems used to control a wide variety of industrial control systems.
Everyone has noticed that there appears to be only one specific active target for the worm. If the weapon does not detect a specific programmable logic controller (PLC) configuration, it sits idle; almost as if it is waiting for further instructions. And we know that when ever it contacts (or is contacted) by another infected computer, the one with the older version of Stuxnet gets updated with the newer version’s software instructions.
What if this isn’t a cyber weapon being used by a nation-state to destroy a weapons program? What if this isn’t an incredibly sophisticated yet inept weapon? What if it is something entirely different?
Criminal Tool not Cyber Weapon
Let’s suppose that the most effective portion of the construction of this malware was actually the intended purpose; spread the infection through as many Siemens’ based ICS systems as possible. The attack payload, the instructions ‘targeted’ at Iranian processing facilities, would just be a red herring thrown across the trail. It successfully makes everyone jump to the conclusion that either (or perhaps both) the Israelis or the Americans were behind the ‘sophisticated’ attack so no one is actually looking for the real perpetrators. Even the Americans and the Israelis disbelieve the other’s protestations of innocence. No one seems to be seriously interested in tracking down the perpetrators.
After the initial furor dies down, and the Stuxnet is dissected and analyzed until no one is really interested any more, then a series of new versions could be released at various locations around the world. The new versions would have a slightly different payload and a new C&C address to report to. The new payload would be a set of ‘document and report’ instructions that would collect detailed information about the PLCs connected to the system.
The Stuxnet control organization would then have the necessary information to target attacks against each of the reporting control systems. The programmers would once again modify the payload, this time modifying the instructions for a number of different PLCs at the facility. One of the controllers would be programmed to visibly ‘misbehave’ at a particular time. Shortly there after the facility management would receive a message threatening to disrupt other manufacturing operations unless a fee were paid. The remaining controllers programs would initiate at separate times unless a special stop signal were received. If Stuxnet were ‘cleaned’ from the system then the process upsets would be set to trigger on specific, yet normal, control system commands to the PLC.
How many facilities would pay the protection fee? How many could afford not to? To properly clean this type system, each PLC would have to be taken off-line, erased and re-programmed from a clean system. For most systems this could not be done piece meal, the entire facility would have to be shut down. The reprogramming would also require re-tuning many of the processes a time and resource consuming process.
If the fee were low enough it would certainly look to be a preferable alternative to many managers. After a few facilities inadequately cleaned their control system and had even worse problems after the shutdown, that news would encourage other managers to up their definition of a reasonable fee.
Which is it?
I am certainly not stating that this is the true nature of the Stuxnet worm. I am neither proficient nor connected enough to be able to make that determination. It does seem to me from reading the reports from Symantec and Langner that the obvious answer is just a little off from what we would really expect to see if this were a cyber-warfare tool. I may be expecting too much from a weapon design team, but there are too many unexplained inconsistencies to suit me.
It is time that we considered alternative explanations and tried to determine the consequences of those alternatives. And someone needs to be thinking now about how to deal with those potential consequences. Stuxnet may have been designed as a cyber weapon. If so it was sloppy and left lying around for anyone to pick-up and use.
Anyone that thinks that we won’t be seeing Stuxnet variants targeted at non-Iranian processing facilities is living in a dream world; they need to get ready for the nightmare. The new targets will either be the real targets or just targets of opportunity. It won’t make much difference to the target.
There are problems with that assessment. If this was a cyber attack by a nation-state on the weapons program of another nation-state it really seems to be a very poorly directed attack. A covert cyber attack needs to remain covert. If it is discovered, the process upsets can easily be corrected, the computer systems purged of the weaponized worm and the weapons program will proceed with tighter attention to cyber security issues. A publicly identified cyber weapon will delay, but not stop the weapons program; too much time and effort for such a minor effect.
The prolific propagation of Stuxnet is a result of a deliberate design process. The weapon was designed to move through computer systems and networks through a wide variety mechanisms ranging from human intervention (USB drive) to a unique peer-to-peer network updating system. More than anything else it seems to search for computers running either of two Siemens’ software systems used to control a wide variety of industrial control systems.
Everyone has noticed that there appears to be only one specific active target for the worm. If the weapon does not detect a specific programmable logic controller (PLC) configuration, it sits idle; almost as if it is waiting for further instructions. And we know that when ever it contacts (or is contacted) by another infected computer, the one with the older version of Stuxnet gets updated with the newer version’s software instructions.
What if this isn’t a cyber weapon being used by a nation-state to destroy a weapons program? What if this isn’t an incredibly sophisticated yet inept weapon? What if it is something entirely different?
Criminal Tool not Cyber Weapon
Let’s suppose that the most effective portion of the construction of this malware was actually the intended purpose; spread the infection through as many Siemens’ based ICS systems as possible. The attack payload, the instructions ‘targeted’ at Iranian processing facilities, would just be a red herring thrown across the trail. It successfully makes everyone jump to the conclusion that either (or perhaps both) the Israelis or the Americans were behind the ‘sophisticated’ attack so no one is actually looking for the real perpetrators. Even the Americans and the Israelis disbelieve the other’s protestations of innocence. No one seems to be seriously interested in tracking down the perpetrators.
After the initial furor dies down, and the Stuxnet is dissected and analyzed until no one is really interested any more, then a series of new versions could be released at various locations around the world. The new versions would have a slightly different payload and a new C&C address to report to. The new payload would be a set of ‘document and report’ instructions that would collect detailed information about the PLCs connected to the system.
The Stuxnet control organization would then have the necessary information to target attacks against each of the reporting control systems. The programmers would once again modify the payload, this time modifying the instructions for a number of different PLCs at the facility. One of the controllers would be programmed to visibly ‘misbehave’ at a particular time. Shortly there after the facility management would receive a message threatening to disrupt other manufacturing operations unless a fee were paid. The remaining controllers programs would initiate at separate times unless a special stop signal were received. If Stuxnet were ‘cleaned’ from the system then the process upsets would be set to trigger on specific, yet normal, control system commands to the PLC.
How many facilities would pay the protection fee? How many could afford not to? To properly clean this type system, each PLC would have to be taken off-line, erased and re-programmed from a clean system. For most systems this could not be done piece meal, the entire facility would have to be shut down. The reprogramming would also require re-tuning many of the processes a time and resource consuming process.
If the fee were low enough it would certainly look to be a preferable alternative to many managers. After a few facilities inadequately cleaned their control system and had even worse problems after the shutdown, that news would encourage other managers to up their definition of a reasonable fee.
Which is it?
I am certainly not stating that this is the true nature of the Stuxnet worm. I am neither proficient nor connected enough to be able to make that determination. It does seem to me from reading the reports from Symantec and Langner that the obvious answer is just a little off from what we would really expect to see if this were a cyber-warfare tool. I may be expecting too much from a weapon design team, but there are too many unexplained inconsistencies to suit me.
It is time that we considered alternative explanations and tried to determine the consequences of those alternatives. And someone needs to be thinking now about how to deal with those potential consequences. Stuxnet may have been designed as a cyber weapon. If so it was sloppy and left lying around for anyone to pick-up and use.
Anyone that thinks that we won’t be seeing Stuxnet variants targeted at non-Iranian processing facilities is living in a dream world; they need to get ready for the nightmare. The new targets will either be the real targets or just targets of opportunity. It won’t make much difference to the target.
Subscribe to:
Posts (Atom)
Posts
