If you’re an operator who is beginning to worry about your OT security, I’d like to encourage you to think about security in a pragmatic way, and give you some tips on how to implement it.
Maybe you are like so many operators I meet who know they need to do something, but they’re beset on all sides by the slick pitches of career salespeople sowing fear, uncertainty, and doubt. You probably suspect there’s something to all the chatter. Clearly, plenty of significant attacks have taken place which have resulted in real loss. It’s easy to think that most of those attacks looked for high-profile targets, either because they had more opportunities for theft, or a greater PR benefit to the attacker if the victim suffered a major embarrassment.
But in your world, the blip on the radar you represent maybe isn’t quite as big and shiny. So, in the spirit of ‘knowing thy enemy’, let’s talk about how targets are selected. Motivations for destructive hacks are varied, and it’s worth thinking about how to prepare yourself against the common ones.
Assuming your facility is connected to the internet, it has at least one public IP address. By definition, this is an address uniquely and randomly assigned to your facility that makes you reachable from anywhere else on the internet. It’s formed as a series of numbers, each of which can be one of 255 values. (For the purists, we’re assuming IPv4).
Chances are, you actually have more than one address. Your IT team probably exposes a few different services to the internet – email, web sites, remote access, customer applications and databases – and each has its own unique internet location.
A typical attacker is generally someone who wants most of all to feel clever and impress other attackers with his cleverness. They aren’t specifically thieves, though many are; they aren’t state-sponsored military actors pursuing a covert information-warfare objective. Most of them will play for a few years, build their skills up to a certain level, and eventually move on to something more productive. A smaller subset will take it further and become genuinely dangerous.
Like any other skill, you have to practice, and these attackers are no different. They run vulnerability-scanning tools against large blocks of public IP addresses, and whatever results come back define the subset that they engage in more detail. Your public IP addresses, numerically defined, are being touched by these sorts of reconnaissance attempts all the time.
The tools used for this are constantly evolving, and just because you may have avoided notice last time doesn’t mean you will again tomorrow. If your internet-facing resources offer up some kind of tantalizing result, you should expect to become the object of your attacker’s attention.
At that moment you probably have no indication of anything going on. You are at risk as a function of how well-protected your network is at that precise moment. In my career, this is where I’ve focused my customers more than any other area.
Industrial networks are particularly vulnerable because of the order in which internet-connected technologies were added. For most of you, a process control system was in place, but it didn’t include internet connectivity. Suddenly, the system was part of a digital transformation and you had to run network connections and ethernet switches and wireless networks and everything else. In an effort to make these transformations as painless as possible, the typical industrial network protocol is fairly permissive.
You can plug things in and have them take instructions from anything that is willing to give them, because they all generally trust the nodes on their network. There are no authentication steps, no encryption tools in widespread use, no implementations of the ‘Trust, but Verify’ methodology that has become routine on the enterprise security side of the house.
Likewise, the number of people who are genuinely knowledgeable about industrial network security are few and far between, and solutions engineers from the product vendors inevitably have a certain bias.
What should you do? Targets are randomly selected, but the chances of being attacked eventually are nearly certain; you don’t have the staff to select and maintain the technology and processes to make the program very successful. You also know the risk is real, and it’s one of those things you’ve been avoiding for a few years, but really shouldn’t ignore it much longer.
What follows is a simple set of questions you can ask before parting with budget in pursuit of security improvements:
- What problem are we trying to solve?
- Have we avoided an overly broad statement?
- Is the solution of that problem a one-time effort or an ongoing process?
- Do we have the necessary staff bandwidth and knowledge to keep the solution working properly?
- Do we have the necessary strategic support from the top down to ensure the entire organization learns both our goals and the method?
- In a moment of self-reflection, am I personally the best person to lead this effort?
The last one is a trick question. Anybody with management skills and a history of real responsibility can learn how to frame a security objective in business terms, and then manage it through to conclusion. You may not have the technical knowledge or understanding of particular risks at the outset, but you can learn that if you know a bit about IT and networks. If all that is entirely beyond you, recruit a technical assistant to help.
As you work through the questions, remember you’re trying to converge on a few different answers simultaneously. Yes, you need to understand more about your current exposures, ideally without spending huge amounts of money to get an answer. Yes, you are trying to avoid setting up your operation for failure by choosing the wrong goal and having the wrong resources to pursue it. And yes, you are probably being faced with multiple tactical security solutions from eager vendors.
The subtext, though, is more important. You need to know how to state the risk problem in business terms: “If my water plant is contaminated, cleanup will take three weeks, 350,000 people will be impacted, and the company’s reputation will be tremendously damaged. My CEO will be on the evening news, and that won’t be good for anybody.”
From that risk statement you might ask what devices attached to your network could cause the water supply to be contaminated, and what options exist to protect those devices from malicious or accidental changes. Now you have a reasonable scope and probably an achievable goal.
The hard task that follows is identifying solution providers from among the dizzying array of buzzwords and marketing fluff.
If you have a good relationship with an ICS value-added reseller or distributor, or you’re already working with an integrator or engineering firm, start there. Don’t ask them about your risk statement, at least not at first. Ask them which security products and vendors they trust, and why. Every security solution you might purchase is essentially a kind of insurance – it’s no silver bullet, but the good ones can perform well if they’re installed correctly and your team knows what to do. For maximum assurance, a trusted relationship with the vendor including full transparency about problems and limitations is critical.
Another great place to identify good vendors is at trade or peer group events in your local area. Word of mouth sells more security solutions than any amount of flashy advertising. There is comfort in knowing other users of the same tool, because you can collaborate on your respective user experiences and work jointly on priorities for new features and enhancements.
Finally, decide what comfort level your management chain can accept regarding how big a piece to bite off. Finding success on a small, neatly defined project is almost certainly a better strategy to begin with and the experience you’ll gain working with your solution providers and your own staff will have a tremendous influence on how you approach project #2.
Thank you for reading, and good luck in your security projects for 2019 and beyond!
Toby Weir-Jones is the Chief Product Officer of Bayshore Networks, a provider of inline protection tools for PLCs and other devices on industrial networks.