A small number of vendors are promoting unidirectional network security devices, most notably Waterfall Security Solutions from Israel. [FD: Waterfall has advertised on digitalbond.com] To their credit Waterfall has doggedly pursued the control system security space and has some good content on using their product in control systems. And based on the number of questions we receive on their product, they are getting some mindshare.

So when clients and prospects ask the question, here is the general version of our answer.

1. Make sure the product actually only allows one-way / unidirectional communication. Too often we have heard descriptions of TCP being used in unidirectional communication or allowing an administrative channel back through the one-way device. As soon as you do this you are lessening the primary advantage of a one-way security device.

2. Determine if you have any truly one-way communication. Based on our review of perimeter security firewall rulesets, there are not many out there. In fact, one of the most common and critical assessment findings is to lessen the holes in the perimeter firewall and implement a true, least privilege ruleset.

There are some candidates for one-way communication. For example, the communication from a safety system to a control system might be a great use of this technology. The control system gets the information and yet is not an attack pathway to the safety system. Pushing data out to a business partner using ICCP or OPC, DMZ or corporate network is another possible use, but remember that the delivery of information will only be best effort with no error messages. Your applications need to support it and no requests can be made from the less secure side.

3. Is the potential of an adversary breaking through your strongly configured, least privilege firewall truly your greatest risk? Remember we should be pushing down the most significant risks first in a risk management process. We do have some clients with very advanced, years in the making, information security programs that could answer this question yes. I think they are in a small minority.

The idea of buying a product to solve security is appealing to managers, and let’s admit that the technology guys love the latest gadget as well. Many control systems would achieve greater risk reduction if that effort and money was put on administrative controls.

These unidirectional security products will become more appealing if network and product designs implement more one-way / push out capabilities.

Following up from yesterday’s post, here are a few more notes on UAC and Bandolier.

First, my earlier post focused on Windows 7 but I probably should mention that UAC applies to 2008 server as well. The UAC implementation on the original 2008 server is similar to Vista, with 2008 R2 being more similar to Windows 7. One other caveat is that these posts are not a thorough treatment of the ins and outs of UAC. For example, we didn’t even touch on File and Registry Virtualization but perhaps we’ll get to that in a future discussion.

Another UAC connection to Bandolier is the ability to audit the UAC group policy settings. There are 10 settings related to UAC that we can easily verify with audit checks provided by the Nessus policy compliance plugins. The settings are:

• Admin Approval Mode for the built-in Administrator account
• Allow UIAccess applications to prompt for elevation without using the secure desktop
• Behavior of the elevation prompt for administrators in Admin Approval Mode
• Behavior of the elevation prompt for standard users
• Detect application installations and prompt for elevation
• Only elevate executables that are signed and validated
• Only elevate UIAccess applications that are installed in secure locations
• Run all administrators in Admin Approval Mode
• Switch to the secure desktop when prompting for elevation
• Virtualize file and registry write failures to per-user locations

You can see more details and a list of the default values here. And here’s what an audit check for one of the settings looks like:

<item>

name: “User Account Control: Only elevate executables that are signed and validated”

value: “enabled”

</item>

Very simple syntax. For common policy values, the Nessus compliance plugins offer this abbreviated syntax. If you’d like to learn more about the how these audit checks work, the Bandolier Security Audit Files, safe vulnerability scanning/auditing, and customizing audit files for your control system environment, please check out the class we are offering in September directly after the EnergySec conference. You can register here.

Finally, see the comments in the previous post for a discussion on how the deterministic nature (or not) of control systems plays into UAC.

We’re develoing our first set of Bandolier audit files that will include Windows 7 components. The control system community, for the most part, has not embraced Windows Vista so Windows 7 is the first exposure for many to User Account Control (UAC). UAC is perhaps the most hated “feature” of Vista — the constant prompts to allow certain actions caused a lot of people to disable it. Windows 7 makes UAC a little more palatable by allowing the prompts to be dialed down to certain types of actions. In this post we’ll look at an overview of UAC, improvements in Windows 7, and see how it affects Bandolier and other Nessus credentialed scanning.

UAC attempts to solve the operating system security problem of over-assigning user privileges that makes life so easy for malware and client-side exploits. The basic concept of UAC is that everything runs in a lower privilege session unless it needs to be elevated. When a user logs on with elevated privileges, two sessions are actually created: one that has the elevated privileges and one that is stripped down. If a program requires elevation, user interaction is required. This helps enforce least privilege which in turn creates a hurdle for malware and can help prevent a certain amount of user error.

So UAC is definitely a positive step in the right direction. But UAC, like other security controls, can be a double-edged sword at times. First, there have been flaws that allow the controls to be bypassed so it’s not perfect. Then there is the incredibly annoying user experience in Vista. Windows 7 attempts to address this problem by providing a congurable “slider” that allows you to determine what level of interruption you get. (This article compares the number of prompts between the two Windows versions: for most scenarios, it’s about two-thirds less in 7 than in Vista.)

And here is another painful edge of the UAC sword: Windows 7 credentialed scanning with Nessus needs to run in a privileged session and thus requires some special treatment. By special treatment, I mean that the scan has to have credentials for the built-in local administrator account or a Domain Admin account to function. Not exactly ideal but understandable given the technology. So why does the built-in administrator account work? Because it is not subject to UAC by default. My next question was whether the scans would work if I renamed the administrator account and the answer is they do.

Here is my summary and opinion of the bottom line:

• UAC helps enforce least privilege on Windows 7 desktops with a lot less interruption than Vista.
• The up side: UAC makes executing most malware and client-side attacks more difficult.
• The down side: Bandolier audits and other Nessus Credentialed scanning must now must run with the built-in local administrator account or a Domain Admin account which seems like a step backward for least privilege.
• The bottom line: I was disturbed by this at first. But after I pondered the tradeoff it’s really not that bad. Would you rather 1.) have all your users running with more privileges than they need and no UAC or 2.) have a single account used for security auditing that has slightly more privileges than needed but gives you all the benefits of Bandolier auditing and credentialed scanning? I’ll choose option 2.

In case you haven’t seen it, we’re capturing topics like this in the Bandolier FAQ page. It includes general information about Bandolier as well as specific troubleshooting information like “Why am I not seeing any results in my Nessus Bandolier report?”.

How many of you have downloaded NISTIR 7628: Smart Grid Cyber Security Strategy and Requirements, saw it was 305 pages and put it aside? Maybe you even waded into the first ten to twenty pages and read a lot of general statements and gave up. Well if you have some time before the summer is over, pick it up again because there is some great information in there.

Let me guide you through the highlights in a quick and painless way.

1. Jump right to Figure 2.2 on page 29 and see a drawing of logical interfaces in an AMI. This shows the common hardware and software components in an AMI deployment. Equally important it shows the communication flows between these components. If you don’t understand what a component, or actor in NISTIR parlance, does, then note the number in the box and go to Table 2. on page 22 and read about it. Don’t look at any of the other information yet.

You can repeat this process for Distribution Grid Management in Figure 2.3, Electric Storage in Figure 2.4, Electric Transportation in Figure 2.5, HAN/BAN in Figure 2.6, and Wide Area Situational Awareness in Figure 2.7.

You should now have a basic understanding of the components and flows in six major “smart grid” domains.

1a. [Optional] You can now look at Figure 2.1 on page 21 that shows Figures 2.2 – 2.7 all combined in a single drawing to see a consolidated smart grid view. Look to the upper left and see many of the existing system such as Plant Control Systems and Transmission SCADA.

2. Now go to Section 3.2 Logical Interface Categories beginning on page 54. Each information flow line drawn between the components in the Figures you just looked at is assigned to one of the 18 Logical Interface Categories. Section 3.2 is a description of the type of communication and high level security requirements for each category. This is good info so spend some time here.

3. The next step in the methodology assigns each logical interface from Figures 2.1 – 2.7 to one of the Logical Interface Categories – - that is why they were individually numbered. So as an example look at Table 2.2 on page 30 and see how the AMI logical interfaces are assigned.

4. The next step in the methodology gets messy and may not be worth reading if you are looking for an overview. Security controls from the DHS Catalog of Security Controls are then assigned to each of the 18 logical interface categories. So the idea is you would draw your system as in Figure 2.2, select the interface category for each connection, and then have a list of recommended security controls. There is a lot of detail in the document, but the concept is simple.

5. Now skip to Appendix A. There are some great use cases here for a variety of smart grid domains. Each use case has a described scenario, smart grid characteristics and corresponding cyber security objectives / requirements. For example AMI: Remote Connect/Disconnect of Meter or EV: Plug In Hybrid Vehicle or Customer Receives and Responds to Utility Price Signal.

6. Finally read the first three pages of Chapter 4 Privacy and the Smart Grid, pages 100 – 102. Provides a good overview of the issue.

All of this should take you less than an hour. If you want more detail after that you have another 260 pages you can go through.

• The field of auto hacking continues to grow, and we have our first auto hacking tool – called CarShark of course. The challenge is in intercepting the signals more than hacking the systems in the car. The question is why would an adversary want to do this? Where is the profit or gain? Besides doing it to show it can be done or some very special circumstances, it is hard to see the gain. Any ideas?
• The Center for Internet Security [CIS] has merged with or absorbed the MS-ISAC. MS-ISAC is known for their good work on the SCADA Procurement Language project. Will Pelgrin will be President and CEO of the combined organization that will still fly under the CIS flag.
• NERC has a 30-day ballot out for changes to CIP-005. These changes strengthen the required technical and administrative controls, as well as documentation requirements, related to remote access to Critical Cyber Assets from outside the electronic security perimeter. One of the significant changes is a requirement for multi-factor authentication.

In Part 1 of our discussion on the OSSTMM rav, we set up some context and background for what the metric is meant to do and what factors go into the calculation. Since then I’ve had the opportunity to use the rav scores in a real-life scenario and am ready for some harder analysis.

We set out to answer these questions: 1.) How can the OSSTMM best apply to control systems security assessments? and 2.) What is the value and impact of translating an assessment into a numeric score? In hindsight, I’m not sure these were exactly the right questions to be asking but let’s address each of them and then I’ll give you my bottom line analysis.

How can the OSSTMM best apply to control systems security assessments? This question is really more about the methodology in general and not specifically the rav metric.The methodology and the rav metric are both designed to be generic enough to apply to multiple types of assessments, known as “channels” in OSSTMM terminology. So you run through the same phases of testing in a physical assessment as you do in a data networks assessment. The simplest example of this is testing Access. For a physical security assessment, this involves counting doors and windows; for a data networks assessment, it means counting open ports.

From a high level standpoint, there is certainly no reason why the OSSTMM cannot be used in control systems. When you get down to the details, though, some adaptations are needed for a typical control system security assessment. Many of the data networks sections are written from an Internet perspective, which often does not apply directly. So one adaptation may be treating the business network as the Internet. Other sections like Property Validation and Competitive Intelligence Scouting usually would not apply directly although I’m sure there are exceptions.

What is the value and impact of translating an assessment into a numeric score? This is probably not a fair question. So we have the OSSTMM methodology and the rav score. Neither is really meant to replace or translate anything. They are just tools to help with the assessment, and more specifically for the rav — with operational security decisions. To me, using the rav metric makes more sense at a security program level for tracking attack surface over time. Some organizations are ready for something like this, but many have other basic issues to address that don’t necessarily require a metric to justify.

Digital Bond’s SCADA security assessment methodology has been proven and matured over the course of ten years. One of the most important things that we do in our assessments is prioritize the top 5 short term and top 5 medium term recommendations. Our clients voice over and over again that this is valuable to them. We factor in risk level and what can be reasonably accomplished in 0-6 month and 6-18 month timeframes. The OSSTMM methodology and rav metric will not directly measure risk or make this kind of judgment call.

Bottom line analysis: If you’re looking for an assessment framework and a supporting metric, the OSSTMM may work for you but be ready to make some adaptations for control system environments. It will be more effective and useful as a long term, program-level strategy than a one time or once-a-year assessment tool. Finally, don’t expect it to do the risk analysis or make the tough judgment calls for you.

Some of the post Stuxnet discussion, and even much before it, has the premise that we need to improve security so this type of attack can never be successful. That if we just all do the right things control systems will be impenetrable. When we see unpatched systems, hard coded passwords, cleartext authentication, unauthenticated firmware upload and other basic security problems, it is clear we have a lot of work in front of us as a control system security community. However, that does not mean that we should expect or even try for perfect security.

If as a community we have the expectation that we can stop all attacks, we will fail. There will always be new 0day vulnerabilities. There will always be human failures to follow policies, such as plugging in a USB stick. Defense in depth has a better chance of preventing an attack from succeeding, but some combination of failures will be possible and will happen from time to time. Furthermore, all the technical and administrative security controls have a cost and at some point the additional risk reduction is not worth the cost.

What we need to focus on is risk management. What are the biggest risks, and how to we reduce them down to a level of acceptable risk. This is not a radical idea in security, but we have missed it in control system security. There is an expectation of perfect security, like when a congresswoman insists on a yes or no answer to “Is the electric grid secure”? We will never be able to just answer Yes to that question no matter how much time and money is spent.

The response I hear is control systems are different. There can be severe damage to the economy or loss of life. Yes, this is true, but you can lose your life when you drive on the highway, or get on a plane, or eat shellfish. You take more risk when you leave the house, yet people do it every day. There is a cost / benefit analysis to these decisions, and there are security controls in place to reduce risk to a level where people chose to proceed.

There are also examples where cyber risk is not the highest risk for a system or asset. A physical attack or human asset attack is much easier and higher risk, and that is where the effort should be placed. There are some great examples in the NISTIR and other places, and I’ll expand on this more in future entries.

Patrick Coyle writes the Chemical Facility Security News blog and tweets @pjcoyle. His blog is my go to resource for all things chemical security, and Patrick also does the hard work of tracking all of the control system security legislation. Patrick was kind enough to write up a blog entry on what you should be paying attention to and forecasting what will happen.

—– Begin Patrick’s Entry —–

Congress is currently in an extended summer recess, they won’t come back to work until the middle of September. When they return to Washington, there is little doubt that the upcoming elections in November will have an increasingly obstructive effect on the legislative process. That could have a serious impact on their ability to send any sort of cyber security legislation to the President for signature.

Congress has become increasingly aware of the ever more complex cyber security threat that is potentially affecting both government and industry. There have been a large number of bills introduced in the 111th Congress addressing various aspects of this issue. Over at Chemical Facility Security News I have been watching nine bills that will have some effect on industrial control system (ICS) security if they become law. Dale has asked me to provide his readers with a quick look at the legislative prospects for any of these bills actually reaching the President’s desk.

No Action to Date

One of the main things that most people don’t realize about Congress is that most bills that are introduced are never acted upon. For instance in the last two years over 6,000 bills have been introduced in the House and over 3,000 in the Senate. Less than 1% ever make it through the process. We can see this reflected in ICS security legislation; of the nine bills that I have been watching since they were introduced, six have had no action taken since they were introduced.

In the current legislative environment there is almost no chance that any of these six bills will make it into law before the November elections and little chance that they will be considered even in a post election session that is currently being discussed.

Action that has been taken

Of the three remaining bills one has been passed in the House (HR 4061) and the other two (S 3480 and S 773) have been passed in committee in the Senate. Of the three bills, HR 4061 is the least controversial (it passed in the House 422-5) and it has the best possibility of passing is it makes it to the Senate floor. It is currently being held up in the Senate in the Committee on Commerce, Science, and Transportation. If this Committee takes action on the bill when it comes back from the Summer Recess then this bill has a chance of passage before the election.

HR 4061 does not really do anything to regulate cyber security. It does provide funds for a variety of programs to study cyber security issues, establishes a variety of tuition assistance programs for students studying cyber security, and directs NIST director to coordinate US representation on international technical standards organizations related to cyber security.

The two remaining bills are more controversial, establishing cyber security offices and providing authority for cyber security regulations. There are relatively minor ICS security provisions in each of these bills. The main effect would be to allow cyber security regulation of facilities designated as critical infrastructure; but no specific regulatory provisions are outlined.

While Sen. Lieberman (S 3480) and Sen. Rockefeller (S 773) have publicly touted their respective bills, neither of their committees (they are both Chairmen of their respective committees) have published the amended versions of their legislation that were actually passed in committee. Until these reports are filed, no further action can take place on either of these bills. Because of some controversial provisions in each of these bills, it is unlikely that they will be able to pass in the Senate in the time remaining before election.

No Action Expected

While no one can guarantee what Congress will (or will not) do, it seems unlikely that there will be significant cyber security legislation passed before the elections this fall. If something does pass, it will almost certainly be HR 4061 and that does little more than provide funds for cyber security research and education.

—– End Entry —–

Patrick also has created a Legislation Status page on his web site.

EnergySec puts on a great electric sector control system security event every year, and it is a bargain at $150. The agenda is now out for this year’s event in Denver, Sept 21 and 22.

Looking at the agenda the highlight for me are presentations from James Arlen, Dave Lewis and Patrick Miller. These three always have a provocative take on the topics of the day and have their technical chops. There are also presentations from the government and ex-government crowd with Carol Hawk from DoE, Mike Assante ex-NERC now NBISE, Tim Roxey from NERC, … Round that out with Sean McBride, a forensics presentation, info on EnergySec and more. If you can get to Denver it looks like another good edition of the event.

If you do go, consider staying the afternoon of the 22nd to attend our half-day hands-on class on Bandolier. You can register for the course at this link.

A lot of noise this week, but only two items for the News and Notes.

• NERC asked all members to provide information on the number of Critical Assets they have today under CIP, and how many they would have under the draft CIP-002-4. The draft version is much more detailed on what is and isn’t a Critical Asset, and the responses will break out the different types of Critical Assets. Should be some interesting info, probably with dramatically different numbers between the current and proposed Critical Asset Lists.
• Sticking with the ever busy electric sector, SERC published their Compliance Statistics which included 87 potential CIP violations that are broken down by CIP #. CIP-004 had the most potential violations followed by CIP-007. Continue on after the charts to the lessons learned section. [Hat tip: @patrickcmiller]