L2Proxy Industrial Security Platform¶
L2Proxy is an industrial access, inspection, policy, and evidence platform for OT and ICS environments. It combines authenticated session context, deep industrial protocol inspection, equipment knowledge, explainable decisions, stateful protection, and industrial-language events.
Customer statement: L2Proxy identifies who introduced an industrial operation, which equipment and process context it affects, whether it is permitted, and why the operation was recorded, allowed, or blocked.
Platform at a glance¶
Identity and session
↓
L2Proxy Dissector
↓
Equipment-aware and stateful policy
↓
Record / Allow / Block
↓
Industrial-language event and traceable evidence
Figure — Platform at a glance: managed layers, enforcement choices, and deployment topologies.
Identity is native when L2Proxy Connect is used. Standalone L2Proxy Services provide the same protocol-aware policy and evidence capabilities at independent industrial network boundaries.
Core product capabilities¶
| Capability | Industrial outcome |
|---|---|
| Native protocol dissection | Visibility beyond TCP/UDP ports and generic flow metadata |
| Explainable Rule Engine | Reviewable policy aligned with permitted plant operations |
| Guided rule authoring | Contextual autocomplete, inline help, validation, and reusable industrial templates |
| Equipment and protection library | Reusable equipment definitions with operational points, safe ranges, permitted commands, and baseline protection |
| Industrial policy management | Guided creation and lifecycle management of user-, equipment-, and operation-specific access policies |
| Policy Profile composition | Assembles reviewed policies into the approved policy set used by an enforcement path |
| L2Proxy Connect | Applies protocol-aware policy inside an authenticated access session and links decisions to the user, session, and access domain |
| Industrial segmentation and microsegmentation | Creates protected access domains and limits communication by network, identity, equipment, operation, and state |
| Per-user standalone enforcement | Assigns a VPN user an isolated access path, Policy Profile, and independent L2Proxy instance when separate network enforcement is preferred |
| Standalone service management | Creates, configures, starts, stops, restarts, and supervises multiple independent protection services |
| Stateful correlation | Detection of sequence, timeout, replay, identity drift, and missing prerequisites |
| Inline allow / block | Enforcement at authenticated sessions or transparent and routed OT boundaries |
| Passive and PCAP workflows | Low-risk baselining, investigation, training, and rule validation |
| Structured event output | Integration with the event archive, reporting, and incident workflows |
| Industrial event normalization | Converts DNP3 traffic into asset-aware operational events, classifications, discovery signals, and readable descriptions |
| Event archive and evidence | Retains raw parser output, rule decisions, and normalized events for query, audit, and investigation |
| Event exploration console | Filters dissections and rule decisions, highlights verdicts, and opens full frame evidence from the browser |
Two enforcement models, one industrial policy platform¶
| Enforcement model | Best fit | Industrial value |
|---|---|---|
| L2Proxy Connect | Authenticated remote industrial access | Links the user and live session directly to equipment, operations, decisions, and evidence |
| Standalone L2Proxy Service | Transparent, routed, isolated, passive, or offline paths | Provides independently managed protection for industrial boundaries and validation workflows |
Both models use the L2Proxy Dissector, Rule Engine, stateful protection, equipment context, and evidence pipeline. A site can use either model or combine them.
This combination supports identity-aware North-South access and East-West protection across managed communication paths. See Industrial Segmentation and Microsegmentation.
Deployment choices¶
L2Proxy Connect¶
Apply industrial policy within the authenticated remote-access session. L2Proxy Connect receives the established user and session context, inspects industrial traffic in the internal forwarding path, and records or enforces the decision before that traffic continues. This provides direct traceability from a person and session to the equipment and operation without requiring a separate bridge or routed inspection detour.
See L2Proxy Connect for the complete customer view.
Transparent bridge¶
Place policy enforcement between industrial segments without changing the existing IP addressing plan. This is suitable for cell/area boundaries where Layer-2 transparency is operationally important.
Routed boundary¶
Apply the same inspection and rule logic between OT subnets or VLANs. This is appropriate for boundaries such as engineering-to-control, site-to-site, or supervisory-to-field networks.
Passive inspection¶
Evaluate traffic without blocking it. Passive operation is the preferred starting point for asset visibility, policy tuning, false-positive measurement, and customer acceptance testing.
Offline PCAP analysis¶
Run the parser and rules against captured traffic. This supports incident review, regression testing, demonstrations, and validation before an inline change window.
See Deployment Modes for selection guidance.
Protocol coverage is not a single yes/no claim¶
L2Proxy separates four levels of maturity:
- Dissection — the protocol can be decoded into fields.
- Stateless policy — fields can be used in packet-level rules.
- Semantic helpers — stable protocol-aware predicates reduce ambiguity.
- Stateful use cases — tested multi-packet policies are available.
DNP3 is currently the first protocol portfolio presented in depth in this customer catalog. Other protocol portfolios can use the same structure for industrial use cases, semantic helpers, stateful protection, complete policy examples, and qualification evidence. Current published scope is stated in the Capability Status page; parser presence alone is not presented as production-ready enforcement.
Rule decisions¶
The customer-facing enforcement scope is deliberately clear. Product interfaces present these as Record, Allow, and Block; the Rule Engine uses the corresponding technical actions shown in parentheses:
- Record (
log) — retain an observation and its operational metadata; - Allow (
accept) — permit an operation that satisfies the policy; - Block (
drop) — stop an operation that violates an approved inline policy; - generic state actions — record, delete, atomically transition, or increment bounded state.
Experimental response/replacement behavior is not part of the primary industrial offer described by this site. Traffic shaping is also not claimed: rate-oriented rules count industrial events and can log or drop at a threshold; they do not shape bandwidth like a QoS scheduler.
Evidence for operations and security¶
A decision can contain the rule name, frame number, endpoints, protocol layers, verdict, authenticated user and session identity when L2Proxy Connect is used, and customer-selected metadata such as device address, point, sequence, phase, or fingerprint. Stateful actions and timeouts have dedicated events, allowing an investigation to reconstruct why a decision occurred.
See Rule Decisions and Evidence for representative records.
The PostgreSQL event model keeps the high-detail dissection archive separate from indexed normalized events. This allows forensic drill-down without forcing operators to read repetitive packet trees. See Event Archive and Evidence.
From protocol logs to operational events¶
The Industrial Event Normalizer converts parsed DNP3 records into a stable event model
for control-room, OT security, reporting, and investigation workflows. It identifies
the operation, classifies its type, category, and severity, maps protocol addresses and
points to customer assets, and produces both a readable industrial description and
machine-queryable process_assets evidence.
This means a technical tuple such as “function 5, Group 12 Variation 1, point 0” can be presented as “SCADA Master sent DIRECT OPERATE: Close command to CB-101 on RTU-South,” while preserving the original group, variation, index, control code, quality, and mapping. See Industrial Event Normalization.
Industrial value¶
Reduce the gap between network policy and process intent¶
A port-based firewall may permit all DNP3 or Modbus traffic between two endpoints. L2Proxy can distinguish reads from controls, evaluate protocol objects and values, and apply different policies to different operations.
Make controls explainable¶
Rules are explicit, ordered, reviewable, and testable. Operations and cybersecurity teams can agree on the permitted sequence and retain evidence of each match.
Present events in the language of the plant¶
Customer-managed asset maps associate protocol addresses and points with names, roles, locations, equipment types, operational intent, units, and criticality. Operations can filter controls, maintenance, configuration, monitoring, responses, alarms, and unknown assets without reading packet-level protocol records.
Move from intent to a valid rule faster¶
The local Rule Authoring Workbench combines a searchable field and helper catalog, contextual autocomplete, operator and value suggestions, inline industrial guidance, lint feedback, engine compilation, and reusable rule templates. Engineers can explore what the parser actually exposes and validate an expression before placing it in a customer policy. See Guided Rule Authoring.
Begin with the equipment—not a blank policy¶
The Equipment and Protection Library organizes security around the plant assets that operations already understand. Breakers, transformers, relays, reclosers, regulators, busbars, capacitor banks, DER interties, and other equipment can carry their monitoring and control points, normal states, operating limits, alarm levels, permitted commands, and baseline protections. See Equipment and Protection Library.
Give each remote user only the required industrial authority¶
The Guided Policy Composer identifies the authenticated VPN user, destination equipment, permitted industrial operations, safety conditions, and enforcement outcome. Reviewed policies are assembled into a complete Policy Profile. L2Proxy Connect can enforce that policy directly within the user's authenticated session; a standalone L2Proxy instance can instead protect an isolated access path where required. See Industrial Policy Management.
Link the authenticated session to the industrial operation¶
L2Proxy Connect combines access identity with industrial protocol meaning. Operations and OT security can determine which authenticated user and live session attempted a read, control, configuration change, or other consequential operation; apply a policy specific to that authority; and retain the result as session-linked evidence. See Identity-Aware Industrial Access.
Operate protection as managed industrial services¶
When standalone enforcement is selected, each protected access path can run as an independent L2Proxy service with its own operating profile, approved Policy Profile, inspection mode, event records, service state, and lifecycle. One service can be commissioned or revised without reconfiguring unrelated protection services. See Standalone Deployment and Operations.
Introduce enforcement without beginning with disruption¶
The same policy logic can be exercised passively and against PCAPs before inline blocking is approved. This supports a measured OT change-management process.
Extend without hard-coding customer policy¶
Protocol helpers extract and canonicalize data. Customer-specific addresses, point mappings, timing, identities, state transitions, and final decisions remain in managed customer policy.
Product boundary¶
L2Proxy is focused on industrial protocol visibility and network policy. It is not a general web application firewall, endpoint antivirus product, TLS interception platform, PLC safety system, or replacement for process control interlocks. See Product Boundaries for the complete statement.