The post-mortem pattern
Read enough breach post-mortems and a pattern appears. The organisation had the control. It had bought it, deployed it, sometimes even audited it. The attacker simply went through a different layer, one where the equivalent decision had never been made, or had been made once and never revisited.
Security is not a firewall. It is seven stacked decisions, one per layer of the network model, each with its own attack surface, its own control set and its own audit fingerprint. Miss one and the others do not compensate; they just make the miss harder to see.
The seven layers, and what each one owes you
Attack surface, control set and audit fingerprint at every layer of the OSI model. The framework references use ISO 27001:2013 Annex A numbering.
| Layer | Typical attacks | Controls | Maps to |
|---|---|---|---|
| L7 Application | SQL injection, XSS, CSRF, API abuse | WAF, secure coding, input validation | ISO A.14 · PCI Req 6 · NIST SI-10, SA-11 |
| L6 Presentation | SSL stripping, encryption downgrade | TLS 1.2 or later, certificate lifecycle management | ISO A.10 · PCI Req 4 · NIST SC-12, SC-13 |
| L5 Session | Session hijacking, replay | Session timeouts, token management, MFA | ISO A.9 · PCI Req 8 · NIST IA-2 |
| L4 Transport | SYN flood, port scanning | Firewall rules, IDS and IPS | ISO A.13 · NIST SC-7 |
| L3 Network | IP spoofing, routing attacks | Segmentation, access control lists | ISO A.13 · NIST SC-7 |
| L2 Data link | ARP spoofing, MAC flooding | Port security, DHCP snooping | ISO A.13 · NIST AC-4 |
| L1 Physical | Cable tapping, hardware tampering | Physical access control, tamper-evident hardware | ISO A.11 · NIST PE family |
- Your WAF does not help if someone walks into the data centre with a USB stick
- Your MFA does not help if session tokens never expire
- Your TLS does not help if the certificate chain is not managed
- Who owns the controls at that layer?
- When were they last tested end to end, not just scanned?
- If that layer failed tomorrow, which business process stops?
Layer by layer
ApplicationSQL injection, cross-site scripting, CSRF and API abuse, met by a web application firewall, secure coding and input validation. ISO A.14, PCI DSS requirement 6, NIST SI-10 and SA-11.
PresentationSSL stripping and encryption downgrade, met by TLS 1.2 or later and certificate lifecycle management. ISO A.10, PCI requirement 4, NIST SC-12 and SC-13.
SessionSession hijacking and replay, met by session timeouts, token management and MFA. ISO A.9, PCI requirement 8, NIST IA-2.
TransportSYN floods and port scanning, met by firewall rules and intrusion detection and prevention. ISO A.13, NIST SC-7.
NetworkIP spoofing and routing attacks, met by segmentation and access control lists. ISO A.13, NIST SC-7.
Data linkARP spoofing and MAC flooding, met by port security and DHCP snooping. ISO A.13, NIST AC-4.
PhysicalCable tapping and hardware tampering, met by physical access control and tamper-evident hardware. ISO A.11, the NIST PE family.
The ISO references use the 2013 Annex A numbering that most Indian certifications still cite in their statements of applicability. The 2022 edition regroups the same controls into four themes; the intent at each layer is unchanged.
The uncomfortable truth
- Your WAF does not help if someone walks into the data centre with a USB stick.
- Your MFA does not help if session tokens never expire.
- Your TLS does not help if the certificate chain is not managed.
Defence in depth is not a slogan. It is seven audits.
A gut-check
Pick one layer. Just one. Now answer three questions. Who owns the controls at that layer? When were they last tested end to end, not just scanned? If that layer failed tomorrow, which business process stops?
If you paused on any of the three, that is your weakest layer. Not the one with the fewest tools. The one with the least clarity.
Where to begin
Run the gut-check for all seven layers with the people who actually operate them, in one room, in one afternoon. Write down the owner, the last end-to-end test and the dependent business process for each. The blanks on that page are the programme. Then fund the layer with the least clarity first, not the layer with the most vendors.
So, which layer is your programme under-investing in?
Krishna works at the intersection of cyber security, infrastructure, AI and enterprise risk, with a focus on engineering trustworthy and resilient technology foundations.
Follow on LinkedInThis perspective expands a post first published by the author on LinkedIn.
