Secure your buildings? uhhhh….

I had to emit a sad chuckle at the GAO report on cyber security for federal buildings.

GAO buildings report cover

In way of background, DHS, through its Federal Protective Service (FPS), provides security at more than 9,000 federal facilities nation-wide.

I’ve read lots of GAO reports. This one is about as scathing as GAO sterilely-objective grammar permits:

DHS lacks a strategy that: (1) defines the problem, (2) identifies the roles and responsibilities, (3) analyzes the resources needed, and (4) identifies a methodology for assessing this cyber risk. A strategy is a starting point in addressing this risk. The absence of a strategy that clearly defines the roles and responsibilities of key components within DHS has contributed to a lack of action within the Department.

Unfortunately, building automation is one of the most overlooked areas of cyber security. In the commercial world, some buildings are leased rather than owned; facilities maintenance teams often fall under separate management than corporate  IT; facilities maintenance personnel are not likely to have cyber security training/forethought, and so on.

On one hand I understand that the folks at FPS haven’t thought about cyber. Has your guard force? Imagine walking up to one of these cops and saying “Hey, I bet there’s an ActiveX control in your HVAC HMI with a stack based buffer overflow. It could probably be exploited via malicious redirect employed by strategic Web compromise.”

He or she will look at you like you are from another planet.

In addition, I recognize that the DHS mission is enormous and ill-defined; oversight is lacking; leadership has surprising turnover; bureaucracy can be oppressive and slow.

For those reasons, I don’t mean to imply that implementing cyber security into federal building automation environments is easy.

One the other hand, it has been two and a half years since Billy Rios knocked building automation cyber security into the limelight. That should be time enough to at least have some type of plan/strategy.

And it would have been, had DHS risk management leaders been relying on a competent and appropriately-resourced *integrated cyber-physical intelligence team* to bring important developments in the external threat environment to leadership attention!

Fines or “Traffic School” for Online ICS?

My post on three ideas for advancing ICS security at a federal level received some comments from Andy Robinson on Twitter. You can read the thread here.

Andy liked my post but took issue with idea number 3:

“Fines for Online ICS. As an example, if water provision systems are connected to the public Internet, it must be brought to the water users’ attention. We need a small consequence right now (something like a $5,000 fine) to avoid a big consequence in the future.”

Essentially, Andy posits that government should help utilities, particularly municipal water provisioners, rather than fine them.

He thinks the punishment should be something like traffic school instead of just slapping them with a fine. He dislikes the idea of transferring funds from already struggling municipalities to the federal government, which only increases taxpayer burden.

That is a fair objection.

Twitter is not an apt medium for discussing some of the broader context of my idea. So here goes:

1. Finding online ICS

Just about anyone can find online ICS. Shodan, ZoomEye, SCADASL cheat sheet. It is not hard. That’s not to say that every online ICS is vulnerable either. But I think being online does make it a target — at least for opportunistic attackers. What we saw with Black Energy supports that.

2. The problem is getting worse

If you go back to Eireann Leverrett’s work on Internet-connected ICS in 2011, and repeat the searches today, you see that in most cases, the number of hits has dramatically increased. Granted, maybe Shodan’s scanning and parsing have also improved, but the assertion that more ICS are being connected to the Internet today is confirmed by Project Shine. We are connecting more ICS to the Internet. The problem is getting worse.

3. Contacting the owner

The problem we want to address is getting the offending systems segmented from the public Internet. The hang-up is that many of these IP addresses are registered to Internet Service Providers (ISPs). There is currently no way to compel the ISP to disclose who owns/operates a particular IP address. Essentially you can’t warn who you can’t reach. There could be privacy and free speech issues here, but also public safety concerns.

4. Assigning responsibility

Even if we know who owns an Internet connected ICS, we don’t know who decided to put it on the Internet (in many cases they probably didn’t “mean” to). Many water systems rely on third party engineers for about every operational aspect of their system. In many cases, it is the engineer’s “fault”. They might know how to specify pumps, but they might not know what a VPN is. Assigning ultimate responsibility is the job of the system owners.

5. Ratepayers must bear the burden at the end of the day

The fact of the matter is that rate-payers have to bear the cost of increased security. It might be unpleasant, but they reap the benefits of a more secure system, ergo, they should pay for what it costs.

6. A fine versus “traffic school”

The “Traffic school” idea is a fair one. We all like to give someone a chance cause they don’t know better — alter behavior though education. I would simply point out that the federal government has offered free trainings for years. Sure take the trainings, I hope they help, but knowing and doing are two different things. Don’t leave it to goodwill alone.

7. Threat of fines will be sufficient in most cases

My belief is that if the DHS or EPA or whoever is the appropriate agency contacts the owner/operator of an Internet-connected ICS and says “we have statutory authority to fine you $5,000 for connecting your industrial control system to the public Internet; however, we will forebear in this instance if you segregate your network within 15 days”, that will effectively get the job done without actually issuing a fine.


Now, I understand that creating a regulatory regime would be fraught with costs; defining terms would be a chore. There are burdens of proof, there are protocols for receiving and processing complaints, records must be kept. And there could even be litigation.

I’m not entirely convinced the “fines for online ICS” proposal is “worth it”; but I am convinced that it has a more direct connection with enhancing the cyber security of industrial control systems in the USA than many other programs have had to date.

On Info Sharing

In September Critical Intelligence held its inaugural CounterIntel Conference and Training in beautiful Park City, Utah. It was probably the most eye-opening security conference I have ever attended. This owes primarily to the outstanding speakers. You can take a look at the full lineup here.

As several recent blog posts have dealt with information sharing, I wanted to relate the on-point comments provided by Mark Weatherford who delivered the keynote address. Mark has an impressive resume, as a former Naval Cryptologic Officer, former DHS Deputy Undersecretary for Cyber Security, and now Principal at the Chertoff Group.

I have heard Mr. Weatherford speak on previous occasions, but I was unprepared for his candor — which had me scribbling furiously away. Here were some gems:

“Government thinks they know what’s right for private industry. That’s wrong and it’s wrong-headed.”

“The government is incapable of providing timely and actionable intelligence to the private sector today.”

“Good intelligence is integrated across sources.”

“Public-private partnership is probably not going to work out, at least in the near term, in a way satisfactory to the private sector.”

“In our business there simply isn’t time to get everyone’s opinion prior to making a decision”

“There is a mystique around classified information — but once people get access to it they are severely disappointed.”

I was more than surprised to hear a former DHS cybersecurity official make those statements. But I think that makes them all the weightier.

National Security Systems and ICS

I was reviewing the Committee on National Security Systems Instruction 1253, which provides guidance for applying security controls to National Security Systems. I was specifically looking through the document for references to industrial control systems.


National Security Systems are essentially any system used for military or intelligence activities (including weapons systems), that are not used for payroll, finance, logistics, and personnel management applications (See 44 U.S.C. 3542(b)(2)).

CNSSI 1253 was updated in March 2014. The previous version (March 2012) said:



Adoption of National Institute of Standards and Technology Special Publication 800-53, Revision 3, Appendix I, is not mandatory and is solely at the discretion of national security community departments and agencies, at this time, pending further applicability by the national security community.

To me, this meant that there was a “free pass” for NSS ICS. I found that quite concerning.

Potentially worse, however, looking at the updated 1253 (March 2014) instruction, I find no reference whatsoever to industrial control systems. My guess for the reason why is that NIST is now addressing ICS security entirely outside of 800-53 (i.e. 800-53 revision 4, released in April 2013, has no appendix dealing with industrial control systems). The industrial control systems guidance is now found in 800-82. Because 800-82 is not part of the core “transformational documents” (e.g. SP800-30, 37, 39, 53, 53A) coordinated between NIST and CNSS, it appears to have been left out of CNSSI 1253.

This leaves me wondering what guidance is being used for categorization and control selection for industrial control systems that are national security systems.

Maybe the guidance is classified. Maybe it exists at the agency level. Maybe there is some reference to 800-82 that I didn’t find. But, in an age where we have our country’s highest defense officials talking about “cyber 9/11” and “digital pearl harbor”, the inability to easily identify a common baseline for securing military industrial control systems appears deeply concerning.

Three ideas for federal advancement of ICS security

Over the past several years I have witnessed a line of federal leaders push information sharing like it is the absolute solution to forever ensuring the cyber security of the infrastructures on which Americans rely. We have had testimony in congressional hearings, proposed and passed legislation, executive orders, NIST info sharing guidance, and WashPost op/eds proclaiming the indispensable nature of information sharing for the preservation of the country.

While fans may show up to watch deceased baseball greats compete on the Field of Dreams, we aren’t talking about the American pastime; we are talking about American infrastructure. We don’t need fans. We need action.

There are three fundamental problems to securing the industrial control systems (ICS) at the heart of our infrastructure that info sharing will never address:

  • insecure control system architectures
  • insecure control systems products
  • insecure control systems communication protocols

Make no mistake: I am an intelligence and information sharing professional. I have been serving the unique intelligence needs of the country’s largest utilities for 8 years, the first two building out the DHS control systems cyber situational awareness effort that became the ICS-CERT, and next six as the Director of Analysis of the only commercial vulnerability and threat intelligence organization to focus specifically and exclusively on industrial control systems. I believe that intelligence and information sharing have a role to play. But that role is to inform appropriate action. It is not a sufficient solution in and of itself.

In an attempt to advance conversation about how to address the core issues at a federal level, I submit the following action-oriented ideas:


Government to lead the way by cleaning its own house. The U.S. government is a significant buyer of industrial control systems technology. Why not use this purchase power to advance the state of ICS security? How about this: As of July 1, 2016 (or whatever reasonable date you choose), new ICS builds relying on federal funds cannot use unauthenticated protocols.


Require network security monitoring for ICS networks owned by the federal government. Instead of worrying quite so much about enterprise networks (which are important),  ask/encourage/incentivize federal ICS owner/operators to install network security monitoring solutions that provide defenders insight into anomalies on *ICS* networks. Other technologies such as application whitelisting would also do well in many of those environments. The government push for these solutions on its ICS networks may spur the market and result in advancement and confidence.


Fines for Online ICS. As an example, if water provision systems are connected to the public Internet, it must be brought to the water users’ attention. We need a small consequence right now (something like a $5,000 fine) to avoid a big consequence in the future.

I recognize that there are significant details to work out in order to implement each of these ideas. But these action-oriented concepts have at least some direct correlation with the underlying problems facing critical infrastructure cyber security.

Let’s forgo the info-sharing pastime, and focus federal efforts on the foundation of a more secure future.