Review - HR 7174 Introduced – NCFI Reauthorization

Earlier this month, Rep Slotkin (D,MI) introduced HR 7174, the National Computer Forensics Institute Reauthorization Act of 2022. The bill would reauthorize the Secret Service’s NCFI through 2032 and expand the scope of responsibilities for the Institute. It would make several changes to 6 USC 383, including adding a list of definitions of key terms. The bill does not include authorization for expenditures to support these changes.

Moving Forward

Slotkin and a number of her 14 cosponsors {including Chairman Thompson (D,MS) and Rep McCaul (R,TX)} are members of the House Homeland Security Committee to which this bill was assigned for consideration. This means that there is certainly sufficient influence to see this bill considered in Committee. This bill will certainly be approved in Committee by a substantial bipartisan majority. The bill will likely be considered in the full House under the suspension of the rules process.

Commentary

The addition the three definitions to the bill ensures that the control system security issues fall within the scope of the NCFI. But it does point out once again that there is a disconnect in cybersecurity definitions in the US Code. Here, for example, the bill uses the control system inclusive definition of the term information system while also defining the term ‘incident’ by reference to a section of 6 USC that uses the IT restrictive definition of that term. Technically, that means that in this section wherever the term ‘information system’ is used it includes control systems, but where the term ‘incident’ is used control systems are excluded. I have discussed this problem many times before, but most explicitly here.

For more details on the provisions of this bill, including a look at the expanded responsibilities for NCFI, see my article at CFSN Detailed Analysis - https://patrickcoyle.substack.com/p/hr-7174-introduced - subscription required.

HR 3490 Passes in House

This afternoon the House passed HR 3490, the Strengthening State and Local Cyber Crime Fighting Act, by a voice vote after only 14 minutes of debate. The bill will proceed to the Senate where, if it is considered, it will likely be under their unanimous consent process with even less debate.

The bill and the National Computer Forensics Institute both continue to ignore potential issues with forensics investigations of attacks on industrial control systems. If the Senate Homeland Security and Governmental Affairs Committee does take up consideration of this bill (probably unlikely) it would be nice to see some sort of language encouraging the development of forensics capability for ICS attacks before they become necessary.

DHS Publishes CyberFETCH 30-day ICR Notice

Today the DHS S&T Directorate published another sloppy information collection request (ICR) notice in the Federal Register (78 FR 66949). This ICR renewal supports the relatively new (2011) CyberFETCH Program. CyberFETCH is a collaborative environment for cyber-forensics practitioners from law enforcement, private sector and academia.

Editorial Errors

Once again the S&T notice includes a wrong Docket #. The Docket # provided (DHS-2013-0021) is for a Customs and Border Patrol program (019 Air and Marine Operations Surveillance System (AMOSS) System of Records). The correct Docket # is DHS–2013–0047. The notice does not include the OMB Control # for the currently approved ICR (1640-0017), nor does it include a reference to the Federal Register page number for the 60-day ICR notice.

Oh, and this ICR renewal was already sent to OMB on September 30^th. That submission says that the 30-day notice was published in the Federal Register on the same day as the 60-day notice.

Now none of these errors go to the substance of the ICR or the CyberFETCH program, but they do indicate a high degree of bureaucratic ineptitude. Some will argue that that is not necessarily a bad thing in a technology organization, but it certainly reflects poorly on the management skills in the Directorate.

The Collection Burden

This notice and the earlier 60-day notice report no changes in the burden estimates for the program. This seems a little bit odd since the currently approved ICR was prepared before the site was established and was a reasonable attempt to estimate the level of participation. Additionally, since this ICR is for the Registration Form, I would think that the rate of new registrations would start to fall off unless there was a new push to get people to participate.

In any case S&T estimates that there will be 1000 new registrants to the program every year for the next three years. It will take 15 minutes to fill out the registration form (it isn’t that complicated) for an estimated annual burden of 250 hours. This is certainly not an unreasonable burden for the potential information sharing and expansion that this program may engender.

The CyberFETCH Potential

I generally think that having a semi-secure environment were cybersecurity professionals can share information on cyber-forensics is certainly a good idea. Since the CyberFETCH activities go on behind semi-closed doors and I am not a member (since I am certainly not a cyber forensics practitioner) I am not able to report on how well this site is serving its intended purpose. I do hope that it includes some active discussions and information sharing on control system forensics as this is an area that needs whatever help it can get.

Cyber Forensics

The debate about the Illinois Water Hack continued this weekend with two different security experts pointing out that DHS and the FBI did not say that there wasn’t a hack, just that they couldn’t find evidence of a hack. The difference is not that subtle and according to these two unrelated authors may be more than just political correctness.

Lack of Forensics

Joe Weiss, in a short posting on his blog over at ControlGlobal.com, said it most plainly:

“The point of the [DHS ICSB-11-327-01.pdf] statement was "no evidence". That means not only could they not confirm a cyber intrusion occurred, they could not confirm a cyber intrusion did not occur.”

He goes on to point out that there is no data log for communications with the disabled pump so that there is no way to determine with certainty if the system unnecessarily cycled the pump by command (either a hack or a bug) or if there was some other fault in the system that caused the pump to fail.

Now I have never worked with the control system logs that Joe is talking about, but I have worked extensively with data historians. Our control system had literally thousands of potential data point available. This was simple stuff like valve states (open, closed, moving) and measurement data (temperature, pressure). We had to select which data points we wanted the historian to record because of the memory limitations in our system. Every time we upgraded our control system the available memory expanded as did the number of points that we could monitor; there was always more data available than was recordable.

If you overlay that complexity with a log of the intra-system commands [both within the system itself, with the HMI and any remote access] and data exchanges that occur in a modern control system and I would assume that one would have an even greater problem. Even with today’s cheap memory, a complex control system just produces too much data to record it all.

What to Record

Jake Brodsky in a lengthy comment (he unfairly labels it a ‘rant’) this weekend over on the SCADASEC list (at InfoCritical.com, registration required) addresses this issue with a high-level summary of the type of information that control system logs should contain to allow for at least some level of forensic analysis of control system anomalies. He doesn’t provide a point-by-point analysis (impossible since it would be different for each systems and installation) but gives a general description of the types of information that should be tracked.

It would be nice if regulatory agencies would specify some minimum level of forensic data recording for systems under their purview. I think NERC CIPs attempt this at some level, but I am not familiar enough with those standards to really comment on their forensic recording status. The CFATS program is stuck with their ‘no requirement’ mandate from Congress. The closest they come is stating:

“Recognizing and logging events and incidents is a critical component of network monitoring.” (Risk-Based Performance Standards guidance document, pg 75)

The EPA is even less helpful to water systems since their mandate from Congress is only to require vulnerability assessments and action plans.

Of course, any forensics data recording requirement would have to be risk based to be effective. It certainly would not make sense to require a blending operation without hazardous materials or DHS chemicals of interest (COI) on site to have the same level of recording as a major oil refinery. Nor for a water system with just 2000 customers to maintain the same records as say the Long Beach, CA water system serving millions.

Cannot Prove a Negative

Of course, we have to remember that it is not possible to prove a negative. If the affected water system in Illinois had had extensive forensic data recorded, DHS and the FBI would still have had to say that ‘no evidence has been found’ rather than ‘there was no cyber-intrusion’. With adequate data you might be able to prove (and even maybe prosecute suspects) that an attack has occurred, but you can never be sure that someone hasn’t come up with a new vulnerability to exploit that you weren’t watching.

One last point to remember; in this case there was some sort of data logging, the communications with the system from a Russian IP was clearly recorded and widely reported. I would almost be willing to bet that it was this data point that caused the Illinois Terrorism & Intelligence

Center (the name for the State fusion center for those who are confused about who the initial report came from) analysts to decide that it was a cyber-attack that needed reporting.

OMB Approves CyberFetch ICR

On Wednesday the Office of Management and Budget announced that they had approved the information collection request (ICR) authorization for the DHS S&T CyberFetch program. Approval of this ICR clears the way for S&T to establish their CyberForensics Electronic Technology Clearinghouse (CyberFetch), a secure on-line information sharing environment for cyber forensics professionals.

The OMB approval comes with a “consistent with change” comment. A review of the OMB documents file for this ICR shows that S&T submitted update copies of their proposed Privacy Act Notice, Routine Uses Notice and the CyberFetch Registration Screen. Presumably these are the changes referred to in the approval notice.

As of this morning there is no mention of the CyberFetch program on the S&T web site. Neither is the CyberFetch.org web site yet functional. There is no telling how much longer it will be for this program to get up and running.

ICS-CERT Monthly Monitor

Friday the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) published the latest edition of their ICS security newsletter, the ICS-CERT Monthly Monitor; which this issue covers two months. A number of interesting topics are covered in this issue, including Spear Phishing, Black Hat 2011, the Siemens fiasco and preserving cyber forensics data.

Spear Phishing

A nice article on Spear Phishing notes that ICS-CERT has been responding to an “increasing number of spear phishing attacks”. One would assume that when ICS-CERT got involved it was a successful spear phishing attack where something ‘malicious’ was noted on the attacked network. It is interesting to note in the article (mentioned in passing as it were) that the apparent response to a successful spear phishing attack involves shutting down the corporate email system “until the extent of the problem [is] known and mitigation steps [are] taken”.

Black Hat Briefings

The brief piece on the Black Hat Briefings conference provides a brief bit of information from the conference that I haven’t seen mentioned elsewhere; the description of an airborne hacker tool. The wireless aerial survey platform (WASP) is apparently a remotely piloted vehicle that would fly over an installation trying to detect and intercept Wi-Fi and cell transmissions. With the increased use of wireless communications between control systems components, this could provide another route of access into the control system network. Of course, high-risk chemical facilities should already be concerned about the use of RPVs for surveillance or even attacks, so this is just one more reason to acquire sophisticated anti-aircraft attack capabilities (just a little sarcasm).

Siemens

The brief piece on the Siemens issues provides essentially a summary of their summarizing advisory that I have previously addressed. I would like to suggest that an alternative analysis of the ICS-CERT approach to the Siemens issues can be found at Ralph Langner’s recent blog posting on the issue. Anyone who has read Ralph’s stuff on Stuxnet will not be surprised that he has been less than enamored with the response of ICS-CERT on much of anything to do with Siemens.

Cyber Forensics

There is a relatively lengthy piece on cyber forensics and the importance of planning for how to respond to a cyber incident. Most facilities will be focusing on getting their systems back into the normal functional mode when something goes wrong with their system (either from an attack, human error, or just a glitch piece of equipment/software). Cyber forensics is used to determine why and how a problem occurred and is important in figuring out how to limit the current problem and prevent it from happening again. This piece is well worth the read and further exploration. Some of the techniques suggested for preserving forensics data would normally fly in the face of standard procedures for quickly restoring functionality, but with more cyber-attacks occurring, facilities really need to consider these techniques as a method of discovering the true extent of what happened.

Other Information

There is also a nice text box describing the wonders and benefits of ‘coordinated vulnerability disclosure’. ICS-CERT has a vested interest in the CVD process, so they can be expected to support it. It seems to me that when the process works (ie: the vendor responds promptly and puts forth a reasonable effort to fix the problem) this system provides the most effective method for identifying and responding to vulnerabilities. When there is no response, or an inadequate response, then alternate methods of communication need to be used.

Finally, the Monitor closes with two pages of ‘Open Source Situational Awareness Highlights’; a listing or articles and blog posts of significance to the control system security community. While certainly not an exhaustive bibliography, it certainly provides a pretty good reading list. I was impressed that there are a couple of blog posts included in their list (none of mine, alas). I would have been more impressed if they had included a listing of some posts by people like Ralph Langner or Dale Peterson that questioned the various responses of ICS-CERT to cyber security issues, but that would be expecting a bit more objectivity than is probably reasonable.

In short, this is a fairly impressive newsletter by a government agency that is small but important cornerstone of the Federal response to cyber security issues in industrial control systems. Everyone in the ICS security community should read it.

DHS S&T Cyber Forensics ICR – 30 Day Notice

On Monday DHS Science and Technology (S&T) Directorate will be publishing (actually available on the web today) a 30-day information collection request (ICR) notice on their proposed CyberForensics Electronic Technology Clearinghouse (CyberFETCH) program. According to the Notice:

“CyberFETCH is responsible for providing a collaborative environment for cyber forensics practitioners from law enforcement, private sector and academia. This clearinghouse will enable its users to share information, best practices and lessons learned within a secure collaborative environment. In order for a user to access this clearinghouse, he/she must complete a registration form to establish a user account.” (76 FR 22910)

More detailed information on the program was available in the 60-day notice published back in February. Public comments on this ICR are solicited. Comments may be filed via the Federal eRulemaking Portal (http://www.regulations.gov/, Docket # DHS-2011-0021). Such comments should be filed by May 25, 2011 to ensure consideration.

Cyber Forensics Clearinghouse ICR

Today the DHS Science and Technology Directorate published a 60-day information collection request (ICR) notice in the Federal Register for a new information sharing program that S&T is planning on establishing to aid in the expansion of computer forensics techniques.

The ICR would allow the CyberForensics Electronic Technology Clearinghouse (CyberFETCH) program to collect personal information that would be used to “determine the authenticity and suitability of the practitioner requesting access” (76 FR 7871). Once properly vetted the ‘practioner’ would be authorized secure access to the CyberFETCH clearing house that allows “users to share information, best practices and lessons learned within a secure collaborative environment”.

Public comments on this ICR are being solicited by S&T and should be submitted by April 12, 2011. Comments can be submitted via the Federal eRulemaking Portal (www.regulations.gov; Docket Number DHS-2011-0004).

Cyber Forensics Basics

As usual, Joe Weiss writing at Control Global.com provides some thoughtful contributions to the cyber security debate. Earlier this week he had a brief posting about the topic of cyber forensics that is well worth reading. For readers of this blog that are not control system cognoscenti a better understanding of Joe’s comments will require another brief session of Control System 101. Process Forensics Computer based control systems have evolved over time and a large part of that evolution has been driven by the memory available in those computers. As available memory has increased over time, so has the complexity of the instructions, the number of devices controlled and the amount of information retained in the system. With the first computer control system that I worked with we could go back and query the system and obtain information about weights, temperature and pressure at any point in the process for a particular manufacturing batch as long as we did it before the next batch was started; the memory had to be cleared before the next process could begin. This information was an important tool in diagnosing process upsets. The next system that was installed at the facility provided that same information to a data historian, a separate computer program that recorded the information in a data base that could be accessed for a much longer time. This increased the utility of the information, but it was still restricted to measurement data; it provided no data on the inputs to the processing system that affected the system. You could, for example, tell that a batch temperature increased, but you could not tell why. Was it because a steam valve was left open too long? Or, was it because an undesirable side reaction was taking place? The information provided could tell us what went wrong, but not why. The next computer upgrade provided significantly more memory and allowed us to begin to tie operating controls into the system in a new way; we could begin to tie control device status into the data historian. This meant that we could track when valves opened and closed; or it did when we replaced the existing valves with more complex (read expensive) ones that had the capability to communicate their status to the control systems. This was the introduction of smart controls in our facility. The next software upgrade allowed us to track the operator commands used to control the system. We could then track when an operator told the steam valve to close, when it started to respond and when that valve was completely closed. This allowed us to gain finer control over batch quality as the time lag between command and operation affected key parameters of the process. All of the above deal with process forensics, being able to go back and look at what occurred during the manufacturing process that caused the product to turn out the way that it did. Process forensics are a critical tool for the process engineer or process chemist to diagnose process upsets and to make the manufacturing process more efficient. Cyber Forensics Cyber forensics is the next step in the industrial control system development process. As process automation allows for more and more computer decision making in the manufacturing process it becomes important to be able to analyze how that control is executed. Ideally the systems engineer will need to know what inputs the computer received from smart devices, the instructions/commands received from outside of the computer, and what instructions/commands the computer actually executed. Unfortunately, we are still at the equivalent of the “weights, temperature and pressure” stage of cyber forensics. Until systems engineers have tools similar to what are currently available to process engineers, they will have to make semi-educated guesses about root causes for control systems failures. And that makes it very difficult to differentiate between an internal system error, a system-system interaction error, a system-human interaction error, and a cyber attack.

Cyber Forensics

There is an interesting, if brief, blog by Joe Weiss over on ControlGlobal.com. It takes a look at an intriguing issue, how do we know that there have been ‘attacks’ on the control systems for the electric power industry? He references a CSPAN radio interview with Siobhan Gorman, the writer from the Wall Street Journal who broke the story. Joe notes that she said that “the intelligence agencies installed special detection mechanisms that picked up the evidence, not the power companies”. Why Cyber Forensics? Joe goes on to make the comment that the “control system cyber forensics [emphasis added] for power companies, and other industries, are marginal at best”. Just what does the term ‘cyber forensics’ mean? It is basically a combination of software and hardware system components that allows an investigator to go back and determine how and why the control system did what it did. Many control systems have some cyber forensics capability. In the chemical facility where I worked it was a fairly routine part of incident investigations for all sorts of process upsets. We would go back and look what commands operators entered into the control system for the process involved. This was a good way to find some of the operator errors that led to or complicated the incidents under investigation. What Joe is talking about in his blog is a bit more complicated than just looking at keyboard command logging. It potentially includes looking at records of all of the system communication; that is communications between the various components that make up the control system. This is the basic reason that the comprehensive forensics capability is lacking in most software; maintaining a record of all of the communications is memory intensive and does little to help process engineers and chemists do their jobs of process monitoring and process improvement. Requiring Cyber Forensics Capability Joe asks a good question at the end of his blog: “If the intelligence agencies do have this capability [to install special detection mechanisms], why isn’t [it] being used throughout critical infrastructure?” There are, of course, many easy answers to that question. The first is that there is no legal basis for requiring that such a capability be installed in any non-governmental cyber system. Additionally, many organizations would be reluctant to give the government that degree of insight into their processes. Finally there is the question of who will pay for this capability. Many of these questions could be answered by requiring cyber forensic capability in all critical control systems in what ever cyber security legislation comes out of Congress this year. For high-risk chemical facilities this issue could also be addressed in upcoming re-authorization legislation for CFATS, but that would require a fundamental restructuring of the risk-based performance standards basis for the current program. Cyber Forensics will not Prevent an Attack One important thing to remember though is that cyber forensics capability will not prevent an attack. It only allows one to go back and determine, after the fact, that an attack has taken place, how the attack was carried out, and potentially allowing investigators to determine (and hopefully prove) who conducted the attack. Even the hardware and software capability is not sufficient to allow these determinations to be made; it still requires a trained investigator to sift through the recorded information. Lacking a trained computer forensics investigator at every critical facility what is needed is a software expert system that can identify unexpected communications with the system and the ability to alert the facility computer security officer (CSO). This will still require that the CSO will at least have basic forensic training to evaluate the situation and determine if expert assistance is required. While this still does not stop an attack, it may allow for timely mitigation of the effects of the attack. CSO Action Required While Congress needs to look at the cyber forensics issue, the CSO at high-risk chemical facilities can take some actions to enhance facility cyber forensics capability. First, contact your control system vendor and see what forensic capability already exists in your system. Ask the vendor what cyber forensic support or training they offer. Finally, ask what system upgrades are available for your system to enhance the cyber forensics capability. The answers to all of these questions need to be fed back into your site security plan development.