Designing for compromise: security architecture for mission-critical systems

Imagine two mission-critical systems exchanging sensitive data, when either system, or the network between them, could be compromised. We’ll build the integration architecture step by step, introducing trust boundaries, identities, access control, data minimisation, encryption, and other security controls that limit blast radius. We’ll show how layered architectural decisions can keep systems secure and resilient even when individual controls fail.

Transcript

2. Anastasiia Voitova Head of Security Engineering @ Cossack Labs Cossack Labs is a security solutions company for mission critical applications, founded in 2014 in UK. Building & breaking secure software in power grids, nance, ML/AI, ICS/SCADA, IIoT, robotic & autonomous systems, communication systems — where data & application security is a hard requirement. Since 2022 — helping Ukrainian defenders be more resilient against russian aggression in multiple domains. fi cossacklabs.com
3. Incident story One compromised laptop became the rst step in a chain of trusted access. Dev laptop GitHub identity Source code Secrets Other systems phishing / malware / local compromise SSH private key / agent / token repositories, CI con g .env, con g, service creds APIs, clouds, databases, partners Anastasiia Voitova fi fi fi fa0c22f6eb619e6368f168b617
4. Incident story One compromised laptop became the rst step in a chain of trusted access. Dev laptop GitHub identity Source code Secrets Other systems phishing / malware / local compromise SSH private key / agent / token repositories, CI con g .env, con g, service creds APIs, clouds, databases, partners The real problem was transitive trust: one credential led to another credential, which led to another system. Anastasiia Voitova fi fi fi fa0c22f6eb619e6368f168b617
5. So what now? We cannot guarantee that the laptop, network, service, or credential will never be compromised.
6. Design for cascading failure 1. Threat modelling (what are the threats scenarios) 2. Data ow analysis (what could go wrong at each component) 3. Attackers (who will attack us and why, including insiders and mistakes) 4. Which security controls we need to protect the system and each component. 5. How we will detect failure? (monitoring and detection) 6. How we will recover? fl fa0c22f6eb619e6368f168b617 Anastasiia Voitova
7. Case story System B reads some data from System A and sends back processing results. No user is involved. SYSTEM A mission-critical API contains sensitive data GET /objects/{id} POST /results service-to-service SYSTEM B partner / adjacent system needs limited access web systems, not classi ed, talk over the internet, client-server. Anastasiia Voitova fi fa0c22f6eb619e6368f168b617
8. Layer 1: reduce network exposure VPN + IP allowlist / rewall rules. The API is reachable only from the expected network segment. SYSTEM A integration system Private network VPN SYSTEM B integration system IP allowlist / ACL Anastasiia Voitova fi fa0c22f6eb619e6368f168b617
9. Layer 1: reduce network exposure VPN + IP allowlist / rewall rules. The API is reachable only from the expected network segment. SYSTEM A integration system Private network VPN SYSTEM B integration system IP allowlist / ACL VPN or IP allowlist is not authentication Anastasiia Voitova fi fa0c22f6eb619e6368f168b617
10. Layer 2: accept speci c service identities mTLS gives both sides a cryptographic identity and protects the channel. mTLS SYSTEM A server certi cate, private key, validates client identity system identity SYSTEM B client certi cate, private key, validates server identity transport security Validate the certi cate chain, expiration, and expected service identity (e.g. SAN). Store private keys securely. Don’t forget about rotation, revocation, generation / distribution. Anastasiia Voitova fi fi fi fi fa0c22f6eb619e6368f168b617
11. Layer 2: accept speci c service identities mTLS gives both sides a cryptographic identity and protects the channel. mTLS SYSTEM A server certi cate, private key, validates client identity system identity SYSTEM B client certi cate, private key, validates server identity transport security mTLS is not authorisation Anastasiia Voitova fi fi fi fa0c22f6eb619e6368f168b617
12. Layer 3: s2s authorisation using JWT scopes mTLS answers “who are you”, JWT answers “what are you allowed to do”. JWT SYSTEM A JWT token scope, aud, exp SYSTEM B server certi cate, private key, validation logic TOKEN SERVICE Issues short-lived JWT for a speci c service and scope. system B authenticates to the token service and receives JWT for System A token should be short-lived token should have scopes and audience for speci c API actions Anastasiia Voitova fi fi fi fa0c22f6eb619e6368f168b617
13. JWT: constrains who, what, where iss - only trusted issuer sub - who the token represents { "iss": "token-service", "sub": "system-b", "aud": "system-a-data-api", "scope": "objects:read results:write", "exp": 1790896800, "jti": "f4d2..." } aud - where it’s used (only System A data API) scope - what it can do (only read objects + write results) exp - short lifetime limits reuse jti - unique token identi er signature - should be valid type - to avoid token confusion attacks revocation is a problem! JSON Web Token Cheat Sheet cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_Cheat_Sheet.html Anastasiia Voitova fi fa0c22f6eb619e6368f168b617
14. Scope should map to a speci c operation Request Required scope B token Result GET /objects/{id} objects:read objects:read ALLOW POST /results results:write results:write ALLOW DELETE /objects/{id} objects:delete — DENY GET /admin/users admin:read — DENY Even with valid JWT, system A should check if system B has rights to access speci c objects. Anastasiia Voitova fi fi fa0c22f6eb619e6368f168b617
15. Layer 4: authorise the object, not the operation DECISION GET /objects/8472 ALLOW only if every check passes GET /objects/1111 DENY even if the object exists treat object IDs as untrusted references. enforce server-side object-level authorisation: check the ownership check data classi cation check object state A valid object ID does not mean an authorised object. fi fa0c22f6eb619e6368f168b617 Anastasiia Voitova
16. What System A checks on every request Trust is not inherited from the previous layer. 1 Network path VPN / source IP is allowed 2 mTLS client certi cate represents System B 3 JWT integrity signature + trusted issuer 4 JWT constraints audience + expiry + not-before 5 Scope operation is explicitly permitted 6 Object policy this object / tenant / data class is allowed fi fa0c22f6eb619e6368f168b617 Anastasiia Voitova
17. Imagine system B is compromised The goal is not to make compromise impossible. The goal is to keep it local, visible, and manageable. SYSTEM A protected data + API fa0c22f6eb619e6368f168b617 valid requests SYSTEM B compromised Anastasiia Voitova
18. Imagine system B is compromised DETECT SIEM audit logging Each layer addresses a different part of the risk. None of them is a magic security control. SYSTEM A valid requests anomaly detection compromised protected data + API CONTAIN short-lived jwt JWT revocation VPN / mTLS revocation kill switch fa0c22f6eb619e6368f168b617 SYSTEM B LIMIT data minimisation per-integration credentials per user encryption network segmentation object-level authZ bulk export limits per operation scopes rate limits Anastasiia Voitova
19. Security patterns
20. Future-proof, adaptive, reusable architectural patterns Zero Trust Network Access – ZT assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location. ZTNA gives users access to speci c network / service. “Never trust, always verify”. NIST SP 800-207. Defence in Depth – creating overlapped and interconnected security defences for the most critical assets. Data centric security – protect the data no matter where it is, not the environment. Based on encryption. Anastasiia Voitova fi fa0c22f6eb619e6368f168b617
21. defence from current threats fa0c22f6eb619e6368f168b617 Anastasiia Voitova
22. defence from current threats fa0c22f6eb619e6368f168b617 future-proof designs Anastasiia Voitova
23. 7 questions before connecting two systems 1 Who is allowed to establish the connection? 2 What cryptographic identity proves it? 3 Which speci c API is this identity, credential or token intended for? 4 Which operations does it actually need? 5 Which speci c data is it allowed to access? 6 What happens if this side is fully compromised? 7 How quickly can we detect it and cut off access? fi fi fa0c22f6eb619e6368f168b617 Anastasiia Voitova
24. How to design for failure Threat modelling: STRIDE, CIAA OWASP Microservices Security Cheat Sheet Security architecture and design: microservice security, building secure and reliable systems, OWASP cheatsheets. OWASP REST Security Cheat Sheet NIST RMF, NIST CSF. OWASP Authorization Cheat Sheet NIST SP 800-53. Building Secure and Reliable Systems OWASP ASVS. cheatsheetseries.owasp.org/cheatsheets/Microservices_Security_Cheat_Sheet.html cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html OWASP OAuth2 Cheat Sheet cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html google.github.io/building-secure-and-reliable-systems/ Chapter 8: Design for Resilience google.github.io/building-secure-and-reliable-systems/raw/ch08.html fa0c22f6eb619e6368f168b617 Anastasiia Voitova
25. Becoming security architect 101 1. Assume individual controls will fail. Design the next boundary before they do. 2. Limit trust, capabilities, and blast radius. Identity does not imply unlimited access. 3. Design for detection and recovery, not only prevention. Security is a continuously maintained property. 4. There is no single “secure architecture”. There is an architecture resilient to a de ned threat model. fi fa0c22f6eb619e6368f168b617 Anastasiia Voitova
26. Anastasiia Voitova Head of Security Engineering @ Cossack Labs anastasi@cossacklabs.com linkedin.com/in/anastasiiavoitova/ cossacklabs.com jobs.dou.ua/companies/ cossack-labs/vacancies/ speakerdeck.com/vixentael fa0c22f6eb619e6368f168b617