Folks often approach me with a question along the lines of, “How do I learn ICS security?” I’ve already talked about the question with regards to general cybersecurity, so let me take a crack at it.

There are a lot of parallels between that question and, “How do I get into infosec?”. I can help to some degree with fundamentals, but the space is so incredibly broad and contains so many verticals and niches that my next questions will almost always be, “In what vertical?” “Offensive or defensive security?”, and so forth. The manufacturers and protocols in use in the electric sector are quite different than those used oil and gas, and the underlying industrial processes are even more different.

With regards to the essential fundamentals to build upon existing cybersecurity knowledge, Rob Lee has put a wonderful and definitive list of ICS security learning resources up on his site. I very much appreciate that he breaks those training resources into several crucial areas for learning how to attack and secure industrial systems. He covers some essential areas which I feel are often missed in these conversations, like processes and vertical operations.

So, real talk. With appropriate cybersecurity skills, you can easily download industrial system simulators or buy industrial control devices off of eBay and learn to exploit them. You will quickly discover that very few lower level ICS standalone devices (much less industrial protocols) have any native security to speak of. Breaking them in a lab isn’t particularly hard. Breaking them in a specific manner is more complex and time consuming, but still very manageable. Industrial devices like PLCs and HMIs are designed to reliably perform a specific set of tasks whenever they are told to, and often don’t have handling for commands or conditions they don’t recognize.

The reason we don’t see power plants fail catastrophically every week is not a lack of adversaries or vandals with opportunity and motive. It’s not necessarily even a lack of technical capacity to do stuff that makes an individual PLC break in a lab. It is primarily because they are complex chemical, mechanical, and electrical systems. They have many physical safety controls not connected to the network, and many redundancies.

When a real, sophisticated adversary decides to attack a system like a power plant, there are two major limitations on their activity:

1) They are typically forward-thinking enough to not launch a visible, kinetic attacks without reason (geopolitics, warfare, attack development, etc). So, they build footholds and then wait.

2) It takes a lot of time and resources to conduct reconnaissance and develop an attack which impacts a unique industrial process as a whole in a specific manner. Every environment is configured in a slightly different way and has different analog and mechanical fail safes. An attack on one company’s oil refining process will not likely work in exactly the same manner on another company’s facility.

That is not to say that serious damage can’t be done to the industrial systems which are exposed to the internet on Shodan – or within an industrial network by accident or haphazardly. This is simply a dice roll given the complexity and redundancy of process systems – and any such activity may draw immediate security detection and response. Things like ransomware certainly may cause a process impact, but that impact is rather unpredictable. So, we absolutely still have to be very careful with active scanning, assessment, and exploitation in live industrial environments. Our tool set and interactive capacity is often extremely constrained in ICS security for very good reason. Breaking individual devices and being an expensive pain, however, is not the same as purposefully turning off the lights to a city, or setting a factory afire.

For example. a good red teamer in ICS knows not only how to attack industrial protocols and devices, but she knows how they fit into a holistic system of systems and can cause an impactful consequence to a process. Secondly, she knows how to have competent conversations with process engineers and operators about this. She can explain to process owners how access or exploitation of a device could realistically lead to a meaningful consequence without adequate mitigations. She can advise the organization to make a risk decision about mitigation of the issue versus the risks the mitigation activity itself poses to the process. Remember, these are often environments with legacy devices that cannot be upgraded due to maintenance contracts or integrations, and which have extremely rare downtime windows. Taking a system down for maintenance may cost millions of dollars.

In summary, here are my recommendations:

1) Ensure you have a solid understanding of the necessary cybersecurity essentials, such as protocol dissection, packet capture and analysis, and packet forging. ICS security is not the first place to start your cybersecurity journey, unless you are moving from an ICS position into cybersecurity.

2) Study essential ICS vocabulary, device programming, and common protocol fundamentals using the resources which Rob shares on his blog. Modbus is a terrific place to start understanding industrial protocols because it is common and well documented. You should understand the basics of ladder logic programming, and what types of devices and protocols exist at the various levels of the (admittedly academic, but useful) Purdue model.

3) Choose to focus on a niche of red teaming or blue teaming, such as forensics or exploit research. Hypothetically, this should match up with your existing IT cybersecurity skill set. Skills certainly do translate (particularly legacy skills).

4) Choose a vertical to focus on. Otherwise, you will be overwhelmed. This could be related to your day job, or simply something that interests you. Read up on the vertical and the industrial vendors, protocols, and processes typically present at each Purdue level. You don’t need to become a mechanical, chemical, or electrical engineer. You need to know enough about the high level process and technologies to have competent conversations with them without looking like a dope.

5) Build your skills in understanding systems of systems, with relation to cybersecurity risk. This means identifying and considering the consequences that the engineers and operators care about in their process. An entire industrial network can be running XP and infected with Conficker, and if it poses no substantial risk of a consequence of concern, it is totally irrelevant. Learn to have constructive conversations with process owners to identify which components of processes could cause consequences of concern despite existing mitigations, and which of those systems are associated with industrial systems. Those are areas you should focus your defensive and offensive security efforts. This is a key skill which will separate you from amateurs.