Capability Status¶
This page prevents a common product-evaluation mistake: treating protocol decoding, rule access, semantic correlation, and production enforcement as the same capability.
Status definitions¶
- Production Implemented, exercised by automated tests, and represented by customer-ready examples.
- Supported Implemented and testable; deployment scope must be confirmed for the customer's traffic profile.
- Preview Available for evaluation, but not represented as a complete production policy package.
- Planned Identified use case or design direction; not part of the current offer.
Product capability matrix¶
| Area | Capability | Status | Evidence / qualification |
|---|---|---|---|
| Rule Engine | Ordered YAML conditions and log / accept / drop |
Production | Typed compile at load; automated engine tests |
| Rule Engine | Dynamic JSON metadata on rule matches | Production | Expressions compile once and evaluate only on logged matches |
| Rule authoring | Contextual field autocomplete and parser-derived catalog | Supported | Current catalog contains 1,602 fields across 28 protocol layers; qualify against the shipped parser version |
| Rule authoring | Inline semantic-helper help and metadata accessor guidance | Supported | Deep DNP3 helper catalog; other protocols retain generic field access and curated templates at their current maturity |
| Rule authoring | Catalog lint plus Rule Engine expression compilation | Supported | Local workbench validates expressions without sending policy content to an external service |
| Rule authoring | Curated industrial rule library and learning paths | Supported | 288 current templates across DNP3, IEC 60870-5-104, Modbus, and S7comm |
| Equipment library | Reusable base equipment definitions and point catalogs | Production | Complete create, review, search, update, delete, bulk-management, and export workflow |
| Equipment library | Baseline safety profiles for every catalog point | Production | Current catalog contains 13 equipment definitions, 36 operational points, and 36 safety profiles |
| Protection library | Equipment-linked baseline protection rules | Production | Operational protections cover binary state, analog range, permitted control codes, setpoint range, alarms, SBO, and prerequisites |
| Protection library | Protection-rule lifecycle management | Production | Create, review, filter, update, delete, bulk-management, export, and readiness visibility |
| Policy management | Guided industrial Access Policy composition | Production | User, source, destination equipment, industrial operation, order, decision, and event behavior are managed as complete policies |
| Policy management | Policy Profile composition and file management | Production | Multiple policies are assembled, ordered, revised, and saved as the final L2Proxy rules file |
| Policy deployment | Per-VPN-user isolated L2Proxy enforcement | Production | A dedicated access path, Service Profile, Policy Profile, and independent L2Proxy instance are assigned per user |
| Service management | Multiple independent L2Proxy profiles and instances | Production | Policy Profile selection plus independent service start, stop, restart, and status management |
| L2Proxy Connect | In-session industrial inspection with Record / Allow / Block | Production | Traffic is evaluated in the internal session forwarding path before onward delivery; integration and engine tests cover the primary decision path |
| L2Proxy Connect | Authenticated user, session, access-domain, and connection-kind context | Production | Context is available to policy helpers and retained with dissection and rule-decision evidence |
| L2Proxy Connect | User- and session-aware industrial policy | Production | Policy can combine authenticated identity with endpoints, decoded industrial operations, equipment context, and stateful conditions |
| L2Proxy Connect | Session-linked file and PostgreSQL evidence | Production | Dissection and rule-match records preserve the available access-session context for investigation |
| Rule Engine | Atomic state transition and replay-resistant consumption | Production | Concurrent compare-and-set tests |
| Rule Engine | Bounded state and atomic counters | Production | Capacity, size, TTL, concurrency, and race tests |
| Rule Engine | Packet-independent timeout event scheduler | Supported | Optional; disabled by default; requires lifecycle Close() |
| DNP3 | Protocol helpers and object/point inspection | Production | Flat helper catalog and parser-backed fixtures |
| DNP3 | Multi-object control fingerprinting | Production | CROB and G41 canonicalization; malformed input fails closed |
| DNP3 | Industrial multi-state policy catalog | Production | Tested YAML examples listed below |
| Normalization | DNP3 industrial-language event generation | Supported | Implemented normalizer; qualify descriptions and vendor traffic with customer PCAPs |
| Normalization | Event type, category, severity, operation, criticality, and alarm classification | Supported | Stable query fields for current DNP3 function and IIN handling |
| Normalization | YAML device/point mapping and structured process_assets |
Supported | Preserves raw point data beside mapped asset context |
| Normalization | Unknown device and point discovery | Supported | Discovery flags plus PostgreSQL asset and point reports |
| Normalization | Tail, batch, dry-run, PostgreSQL storage, and reporting views | Supported | Standalone CLI and idempotent schema provided |
| Normalization | Modbus, S7comm, IEC 104, and other protocol normalizers | Planned | Extension interface exists; current executable activates DNP3 only |
| Event archive | Raw dissection and rule_match JSONB retention |
Supported | The raw event archive stores both event families with ingestion time and ID |
| Event archive | Indexed normalized industrial-event database | Supported | Live industrial_events table and four operational views |
| Event archive | Browser Event Explorer for dissections and rule decisions | Supported | Live Event2 provides server-side event-family filters, optional polling, paging, counts, verdict display, and frame drill-down |
| Event archive | Customer-defined retention, partitioning, compaction, and backup policy | Planned / deployment-specific | Current schema is not partitioned and does not impose automatic retention |
| Modbus | Field and transaction-aware rules | Supported | Existing read-before-write/readback example; no further expansion currently active |
| S7comm | Protocol dissection and field-level policy | Preview | Stateful helper package is intentionally not offered yet |
| S7comm-plus | Protocol inspection | Preview | Does not imply production stateful enforcement |
| Other industrial protocols | Parser-dependent visibility | Preview | Must be qualified per protocol and traffic profile |
| Persistent/distributed state | State recovery across engine restart | Planned | Deliberately excluded until a proven customer requirement exists |
| Atomic multi-key transition | Cross-asset all-or-nothing state update | Planned | Design gate documented; not in runtime |
DNP3 stateful policy evidence¶
Current tested examples include:
- Select-Before-Operate for fixed and multi-object controls;
- command-to-status verification;
- device restart and recovery sequencing;
- maintenance-authorized control;
- active/standby master enforcement;
- session identity binding;
- safety trip/acknowledge/clear/reset;
- unauthorized feedback change monitoring;
- valve/pump process interlock;
- file-transfer lifecycle;
- configuration change followed by restart and health verification;
- rate/burst detection;
- alarm lifecycle and chattering detection.
See DNP3 State Machines for business and operational descriptions.
Customer qualification remains mandatory
A green product status does not automatically validate every vendor implementation, network topology, object variation, retransmission pattern, or process policy. Production deployment requires representative traffic and customer-approved tests.