S 1350 Introduced - National Risk Management Act

Last month Sen Hassan (D,NH) introduced S 1350, the National Risk Management Act of 2021. The bill would require CISA to “establish a process by which to identify, assess, and prioritize risks to critical infrastructure, considering both cyber and physical threats, vulnerabilities, and consequences” {new §2218(b)(1)(A). The bill adds a new §2218, National Risk Management Cycle, to the Homeland Security Act of 2002.

NOTE: This review is based upon a submission draft of the bill from Hassan’s web site. An official GPO version of the bill is not yet available. See my blog post about that publication delay problem.

Definitions

Section 2218(a) provides the key definition for the Section. Two terms are defined:

• Critical infrastructure, and

• National critical functions

The first is defined by reference to 42 USC 5195c(e). The term ‘national critical functions’ is similarly defined as {new §2218(a)(2)}:

The functions of government and the private sector so vital to the United States that their disruption, corruption, or dysfunction would have a debilitating effect on security, national economic security, national public health or safety, or any combination thereof.

National Risk Management Cycle

Subsection (b)(1) requires CISA to establish “a process by which to identify, assess, and prioritize risks to critical infrastructure, considering both cyber and physical threats, vulnerabilities, and consequences”. The process will include CISA consultation with “Sector Risk Management Agencies, critical infrastructure owners and operators, and the National Cyber Director” {new §2218(b)(1)(B)}. The process will be publicly reported in the Federal Register within 180 days of the enactment of this bill.

National Critical Infrastructure Resilience Strategy

Subsection (b)(2) requires the President to submit to Congress a national critical infrastructure resilience strategy designed to address the risks identified above. In the submitted strategy, the President will {new §2218(b)(2)(B):

• Identify, assess, and prioritize areas of risk to critical infrastructure that would compromise, disrupt, or impede their ability to support the national critical functions of national security, economic security, or public health and safety,

• Assess the implementation of the previous national critical infrastructure resilience strategy, as applicable,

• Identify and outline current and proposed national-level actions, programs, and efforts to be taken to address the risks identified,

• Identify the Federal departments or agencies responsible for leading each national-level action, program, or effort and the relevant critical infrastructure sectors for each,

• Outline the budget plan required to provide sufficient resources to successfully execute the full range of activities proposed or described by the strategy, and

• Request any additional authorities or resources necessary to successfully execute the strategy.

Moving Forward

As I mentioned earlier today, S 1350 will be considered by the Senate Homeland Security and Governmental Affairs Committee during a business meeting on Wednesday. This almost certainly means that there will be significant bipartisan support for the bill in Committee.

The problem will be moving the bill to the floor of the Senate. Last year I would have said that this would not be an important enough bill to be considered on the floor under regular order. The extended debate, amendment and cloture process takes up a lot of the Senate’s limited floor time. This is especially true early in an Administration when so much of the Senate efforts are expended in providing advice and consent on political appointees. Typically, I would have said that this bill would have to run the risks of the unanimous consent process; the risk being that a single Senator could stop consideration of the bill.

This year with the ghosts of the SolarWind and Microsoft Server attacks and the ongoing problems with the ransomware attack on Colonial Pipeline, there might be some serious pressure to bring this bill to the floor. It could end up being the vessel for containing the increasing political pressures to do something about the national cybersecurity problem. The problem then would be for the fractured Senate leadership to keep some modicum of control over the amendment process.

Commentary

This bill is very broadly written and that was certainly the intent. The crafters wanted to give CISA and the President the greatest leeway to define a frequently changing problem and provide congress with specific proposals to Congress for future lawmaking efforts to support solving the problem. In general, I support this process.

Having said that, there is a glaring disconnect between the risk identification process and the national response process. The first cause of this is the failure to limit the risk identification process to just those areas where the national government can have a direct impact on risk mitigation. The Federal government cannot afford the people, time or money to address all of the risks faced by the critical infrastructure in the United States. Fortunately, the second definition in §2218(a) provides a reasonable means for limiting that risk assessment process. I would make the following revisions to §2218(b)(1)(A):

‘‘(A) IN GENERAL.—The Secretary, acting through the Director, shall establish a process by which to identify, assess, and prioritize risks to critical infrastructure, considering both cyber and physical threats, vulnerabilities, and consequences.:

“(i) establish a process by which to identify, assess, and prioritize risks to critical infrastructure that would be expected to impact national critical functions, and

“(ii) consider both cyber and physical threats, vulnerabilities, and consequences.”

The second part of the problem is the failure to identify those mitigation and resiliency measures that ought to be the sole responsibility of the critical infrastructure owner/operators (including in some instances State, local and Tribal governments). To that end, I would add an additional subparagraph to (A) above:

“(iii) identify the necessary minimum self-protection measures and reporting requirements that a critical infrastructure facility should be expected to implement to help reduce the risks identified in this Section.”

Reader Comment – 09-08-13 – ‘Risk’ vs ‘risk’ Management

Russell Thomas, developer of the Ten Dimensions of Cyber Security Performance that I’ve discussed earlier, has posted a very short comment on this week’s blog post about Ralph Langner’s critique of the Cybersecurity Framework. Actually, Russell’s comment was a link to a very lengthy (even by my standards) blog post about Ralph’s general criticism of cyber risk management. It is readily apparent that Ralph and Russell approach cybersecurity from two completely different backgrounds, but they both bring valuable ideas to the discussion of risk management to which the control system community should pay close attention.

Anyone that is seriously interested in the theoretical basis for cybersecurity risk management needs to follow Russell’s blog, Exploring Possibility Space. Russell is an innovative thinker and draws upon a number of academic disciplines in formulating his ideas. There is a tendency to slip into academic speak from time to time, but his ideas are certainly worth the effort to wade through that jargon when it arises.

I highly recommend that anyone seriously invested in cybersecurity risk management should read Russell’s post about Ralph’s approach to risk management. I’ll try to hit the highlights here.

Empirical Justification

Russell points out that both he and Ralph agree that there is little empirical justification for what Russell calls “Little ‘r’ risk” (see his post on ‘risk vs Risk’) management. Ralph sees this as a reason to ignore formal risk management techniques. Russell sees this as a reason to extend the study of Risk management so that there is a useful theoretical basis for developing and evaluating risk management techniques.

This is the classic argument between theoreticians and technicians in any newly developing field. In the short run Ralph’s arguments are certainly justifiable, but in the longer run it will be folks like Russell who will provide us with a solid basis for securing the cyber enterprise, particularly on the control system side. That is if Ralph and his compatriots can cobble together a relatively effective cybersecurity program that prevents catastrophic attacks in the meantime.

Practical Feasibility

Again Russell and Ralph mainly agree that the currently accepted theories on probabilistic risk are lacking in practical applications. Again, Ralph sees this as a reason to eschew the study of probabilistic risk management for work on actual applications. Russell’s approach is to change the way we look at probabilistic risk management to make it more practical. He provides one of his papers, “How Bad is it? – A Branching Activity Model to Estimate the Impact of Information Security Breaches”, as an example of the new types of research that are expanding the usefulness of the technique.

Once again, I think that these two have more in common that it initially appears. I would love to see these two on a panel discussing this topic (Dale or Joe please note the suggestion). An effective melding of their viewpoints would be very beneficial to the cybersecurity enterprise.

Langner Criticizes Cybersecurity Framework

Ralph Langner, of specific Stuxnet fame and a recognized control system security expert, has an interesting post on his corporate blog about the general ineffectiveness of the proposed Cybersecurity Framework and his own detailed proposal for an industrial control system security framework; Robust ICS Planning and Evaluation (RIPE). A review of RIPE will have to wait for a time when I have more time available to closely read the 12 page document, but his comments about the proposed NIST Framework deserve immediate attention.

Unpredictability

Ralph makes an important point early in his post when he states that “a fundamental problem of the CSF is that it is not a method that, if applied properly, would lead to predictable results”. The reason for that is clearly because the Framework is not, at its base, a document about cybersecurity, but rather a political document. It effectively transfers political risk from the Federal Government to facility owners. It allows the government to politically assign blame for a successful cyber-attack to the corporate victim.

As we saw after the fall of the Twin Towers the US public, and to a lesser extent, the business community, clearly placed the blame for the success of the attacks on the government’s inability to ‘connect the dots’ and intercept the attackers before they got to the aircraft. Little or no mention was made about the poor security posture of the airlines that allowed the attackers to take weapons onto the airplanes or to take control of the cockpits once they were on the aircraft.

The airlines security failures were seen as a lesser problem because no one could have foreseen that the aircraft would be used as weapons because no one had done so before. Ralph points out in his RIPE paper that this is a predictable application of ‘risk-based’ reasoning. He notes that:

“Cyber attacks against industrial control system installations are extremely rare, making it appear like a waste of company resources to protect against them. The generally accepted policy is to accept the risk and only after having seen a significant successful attack at home within the same industry, then figure out how to protect.” (pg 1)

Since industry has effectively killed every attempt to write actual cybersecurity legislation that could require industry to take even the most rudimentary positive protective actions, it has become necessary for the government to protect itself from future claims of blame for successful cyber-attacks on those industries.

Risk Management

One of the reasons that the airlines had such a poor security posture, even after three decades of successful terrorist hijackings, was that they had done a cost benefit analysis of the hijack risks. It was clear, in a corporate sense, that the monetary and public relations costs of adequate security was much higher that the relatively rare loss of an aircraft and its passengers. We still see this today, even after the events of 2001, in the complaints about the costs and inconveniences associated with TSA and its airport screening measures.

One of the reasons that the airlines were not held to account for the failure of the risk assessments was that there was never a public accounting of those decisions. The Framework will change that for high-risk critical infrastructure organizations. The Tier process that I described in an earlier post and Ralph takes to task in his post is clearly an attempt to make management make a recordable statement about their risk management decisions; a statement that will clearly be able to assign responsibility for poor (in hind sight) decisions that led up to a successful cyber-attack.

The remainder of the Framework will clearly show that the government did its part in helping the devastated target to secure their computer systems against outside attack. But the Tier process will allow the feds to show that management decisions were reasons that the cyber-defenses were not up to the task of protecting critical infrastructure from attack. It is all about CYA.

Australian Chemical Security Guidance Document

On Wednesday the Australian Government and the Plastics and Chemicals Industry Association (PACIA) announced the release an updated version of their Site and Supply Chain Security Guidance (SSCSG). This voluntary framework document is some what similar to the Risk Based Performance Standards guidance document produced by DHS in that it provides general guidance on how to develop a chemical security program. It is part of the Australian chemical industry’s Responsible Care program.

The DHS RBPS guidance document provides a much more comprehensive discussion of features that a security program should address, but chemical security professionals will find many things of interest in this document. It reflects a slightly different appreciation of the potential terrorist threat and how industry and government should respond to that threat.

Investigation of Security Incidents

It goes without saying that any security program will provide for investigation of security incidents and section 2.3 of this SSCSG briefly addresses this issue. It includes a list of examples of incidents that “would warrant investigation”. It includes examples of things readily recognizable by security professionals in any industry:

• “Doors not secured, holes in fence lines, indication of illegal entry
• “Unauthorised (sic) entry by personnel into restricted areas of the facility
• “Signs of vehicles in restricted areas along pipelines, fence lines, electrical substations, or remote plant security gates”

It also includes examples that are very specific to the chemical process industry that might be overlooked as possible security issues:

• “Major unexplained process upsets
• “Unexplained loss of containment of hazardous material
• “Unexplained loss of raw material or product”

The underlying incidents are typically investigated as process upsets that need to be resolved to ensure safe and profitable operation of the manufacturing process. What may be overlooked by chemical process professionals is that these may also be indications, especially if a routine processing issue cannot be identified as the root cause of the incident, of an attack on the site.

High-risk chemical facilities should include a chemical security professional in their routine incident investigation team. Even if the incidents provide no indication of a security breach, participation in the investigation will provide that security professional with additional insights into how the facility might be attacked.

Physical Security Measures

The discussion of physical security measures is generally much less detailed than that found in a number of different sections of the RBPS. There are some points in the discussion of access control that bear repeating. In listing the circumstances that must be considered in determining the appropriate level of access control (in section 4.1) they include the “degree to which facility operations are controversial”. This is something that is overlooked in the discussions in the RBPS.

For rather obvious reasons, there is a tendency in this country to equate a terrorist threat with a threat of an attack by Muslim Extremists. This is certainly not the limit of the terror threat. There are a number of other different (and evolving) types of organizations that might be expected to attempt attacks on chemical facilities. Target selection for each of these groups will be affected by their political goals and facility security assessments need to take this into account.

There is an access control measure included in the discussion in this section that I must admit that I had never considered, or heard mentioned in connection with chemical facility security. That measure is:

“Keep publicly accessible restroom doors locked and set up a key control system. If there is a combination lock, only office personnel should open the lock for visitors.”

I have seen this security measure employed at some convenience stores to reduce the incidence of vandalism or street level drug sales, but I have never heard of it being applied to an industrial security situation.

Cyber Security

Most of the cyber security discussion in section 4.3, as in the RBPS, focuses on Information Technology (IT) systems rather than control systems. Most of the information covered here is covered in much more detail in the RBPS, but there is an interesting addition here that I have not seen elsewhere. In their discussion of the potential reasons that a hacker might attack a cyber system at a chemical facility they include to “prevent emergency response systems” from working.

As I have mentioned on a number of occasions, a prompt and effective emergency response to an attack (or accident) will go along way to mitigating the consequences, particularly the off-site consequences, of a chemical release incident. The speed and efficacy of the response will depend, in large measure, on the speed with which the responders are notified and the detailed information they receive about the incident. Thus, a very effective way of ensuring the effectiveness of an attack would be to hamper that exchange of information.

I have long advocated the use of automated systems to detect leaks of toxic chemicals, track the progress of the plume dispersion and provide that information to emergency response personnel. Timely sharing of that information is crucial to maximize the effectiveness of the emergency response process. Protecting these automated systems should certainly be included in the cyber security program for the facility, particularly if they are connected to outside communications systems.

Chemicals of Interest

One key element of any chemical security program is the determination of which chemicals will be covered. The RBPS does not specify the DHS chemicals of interest (COI), but it is certainly based upon that list. Similarly the SSCSG depends on the Australian list of ‘chemicals assessed as of immediate potential security concern’ (I won’t even try to list that acronym, I’ll just use our ‘COI’) which is reproduced in Appendix A (how appropriate) of the SSCSG.

The Australian COI list only contains 96 chemicals (vs. over 300 on the DHS COI list) and there are substantial differences. The rationale for the Australian list is not included in this document, but it certainly focuses more on toxic chemicals and less on flammable chemicals. The Australian list includes a large number of pesticides where the DHS toxics list is mainly limited to Toxic Inhalation Hazard (TIH) chemicals as they are more easily ‘weaponized’.

While the pesticides included in the Australian list are not regulated under CFATS, chemical security professionals will want to take a look at the security of these chemicals where a facility may have been identified as a potential target for some eco-terrorist groups. Some of those groups would be at least as concerned about the production, storage or use of these pesticides as they would industrial TIH chemicals.

Risk Management Model

Though DHS does not specifically call it a ‘risk management model’ the CFATS program is clearly (and specifically) based on the Deter, Detect and Delay model, a very comprehensive model as far as it goes. The model used in this document (outlined in limited detail in Appendix B) expands that model to include Response and Recover. Response is defined as the “level of reaction required to counter an intrusion”. And Recover is defined as the “ability to ensure that operations can continue”.

As DHS, as an organization, is trying to advance their homeland security efforts to include ‘resiliency’ as part of their management mantra, the CFATS program should certainly consider expanding their model to what the Australians call the D3R2 (D Cubed, R Squared) model to address these resiliency issues. That should certainly include the provisions for a more comprehensive emergency response program for high-risk chemical facilities.

Reviewing Other Security Programs

The Australian Site and Supply Chain Security Guidance, like the CFATS RBPS, exists within a security framework that includes a variety of laws, regulations and industry standards. Viewing this document provides only a limited view of the Australian chemical security landscape.

Having said that, security professionals involved in chemical facility security activities would do well to review this relatively short (30 pages of relatively large type and white spaces) document. It provides a slightly different focus on chemical security issues from that found in the RBPS. As such it helps provide a more complete look at the chemical facility security picture.