IEC 62443 Compliance Guide¶
SolidSyslog provides the audit trail that IEC 62443-4-2 asks a control system component to keep. It formats records to RFC 5424, holds them through an outage, delivers them over UDP, TCP or authenticated TLS, and gives a collector what it needs to detect loss. This page maps that to the audit-logging Component Requirements, control by control, and states what you supply alongside it.
The parts that usually cost integration time arrive ready-made. TLS, storage and the OS primitives are each filled by a platform you select and configure, not an adapter you write, and the platform matrix shows what ships for your target.
The library goes inside the product you ship, so the capability rating belongs to that product rather than to SolidSyslog. What follows is our account of how the library helps you meet the audit-logging controls, and is not a substitute for assessment of your finished product.
Security Levels¶
IEC 62443 grades security capability on four levels, defined by the adversary a component is expected to withstand rather than by any list of features. The standard keeps three senses of that scale apart: the level a product is capable of (SL-C), the level a deployment targets (SL-T), and the level it achieves (SL-A). A capability rating attaches to a component, so it belongs to the product you build. This page therefore states what SolidSyslog provides against each control and leaves the level to the assessment that can carry it.
Control Implementation¶
The Component Requirements below are the audit-logging-relevant subset of IEC 62443-4-2.
The table describes a deployment that has selected the protections it needs. Each control's third column says what selecting it involves, and nothing here happens by default.
| Control | What SolidSyslog provides | How you complete it |
|---|---|---|
| CR 1.5 Authenticator management | A TLS platform presents your client credential, so the collector authenticates the device. Selecting one and pointing it at your certificate and key is the whole of the wiring. The library reads the material you supply and holds none of its own | Supply the credential and protect it where it rests. File permissions, a secure element or a hardware security module all work, because the library takes the material rather than the storage |
| CR 1.8 Public key infrastructure certificates | The same TLS platform verifies the collector against trust anchors you supply, and checks its identity against a name you declare | Enrolment stays with your PKI. Where your assessment needs revocation checking, configure it in your TLS library: SolidSyslog neither performs that check nor prevents it, and the reasoning is under TLS obligations |
| CR 2.8 Auditable events | Any event your application raises becomes a conforming RFC 5424 record, with the device identity, the timestamp and its quality, and a sequence number already filled in. Carrying a field of your own is a one-function vtable, described under structured data | Decide which of your application's activity is security relevant and call SolidSyslog_Log where it happens. The record format and the delivery path are already built |
| CR 2.9 Audit storage capacity | Store and forward holds records through an outage and sends them when the link returns. You set the capacity, and an early warning tells the application before it is reached. Building up the protection you need covers the wiring | Size it to your outage budget and choose the medium. Durability under power loss belongs to the filesystem beneath, which each platform page states |
| CR 2.10 Response to audit processing failures | Every failure in the audit path reports through your error handler: delivery that does not succeed, a stored record that fails verification on read, a store that cannot be written. A full store is the case with a policy attached, and you choose whether it discards the oldest, discards the newest, or stops accepting. An early warning arrives before it is reached | Decide what an operator is told and whether the device keeps running. Error severity states what a handler receives and how urgent each event is |
| CR 2.11 Timestamps | Records carry an RFC 5424 timestamp from the time source you provide, alongside a statement of how far it can be trusted: whether the zone is known, whether the clock is synchronised, and to what accuracy. A clock that cannot answer yields NILVALUE rather than a plausible wrong time | Provide the clock and the sync state to declare. A device with no real-time clock is a supported case: it reports the quality honestly and the collector reads it accordingly |
| CR 2.12 Non-repudiation | The library supplies the evidence this control rests on rather than the cryptographic binding itself. Mutual TLS identifies the device to the collector, SolidSyslogMetaSd carries a sequence number assigned when the event is raised so a gap reflects loss anywhere in the pipeline, and sealing with HMAC-SHA256 or AES-256-GCM makes stored records tamper-evident |
Supply and manage the keys. Mutual TLS authenticates the peer that holds the connection, so where a relay terminates it the binding is to the relay rather than to the device, and a shared-key seal is verifiable by any holder of that key. Weigh both where an assessment turns on attribution |
| CR 3.9 Protection of audit information | Records are protected wherever they sit. At rest a SecurityPolicy seals each one, and AES-256-GCM encrypts it as well as making tampering detectable, which answers CR 4.1 and CR 3.4 through the same mechanism. In transit a TLS platform protects it on the wire. A record removed rather than altered leaves a gap in the sequence number, so its absence is visible at the collector | Choose the policy that matches your threat model and manage its key. At-rest cryptography compares what each one gives you. The policy is a role, so a hardware-backed one of your own fits the same way |
| CR 6.1 Audit log accessibility | Records leave the device as they are raised, so the audit log is held and read on your collector rather than on the endpoint. Any collector that speaks RFC 5424 over the transport you choose can take it, and the enhancement's programmatic access is that collector's interface | Choose and operate the collector, and control who may read the log there. Anything held on the device during an outage is sent when the link returns, up to the capacity you configured |
| CR 6.2 Continuous monitoring | Security-relevant events reach your monitoring as they happen, in a format any SIEM or intrusion-detection tool already parses, so the device is visible to whatever watches the system. The sequence number lets the monitor confirm it is seeing everything, and a device that goes quiet is itself a signal. Records held during an outage arrive late rather than never, up to the capacity you configured, and the sequence number shows the monitor anything that did not survive it | Choose the tool that watches and decide what it alerts on. The device supplies the evidence and the monitoring policy stays yours |
Both identity controls have requirement enhancements calling for hardware-backed key protection. The library reads whatever material you supply, so meeting those falls to your key storage. What any TLS stream must do is stated once under TLS obligations, and each backend's page records where it falls short of that contract today.
The library's error guards bear on CR 3.7 Error handling: every failure path reports through the injected error handler rather than failing silently.
Getting there¶
A conforming syslog record is the foundation, and the RFC compliance matrix states clause by clause what the library emits and what it leaves to you. With that in place, the table above is how that conformance answers the Component Requirements.
Building up the protection you need is the integration path: it starts at a device with no syslog and adds one capability at a time, with the question that decides whether you need each step and an indication of what it costs. How the library itself is built, and why it ports without modification, is under Core.
The development-process evidence IEC 62443-4-1 asks for is published separately: the SBOM, the vulnerability triage runbook, Security policy for coordinated disclosure, and the test and analysis gates described in CI. Threat modelling under 4-1 is yours to do for the product; the threat model page is the input we owe it.