Review – CSB Updates Accidental Release Reporting Database – 1-16-25

Yesterday the CSB updated their published list of reported chemical release incidents. They added 15 new incidents that occurred since the previous version was published in October. These are not incidents that the CSB is investigating, these are incidents that were reported to the CSB under their Accidental Release Reporting rules (40 CFR 1604).

The table below shows the top five states based upon the number of reported incidents since the July update was published.

For a deeper dive into the latest reporting data, see my article at CFSN Detailed Analysis - https://patrickcoyle.substack.com/p/csb-updates-accidental-release-reporting-68d - subscription required.

Review - CSB Updates Accidental Release Reporting Data – 10-24-24

Yesterday in preparation for their quarterly business meeting today, the CSB updated their published list of reported chemical release incidents. They added 28 new incidents that occurred since the previous version was published [removed from paywall] in July. They also removed one incident that occurred before July. These are not incidents that the CSB is investigating, these are incidents that were reported to the CSB under their Accidental Release Reporting rules (40 CFR 1604).

The table below shows the top five states based upon the number of reported incidents since the July update was published.

For more information on the information added to the CSB database, including a list of possibly missing incident reports, see my article at CFSN Detailed analysis - https://patrickcoyle.substack.com/p/csb-updates-accidental-release-reporting-4fb - subscription required.

Review - PHMSA Publishes Next Set of Hazmat FAQs – 8-18-23 – Incident Reporting

Today, DOT’s Pipeline and Hazardous Materials Safety Administration (PHMSA) published a notice in the Federal Register (88 FR 56702-56705) on “Hazardous Materials: Frequently Asked Questions – Incident Reporting”. This is part of a continuing effort at PHMSA to convert existing Letters of Interpretation into more broadly applicable frequently asked questions (FAQs) that was started [removed from paywall] in March of 2022.

Public Comments

PHMSA is soliciting public comments on this proposed set of FAQ and responses. Comments may be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket #PHMSA-2021-0109). Comments should be submitted by September 18^th, 2023.

Commentary

I think that this project of converting existing historical letters of interpretation into broadly applicable FAQ’s is a commendable information sharing effort on the part of PHMSA. The only problem is I am unable to find the FAQ’s from the initial tranche published in the Federal Register by PHMSA in March of 2022 on the PHMSA website. There is a “Hazardous Materials Safety FAQs” page, but it was last updated on August 23, 2019 and contains none of the questions proposed in the earlier notice.

If PHMSA is going to continue with this program, each subsequent notice in the Federal Register should contain a link to the web site where PHMSA is going to make these FAQ’s and responses readily available to the public. And to be fair, this notice should be updated with that link.

I will be posting this commentary as a comment on this notice.

 

For more details about this notice, including a list of the proposed FAQ’s, see my article at CFSN Detailed Analysis - https://open.substack.com/pub/patrickcoyle/p/phmsa-publishes-next-set-of-hazmat - subscription required.

FAR Cyber Incident Reporting NPRM Sent to OMB – 5-11-23

Earlier this week, the OMB’s Office of Information and Regulatory Affairs (OIRA) announced that it had received a Federal Acquisition Regulation (FAR) notice of proposed regulations (NPRM) for “FAR Case 2021-017, Cyber Threat and Incident Reporting and Information Sharing”. An earlier version of this NPRM was recently withdrawn from review at OMB.

According to the Fall 2022 Unified Agenda entry for this rulemaking:

“DoD, GSA, and NASA are proposing to amend the Federal Acquisition Regulation (FAR) to increase the sharing of information about cyber threats and incident information between the Government and certain providers, pursuant to OMB recommendations, in accordance with section 2 (b)-(c), and Department of Homeland Security recommendations, in accordance with section 8(b), of Executive Order 14028, Improving the Nation’s Cybersecurity. In addition, requires certain contractors to report cyber incidents to the Federal Government to facilitate effective cyber incident response and remediation, pursuant to Department of Homeland Security recommendations in accordance with sections 2(g)(i) of Executive Order 14028.”

There is no public record of what may have changed between the earlier version of this NPRM and the one currently being reviews by OIRA.

Last month Rep McMorris-Rogers (R,WA) introduce HR 9234, the Critical Electric Infrastructure Cybersecurity Incident Reporting Act. The bill amends 16 USC 824o-1, Critical electric infrastructure security, adding a requirement for DOE to establish cybersecurity incident reporting regulations for Critical Electric Infrastructure (CEI). No funding is authorized by this legislation.

Moving Forward

Both McMorris-Rodgers and her sole cosponsor {Rep Upton (R,MI)}, are members of the House Energy and Commerce Subcommittee to which this bill was assigned for consideration. This means that there could be sufficient influence to see the bill considered in Committee. The sole problem that this bill faces is that there is already-passed legislation {the Cyber Incident Reporting for Critical Infrastructure Act of 2022, Division Y of the Consolidated Appropriations Act, 2022 (PL 117-103)} making CISA the recipient of cybersecurity incident reports with a 48 hour time limit and the regulation development is already progressing on that statute. A great deal of effort went into making that legislation pass and Congress is unlikely to upset that legislative cart before the regulation is crafted.

And of course, there is too little time left in the session for such a controversial bill to make its way through the legislative process in any case.

Commentary

The crafters of the CISA CIRCIA rule foresaw potential conflicts in agency reporting requirements and established processes codified under 6 USC 681g to avoid problems under conflicting reporting requirements. This bill should have taken notice of those requirements by mandating DOE coordination of reporting requirements under that section. For instance the authors of this bill could have added a paragraph (4) to the new subsection (e):

“(4) Within 180 days of the passage of the Critical Electric Infrastructure Cybersecurity Incident Reporting Act, the Secretary will coordinate with the Director of the Cybersecurity and Infrastructure Security Agency to establish policies, processes, procedures, and mechanisms to ensure reports are shared with the Agency pursuant to 6 USC 681g(1).”

 

For more details about the provisions of this legislation, see my article at CFSN Detailed Analysis - https://patrickcoyle.substack.com/p/hr-9234-introduced - subscription required -

Review - CISA Publishes RFI for Cyber Incident Reporting Rule

CISA published a request for information in Monday’s (available on line today) Federal Register (87 FR 55833-55836) to support their development of a congressionally mandated rulemaking for cybersecurity incident reporting (CSIR) under §2242(b) of the Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA) of 2022 (Division Y, PL 117-103, 136 STAT 1044). CISA has until March 15^th, 2024 to publish a notice of proposed rulemaking (NPRM) to establish the CSIR regulations.

The RFI looks for public comments on the following categories of information:

Definitions, criteria, and scope of regulatory coverage,

Report Contents and Submission Procedures,

Other incident reporting requirements and security vulnerability information sharing, and

Additional policies, procedures, and requirements.

Public Comments

CISA is soliciting public comments on the RFI (duh). Comments may be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket # CISA-2022-0010). Comments should be submitted by November 14^th, 2022.

Public Meetings

In a separate Federal Register notice, CISA is providing information about a series of public meetings that will address the RFI topics. The cities currently included in the meeting list include:

Salt Lake City, Utah - September 21, 2022,

Atlanta, Georgia - September 28, 2022,

Chicago, Illinois - October 5, 2022,

Dallas/Fort Worth, Texas - October 5, 2022,

New York, New York - October 12, 2022,

Philadelphia, Pennsylvania - October 13, 2022,

Oakland, California - October 26, 2022,

Boston, Massachusetts - November 2, 2022,

Seattle, Washington - November 9, 2022, and

Kansas City, Missouri - November 16, 2022

Personnel wishing to attend one of these listening sessions may register via email (circia@cisa.dhs.gov). Registration will be accepted up to two days prior to the meeting date.

 

For more details about what CISA is looking for, see my article at CFSN Detailed Analysis - https://patrickcoyle.substack.com/p/cisa-publishes-rfi-for-cyber-incident - subscription required.

Review - Senate Passes S 3600 – Cybersecurity

Yesterday, the Senate took up S 3600, the Strengthening American Cybersecurity Act of 2022, which was introduced last week. The Senate considered the bill under the unanimous consent process. After adopting two amendments, the Senate passed S 3600 without debate or vote. The bill contains FISMA modifications similar to those found in S 2902, cybersecurity incident reporting requirements similar to those found in S 2875, as well as federal cloud security requirements.

Moving Forward

This strongly bipartisan action by the Senate would seem to grease the skids for this to pass quickly through the House and land on the President’s desk. Unfortunately, there are competing versions of portions of this bill in the House and this bill will have to overcome the ‘my bill first’ claims from at least two different House committees, Homeland Security and Science, Space, and technology. The current concerns about the Russian/Ukrainian related cybersecurity threats, may provide sufficient impetus to bring this bill to the floor of the House. If it gets by the two Chairs, this bill could easily be considered under the House suspension of the rules process and it could be on the President’s desk before the end of the month, or it could still be sitting on the Clerk’s desk at the end of the year.

Commentary:

This bill reflects a great deal of behind the scenes bargaining in the Senate. This will probably be the premier cybersecurity legislation for this Congress. My review today was done quickly to get it out and I am going to have to take a very detailed look at the cyber incident reporting requirements of §203. That post will come out later this week.

For more details about the provisions of this bill, see my article at CFSN Detailed Analysis - https://patrickcoyle.substack.com/p/senate-passes-s-3600 - subscription.

Review - HR 5440 Introduced – Cyber Incident Reporting

Last month, Rep Clarke (D,NY) introduced HR 5440, the Cyber Incident Reporting for Critical Infrastructure Act of 2021. Similar to S 2875, this bill establishes the Cyber Incident Review Office in CISA and establishes requirements for cyber incident reporting. It amends the Homeland Security Act of 2002 by adding a new §2220A, Cyber Incident Review Office. No new funding is provided in the bill.

Moving Forward

Clarke and all three of her cosponsors {Rep Thompson (D,MS), Rep Katko (R,NY), and Rep Garbarino (R,NY)} are influential members of the House Homeland Security Committee to which this bill was assigned for consideration. This bill will move forward in Committee, but there will almost certainly be revisions made to the language of the bill before it is approved with strong bipartisan support.

I am not convinced that the strong support in Committee will allow this bill to move to the floor of the House. There will be some inter-committee posturing trying to see more influence on these cybersecurity reporting requirements being retained by existing regulatory agencies. This would ensure that the leadership of other committees would retain their influence on both such reporting and the regulatory responses to those reports. If this bill were to make it to the floor of the House, I suspect that it would receive bipartisan support.

Commentary

I am suitably impressed with the effort that the Committee Staff took in their use of language and definitions to insure that cyberattacks on industrial control systems would be included in the regulations to be developed by CISA. There was one area, however, where that effort fell short. In the proposed §2220A(d)(5)(D) discussion of the content that would be required in the covered reports, bill requires in  clause (iv) that the report includes: “Where applicable, identification of the category or categories of information that was, or is reasonably believed to have been, accessed or acquired by an unauthorized person.” There is no corresponding requirement to report any specific information about operational technology or processes affected by the covered cyberattack. To correct this, I would suggest inserting a new clause (v):

“(v) Where applicable, identification of the operational control system, technology, or devices believed to have been accessed, modified or interrupted by an unauthorized person,”

While the language in this bill and S 2875 are not nearly identical, my comments about the weaknesses in the Senate bill also apply to this bill. To be effective these reporting regulations will have to include provisions for CISA to specifically identify covered facilities and directly notify them of that status and their reporting obligations prior to a cyber incident occurring. Otherwise, facilities will be able to argue that they were unaware that they were specifically considered to be a covered facility with reporting responsibilities under the rules.

I am not sure how CISA would go about accomplishing that task in anything approaching a comprehensive manner. This may be the best argument for letting this designation responsibility remain with other federal regulating agencies and allowing CISA to be the recipient of the required reports.

For more details about the provisions of this bill, see my article at CFSN Detailed Analysis - https://patrickcoyle.substack.com/p/hr-5440-introduced - subscription required.

CRS Reports - Comparison of Selected Cyber Incident Reporting Bills

This week the Congressional Research Service published at report on “Cybersecurity: Comparison of Selected Cyber Incident Reporting Bills—In Brief”. This report provides a side-by-side comparison of key provisions of four current pieces of cybersecurity reporting legislation:

• HR 5440 – the Cyber Incident Reporting for Critical Infrastructure Act,

• S 2407 – the Cyber Incident Notification Act of 2021,

• S 2875 – the Cyber Incident Reporting Act of 2021, and

• S 2943 – the Ransom Disclosure Act

NOTE: I have not yet reviewed HR 5440.

Review - S 2875 Introduced – Cyber Incident Reporting

Last month Sen Peters (D,MI) introduced S 2875, the Cyber Incident Reporting Act of 2021. The bill amends the Homeland Security Act of 2002 to establish a Cyber Incident Review Office within CISA and establishes cyber incident reporting requirements, including specific reporting requirements for ransomware incidents. No new spending is authorized by this bill.

As I mentioned yesterday, the Homeland Security and Governmental Affairs Committee will hold a markup hearing tomorrow that will include this bill. While amendments to the language are probably to be expected, this bill will almost certainly pass out of Committee with a favorable report. While the business community would probably rather not see this bill become law, there is a large enough loop-hole (see below) that there will probably not be any strong public opposition to the bill. It will be some-time, however, before this bill makes it to the floor of the Senate for consideration and there will be significant amendments that will further weaken the bill.

Commentary

A major problem with this bill is that there are no provisions to allow CISA to establish an actual list of covered entities, or a requirement to notify covered entities of their specific coverage under the provisions of this bill. The regulations outlined in §2232(b) only allow CISA to provide a “clear description of the types of entities that constitute covered entities”. This allows a private entity to determine, absent specific notification, that they are not covered entities for any number of reasons, real or crafted. This would allow those companies to ignore the reporting requirements of the bill and argue (maybe successfully, maybe not) against an application of a CISA subpoena.

The provisions of §2232 needs to include authorization for CISA to specifically identify entities that it determines meet the criteria in §2232(b) and to notify those entities that they are covered entities and the reason for that identification. Obviously, provisions would have to be made for an appeal process to petition a reversal of that identification, but positive identification would remove the nearly legitimate “I did not think we were a covered entity” defense.

That still leaves the less obvious loophole related to the lack of a clear definition of a ‘covered cyber incident’. This is the same problem that I addressed in relation to the CFATS program new cyber incident reporting guidance. Unfortunately, I do not see a ‘simple’ solution to this. We can hope that CISA could provide a broad enough “clear description of the types of substantial cyber incidents” that existing and yet to be developed cyberattacks would not be able to be ignored by corporate lawyers under the “we just did not think that this was a covered incident” defense.

For more details on the provisions of the bill, see my article at CFSN Detailed Analysis - https://tinyurl.com/nv47z7jy - subscription required.

Review - Cyber Incident Reporting – Lessons from CFATS

With all the talk on Capitol Hill about cybersecurity incident reporting, perhaps Congress ought to take a look at the Chemical Facility Anti-Terrorism Standards (CFATS) program. That program has had a mandatory requirement for reporting ‘significant cyber events’ since 2009. Lessons learned from that program may provide valuable insight into how a cyber event reporting program should be crafted.

Over the years the CFATS program has been one of the most cooperative regulatory programs around. DHS and industry organizations have worked together to make the program successful and individual facilities have worked with chemical security inspectors to ensure that their facilities are in compliance with the regulations. In short, if mandatory reporting requirements are going to be effective, this is the program where we would expect them to be most effective.

The recent change in the reporting guidance from CISA would seem to indicate that they are questioning the efficacy of the existing CFATS reporting requirements. CISA is removing some of the ambiguity that would allow facilities an excuse to not report cyber incidents. While only time will tell if this change does actually increase the reporting rate, I do not expect that it will. Industry has little reason to expect that a minor cyber incident will ever come to the attention of the government, so why should they be reported and expose the company to the potential attention of federal cyber investigators. And reporting a major attack that has not yet come to the attention of the public (and investors) would seem to be self-defeating.

Any cyber reporting mandate from Congress has to take these realities into effect. Congress needs to learn the rule I was taught as a young Sergeant; never give an order you know will not be obeyed. It makes you look stupid and undermines your authority.

For more detailed discussion about the background of the CFATS program and how it impacts the less than effective cyber incident reporting requirement, see my article at CFSN Detailed Analysis - https://patrickcoyle.substack.com/p/cyber-incident-reporting - subscription required.

Review - CFATS and Cyber Incident Reporting – 9-2-21

Today CISA updated both the Chemical Facility Anti-Terrorism Standards (CFATS) program landing page and the CFATS Knowledge Center to make the chemical security community aware of new guidance (Reporting Cyber Incidents) on the reporting of cyber incidents under Risk-Based Performance Standard (RBPS) 8 (Cyber) and RBPS 15 (Reporting of Significant Security Incidents).

While the Office of Chemical Security is not currently requiring changes to approved site security plans (SSPs), covered facilities can expect that chemical security inspectors will begin inspecting compliance with this new guidance. Chemical facilities that are not currently covered by CFATS should probably review the new guidance documents and incorporate them into their incident response plans.

CFATS covered facilities should review all of these new pages to determine if there is anything covered in them that is not appropriately reflected in their Site Security Plan. If the plans do appear to be deficient in any way, the facility should contact their chemical security inspector to determine if a formal revision of the SSP is required.

For more details on the documents and guidance, see my article at CFSN Detailed Analysis - https://patrickcoyle.substack.com/p/cfats-and-cyber-incident-reporting - subscription required.

CSB Publishes On-Line Incident Reporting Form

Yesterday the Chemical Safety and Hazard Investigation Board (CSB) published a link to their new online chemical release reporting form. They also established a new page on their web site, that currently only provides login and registration for their incident report rule news. This form supports the chemical release incident reporting rule that was published in February and became effective on March 23, 2020.

The .PDF form would be downloaded from the site, completed in the event of an incident and then emailed to report@csb.gov.

40 CFR 1604 (not yet officially published on govinfo.gov, wording can be found here from final rule) requires that:

“The owner or operator of a stationary source must report in accordance with paragraph (b) or (c) of this section, any accidental release resulting in a fatality, serious injury, or substantial property damage [links to definitions of highlighted terms added]” {§1604.3}.

The CSB has not yet published the reporting guidance document promised in the preamble to the final rule.

S 2764 Introduced – Aircraft Cybersecurity

Last week Sen. Markey (D,MA) introduced S 2764, the Cybersecurity Standards for Aircraft to Improve Resilience (Cyber Air) Act of 2016. The bill replicates the three amendments that Markey proposed to HR 636, the FAA authorization bill currently under consideration in the Senate.

Definitions

With the combination of the three amendments §2 provides a common set of definitions. Terms included in this section are:

• Covered air carrier;

• Covered manufacturer;

• Cyberattack;

• Critical software systems; and

• Entry point.

The two critical terms are ‘cyberattack’ and ‘critical software systems’. Cyberattack is defined as “the unauthorized access to aircraft electronic control or communications systems or maintenance or ground support systems for aircraft, either wirelessly or through a wired connection” {§2(3)}. The term ‘critical software systems’ is defined as “software systems that can affect control over the operation of an aircraft” {§2(4)}.

Incident Reporting

Section 3 of the bill is essentially SA 3468, the first of three cybersecurity amendments that Markey proposed to HR 636. It would require the Administrator to prescribe regulations requiring air carriers and manufacturers to disclose cyberattacks to the FAA. The attacks would have to be reported whether or not they were successful. The attacks would have to be reported “whether or not the system is critical to the safe and secure operation of the aircraft, or any maintenance or ground support system for aircraft, operated by the air carrier or produced by the manufacturer, as the case may be” {§3(a)}.

FAA would use the information disclosed by air carriers and manufacturers to inform future regulatory actions. The FAA would also be required to “notify air carriers, aircraft manufacturers, and other Federal agencies of cybersecurity vulnerabilities in systems on board an aircraft or maintenance or ground support systems for aircraft” {§3(b)}.

Cybersecurity and Operating/Manufacturing Certificates

Section 4 is essentially SA 3469. It would require the Secretary of Transportation to prescribe regulations incorporating cybersecurity standards into the requirements to obtain/maintain air carrier operating certificate or a production certificate under 49 USC Chapter 447. Those regulations would include requirements to {§4(b)(2)}:

• Require all entry points to the electronic systems of each aircraft operating in United States airspace and maintenance or ground support systems for such aircraft to be equipped with reasonable measures to protect against cyberattacks, including the use of isolation measures to separate critical software systems from noncritical software systems;

• Require the periodic evaluation of the measures described in subparagraph (A) for security vulnerabilities using best security practices, including the appropriate application of techniques such as penetration testing; and

• Require the entry point measures to be periodically updated based on the results of the evaluations conducted above.

Consumer Communications Equipment

Section 6 address the role of the DOT-FCC’s Commercial Aviation Communications Safety and Security Leadership Group as did amendment SA 3470. The bill would make them responsible for evaluating the cybersecurity vulnerabilities of broadband wireless communications equipment designed for consumer use on board aircraft operated by covered air carriers. They would be required to {§6(b)}:

• Ensure the development of effective methods for preventing foreseeable cyberattacks that exploit broadband wireless communications equipment designed for consumer use on board such aircraft; and

• Require the implementation by covered air carriers, covered manufacturers, and communications service providers of all technical and operational security measures that are deemed necessary and sufficient by the Leadership Group to prevent cyberattacks described above.

Reports to Congress

Section 5 of the bill can be found in the language of the first Markey amendment to HR 636. It requires an annual report to Congress on the attacks reported under provisions of §3.

Section 6(b) would require annual reports by the Leadership Group to Congress. Those reports would include {6(b)(1)}:

• The technical and operational security measures developed to prevent foreseeable cyberattacks that exploit broadband wireless communications equipment designed for consumer use on board aircraft operated by covered air carriers; and

• The steps taken by covered air carriers, covered manufacturers, and communications service providers to implement the measures described above.

Moving Forward

Markey is a rather junior Democrat on the Senate Commerce, Science and Transportation Committee. Normally this might provide him sufficient influence to have the Committee consider this bill. But slightly different versions of the HR 636 amendments that formed the basis for this bill were already considered and rejected by moderately bipartisan votes in the Committee during markup of S 2658. The Committee is extremely unlikely to take up this bill with that history.

Commentary

It looks like Markey is trying to make a name for himself as the cybersecurity Senator. He is well out in front of his colleagues in suggesting detailed legislative solutions to cybersecurity problems that most of his compatriots have not yet recognized as being serious problems. At this point that kind of leaves him as a voice crying in the wilderness. How long he will be willing to continue to do this in the face of general opposition in the Senate is an interesting political question.

Of course it will take a single high-visibility cyber incident to change Markey from a political odd ball into a prophet. If such an incident (probably with loss of life) occurs during the remainder of this session of Congress, we can expect that this bill would probably form the initial basis for the knee jerk reaction of the Senate.

With that in mind, let’s look at some of the problems that arise in legislation when politicians try to get too detailed in their technical mandates. The use of the term ‘critical software systems’ unnecessarily limits the application of this bill. It should instead read ‘critical control systems’ or maybe ‘critical electronic systems’ if one wanted to include electronic communications systems in the cybersecurity coverage. The way the bill is currently written, for example, completely ignores firmware issues.

In section 6 of the bill we see a similar problem with the use of the term ‘broadband wireless communications’ to describe potential cybersecurity problems caused by customer communications equipment. While wi-fi connections are a potential route of entry into critical aircraft systems, they are not the only consumer communications mode that may cause problems. Cyber radio and even potentially cell phone traffic could prove to be problematic in future configurations. To allow the broadest application of the intent of this section this probably would have been better written as ‘consumer communications equipment’.

One of the complaints I have heard repeatedly from cybersecurity specialists when we start talking about legislation in this realm is that such legislation is likely to be out-of-date or inadequately focused before the legislation is passed. Legislation like this bill is certainly what they are talking about. Legislation needs to be broadly written to allow the regulators with at least some technical background to address the changing technological environment in which the regulated industry operates.

Not only are legislators likely to get the technical details wrong, but legislators take even longer to adapt to change than do regulators. When you add the legislative delay on top of the regulatory delay you end up with obsolete regulations attempting to control completely unforeseen circumstances.

FRA Publishes 30-day ICR for Accident Reporting Form

Today the DOT’s Federal Railroad Administration published a 30-day information collection request (ICR) notice in the Federal Register for changes that it is proposing to make to their accident and incident reporting requirements for accidents involving crude oil trains. The 60-day ICR was published in April and I submitted comment to that ICR based upon a blog post made a few days before that were based on a draft version of the ICR that was published along with the FRA’s Emergency Order 30.

I mentioned my comment submission because a large portion of today’s ICR notice is taken up with the FRA’s responses to my comments (though they did get my first name wrong – Patrick not Peter).

The FRA somewhat agreed with my suggestion that an entirely new form would be needed to collect the data needed for a complete analysis of the crude oil train accidents. They noted that that was beyond the scope of the current ICR (which legitimately was for a revision to an existing reporting requirement) and reported that they intend “to continue considering other options for gathering additional information concerning rail cars carrying crude oil (and other hazardous materials) involved in reportable accidents”.

That was the only positive response to my comments. In response to my comment about their handling of residue cars the same as filled railcars, they noted that they were already doing that for all other railcar reporting requirements on the form. And to my complaint about the lack of data collection about railcar types and failure rate analysis they responded that would be considered in future rulemaking activities as well.

The FRA is soliciting public comments upon this ICR submission. Comments should be submitted to the OMB’s Office of Information and Regulatory Affairs (OIRA) by September 11^th, 2015 and may be submitted via email (oira_submissions@omb.eop.gov).

NOTE: While my suggestions and comments were not actually adopted in this instance, at least my comments were heard and considered. I urge anyone with an interest in Federal regulatory affairs to take any opportunity that is provided to respond to the governments. You may not get to see the changes you want to be made, but it is probably the only way that an individual American is going to have a direct chance to influence Government without spending a ton of money.

FRA Publishes Incident ICR Revision

Today the DOT’s Federal Railroad Administration (FRA) published a 60-day information collection request (ICR) revision notice in the Federal Register (80 FR 23069-23071). This is the same incident report ICR notice that I discussed earlier in conjunction with the documents released last week by DOT concerning the additional actions that DOT is taking to reduce the risk from crude oil trains.

The FRA is soliciting public comments on this ICR notice. Comments may be submitted via the Federal eRulemaking Portal (www.Regulations.gov; Docket # FRA-2015-0007). Comments should be submitted by June 23, 2015. My comment was submitted today.

PHMSA Revises Time Standard for Reporting Pipeline Incidents

Today the Pipeline and Hazardous Material Safety Administration published an advisory bulleting (ADB-2013-01) in the Federal Register (78 FR 6402-6403) revising the expected reporting time frame for pipeline accidents and incidents for which pipeline operators are required to provide telephonic or electronic reports to the National Response Center. The notice also notes that PHMSA will be issuing new regulations formalizing that expected response time in accordance with §9 of the Pipeline Safety, Regulatory Certainty, and Job Creation Act of 2011 (PL 112-90).

Current regulations (49 CFR §191.5 and §195.52) require pipeline owners and operators to notify the NRC by telephone or electronically at the earliest practicable moment following discovery. In a 2002 advisory notice (67 FR 57060) PHMSA clarified that “at the earliest practicable opportunity” usually means one-to-two hours after discovery of the incident. In this advisory PHMSA is changing that guideline to one-hour.

The advisory goes on to explain that the information to be included in that initial report includes:

• The name of the operator;

• The name and telephone number of the person making the report;

• The location of the incident;

• The number of fatalities and injuries; and

• All other significant facts that are relevant to the cause of the incident or extent of the damages.

PHMSA will be issuing a regulatory change to reflect these new requirements.

Analysis of S 3414 – Critical Cyber Infrastructure

This is part of an ongoing in-depth review of the provisions of S 3414, the Cybersecurity Act of 2012, that will be of interest to the control systems community. The first post in the series was:

Analysis of S 3414 – National Cybersecurity Council

In today’s posting I will look at the provisions of §103 which deal with the identification of critical cyber infrastructure. This is important as the only private sector entities that will be directly affected by the provisions of this bill will be those so identified.

Risk Assessments

The bill requires {§102(a)(1)(A)} that an agency from within the members of the Council be appointed to conduct high-level risk assessments of cyber risks to critical infrastructure. There are two separate protections provided that ensures that private sector participation in this risk assessment process is voluntary. First the bill states that the participation will be voluntary {§102(a)(1)(A)} and then it specifically states that {§102(a)(1)(B)}:

“Nothing in this subsection shall be construed to give new authority [emphasis added] to a Federal agency to require owners or operators to provide information to the Federal Government.”

Clearly there is a minor conflict between the two provisions. If the Federal Government already has authority to compel the provision of cyber security information, then that information can presumably be used in the conduct of risk assessments. Some sectors that are already compelled to submit cybersecurity data include the nuclear sector and CFATS covered facilities.

It is intended that the lead agency conduct this assessment in a cooperative fashion with other government and private sector agencies. Some of the private sector entities specifically listed in this cooperative requirement are {§102(a)(2)}:

• Critical Infrastructure Partnership Advisory Council (CIPAC); and

• Information Sharing and Analysis Organizations (ISAO)

Readers are reminded that there is an influential control systems organization within CIPAC, the Industrial Control System Joint Working Group (ICSJWG). They will be an invaluable resource for conducting the risk assessment of control systems.

The agency conducting the risk assessment is required to establish a process by which “owners and operators and other relevant private sector experts” {§102(a)(3)(A)} can provide input into this process. Given the tight timeline required for the initial assessment (180 days), it is unlikely that the ‘process’ will be established soon enough for much participation in the initial assessment, but this assessment will be updated on an “ongoing basis” {§102(a)(2)(B)} so we would expect more input at that stage of the process.

The completed risk assessments will be submitted to the President, appropriate Federal agencies, and Congress. The assessment will be submitted in both a classified and unclassified version. Since an unclassified version is being required to be produced, it would seem to me that requiring the public publication of that version should be required in this bill. At the very least  CIPAC, the ISAOs and the owners and private sector entities that participated in the development of the risk assessment should also be included in the distribution of the unclassified version.

Identifying Critical Cyber Infrastructure

Section 102(b) requires the establishment of procedures for the identification of categories of critical cyber infrastructure. Again it is clearly enumerated within this bill {§§ 102(b)(1) and 102(b)(2)(B)} that the process will be a cooperative one involving Federal agencies, CIPAC, ISAOs, owners, private sector entities as well as State and local government agencies.

The definition of ‘critical cyber infrastructure’ is a rather wide ranging operational definition. It is defined by the resulting damage that can be done by damage to or unauthorized access to such critical infrastructure. The bill limits coverage to infrastructure which could result in {§102(b)(3)(B)}:

• The interruption of life-sustaining services;

• Catastrophic economic damage to the United States; or

• The severe degradation of national security or national security capabilities.

Interestingly, most high-risk chemical facilities covered under the CFATS program, even those where large mass casualty events could occur, would not be able to be designated as critical cyber infrastructure under this definition. Water treatment plants could be covered, but chlorine producers could not. It is questionable if even a large petrochemical refinery could be covered because of the vague definition of ‘incapacitation of or sustained disruption of a transportation system’ {§102(b)(3)(B)(ii)(III)}. Even an electrical transmission system entity might not fall under the ‘life-sustaining services’ description because of a lack of ‘a mass casualty or mass evacuation’ outcome {§102(b)(3)(B)(i)}.

There is another significant limitation of critical cyber infrastructure. In order to appease people concerned with the regulation of the internet as an infringement of first amendment rights, the bill specifically prohibits identification of an entity as ‘critical cyber infrastructure’:

• Infrastructure based solely on activities protected by the first amendment {§102(b)(5)(A)};

• An information technology product based solely on a finding that the product is capable of, or is actually, being used in critical cyber infrastructure {§102(b)(5)(B)}; or

• A commercial item that organizes or communicates information electronically {§102(b)(5)(C)}.

Notification

The bill provides that within 10 days of the determination of an entity being identified as critical cyber infrastructure the Council will notify both the owner and Congress of that determination. There is no provision in this section for appeal by an owner of the designation, but there is 60-day window for Congressional action on the designation before the designation takes effect. Under our current and foreseeable situation of Congressional stalemate, it is unlikely that either house of Congress much less both, could take action during that time frame.

Incident Reporting Requirements

There is one paragraph in this section that does provide an affirmative requirement for action to be taken by any entity designated as critical cyber infrastructure. Section 102(b)(4) requires that:

“The Council shall establish procedures under which each owner of critical cyber infrastructure shall report [emphasis added] significant cyber incidents affecting critical cyber infrastructure.”

The definition of ‘significant cyber incident’ is provided in §2(24) of the bill. It defines such an incident in terms of what happened or could have happened as a result of the incident. Two such results are included:

• The exfiltration of data that is essential to the operation of critical cyber infrastructure; or

• The defeat of an operational control or technical control, as those terms are defined in section 708, essential to the security or operation of critical cyber infrastructure.

Nothing in this reporting requirement requires that actual damage of the critical cyber infrastructure takes place or that any outside entity is damaged in any way.

Reporting Cybersecurity Incidents

The Repository of Industrial Security Incidents (RISI) is an independent organization that collects and analyzes information about, and reports on, cybersecurity incidents involving industrial control systems. This weekend they announced a new online incident reporting form that allows for the anonymous reporting about industrial control system security incidents.

There is no other organization that (sorry ICS-CERT) that has a similar mandate. Since this is a non-governmental organization they have no way of requiring facilities to report these incidents. They rely on voluntary reporting and public news reports to maintain their data base of industrial control system security incidents.

RISI provides an incentive for reporting incidents; they provide one month of free access to reports and information to anyone reporting an ICS security incident. This will, of course, require some self-identification, but RISI maintains strict confidentiality. They note on their web site that:

“All reporting to RISI is strictly confidential. The security of all submitted information is of critical importance to RISI and all sensitive references are removed (and not masked) so there is no risk to the contributor or company. In addition, the investigative database is not available on line so identity data is not at risk from cyber theft.”

I would like to urge all readers working in chemical facilities (and any other facility that uses industrial control systems) to utilize this new reporting form to report any industrial control system security incidents. If the incident is an apparent attack, by all means report to law enforcement authorities first, but please follow-up with a report to RISI.

DHS Incident Reporting Page Update 06-02-11

On Thursday DHS updated their web page for incident reporting. They added a new section and removed a section that was on the earlier version of the web page.

See Something Say Something

The added information is a section at the top of the page for the Department’s “See Something Say SomethingTM” campaign. It advises people to report suspicious activity to the local police and to dial 911 in the event of an emergency. It also provides a link to the web site for “See Something Say Something” campaign.

This is, of course, good information, but it is a sad comment on the state of security awareness in the country when a Federal agency like DHS has to take this kind of formal effort to push a publicity campaign to get the public to report suspicious activity to their local police.

FBI Removed from Site

The 4S blurb actually replaces a section found on the earlier site for reporting suspected criminal or terrorist activity. That earlier section urged reporting to the FBI instead of local police and provided multiple links to the FBI. That section didn’t provide a distinction between suspicious activity and an emergency situation which would require notification via 911.

Sadly, when the 4S section was added it did totally replace the earlier information and there is now no link to the FBI on this web page. It’s sad because the FBI is the agency on the Federal level that is tasked with investigating terrorism. Of course, one would like to think that a suspicious activity report specifically linked to a possible terrorist attack submitted to the local police would automatically be forwarded to the FBI in a timely manner.

Now I understand that the distinction between what suspicious activity should be reported to the local police and which should be reported directly to the FBI is a fairly sophisticated concept. I would suggest, however, that someone who is going to look for a DHS web site on incident reporting to look for suspicious activity contact information is probably capable of understanding that distinction if even a modicum of writing talent is used in the explanation.

Missing Information

This site provides contact information for reporting suspicious activity for immigration issues, chemical facility issues, computer issues and activity in and around Federal Buildings. It doesn’t, however, provide contact information for incidents involving either transportation or maritime related activity. I don’t understand why the two largest counter-terrorism programs within the Department (TSA and Coast Guard/MTSA) are ignored like this.