Terrorism Risk Insurance Rule Sent to OMB

Yesterday the Treasury Department sent a notice of proposed rulemaking (NPRM) to the OMB’s Office of Information and Regulatory Affairs (OIRA) concerning revisions to the existing Terrorism Risk Insurance program. While this rulemaking was not listed in the latest Unified Agenda, it almost certainly includes revisions to the program required by Terrorism

Risk Insurance Program Reauthorization Act of 2015 (PL 114-1) that was passed early last year.

Changes should include:

• Program trigger amounts;

• Provisions for the recoupment of the Federal share of compensation;

• Changes to the process of certification of acts of terrorism;

• Establishment of the Advisory Committee on Risk-Sharing Mechanisms;

• Changes to insurer reporting requirements;

At this point there is no way to predict how long it will take OIRA to approve this NPRM.

Configuring and Managing Remote Access for Industrial Control Systems

This afternoon the DHS ICS-CERT published an abstract of and link to an interesting document developed by the British Centre for the Protection of National Infrastructure. The 67 page document addresses the design of systems to allow remote access for ICS.

The ICS-CERT abstract explains:

“Part of the security equation involves how operational assets are accessed and managed and how the cyber security posture of a control system can be impacted if the management of remote access is not understood by business or is conducted poorly. However, the application of proven and accepted remote access solutions may not map perfectly to control systems environments. Requirements for availability and integrity, combined with the unique nuances and attributes often found in ‘purpose built’ systems, drive new demand for guidance as it pertains to creating secure remote access solutions for industrial control systems environments.”

The table of contents lists some interesting topics:

• Remote access in industrial control system architectures;

• Roles and remote access in control system architectures;

• Types of remote access solutions;

• Security Considerations;

• Remote access security considerations unique to control systems;

• Applying good practices;

This looks like an interesting document that should provide some valuable insights. I’ll be looking at it in more detail in the coming days, but this is more of a technical document than the type of thing I address in detail in this blog.

Potential PSP Problems

This is part of a continuing series of blog posts about the recently released Federal Register notice about the implementation of the Chemical Facility Anti-Terrorism Standards (CFATS) personnel surety program (PSP). The notice outlines how the Infrastructure Security Compliance Division (ISCD) is planning to implement the vetting of covered chemical facility personnel and visitors against the FBI’s Terrorist Screening Database (TSDB) to determine if any covered personnel are suspected of having ties to terrorist organizations. Other posts in this series include:

DHS Publishes CFATS PSP Notice

How The Multiple Options in PSP Can Work Together

In this post I will be looking at some of the problems that can be expected to arise as the new terrorist ties portion of the CFATS Personnel Surety Program is put into operation. Some of these potential problems will have reasonable workarounds readily available and others will require programmatic changes by ISCD. This discussion, however, is predicated on my current understanding of the PSP implementation that we have not yet seen published. A lot will depend on the way that ISCD sets up the data submission tool in CSAT.

Multiple Facilities

There are a significant number of companies in the United States that have multiple facilities covered under the CFATS program. ISCD has been accommodating in the past in allowing for these types of organizations to submit data to CSAT from the corporate level that is common to two or more facilities and I suspect that they intend to continue this practice with the PSP.

ISCD has made it clear in their Notice that they would like to see individual TSDB screening tied to facilities so that if subsequent changes to the TSDB turn up terrorist ties, ISCD will be able (law enforcement rules allowing) to notify the affected facility of the problem. While most of the employees whose screening data is submitted from corporate will be tied to a particular facility, that will not be the case for all employees. There will be corporate level personnel that will need to be able to move through all of the covered facilities.

It is conceivable that ISCD would require the information on those corporate level individuals to be submitted on each facility CSAT account. While this would not technically violate the 6 USC 622(d)(2)(A)(i) prohibition of requiring more than one data submission on an individual by a covered facility, it would certainly conflict with the Congressional intent. And it would likely put ISCD in the position of having to pay for multiple TSDB screenings of an individual.

The simplest way around this problem would be for ISCD, in allowing for corporate data submissions for multiple facilities to not tie the names submitted to an individual facility, but rather to the larger organization. That way ISCD would still have a point of contact about the individual in the event of a positive match or question about identification, but the individuals would be able to move about all of the covered facilities within the organization.

Facility Turnaround Contractors

Many chemical facilities (continuous process facilities in particular) conduct periodic facility shutdowns for maintenance called turnarounds. A contractor typically provides a large temporary workforce to quickly conduct the large scale repair, replacement and system upgrades that are part of this maintenance activity. These contractors serve multiple facilities and have a high employee turnover, especially when seen from the facility point of view.

It is extremely impractical for facilities to do individual information submissions for the contractor employees in this type of situation. Additionally, such data submissions would place an unreasonable load on the administration of the PSP at ISCD.

This would be an ideal situation for the use of Option 3. Each of the turnaround employees would be required to have a Transportation Workers Identification Credential (TWIC) and the contractor would be required to operate a TWIC Reader at the contractor entrance to the facility.

Local Delivery Drivers

While a facility may well be able to require over-the-road truck drivers delivering to the facility to have TWIC or HME for facility entrance, that is less likely for local less-than-load truck drivers, and completely beyond the bounds of reason for local deliveries from retail establishments and package delivery services.

The easiest way to deal with these drivers under the PSP program is to exclude them from the program. This can be done by setting up a specially designated delivery location outside of the facility’s restricted area or an area in clear view of the security personnel (either visually or via CCTV). They can be met there by facility personnel and if they have to enter the restricted area they would be escorted during that time.

Electronic Access

Many facilities routinely provide remote access to computer systems to a variety of folks. While employees are already covered under the PSP. A serious problem arises, however, when various outside service personnel or contractors are provided access to covered computer systems. Contractors with routine off-site access can presumably be covered in the same way as on-site contractors are but I would suspect that ISCD is going to want to see strong evidence that the facility has some sort of strong control on a contractors vetting of personnel. What is going to be much more problematic will be large vendors (and especially internationally based vendors) where the facility does not have a significant measure of economic influence on the vendor to require that they limit personnel to those that have been appropriately vetted by the PSP. ISCD is going to have to provide some clearer guidance on this issue.

False Positives

The biggest problem with the PSP program will be the issue of false positive matches with the TSDB. The TSDB is a name-based database that includes little or no biometric information on the individuals on the list. It is inevitable that there will be matches of names submitted by chemical facilities to TSDB listings that actually have no relationship to the individual on the TSDB. I suspect that the rate of false positives will be such that larger CFATS facilities will have to deal with multiple instances of receiving unfounded notifications of possible terrorist ties. All facilities must be prepared to deal with this situation when they submit their initial lists under Option 1.

After the initial data submissions this problem will be less important as most employment agreements will provide for termination of new hires that come back as positive on the TSDB screening in much the same way as drug screens and background checks call for termination and requests for redress will be handled as an individual matter. With this initial data submission for all current employees the situation is quite a bit different. When a key employee comes back with a positive TSDB match that is likely a false positive, then the organization has a stake in the redress process that is not anticipated in the ISCD privacy documentation [Note: this is the latest Privacy Impact Assessment document for the PSP]. The current redress procedures are:

“If you believe that the information submitted by [INSERT NAME OF CFATS COVERED FACILITY AND OF THEIR DESIGNEE(S) (IF APPLICABLE)] has been improperly matched by DHS to the identity of a known or suspected terrorist, you may write to the NPPD FOIA Officer at 245 Murray Lane SW, Washington, D.C. 20528-0380. You may also request an administrative adjudication under CFATS [6 CFR 27.310(a)(1)].”

Facilities are almost certainly going to need to have procedures in place in their newly revised SSP to cover how they are going to deal with the receipt of notification of a TSDB match for current personnel. Those procedures are going to have to be able to deal with a relatively new hourly worker, a well-known and respected long-time employee, and a manager coming back with a positive match. If the facility expects to keep any of these employees around during the almost certainly lengthy redress process, they are going to have to be able to convince ISCD that mitigating controls are in place to address the risk that these employees actually do have terrorist ties. I have no idea what mitigating controls other than personal escort might be acceptable to ISCD.

Other Situations Will Come Up

Facilities are going to have to take a hard look at their specific situation to see what areas of their facility are routinely entered by non-employees. Where there is little advance notice of who that non-employee is going to be, facilities are going to have to come up with ways to provide PSP vetted escorts. Where there is sufficient advance notice to provide for execution of one of the four TSDB vetting options, facilities will have to decide in advance how they are going to select the appropriate option.

As more of these complicated situations arise, I would certainly like to hear about them. I would particularly like to hear about those situations where ISCD has agreed to an innovative way of dealing with the problem.

ICS-CERT Updates Two Advisories

This afternoon the DHS ICS-CERT published to advisory updates; one for a December advisory for vulnerabilities in Advantech’s EKI devices; the other for a November advisory for vulnerabilities in Unitronics’ VisiLogic OPLC IDE devices.

Advantech Update

This update adds a new authentication vulnerability (CVE-2015-7938) and reports that Advantech published firmware updates for all four vulnerabilities on December 31^st, 2015. Interestingly it also removes reference to this being an uncoordinated disclosure.

Unitronics Update

This update adds a new code injection vulnerability (CVE-2015-7939) and reports that an even newer update is now available that presumably addresses all three vulnerabilities.

Vulnerability Descriptions

An interesting article yesterday over at DarkReading.com that looked at default passwords was well worth reading for that reason alone, but an even more important aspect was buried towards the bottom of the article. Kelly Jackson Higgins looked at a recently released control system vulnerability and brought out more details from the researcher than were published in the related ICS-CERT advisory on the vulnerability.

The Vulnerability

Last month the DHS ICS-CERT published an advisory for a buffer overflow vulnerability in the Schneider Modicon M340 PLC. The Advisory described the vulnerability in this way:

“David Atch of CyberX has identified a buffer overflow vulnerability in Schneider Electric’s Modicon M340 PLC product line. Schneider Electric has produced a new firmware patch to mitigate this vulnerability.”

In yesterday’s article Higgin’s described the vulnerability in more detail”

“CyberX found a buffer overflow flaw in the products that can be exploited when a random password of between 90 and 100 characters is typed into the PLC's web interface. It basically crashes the device, and allows an attacker to execute code remotely.”

The publicly available Schneider Security Notice (.PDF Download) for the vulnerability provides even more details about the vulnerability which is actually in the Ethernet communication module for the PLCs:

• The attacker enters a password greater than 65 characters into the Password field (Generally between 90-100 characters is enough to cause the device to crash) and presses OK (no username is required).

• The web server handles the request and attempts to copy the oversized password into a 65-character buffer using strcpy(), which is void of buffer length protection.

Advisory Deficient?

Obviously, the Advisory from ICS-CERT does not provide the same level of detail as found in the Schneider Notice. The question is whether or not the Advisory is in some way deficient because of that lack of detail. To be sure, ICS-CERT does provide a link to the Schneider site where the Notice can be downloaded, so, in a round-about way the information is available to the reader. The question is, is that good enough?

ICS-CERT maintains that, as part of their disclosure policy that:

“After coordinating with vendors and gathering technical and threat information, ICS-CERT will take appropriate steps to notify end users about the vulnerability. ICS-CERT strives to disclose accurate, neutral, objective information focused on technical remediation and mitigation [emphasis added] for asset owners and operators.  ICS-CERT will reference other available information and correct misinformation when possible.”

If we look at the information solely for its focus on ‘technical remediation and mitigation’ ICS-CERT can be forgiven for not openly providing the same sort of detailed information on the mechanism of the vulnerability that is provided in the linked Schneider Notice. That information does not directly affect the ‘remediation and mitigation’ of the vulnerability.

On the other hand, only two major vendors routinely provide public access to vulnerability notices and a similarly limited number provide notices to registered owners. The bulk of the vendors associated with ICS-CERT advisories do not provide any information on vulnerabilities, even in the version notes when those are provided for updates. If this vulnerability were in a device from one of these other manufacturers, the owner would not have access to this information.

How are the Advisories Used?

There is little or no information available on how these ICS-CERT advisories are actually used. There is usually little written about the advisories and most of what is written (other than this blog) is a very brief; one-sentence description and a link to the advisory. The underlying vulnerabilities are sometime discussed in the literature, but one has to follow a number of different publications or writers to keep up with what vulnerabilities have been uncovered. Additionally, there is seldom information readily available about mitigation measures or links for patches and updates from any but a few of the major vendors.

For anyone that is interested in one-stop shopping for information about control system vulnerabilities and their remediation, ICS-CERT is just about the only source. ICS-CERT is to be commended for conducting this outreach effort to try to make this information readily available to the disparate control system community.

With that in mind, I would like to call attention to a couple of sentences that are found in the impact section of every advisory published by ICS-CERT:

“Impact to individual organizations depends on many factors that are unique to each organization. NCCIC/ICS-CERT recommends that organizations evaluate the impact of this vulnerability based on their operational environment, architecture, and product implementation.”

Why is this important? Every facility manager that becomes aware of a vulnerability in their automation control system has to make a very important risk-based analysis of what will be done about that vulnerability in their facility. The cost in time and effort (including acquiring the services of a control system engineer for many facilities) to test and verify that the mitigation measures suggested will work in the unique environment at that facility and then to shut down production to upgrade or update the affected devices can be quite high. Against that must be weighed the potential consequences of a successful attack (or even an accidental ‘attack’ in some cases).

Determining the cost side of the equation will be very simple for most managers. They will be painfully aware of the costs of shutting down operations, something that they are generally striving to avoid at nearly any cost. The consequences of a potential attack are much harder to calculate, particularly since figuring the likelihood of an attack is an integral part of that calculation.

If the manager is using the only one-stop source of control system vulnerability information as the source of information for determining if a vulnerability is of sufficiently high potential cost to justify the cost of shutting down production to fix the problem, then the information provided in this ICS-CERT Advisory probably falls short. A quick read of the Advisory identifies the vulnerability and potential consequence, but could easily leave the manager figuring that at least one mitigation measure is in place; password protected access to the device. That would probably be enough to postpone the fix until the next scheduled turnaround or the next time maintenance has to take one of the PLC’s out of service for another unrelated problem.

What Should We Expect from ICS-CERT?

Given all of this, what should we be expecting from ICS-CERT in the vulnerability advisories? First we have to acknowledge the legal disclaimer at the top of every alert and advisory:

“All information products included in http://ics-cert.us-cert.gov are provided "as is" for informational purposes only. The Department of Homeland Security (DHS) does not provide any warranties of any kind regarding any information contained within.”

Not only is this the type disclaimer that we have become accustomed to in the software world (and that is room for a whole other diatribe), but in a very real sense it specifically applies to ICS-CERT disclosures. ICS-CERT is not actually doing most (if any) of the research that is forming the basis for these information products. ICS-CERT is typically informed of the vulnerabilities by researchers and there are frequently disagreements about the extent (or sometimes even the existence) of the vulnerabilities between the researchers and the vendor. So there is no way that ICS-CERT can provide any guarantees about the information that it does share.

There is also another complicating factor; the whole public disclosure debate. The more information that is made publicly available about vulnerabilities, the argument goes, the easier it is for less skilled attackers to make use of that information to effect exploits against uncorrected systems. So, ICS-CERT has to weigh the amount of information it makes available to owners so that they can make a reasonable decision to fix their systems in a timely manner against providing early information to attackers. This can, for critical infrastructure however, be mitigated by early disclosure via the US-CERT Secure Portal.

The bottom line is that ICS-CERT has to decide, or maybe congress has to decide for them, what their mission is. If they are going to be the link between researchers and vendors and users so that vulnerabilities in control systems are going to be identified and fixed and control systems are going to be upgraded/updated with those fixes, then they are going to have to provide the information necessary to all three parties. For control system users that information is going to have to be as complete a definition of the vulnerability as possible so that a legitimate risk-cost-benefit decision can be made about how and when mitigation measures (including measures other than vendor supplied updates) are applied to the system.

If they are not, or for some reason cannot, be that intermediary between vendors/researchers and the user community, then we are going to have to find/establish that agency that will provide user/owners with the necessary information to make intelligent decisions about when and how patches and updates will be applied. Without that information, the vast majority of control system owners are going to assume that their systems that are working for the intended purpose are fine and updates and upgrades will be considered if and when new tools will make them worthwhile changing. And those systems will be vulnerable to attack.

ISCD Publishes January 2016 CFATS Update

This afternoon the DHS Infrastructure Security Compliance Division (ISCD) published the January 2016 CFATS Update. The latest update shows that the Chemical Facility Anti-Terrorism Standards (CFATS) program continues to progress with authorizing and approving site security plans. ISCD also continues to conduct an increasing number of compliance inspections. The number of covered facilities continues to decrease.

	December 2015	January 2016
Covered Facilities	3,110	3,088
Authorized SSPs	3,258	3,285
Approved SSPs	2,271	2,354
Compliance Inspections	378	450

ISCD continues to report more Authorized SSPs than there are covered facilities. This statistical anomaly means that we have no way of knowing how many facilities currently have Authorized SSPs. It also calls into question how far along the government actually is in approving Site Security Plans (SSP). While the numbers would seem to indicate that there are only 734 SSPs to approve we have no way of knowing if the double counting of Authorized SSPs has been extended to approvals as well.

Even though the GAO complained last year that ISCD was not accurately reporting the number of facilities that had not passed their Compliance Inspection, DHS continues to only report the number of facilities inspected without delineating how many have passed those inspections. With the past problems in mind, this certainly calls into question the efficacy of the inspection process.

It continues to be disheartening to see the decrease in the number of facilities covered by the CFATS program because we have no way of knowing if the decrease is due to programs effectiveness at convincing facilities to stop using the DHS chemicals of interest (COI) that form the basis for being in the program or if the program is pushing companies out of the chemical business due to the cost of security. DHS continues to fail to provide even the most basic information about why the number of covered facilities continues to decrease at a rate faster than new SSPs are authorized.

Having complained about the lack of relevant details being reported (on an ongoing basis) I must take this opportunity to call attention to the fact that the hard-working men and women of ISCD continue to do the day-to-day work of implementing the CFATS program. Visits to facilities to help organizations get their site security plans authorized and approved continued unabated as did compliance inspections during the holiday season. With the unseasonable severe weather last month through much of the country, the dedication and perseverance of the Chemical Security Inspectors is to be applauded.

There will be a number of changes in the CFATS program in the coming year. We will see the personnel surety program completely rolled out and implemented in Tier 1 and Tier 2 facilities. We are likely to see a notice of proposed rulemaking for an update of the CFATS program that may include a change to the risk analysis process that ISCD uses to Tier facilities. Hopefully, the year will also see final action on the ‘temporary’ exemption from Top Screen submissions for agricultural producers. And there is always the possibility that ISCD will finally figure out a cost effective way to implement the Congressionally mandated ammonium nitrate security program.

It is going to be an interesting year. And remember, all we need is one security incident at CFATS covered facility (and given the way the world is heading, that incident is likely to be cyber related) to get increased Congressional attention on the program.

ACC and NACD Update CFATS Alternate Security Plan

Over the holidays the American Chemistry Council (ACC) and the National Association of Chemical Distributors (NACD) published a new updated version of the ACC’s Alternative Security Plan (ASP) for the CFATS program. The original version of the ASP was released three years ago as an easier way for regulated chemical facilities to submit site security plan (SSP) information for the Chemical Facility Anti-Terrorism Standards (CFATS) program.

The goal of the ASP program has been to not only make it easier to submit the information that the Infrastructure Security and Compliance Division (ISCD) of DHS needs to evaluate the SSP, but to also provide the submitting facility with a document that could actually be used in the implementation and day to day operation of the SSP.

The new program includes;

• An ASP Guidance Document (.PDF);

• An ASP Template (with instructions) (.DOCX Download); and

• A set of nine forms to be used with the ASP (.ZIP download)

A quick review of the literature associated with ASP II shows that it does include at least some information from the new legislation authorizing the CFATS program (the Protecting and Securing Chemical Facilities from Terrorist Attacks Act of 2014, PL 113-254), but it does not refer specifically to the new personnel surety program being rolled out by ISCD (understandable since many of the details of that program have yet to be published). It also does not address the Expedited Approval Program (EAP) initiated by ISCD this last summer as an alternative to both SSPs and ASPs.

Long time readers of this blog will undoubtedly remember that I was a big fan of the ASP when it was rolled out (see my series of blogs here). This looks like it will be a valuable update of that program. I am especially glad to see that the NACD has specifically signed on to this as a partner in the revised program.

I will be looking at this revised program in more detail in future posts.