In Vista, Microsoft added a feature called Network Location Awareness.  In short, the service is able to detect when and what networks you connect to and tag them with different profiles (i.e. Public, Private, Domain).  These profiles are then assigned their respective firewall policy and rules.  However, if you had multiple active network interfaces it would assign the most restrictive policy to all the interfaces.

That has been changed in Win7/2008RC2 so that each interface has its own firewall policy and rules.  An example of its use would be in a proxy server environment.  You could assign a more restrictive outbound and inbound policy to the public facing interface to only allow the needed ports to communicate to the internet and only the Internet.  Conversely, you could deny all traffic on the private interface except the ports you need to patch/update and send requests to the proxy.

The second feature that was updated, and my personal favorite, is the support for port ranges within firewall rules.  In the past, you had to create a firewall rule/exception for each port (i.e. pre-Vista) or comma separate ports (i.e. post-Vista).  Win7/2008RC2 has now added the ability to specify ranges of ports in addition to the Vista functionality.

For example, an active and passive FTP rule in Vista would look as follows:

In Win7/2008RC2, it would look like this:

As you can see the new rule structure helps you understand and update rules faster.  This would be very useful when enabling and auditing a control system, with several modules, to communicate through a firewall.

• Multiple Active Firewall Profiles
• Support for port ranges within rules
• Dynamic encryption
• Tunnel mode authorization and exceptions
• Service Hardening and Firewall Triggers

I will be discussing each of the above features in follow-up blog posts starting tomorrow.

The morning module will teach you how to use and customize the Bandolier Security Audit Files. Jason has developed a more detailed outline showing you what you will learn. It is ideal for asset owners or consultants who will want to use Bandolier for security audits and assessments.

There is still space in the course. Register at this link.

These can apply to quite a few aspects of securing systems. Everything from developer education, to sandboxing applications, to monitoring/auditing systems, and dozens of other areas. So without further commentary, here are a few selected points from the article that seem to apply to most:

• This program would lull you into a false sense of security.
• It would cause undue alarm and destroy your desire to continue your voyage in this ship.
• It demonstrates a lack of faith in our Captain.
• The apparent security which “life” boats offer will make our Navigators reckless.
• These proposals will distract our attention from more important things i.e. building unsinkable ships. They may even lead our builders to false economies and the building of ships that are actually unsafe.
• In the event of being struck by an iceberg (we will never strike first) the “life” boats would certainly sink along with the ship.
• Such a catastrophe is too horrible to contemplate. Anyone who does contemplate it obviously advocates it.

And I have a question for loyal blog readers. Many of the initiatives focus on centralization. Manage the Federal Enterprise Network as a single network enterprise. Deploy IDS/IPS across the whole enterprise. Coordinate all R&D. Government wide counter intelligence. This is similar to idea that if we combine all these Federal Agencies into DHS all will be well. Is this a good thing? At this point I don’t how I would answer that question.

The final initiative is directly related to control systems. “Initiative #12. Define the Federal role for extending cybersecurity into critical infrastructure domains”. If you read the corresponding paragraph, it interestingly does not match the Initiative description of “defining the Federal role”. What should the Federal role be? Should they mandate cyber security measures for private critical infrastructure companies and have enforcement mechanisms similar to the electric sector? Should they simply provide security guidance? Emergency response assistance? What should the USG role be? Should it be more like the European model that seems to be making more progress with less furor?

Instead the paragraph on Initiative 12 talks about building on existing partnerships, creating public/private information sharing, etc. These are all items, particularly information sharing, that have been talked about and organizations purpose built for these tasks for five or more years. I don’t think it is controversial to say that the results have fallen far short of expectations. So far there has not been a shift in the benefits to participation or significant USG changes in approach that would lead to these efforts now bearing fruit.

While the convenience of this setup is understandable, there are a few concerns I have about the implementation. The first two issues I see are similar to VOIP implementation issues. The first is that, if somebody is able to gain access to the control network, they would have access to the video surveillance as well. The second issue is that the camera system increases the attack surface for the control network.

There are two other issues that immediately came to mind regarding integrating cameras on the control network. If an attacker has access to the control network and the cameras were on the same network, the attacker could prevent the security video from reaching the ClearSCADA system.  Should an attacker take down a router or switch, both the control network and surveillance system would be taken offline, leaving the remote sites open to physical attacks.

There are definite benefits of this system, mostly ease of use and ease of implementation. However, with all additions to the control network, there must a business case and risk assessment.

A couple of months ago I posted a bit about an iPhone virus that was making the rounds. This virus relied on default passwords on jail broken phones to propagate itself using built in SSH capabilities. As many users did not bother to change the default passwords they were at risk, allowing the virus to spread. Coupled witha growing number of SCADA apps for smart phones I thought it worht while to note the possibilities for security issues.

The spread of a smart phone virus raises the question: “What is the potential impact of an infected smart phone to control systems?”

With the rising number of third party apps being produced for these phone, in light of the Veracode’s State of Software Security report that Jason posted about we see a huge growth area for potential new 0days in apps that are not thoroughly vetted for security implications. There is also the possibility of malware being produced and packaged and purveyed through the various “App stores” or via free ware. Malware with built in rootkits or other software that communicates externally to report on users habits.

The possibility of an infected phone communicating on corporate or control system networks via the built in Wi-Fi (802.11) or by being meshed with a PC via bluetooth is very real, a possibility that opens a whole new world of vectors that attackers could employ.

So onto our ultra simple fuzzer:

#! /usr/bin/env python

import sys
import os
from struct import *
from scapy.all import *

def result_test_write(response, file, data, x):
 if response:
 file.write(data)
 file.flush()
 os.fsync(file)

 else:
 print "No response received for run %d" % (x)
 file.write(data)
 file.flush()
 os.fsync(file)
 file.close()

target = "10.0.0.125"
valid_request = list("\x53\x69\x6d\x70\x6c\x65\x00\x50\x72\x6f\x74\x6f\x63
                      \x6f\x6c\x00\x52\x65\x71\x75\x65\x73\x74\x20\x4d\x73\x67")
port = 6294

ip = IP(dst=target)

for element in range(0, len(valid_request)):
 if valid_request[element] == '\x00':
 valid_request[element] = 'A'

for element in range(0, len(valid_request)):
 mutated_data = valid_request
 mutated_data[element] = chr(random.randrange(0,255))

 source_port = random.randint(1025, 65535)
 file = open("test_%04d" % (element), 'w')
 data = "".join(mutated_data)

 ip = IP(dst=target)
 udp = UDP(dport=port, sport=source_port)
 ans, unans = sr(ip/udp/data, verbose=1, timeout=5, multi=1)

result_test_write(ans, file, data, element)

We’ve got a known good request (one that generates a response) stored in the valid_request variable, and we’ve noticed that there are lot of printable characters, and some null characters in it. So we’ve wrote some code that does a couple of things that can make protocols that leverage a lot of string have trouble. Null characters are used as a stopping point in string copies, so we’ll get rid of those and replace with a printable character. Next is where we get down to business, we go through each byte of the valid data and change it to a random value, one at a time. If we’re lucky we might find a byte that the server uses to decide how much space to allocate, causing a buffer overflow, or we might find a control character that uses an undefined mode. Following that, we check to see if we got any response, log our fuzzed request to a file, and keep on going.

Of course this is just the beginning, there is a ton of functionality you can add, and certainly much better monitoring of the process than just looking for a response packet, but that’s not the point. Here you have an example that you can quickly get up and running, maybe while you’re getting a more intelligent fuzzer running, and maybe because that’s all the time you have. Whatever the cause, one error/crash makes the time spent putting together simple scripts like this more than worth it.

I’ve gotten to where I read any InfoSec literature through a control systems lens. I’m always asking, “how does this apply or not apply to the control system applications and hardware we work with?” In this case, the relevance is easy to find. The distribution of vulnerabilities by language, for example, is an interesting educational tool for developers regardless if the application you’re writing is balancing a checkbook or opening a breaker.

For those of us that are looking at security every day, there are few surprises here. What we have to do if find ways to educate people that there is a problem. That’s where reports like this can be useful. Here are Veracode’s key observations:

1.) Most software is indeed very insecure.

2.) Third-party software is a significant percentage of the enterprise software infrastructure, and third-party components are a significant percentage of most applications.

3.) Open source projects have comparable security, faster remediation times, and fewer Potential Backdoors than Commercial or Outsourced software.

4.) A significant amount of Commercial and Open Source software is written in C/C++ making it disproportionately susceptible to vulnerabilities that allow attackers to gain control of systems.

5.) The pervasiveness of easily remedied vulnerabilities indicates a lack of developer education on secure coding.

6.) Software of all types from Finance and Government sectors was relatively more secure on first submission to Veracode for testing.

7.) Outsourced software is assessed the least, suggesting the absence of contractual security acceptance criteria.

Each of these points is interesting and could be its own blog post in its own right but I want to focus on number five for now. I absolutely believe that more can and should be done for developer education. But the other lens I look through now (thank you, Ross Anderson) is the economic perspective. What is the incentive for developers to do better with secure coding in the control system space? Until customers require it, it’s just not going to happen.

Perhaps the most effective way that customers can require more from vendors is at the time of purchase. Easy win here: the procurement language document has been out for a while now and contains a secure coding section. A while back I conducted an informal survey of control system vendors regarding use of the procurement language in RFP’s. The results are disappointing. One positive outlier was at 40%, but most were closer to the single digit percentages.

I agree with the report — we’ve got education to do, but for our space it’s not just at the developer level. How much longer will it take to for us to have the at least same security expectation levels of our critical infrastructure applications as we do when we order a pizza online?

Digital Bond offers an application assessment service if you want to know what the “state of things” is for your software.