Introducing Bandolier: Vulnerability Scanner Audit Files

We had all our asset owner and vendor partners in the Dept. of Energy research project rightly say we need names for the forthcoming tools. So let us introduce the first: Bandolier.

Bandolier will be a set of security audit templates that you will run on Nessus and other popular vulnerability scanners to compare control system devices (HMI, Historians, Realtime servers, OPC clients and servers, ICCP servers, …, almost anything with a Windows or *nix OS) to a best practice, gold standard configuration developed specifically for the appropriate applications on that system. You can think of this as a control system application extension to the NIST SCAP concept.

In the project we will be developing at least 20 audit templates, and our asset owner partners have first selection for about half of those. Which means we still are looking for additional interesting candidate systems. Take a look at this Bandolier Overview and let us know if you have a system you would like included in the project. We have plenty of candidates but are trying to include newer systems that will be widely deployed and can in fact be hardened.

UPDATE: An asset owner asked why only newer systems that can be hardened. Mainly because the audit files will identify if the best practice config is implemented. If a system can’t be patched or hardened and is a vulnerable state, it is of little value to verify that it is in a vulnerable state.

6 comments to Introducing Bandolier: Vulnerability Scanner Audit Files

  • erik.hjelmvik

    Operation-critical devices such as controllers, RTU’s and IED’s can’t be hardened using best practice solutions from the corporate IT world. It would however be interesting to be able to identify these types of critical devices solely by performing a network scan. This way the asset owner could get a list of the detected devices, and see if he is aware of them all. This could in fact be one way of assessing the NERC CIP 002-1 R3 requirement that states:

    “… the Responsible Entity shall develop a list of associated Critical Cyber Assets
    essential to the operation of the Critical Asset”

    If we could detect these critical devices by performing a network scan then we could also use this method to see if an asset owner erroneously has placed any critical device so that it is accessible from the corporate network. Remember that NERC CIP 005-1 R1 states that:

    “The Responsible Entity shall ensure that every Critical Cyber Asset resides within an Electronic Security Perimeter”

    So by performing a scan for from the corporate network we could check whether or not the critical devices are accessible or protected by a perimeter (such as a properly configured firewall)

    So the key question is: Can we identify if a device on a network is a controller, RTU, IED or similar just by performing a network scan?

    -Yes you can!
    The simplest way is to use the open source network scanner Nmap. For quite some time there has been an entry in the Nmap OS fingerprint database for one embedded control system device (I won’t disclose which device or which vendor). There are, to my knowledge, luckily no more control system devices in the Nmap OS database. It is however very simple to generate fingerprints for new devices using Nmap, so asset owners or SCADA contractors could build their own internal Nmap OS databases with fingerprints specialised for critical devices.

    But I urge you all NOT to submit these fingerprints to Fyodor (the creator of Nmap). Having one control system device in there is more than enough!

  • There are already several other tools out there that identify almost every control system device that has a MAC address/Network Interface Card (NIC) as this is already public knowledge. In fact, it’s much *easier* to identify control system devices *because* of this. Most control system devices have proprietary “operating systems” that are tied to their vendor, which, in turn, is tied to its NIC’s MAC address. Therefore, it’s usually a sure fire shot. Dealing with other operating systems such as Unix or Windows is much more complex. You can’t rely on the MAC address of the NIC, since they can use any number of NICs on the market and they are OS independant. Therefore, you have to rely on several actual “fingerprinting” techniques based of of behavioral analysis (relatively). Go download a copy of LANGuard, scan your devices (in a testing environment of preferably), and you’ll see what I’m talking about. You can achieve the same results with any scanner that will do a layer 2 “MAC address scan.” CAUTION: this will produce several ARP requests (ARP storm), which is why I recommend a test environment.

  • erik.hjelmvik

    Thanks for putting up a dialogue Clint!

    Yes, I am very much aware of the fact that the first 3 bytes of the MAC address of a network device reveals its vendor. In fact one of the tools out there that can identify the vendor based on the MAC address is the open source application NetworkMiner, which I have developed my self. By using NetworkMiner (rather than LANGuard that you suggested) the device vendors can be revealed by just sniffing network traffic, i.e. you won’t have to worry about producing large amounts of ARP requests.

    So why did I suggest that an active fingerprinting method based on layer 3 and 4 should be used instead of just looking at the MAC prefix at layer 2?

    Well, as you probably know the Ethernet header (in layer 2) is replaced as soon as a packet traverses a router or firewall. So relying on the MAC address won’t work when a scan is performed on a routed network or if you are scanning through firewalls. The basic idea I had was to put an Nmap scanner, loaded with OS fingerprints for control system devices, on a corporate network and let it go through your IP address space in order to make sure that no control system devices are accessible from the corporate network. This would not work if you were using MAC prefixes to identify the device vendors.

    I do however admit that for a local network it would be enough just to check the MAC prefix to determine which embedded devices you have running. But my opinion is that there is no need for using a fancy tool like GFI LANGuard just to perform a MAC prefix lookup, simple tools like Nmap (and many others) can do this just as good.

    Ps. Interesting book you have written!

  • I agree, I forgot about the routed network part of your first post. I also agree that LANGuard is an over-kill for that purpose but I mentioned it because I’ve actually seen several asset owners use it and are, therefore, familiar with it already.

    I tried to go download a copy of your NetworkMiner but SourceForge is sending me to a blank Index. I would love to demo it.

  • davidm

    Erik, by urging people not to submit nmap signatures, you seem to be advocating “security by obscurity”. The preponderance of opinion in the IT security world seems to favor “security by design”. As you and Clint discussed, there are other ways to enumerate the control system devices on a network. Wouldn’t it be better to improve the visibility of these devices in the interest of security?

  • erik.hjelmvik

    David,

    The systems/devices I am talking about have no security; they have no proper authentication mechanisms and I can from personal experience say their TCP/IP stacks can be knocked out quite easily.

    This topic is similar to the topic of using non-standard TCP ports for SCADA communication. In fact there was a recent discussion on this subject at the scadasec mailing list, where Matt Franz pointed out that:

    “Its not about obscurity, its about relative risk based on access, connectivity, availability of attacker tools, knowledge required among an attacker community. It doesn’t make it more security but it does affect the risk equation IMHO.”

    I would say this statement works reasonably well also in the case of Nmap fingerprints for SCADA and control system devices. To avoid having the fingerprints in the public Nmap database does not make these systems any more secure, but it will prolong the time it takes for a potential attacker to find the devices. So it is about making sure that whitehats detect which systems that aren’t properly protected before the blackhats do. That’s why I’m mandating that asset owners and security consultants should build their own OS fingerprint databases, but without submitting the fingerprints to the public.

    > Wouldn’t it be better to improve the visibility of these devices in the interest of security?

    In what way am I not improving the visibility of these devices by suggesting for whitehats to create OS fingerprints for their devices, and then scanning their networks?

Leave a Reply