Back to Blog
OT or Operational Technology can be defined as the hardware and software dedicated to detecting or causing changes in physical processes through direct monitoring and/or control of physical devices such as valves, pumps, etc. For those of us who have lived in the IT world, this may seem like a foreign realm and terms like SCADA (supervisory control and data acquisition), DCS (distributed control system), ICS (industrial control system), and PLCs (programmable logic controller) may take you out of your safe space. No one likes to feel like they are the Noob in the room and the divide between IT and OT makes both sides uncomfortable as neither feels they can play well in the other’s world. Given the upsurge in operational technology security threats and the increased visibility in many companies to this new vector, both sides are going to need to meet in the middle to address the issue. The question is where do you start? Many organizations run into trouble because the OT teams are adamant about limiting any impact to the continuous operations of the operational technology network and the connected devices. This stance is justifiable as impact here can affect business outcomes and potentially damage equipment, but may also result in injury or in the worst-case loss of life. IT security teams typically don’t understand the legacy nature of systems and networks in the operational technology side of the house and the issues that the OT team is dealing with in keeping systems running where uptime is measured in years.
One of the easiest places to start and one that is often skipped in the rush to get controls in place is developing an operational technology security policy. It is extremely difficult if not impossible to effectively skip stages in the maturity cycle and that’s why skipping the development of an operational technology security policy is so critical. By starting with policy, it gives a starting point for both sides of the organization to have a conversation that can result in bridging divides and reaching a common understanding of what the outcome should actually be for operational technology security. The OT team can get an understanding of what type of controls are being proposed and the IT security team can get an understanding of where and why controls will and will not work. Here is a good comparison from NIST 800-82:
| Category | Information Technology System | Industrial Control System |
| Performance Requirements | Non-real-time The response must be consistent High throughput is demanded High delay and jitter may be acceptable Less critical emergency interaction Tightly restricted access control can be implemented to the degree necessary for security |
Real-time Response is time-critical Modest throughput is acceptable High delay and/or jitter is not acceptable Response to human and other emergency interaction is critical Access to ICS should be strictly controlled, but should not hamper or interfere with the human-machine interaction |
| Availability (Reliability) Requirements | Responses such as rebooting are acceptable Availability deficiencies can often be tolerated, depending on the system’s operational requirements |
Responses such as rebooting may not be acceptable because of process availability requirements Availability requirements may necessitate redundant systems Outages must be planned and scheduled days/weeks in advance High availability requires exhaustive pre-deployment testing |
| Risk Management Requirements | Manage data Data confidentiality and integrity is paramount Fault tolerance is less important – momentary downtime is not a major risk Major risk impact is the delay of business operations |
Control physical world Human safety is paramount, followed by protection of the process Fault tolerance is essential, even momentary downtime may not be acceptable Major risk impacts are regulatory non- compliance, environmental impacts, loss of life, equipment, or production |
| System Operation | Systems are designed for use with typical operating systems Upgrades are straightforward with the availability of automated deployment tools |
Differing and possibly proprietary operating systems, often without security capabilities built-in Software changes must be carefully made, usually by software vendors, because of the specialized control algorithms and perhaps modified hardware and software involved |
| Resource Constraints | Systems are specified with enough resources to support the addition of third-party applications such as security solutions | Systems are designed to support the intended industrial process and may not have enough memory and computing resources to support the addition of security capabilities |
| Communications | Standard communications protocols Primarily wired networks with some localized wireless capabilities Typical IT networking practices |
Many proprietary and standard communication protocols Several types of communications media used including; dedicated wire and wireless (radio and satellite) Networks are complex and sometimes require the expertise of control engineers |
| Change Management | Software changes are applied in a timely fashion in the presence of good security policy and procedures. The procedures are often automated. |
Software changes must be thoroughly tested and deployed incrementally throughout a system to ensure that the integrity of the control system is maintained. ICS outages often must be planned and scheduled days/weeks in advance. ICS may use OSs that are no longer supported |
| Managed Support | Allow for diversified support styles | Service support is usually via a single vendor |
| Component Lifetime | Lifetime on the order of 3 to 5 years | Lifetime on the order of 10 to 15 years |
| Components Location | Components are usually local and easy to access | Components can be isolated, remote, and require extensive physical effort to gain access to them |
Like any other policy discussion, it is best practice to start with an industry-accepted guideline, but it should be tailored to the organization. It’s critical to understand what the end state should be and develop a realistic roadmap to get there. Optimally this should be approached from a risk-based perspective, understanding what the tolerance for risk is in a given environment will indicate what the final state of the controls should be and will usually provide input to the timeline for how aggressively the end state is reached. If you are looking for a place to start and a framework to apply then I would recommend taking a look at NIST 800-82, the NIST Guide to Industrial Control Systems (ICS) Security. This guide is not only a good place to start the policy discussion but it also provides a good primer for those not familiar with operational technology and terms.
Once you settle on a framework and develop a plan to implement policy, look for opportunities to create small wins where you can demonstrate the ability to raise the security posture in a low impact manner. One of the biggest needs in many environments is simply to have an accurate inventory of which devices and systems are on the network and a way to raise a flag if a change happens, either adding or removing a device. This can be accomplished in a very low impact way by implementing a passive scanning technology to gather information that is readily available on the network for every connected device with no impact on the network. This step can then be enhanced to leverage this information to in turn develop relevant security detail such as vulnerability information, rogue device connectivity, and potentially malicious connection information. This can all be accomplished with no impact on the network and OT environment. This is where you start, bridging the gap between the organizations through shared understanding, a common taxonomy, and implementing controls that benefit both groups. Operational technology security is an area that we can’t afford to take lightly anymore.
Download 5 Crucial Steps to Secure Industrial Networks
Ben Carr is VP Strategy at Cyberbit