Saturday, February 13, 2016

CG - Application of Cybersecurity Principles

Yesterday the Coast Guard published a copy of “The Application of Cybersecurity Principles to Marine and Offshore Operations” on their Homeport web site (sorry the CG does not use real links on Homeport – You can find this under the Cybersecurity tab). The publication is apparently the first volume in a series of publications on maritime cybersecurity being published by the American Bureau of Shipping.

A quick look at the table of contents looks like the 35-page publication covers the basics of cybersecurity (both IT and OT). It will be interesting to see what specific changes are being recommended for the maritime environment.

There is a nice brief discussion about cybersecurity in general in the first section of the publication. It makes a significant comment that applies to a variety of environments beyond just the maritime (pg 2):

“Most organizations arguably understand the need for protecting and monitoring cyber-linked business support and control systems. Even so, the breadth and complexity of protecting such systems may present a daunting challenge to many organizations that do not have a comprehensive picture of cybersecurity.”

There is also an important discussion of how cybersecurity and safety intersect, particularly in cyber-physical systems (CPS). The authors make an important point (pg 3):

“A cybersecurity incident on a ship, on a platform, or within a facility, might result from system fault or failure, operator error or inaction, inadvertent conflicts in incompatible software, or deliberate malfeasance or malice. Any such incident may result in intrusion or malfunction in a general purpose network, resulting in a cascading failure that can spread into ship or platform CPS to cause unexpected consequences for any number of systems.”

This looks like a document that will be well worth reading by anyone in control system management as well as cybersecurity professionals. Certainly the maritime community should, as the Coast Guard intended, take a specific interest in this publication and the remainder of the series as it becomes available.

Bills Introduced – 02-12-16

Yesterday as the House and Senate prepared to leave for a week long recess there were 31 bills introduced. Of these, only one may be of specific interest to readers of this blog:

HR 4578 To amend title 49, United States Code, to provide for minimum safety standards for underground gas storage facilities, and for other purposes. Rep. Sherman, Brad [D-CA-30]

It is interesting that this bill was introduced on the day that the Porter Ranch gas leak in Southern California was reported as being blocked. It will be interesting to see what ‘other purposes’ were added to this bill’s coverage.

Responses to Latest CSF RFI – 02-13-16

This is part of an on-going look at the responses to the National Institute of Standards and Technology (NIST) latest request for information (RFI) on potential updates to the Cybersecurity Framework (CSF). A reminder, the comment period will remain open until February 9th, 2016. The previous posts in this series include:

This week there were ten new responses to the RFI. This is almost the same as the total number that had been submitted by last Saturday, and they all came before the original deadline. This week’s responses came from:

Prevent Duplication of Regulatory Processes

NIST question 9 asks:

“What steps should be taken to “prevent duplication of regulatory processes and prevent conflict with or superseding of regulatory requirements, mandatory standards, and related processes” as required by the Cybersecurity Enhancement Act of 2014?”

One commenter recommended that the Federal government should consolidate the Federal cybersecurity effort to avoid having multiple requirements from separate agencies. Similarly, another commenter suggested that if the CSF were to become the regulatory standard, that all agency regulations should be based upon that standard. On the other hand, a separate commenter noted that regulatory requirements should be included in the CSF. Alternatively, another commenter suggested that NIST should have greater outreach to Federal, State and local regulators to aid them in developing consistent regulatory schemes.

One commenter noted that as new industry and international standards are developed they should be incorporated in the CSF. Another commenter suggested that the relationship between the CSF and the NIST Risk Management Framework should be clarified.

Should CSF be Updated?

NIST question 10 asks:

“Should the Framework be updated?”

One commenter noted that the CSF should be cautiously updated to reflect changes in evolving cyber technology and the risk landscape. Another commenter suggested that the CSF needs an implementation plan and an assessment tool like DHS’ Cyber Resilience Review tool. Yet another commenter recommended that newer versions of the CSF should focus on critical areas and key mitigation plans like perimeter defense strategies.

Private Sector Involvement

NIST question 20 asks:

“What should be the private sector’s involvement in the future governance of the Framework?”

One commenter suggested that while NIST should maintain responsibility for CSF governance, ISACS should become directly involved in CSF changes. Another noted that industry Organizations like CHIME should become involved in the CSF process. One commenter suggested that the NERC CIP process has shown that a period of stability is needed between revisions of the CSF, so that lessons learned can be properly identified and incorporated.


While the number of commenters that have provided input during the initial 60-day comment period is staggeringly inadequate, the latest batch has a number of interesting and provocative ideas for NIST to consider.

I would like to point out that the majority of the comments received this week were in the CSF comment submission format. This makes the review of the comments much easier. Commenters need to realize that if their intent is to actually influence the CSF improvement process, then making it easier for the reviewers to understand and collate the responses increases the efficiency of the influence.

There were a couple of commenters that seemed to have confused the management tool that is the Cybersecurity Framework and cybersecurity regulations. The CSF is a tool that can be used to analyze the current state of an organizations cybersecurity practices and to figure out what the organizational goals in the field should be and how to achieve them. Regulatory schemes are designed to set minimum standards, establish compliance measures for those standards and ensure that those compliance standards are met. One would like to think that an organization, while having to meet regulatory requirements, would aspire to a higher standard performance. The CSF provides a tool to establish that higher performance level and outline a means to achieve that goal.

Regulatory agencies could certainly use the CSF as a tool for ensuring that their minimum standards reflect industry standards and capabilities. It also provides the necessary references for finding appropriate measurement tools to gauge the effectiveness of responses to regulatory requirements.

But, the CSF is not a regulatory framework. It was never intended to be such and would lose much of its effectiveness if it became one. Probably the greatest advantage of the CSF verses cybersecurity regulations is that it should be easier to update the Framework to reflect changes in the cybersecurity landscape than it would ever be to update regulations. In large part this is because it’s voluntary nature makes organizations much less resistant to changes in the Framework.

Friday, February 12, 2016

Another New PSP FAQ Posted to CFATS Knowledge Center

This afternoon the DHS Infrastructure Security Compliance Division (ISCD) published another new frequently asked question (FAQ) on their CFATS Knowledge Center web page. As with a number of recent additions to the FAQ list, this one deals with the CFATS personnel surety program (PSP) that the Department is in the process of rolling out.

FAQ #1769 asks:

“My facility must perform background checks in accordance with the Risk-Based Performance Standard (RBPS) 12 “Personnel Surety” on affected individuals. Who is an affected individual?”

Typically, these FAQ responses quote from the appropriate portion of the CFATS regulation as the major part of the response. The appropriate part of the CFATS regulation in this case would be 6 CFR 27.230(a)(12):

“Perform appropriate background checks on and ensure appropriate credentials for facility personnel, and as appropriate, for unescorted visitors with access to restricted areas or critical assets….”

In this case the response is in two parts:

• Facility personnel who have or are seeking access, either unescorted or otherwise, to restricted areas or critical assets; and
• Unescorted visitors who have or are seeking access to restricted areas or critical assets.

They go on to explain the difference in the first part from the actual wording of the regulation by noting:

“The regulatory text makes no distinction between facility personnel who are escorted and facility personnel who are unescorted, and uses the term ‘unescorted’ to modify only the noun ‘visitors.’ As such, if facility personnel have access, either unescorted or escorted, to restricted areas or critical assets, they are deemed to be affected individuals who must be screened for the purposes of the Personnel Surety protocol.”


The ISCD folks are being very careful with this distinction because there were a number of comments that they had received during the various information collection request comments periods that made it clear that very many people were under the misapprehension that only facility personnel that had unescorted access to critical areas would require personnel surety checks.

I am more than a little surprised that ISCD did not also take this opportunity to reinforce the other question that is closely related to this one; are contractor personnel ‘facility personnel’ or ‘visitors’? They made it clear in their Federal Register notice that they intend to give facilities the widest possible latitude in determining how contractors, even various groups of contractors will be handled for the PSP. The facility will be required to provide an explanation of how contractors are being handled in the revision to the Site Security Plan that will be made to implement the new terrorist screening portion of the RBPS #12 requirements.

The Actual Drone CI Provision

The information that I received yesterday for last night’s post about drones and critical infrastructure facilities was not as complete as it could have been and as a result I made a small leap to the wrong amendments. While the two amendments that I reported on were submitted for consideration, they were not taken up by the Committee. Instead, Chairman Schuster’s (R,PA) Manager’s Amendment does contain similar language and was adopted by the Committee.

The Schuster amendment still adds a new 49 USC 45509 that adds the requirement I described yesterday for new regulations from the FAA. There is no requirement for covered facilities to register in order to have the regulations apply like we saw in Babin #81.

The very real difference between the adopted Shuster language and the two Babin amendments that I described last night can be found in the definition of critical infrastructure. The Schuster amendment’s definition {§45509(c)} only includes CFATS facilities and MTSA facilities. It does not include water treatment plants, waste water treatment facilities, DOD/DOE owned facilities or NRC regulated facilities.

Moving Forward

HR 4441 was approved in Committee yesterday on a near party line vote. In fact, there were two Republicans that voted against the bill. This means that the bill probably would not pass if it was brought to the floor under suspension of the rules which requires a 2/3rds vote to pass. This means that it would require a rule which would leave open the possibility of further amendments on the floor.

The unanimous Democratic opposition to the bill means that this version of the bill would almost certainly not get considered in the Senate. We are likely, therefore, to see another version of the bill with more bipartisan support introduced and voted upon in the Senate. The House could then either accept the Senate language or demand that a conference committee work out the differences in the two bills. In the 114th Congress there has been a pretty even split between the two options.

There was no recorded vote on the Schuster amendment (not unusual) so it is hard to tell whether there is any substantial opposition to this provision which was a relatively minor part of that amendment. I suspect that there was significant opposition to the Babin amendments and that the Schuster language was offered as an acceptable substitute. This might mean that the Schuster language could end up in any conference reported bill.


My comments from last night still stand except that the even further limiting of the drone regulations to just CFATS and MTSA covered facilities is even more inexplicable than was the lack of coverage in the Babin amendments for the electric grid and gas distribution lines. The only thing that I can figure is that including the water facilities would have required involving the EPA oversight committees and that was fraught with problems. There has been a general disinterest in Congress in requiring any real security of water treatment facilities. This is probably due to the fact that most of the facilities are owned by local governments that generally have little interest in spending money on real security measures.

DOT/DOE and NRC regulated facilities are already typically listed as flight restricted zones so that technically flying drones over them is already illegal. Raising the issue in this forum would just add ways for the bill to acquire more opposition.

It will be interesting to see if the industrial backers of this language can convince the Senate Commerce, Transportation and Infrastructure Committee to include it in their version of this bill.

NIST Publishes RFI Comment Extension Notice

As I mentioned earlier this week, today the National Institute of Standards and Technology published a notice in the Federal Register (81 FR 7506) announcing the extension of the comment period on their request for information (RFI) on updating the Cybersecurity Framework. The comment period is extended until February 23rd, 2016.

It does not appear that there were any specific requests for extension of the comment period. The notice only mentions that the comment period coincides with “a timeframe in which a variety of cybersecurity events are scheduled to occur”. While a number of cybersecurity professionals do attend many of these events, I really doubt that that is the reason for the very poor comment rate that we have seen to date.

I would like to mention again that NIST has adopted the use of a spread sheet format for submission of comments. Since I also do my own personal reviews of these comments (as my readers are certainly aware) I can attest to the fact that it is much easier to compile comments from this spread sheet format. If you have to include a long expository comment showing your erudition and mastery of the subject matter, please at least take the time to put a brief answer to the questions into the NIST response form. I know that I will only give a cursory scan to your exposition and concentrate on the concise answers in the form.

Thursday, February 11, 2016

Critical Infrastructure Drone Restrictions

Earlier this evening I received a heads up that the House Transportation Committee, during their markup of HR 4441, the Aviation Innovation, Reform, and Reauthorization Act of 2016, the Committee passed an amendment that would restrict small unmanned aircraft systems from flying over critical infrastructure facilities.

Somehow I over looked this bill when it was introduced last week, but it has an entire sub-title dealing with small unmanned aircraft systems, commonly referred to as drones. I’ll go back and review that entire sub-title in a subsequent post.

There were actually two nearly identical amendments (#081 and #084) introduced by Rep. Babin (R,TX) that dealt with drones and critical infrastructure facilities. It is not clear from the Committee web site tonight which of the two amendments was adopted, but it really does not matter much at this point for reasons that I will discuss later in this post.


The underlying bill defines ‘small unmanned aircraft’ as “an unmanned aircraft weighing less than 55 pounds, including everything that is on board the aircraft” {new 49 USC §45501(8)}.

The other critical definition (pardon the repetition here) is that for critical infrastructure. Instead of the typical weasel worded definition that can be stretched to fit everything or nothing these amendments get very specific. They use coverage by other federal security programs as the basis for the definition. Those specifically listed programs are {{new 49 USC §45509(d)}:

• MTSA program;
• CFATS program;
• Public water system program;
• Public treatment works program;
• Facilities owned by DOD or DOE; and
• Facilities regulated by NRC

New Regulations

The amendments would require the Administrator of the FAA to issue final regulations (in an unreasonably short 6 months) “concerning the operation of small unmanned aircraft systems in the proximity of critical infrastructure facilities” {§45509(a)}. The regulations would be required to {§45509(b):

• Describe the critical infrastructure facilities to which the regulations would apply;
• Ensure that the designated facilities are part of an established federal security laws;
• Establish boundaries for permissible unmanned aircraft operations;
• Permit facility owners to operate unmanned aircraft over the facilities; and
• Establish criminal penalties for violating the regulations.

The difference between the two amendments is that #081 would require eligible facilities to register with the Administrator for the regulations to have effect. Amendment #084 automatically covers all of the eligible facilities.

Moving Forward

Until the complete committee record for this markup becomes available and we can look at the votes I will not be able to tell for sure if this bill has bipartisan support. As it clearly has the support of the Chair of the Transportation and Infrastructure Committee {Rep Shuster (R,PA) is the author and Committee Chair}, the bill will make its way to the House floor and it will pass. If it has bipartisan support it may make it whole to the Senate floor for consideration.

Given the very large number of amendments that were offered in Committee, I suspect that this bill may require a rule for consideration in the House, which would open it up for more amendments there.

It is way too early to know if one of these amendments will make it into the final FAA authorization act.


I strongly suspect that industry will support this amendment (either version). The American Chemistry Council has provided me with a statement of support that the vote for the amendment will “help address a mounting security concern and help safeguard chemical facilities”. I really expect other industry organizations to chime in.

Now I have frequently written about the potential hazards that drones pose to chemical facilities (most recently here), so one would expect that I would be supportive of these amendments, and I suppose that I am. They are a good first pass at attempting to address the obvious security problems with drones. But there are three glaring problems with these amendments.

First, they missed a couple of types of very important critical infrastructure facilities in their definition; electric grid facilities and gas transmission facilities come quickly to mind. The gas transmission facilities I almost understand; they are not covered by a formal federal security program (TSA security coverage is very vague and voluntary). Large portions of the electric grid, however, are covered under the NERC CIP program which should count as a federal security program.

The second and certainly more important problem is that making flying drones over one of these protected facilities a crime is not going to stop someone who intends to do the facility harm; its just another law to be broken in the process. To make this restriction really mean something it has to authorize covered facility owners to take action to stop a drone from flying over their facility.

Currently the FAA has made clear that shooting down a drone is just as illegal as shooting down any other aircraft in the national airspace. There are a number of good reasons for taking; probably the most important is that shooting down aircraft results in uncontrolled crashes that may do more damage than the unrestricted drone ever word.

There are, however, a number of emerging technologies are being designed for active drone defense that would allow a defender to take control of a drone in a specified area and cause it to make a controlled landing in a designated area. Unfortunately, a critical infrastructure owner would be unlikely to try to employ such a system, fearing running afoul of the current rules that protect aircraft.

For legislation to provide real protection to critical infrastructure from drone attacks of whatever sort, it will have to provide legal cover for taking action against the drones. While I don’t think we want the local chemical company to employ air-defense weapons to protect their air space (like nuclear facilities did after 9-11), but specifically taking control of drones violating very clearly defined airspace near and over designated facilities to force a controlled landing would seem to me to be very reasonable.

Finally, there is the problem of identifying the restricted air space defined in the required regulations well enough so that a non-adversarial drone hobbyist does not inadvertently violate that air space. Currently pilots have very detailed maps of restricted air space that they are supposed to maintain and they have received training in how to read those maps as part of their required pilot training. Even so, there are a relatively large number of inadvertent restricted air space incursions every year.

How we are going to get that level training to the over 350,000 currently registered sUAV owners is completely beyond me.
/* Use this with templates/template-twocol.html */