Cyber security vulnerability assessment

Companies that decide to undertake a cyber security program often falter right out of the starting blocks because they don’t begin by addressing some of the most basic concepts of security. Without that knowledge it is impossible to plan, and without a plan, the results will be haphazard at best and will likely make things worse. A sensible approach needs to begin with a basic understanding of what vulnerabilities may exist in your systems. Such an analysis is conceptually straightforward, but it can get complex in practice if not executed well. In most situations it is painful because companies often discover that the situation is worse than they thought.

One of the first steps is to determine what security standard(s) or guidance you need to be addressing. There are a few possibilities with a history of addressing control system components, such as NERC CIP-005, CIP-007, INGAA, CPNI, and DHS CFATS. Your industry and the nature of your processes will guide this decision. You might think that choosing a standard is too “high-altitude” when what you really want to do is go out and start buying firewalls, but consider this analogy: Let’s say you want to build a food processing plant, so you want to use sanitary practices. If you don’t know how groups like 3-A and the FDA have established sanitary practices, there’s little chance you will end up with a facility that will pass inspection. The same goes for plant safety systems. You can fix some obvious hazards, but eventually you need the guidance that a standard gives.

Next, you need to convince yourself that vulnerability assessment is not an event. It is a process that goes on constantly. You need to think about it every day because your systems are not static, nor are the threats. Plug yourself into information feeds from cyber security groups, beginning with the DHS ICS-CERT. This will help keep you up-to-date and suggest directions for your own analysis.

A painful process

Probably the part of the process that companies find the most painful, physically and psychologically, is taking an inventory of all your cyber assets, how they’re connected, and how they’re programmed. This can be a monumental task if you don’t have much documentation or what you have isn’t current. But it means everything:

• Servers
• Network switches
• User terminals
• Desktop and laptop PCs
• PLCs and controllers
• Terminal racks
• Wireless transmitters and receivers
• Mobile devices on the network, and
• Everything else.

Once you’ve found all those devices, document what software is installed on each, and how they’re interconnected. Yes, it may be a huge job, but it is absolutely necessary.  This includes not just servers like file, database, print, and web but also applications like Microsoft Word and even system firmware. Once compiled, your documentation must be updated every time you change anything, including software patches and updates. Otherwise, there is no possible way you will be able to block all the points that a creative hacker might find.

In a perfect world, this shouldn’t be a significant undertaking at all, because all of this would already exist and be up-to-the-minute. However, I’ve never seen it. No company has everything complete and current, so don’t think you’re alone.

Performing this process is easier if you have a plan:

Talk to your people—The individuals who work with your networks may be very familiar with specific parts of your systems, and may have some ideas of where vulnerabilities exist. Make sure your discussions don’t turn into interrogations if you want cooperation. Also make certain that you have a process in place to keep all of this documentation protected. The last thing you want is to perform the vulnerability analysis and have this information end up in the wrong hands. 

Review your documentation—Anything is better than nothing. Even outdated and incomplete diagrams can serve as a starting point and be revised.

Review device configurations—This can be a very tedious process, but you need to know all the software that’s running in your facility, down to the revision level. Finding the answer may be difficult in situations where the code in a particular area or machine is from an OEM or system integrator. Such a third-party supplier might not want to divulge that information, although more are beginning to understand the need for it in this context. This exercise might be a good time to get rid of things that shouldn’t be there, like that MP3 player installed on a control room terminal.

Trace wires—Buy some kneepads and start crawling around under tables and looking behind racks. You need to see where the connections are, and what connections might exist that you don’t know about. There are all sorts of reasons why somebody thought tying various devices together was a good idea, and you need to find them.

Analyze network traffic—When you see how things are really interacting on your networks, it can alert you to all sorts of things. You need to know what is talking to what, because these communication channels need to be controlled and directed. Where does this VPN go? What new channels needed to be created when we changed ownership?

Analyze wireless traffic—While you can trace wires, wireless can go anywhere. Begin by determining how many and which frequencies you’re using. Bluetooth, 802.11, Zigbee, 900 MHz, and more are possibilities. This is especially critical since breaking into your network may require nothing more than buying the same kind of wireless repeater someone installed to replace damaged wiring.

Once your documentation gets into better shape, test yourself. Get out in the plant and run audits to see if the diagram matches reality. If the diagram says five connections should be coming out of that switch, why are there six? Pick a cable and make sure you can find it on the plan. Does this firewall have the correct rules installed? If you flunk any of those tests, you need to take a hard look at the work so far.

The next level

More sophisticated analysis can begin once your documentation is in order. Look at your systems and ask yourself some questions:

What processes and tools can operate manually? What happens if you are subject to an attack or other system failure? Do you have the possibility to run anything independently in manual mode? If you’re stuck in a degraded situation, that ability can be the difference between continuing to produce and being shut down completely.

How many of your systems share infrastructure? Are you networked more tightly than you should be? Keeping some separation between parts of the plant or production units can help isolate problems and minimize the effects of an intrusion.

How “flat” is your security? If you have a remote terminal at a location that is normally unmanned, the level of physical and cyber security at this location should probably be higher than it is for the control room within your plant. The level of security should reflect the potential for intrusion.

What security weaknesses are baked into various devices within your plant? There are likely many devices on your networks that have little protection on their own. PLCs have default passwords and even hard-corded passwords, all the solutions implemented by a vendor may use the same architecture for each client (even down to the MAC address), or data exchanged via clear text. If those can’t be changed, such devices will require extra network protection.

Look at your systems with the idea of trying to make something malfunction or break on purpose. Can you force a valve to open or close? Can you make a pump start when it shouldn’t? If a hacker is trying to break into your plant, this is the kind of thing that could happen.

Can a less critical (and less protected) system serve as a gateway to something important? Look at how various systems are interconnected. A low-level system may have little protection because the possibility of causing mayhem is small. While that is appropriate, you have to make sure the low-level system cannot offer the means to infiltrate something more critical.

Industrial realities

Engineers who work in IT environments look at industrial networks and usually ask why we don’t use some basic security techniques common to office and commercial systems. The fact is that much industrial equipment is pretty weak. If a hacker can reach a PLC, it’s probably a soft target. That means our networks have to be hardened at multiple levels; otherwise, someone breaking through a perimeter will have little trouble moving around and causing problems, potentially even placing someone’s life at risk.

This is one of the reasons why knowing your networks inside-out is so important. You have to be able to out-think a hacker, finding possible weaknesses and fixing them before someone on the outside can take advantage of an opening. You’ll never be completely secure, but with some coordinated efforts, you may be able to stay one step ahead.

Matt Luallen is founder of Cybati, a cyber security training and consulting organization, and is a frequent contributor to CFE Media.

https://www.us-cert.gov/control_systems/ics-cert/

https://cybati.org

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our WTWH Media editorial team and getting the recognition you and your company deserve. Click here to start this process.