Bills Introduced – 02-27-18

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

HR 5099 To amend the Homeland Security Act of 2002 to establish in the Department of Homeland Security a fusion center technical assistance program. Rep. Estes, Ron [R-KS-4]

HR 5131 To improve the effectiveness of Federal efforts to identify and address homeland security risks to surface transportation, secure against vehicle-based attacks, and conduct a feasibility assessment of introducing new security technologies and measures, and for other purposes. Rep. Watson Coleman, Bonnie [D-NJ-12] 

I will be watching HR 5099 to see if it includes specific cybersecurity requirements, particularly for industrial control system security issues.

I will be watching HR 5131 for chemical transportation security issues.

ICS-CERT Publishes 5 Advisories and 5 Siemens Updates

Yesterday the DHS ICS-CERT published two medical device security advisories for products from Philips and Medtronic. They published three industrial control system security advisories for products from Emerson, Delta Electronics and Siemens. They also updated five previously published control system security advisories for a variety of products from Siemens.

NOTE: The Siemens advisory and five updates were briefly mentioned here last week. There was another advisory and another update (both 3^rd party vendor problems affecting Siemens products) that Siemens announced at the same time that ICS-CERT has apparently decided not to address.

ICS-CERT also recently announced a call for abstracts for the Spring 2018 meeting of the ICSJWG in Albuquerque, NM on April 10 - 12, 2018. Abstracts need to be submitted by March 13^th, 2018.

Philips Advisory

This advisory describes a relatively large number of vulnerabilities in the Philips Intellispace Portal ISP visualization and image analysis system. The vulnerabilities are apparently being self-reported. There is no report about these vulnerabilities on the FDA medical device safety page. Philips will be issuing an updated version in the coming months to mitigate the vulnerabilities.

NOTE: Apparently at least some of these vulnerabilities are 3^rd party vendor issues that have seen publicly available exploits in other products.

The 35 reported vulnerabilities include:

• Improper input validation (13) - CVE-2018-5474, CVE-2017-0143, CVE-2017-0144, CVE-2017-0145, CVE-2017-0146, CVE-2017-0148, CVE-2017-0272, CVE-2017-0277, CVE-2017-0278, CVE-2017-0279, CVE-2017-0269, CVE-2017-0273, and CVE-2017-0280;

• Information exposure (8) - CVE-2017-0147, CVE-2017-0267, CVE-2017-0268, CVE-2017-0270, CVE-2017-0271, CVE-2017-0274, CVE-2017-0275, and CVE-2017-0276;

• Permissions, privileges and access controls (4) - CVE-2018-5472, CVE-2018-5468, CVE-2017-0199, and CVE-2005-1794;

• Unquoted search path element - CVE-2018-5470;

• Left over debug code - CVE-2018-5454; and

• Cryptographic issues (8) - CVE-2018-5458, CVE-2018-5462, CVE-2018-5464, CVE-2018-5466, CVE-2011-3389, CVE-2004-2761, CVE-2014-3566, and CVE-2016-2183

ICS-CERT reports that an uncharacterized attacker could remotely exploit these vulnerabilities  to gain unauthorized access to sensitive information, perform man-in-the-middle attacks, create denial of service conditions, or execute arbitrary code.

Medtronic Advisory

This advisory describes two vulnerabilities in the Medtronic 2090 CareLink Programmers. The vulnerabilities were reported by Billy Rios and Jonathan Butts of Whitescope LLC. There is no report about these vulnerabilities on the FDA medical device safety page. Medtronics has identified compensating controls that mitigate the vulnerability. There is no indication that the researchers have been provided an opportunity to verify the efficacy of the fix.

The two reported vulnerabilities are:

• Strong password in a recoverable format - CVE-2018-5446; and

• Relative path traversal - CVE-2018-5448

ICS-CERT reports that an uncharacterized attacker with access to a CareLink Programmer could exploit the vulnerability to obtain per-product credentials to the software deployment network. These credentials grant access to the software deployment network, but access is limited to read-only versions of device software applications. No write capability exists with the credentials.

Emerson Advisory

This advisory describes a stack-based buffer overflow vulnerability in the Emerson ControlWave Micro Process Automation Controller. The vulnerability was reported by Younes Dragoni of Nozomi Networks. Emerson has a new firmware version that mitigates the vulnerability. There is no indication that Dragoni has been provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively low-skilled attacker could remotely exploit the vulnerability to execute a denial of service attact.

Delta Advisory

This advisory describes three vulnerabilities in the Delta WPLSoft PLC programming software. The vulnerability was reported by Axt via the Zero Day Intitiative. The newest version of the software mitigates the vulnerability. There is no indication that Axt has been provided an opportunity to verify the efficacy of the fix.

The three reported vulnerabilities are:

• Stack-based buffer overflow - CVE-2018-7494;

• Heap-based buffer overflow - CVE-2018-7507; and

• Out-of-bounds write - CVE-2018-7509

ICS-CERT reports that a relatively low-skilled attacker could remotely exploit these vulnerabilities to allow remote code execution or cause the software the attacker is accessing to crash.

Siemens Advisory

This advisory describes a cryptographic vulnerability in the Siemens SIMATIC Industrial PCs. This is a 3^rd party vulnerability in RSA key generation allowing for a potential ROCA attack. The vulnerability is being self-reported by Siemens. Siemens has produced firmware updates that mitigate the vulnerability.

ICS-CERT reports that an uncharacterized attacker [probably pretty skilled IMO] could remotely exploit the vulnerability to conduct cryptographic attacks against the key material.

NOTE: This is going to be a widespread vulnerability, potentially affecting any control system using Infineon’s Trusted Platform Module for the generation of RSA keys. It is also another vulnerability that it would have been helpful if ICS-CERT had published an alert on the topic last fall.

SIMATIC Update

This update provides additional information on an advisory that was was originally published on May 9^th, 2017 and updated on June 15, 2017,on July 25^th, 2017, on August 17^th, 2017, on October 10^th, on November 14^th, November 28^th, and most recently January 18, 2018. The update adds five new vulnerabilities to the advisory:

• Improper restrictions of operations within the bounds of a memory buffer (3) - CVE-2017-12818, CVE-2017-12820, and CVE-2017-12821;

• Security features - CVE-2017-12819; and

• Improper access control - CVE-2017-12822

Industrial Products Update

This update provides additional information on an advisory that was originally published on December 5th, 2017 and updated on December 19th, 2017 and again on January 23^rd, 2018. The new information includes new affected version data and mitigation links for:

• SIMATIC ET 200MP IM155-5 PN ST: All versions prior to V4.1;

• SIMOTION P V4.4 and V4.5: All versions prior to V4.5 HF5;

• DK Standard Ethernet Controller: All versions prior to V4.1.1 Patch 05; and

• EK-ERTEC 200 PN IO: All versions prior to V4.5

PROFINET 1 Update

This update provides additional information on an advisory that was originally published on May 9^th, 2017 and updated on June 15, 2017,on July 25^th, 2017, on August 17^th, 2017, on October 10^th, 2017, November 14^th, 2017, and most recently on January 23^rd, 2018. The update provides updated affected version information and mitigation links for:

• SIMATIC WinCC flexible 2008: All versions prior to flexible 2008 SP5

PROFINET 2 Update

This update provides additional information on an advisory that was originally published on May 9^th, 2017 and updated on June 15, 2017,on July 25^th, 2017, on August 17^th, 2017, on October 10^th, on November 14^th,  November 28^th, 2017, and most recently January 18^th, 2018, and most recently on January 25^th, 2018. The new information includes new affected version data and mitigation links for:

• SIMATIC ET 200MP-IMI55-5 PN ST: All versions prior to V4.1

Ruggedcom Update

This update provides additional information on an advisory that was was originally published on September 28^th, 2017, and updated on October 17^th, 2017. The new information adds corrected version information and mitigation links for:

• SCALANCE XR-500/XM-400: All versions between v6.1 and 6.1.1; and

• SCALANCE XB-200/XC-200/XP-200/XR300-WG: All versions between v3.0 and v3.0.2

Committee Hearings – Week of 02-25-18

With both the House and Senate back in Washington this week there are a relatively small number of hearings being held on both sides of the Capitol. Two Senate hearings may be of specific interest to readers of this blog; DHS authorization markup and an oversight hearing looking at PTC implementation.

DHS Authorization

On Wednesday the Senate Homeland Security and Governmental Affairs Committee will hold a markup [.PDF download] of HR 2825, the DHS Authorization Act of 2017. The bill was passed in the House by a substantially bipartisan vote in July of last year. It is unusual that the Committee is taking up the bill without introducing a bill of its own, but the Senate has been busy with nominations and other ‘incidental’ business.

PTC Implementation

On Thursday the Senate Commerce, Science, and Transportation Committee will conduct an oversight hearing on the implementation of positive train control (PTC) technology by passenger railroads. The Committee asked for reports from both the GAO and the DOT Inspector General on the topic and both reports will be presented at this hearing. The witness list includes:

• Susan Fleming, Government Accountability Office;
• Barry J. DeWeese, Department of Transportation OIG;
• David L. Mayer, Metropolitan Transportation Authority; and
• Richard Anderson, Amtrak

S 2444 Introduced – Grid Security

Earlier this month Sen Cantwell (D,WA) introduced S 2444, the Energy Cybersecurity Act of 2018. It would require the Department of Energy to address electric grid cybersecurity, resiliency and risk assessment issues.

Cybersecurity

Section 3(a) would require the Secretary to address energy sector cybersecurity issues. It would require DOE to develop cybersecurity applications and technologies to {§3(a)(1)(A)}:

• Identify and mitigate vulnerabilities; and

• Advance the security of field devices and third-party control systems;

The vulnerabilities that are required to be addressed specifically include {§3(a)(1)(A)(i)}:

• Dependencies on other critical infrastructure; and

• Impacts from weather and fuel supply.

The security advances would specifically include devices and systems such as {§3(a)(1)(A)(ii)}:

• Systems for generation, transmission, distribution, end use, and market functions;

• Specific electric grid elements including advanced metering, demand response, distributed generation, and electricity storage;

• Forensic analysis of infected systems; and

• Secure communications

The bill would authorize the expenditure of $65 million per year through 2026 for these efforts.

Cyberresilience Testing

Section 3(b) of the bill would require the Secretary to develop a cyberresilience testing program “to identify vulnerabilities of energy sector supply chain products to known threats” {§3(b)(1)(A)}. The program would include oversight of third party cyber-testing and developing procurement guidelines for energy sector supply chain components. The bill would authorize the expenditure of $15 million per year for this program.

Cyberresilience Operational Support

Section 3(c) of the bill would allow the Secretary to carry out a program to {§3(c)(1)}:

• Enhance and periodically test the emergency response capabilities

 of the Department in coordination with other agencies, the National Laboratories, and private industry;

• Expand cooperation of the Department with the intelligence communities for energy sector-related threat collection and analysis;

• Enhance the tools of the Department and ES–ISAC for monitoring the status of the energy sector;

• Expand industry participation in ES–ISAC; and

• Provide technical assistance to small electric utilities for purposes of assessing cyber-maturity level.

The bill would authorize the expenditure of $10 million per year for these activities.

Energy Sector Infrastructure Risk

Section 3(d) of the bill would require the Secretary to “develop an advanced energy security program to secure energy networks, including electric, natural gas, and oil exploration, transmission, and delivery” {§3(d)(1)}. The goal of the program would be “to increase the functional preservation of the electric grid operations or natural gas and oil operations in the face of natural and human-made threats and hazards, including electric magnetic pulse and geomagnetic disturbances” {§3(d)(2)}.

To support this effort the Secretary would be allowed to {§3(d)(3)}:

• Develop capabilities to identify vulnerabilities and critical components that pose major risks to grid security if destroyed or impaired;

• Provide modeling at the national level to predict impacts from natural or human-made events;

• Develop a maturity model for physical security and cybersecurity;

• Conduct exercises and assessments to identify and mitigate vulnerabilities to the electric grid, including providing mitigation recommendations;

• Conduct research hardening solutions for critical components of the electric grid;

• Conduct research mitigation and recovery solutions for critical components of the electric grid; and

• Provide technical assistance to States and other entities for standards and risk analysis.

The bill would authorize the expenditure of $10 million per year to support these activities.

Moving Forward

Cantwell is the Ranking Member on the Senate Energy and Natural Resources Committee to which this bill was assigned for consideration. This would seem to indicate that she could have the necessary influence to see this bill considered by that Committee. The lack of a Republican co-sponsor, however, may indicate the lack of bipartisan support necessary to see the bill moved out of Committee.

The big stumbling block to moving this bill forward is the inclusion of funding authorization for the programs described in the bill. While the amounts authorized are small on the federal money scale, under Senate rules they would still have to come out of existing funding. If Cantwell can identify funding sources for this bill, it would make moving the bill forward much easier.

Commentary

Section 2 of the bill does provide definitions of some of the organization terms used in the bill, but it does not address any of the technical definitions of terms like ‘cybersecurity’ or ‘cyberresilience’. I suspect that this was done to provide the Secretary with the widest possible latitude in exercising authority under this legislation. Unfortunately, I think that this actually have the opposite effect; actually limiting what actions are taken.

As I am with most pieces of cybersecurity legislation that I review, I am disappointed that Cantwell (and her Committee Staff who actually crafted this bill) fails to address the role of independent security researchers in discovering vulnerabilities in software and devices. Section 3(b) of this bill would have been an excellent place to address this issue.

Instead of establishing a “cybertesting (sic) and mitigation program to identify vulnerabilities of energy sector supply chain products” the bill should have established an office in the DOE responsible for the identification and coordination of cyber-vulnerability mitigation in devices and applications used in the energy sector. While this is very similar to what ICS-CERT is currently doing on a voluntary basis for a much wider range of devices, a DOE-CERT would be given the specific responsibility to push vulnerability communications down to covered user-entities. Positive vendor responses to vulnerability identification could be ensured by DOE-CERT requiring covered user-entities to take specific compensatory measures when vendors cannot or will not mitigate vulnerabilities. A DOE-CERT could also provide support to the independent researcher community buy managing a DOE bug bounty program.

Finally, I would have liked to have seen this bill specifically address supporting {in §3(c)} National Guard cyber units in preparing for emergency response for cyber related grid emergencies. This would be particularly appropriate for grid emergencies that cross State boundaries. A DOE resiliency office could serve a coordinating office for multi-state planning and execution of responses to grid emergencies. This non-military coordination would provide political and legal cover for posse comitatus concerns.

Bills Introduced – 02-26-18

Yesterday, with both the House and Senate back in town after the long week off for President’s day, there were 21 bills introduced. Of those, two may be of specific interest to readers of this blog:

HR 5089 To improve threat information sharing, integrated operations, and law enforcement training for transportation security, and for other purposes. Rep. Barragan, Nanette Diaz [D-CA-44]

HR 5094 To direct the Secretary of Homeland Security to improve suspicious activity reporting to prevent acts of terrorism, and for other purposes. Rep. King, Peter T. [R-NY-2]

I will be watching HR 5089 for its potential effects on chemical transportation security.

While I suspect that HR 5094 will be very generic in scope, I will be watching it for potential impacts on chemical facility security and (a real remote possibility) cybersecurity.

Bills Introduced – 02-23-18

Last Friday, with the House and Senate meeting in pro forma session (almost all of the members were back in their districts), there were 9 bills introduced. Of those, two may be of specific interest to readers of this blog:

HR 5079 To amend the Homeland Security Act of 2002 to require the Department of Homeland Security to develop an engagement strategy with fusion centers, and for other purposes. Rep. Bacon, Don [R-NE-2]

HR 5081 To amend the Homeland Security Act of 2002 to establish within the Transportation Security Administration the Surface Transportation Security Advisory Committee, and for other purposes. Rep. Katko, John [R-NY-24]

I will be watching HR 5079 for the specific types of engagement being proposed to see if they might have an impact on information sharing in chemical security or cybersecurity areas.

HR 5081 will almost certainly be covered here for its potential impact on chemical transportation security activities.

EPA Publishes TSCA Fee NPRM

The Environmental Protection Agency (EPA) is publishing a notice of proposed rulemaking in the Monday edition of the Federal Register (83 FR 8212-8235) proposing user fees for the administration of the Toxic Substances Control Act. In accordance with 15 USC 2625(b) the rule proposes to establish fees to defray some of the Agency costs related to activities under TSCA sections 2604, 2605, 2606 and 2613 and establish a definition of ‘small business concern’ to be used for establishing lower fees as directed by Congress.

Agency TSCA Costs

Since under the revised 15 USC 2625(b)(4)(F) the EPA is required to set fees so as to defray the costs of administering the TSCA program, it must first establish those costs. The preamble discusses how the Agency came up with their annual program cost estimate of $80.2 million. Details are provided for how the cost estimates were made for §2604, §2605, §2606, and §2613.

It is interesting to note that the EPA is not considering in this NPRM to assess greater fees for submissions containing CBI claims.

Setting Fees

While the EPA is required to collect fees to defray not more than 25 percent of the costs to the Administrator for the administration of these four sections, the Administrator does have some leeway in establishing the specific fees for each section to reach that goal. In this NPRM the Agency is proposing to set specific fee levels for each of the covered activities with the aggregate amount collected reaching the total allowed 25%.

The table below shows the fees established by the revised 40 CFR 700.45 proposed in this NPRM.

Activity (40 CFR §)	Small Business	All Others
Premanufacturing Notice (§720)	$2,800	$16,000
Significant New Use (§721)	$2,800	$16,000
Exemption Application (§723.50 and §725)	$940	$4,700
Instant photographic film article exemption notice (§723.175)	$940	$4.700
Microbial commercial activity notice (§725)	$2,800	$16,000
Test rule	$1,960	$9,800
Test order	$5,900	$29,500
Enforceable Consent Agreement	$4,560	$22,800
EPA-initiated chemical risk evaluation	$270,000	$1,350,000
Manufacturer-requested risk evaluation of a Work Plan Chemical	NA	$1,300,000
Manufacturer-requested risk evaluation of a Non-Work Plan Chemical	NA	$2,600,000

Small Business Definition

In this NPRM the EPA is also proposing to update the definition of a ‘small business concern’ found at 40 CFR 700.43. They are adjusting the annual sales figure limit in the definition by applying an inflation correction to the current sales figure and using a three-year sales average instead of the latest sales figure. The new definition sets that average sales figure at $91 million.

Public Comment

The EPA is soliciting public comments on this NPRM. Comments may be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket # EPA-HQ-OPPT-2016-0401). Comments should be submitted before April 27^th, 2018.

CFATS PSP ICR Revision Comments – 02-24-18

Back in December the DHS Infrastructure Security Compliance Division (ISCD) published a 60-day information collection request revision notice for proposed changes to the personnel surety program (PSP) for the Chemical Facility Anti-Terrorism Standards (CFATS) program. Comments on the proposed extension of the anti-terrorist screening requirement to Tier III and Tier IV facilities were solicited. The first comments were received this week.

Comments were received from (links are .PDF downloads):

• The Chlorine Institute;

• The Fertilizer Institute; and

• The International Liquid Terminals Association

Rather than the general opposition to the PSP process that marked many industry comments on earlier iterations of the PSP ICR process, these three comments raised some interesting questions (and generally provided potential solutions) arising from the expansion of the PSP terrorist vetting program.

Some detailed questions were raised about the assumptions that were made by ISCD for calculating the average burden estimate. It would seem that ISCD has a better basis for making these estimates now that they have worked closely with Tier I and Tier II facilities in implementing the PSP submissions, but legitimate questions have been raised about differences between the types of facility included in the two different risk categories of facilities.

There close of the comment period is Monday, so there is a decent chance that there will be more comments posted to the www.Regulations.gov web site for this ICR. ISCD will take some amount of time to review the comments and address them as they determine appropriate. ISCD will then publish a 30-day ICR notice before sending the ICR to OMB for approval. It could still be six months to a year or more before OMB approves the expansion of the PSP terrorist screening process. And we have to remember that Congress will have a chance to weigh in on the process (again) when they (hopefully) reauthorize the CFATS program later this year.

Public ICS Disclosures – Week of 2-17-18

This week we have three vendor notifications of control system vulnerabilities from ABB and Schneider (2).

ABB Advisory

This advisory describes three vulnerabilities in the ABB CCLAS laboratory information management system. The vulnerabilities are self-reported. A new version is available that mitigates the vulnerabilities.

The reported vulnerabilities are:

• Path traversal (2); and

• Cross-site scripting

Flexera FlexNet Publisher Advisory

This advisory describes a buffer error vulnerability in a number of the Schneider products that use their Floating License Manager. The vulnerability was reported last summer by Flexera Software, the third-party vendor supporting this Schneider product. Schneider has new product versions that mitigates the vulnerability.

NOTE: As always with 3^rd party vulnerabilities, the open question is which other vendors have used the same vulnerable code in their products?

Saitel DP Advisory

This advisory describes a privilege escalation vulnerability in the Schneider Saitel DP substation controller. This 3^rd party vulnerability (Linux kernel) was reported in 2016 and there are multiple publicly available exploits for the underlying vulnerability. Schneider has a patch available to mitigate this vulnerability.

Commentary

Two 3^rd party vulnerabilities this week re-raise the question about what responsibility vendors have for both vetting 3^rd party code and monitoring for reports of vulnerability in that code. The license manager problem above easily be a positive example of responding to a reported vulnerability and the time lag between the initial vulnerability report and this weeks notification could be a reflection of how long it took to fix the problem.

The much longer delay in fixing the Linux kernel issue, however, argues that there was a significant delay between the original vulnerability discovery and the start of the Schneider response. While open source products like Linux do not have the same ability to push fixes to the field as large corporations like Microsoft, there is no doubt that the vibrant community does very openly discuss their vulnerabilities and fixes.

Vendors that are going to use 3^rd party code (and it looks like every vendor does) and are concerned about their customers’ secure use of their products (and that is obviously not every ICS vendor) are going to have to maintain an active monitoring of their code suppliers to ensure that the vendor becomes aware of reported vulnerabilities as soon as possible. Vendors then have a responsibility to check for those 3^rd party vulnerabilities in their own products as soon as possible.

Large ICS vendors should be able to use their size as leverage with their 3^rd party suppliers to require advance notification of vulnerabilities before they are publicly announced. This would allow them at least some time to begin working on analysis and fixing problems before the vulnerability is publicized.

S 2392 Introduced – Cybersecurity Technology

Earlier this month Sen. Daines (R,MT) introduced S 2392, the Cyber Support for Anti-Terrorism by Fostering Effective Technologies (Cyber SAFETY) Act of 2018. The bill would extend the protections of the SAFETY Act (6 USC 441 et seq) to cybersecurity technology in addition to the existing protections for anti-terrorism technology.

SAFETY Act Background

The DHS Science and Technology Directorate administers the SAFETY Act and describes it on their web site this way:

“The SAFETY Act provides incentives for the development and deployment of anti-terrorism technologies by creating systems of risk and litigation management. The purpose of the Act is to ensure that the threat of liability does not deter potential manufacturers or sellers of effective anti-terrorism technologies from developing and commercializing technologies that could save lives.”

After appropriate review of proposed technologies {see 6 USC 441(b)}, the Secretary certifies an anti-terrorism technology {“any product, equipment, service (including support services), device, or technology (including information technology) designed, developed, modified, or procured for the specific purpose of preventing, detecting, identifying, or deterring acts of terrorism or limiting the harm such acts might otherwise cause”; 6 USC 444(1)} as qualified anti-terrorism technology. When that qualified technology is employed in response to an act of terrorism, the seller/provider of that technology is provided some protections against 3^rd party liability claims resulting from the approved use of the technology.

Amendments to SAFETY Act

The bill would make a number of amendments to the existing language of the SAFETY Act. Most of those changes consist of adding the words “cybersecurity” or “qualifying cyber incidents” in places in the Act which make reference to “anti-terrorism” or “acts of terrorism”.

There is only one definition supplied by this bill; adding the term “qualifying cyber incident” to the list of definitions in §444. That new definition applies the definition of ‘incident’ from 44 USC 3552(b)(2). That definition is a very IT centric definition that applies to any occurrence that “actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system” {§3552(b)(2)(A)}. It also specifically includes “a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies” {§3552(b)(2)(B)}.

Moving Forward

Daines is a relatively low-ranking member of the Senate Homeland Security and Governmental Affairs Committee to which this bill was assigned for consideration. This means that he may have enough influence to have this bill be considered in Committee.

I do not see anything in this bill that would engender any significant opposition. If the bill were to be considered in Committee, it would probably pass with bipartisan support as it would if it were to ever reach the floor of the Senate.

Commentary

While the provision for limited protections against 3^rd party liability claims for qualifying cybersecurity technology certainly has its merits, there are a couple of very serious problems with this bill. And those deal with definitions, both those that are missing and those that are lacking.

The most glaring problem with the bill is the lack of a definition of ‘cybersecurity’ or more importantly ‘cybersecurity technologies’ as the term is usually used in the proposed revision to the SAFETY Act. The definition of ‘qualified anti-terrorism technology’ can help provide a framework for a definition once we add terminology appropriate to ‘cybersecurity’. I would propose that the following definition be added at the end of the bill:

“(8) CYBERSECURITY TECHNOLOGY – The term “cybersecurity technology” means any product, equipment, service (including support services), device, or technology (including information technology) designed, developed, modified, or procured for a cybersecurity purpose as that term is defined in 6 USC 1501(4).”

That ‘cybersecurity purpose’ term, in turn, relies on the expansive definition of ‘information system’ in §1501(9) that specifically includes industrial control system components. Thus, the ‘cybersecurity technology’ would also encompass ICS protections, which are mostly missing from this bill.

The other major problem with definitions in this bill is the definition of “qualifying [emphasis added] cyber incident” does not include any mention of a requirement for the Secretary to designate an incident as a ‘qualifying cyber incident’. Thus, any incident meeting the IT centric and very expansive definition in §3552(b)(2), would, a priori, be a ‘qualifying cyber incident’. This could easily be rectified by changing the wording of the definition to:

“(7) QUALIFYING CYBER INCIDENT –

(A) The term “qualifying cyber incident” means any incident, as that term is defined in section 3552(b) of title 44, United States Code, that the Secretary determines meets the requirements under subparagraph (B), as such requirements are further defined and specified by the Secretary.

(B) REQUIREMENTS.— An act meets the requirements of this subparagraph if the act—

(i) is unlawful;

(ii) causes harm to a person, information system (as that term is defined in section 1501(9) of title 6, United States Code), property, or entity, in the United States, or in the case of a domestic United States air carrier or a United States-flag vessel (or a vessel based principally in the United States on which United States income tax is paid and whose insurance coverage is subject to regulation in the United States), in or outside the United States; and

(iii) uses a cybersecurity threat or malicious cybercommand and control as those terms are defined in section 1501(5) and (11) of title 6, United States Code.

ICS-CERT Updates Meltdown Alert Again

Today the DHS ICS-CERT published the second update of their Meltdown Alert for this week. The update provides new information on the alert that was originally published on January 11^th, 2018 and updated on January 16^th, 2018, January 17^th, 2018, January 30^th, 2018, and on February 20^th, 2018.

The update provides links to three new vendor documents. They are:

• Beckman Coulter;

• Siemens (actually this link is good, but the one in the update does not work);

• Stryker (this is a direct link, the one in the update is a link to a link)

Both the Beckman and Stryker links take you to documents that were dated in January, so they are very preliminary notifications with little information. The Siemens document is dated today, and it provides some level of actionable detail for a number of industrial products.

NOTE: Siemens also released two other new security notifications this morning as well as updating six previously issued notifications. We may see these tomorrow on ICS-CERT, but more likely it will be next week.

CFATS Authorization – Protection from Drones

This is the second in a continuing series of blog posts on my proposed changes to the CFATS authorization. The current authorization for the program ends on December 18^th, 2018. These posts address some of the language that I would like to see in any re-authorization bill. Earlier posts in the series include:

CFATS Reauthorization – Cybersecurity

CFATS Reauthorization – Agricultural Production Facilities

The Drone Problem

The growing sophistication and ready availability of unmanned aerial systems (UAS) provides unique challenges in protecting critical infrastructure. This is particularly true in the case of high-risk chemical facilities. Small UAS can be used to conduct detailed reconnaissance of facilities before a physical attack is initiated and increasing payload size means that they may be used a delivery method for improvised explosive devices. The increasing battlefield sophistication in the use of UAS by organizations like ISIS almost ensures that the technology will be used by terrorists.

Defending against UAS attacks in the United States presents two separate, but closely related, issues for the facility owner. First, legally (18 USC 32) it is not permissible to interfere with an aircraft in flight and the FAA and Congress have made clear that the federal government considers all but the very smallest UAS to be aircraft. In large part because of that legal restriction the technology needed to identify, track and take control of UAS intruding upon the airspace of a high-risk chemical plant has not been robustly developed.

Protection Against Drones

With the above in mind, I would suggest that the following language be added to any CFATS reauthorization bill:

Sec. 631 Protection Against Unmanned Aircraft

(a) Restricted Air Space – The Secretary will work with the Administrator of the Federal Aviation Administration to ensure that each high-risk chemical facility in Tier I and Tier II with release hazard chemicals of interest will be declared a National Defense Airspace and in accordance with 14 CFR 99.7 the FAA will issue appropriate Special Security Instructions restricting operations of unmanned aircraft (UA) within the area.

(b) The Secretary will:

(1) establish procedures to allow facilities in Tier III and Tier IV, and Tier I and Tier II facilities not included in (a) above, to petition to have their facilities provided the protections outlined in (a) above;

(2) work with the Administrator to establish standards to consider such petitions while providing minimal interference in the operation of the National Airspace.

(c) Actions to enforce special security instructions.

(1) Notwithstanding provisions of 18 USC 32, owner/operators of chemical facilities that have been declared to be a National Defense Airspace are authorized to take actions to stop a UA from violating the Special Security Instructions issued by the FAA, to include forcing the aircraft to land. Any UA recovered will be turned over to the FBI for investigation.

(2) The Secretary will direct the Science and Technology Directorate to aid in the development of technology for the tracking, identification and control of UA to be certified under 6 USC Part G.

This would, of course, require the addition of a definition of UA to §621. The easiest way to do that would be to add the FAA definition of UA from 14 CFR 107.3.

Bills Introduced – 02-20-18

Yesterday, with the House and Senate meeting in pro forma session (most congresscritters back in their districts), there were 9 bills introduced. Of those one may be of specific interest to readers of this blog:

HR 5074 To authorize cyber incident response teams at the Department of Homeland Security, and for other purposes. Rep. McCaul, Michael T. [R-TX-10]

As usual with cybersecurity bills, I will be watching definitions closely to see if the provisions specifically apply to industrial control systems.

ICS-CERT Publishes ABB Advisory and Updates Meltdown Alert

Today the DHS ICS-CERT published a new control system security advisory for products from ABB. They also provided an update of their previously issued alert for the Meltdown and Spectre vulnerabilities.

ABB Advisory

This update describes an information exposure vulnerability in the ABB netCADOPS Web Application. The vulnerability was reported by İsmail Erkek. ABB has provided product updates to mitigate the vulnerability. There is no indication that Erkek was provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively low-skilled attacker could remotely exploit this vulnerability to allow critical information about the database to be exposed. The ABB security advisory clarifies that the attacker would have to have access to the control network hosting the DMS to exploit the vulnerability.

Meltdown Alert Update

This update provides additional information on an alert that was originally published on January 11^th, 2018 and updated on January 16^th, 2018, January 17^th, 2018 and on January 30^th, 2018. The update adds a link to a new vendor notification from Honeywell. Previously identified vendor pages for ABB and Schneider have been updated since the last ICS-CERT update. NOTE: The updated ABB page is the one I mentioned on Saturday.

CFATS Program Oversight Hearing

Last week the Cybersecurity and Infrastructure Protection Subcommittee of the House Homeland Security Committee held an oversight hearing looking at the Chemical Facility Anti-Terrorism Standards (CFATS) program. According to the opening statement of the Chair, this is the first step in the reauthorization process for that program. The current authorization for the program ends on December 18^th, 2018.

Support for CFATS Program

Three of the witnesses were from chemical manufacturing organizations who represent CFATS covered facilities in a range of industries. The fourth witness was a well-known environmental advocate who has frequently addressed chemical manufacturing safety issues.

Generally speaking, all four witnesses supported the CFATS program and advocated for its reauthorization. All expressed concerns that the reauthorization should not take the form of year-to-year extensions of the program that were seen prior to 2014.

Suggestions for Reauthorization Changes

Chet Thompson, representing the American Fuel & Petrochemical Manufacturers, specifically recommended another medium-term extension of the program requiring specific congressional reauthorization, as was done in 2014. His other recommendations for the reauthorization were generally restrictive:

• Do not include an inherently safer technology mandate (in oral testimony);

• Continue to protect the confidentiality of site security information;

• Require changes in the Appendix A chemical of interest (COI) list to go through comment-response process;

• Avoid extending the anti-terrorist vetting program to Tier III and Tier IV facilities; and

• Avoid any major changes to the program.

Kirsten Meskill, representing the American Chemistry Council, had three recommendations in her written testimony for the reauthorization of the CFATS program:

• Improve transparency in DHS risk determinations;

• Reconsider the value of Terrorist Screening Database (TSDB) screening at low risk facilities; and

• Recognize industry stewardship programs.

Pete Mutschler, representing both the Fertilizer Institute and the Agricultural Retailers Association, included two reauthorization suggestions in his testimony;

• Continue to protect the confidentiality of site security information; and

• Recognize industry stewardship programs.

Paul Orum, representing the Coalition to Prevent Chemical Disasters, was the most detailed in his recommendations for reauthorization changes. In his testimony Orum addressed (with specific suggestions):

• Use all available options – not just management and control strategies;

• Exercise oversight – especially of the ability of CFATS standards to realistically ensure protection;

• Use available resources – especially make better use of employee input;

• To improve public confidence, respect community concerns; and

• Support other programs that improve chemical security;

Commentary

Readers will remember that I started the CFATS reauthorization discussion rolling last fall when I did two blog posts on my suggestions for changes to the program (here and here).

My first post addressed cybersecurity issues. None of the witnesses addressed cyber issues in their prepared testimony and there was only one question about cybersecurity during the hearing (52 minutes). The responses were fairly generic calls for information sharing. Thompson did note that the current Risk Based Performance Standard 8 of the CFATS program addresses cybersecurity.

One interesting topic that did come up during questioning (49 minutes) was the use of unmanned aerial vehicles (UAV) or drones. There was just one question (51 minutes) on the topic and the answers were very generic. Meskil pointed out that drones are a duel edged sword; they are useful in many inspection and maintenance operations at facilities, but weaponized drones are a potential threat that has yet to be addressed. While I will address specific recommendations for drone provisions of the CFATS reauthorization, I will note here that drone rules have to take into account two specific restrictions:

• Interference in the operation of a drone is a federal felony; and

• Tracking and intercepting a drone is technologically and operationally complicated.

Finally, on the topic of inherently safer technology (IST); there should be no mistake made, the CFATS regulations have had a positive impact on the application of risk reduction measures at a relatively large number of chemical facilities. This is clearly seen in the reduction in the number of facilities over the years that have left the CFATS program. Orum is correct that DHS and ISCD could further aid this legitimate risk reduction effort by being more forthcoming about the number and types of facilities that have exited the program by reducing and/or eliminating their COI inventories. As I have said on a number of occasions, requiring a specific IST review/implementation process ignores the complexity of the situation, but ISCD should be providing information gleaned (and anonymized) from former CFATS facilities to similar facilities to make the process somewhat less complicated.

NIST Framework Update – 02-17-18

This week the National Institute of Standards and Technology updated their Cybersecurity Framework web site. Only two things of potential new interest on the redesigned web site; new CSF ‘Online Learning’ and a brief announcement about the date of the next CSF Workshop.

Framework Learning

The new Online Learning page is going to be a disappointment to anyone that expects NIST to provide some new high-tech learning environment. What NIST has provided is three new pages with old-fashioned written discussions with minimal graphics addressing the following topics:

• Components of the Framework;

• Uses and Benefits of the Framework; and

• History and Creation of the Framework.

The information presented is useful and well written. It is just odd to see this presentation format used to address such a modern issue. Actually, I kind of liked it.

Framework Workshop

The new Latest Update page announces that NIST intends to hold their next CSF workshop on September 11^th -13^th, 2018 in the Washington, DC area. Further information will be published in the coming weeks.

Commentary

Back in December NIST published the latest draft version of CSF v1.1 for comments. The comment period closed on January 18^th. NIST has still not published the comments that it has received. The Latest Update page still notes that: “All responses will be published publicly in the coming weeks.”

NIST has chosen not to use the Federal eRulemaking Portal (www.Regulations.gov) to receive comments for a variety of reasons. Most importantly, the justification is that the CSF is not a regulatory regime, so that particular public comment process is not necessary.

In earlier iterations of the CSF process NIST published the responses on the CSF web site as they came in. This allowed interested parties to see what other interested individuals and organizations were saying and add their two-cents worth as appropriate. It also allowed gadflies like myself to conduct on-going analysis and comments (see here for example) as the comments came in. Again, I would like to think that commentators such as myself helped to publicize the CSF discussions and maybe even inspire some additional comments being submitted that would not have otherwise been made.

I am disappointed that NIST did not provide the cybersecurity community to see these comments as they came in. It makes the revision process look much more closed than were the earlier efforts. I am afraid that this type of government activity that is being moved back behind closed doors by an Administration that supposed to be ‘business friendly’. Failing to conduct public business in the public eye is not now, nor never has been ‘business friendly’.

We need NIST to move the CSF modification process fully back into the public spotlight.