HR 2810 Conference Report – 2018 NDAA

This week the conference committee considering the differences in the House and Senate versions of HR 2018, the FY 2018 National Defense Authorization Act (NDAA) published their report on a final version of the bill. Additionally, the bill contains an explanation of how the conferees came to compromise language.

Cybersecurity Provisions

As is to be expected there are a number of cyber related provisions found in the bill. The list below shows the title of the appropriate sections and the pages within the report for both the actual language adopted by the conference and the discussion of how that language was arrived at.

§1090. Providing assistance to House of Representatives in response to cybersecurity events. (pgs 326-7; discussion pg 933)

§1110. Pilot program on enhanced personnel management system for cybersecurity and legal professionals in the Department of Defense. (pgs 352-6; discussion pg 950)

Subtitle C—Cyberspace-Related Matters

PART I—GENERAL CYBER MATTERS

§1631. Notification requirements for sensitive military cyber operations and cyber weapons. (pgs 457-8; discussion pgs 1016-7)

§1632. Modification to quarterly cyber operations briefings. (pg 459; discussion pg 1017)

§1633. Policy of the United States on cyberspace, cybersecurity, and cyber warfare. (pgs 459-60; discussion 1017-8)

§1634. Prohibition on use of products and services developed or provided by Kaspersky Lab. (pgs 460-2; discussion pg 1018)

§1635. Modification of authorities relating to establishment of unified combatant command for cyber operations. (pg 462; discussion pgs 1018-9)

§1636. Modification of definition of acquisition workforce to include personnel contributing to cybersecurity systems. (pg 462; discussion pg 1019)

§1637. Integration of strategic information operations and cyber-enabled information operations. (pg 462-5; discussion 1019-20)

§1638. Exercise on assessing cybersecurity support to election systems of States. (pg 465; discussion pg 1020)

§1639. Measurement of compliance with cybersecurity requirements for industrial control systems. (pg 465; discussion pg 1020)

§1640. Strategic Cybersecurity Program. (pgs 465-7; discussion pgs 1020-1)

§1641. Plan to increase cyber and information operations, deterrence, and defense. (pg 467; discussion pg 1021)

§1642. Evaluation of agile or iterative development of cyber tools and applications. (pgs 467-9; discussion pg 1021)

§1643. Assessment of defense critical electric infrastructure. (pg 469; discussion pg 1021)

§1644. Cyber posture review. (pgs 469-70; discussion pgs 1021-2)

§1645. Briefing on cyber capability and readiness shortfalls. (pgs 470-1; discussion pg 1022)

§1646. Briefing on cyber applications of blockchain technology. (pg 471; discussion pg 1022)

§1647. Briefing on training infrastructure for cyber mission forces. (pgs 471-2; discussion pg 1022)

§1648. Report on termination of dual-hat arrangement for Commander of the United States Cyber Command. (pg 472; discussion pgs 1022-3)

PART II—CYBERSECURITY EDUCATION

§1649. Cyber Scholarship Program. (pgs 473-4; discussion pg 1023)

§1649A. Community college cyber pilot program and assessment. (pgs 474-5; discussion pg 1023)

§1649B. Federal Cyber Scholarship-for-Service program updates. (pgs 475-6; discussion pg 1023)

§1649C. Cybersecurity teaching. (pg 477; discussion 1023)

The one provision listed above that may be of specific interest to readers of this blog is §1639. It requires the Secretary of Defense to measure “the progress of each element of the Department of Defense in securing the industrial control systems of the Department against cyber threats, including such industrial control systems as supervisory control and data acquisition systems, distributed control systems, programmable logic controllers, and platform information technology” {§1639(a)}. This measurement is to be included in the scorecard used in the implementation of the DOD Cybersecurity Discipline Implementation Plan.

An interesting term is used here; ‘platform information technology’. It is a military term that can be defined as computer hardware and/or software used to support operations technology. In an industrial control system environment this would certainly include human machine interfaces and data historians as well as the communications systems involved in the control system.

Unmanned Aircraft Systems

There are a number of provisions in the revised language for HR 2810 that refer to unmanned aircraft systems (UAS). One is of potential interest to readers of this blog because it addresses DOD authority to deal with intrusive UAS at or near DOD facilities or operations.

§1692. Protection of certain facilities and assets from unmanned aircraft. (pgs 509-12; discussion pgs 1038-40)

This provision will provide an exemption for DOD from the air piracy provisions of 49 USC 46502 and from “any provision of title 18 (USC)” {§1692(a)} for actions taken to protect DOD covered facilities from the threat posed by UAS. This would include actions taken to {§1692(b)}:

• Detect, identify, monitor, and track the unmanned aircraft system or unmanned aircraft, without prior consent, including by means of intercept or other access of a wire communication, an oral communication, or an electronic communication used to control the unmanned aircraft system or unmanned aircraft;

• Warn the operator of the unmanned aircraft system or unmanned aircraft, including by passive or active, and direct or indirect physical, electronic, radio, and electromagnetic means;

• Disrupt control of the unmanned aircraft system or unmanned aircraft, without prior consent, including by disabling the unmanned aircraft system or unmanned aircraft by intercepting, interfering, or causing interference with wire, oral, electronic, or radio communications used to control the unmanned aircraft system or unmanned aircraft;

• Seize or exercise control of the unmanned aircraft system or unmanned aircraft;

• Seize or otherwise confiscate the unmanned aircraft system or unmanned aircraft; or

• Use reasonable force to disable, damage, or destroy the unmanned aircraft system or unmanned aircraft.

Moving Forward

The House Rules Committee is currently scheduled to hold a hearing this evening to construct the rule for the floor consideration of the conference report. This will almost certainly be a structured rule with limited debate and no floor amendments. The House is then scheduled to take up the conference report under that rule on Tuesday. It will almost certainly pass with some measure of bipartisan support; as it will later in the week in the Senate.

Commentary

It would have been helpful if §1639 had included some sort of requirement for DOD to publicly publish the measurement guidelines that would be used to evaluate the cybersecurity of industrial control systems. Those guidelines could be very useful for other large organizations to conduct a similar high-level review of the cybersecurity of ICS.

In the section on UAS protections for DOD facilities I find it extremely interesting that the language ‘any provision of’ 18 USC was used instead of just references to the specific aircraft protection provisions of 18 USC 32. Other provisions that could have been specifically included:

§39A - Aiming a laser pointer at an aircraft;

§1030 - Fraud and related activity in connection with computers; or

§2511 - Interception and disclosure of wire, oral, or electronic communications prohibited.

Of course, lawyers are well known for their ability to attempt to stretch legal requirements to cover unusual circumstances, so perhaps the crafters of §1692 were justified in their use of ‘any provisions’. We will just have to wait and see how much the lawyers at DOD stretch that language to include not so reasonable actions taken against UAS and their pilots.

Automated Safety Systems and Security

Yesterday, after I made my posting here about automated safety systems and their applicability as security systems, I posted a question on the same subject over on the ControlGlobal.com security discussion board. While that site hasn’t been too active of late, I thought that it might be a good place to get feed back from control system professionals. The question posted was: “Is anyone using an existing automated safety system as a documented mitigation technique as part of a facility security plan?” I was pleasantly surprised to get two quick responses to the question. Actually neither was a direct response to the question, but were supportive of the idea. Both the response from Walt Boyes (Editor at Control and at ControlGlobal.com) and fenton2 (a regular contributor at that site) are worth reading. If there are any readers here that would be interested in joining that discussion feel free to post your responses at the ControlGlobal.com site, I’ll make sure that such postings get cross coverage here. Readers preferring to post their response here, will of course be appreciated.

Comingling Safety and Control Systems

There is an interesting blog post by Joe Weiss over at ControlGlobal.com about concerns in the regulatory community about the comingling of control systems and safety systems. To understand the concern we need to do a little instructional backgrounder here as part of Industrial Control Systems 101. Industrial Control Systems 101 In a chemical facility an industrial control system (ICS) may be used to control a chemical process. An operator typically uses a computer to monitor process conditions (weights, temperatures, pressures, etc) and control process equipment (valves, pumps, etc). These systems can be fairly simple with all process decisions and actions being controlled by the human operator or more complex with active computer controls of multiple process parameters. A safety system is a system used to protect process equipment, personnel and/or the environment from unsafe process upsets. These can be straight mechanical systems like pressure relief valves or they can be automated systems where there is, at a minimum, a sensor, an actuator and a controller between the two. The sensor is used to detect an impending process upset, the controller receives the signal from the sensor and directs one or more actuators to take action to prevent that upset. You may have a chemical process where heat is used to drive a reaction to completion. There will be optimum process temperature conditions that the operator will use a control system to maintain; too low a temp and the process will be inefficient; too high a temp and there will be quality issues with the product. The ICS will be used to manipulate heating and cooling to maintain the process within that optimum temperature range. The same process may have a temperature above the optimum temperature range where an unsafe chemical reaction can take place; an auto-ignition temperature for example. A safety system would be in place to automatically turn off heating and start cooling if the process temperature gets within a pre-set limit of that unsafe temperature. Now the ICS should never allow the temperature to approach that unsafe condition because it is beyond the optimum temperature range. But the safety system is put into place because there is always the possibility that there could be a failure in the ICS, a human error, or some other problem that allows the temperature to rise to an unsafe level. It would seem obvious that one would want to make sure that a failure in the ICS that would allow an unsafe temperature rise would not affect the safety system. This is one of the reasons that in the ‘good ole days’ safety systems were designed as stand alone systems with their own sensors, controllers and actuators. The power systems were even separate with battery back up systems for the safety systems where electric systems were used. As both safety systems and control systems became more complex it became easier to justify the linkage of parts of these two systems. Sensors became more robust with very low failure rates and multiple sensors were being used in any case, so why not use the same sensor array for both systems. As systems became more complex it became harder to physically fit in separately actuated systems that accomplished the same thing so common controls were used in both systems. Finally, as the programming of the control system became more complex and interactive it became easier to justify putting the safety system controller on the same computer system as the ICS. Unfortunately, with the mergers of these two systems it becomes easier to posit a single system failure that could affect both systems. Some systems engineers feel that the new system failure rate is lower than the rate of double failures in the old systems so the combination of the two systems is justified as being safer than the old separate systems. This is certainly true, but two systems with modern low failure rates would be safer still. Safety Systems as Security Systems This discussion would not seem to be germane to the discussion of security at high-risk chemical facilities, until one realizes that safety systems are actually the final line of defense against a cyber attack on the facility control system. In addition to protecting against a failure in the ICS they would also prevent catastrophic consequences from a deliberate misuse of that system. Using the example in the ICS 101 discussion above, suppose a terrorist gained control of the ICS either through corrupting an operator or via a cyber attack on the control system computer. Changing the high temperature limits of the control system could allow the system temperature to rise to the auto-ignition temperature, causing a catastrophic fire in the facility equipment. An old-style safety system would prevent that occurrence and stymie the terrorist attack. In other words, an existing old-style stand-alone safety system could be considered to be a security measure. No added cost or complexity, just another layer in the protective shield around the facility. But, that would only be true if the safety system were maintained as a separate system from the ICS. A safety system that is tied into the ICS would be subject to the same attack and would not prevent the catastrophic consequences of the attack.