ISCD Publishes CFATS Update – 9-30-16

Today the DHS Infrastructure Security Compliance Division (ISCD) published their October 2016 CFATS Update, outlining the status of the implementation of the Chemical Facility Anti-Terrorism Standards (CFATS) site security plan (SSP) process. Even while ISCD is working on implementing CSAT 2.0 there continues to be increases in the number of CFATS facilities with authorized and approved SSPs.

	August 2016	Sept 2016	Oct 2016
Covered Facilities	2,984	2,962	2,948
Authorized SSPs	3,410	3,415	3,448
Approved SSPs	2,645	2,653	2,671
Compliance Inspections	1,177	1,260	1,281

The update continues to ignore:

• Calls for a categorization of why over half of the facilities initially covered by the CFATS program have left the program;

• Calls for an explanation of why there are more authorized SSPs than there are facilities in the CFATS program;

• Calls for an explanation of how many SSPs remain to be completed;

• Calls for an accounting of how many of the facilities have failed their compliance inspections.

NOTE: All of those ‘Calls for…’ have come from this blog.

ICS-CERT Publishes Building Control System Advisory

Yesterday the DHS ICS-CERT published a control system security advisory for twin vulnerabilities in the American Auto-Matrix Building Automation Front-End Solutions application. The vulnerabilities were reported by Maxim Rupp. American Auto-Matrix has produced an update to mitigate the vulnerabilities. There is no indication that Rupp has been provided an opportunity to verify the efficacy of the fix.

The vulnerabilities include:

• Local file inclusion - CVE-2016-2307; and

• Plain text storage of a password - CVE-2016-2308

ICS-CERT reports that a relatively unskilled attacker could remotely exploit these vulnerabilities to provide an attacker authenticated credentials to all aspects of the system.

CSAT 2.0 Update – 9-30-16

CSAT 2.0 is going live and there have been some changes on the Chemical Facility Anti-Terrorism Standards (CFATS) web site to support the change in the Chemical Security Assessment Tool (CSAT). Today the folks at the DHS Infrastructure Security Compliance Division (ISCD) published links to three new CSAT manual on the CFATS Knowledge Center web page. Earlier this week they published a list of dates for CSAT 2.0 webinars and in-person demonstrations.

New Manuals

In addition to the previously published Top Screen user manual, DHS has now also published:

• Security Vulnerability Assessment / Site Security Plan Instructions;

• CSAT Survey Application User Manual; and

• CSAT Portal User Manual

NOTE: I am having problems downloading the CSAT Portal User Manual. I’m sure that this is a temporary problem. It does not appear that it is a problem with the link, the document is just taking a long time to successfully load.

The Survey Application User Manual is a new manual. It describes how various parts of the CSAT application work.

The CSAT web site has not yet been updated to show these new manuals. They are currently only available on the CFATS Knowledge Center.

Webinars and Demonstrations

ISCD will be reprising their two-part webinar demonstrating the CSAT 2.0 application. Webinar 1 (CSAT Portal and Top Screen) will be held on October 12^th (registration). Webinar 2 (SVA and SSP) will be held on October 13^th (registration).

ISCD will be holding a number of live demonstrations of CSAT 2.0 at cities around the country. The current schedule includes:

• Boston, MA – 10-25-16 (registration);

• Tampa, FL – 10-27-16 (registration);

• Chicago, IL – 11-15-16 (registration);

• New Jersey – TBA;

• Los Angeles, CA – TBA;

• Houston, TX – TBA;

• San Francisco, CA – TBA; and

• Portland, OR – TBA

Coast Guard Announces NMSAC Meeting – 10-18-16

Yesterday the Coast Guard published a meeting notice in the Federal Register (81 FR 66977-66978) for a two-day public meeting of the National Maritime Security Advisory Committee on October 10^th, 2016 in Leesburg, VA. There will be a webcast of the meeting as well as a teleconference link.

Topics of specific interest to readers of this blog will be addressed on the first day of the meeting. They include:

• Extremely Hazardous Cargo Strategy;

• Transportation Worker Identification Credential;

• Facility Security Officer Regulation and Training; and

• Regulatory Update.

There is no indication in the notice that advance registration is required to attend, view the web cast (https://share.dhs.gov/​nmsac/​) or listen to the teleconference connection (1-855-475-2447; pass code 764 990 20#).

Written comments on the above topics may be submitted to NMSAC for consideration. Comments can  be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket # USCG-2016-0499).

Bills Introduced – 09-28-16

Yesterday with the Senate and House running back to their home districts for campaign purposes a total of 199 bills were introduced. Of those one bill may be of specific interest to readers of this blog:

HR 6227 To provide for a comprehensive interdisciplinary research and development initiative to strengthen the capacity of the electricity sector to neutralize cyber attacks. Rep. Bera, Ami [D-CA-7]

Without even seeing the wording of this bill I suspect that it has very little chance of passing in this session of Congress. It will be interesting to see, however, exactly how it is worded to see if it should (IMHO) be reintroduced next session.

ICS-CERT Publishes Vulnerability Coordination Report

Yesterday the DHS ICS-CERT published a new Vulnerability Coordination Report with data specific for FY 2015. This is being billed as an annual report, but this is the first time the report has been published. If it is an annual report, I would expect that the next version (for FY 2016) will be published early next year.

Coordination Policy

While there is a great deal of statistical data for 2015 and previous years, the most valuable information in this report is the policy explanation for its vulnerability coordination process. The document describes a five step process for handling vulnerability coordination (pg 1):

1. Detection and Collection: ICS-CERT obtains vulnerability information in three ways: ICS-CERT vulnerability analysis, monitoring public sources of vulnerability information, and direct notification of vulnerabilities to ICS-CERT by vendors and independent security researchers.

2. Analysis: Once ICS-CERT has catalogued the vulnerabilities, vendor and ICS-CERT analysts work to understand the vulnerabilities by examining and identifying the issues, as well as the potential threat.

3. Mitigation Coordination: After validating a reported vulnerability, ICS-CERT will continue to work with the vendor on mitigation, including possible patch issuance. Researchers then have the opportunity to validate solutions prior to publication.

4. Application of Mitigation: ICS-CERT will work with the vendor to allow sufficient time for end users to obtain, test, and apply mitigation strategies prior to disclosure. This time window is variable depending on the circumstances of the vulnerability and the impact to critical infrastructure.

5. Disclosure: After gathering the technical and threat information related to the vulnerability, ICS-CERT will notify asset owners about the vulnerability through the publication of an ICS-CERT advisory.

The document describes an ‘advisory’ this way (pg 2):

Advisories provide timely information about current security issues, vulnerabilities, and exploits. An ICS-CERT advisory is intended to provide awareness to or solicit feedback from critical infrastructure owners and operators concerning ongoing cyber events or activities with the potential to impact critical infrastructure computing networks. An advisory contains information from the researcher’s initial report, validation of the vulnerability, a description of the vulnerability including exploitation impact, and mitigations steps that asset owners can apply. ICS-CERT issues an advisory after the vulnerability coordination process has occurred. This means the researcher has contacted ICS-CERT before issuing a public notification of their findings.

This is followed by their description of an ‘alert’:

“ICS-CERT intends for its alerts to provide timely notification to critical infrastructure owners and operators concerning threats or activity with the potential to impact critical infrastructure computing networks. ICS-CERT produces alerts based on a vulnerability discovery and the vendor’s validation and uses them to rapidly disseminate information about a vulnerability that someone has publicly released without coordination.”

Interestingly there is no discussion of the publicly stated 45-day disclosure policy explicated on the ICS-CERT Vulnerability Disclosure Policy web page. That policy states:

“In cases where a vendor is unresponsive, or will not establish a reasonable timeframe for remediation, ICS-CERT may disclose vulnerabilities 45 days after the initial contact is made, regardless of the existence or availability of patches or workarounds from affected vendors.”

That 45-day time limit, according to the data provided in this new report shows that a ‘reasonable timeframe’ is based upon a very generous definition of ‘reasonable’. The report notes (pg 5) that in 2015 only 27% of the tickets opened for control system vulnerabilities were resolved in 50 days and 29% were not resolved by 200 days into the coordination process.

Coordination with Governments

The Executive Summary of this new document states that: “The goal of ICS-CERT is to reduce industrial control systems (ICS) risks within and across all critical infrastructure sectors by coordinating efforts among Federal, state, local, and tribal governments, as well as industrial control systems owners, operators, and vendors.” There are a number of instances where the coordination with owners, operators and vendors are discussed within this report.

There are no indications within the report that ICS-CERT is doing anything about coordinating efforts with ‘Federal, state, local, and tribal governments’ unless those governmental organizations are control system owners or operators. To be fair, I am not aware of any State, local or tribal government organizations that specifically deal with industrial control system security issues. The only organizations at that level that might need vulnerability information would be criminal investigators dealing with cyberattacks on industrial control systems. At this point I do not believe that there are any criminal investigators currently targeting ICS attacks.

On the Federal level there is a completely different issue. A number of Federal regulatory agencies are facing issues with control system security problems. The Food and Drug Administration (FDA), the National Highway Transportation Safety Administration (NHTSA) and the Federal Aviation Administration (FAA) immediately come to mind. It would have been nice to see some level of discussion of what efforts (if any, I suppose) that ICS-CERT is taking to support those organizations in their regulatory efforts in dealing with control system security issues.

Statistical Analysis

ICS-CERT has included a large amount of statistical information about vulnerability reporting, coordination and composition within this report. The information provided is valuable for people looking at changes in the industrial control system security environment over time. Unfortunately, that data presentation frequently makes that data analysis problematic.

One of my pet peeves in popular statistical analysis, for example, is the reporting of ‘average’ numbers and tracking changes in those ‘averages’ over time. Discussing changes in average without looking at the standard deviation (variation) associated with those averages destroys any confidence in the analysis. In this case the large variation in the number of vulnerabilities reported in Figure 7 (for instance) ensures that there is very likely a wide variation in standard deviations. That could easily mean that the ‘8.55’ average reported for 2010 is essentially the same number (the famous ‘within the margin of error’) as the ‘6.85’ average reported for 2015.

This is not a problem unique to this ICS-CERT report. It is very common in any popular reporting of changes in average values, particularly in reports from government agencies. Still, these types of statistical reporting errors greatly decrease the utility of the information being presented in this report.

ICS-CERT Publishes Siemens Advisory

Yesterday the DHS ICS-CERT published a new control system security advisory for products from Siemens. Two recently published Siemens updates have yet to be reported by ICS-CERT

Siemens SCALANCE Advisory

This advisory describes a web security vulnerability in the Siemens SCALANCE M-800 and S615 modules. The vulnerability was reported by Alexander Van Maele and Tijl Deneut from HOWEST (University College West Flanders). Siemens has produced a new firmware version, but there is no indication that the researchers were provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that the vulnerability is remotely exploitable, but that it would be difficult to develop an exploit that could allow an attacker in a privileged network position to obtain web session cookies under certain circumstances. The Siemens Security Advisory explains that an attacker would have to be in a privileged network position to obtain web session cookies under certain circumstances.

This vulnerability was publicly reported by Siemens last Thursday.

Recent Siemens Updates

Last week on the same day that Siemens announced their update for the vulnerabilities described above they also announced an update for their glibc vulnerability that ICS-CERT reported on in July. I had expected to see the ICS-CERT update their advisory yesterday.

Yesterday Siemens announced an additional update on multiple vulnerabilities in their SIMATIC WinCC, PCS 7 and WinCC Runtime Professional products. ICS-CERT initially reported on these vulnerabilities in April and updated the report in June and again in July. With this only being publicly reported by Siemens yesterday, it was probably too much to expect that ICS-CERT would also be updating their advisory on the same day.

Hopefully we will be seeing ICS-CERT updating these two advisories in the coming days.

ISCD Updates FAQ #1627 Again

Today the DHS Infrastructure Security Compliance Division (ISCD) published a new frequently asked question (FAQ) on their CFATS Knowledge Center. Actually, FAQ #1627 was first published in May 2009 and then it was updated in August of this year. So what’s going on?

I noticed a week ago Saturday that the reference to the most recent update to FAQ #1627 was missing from the CFATS Knowledge Center (I check for the most recent updates every day). A more detailed follow-up check showed that FAQ #1627 was completely missing from the database.

It seems that ISCD has been doing a detailed review of their FAQs to determine which FAQ responses will be affected by the implementation of CSAT 2.0 (a lot, I suspect). Some of those FAQs will have to be rewritten (oh boy, I’m not looking forward to that blog post), but some will no longer be relevant and those will be discarded.

Until a week ago last Saturday I was not aware of ISCD removing any FAQs from their lengthy list. If some have been deleted, they have not mentioned it. If some have been deleted there would not be a simple way of checking using the search function on CFATS Knowledge Center. Of course, the question is whether or not there is a reason to keep track of deleted FAQs?

On one hand, FAQs are not really official policy, they just reflect official policy. That’s one of the reasons that so many FAQs provide references back to official manuals and the CFATS regulations. That could easily mean that as policy changed (as reflected by official changes in manuals) that some FAQs became obsolete to the degree that it made no sense to update the response and those FAQs could/should be deleted.

On the other hand, some people are reading FAQs and, inevitably, some are making decisions about their CFATS implementation based upon those FAQ responses. They deserve to be notified when FAQs they may have relied upon have been deleted. I know the changes in the manuals should be enough notification (legally) but with the reputation that ISCD has worked so hard to build that they work closely with the regulated community argues that they should take the extra step and make specific notification of any deletions.

Oh, and some may have been deleted by mistake. You know, like FAQ #1627.

S 3379 Introduced – Transportation Security

Last week Sen. Thune (R,SD) introduced S 3379, the Surface Transportation and Maritime Security Act. The bill includes requirements for a number of GAO studies and TSA management reviews with the intent of increasing the TSA’s focus on surface transportation security issues. Only three of the provisions of the bill are likely to be of specific interest to readers of this blog:

Transportation Worker Identification Credential improvements and assessment;

Voluntary adoption of Transportation Worker Identification Credential; and

Background records checks for issuance of hazmat licenses.

TWIC Background Checks

Section 17(a) of the bill would require the DHS Secretary to “establish a process to improve background checks and terrorism vetting processes” {§17(a)(1)}. Those improvements are to include:

• Establishing an entity within the Office of Intelligence and Analysis to provide guidance on security threat assessment processes;

• Conducting a comprehensive risk analysis of the security threat assessment processes to identify areas needing additional internal controls and quality assurance procedures and implementing those procedures;

• Improving fraud detection techniques;

• Updating guidance and finalizing a manual for Trusted Agents and adjudicators to ensure clear guidance on processes and regulations; and

• Establishing quality controls to ensure consistent procedures to review adjudication decisions and terrorism vetting decisions.

The remainder of the section deals with requiring a comprehensive review of the Transportation Security Card Program by DHS. Once the review is conducted the bill would require DHS to provide a corrective action plan to Congress to correct any identified deficiencies. Then the Department Inspector General would be required to report to Congress on the implementation of that action plan.

CFATS and TWIC

Section 19 of the bill adds a new paragraph (c) to 6 USC 469. That section of the US Code deals with establishing fees for credentialing and background investigations. This amendment would establish that the phrase ‘individuals engaged in the field of transportation’ in §469 will include:

• Individuals required to obtain a transportation worker identification credential under section 101.514 of title 33, Code of Federal Regulations;

• Individuals required to obtain a hazardous materials endorsement on a commercial driver’s license issued by a State under section 5103a of title 49, United States Code; and

• Personnel at a facility that engages in loading, unloading, handling, or storage incidental to transportation who are subject to background checks under section 27.230(a)(12) of title 6, Code of Federal Regulations [Chemical Facility Anti-Terrorism Standards (CFATS) program].”.

HMI and TWIC

Section 21 of the bill amends 49 USC 5103a adding a new subparagraph (d)(3) specifying that an individual in possession of a Transportation Workers Identification Credential (TWIC) has met the “met the background records check required” for the hazardous materials indorsement (HMI) for a commercial driver’s license.

Moving Forward

Thune is the Chair of the Senate Commerce, Science and Transportation Committee, the Committee to which this bill was referred for consideration. He has bipartisan support in the leadership of that Committee from his four cosponsors {Sen. Nelson(D-FL), Sen. Fischer (R-NE), Sen. Booker (D-NJ), and Sen. Blumenthal (D-CT)}. This bill will almost certainly move forward in the lame duck session. If it gets to the floor of the Senate (problematic depending on how much push Thune puts behind the bill) it would probably pass under the Senate unanimous consent process.

Commentary

I noted in my earlier post on this bill that it was unusual that the bill was not also referred to the Senate Homeland Security and Governmental Affairs Committee. I’m pretty sure that this was done to avoid any delays in getting the bill considered on the Senate floor and not for petty inter-committee politics.

That is probably the reason that the CFATS and TWIC section of this bill was so ineffectually done. In amending 6 USC 469 this bill almost certainly would have no actual effect on the TWIC process. The bill should have amended 49 USC 70105(b)(2); that paragraph deals with who should be issued a TWIC. The current amendment would not change that.

This is an issue since Congress passed the Protecting and Securing Chemical Facilities from Terrorist Attacks Act (PL 113-254) specifically authorizing the use of the TWIC as a part of the personnel surety program. With the TWIC only authorized for transportation personnel working in and around US ports, this only solved part of the problem. If chemical facility workers (not working at a facility covered under the Maritime Transportation Security Act) were authorized to apply for a TWIC, the CFATS covered facilities could require their employees to get TWICs and ease a bunch of the paperwork burden of the CFATS Personnel Surety Program (PSP).

The fact that requiring employees to pay the TWIC registration fee passes the cost of personnel surety to the employees is frequently overlooked in Congressional conversations about TWIC and CFATS. I suppose that companies could be expected to reimburse employees for the expense (and some certainly would), but that has not come up in any of the talks that I have heard about TWIC and CFATS.

It is disappointing that this bill was introduced so late in the session. Many of the issues addressed (ineffectually to be sure) in this bill have been on the Congressional radar for a number of years. There have been a number of transportation related bills that could have included these inoffensive, bipartisan-supported measures. Instead they were cobbled into a bill that really has little chance to reach the President’s desk because of the politics of the end-of-session in a Presidential election year.

House Passes HR 5459 - Cyber Preparedness Act of 2015

This afternoon the House passed HR 5459, the Cyber Preparedness Act of 2015 by a voice vote after only ten minutes of debate under the House suspension of the rules process. The bill makes minor revisions to the Homeland Security Act of 2002 to enhance cybersecurity information sharing and makes enhancing cybersecurity an allowable use of DHS grants under the Urban Area Security Initiative and State Homeland Security Grant Program.

As I have noted in earlier blog posts, this bill continues to use an IT-limited definition of ‘cybersecurity risk’ that does not include industrial control systems. That does not mean that DHS cannot share ICS cybersecurity risk information with fusion centers, it is just not required to share that information.

If this bill is taken up by the Senate (not guaranteed by any stretch of the imagination this late in the session in an election year) it will probably be considered (and passed) under their ‘unanimous consent’ process that does not provide any opportunity for amendments on the floor.

NHTSA Publishes Automated Safety Technologies Guidance

Yesterday the DOT’s National Highway and Transportation Safety Administration (NHTSA) published an enforcement guidance document in the Federal Register (81 FR 65706-65709) concerning Safety-Related Defects and Automated Safety Technologies. This is in addition to the recently published Federal Automated Vehicles Policy document published earlier this week.

Legal and Policy Background

The new enforcement guidance document outlines the legal and policy background that provides the authority of NHTSA to regulate safety in current and emerging automated motor vehicle safety technologies. An important component of the NHTSA policy is the statement that:

“For software or other electronic systems, for example, when the engineering or root cause of the hazard is known, a defect exists regardless of whether there have been any actual performance failures.”

Addressing the need for recalls to address software related safety issues, the new guidance document provides the following discussion:

“Software installed in or on a motor vehicle—which is motor vehicle equipment—presents its own unique safety risks. Because software often interacts with a motor vehicle's critical systems (i.e., systems encompassing critical control functions such as braking, steering, or acceleration), the operation of those systems can be substantially altered by after-market software updates. Software located outside the motor vehicle could also be used to affect and control a motor vehicle's critical systems.^[4] Under either circumstance, if software (whether or not it purports to have a safety-related purpose) creates or introduces an unreasonable safety risk to motor vehicle systems, then that safety risk constitutes a defect compelling a recall.”

Policy Guidance

The only specific guidance provided in the document is found in the next to last paragraph:

“Motor vehicle and motor vehicle equipment manufacturers have a continuing obligation to proactively identify safety concerns and mitigate the risks of harm. If a manufacturer discovers or is otherwise made aware of any safety-related defects, noncompliances, or other safety risks after the vehicle and/or equipment (including automated safety technology) has been in safe operation, then it should promptly contact the appropriate NHTSA personnel to determine the necessary next steps. Where a manufacturer fails to adequately address a safety concern, NHTSA, when appropriate, will address that failure through its enforcement authority.”

Commentary

Anyone that is looking for specific guidance from NHTSA on how manufacturers (both vehicle and equipment) are going to be expected to ensure that their vehicle control systems are protected from cyber-attack are going to be sorely disappointed in this document. In fact, the guidance does not specifically address security issues related to software or control systems.

Having said that, it is clear from the portions of the document quoted above that NHTSA is planning on taking a broad approach as to what constitutes a ‘safety defect’ when it comes to vehicle automation systems. It would be hard to argue that security defects that would allow an attacker to affect, or even access, control systems that affect the safe operation of the vehicle would not be addressed by this approach.

The real defect in this guidance is the failure to address how NHTSA could expect to receive vehicle automation defect information other than from the manufacturer. The failure to establish a system for independent security researchers to report security defects in the software, hardware or firmware of vehicle automation systems directly to NHTSA (or another government agency like ICS-CERT) is understandable only in that this guidance document is directed at vehicle and equipment manufacturers. Not mentioning that receiving such information, however, would be an important part of the analysis and enforcement process is unforgivable.

Hopefully, this guidance document will not be the last word from NHTSA on the issue of vehicle control system safety. The failure to specifically address automation system security in this guidance document or the earlier performance guidance document could mean that NHTSA is intending to specifically address that area in a separate document. Or, more likely in my opinion, NHTSA continues to skirt the security issue because of a lack of specific congressional authority to address the matter.

Bills Introduced – 09-22-16

Yesterday with both the House and Senate in session there were 73 bills introduced reflecting the impending (if currently unknown date) shutdown of Congress for the remainder of the election season. Most of the bills introduced yesterday (and for the remainder of the month) are re-election tools not real attempts to enact legislation. Of those bills three may be of specific interest to readers of this blog:

HR 6116 To enable needed drinking water standards, reduce lead in drinking water, plan for and address threats from climate change, terrorism, and source water contamination, invest in drinking water infrastructure, increase compliance with drinking water standards, foster greater community right to know about drinking water quality, and promote technological solutions for drinking water challenges. Rep. Pallone, Frank, Jr. [D-NJ-6]

HR 6121 To amend the Safe Drinking Water Act with respect to climate resiliency, security, and source water protection planning, and for other purposes. Rep. Capps, Lois [D-CA-24]

HR 6134 To establish a National TechCorps program, and for other purposes. Rep. Bera, Ami [D-CA-7]

HR 6116 and HR 6121 are only two of a number of bills about public water systems, but they are the only two to specifically mention ‘security’ in their description blurb. I will specifically be watching these two for chemical security or cybersecurity measures, but I’m not holding my breath.

The National TechCorps will only be of interest hear if it specifically deals with cybersecurity matters.

DHS Announces PNT Study

Yesterday the DHS Science and Technology Directorate (S&T) and DHS National Protection and Programs Directorate (NPPD published a brief notice in the Federal Register (81 FR 65390) announcing a study to define and validate current and future positioning, navigation, and timing (PNT) requirements for critical infrastructure. The requirements defined and validated by the study will support key decisions in the development of complementary PNT solutions.

The announcement notes that:

“Accurate PNT is essential for critical infrastructures across the country. Currently, the Global Positioning System (GPS) is the primary source of PNT information. However, GPS signals are susceptible to both unintentional and intentional disruption leaving critical infrastructure vulnerable to operational impacts from disruptions. Due to the essential need for precise timing within many of the critical infrastructure sectors, DHS will initially focus the study on timing requirements within the electricity and wireless communications sectors. Subsequently, DHS will engage additional sectors and expand the study to include positioning and navigation requirements.”

DHS is currently soliciting participants in the electricity and wireless communications sector. Interested parties should contact John Dragseth, NPPD, DHS, John.Dragseth@dhs.gov, 703-235-9467; or Sarah Mahmood, S&T, DHS, Sarah.Mahmood@hq.dhs.gov, 202-254-6721.

Bills Introduced – 9-21-17

Yesterday with both the House and Senate in session there were 44 bills introduced. Of those, one may be of specific interest to readers of this blog:

S 3379 A bill to improve surface transportation and maritime security. Sen. Thune, John [R-SD]

It is interesting that this bill was only referred to Thune’s Commerce, Science and Transportation Committee and not the Homeland Security and Government Affairs Committee. According to a Committee press release:

“The legislation addresses deficiencies in the Transportation Security Administration’s (TSA) efforts to protect rail, transit, highway, and maritime passenger and freight transportation identified through congressional oversight and a recent report by the Department of Homeland Security inspector general.”

The details of this bill will be interesting, but it will be unlikely for the bill to get through both the Senate and House before the end of the session in December.

Reader Comment – Defense in Depth

Last night Dave Kuipers, a long-time member of the ICS cybersecurity team at Idaho National Labs, posted a comment to my blog post about the recent update of the ICS-CERT defense in depth paper. His lengthy comment provides some additional background information about how the team at INL considered the use of safety systems and operator response as part of the ICS defense in depth strategy. His comment is thoughtful and well worth reading.

I am a little concerned with the comment about ‘throwing out the baby with the bathwater’ that was included in his response because it would seem to indicate that the points that I was trying to make in my post may have been misunderstood. And I need to address my side of that communication problem.

First, I obviously did not make clear enough that I was not disparaging the technical aspects of the lengthy and well thought out paper. Defense in depth is the only way that an organization can have any hope of defending any sort of computer based system, particularly industrial control systems. I did not address the technical merits of the paper in my blog post because I do not have the technical background to do more than address the highlights. Those technical merits should be addressed by control system security experts.

My post addressed what thought was an insufficient level of attention to another area of the defense of system that uses the control system, safety systems and operator response. To be fair, this is not actually a cybersecurity defense, it is more appropriately a defense of the higher level system of which the ICS is an important component. As such, in hind sight, Dave’s comments are really appropriate.

In the ICS security community there is a great deal of deserved attention paid to the security aspects of the control system components. This is very important and certainly worthwhile. This technical focus, however, leads to a very distressing picture of the security of the businesses that rely on the use of industrial control systems. The history of poor security design and integration of control systems has left us with a legacy of systems that have porous security at best leaving industry with little hope of security for their systems in the foreseeable future.

People need to remember, however, and I would like to see ICS-CERT be more active in spreading this word, that industrial control systems do not operate in a vacuum. While connecting ICS to business systems have made the control systems arguably more vulnerable, other business processes help mitigate some of those vulnerabilities. If the control system security committee feels free to bemoan the decreased security that accompanies business system linkage, they also need to acknowledge and work with the business processes that help protect against the worst consequences of cyber insecurity. Safety systems and operator training are two of those processes that deserve mention, consideration and integration into control system security planning. This would add yet another dimension to defense in depth.

Bills Introduced – 9-20-16

I had to go back and re-look at Tuesday’s bill introductions as only six resolutions were listed when I checked Congress.gov yesterday. Sure enough there were 44 bills introduced in the House and Senate on Tuesday. Of those, only two may be of specific interest to readers of this blog:

HR 6071 Making continuing appropriations for fiscal year 2017, and for other purposes. Rep. Flores, Bill [R-TX-17] 

HR 6073 To direct the Secretary of Homeland Security to conduct research and development to mitigate the consequences of threats to voting systems, to amend the Help America Vote Act of 2002 to require the voting systems used in elections for Federal office to comply with national standards developed by the National Institute of Standards and Technology for operational security and ballot verification, to establish programs to promote research in innovative voting system technologies, and for other purposes. Rep. Johnson, Henry C. "Hank," Jr. [D-GA-4]

It will be interesting to see if HR 6071 or HR 5325 (the Senate ‘vehicle’ for the FY 2017 interim funding) will become the legislation used to continue operation of the Federal government through the start of the next fiscal year. Since we no longer have to worry about the year-to-year extension of the CFATS program, I probably will not be doing the in-depth coverage of the interim spending bill that I have done in years past, unless of course it contains some language of specific interest.

HR 6073 is really an IT cybersecurity bill, but I thought I would at least mention it in passing. It is unlikely to gain traction because of the states’ rights aspect of control of the election mechanism. I suspect that after the almost inevitable charges of election hacking that will arise out of November’s election, that this topic will arise again in the next Congress.

ICS-CERT Publishes Moxa Advisory

Today the DHS ICS-CERT published a control system security advisory for an unquoted service path escalation vulnerability in Moxa’s Active OPC Server application. The vulnerability was reported by Zhou Yu. Moxa has produced a new version to mitigate the vulnerability. ICS-CERT reports that Yu has verified the efficacy of the fix.

ICS-CERT reports that a relatively low skilled attacker with local access and network credentials could exploit this vulnerability to allow an authorized but non-privileged local user to execute arbitrary code with elevated privileges on the system.

Bills Introduced – 09-19-16

With both the House and Senate in session yesterday there were six bills introduced. Only one of those may be of specific interest to readers of this blog:

HR 6066 To enforce Federal cybersecurity responsibility and accountability. Rep. Abraham, Ralph Lee [R-LA-5]

This bill is being marked up in Committee tomorrow. A committee print of the bill is available. This bill deals with federal IT security and responsibilities for that security. There will not be further coverage of the bill in this blog.

ICS-CERT Publishes BINOM3 Alert

Yesterday the DHS ICS-CERT published an alert for publicly disclosed control system vulnerabilities in the BINOM3 Electric Power Quality Meter. The vulnerabilities had previously been disclosed to ICS-CERT by Karn Ganeshen, but ICS-CERT has not been able to get a response from BINOM3 about the vulnerabilities.

The reported vulnerabilities include:

• Reflected and stored Cross-site Scripting;

• Clear Text Passwords;

• Sensitive information leakage in GET request; and

• Access Control Issues

These are the same vulnerabilities that I reported on Saturday.

Tannerite® and Terrorism

The bombs used in an apparent terror attack in New York City this weekend reportedly (see for example) [corrected link - 08-12-19 0740] contained residue of a material similar to Tannerite®, a mixture of ammonium nitrate and aluminum powder. This first use of this material in a successful improvised explosive device (IED) demonstrate the problems that will be faced by the DHS contracted study on reducing the threat of IED by limiting access to explosive precursor chemicals.

Tannerite explosive targets are currently available without any legal controls. Tannerite-like explosives can be easily made by anyone with access to ammonium nitrate and aluminum powder, neither of which currently have any restrictions on their sale. In fact, ammonium nitrate can be found in many commercially available cold packs and aluminum powder can be made by anyone with access to aluminum metal.

Congress tried to get DHS to regulate the sale of large quantities of ammonium nitrate, but coming up with cost effective regulations that would make access to the large quantities that were used in the Oklahoma Federal Building bombing has proven to be impossible. This is the reason that DHS has contracted with the Academies of Science to study possible controls on the supplies of IED precursors.

While making large-scale IEDs (truck bombs) may be possible to limit by controlling access to ammonium nitrate, the large number of chemicals that can be combined to make small-scale IEDs (pressure cooker bombs) ensure that the government will never be able to shut off the flow of commercial chemicals into these types of devices.

To feasibly restrict access to precursors to IEDs someone is going to have to decide where to set the size limit on IEDs; the size of an explosive device that makes it worthwhile to impose costly controls on the sale and distribution of the chemicals involved. We are not going to be able to stop the making of small IEDs through chemical sale controls without paralyzing legitimate chemical commerce.

HR 5459 Amended in Committee

Earlier this week the House Homeland Security Committee amended and approved HR 5459, the Cyber Preparedness Act of 2015. The amendment made a number of relatively minor changes to the requirements for sharing cybersecurity information with fusion centers. The most important change was to add a definition of ‘cybersecurity risk’, adopting the language of 6 USC 148(a)(1). As I noted earlier, this definition does not include control systems.

Unfortunately, the way that that definition was added to the bill does not extend that definition to the expansion of authorized expenditures for grants under the Urban Area Security Initiative and State Homeland Security Grant Program. This may be less important than the addition of the definition earlier in the bill because DHS has a certain amount of leeway in how they disperse grants under these programs.

This bill is currently scheduled for consideration under suspension of the rules this Wednesday. It will likely pass with substantial bipartisan support. The big question facing this bill is whether or not it will be taken up by the Senate. This late in the session, it is likely that the only way this bill would come to the floor would be through the unanimous consent process. That would mean that there would be no further chances to amend this bill before it is sent to the President.

Public ICS Vulnerability Disclosure – 09-10-16

This week there was one public disclosure of an industrial control system on the Full Disclosure mailing list. Karn Ganeshen reported a number of vulnerabilities in the BINOM3 Electric Power Quality Meter. Karn reports submitting a vulnerability notification to ICS-CERT on May 25^th, 2016, noting that there has been no reply from the Russian vendor to date.

The reported vulnerabilities include:

• Reflected cross-site scripting;

• Stored cross-site scripting;

• Weak credentials;

• Undocumented root account;

• Sensitive information stored in clear text;

• Vulnerable to cross-site request forgery;

• Sensitive data leakage; and

• Access control issues

With their 45-day non-response disclosure policy it seems odd that ICS-CERT has not issued an advisory on this vulnerability.

ICS-CERT Publishes 4 Advisories

Yesterday the DHS ICS-CERT published four new control system security advisories for products from Rockwell, Trane, ABB and Yokogawa. The Rockwell advisory had previously been published on the US CERT Secure Portal back on August 11^th.

Rockwell Advisory  

This advisory describes a parser buffer overflow vulnerability in the Rockwell RSLogix 500 and RSLogix Micro products. The vulnerability was reported by Ariele Caltabiano (kimiya) via the Zero Day Initiative (ZDI). Rockwell has produced an update that mitigates the vulnerability but there is no indication that kimiya has been provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that it would be relatively easy to create an exploit that would allow malicious code to execute on the target computer at the same privilege level as the logged-in user. They also report that a social engineering attack would be required to cause an operator to load and execute the malformed RSS file.

Trane Advisory  

This advisory describes an information exposure vulnerability in the Trane Tracer SC field panel. The vulnerability was reported by Maxim Rupp. Trane has produced an update to mitigate this vulnerability and ICS-CERT reports that Maxim Rupp has verified the efficacy of the fix.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit this vulnerability to obtain sensitive information from the contents of configuration files not protected by the web server.

ABB Advisory  

This advisory describes a credential management vulnerability in the ABB DataManagerPro application. The vulnerability was reported by Andrea Micalizzi via ZDI. ABB has produced a new version to mitigate the vulnerability, but there is no indication that Micalizzi has been afforded an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively unskilled attacker with local system access could exploit the vulnerability to insert and run arbitrary code on a computer where the affected product is used. The ABB Security Advisory reports that an “attacker that manages to get malicious code to a specific directory in the file system of a computer where DataManagerPro is used, could get this code executed by an authenticated and legitimate user of DataManagerPro”.

Yokogawa Advisory

This advisory describes an authentication bypass vulnerability in the Yokogawa STARDOM controller. This vulnerability is apparently being self-reported. Yokogawa has produced a new version that mitigates the vulnerability. The Yokogawa Security Advisory reports that the STARDOM controller does not require authentication to connect to the device.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit this vulnerability to execute commands such as stop application program, change values, and modify application.

Cybersecurity for Building Control Systems

ICS-CERT reported that the National Institute of Building Sciences will be holding a series of workshops in Arlington, VA on cybersecurity for building control systems. The ICS-CERT announcement does not provide much in the way of support details (Date, location, cost, etc) but the provided web link to the NIBS workshop site does provide all of the necessary details.

ISCD Makes SVA 2.0 Webinar Available

Today the DHS Infrastructure Security Compliance Division (ISCD) updated their earlier notice  about the CSAT 2.0 webinars that were held last week. In addition to providing links to the CSAT 2.0 Portal and CSAT 2.0 Top-Screen demonstration the revised notice on the CFATS Knowledge Center now includes a link to the CSAT 2.0 Security Vulnerability Assessment – Site Security Plan demonstration.

ISCD has not yet released new manuals for any CSAT 2.0 tool other than the new Top Screen manual.

HR 5786 Introduced – Rail Spill Fund

Back in July Rep. DeFazio (D,OR) introduced HR 5786, the Community Protection and Preparedness Act of 2016. The bill would establish a Rail Account within the Oil Spill Liability Trust Fund as well require actions by the DOT’s Federal Railroad Administration to improve the track inspection process.

Rail Account

Section 2 of the bill would add a new §5111 to 49 USC establishing a new Rail Account within the Oil Spill Liability Trust Fund established under  26 USC 9509. The account would be funded by a $1500 fee charged to each shipper who offers flammable liquids for transportation in DOT 111 or CPC-1232 rail cars that have not been upgraded to the DOT 117R standard. The fee would be charged for each rail car used in such service during the previous fiscal year.

The bill would authorize expenditures from the Rail Account for response activities related to a flammable liquid accident incident to rail transportation. It would also provide authority for the Secretary of Transportation to use the Rail Account funds to provide grants to State and local governments for planning for, and training for, emergency response activities related to such incidents.

Rail Track Inspection

Section 3 of the bill would require DOT to issue regulations requiring Class I railroads “to inspect all track where an accident or incident involving the transportation of flammable liquids or material poisonous or toxic by inhalation by rail could affect a high consequence area” {§3(a)}. The inspections would be required to be completed by foot and “periodically, by a gage restraint measurement system” {§3(b)(2)}. The Secretary would determine the frequency with which such inspections would be required.

Section 4 of the bill would authorize the expenditure of ‘such funds as may be necessary’ by the FRA to hire two additional track inspection specialists per region.

Moving Forward

Neither DeFazio nor his two co-sponsors are members of the House Transportation and Infrastructure Committee, so it is extremely unlikely that this bill would be considered by the Committee. Flammable liquid shippers would be expected to vigorously oppose this bill as would Class 1 railroads, so the bill would be unlikely to pass in committee even if considered.

Commentary

There have been a series of bills out of the Oregon congressional delegation recently concerning a Rail Account in the Oil Spill Liability Trust Fund (S 1175, HR 5762, and now this one). The only one that has even a remote chance of being considered in committee is the Senate bill and that has little chance of being considered on the floor of the Senate, especially this late in the session.

Both the Senate bill and the earlier House bill used an amendment to 26 USC 9509 (establishing the Trust Fund) to establish the Rail Account. This bill took a different approach and added the requirement to 49 USC instead of 26 USC. In the House this is important because it drastically reduced (from four for HR 5762 to one for this bill) the number of committees that would have to acquiesce to the bill being considered on the floor of the House. That is not much of an issue this year as the bill is not going to even be considered in committee. If the leadership of the House were to change next year (an admittedly outside chance) then such a change could make a difference in allowing the bill to come to the floor for a vote.

Markup Hearing for S 546, RESPONSE Act, Scheduled

Earlier this week (after my hearing schedule blog post) the House Transportation and Infrastructure Committee scheduled a markup hearing for a number of bills tomorrow. Of potential interest to readers of this blog is the markup of S 546, the Railroad Emergency Services Preparedness, Operational Needs, and Safety Evaluation (RESPONSE) Act of 2015. This bill, passed in the Senate on May 9^th under the Senate’s unanimous consent process. The bill is virtually identical to HR 1043 that has yet to be acted upon by any of the five subcommittees of the Transportation Committee to which it has been assigned for consideration.

There is one amendment currently published for consideration in tomorrow’s hearing. The amendment contains a number of minor wording and procedural changes that do not substantially affect the purpose of the bill, establishing a subcommittee of the existing National Advisory Council to look at topics related to improving emergency responder training and resource allocation for hazardous materials incidents involving railroads.

This bill will almost certainly be passed on a voice vote in tomorrow’s hearing.

NARA Publishes CUI Final Rule

Today the National Archives and Records Administration’s (NARA) Information Security Oversight Office (ISOO) published a final rule in the Federal Register (81 FR 63323-63347) to establish oversight regulations for a variety of federal controlled unclassified information (CUI) programs. The new regulation establishes policy (32 CFR 2002) for agencies on designating, safeguarding, disseminating, marking, decontrolling, and disposing of CUI, self-inspection and oversight requirements, and other facets of the Program. The effective date of this rule is November 14^th, 2016.

The notice of proposed rulemaking (NPRM) for this rule was published in May 2015. I did a series of blog posts on the provisions of that NPRM. There were only 14 comments filed in response to the NPMR, but they resulted in a number of changes made in the final rule. This final rule was approved by OMB on August 9^th.

This rulemaking was designed primarily to effect the CUI protection activities of federal agencies, but it also applies to all organizations (sources) that handle, possess, use, share, or receive CUI—or which operate, use, or have access to Federal information and information systems on behalf of an agency.

CUI Registry

Section 2002.10 requires that NARA (the CUI Executive Agency – CUI EA) establish a CUI Registry to act as “the authoritative central repository for all guidance, policy, instructions, and information on CUI” {§2002.10(a)(1). The CUI Registry has been established and among other things it provides the current list of non-classified information protection programs covered under this regulation. Those programs include such critical infrastructure programs as:

• Ammonium Nitrate

• Chemical-terrorism Vulnerability Information*

• Critical Energy Infrastructure Information

• DoD Critical Infrastructure Security Information

• Physical Security*

• Protected Critical Infrastructure Information*

• Water Assessments

The programs marked with an asterisk (*) identify those programs that are codified in the U.S. Code, Code of Federal Regulations, or as a Government-wide policy. This is an important distinction for this regulation. The regulation sets minimum standards for CUI Basic programs, programs while the codifying documents for the CUI Specified programs set program standards that do not conflict with the minimum requirements of the CUI regulations. If existing CUI Specified programs do not meet the minimum security standards set forth in this rule, the programs will have to be updated to come into compliance.

NIST SP 800-171

Federal agencies holding CUI on computer systems are required to conform with the computer system requirements of FIPS Pub 199 at no less than the moderate confidentiality impact level {§2002.14(g)}. For non-federal information systems the computer security standard that must be applied is NIST SP 800-171{§2002.14(h)(2)} for systems used to process, store or transmit CUI.

Commentary

Most private sector organizations are not going to be required to process, store or transmit CUI. With one major exception, CUI information will generally be information that federal agencies will have received from non-federal agencies (including private sector companies). The CUI designation is being used to protect the information while in federal control. Security information that is subsequently shared by the federal agency may have CUI designations to protect the source of the information from public disclosure.

The one major exception is the Chemical-terrorism Vulnerability Information (CVI) program administered under the Chemical Facility Anti-Terrorism Facility Standards (CFATS) program. Again the basis of the CVI (a CUI designation) protections is CFATS security information (Top Screens, Security Vulnerability Assessments and Site Security Plans for instance) being shared by private sector entities to a government agency (DHS Infrastructure Security Compliance Division – ISCD). The CFATS regulations, however, require the originating facility to protect the information using the procedures set forth in the CVI Procedures Manual.

The CVI program is a listed CUI Specific program, so where ever the current CVI procedures meet or exceed the requirements for storage, marking, transmission, sharing, declassifying or destroying the CVI information, no change in the CVI program will be required. The one obvious area where the CVI program does not meet the CUI program requirements is in specifying the NIST 800-171 standard for computer systems used to handle CVI information. Other minor changes may also be necessary.

Bills Introduced – 09-13-16

With both the House and Senate in session there were 39 bills introduced yesterday. Of those only one may be of specific interest to readers of this blog:

HR 6002 To provide for the acquisition and publication of data relating to cybercrimes against individuals, and for other purposes. Rep. Clark, Katherine M. [D-MA-5]

Future coverage of this bill in this blog will depend on how expansive the definition of ‘individuals’ is and what the ‘other purposes’ may be.

ICS-CERT Defense-in-Depth Paper Updated

Today the DHS ICS-CERT published a notice on their web site that they have updated one of their Reference Practice documents; “Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies”. The original document was written in 2009 and this update reflects (according to the official abstract) changes in control systems management, security practices, and change management within the ICS community.

I was not closely following ICS-CERT when the original document was published. I did run into it a number of years later, but did not save a copy of the document because it was clearly dated. This means that I do not have any reasonable expectation that I can write about the changes in the document. That means that I’ll have to deal with it only in its current form.

Real Brief Overview

Both the abstract and the Executive Summary from the actual document provide describe the organization of the revised documents this way:

“Background and Overview” outlines the current state of ICS cybersecurity and provides an overview of what defense in depth means in a control system context;

“ICS Defense-in-Depth Strategies” provides strategies for securing control system environments;

“Security Attacks” outlines how threat actors could carry out attacks against critical infrastructures and the potential impact to ICSs and networks; and

“Recommendations for Securing ICS” provides resources for securing ICSs based on the current state-of-the-art methods and lessons learned from ICS-CERT activities, national and sector-specific standards for ICS security, and tools and services available through ICS-CERT and others that can be used to improve the security posture of ICS environments.

Remember the Objective of ICS Security

I’ll leave a review of the most of the technical aspects of the document to those with the appropriate background in implementing cybersecurity techniques. What I am more concerned about is what is lacking from this discussion; an appreciation that industrial control systems are really only potential targets of attack because of the industrial process which they control. This document mentions this a couple of times in passing (for instance in section 2.2.5 where it states “…or if the ICS controls a process with potential human safety consequences, it may

require special consideration and additional controls.”), but the document fails to address the consequence of this fact of life.

Specifically, it fails to address the fact that the first step in any risk assessment of the security of an industrial control system needs to start with a review of the process being controlled and the consequences of a loss of control or even a loss of view of that process. The level of risk for an ICS that controls the manufacture of widgets, is much less than one that controls the use, storage or manufacture of toxic inhalation hazard chemicals, which is different than one that controls high-speed passenger rail traffic on a high-profile transportation corridor.

Failure to take into account the consequences of a successful attack on a control system means that any cost/benefit analysis of the risk versus the cost of ‘adequate security’ will be grossly misestimated. It is also very likely to lead to a misunderstanding of which controls are actually critical controls that may need additional security protections.

Safety Controls in Defense-in-Depth

The other area where a lack of appreciation of the actual purpose of industrial control systems is found in the discussion of different types of defenses that can be used in a defense-in-depth system. Where ever the loss of control or loss of view of a process can lead to safety concerns for facility personnel or, even more importantly, off-site personnel, an important part of the defense-in-depth process has got to be safety controls that are not part of the industrial control system that may be attacked.

The successful design, application and implementation of these safety controls may go a long way to mitigate a successful attack on the control system. A clear understanding of the design basis for the safety controls and the degree of their integration with or in the industrial control system is absolutely necessary for the proper assessment of the risk of a successful attack on a control system and the proper design and implementation of an effective defense-in-depth strategy.

Probably the most important safety control in many process environments is the skill and knowledge of the operators that oversee the functioning of the process being controlled by the industrial control system. Ensuring that operators have skill and experience to identify non-standard operating excursions (and the methods of identifying those excursions outside of the possibly vulnerable control system) and the ability to assume enough process control without using a compromised ICS to avoid the worst safety consequences of loss of control via the ICS is another defense-in-depth strategy that is missing from the discussion in this document.

Need to Expand the Parochial View of ICS Security

We must at all times remember that industrial control systems (except in honey pots) do not exist in a vacuum. They exist to control an actual physical process. An understanding of that process, and the consequences of that process being upset, must inform all decisions about the security of the industrial control system.

For example, if in a chemical manufacturing facility, we only have one isolatable process that could have significant off-site consequences if we lose control or view of the control system for that process, we should certainly take a long, hard look at making a separate Cell Security Zone (see page 19) for the devices monitoring and controlling that process to build-in an additional layer in the defense of the devices controlling that process.

Now I understand that ICS-CERT is first and foremost a cybersecurity organization focused on industrial control systems. They do not have the expertise in the wide variety of process that may be controlled by such systems, so it is easy for them to overlook that additional level of complexity in looking at cybersecurity for control systems. But, they really do need to ensure that they learn the absolute necessity for including process safety (consequence) analysis in any discussion of analyzing control system security or designing an effective defense-in-depth cybersecurity plan.

Failure to include such process analysis will inevitably mean that security controls will be focused on the wrong things, allowing an attacker a better opportunity to create a successful attack. Or, maybe actually inadvertently decrease the effectiveness of the safety controls and thus end up making the process less safe. Either way, the affected organization could find itself cybersecuritied into a reduced safety environment.