FRA Safety Advisory – Train Accidents and Pipelines

Today the Federal Railroad Administration (FRA) published a safety advisory in the Federal Register (78 FR 13747) that is based upon an accident investigation recommendation made by the National Transportation Safety Board.

NTSB Recommendation

The NTSB recommendation (R-12-04; NOTE: this link takes you to the NTSB search page; NTSB does not use permanent links to its recommendations) was a result of their investigation of the June 19^th, 2009 derailment of a CN freight train in Cherry Valley, IL. According to an NTSB letter report (pg 3) on the derailment, one of the results of that accident was that a 12” natural gas pipeline was damaged, even though it was buried much deeper than required by current regulations.

The pipeline did not leak after the accident, but the damage was such that it could have been expected to leak if it had not been examined and repaired immediately after the accident was cleared. As a result, the NTSB made the following two recommendations:

• That PHMSA inform pipeline operators about the circumstances of the accident and advise them of the need to inspect pipeline facilities after notification of accidents occurring in railroad rights-of-way.

• That the FRA inform railroads about the circumstances of the accident and advise them of the need to immediately notify pipeline operators of accidents occurring in railroad rights-of-way and ensure that pipeline inspections have been accomplished prior to resumption of service.

PHMSA made their notification in an Advisory Bulletin published in the Federal Register (77 FR 45417-45418) on July 31^st, 2012.

FRA Safety Bulletin

Today’s FRA Safety Bulletin states:

“Like PHMSA, FRA encourages railroads to use the 811 ``Call Before You Dig'' program to notify pipeline operators of rail accidents occurring in railroad rights-of-way where pipelines are present and to ensure that pipeline inspections are accomplished prior to resumption of service. By calling 811, pipeline owners and operators will be notified of potential problems the accident may have caused to the pipeline, and enable the pipeline owners and operators to work with the involved railroads to prevent further injury to individuals cleaning up the accident site.”

Emergency Response Personnel

Local emergency response officials are probably (hopefully) more knowledgeable of major pipelines that run through their area than are the railroads that run trains through the area. Incident Commanders at all derailments should also use the 811 “Call Before You Dig” line to ensure that they are aware of all major (and minor) pipelines in the area that could have been damaged by the train cars.

The fact that this accident damaged a pipeline that was buried under 11 feet of dirt and enclosed in an 16” casing shows how much damage to underground utilities can be sustained in an incident like this. Emergency response personnel need to be cognizant of this potential danger (as if derailments weren’t dangerous enough already).

HR 307 Amended and Passed in Senate

Yesterday the Senate amended and adopted HR 307, the Pandemic and All-Hazards Preparedness Reauthorization Act of 2013. The measure passed by unanimous consent without discussion.

The amendment adopted was the substitute language adopted in Committee. Now that we can see the version passed by the Senate, it is clear that this is the same language that was proposed by Sen. Burr (R,NC) in S 242.

The bill will now go back to the House for reconsideration or request for conference. The differences between the two bills are very minor; the House may just adopt the Senate amendments. I do expect fairly quick action on this either way.

Bills Introduced – 2-27-13 (Revised)

There were four more bills yesterday that would prevent/modify the sequester of Federal funding. No way of telling yet what specific affect either bill would have on cybersecurity or chemical safety/security spending. The four bills are:

H.R.849 Latest Title: To amend the Balanced Budget and Emergency Deficit Control Act of 1985 to eliminate the section 251A sequestrations and to reduce the security and nonsecurity discretionary spending limits by $320 billion from fiscal year 2014 through fiscal year 2021, and to suspend the statutory limit on the public debt until February 1, 2017. Sponsor: Rep Smith, Adam (D,WA)

H.R.857 Latest Title: To amend section 251A of the Balanced Budget and Emergency Deficit Control Act of 1985 to eliminate the Department of Defense sequestration for fiscal years 2013 and 2014 and sequester such eliminated sums over a period of fiscal years 2015 through 2021. Sponsor: Rep Cook, Paul (R,CA)

S.16 Latest Title: A bill to provide for a sequester replacement. Sponsor: Sen Inhofe, James M. (R,OK)

S.18 Latest Title: A bill to amend the Balanced Budget and Emergency Deficit Control Act of 1985 to replace the sequester established by the Budget Control Act of 2011. Sponsor: Sen Ayotte, Kelly (R,NH)

Neither of the House bills, nor the Ayotte bill has much chance of actually being considered. Legislation on spending that does get floor consideration typically comes from the Chair (or sometimes Ranking Member) of the Appropriations Committees. The Inhofe bill will be considered today in the Senate as part of the deal that I mentioned yesterday (though I called it the McConnell bill there).

(NOTE: This post was revised because I found the Senate bills after the Congressional Record became available this morning. I initially check bills sequentially first thing in the morning through Thomas.gov as they become available quicker there. The two Senate bills were introduced out of sequence.)

Bills Introduced – 2-27-13

There were two more bills yesterday that would prevent/modify the sequester of Federal funding. No way of telling yet what specific affect either bill would have on cybersecurity or chemical safety/security spending. The two bills are:

H.R.849 Latest Title: To amend the Balanced Budget and Emergency Deficit Control Act of 1985 to eliminate the section 251A sequestrations and to reduce the security and nonsecurity discretionary spending limits by $320 billion from fiscal year 2014 through fiscal year 2021, and to suspend the statutory limit on the public debt until February 1, 2017.
Sponsor: Rep Smith, Adam (D,WA)

H.R.857 Latest Title: To amend section 251A of the Balanced Budget and Emergency Deficit Control Act of 1985 to eliminate the Department of Defense sequestration for fiscal years 2013 and 2014 and sequester such eliminated sums over a period of fiscal years 2015 through 2021.
Sponsor: Rep Cook, Paul (R,CA)

Neither of these bills has much chance of actually being considered. Legislation on spending that does get floor consideration typically comes from the Chair (or sometimes Ranking Member) of the Appropriations Committees.

TSA Publishes 30-day ICR Renewal Notice for HME-STA

Today the TSA published a 30-day information collection request (ICR) renewal notice in the Federal Register (78 FR 13367-13368) to support the collection of information from personnel applying for a Hazardous Materials Endorsement to their State Commercial Driver’s License. The TSA uses the collected information to conduct a Security Threat Assessment (STA) required under 49 USC 5103a.

As I noted in my blog post concerning the 60-day notice for this ICR renewal, TSA is forecasting a continuing decline in the number of applications for new and renewed HME. Other than the change in burden hours and cost associated with this declining enrollment, there are no changes being made from the currently approved ICR.

Public comments on this ICR renewal may be submitted to OMB via email (oira_submission@omb.eop.gov). Such comments should be received by March 29^th, 2013.

Bills Introduced – 2-26-13

Yesterday Sen. Mikulski (D,MD), the Chair of the Senate Appropriations Committee, introduced S 388, a “bill to appropriately limit sequestration, to eliminate tax loopholes, and for other purposes”. This bill and Sen. McConnell’s (R,KY) counter bill (that is to be introduced today) will be considered on Thursday. No details are available yet on either bill so it is too early to tell what effect, if any, these bills will have on cybersecurity, chemical security or safety spending.

Given the fact that the sequester is due to go into effect on Friday, this is kind of last minute; but we are getting used to that. If consideration of this bill (one of the two) carries over until Friday, Saturday or even Monday, I’m pretty sure that there will be no practical effects felt by the technical sequestration of funds. It seems that these budget ‘deadlines’ are more political theater than reality.

NPPD Publishes 60-day ICR Notice for TRIPwire Program

The National Protection and Programs Directorate (NPPD) of DHS published a 60-day information collection request notice in today’s Federal Register (78 FR 13366-13367). This new ICR would support the existing user registration for the Technical Resource for Incident

Prevention (TRIPwire) program operated out of the Office of Bombing Prevention. According to this notice TRIPwire “is OBP's online, collaborative, information-sharing network for bomb squad, law enforcement, and other emergency services personnel to learn about current terrorist improvised explosive device (IED) tactics, techniques, and procedures”.

This is one of those long-standing (since at least 2009 that I know of) programs that has collected voluntary registration information without an OMB ICR program number. Agencies collecting information from State and local governments and the private sector are required to get OMB approval of those information collections to ensure that there is a legitimate governmental need for the information and that the collected information is appropriately used and protected. The Obama Administration has been very proactive in bringing these voluntary programs into coverage of the ICR program, so it is somewhat surprising that this particular program is just now receiving this attention.

The OBP expects that there will be an annual participation in this registration collection by about 3,500 participants and that the average time spent in providing the information will be 10 minutes. This annual time burden of 583 estimated hours will have a total cost burden $11,803 on the information providers.

Public comments on this ICR may be provided via the Federal eRulemaking Portal (www.Regulations.gov; Docket # DHS-2012-0022). Comments need to be submitted by April, 29^th, 2013.

TSA Publishes 60-day ICR Renewal Notice for Pipeline CSR

Yesterday the Transportation Security Administration (TSA) published a 60-day information collection request (ICR) renewal notice in the Federal Register (78 FR 13075-13076). This ICR supports the TSA Pipeline Corporate Security Review Program.

Pipeline CSR Program

According to yesterday’s notice the Pipeline Corporate Security Review Program is designed to allow the TSA to:

• Develop first-hand knowledge of a pipeline operator's corporate security policies and procedures;

• Establish and maintain working relationships with key pipeline security personnel; and

• Identify and share smart security practices observed at individual facilities to help enhance and improve the security of the pipeline industry.

The TSA inspector conducting the review uses a Pipeline Corporate Security Review form (TSA Form 1604) to both serve as a guide to the discussion about the pipeline security program at that facility/organization and to document the results of the review.

The Original ICR

The original ICR for this program was approved in 2010. It noted that the CSR would involve 12 reviews per year and that each review would take about 8 hours to complete. The ICR reported an expected annual burden cost of $11,076 (@ about $115/hour).

The original 60-day ICR notice noted that there was a potential universe of 2200 organizations at which a CSR could take place. That notice also noted that there would be a follow-up visit at one or two of an organization’s field locations to assess how well the organization was actually implementing their corporate pipeline security plan. That comment was not present in the subsequent 30-day ICR notice nor was there any indication of follow-up visits in the approved ICR.

The current ICR expires on May 31^st, 2013.

Information provided to the TSA in these reviews will be protected under the Sensitive Security

Information (SSI) program in accordance with procedures meeting the transmission, handling, and storage requirements of SSI set forth in 49 CFR parts 15 and 1520.

Updated ICR

The only substantive change in this ICR notice is that TSA is now expecting to conduct 15 CSR’s per year instead of 12. This would increase the burden time to 120 hours per year. The notice does claim that there will be no cost burden to respondents.

Public Comments

TSA is soliciting public comments on this ICR renewal. Comments may be submitted by email (TSAPRA@dhs.gov). Comments must be submitted by April 29^th, 2013.

Bills Introduced – 02-25-13

The first day back in Washington and the House and Senate are down to a more normal number of bills introduced on Monday, 16 in the House and 5 in the Senate. Two of the House bills may be of interest to readers of this blog:

HR 804 Latest Title: To cancel the 251A sequester for the revised security category and to provide for a reduced spending plan with respect to the Department of Defense, and for other purposes. Sponsor: Rep Coffman, Mike (R,CO)

HR 809 Latest Title: To provide for improvement of field emergency medical services, and for other purposes. Sponsor: Rep Bucshon, Larry (R,IN)

It is hard to tell from the brief information currently available if either of these bills will really be of interest. The reduced spending plan in HR 804 could potentially affect cyber-operations in DOD. I can think of plenty of ways that improvements in field emergency medical services would be of direct benefit to chemical emergencies at both fixed sites and transportation incidents. We’ll just have to wait and see what the actual language of the bills contain.

STB Announced Meeting of RETAC – 3-14-13

Today the Surface Transportation Board (STB) published a meeting announcement in the Federal Register (78 FR 13156-13157) for the upcoming meeting of the Rail Energy Transportation Advisory Committee (RETAC). The meeting will be held in Washington, D.C. on March 14^th, 2013.

According to the notice, RETAC was formed to provide advice and guidance to the Board, and to serve as a forum for discussion of emerging issues regarding the transportation by rail of energy resources, particularly, but not necessarily limited to, coal, ethanol, and other biofuels. With the oil industry considering the use of rail transportation to move crude oil where pipelines are not yet available, transportation of crude is certain to be added to the Committees plate.

The agenda for this meeting includes:

• Rail performance;

• Capacity constraints;

• Infrastructure planning and development;

• Effective coordination among suppliers, carriers, and users of energy resources;

• Introduction of new members;

• Review of applicable rules;

• Performance measures review;

• Discussion of domestic oil production and transportation;

• Discussion of the impact of increases in export coal;

• Industry segment reports by RETAC members; and

• Roundtable discussion.

This meeting is open to the public and the notice does not mention any requirement to register to attend. Neither does it mention any possibility of members of the public being allowed to make presentations, oral or written, to the Committee.

FMCSA Re-submits Unified Registration Final Rule to OMB

In an amazing display of inter-agency cooperation OMB announced that it had first rejected and a Federal Motor Carrier Safety Administration final rule and then accepted the resubmission, all in a single day. I mentioned the FMCSA Unified Registration rule when it was originally submitted to the OMB for review just a little over a week ago.

OMB rejected the original submission as being improperly submitted. The submission error was apparently insubstantial enough that FMCSA was able to correct the problem and resubmit the rule all in the same day. The OMB rejection announcement did not explain the reason that they decided that the original submission was improperly submitted.

NIST Publishes Cybersecurity RFI

This morning the National Institute of Standards and Technology (NIST) Published a notice in the Federal Register (78 FR 13024-13028) requesting information in support of their development of the Cybersecurity Framework directed by the President’s Executive Order “Improving Critical Infrastructure Cybersecurity” (EO 13636).

The RFI

The bulk of the request for information (RFI) is as I have described in two previous blog posts on the President’s Executive Order:

Cybersecurity EO – Developing the Cybersecurity Framework

Cybersecurity EO – NIST RFI Questions

The opening paragraphs of the Supplementary Information section of the RFI are substantially different than those found in the Draft RFI published a week and a half ago. There is not a lot of new information here; mainly just a change in focus and justification for the development of the Framework. An important part of this is the following general statement of how NIST will tackle this complex task:

“As a non-regulatory Federal agency, NIST will develop the Framework in a manner that is consistent with its mission to promote U.S. innovation and industrial competitiveness through the development of standards and guidelines in consultation with stakeholders in both government and industry. While the focus will be on the Nation’s critical infrastructure, the Framework will be developed in a manner to promote wide adoption of practices to increase cybersecurity across all sectors and industry types.”

Suggested Changes

The suggestions that I made for additional questions and the modification of one question were certainly not adopted in the RFI. Since the suggestions were made just yesterday, even if NIST had been so inclined, there was not time to make changes to the RFI for today’s publication.

While the RFI provides a number of questions that NIST wants to have the critical infrastructure community address in their responses, the RFI also makes clear that any additional information the community can provide that might assist NIST in developing the framework will be appreciated. With that in mind I want to re-post the additional questions that I think should be addressed in the development of the Cybersecurity Framework. I would like to suggest that any critical infrastructure facility or organization with industrial control systems should address these questions when providing a response to this RFI.

• Does the organization maintain separate security programs for control systems and information systems or are they combined under a single manager?

• Are there significant differences in the ways in which the security programs for IT and control systems manage the risks associated with those systems?

• Does the organization utilize different standards, guidelines and/or best practices in establishing the security requirements for their IT systems and control systems?

Public Response

The whole point of an RFI is to solicit public comments on the topic. Comments on this RFI may be submitted to NIST via email (cyberframework@nist.gov). Comments need to be submitted by April 8^th, 2013. NIST reports that they will publish all comments received, without redaction, at http://csrc.nist.gov.

It is important that everyone in the control system cybersecurity community should take the time to read and respond to this RFI. NIST needs as much as possible from this community to ensure that the unique cybersecurity concerns of control systems be adequately addressed in the preliminary Framework being developed by NIST.

Moving Forward

This early publication of the NIST RFI is one of the best signs that I have seen that this Executive Order might actually get implemented before President Obama leaves office. There are still a number of potential road blocks and political hurdles that must be overcome, but this is an encouraging sign.

Cybersecurity EO – NIST RFI Questions

This is the second in a series of posts about the Cybersecurity Framework being developed by the Director of the National Institute of Standards and Technology (NIST). This post looks at some of the questions NIST is including in their Request for Information that will be published in the Federal Register in the hopefully not too distant future.

Earlier blog posts include:

Cybersecurity EO – Developing the Cybersecurity Framework

As I noted in the earlier post, the Director has posted on the NIST web site a draft of the request for information (RFI) that he intends on publishing in the Federal Register as part of the collaborative effort to develop a consensus supported Cybersecurity Framework as part of President Obama’s Executive Order “Improving Critical Infrastructure Cybersecurity” (EO 13636). Under the terms of that EO the Director of NIST is supposed to publish a preliminary Framework by October 17^th, 2013.

The draft RFI addresses three main areas that it wishes the critical infrastructure community to address in providing information to support the development of the Cybersecurity Framework. They are:

• Current Risk Management Practices (pg 4);

• Use of Frameworks, Standards, Guidelines, and Best Practices (pg 5); and

• Specific Industry Practices (pg 6).

Current Risk Management Practices

There are twelve general questions listed in this section that NIST would like the critical infrastructure (CI) community to answer. The first two are sort of generic questions dealing with the challenges associated with cybersecurity; specifically with improving CI cybersecurity practices and with developing a cross-sector, standards based Framework. The remaining questions deal more specifically with how CI organizations are currently dealing with cybersecurity management issues.

While I have mentioned an apparent information technology focus of the EO and the RFI, that focus is much less noticeable here. None of the questions actually mentions IT and they all could clearly include policies and procedures dealing with control system issues. I do think that the vast majority of the responses that NIST will receive for these questions will be IT focused. That realistically reflects the fact that the IT portion of the cyber-community is much larger and has been focusing on cybersecurity issues longer.

Having said that, and given the fact that control system security issues are more likely to lead to catastrophic effects, I would like to suggest that NIST add two control-system specific questions to the mix about current risk management practices:

• Does the organization maintain separate security programs for control systems and information systems or are they combined under a single manager?

• Are there significant differences in the ways in which the security programs for IT and control systems manage the risks associated with those systems?

Use of Frameworks, Standards, Guidelines, and Best Practices

Since the President’s guidance for the development of the Cybersecurity Framework emphasizes the maximum possible use of existing consensus standards this second set of questions will be very important in gathering the data necessary for that development.

Again, the questions in this section are generic enough that they could address both IT and control system security issues. Unfortunately, given the relative size of the IT security and control system security communities within most organizations, I’m afraid that the control-system security side of the problem will not receive the same level of attention in the responses to these questions.

To ensure that the control-system side receives adequate attention I would like to see one question added to this section:

• Does the organization utilize different standards, guidelines and/or best practices in establishing the security requirements for their IT systems and control systems?

Specific Industry Practices

The last set of questions deal with 9 specific areas dealing with current industry practices concerning cybersecurity. Those areas are:

• Separation of business from operational systems;

• Use of encryption and key management;

• Identification and authorization of users accessing systems;

• Asset identification and management;

• Monitoring and incident detection tools and capabilities;

• Incident handling policies and procedures;

• Mission/system resiliency practices;

• Security engineering practices; and

• Privacy and civil liberties protection.

Reading the questions for this section it is clear that NIST considers these 9 areas to be the core practices that will be included in the framework. This makes the inclusion of the first area very important. I would, however, like to suggest that one key area is missing from this list, a personnel surety program though I suppose that could be shoe-horned into the identification and authorization of users.

The IT-centric nature of the program does raise its head unnecessarily in Questions 7 in this section. That question reads:

Do organizations have a methodology in place for the proper allocation of business resources to invest in, create, and maintain IT standards?

Substitute ‘cybersecurity’ for ‘IT’ in that question and I think that you have a more appropriate question for both sides of the cyber house.

Moving Forward

It was encouraging to see that NIST was so far ahead of the game with their development of the draft RFI before the ink was dry on Obama’s signature on the EO. Of course they were well aware of the Cybersecurity Framework requirements, probably back in November, or maybe even before. The delay in getting the RFI published in the Federal Register, however, points to the political wrangling that will inevitably make it difficult for NIST to meet their October 17^th deadline for the publishing of the preliminary Framework.

And remember, there are other deadlines that will have an impact on the timeliness of NIST’s work. I’ll look at those in some detail in future blogs in this series.

Cybersecurity EO – Developing the Cybersecurity Framework

It has been almost a week since President Obama’s Executive Order on critical infrastructure cybersecurity (EO 13636) was officially published in the Federal Register (78 FR 11737-11744). There are a number of important deadlines provided in the EO but one of the most critical is the requirement for NIST to publish a “preliminary version of the Cybersecurity Framework” {§7(e)} within 240 days of the publication of the EO (deadline – 10-17-13).

Consultative Process

Complicating the meeting of this deadline are the requirements of §7(d) that describe the development requirements that must be met. The first is that the Director of NIST will “engage in an open public review and comment process”. Principally this is going to require that at the end of initial process the preliminary Framework will be published in the Federal Register and there will be a public comment period provided. Since this is the end product of the 240 day deadline. That does not seem to be a cause for potential delay except that the document has to be submitted to OMB for review/approval before that publication takes place. That review process can take anywhere from a couple of weeks to years.

The Director is also required to consult with a variety of government agencies in the development process. The EO states that the Director will consult with “the [DHS} Secretary, the National Security Agency, Sector-Specific Agencies and other interested agencies including OMB”. The Director of NIST does not have the same political weight as the Secretary, the Director of NSA or OMB, so that ‘consultative’ process will probably be done in more of a directed fashion. That will be further complicated by the fact that those three agencies have frequently conflictive objectives. Of course, no one expects that there will be any petty political foot dragging because NIST got to develop the Framework and not DHS or NSA (just a tiny bit of political sarcasm here).

Other ‘lesser’ government agencies are also to be consulted in the framework development process. They include:

• Other relevant agencies;

• Independent regulatory agencies; and

• State, local, territorial, and tribal governments.

A number of ‘other’ federal agencies have some measure of cybersecurity oversight responsibility that will have to be consulted so that their toes won’t get stepped upon. The real sensitive toes will be found in the ‘independent’ regulatory agencies who have some active current cybersecurity programs in place, including FERC, NRC and SEC to mention a few.

There are also requirements to consult with the private sector. These are more clearly identified in §6 of the EO and include the:

• Critical Infrastructure Partnership Advisory Council;

• Sector Coordinating Councils;

• Critical infrastructure owners and operators;

• Universities; and

• Outside experts.

Since the Secretary has 150 days to identify specific critical infrastructure at ‘Greatest Risk’ this could be a special delaying factor in the consultative process. It looks, however, like the Director has found a way to shortcut this problem and to expansively engage the potentially affected private sector communities. There is going to be a Request for Information (RFI) published in the near future in the Federal Register asking for general and some specific information that will be used to develop the preliminary Framework. In effect, if not de jure, this will be an advance notice of propose rulemaking (ANPRM).

Draft RFI

It certainly seems like the Director intends to meet the 240 day deadline set by the President. A draft copy of the RFI was produced (apparently from the file name) on February 12^th the day before the President released the EO. I have been waiting expectantly all week for it to appear in the Federal Register, but it appears that we may have already hit the first OMB delay.

The NIST draft RFI document (page 1) proposed three goals for the Framework development process:

• To identify existing cybersecurity standards, guidelines, frameworks, and best practices that are applicable to increase the security of critical infrastructure sectors and other interested entities;

• To specify high-priority gaps for which new or revised standards are needed; and

• To collaboratively develop action plans by which these gaps can be addressed.

NIST goes on to explain (page 2) that in order to be effective the Framework should provide:

• A consultative process to assess the cybersecurity-related risks to organizational missions and business functions;

• A menu of management, operational, and technical security controls, including policies and processes, available to address a range of threats and protect privacy and civil liberties;

• A consultative process to identify the security controls that would adequately address risks that have been assessed and to protect data and information being processed, stored, and transmitted by organizational information systems;

• Metrics, methods, and procedures that can be used to assess and monitor, on an ongoing or continuous basis, the effectiveness of security controls that are selected and deployed in organizational information systems and environments in which those systems operate and available processes that can be used to facilitate continuous improvement in such controls;

• A comprehensive risk management approach that provides the ability to assess, respond to, and monitor information security-related risks and provide senior leaders/executives with the kinds of necessary information sets that help them to make ongoing risk-based decisions;

• A menu of privacy controls necessary to protect privacy and civil liberties.

Control System Coverage

A close reading of the guidelines explicated above shows that the NIST appears to be information focused. This is made clear by the introductory sentence that precedes the list above. It states:

“In order to be effective in protecting the information and information systems [emphasis added] that are a part of the U.S. critical infrastructure, NIST believes the Framework should have a number of general properties or characteristics.”

Reading through the remainder of the document there are a few mentions of control system issues but the vast bulk of this document focuses on information systems. I’ll look at the information requirements, and their relationship to control system security issues, of the RFI in future blog posts.

VCAT Webinar

Bridget O'Grady has a blog post over at the Association of State Drinking Water Administrators (ASDWA) website that notes that the Chemical Sector-Specific Agency (CSSA) in the DHS Office of Infrastructure Protection will be holding a webinar to discuss their Voluntary Chemical Assessment Tool (VCAT).

Background

As I have noted before the VCAT was designed to provide a method of assessing the security vulnerabilities of non-regulated chemical facilities, though I firmly believe that a VCAT assessment would also be valuable for facilities regulated by such programs as CFATS or MTSA.

One of the beneficial uses of the program is to look at the comparative effectiveness of various proposed security measures. Once the current facility information is entered into the system a risk score is provided. Subsequent changes to the facility information reflecting proposed security measures will change the risk score allowing the facility security manager to conduct a cost benefit analysis of various possible security measures.

The CSSA has not publicly provided any data on the methodology used in the VCAT so it is difficult to assess how well the program deals with the various complexities of the security assessment process. It should, however, provide an analysis that is not influenced by what a particular vendor is selling; something that is not always readily available to security managers.

Alion Science and Technology

An interesting bit of information provided by Bridget’s post led me to the Alion Science and Technology web site. They note that they developed the VCAT using their  CounterMeasures® assessment system. It also claims that the VCAT has been endorsed by ACC and SOCMA, though no links to those endorsements have been provided. I can’t find anything related to VCAT on the ACC site, but there are a number of references (available to SOCMA members only) to VCAT on the SOCMA site.

There is nothing on the CSSA web site that would indicate that Alion was the contractor for the development of the VCAT. That type of information is not typically provided publicly by DHS.

The Webinar

Bridget reports that the webinar will be held on March 20^th, 2013 at 4:00 pm EDT. Personnel wishing to register for the webinar should contact rpross@alionscience.com.

NOTE: Bridget provides the following link to VCAT: http://vcat.anl.gov. That is the link to the VCAT assessment portal and you must have logon information to access that portal. Contact chemicalsector@hq.dhs.gov to get access to that site.

Congressional Hearings – Week of 2-24-13

Both the House and Senate will be in town this week and the hearing process begins to heat up with early emphasis on budget matters. We have two homeland security related meetings this week and an organizational meeting from the lineup that might be of interest to readers of this blog.

Coast Guard Mission

The House Transportation and Infrastructure Committee will hold a hearing on Tuesday to look at the “Coast Guard Mission Balance”. The Deputy Commandant for Operations, Vice Admiral Neffenger, is the only scheduled witness. It will be interesting to see how much of the testimony and questioning deals with port security issues.

TSA Budget

The Homeland Security Subcommittee of the House Appropriations Committee will be holding a hearing on Wednesday on “TSA – Resources for Risk-Based Security”. The TSA Administrator, John Pistole, is the only scheduled witness. The thing to watch for here is how much time is taken up with surface transportation security issues; I don’t expect that it will be much.

Committee Organizational Meeting

The Senate Homeland Security and Governmental Affairs Committee will hold an organizational meeting on Tuesday. Nothing of real importance will be discussed here, but it will be interesting to watch the relationship between the new Chairman and the Ranking Member. For the last couple of congresses the friendly relationship between Lieberman and Collins had a large influence on the bills that the Committee crafted.

House Floor

Not much going on in the House this week, though that is likely to change as the week goes by. There are only two bills and one resolution currently on the Majority Leader’s agenda for the week. None of them deal with security issues.

HR 654 and Water Facility Security

As I noted in an earlier blog, Rep Harper (R,MS) introduced HR 654, the  Grassroots Rural and Small Community Water Systems Assistance Act. This bill would amend the Safe Drinking Water Act (42 U.S.C. 300f et seq) to reauthorize and address funding priorities for technical assistance to small public water systems.

While the bill does not directly affect the language for the protection of water systems from terrorist attack of 42 USC 300i-2, it would, in passing, possibly provide some funding support for such activities. It would add §300j(1)(e)(8)(A):

“The Administrator may use amounts made available to carry out this subsection to provide technical assistance to nonprofit organizations that provide to small public water systems onsite technical assistance, circuit-rider technical assistance programs, onsite and regional training, assistance with implementing source water protection plans, and assistance with implementing monitoring plans, rules, regulations, and water security [emphasis added] enhancements.”

The congressional findings section of this bill implies that small water systems are those that “serve a population of less than 10,000 individuals” {§2(3)}. This is well above the 3,300 minimum used for the security requirements of public water treatment facilities. And the funding described in this bill is separate from the anti-terrorism program funding provided for small public water treatment facilities in 42 USC 300i-2(e).

At this point it is not clear to me how likely this bill will be to make it to the floor in the House. I don’t see anything in the bill that would interfere with a bipartisan vote in either the House or Senate. It is just a matter of how much of a priority the leadership would place on moving this to the floor for consideration. I would not be surprised to see this added to an EPA funding bill if one gets considered in the 113^th Congress.

ICS-CERT Publishes Honeywell EBI Advisory

Late this afternoon the DHS ICS-CERT published an advisory for an ActiveX vulnerability for the Honeywell Enterprise Buildings Integrator (EBI). The vulnerability was reported by Juan Vazquez of Rapid7 in a coordinated disclosure.

The Advisory

ICS-CERT reports that a moderately skilled attacker using a social engineering attack could remotely exploit this vulnerability to execute arbitrary code on the system. ICS-CERT maintains that the need to use a social engineering attack vector “decreases the likelihood of a successful exploit” (pg 3). Recent reports on the success rates for social engineering attacks don’t seem to support that assertion.

Honeywell recommends that the HscRemoteDeploy.dll be disabled on “any client or server computers on affected systems”. They have an update package that accomplishes this, but recommend that it be only run by a “qualified, trained resource”. Honeywell has also asked Microsoft to “issue a kill bit for the HscRemoteDeploy.dll in a future monthly Microsoft Windows security update”. This will disable the DLL on any machines running the automated Windows update.

No Public Exploit Code, Yet

The advisory reports that there is no known exploit code publicly available at this time. It also notes that Rapid7 plans on releasing a Metasploit module for this vulnerability next month. This continues a trend upon which I have recently reported that white hat researchers are publishing exploit code even on coordinated disclosure vulnerabilities. Rapid 7 is more forgiving in their publication process than is Exodus Intelligence since they are giving owners a reasonable chance to install their system updates before the exploit code is published. It would be even more forgiving if they held off their publication until Microsoft publishes the DLL kill bit in their Windows update.

DHS Privacy Impact Assessment Publication Change

DHS published a notice in today’s Federal Register (78 FR 12337-12343) announcing a change in the availability status of 38 Privacy Impact Assessments (PIA) that were published between June 1^st and November 30^th, 2012. Those PIAs are currently published on various Department web sites, but after April 23, 2013, they will only be available upon request from the issuing agency.

PIAs of Interest

These PIAs are required by government regulation because the Department collects, stores and uses personally identifiable information (PII) in the supported programs and the PIAs outline the steps the Department takes to protect that information. Four of the programs listed in this notice may be of specific interest to readers of this blog; they are [Note: links are to the description of the PIA in this notice]:

• DHS/OPS/PIA-008 Homeland Security Information Network R3 User Accounts (HSIN);

• DHS/OPS/PIA-007 Homeland Security Information Network 3.0 Shared Spaces;

• DHS/NPPD/PIA-009 Chemical Facility Anti-Terrorism Standards (CFATS);

• DHS/USCG/PIA-001(b) Homeport Internet Portal.

There is no centralized location for finding these PIA’s on the DHS web site. Each organization maintaining PIAs has a separate web site where the current links can be found to the actual PIA. The above listed PIAs can be found at the listed links:

• HSIN R3 User Accounts;

• HSIN 3.0 Shared Spaces;

• CFATS

• Homeport

According to the Office of Operations Coordination and Planning web site the HSIN 3.0 Shared Spaces PIA was updated in January of this year. I suppose that the updated PIA is not going to be removed from the site this April.

Interestingly the NPPD , the  Office of Operations Coordination and Planning, and the Coast Guard PIA web sites all provide links to a number of PIAs that predate the June 1^st, 2012 start of the period covered by this notice. Why the particular PIAs listed in this notice will be removed from the web site and not the earlier ones is not clear.

Why?

Actually, the whole purpose of removing the PIAs from the DHS web site is not clear. In fact, it appears to me to be counterproductive to the whole PIA process. PIAs are produced to ensure, and document for the public, that PII collected by the government is collected for legitimate purposes and is appropriately protected by the collecting agencies. Making these documents less available inevitably leads to questions of the need for collecting the data and the viability of the measures to protect that data.

This is especially confusing since no reason or justification is provided for the action.

ICS-CERT Updates Wonderware Advisory

This afternoon the DHS ICS-CERT updated their advisory for Ruby on Rails, an open source web framework used by a third-party component of the Wonderware Intelligence. The multiple vulnerabilities included in the advisory were reported by Aaron Patterson in a coordinated disclosure. The advisory was initially released on the CERT secure portal; this update is the first time it has been published publicly.

The Advisory

The reported vulnerabilities include:

• Permissions, privileges and access controls, CVE-2013-0155;

• Input validation, CVE-2013-0156; and

• Input validation, CVE-2013-0333. NOTE 1: This vulnerability was added in this update. NOTE 2: There was a typo in the link provided in the advisory, I have provided the correct link here.

ICS-CERT notes that a low skilled attacker could remotely exploit these vulnerabilities to execute arbitrary code. Invensys has produced a new version of their Tableau Dashboard Server that mitigates these vulnerabilities.

Older Versions

Invensys has come up with a unique way to deal with these vulnerabilities in older, unsupported systems. The advisory notes that:

“Customers currently using a version older than 1.5 SP1 are required to obtain a new license.”

There is always a bit of a disconnect between the interests of the vendor and the customer when it comes to correcting security deficiencies in older systems. Many owners (maybe most) will use a control system for a very long time; some long past any time that a reasonable vendor would spend money on developing and providing patches. Presumably this new license will provide the owners of older systems with a more supportable version of their system.

Ruby on Rails

The big question here is if this is really an Invensys security vulnerability. It certainly affects these Wonderware systems, but it is more properly a vulnerability in a third-party component (Tableau Server) of the system and that is based upon an open source program, Ruby on Rails.

As I have asked on a number of similar occasions, who else is using either Tableau Server or Ruby on Rails in their ICS system? Shouldn’t we expect to find these three vulnerabilities in their system as well?

New CISPA Bill Identical to Version Passed in House

As I promised, since the GPO was finally able to make a copy of HR 624, the Cyber Intelligence Sharing and Protection Act (CISPA), available yesterday, I have done a detailed review of the bill and it is virtually identical (two small, inconsequential wording changes) to the version of HR 3523 that was passed in the House last session, including the privacy provisions added during the House floor debate.

While this bill is being actively opposed by privacy advocates with a zeal that approaches paranoia, I really don’t see their concern. The bill has been watered down to the point where there are really no requirements to share information with the federal government about cyber-attacks and no real authority for the federal government to share information with the private sector.

This bill will make its way back to the floor of the House and will pass once again. The Senate will ignore the bill and we will be left with the information sharing provisions of the President’s EO without any legal protections to actually allow the information sharing to really proceed.

ACC ASP Press Release

I got a nice email from Scott Jenson, Director of Issues Communication, American Chemistry Council, providing me with a copy of the press release about their CFATS Alternative Security Program. Reader’s will remember my detailed review of this template for submitting the information necessary for ISCD to evaluate a facility site security plan.

ISCD Endorsement

I’ve been a little disappointed that ACC hasn’t been a more proactive in publicizing this outstanding tool. Reading this press release it is clear to see why Scott and his people have held off. In the press release there is a link to a very kind letter from David Wulf, Director, Infrastructure Security Compliance Division, essentially endorsing the ACC ASP. David says, in part:

“Thank you especially for ACC's efforts to help high - risk chemical facilities meet the CFATS requirements through the development of the ACC Alternative Security Program ( ASP) Guidelines and Template . We commend your decision to make these documents available to all facilities regulated under CFATS for potential consideration and reference in the development of other ASPs.”

There is no date on the Wulf letter, but I’m assuming that as soon as ACC had this letter in hand, they started immediate work on this press release. This is a very valuable endorsement. I would like to join David in commending ACC for sharing this tool with the whole of the regulated community, not just their member organizations.

BTW: It would be nice to see some mention of this ASP somewhere on the DHS Chemical Security web page. A mention of the ACC ASP with a link to the document would make it easier for non-ACC members to avail themselves of this tool.

ISCD Promises Better SSP Performance

David takes the opportunity in this letter to address the continued slow pace of SSP approvals. He notes that ISCD has streamlined the authorizing and approval process and then reports that ISCD has set “set a goal of 400 approvals [emphasis added] by the end of 2013”. This would be a truly remarkable accomplishment since the last official number that I had seen on approvals was that only 2 had been completed. Even at this rate they will only have about 1/3 of the SSPs approved before they have to go back and start re-evaluating SSPs that were previously approved.

Actually, ISCD has not approved any SSPs yet. They have only given provisional approvals because facilities can still not comply with the Terrorist Screening Database vetting requirements of Risk-Based Performance Standard 12. Metric 12.4 for all four Tier levels states that:

“Processes are in place to provide DHS with the necessary information to allow DHS to screen individuals (e.g., employees, contractors, unescorted visitors) who have access to restricted areas or critical assets against the TSDB.”

Since ISCD has not yet even published their proposed procedures for this vetting process, facilities are not able to comply with this requirement. ISCD is over four months late (based upon a promise made by Undersecretary Beers in testimony to a Congressional Committee) in the publication of the 60-day information collection request (ICR) in the Federal Register. If this were to be published today it would still be nearly the end of the year (best case) before final OMB approval could be given to begin the collection of the information necessary for this vetting.

So it will be nearly impossible for ISCD to achieve their goal of 400 approvals by the end of the year. I’m all for setting high goals David, but they must be achievable.

ICS-CERT Publishes CoDeSys Server Advisory

This afternoon the DHS ISC-CERT published an advisory for multiple vulnerabilities in the 3S CoDeSys Gateway-Server application. The vulnerabilities were reported by Aaron Portnoy of Exodus Intelligence in a coordinated disclosure.

The Advisory

The reported vulnerabilities include:

• Improper access of indexable resource, CVE-2012-4704;

• Directory or path traversal, CVE-2012-4705;

• Heap-based buffer overflow, CVE-2012-4706;

• Improper restriction of operations within the bounds of a memory buffer, CVE-2012-4707; and

• Stack-based buffer overflow, CVE-2012-4708.

NOTE: the CVE links may not be active for a couple of days; NIST uses this report to populate the CVE file.

ICS-CERT reports that a moderately skilled attacker could remotely exploit these vulnerabilities to crash the system or exploit arbitrary code. 3S has produced a patch that ICS-CERT reports mitigates these vulnerabilities.

Exploits Code Available?

The advisory states that there are no publicly available exploits for these vulnerabilities. Given that they were reported by Exodus Intelligence, I am not so sure that that is the case. Readers will remember my comment on the Exodus business model in an earlier blog post. EI provides their customers with exploit code for all of their ‘responsibly reported’ discoveries either just after the vulnerabilities are reported or when the vendor reports the vulnerabilities. Now this might not fit the ‘publicly available’ definition that ICS-CERT is using this week, but it looked like it did last week with the Schneider advisory.

More on Tigeuntourine Gas Refinery Attack

Joe Trindal, a long time reader and security expert, was kind enough to provide me with a copy of a slide presentation he used to present a case study of the recent Tigeuntourine Gas Refinery terrorist attack. I’m trying to get him to post it on the internet somewhere where all can see it, but he has given me permission to discuss some of the elements.

Collateral Damage

First off readers might remember that I noted in an earlier blog that I was surprised that there weren’t more deaths and destruction as a result of the counter-attack on the facility. While I haven’t heard Joe’s narration of these slide, it appears that the reason for the relative lack of collateral damage is due to the fact that the bulk of the fighting took place away from the actual production facility (see satellite photo, courtesy Joe Trindal). Only after the security checkpoint and the Al Hayat accommodations compound were secured did the terrorists seize the production facility. Essentially the same order was followed by the security forces when they re-took the facility.

Still flammable gasses and liquids are handled at the facility and damage to almost any of the processing equipment could lead to a serious conflagration or catastrophic explosions. Now this is a gas refinery so more of the equipment is hardened to handle high pressures. This means that it is less likely (though certainly not impossible) that a stray bullet would penetrate the piping resulting in a flammable gas/liquid release.

If the security forces re-taking the production facility were aware of the danger, and employed only pistols and sub-machineguns (lighter caliber weapons) then the danger would have been further reduced. Still they took a major risk when they decided to attack the facility that would be justified only if there were an imminent danger of the terrorists starting to detonate their explosive devices.

Lack of Will

Looking at Joe’s presentation and the satellite imagery, it seems clear to me that the terrorists who seized this facility lacked the will to become martyrs to their cause. They had a day to prepare for the security force assault on the process facility. If they had taken defensive positions within the processing equipment and prepared demolitions with dead-man switches, the facility would not be standing today. Based upon other attacks, we certainly cannot rely on future attackers lacking the will to die for their cause.

Attack Elements

Joe’s presentation reports that the assault team consisted of 33 attackers organized in three assault teams. They were equipped with assault rifles, light machine guns and rocket propelled grenade launchers; so roughly a light infantry platoon in personnel and equipment. A foreign raised terrorist force of this size would be difficult to get into place with weapons and equipment in the United States, but certainly not impossible. If we are looking at domestic terror groups pulling off this type of attack it becomes much more doable.

Few facility security forces would be able to withstand this sort of assault. Hitting in the early morning hours at three separate sites on a facility perimeter, most installations would fall within minutes, certainly before local police patrol forces could respond.

The force was prepared for a counter-attack by security forces. They:

• Dispersed hostages around the facility – making a single rescue move impossible;

• Set demolition charges on foreign hostages – making ‘high-value’ hostages harder to rescue;

• Set anti-personnel improvised explosive devices – increasing the effectiveness of a limited number of personnel; and

• Set demolitions throughout the facility – attempted to insure destruction of facility even if they were overwhelmed.

These actions certainly contributed to the high death toll amongst the hostages and terrorists.

Stateside Equivalent

Joe is convinced that the attack on the refinery in Algeria increases the risk for a similar attack on facilities here in the United States. An attack with even the limited success seen in Algeria (the facility was only down for a week so the attack was more of a propaganda success than anything else, unless of course you are a family member of one of the employees/contractors killed in the action/counteraction) would have a large psychological and propaganda impact if perpetrated in the US; at least equal to the funk seen after the destruction of the Twin Towers. If a mid-sized or large petrochemical refinery were seriously damaged or destroyed the economic impact would be huge.

Joe has more access to intelligence information than I do, but I don’t really see this type attack being conducted in this country by one of the al Qaeda affiliated organizations. The logistics of supporting an attack force of this size in this country would make it too easy for law enforcement and facility security to detect the attack in the preparatory stages.

I can see a Tom Clancy type scenario where a middle-eastern semi-military terrorist group (not necessarily affiliated with al Qaeda) works with a Mexican drug cartel to stage a cross border attack on a US refinery. If young Jack Ryan didn’t discover the attack in the preparatory stages this could be successfully done.

Having said that; we must remember that we have some homegrown groups that have the requisite quasi-military training and weapons necessary to pull off this sort of coordinated attack.

Prevention

While this type of attack is a low probability event, it is not a zero probability. Given that, how do you defend against such an assault? Once three light-infantry squads start firing on your perimeter, you don’t. There is no company that can afford to have the type of hardened defenses and manpower on hand 24/7 to repel such an attack, particularly given the size of the perimeter of most refineries and the proximity of other businesses and houses. The oil business just isn’t that profitable.

The best way to stop such an attack is to arrest the perpetrators in the planning stages. The FBI and Homeland Security intel folks have been doing a good job at this type of thing. Local police and facility security forces have a strong part to play in this counter-intel type operation with an effective counter-surveillance program.

Counter-Attack

Sooner or later an attack like this (though probably on a smaller scale to avoid detection) is going to succeed. A team of determined terrorists who are willing to die are going to gain control of a portion of a large petrochemical facility. And someone is going to have to go in and dig them out without blowing up the facility.

This job will almost certainly fall to the local police swat team or their FBI counterparts. But before they go barging in with their high-powered rifles and flash-bang stun grenades, someone is going to have to explain the safety facts of life in a refinery to these head-strong folks.

High-powered rifle bullets will go right through storage tank walls, perhaps even pressure tank walls, and most piping. If there are liquids or gasses inside when those penetrations happen the stuff will come out. If that stuff is flammable (and most things at a refinery are) there is a good chance that an explosive vapor cloud will form and the next spark or muzzle flash may accomplish the terrorist aim of destroying at least a significant portion of the facility.

Someone is going to have to think long and hard about counter-shooter operations within refineries and chemical facilities. Action teams are going to have to have a thorough understanding of the hazards involved and in what parts of the refinery they are working; different parts have different hazards. Low powered weapons of limited range are going to be required. And most importantly, tools and weapons will have to be non-sparking, non-flame producing.

And, of course, now is the time to start thinking about things like this, not when there is a team of shooters emplacing explosive devices in your refinery.

National Freight Advisory Committee Established

The Department of Transportation (DOT) published a notice (78 FR 11727-11728) in Tuesday’s Federal Register (available on-line on Saturday) announcing the formation of the National Freight Advisory Committee (NFAC) and soliciting nominations for membership on the NFAC.

The NFAC will provide advice and recommendations to the Transportation Secretary on matters related to freight transportation to include:

• Implementation of the freight transportation requirements (§§ 1115, 1116, 1117 and 1118) of the Moving Ahead for Progress in the 21st Century Act (Pub. L. 112-141);

• Establishment of the National Freight Network {21 USC 167(c) in §1115};

• Development of a National Freight Strategic Plan{21 USC 167(f) in §1115};  

• Development of strategies to help States implement State Freight Advisory Committees (§1117) and State Freight Plans (§1118);

• Development of measures of conditions and performance in freight transportation {21 USC 167(g) in §1115};   

• Development of freight transportation investment, data, and planning tools {21 USC 167(h) in §1115};   and

• Legislative recommendations.

The Secretary of Transportation will appoint at least 25 members to the NFAC representing a broad cross section of the freight transportation community, including:

• State Departments of Transportation;

• State, local, and tribal elected officials;

• Local planning offices;

• Shippers, businesses, and economic development;

• Air cargo, freight forwarder, rail, maritime, ports, trucking, and pipelines;

• Labor unions; and

• Safety, the environment, and equity communities.

Nominations for appointment as committee members are being solicited. A sample template for nomination submissions can be found here. Nominations may be emailed to  freight@dot.gov and should be received by March 21^st, 2013.

Offensive Cyber Weapons – Construction, Development, and Employment

Thanks to a TWEET® from Thomas Rid yesterday I had a chance to read an article by Dale Peterson in the Journal of Strategic Studies about offensive cyber-weapons. Now if you have been reading Dale’s blog at DigitalBond for the last couple of years like I have, there really isn’t much new information here; but he has brought a great deal of information together here in a way that hasn’t been done before. More importantly, he has brought the information to a completely new audience; an audience that really needs to understand just how easy it is to construct a cyber-weapon to attack industrial control systems.

Insecure By Design

People in the control system security community are certainly aware of Dale’s almost patented phrase ‘insecure by design’. Not surprisingly Dale opens his article with a discussion of this concept. Using the Stuxnet example he explains:

“The purpose of Stuxnet was to load a program onto the Programmable Logic Controller (PLC) that controlled the centrifuges at the Natanz fuel enrichment plant. The attackers developed various Windows exploits in order to gain access to the network that the PLCs were on. But once access was gained, no attack code was required to load the cyber weapon onto the PLCs. The Siemens S7 PLC has no source or data identification so any attacker with access to it can load his own program, tell the process to stop, reboot the PLC, or whatever else is desired.”

Three Weapon Types

Dale addresses the issue of the complexity of industrial control systems being a sort of cyber-defense, by noting that there are three different types of attacks that can be initiated depending on the knowledge the attacker has about the control system. Basically they can be described as:

• Simple Weapon – The “attacker uses the lack of authentication to cause the system to crash or operate incorrectly”;

• Moderately Complex Weapon – The “attacker learns about the process and determines how to destroy a physical component or subsystem that will take time to replace”; and

• Complex Weapon – The “attacker modifies the process in a stealthy manner so a cyber attack is not suspected”.

He goes on to give a brief example of how complex a ‘simple weapon’ can be made using a worm to reprogram firmware in a ControlLogix PLC that produces intermittent process failures. As a process chemist this is my most feared type of attack because random failures will be almost impossible to detect as an attack. Unless the facility engineering team has reason to suspect a cyber-attack they will waste untold man-hours trying to track down the root cause of their apparently unrelated process problems while the facility becomes an economic wreck.

Weapon Deployment

Dale notes that cyber-weapon deployment is actually more difficult in most cases than is the development of the actual attack code. This is because most critical cyber-targets are going to be electronically isolated from the easiest attack vector, the internet. Dale briefly describes a variety of common methods of getting the electronic weapon payload into the targeted system. Unfortunately, to my mind, he only mentions in passing the most likely method to be employed against most Western nations; spear phishing.

Because of the difficulties in gaining electronic access to the most important targets the most effective method of deployment is advanced deployment of the electronic payload and then subsequently activating the weapon at the most opportune time. This requires some sort of ‘command and control’ communications link. Dale spends some time describing some of the techniques that are available to achieve these communications.

The Audience

As I noted earlier, Dale is focusing this paper on a different audience than he normally attracts to his blog or his business. Given the publication, it is obvious that he is targeting the planners and politicians that will be either deploying cyber-weapons or defending against them. With that audience in mind, I think he has achieved a reasonable level of technical detail in his presentation. I think he has successfully avoided the pitfalls frequently encountered when a technical expert describes a problem for a non-technical audience.

Most readers of this blog are not going to find anything new here, but I do recommend that anyone in the control system business; including owners, vendors, and integrators, should send a copy of this article to their legislative representatives in Washington. With cybersecurity being an important political topic in the coming months, this article might help to favorably inform the lawmakers about the real cybersecurity problems facing this country.