Blog
April 14, 2022
Prin. Content Engr.
Edge networks and OT environments encounter a unique set of challenges when attempting to adopt enterprise security frameworks.
In this post, SynSaber’s Principal Content Engineer, Caleb Mathis, delves into security frameworks, asset identification, and protocols in OT and edge networks.
Security frameworks provide a starting point for establishing processes, policies, and administrative activities for information security management. Over decades, an extensive collection of standards, recommendations, and best practices has been curated to create the litany of adherence procedures that drive security within organizations.
Whether an organization has adopted NIST, ISO2700, IEC 62443, CIS, or GDPR as its top-level framework, the shared questions for an organization remain the same:
- How do we assess an accurate baseline of our current security posture against a chosen framework?
- What is the balance of people, process, and technology that fits our organization’s unique security constraints?
- How do we prioritize security improvements at different organization levels?
- How do we prove compliance across different regulation requirements?
- How do we quickly adopt changes to different regulation requirements?
- What will it cost?
Spreadsheet after spreadsheet has been generated for each framework and crosswalked with other frameworks, with the result being a series of hybrid qualitative and quantitative measurements of security posture. Whether that data is migrated to a database or managed uniquely within each organizational unit, the data is used to assess, plan, and prioritize security efforts year on year.
Organizations continue to add more technology that simplifies this process, and a wealth of information is available to enable security practitioners to meet different standards.
With IT security teams having a storied history of driving measurable improvements, why is it so difficult to achieve the same success in edge networks, particularly in OT environments?
Without delving into the complexities of shared resources and relationships between OT and IT business units, OT backward compatibility requirements, and different prioritizations within the Confidentiality, Integrity, and Availability (CIA) triad, each framework relies on consistency in the definition of an asset. Any migration from qualitative to quantitative security measurements will struggle without the unification of an asset model.
Assets in IT
“Within the information risk landscape, we can define Asset as any data, device, or other component of the environment that supports information-related activities, and which can be affected in a manner that results in a loss.”
https://cio-wiki.org/wiki/Factor_Analysis_of_Information_Risk_(FAIR)
While assets can be defined at the data and/or application level, the most common starting point for asset definition is typically by defining the devices. In IT environments, different technology vendors provide devices with varying organizations around a tuple of information. Tuples are useful for storing information that belongs together, such as identifying a person.
As unique as these individuals are, there is a strong possibility that within an organization, these names might be used to identify other employees.
As the tuple expands, the uniqueness of the individual increases. Data can be queried using the employee’s ID, and computations can be done in the forms of counts, averages, or time differences to get insights and analytics. The tuple of information for devices in IT environments is often defined with respect to networking related information for security as follows:
This information can be extracted from the devices themselves from host-level monitoring or from the communications between devices. While MAC addresses are unique to a device, there are several scenarios where consolidation between host information and network-related information must occur. Additional elements can be added to a tuple to identify the devices more accurately, such as subnet, active directory domain, facility, business unit, security owner, and/or country, depending on scope and organizational preference.
Accuracy in measuring assets can largely be achieved within IT, as many technologies have been built with integrations to allow visibility at different network and host levels and aggregated in various ways. However, this is not the case for OT environments.
Assets in OT & Edge Networks
The scenario consistently occurs where IT security practitioners must assess OT environments, and the first question is, “Well, what assets do you have in your environment?”.
Whether the returned data is a curated spreadsheet of a tuple of asset information or a handwritten list pulled from a plant manager’s desk, curation of that information requires engineers to dig through a large set of historical information and/or aggregate data from multiple control systems. Even then, there is no guarantee that each device on the network has been accounted for and the process of acquisition often leads to devices that were previously unknown being discovered.
Some security vendors have attempted to solve this problem by spanning data from switches, which is a common technique for tools in IT. However, problems arise with the traditional asset models used for IT and aggregation of data across a core switch when considering the flow of communication between higher and lower networks and across networks.
Also, due to the volume of traffic and complexities of OT environments, many security vendors have large, inflexible devices that are not easily deployable to different portions of a network.
For example, let’s consider a test network of devices as follows:
Communication flows occur both vertically and horizontally. If relying exclusively on data from the core switches, there would be several IPs associated with the MAC address from a switch — this violates the standard tuple for IT and often leads to a consolidation of multiple IP addresses into one asset.
SynSaber took this into account through the design of a small form factor sensor that can be deployed in the most difficult to reach environments, providing accurate, consistent asset models with a lower cost of entry.
Protocols in OT & Edge Networks
The devices in OT networks use a mix of protocols to communicate with each other. Even after resolving the variations of the standard tuple, accuracy in assets requires a depth of understanding of the protocols themselves. An example diagram of Modbus communication can be found in the official specification:
Vertical communication between end devices and the HMIs is done through traditional TCP/IP networking using Modbus as the communication medium. However, the gateways pictured above are what devices at the HMI level use to reference devices below the gateway.
To overcome this, Modbus added an additional data element named Unit ID within the protocol that the gateway uses to forward the Read or Write Function Codes to the appropriate asset below. This data element is a single byte and allows for each gateway to hold up to 256 additional asset addresses below it.
Conclusion
At SynSaber, we strive to reduce the efforts required by operators to curate asset data. We do this through a combination of flexible deployment and configuration options that allow data to be sent to several data aggregators for analysis by auditors and internal compliance teams within the context of any security framework.
Check out the reference architecture here: https://synsaber.com/resource/synsaber-reference-architecture/
~Caleb 🌊🏔️
Become a Subscriber
SYNSABER WILL NEVER SELL, RENT, LOAN, OR DISTRIBUTE YOUR EMAIL ADDRESS TO ANY THIRD PARTY. THAT’S JUST PLAIN RUDE.
