IEC 61850 Security Research: From SCL and MMS to GOOSE, Sampled Values, and the Process Bus

By RUGERO Tesla (@404Saint). IEC 61850 is another one of those protocols that becomes more interesting the deeper you go. At first glance, it looks like another industrial protocol to dissect: identify the transport, decode the messages, enumerate the data model, and look for places where authentication or authorization is missing and that description turns out to be inadequate. IEC 61850 is an ecosystem of communication models rather than a single protocol. MMS operates over the station bus and provides a comparatively conventional client/server interface. GOOSE and Sampled Values operate directly over Ethernet and introduce an entirely different set of assumptions around multicast, timing, state, sequencing, and data integrity. That difference became the central theme of this research. I spent several days building an isolated IEC 61850 laboratory around libIEC61850 , examining SCL configuration, MMS sessions, control operations, GOOSE, Sampled Values, and process-bus behavior. The work combined packet captures, custom Python tooling, native library examples, malformed-input testing, and direct observation of the simulated IEDs. There was also an unexpected historical component. During the research, Parker McCauley pointed me toward Bruce Muschlitz, a former UCA conformance-testing participant, with a simple instruction: Ask Bruce about the UCA decision dart board. That conversation eventually led to an older 9-2LE Sampled Value capture, a legacy Excel visualization tool, and several observations about how real conformance testing used to be performed. So this article is both a protocol-security study and a record of how the investigation evolved. 1. Establishing the IEC 61850 Architecture Before touching packets, I wanted a clear model of what I was actually testing. The laboratory was divided conceptually into three communication areas: IEC 61850 Laboratory │ ┌────────────────┼────────────────┐ │ │ │ ▼ ▼ ▼ SCL / Station Bus Process Bus Configuration │ │ │ ┌─────┴─────┐ │ │ │ MMS GOOSE SV │ │ │ TCP/102 Ethernet Ethernet The difference matters because MMS and the process-bus protocols do not provide the same security boundaries. MMS uses ISO-on-TCP and exposes an application-layer model containing logical devices, logical nodes, data objects, and control points. GOOSE and Sampled Values are much closer to the wire. They are Layer 2 Ethernet protocols identified by EtherTypes rather than TCP or UDP ports. That immediately creates different questions for a security researcher. For MMS: - What can a client discover? - Can it establish a session anonymously? - What objects are exposed? - Which operations require authorization? - Are control operations protected? For GOOSE and SV: - Who is allowed to publish? - How is publisher state represented? - How are sequence numbers interpreted? - What happens when frames originate from an unexpected source? - Can subscribers distinguish legitimate traffic from manipulated traffic? The architecture primer established these questions before the experiments began. 2. SCL: The Configuration Is Part of the Attack Surface The first formal phase examined the SCL configuration rather than immediately attacking the network protocols. IEC 61850 systems rely heavily on configuration describing IED capabilities, logical nodes, communication parameters, datasets, and relationships between devices. That means some of the information required to understand the operational system may exist before a single application-layer packet is exchanged. Figure 1. SCL configuration analysis from the laboratory. The configuration provided the structural baseline used for subsequent MMS and process-bus experiments. This was important for the rest of the research because the later experiments were not performed against an abstract IEC 61850 endpoint. They were performed against a specific configured data model. The configuration therefore became the reference against which observed behavior could be interpreted. 3. MMS: Finding the Station-Bus Attack Surface The next phase moved into MMS. The laboratory IED exposed MMS through ISO-on-TCP on port 102 . Once a connection could be established, the interesting question was no longer whether TCP/102 was reachable. It was what the server was willing to disclose and execute after the connection. The first step was enumeration. A custom Python harness was used to inspect the MMS information model and map the exposed hierarchy. MMS │ ├── Logical Devices │ │ │ └── Logical Nodes │ │ │ └── Data Objects │ │ │ └── Data Attributes │ └── Control Objects Figure 2. MMS data-model enumeration performed against the laboratory IED. The important observation was that the server exposed a meaningful operational model after session establishment. This matters because IEC 61850 does not merely expose registers in the way a simple legacy industrial protocol might. The client is interacting with a structured information model. Once that model is known, the next question becomes much more interesting: Which parts of that model can actually be manipulated? 4. MMS Control: Discovery Became Manipulation The third phase focused on control operations. The initial attempt to write directly to a control value did not behave as a naive writable register would. The server rejected the operation because of its data-typing and control semantics. That failure was useful. It demonstrated that a failed raw write does not necessarily mean the underlying control point is protected. IEC 61850 provides higher-level control services through the ACSI model, and the correct operation path produced a very different result. The laboratory demonstrated that a properly constructed control operation could alter the simulated control state without an authentication mechanism being enforced by the tested configuration. Figure 3. Laboratory observation of MMS control operations against the simulated IED. This became one of the more important distinctions in the research: A protocol implementation can correctly enforce its application semantics while still providing insufficient security authorization. The server knew that the request had to be structured correctly. It did not necessarily know whether the requester should have been allowed to perform it. That is central to industrial protocol security. 5. Leaving TCP Behind: The Process Bus At this point the research became considerably more interesting. MMS had given me a structured client/server interaction model but GOOSE and Sampled Values did not. Both operate directly over Ethernet. Ethernet │ ├── 0x88B8 → GOOSE │ └── 0x88BA → Sampled Values The laboratory used Linux network namespaces and a virtual Ethernet bridge to create an isolated process-bus environment. The basic topology was: br-processbus / \ / \ ns-ied1 ns-sub1 │ │ veth-ied1 veth-sub1 The IED and subscriber could therefore exchange Layer 2 traffic without involving the physical network. That gave me a controlled environment for examining the actual Ethernet frames. Figure 4. Process-bus traffic observed inside the isolated laboratory bridge. This was also where the security model changed. There was no TCP session to authenticate. There was no client/server connection in the conventional sense. A subscriber observes Ethernet frames and interprets them according to the protocol semantics. That makes source identity, state numbers, sequence numbers, timing, and cryptographic protection much more important. 6. GOOSE State Is More Than Payload GOOSE frames contain state and sequencing information that allows subscribers to reason about publisher behavior. Among the fields examined were: stNum sqNum TAL stNum represents the state number while sqNum tracks sequencing within a state. The Time Allowed to Live value provides another important piece of information about the expected timing behavior of a message. These fields are not merely metadata. They influence how a subscriber interprets the stream. That means manipulating them can potentially affect the subscriber's view of system state even when the underlying payload appears structurally valid. The research therefore moved from passive dissection into controlled anomaly injection. 7. GOOSE and SV Injection The fifth phase tested how the process-bus environment reacted to deliberately manipulated traffic. The experiments included: - unauthorized source MAC addresses; - extreme stNum values; - sequence-number manipulation; - quality-field manipulation; - Sampled Value frequency anomalies. Figure 5. Controlled GOOSE state-number manipulation using an unauthorized source. The purpose was not to demonstrate a production attack. The laboratory was used to determine how the simulated protocol participants interpreted abnormal frames. A structurally valid frame can therefore become interesting from a security perspective even when the Ethernet frame itself is perfectly ordinary. 7.1 Quality Metadata One experiment modified the quality information associated with the transmitted measurement. Figure 6. Controlled quality-field manipulation during process-bus testing. This illustrates an important property of industrial telemetry: The numerical value is only part of the information being transmitted. A measurement may be accompanied by metadata describing its quality or validity. An attacker who changes the metadata does not necessarily need to modify the numerical value itself to influence how downstream systems interpret the measurement. That creates a useful difference between: Value integrity + Metadata integrity. They both matter. 7.2 Sampled Value Frequency The same principle appeared in Sampled Values. Sampled Value streams are time-dependent. Their usefulness depends not only on the numbers being transmitted, but also on the temporal characteristics of the stream. One controlled experiment introduced a frequency mismatch into the SV traffic. Figure 7. Controlled Sampled Value frequency anomaly observed during the process-bus experiment. This becam