From 9ca32dddfbc96bfde5eb37bdbddc8989253b8c4c Mon Sep 17 00:00:00 2001 From: znetsixe Date: Mon, 23 Mar 2026 11:35:40 +0100 Subject: [PATCH] Extend architecture review with security positioning --- architecture/stack-architecture-review.md | 82 +++++++++++++++++++++-- 1 file changed, 76 insertions(+), 6 deletions(-) diff --git a/architecture/stack-architecture-review.md b/architecture/stack-architecture-review.md index 61de927..d708782 100644 --- a/architecture/stack-architecture-review.md +++ b/architecture/stack-architecture-review.md @@ -364,7 +364,77 @@ Questions still open: - telemetry transport or only synchronization/eventing? - durability expectations and replay behavior? -## 7. Recommended Ideal Stack +## 7. Security And Regulatory Positioning + +### 7.1 Purdue-style layering is a good fit + +EVOLV's preferred structure aligns well with a Purdue-style OT/IT layering approach: + +- PLCs and field assets stay at the operational edge +- edge runtimes stay close to the process +- site systems mediate between OT and broader enterprise concerns +- central services host APIs, identity, analytics, and engineering workflows + +That is important because it supports segmented trust boundaries instead of direct enterprise-to-field reach-through. + +### 7.2 NIS2 alignment + +Directive (EU) 2022/2555 (NIS2) requires cybersecurity risk-management measures, incident handling, and stronger governance for covered entities. + +This architecture supports that by: + +- limiting direct exposure of field systems +- separating operational layers +- enabling central policy and oversight +- preserving local operation during upstream failure + +### 7.3 CER alignment + +Directive (EU) 2022/2557 (Critical Entities Resilience Directive) focuses on resilience of essential services. + +The edge-plus-site approach supports that direction because: + +- local/site layers can continue during central disruption +- essential service continuity does not depend on one central runtime +- degraded-mode behavior can be explicitly designed per layer + +### 7.4 Cyber Resilience Act alignment + +Regulation (EU) 2024/2847 (Cyber Resilience Act) creates cybersecurity requirements for products with digital elements. + +For EVOLV, that means the platform should keep strengthening: + +- secure configuration handling +- vulnerability and update management +- release traceability +- lifecycle ownership of components and dependencies + +### 7.5 GDPR alignment where personal data is present + +Regulation (EU) 2016/679 (GDPR) applies whenever EVOLV processes personal data. + +The architecture helps by: + +- centralizing ingress +- reducing unnecessary propagation of data to field layers +- making access, retention, and audit boundaries easier to define + +### 7.6 What can and cannot be claimed + +The defensible claim is that EVOLV can be deployed in a way that supports compliance with strict European cybersecurity and resilience expectations. + +The non-defensible claim is that EVOLV is automatically compliant purely because of the architecture diagram. + +Actual compliance still depends on implementation and operations, including: + +- access control +- patch and vulnerability management +- incident response +- logging and audit evidence +- retention policy +- data classification + +## 8. Recommended Ideal Stack The ideal EVOLV stack should be layered around operational boundaries, not around tools. @@ -446,7 +516,7 @@ These should be explicit architecture elements: - versioned configuration and schema management - rollout/rollback strategy -## 8. Recommended Opinionated Choices +## 9. Recommended Opinionated Choices ### 8.1 Keep Node-RED as the orchestration layer, not the whole platform @@ -501,7 +571,7 @@ The architecture should be designed so that `tagcodering` can mature into: - site/central configuration exchange point - API-served configuration source for runtime layers -## 9. Suggested Phasing +## 10. Suggested Phasing ### Phase 1: Stabilize contracts @@ -533,13 +603,13 @@ The architecture should be designed so that `tagcodering` can mature into: - advisory services from central - auditability of downward recommendations and configuration changes -## 10. Immediate Open Questions Before Wiki Finalization +## 11. Immediate Open Questions Before Wiki Finalization 1. Which signals are allowed to use reconstruction-aware smart storage, and which must remain raw or near-raw for audit/compliance reasons? 2. How should `tagcodering` be exposed to runtime layers: direct database access, a dedicated API, or both? 3. What exact responsibility split should EVOLV use between API synchronization and broker-based eventing? -## 11. Recommended Wiki Structure +## 12. Recommended Wiki Structure The wiki should not be one long page. It should be split into: @@ -549,6 +619,6 @@ The wiki should not be one long page. It should be split into: 4. security and access-boundary model 5. configuration architecture centered on `tagcodering` -## 12. Next Step +## 13. Next Step Use this document as the architecture baseline. The companion markdown page in `architecture/` can then be shaped into a wiki-ready visual overview page with Mermaid diagrams and shorter human-readable sections.