The mission of the security operations center (SOC) has evolved over the years. Building a security operations center used to involve onboarding as many device feeds as possible. Today, it’s more about having an integrated security information and event management (SIEM) and big data platform — complemented by workflow, automation and analytical tools — with device feeds that all tie directly back to specific business goals. The SOC needs to be streamlined — a modern strategy is especially critical for operational technology environments.
Operational technologies are all systems, all Purdue model levels and related computing used to run industrial environments, automation and control systems.
What Do Operational Environments Need?
When building a security operations center, the No. 1 priority is defining your specific business objectives. In fields such as process manufacturing, firms are concerned about protecting their recipe and keeping the equipment running.
What is the recipe? It defines the tolerances, temperatures and chemicals workers should use and how to apply them. These rules might include specific times and specific ratios in manufacturing processes. The recipe is what allows the brand to be different and better than its rivals.
So how does a security team protect that critical asset? This is exactly the type of business question industry needs to ask. It will help define our strategy for building a security operations center for operational technology environments.
To learn more about how to modernize your security operations center for operational technology, register for our webinar.
Different Risks With Operational Technology
Most industries that have operational technology environments, including oil and gas, manufacturing, distribution and critical infrastructure, have been around for decades. So, there is the perception that security for operational technology is historically different. Workers may think their industry is not subject to the same types of cybersecurity risks as traditional IT. Risks are there though, and malware attacks can propagate across operational environments. For example, the Shamoon malware disrupted the operations of oil and gas producers and destroyed company data.
These security risks are present within operational technology and could have devastating impacts if exploited. Field operations and, in some cases, manufacturing operations involve heavy equipment and critical machinery. If the equipment were to go down or if it were to spin out of control, there could be terrible results.
For example, it’s important to avoid what we call a race condition. Let’s say a pump or a nuclear reactor has a normal cycle to produce something 60 times a minute. Then suddenly, malware is introduced that increases the cycle to 1,000 times a minute. If that process runs for about five minutes, soon everything will overheat, and there could be a meltdown or explosion.
Monitoring Operational Technology in a Modern SOC
After naming business objectives and building SIEM use cases around those objectives, the next step to creating a good SOC is knowing what devices are in your operational technology environment. One of the reasons why the adoption of cybersecurity monitoring for operational technology has been slow until recent years is there have not been many ways to understand what’s on the operational technology network. Today, we have different monitoring solutions for operational technology, Internet of things and Internet of medical things that can tell you all the devices on your network, the current software version of each device and even what version of software the device should be on.
Next, you need to have a way to monitor the operational technology devices for changes or attacks in real time. Then, it is a matter of connecting that data to the security operations center. Some groups want to build a specific security operations center for operational technology, but the reality is that most clients want to build a converged IT/operational technology SOC. For clients who are just starting down this path, the goal should be to gain initial awareness and make sure devices are patched at the right level.
Teach the SOC Team to Talk About Operations
Another thing different about operational technology, as opposed to another type of business which might need a SOC, is the people. Operational technology organizations tend to not have a traditional chief information security officer role. This is because operational technology workers tend to come from mechanical and electrical engineering careers, where they focus on machinery and processes. By contrast, security experts tend to come from software development and computer science disciplines, and they focus on emerging IT threats. Therefore, the management for operational technology groups and organizations is often not used to having a top-down security function overseeing them.
Another critical difference in building an operational technology security operations center is having personnel with the right level of expertise. Level one, two and three SOC analysts have often been trained on what to do when they see an event that is targeting a database. IT analysts know what steps to take if an exchange server goes down. But if malware is bringing down an oil refinery, you can’t just call the IT manager and reboot a server.
In order to make sure your people are the right fit for the job, you can cross-train your security analysts or create a special operational technology pod that sits in the same room or same building. The analysts in that pod need to understand the urgency of addressing an alert involving heavy equipment.
Incident Response Plans for Operational Technology
An operational technology security operations center also needs very different incident response plans. Instead of contacting forensic investigation teams and public relations, the right contact is the plant manager and the director of field operations in a given territory.
The team also needs to know specific language about the work. This may be very different from the conversations they’re used to about reinstalling software on laptops. Potential impacts to operational technology devices have to be communicated in a language that the field director or field operations director would understand. That language could include terms for industrial control systems and supervisory control and data acquisition systems.
Operational Technology SOC Consulting
SOC experts like IBM use the Purdue model to look at how IT and operational technology converge. This includes a proprietary use case library — mapping to the various threat vectors, industry verticals and layers of the Purdue model. In the future, all security operations centers will integrate IT and operational technology. So, now is the time to bring these teams together.
The post Ensuring Your Security Operations Center is Ready for Operational Technology appeared first on Security Intelligence.
This post appeared first on Security Intelligence
Author: Shelley Bland