ICS Security Legislation

In an earlier blog post I wrote that there needed to be a requirement for control systems at critical infrastructure to be registered with ICS-CERT so that they could push control system vulnerability information to those organizations efficiently. A new ‘requirement’ clearly means a regulation and I have not discussed the items that I would like to see that would address control system security. With the Senate promising (yet again) to take up cybersecurity legislation and the leadership desiring to cover ‘critical infrastructure’ in that legislation, it might be a good time to look at what type of requirements may actually work to increase security.

Coverage

While all control systems should have some minimal level of security in place, Congress does not have the support necessary to legislate that requirement. Even if it did, there is not enough qualified manpower in the United States, much less in the government, to provide even minimal oversight of such sweeping regulations. If control system security legislation is to pass it must be limited to cover just those facilities that are critical to homeland security and the health and welfare of large segments of the United States. However that is defined in legislation it will leave holes and draw opposition. That is the way of politics.

Legislators, and their staffs, are, almost by definition, not security experts. We should not expect them to be able to specify any real sort of detailed security procedures in their legislation. Even if they did have the skill, putting detailed security requirements in legislation is an easy way to make those requirements ineffective. First off, with the rapidly changing cyber landscape, the requirements would be out of date before the ink was dry. Secondly, publicly setting detailed requirements would tell our adversaries what areas of attack to avoid, pointing them at new vulnerabilities.

Having said that, any legislation must avoid the problems that currently face the chemical facility security regulations. The CFATS legislation prohibits DHS from specifying any security measure as being required for compliance with the program. While that ensures that each facility has the widest latitude in developing an effective security program, it makes it impossible for DHS to require that holes in that program be plugged. At its heart, this is the reason that DHS has yet to approve any site security program at a covered chemical facility.

Requirements

There are some basic requirements for any control system security program and they should be included in any cybersecurity legislation. They include, in no particular order:

• Network connection map;

• Monitor network communications;

• Role based access control;

• Patch and update management;

• Security breach reporting program; and

• Security training

Security managers that do not know what is connected to their control system network cannot establish and maintain a security program that will protect that network. This includes knowing what ports are available and ensuring that appropriate controls are put into place for each port.

The monitoring of network communications is an essential part of every cybersecurity program. Knowing what communications are normal on the network is a prerequisite to identifying attacks in progress.

Any type of security program, cyber or otherwise, must include a program for establishing who has access to what portions of the secured area. Access controls for cyber-systems need to establish who has what level of access to the system. For critical infrastructure the access control system absolutely needs to include a personnel surety program where background checks and even a Terrorist Screening Database (TSDB) search needs to be done on each person who has a predetermined minimum level of access to the system.

Every control system will have to be patched or updated at some point in time. Procedures need to be put into place to determine what patches are required for the system and to evaluate the effects each patch or update has on the system as deployed. For critical infrastructure systems this should include registering the system with ICS-CERT so that any security problems are identified to the system owner as soon as ICS-CERT becomes aware of the potential vulnerability.

Because there are a number of business reasons that an organization may not want to report a security breach, a critical infrastructure facility must be required to report any breach that is detected. This is necessary not only to help protect that installation, but to allow facilities with similar systems to prepare for the same type of attacks.

Finally, no matter how well a security program is put together, it will absolutely fail if all personnel who operate that system are not adequately trained in all of the security measures and techniques employed to protect the system. Training should be role-based and needs to be updated any time significant changes are made to the systems.

Other Requirements

I know that there may be other security program requirements that could be added to the above list, but I’m not sure that they would be as universally applicable. For example one could require that each covered critical infrastructure control system have an independent security evaluation conducted on the system; you could use something like the ICS-CERT Cyber Security Evaluation Tool (CSET). While this may be a fine tool, I’m sure that it has not been vetted against all of the potential control systems that might be employed by targeted companies. ICS-CERT certainly doesn’t have enough personnel available to conduct such screenings on all of the potentially covered facilities.

I would love to hear from others in the control system security community about what other general provisions could be added to an ICS security program for all high-risk critical infrastructure control systems. The only restriction that I would ask is that the controls would have to be applicable to nearly all such systems, regardless of the industry involved.