Implementing Operational & Network Security

Foundation covered change management (8.32), logging/monitoring (8.15/8.16), network segregation (8.22), and backup (8.13) as concepts to recognize. This lesson is about building the actual processes and pipelines behind them.

Change management: gates, not paperwork for its own sake

A working change management process needs enough structure to prevent unreviewed changes from reaching production, without becoming so heavy that people route around it. A reasonable minimum:

Request  → What's changing, and why (tied to a ticket/ID)
Assess   → Risk/impact assessment — could this affect security controls?
Approve  → A different person than the requester signs off
           (segregation of duties, Foundation Annex A 5.3)
Test     → Verified in a non-production environment first
Deploy   → With a documented rollback plan ready before deployment
Review   → Confirm the change achieved its intent, log any issues

The most common Implementer-level failure isn't skipping the process for major changes — it's an informal exception path for "small" or "urgent" changes that quietly becomes how most changes actually happen, undermining the process for exactly the changes most likely to introduce risk (rushed, under-reviewed emergency fixes).

Logging without monitoring is half a control

Foundation's lesson 10 already distinguished 8.15 (logging) from 8.16 (monitoring). Implementing 8.16 properly means alert tuning, not just switching on every possible alert:

• Too few alerts (or none) means real incidents go unnoticed — the classic logging-without-monitoring gap.
• Too many alerts, especially low-value ones, causes alert fatigue — the team starts ignoring or auto-dismissing alerts, which is functionally almost as bad as having no monitoring at all, since a genuine critical alert gets lost in the noise.

A practical approach: start with a small number of high-confidence, high-value alerts (failed privileged logins, unexpected outbound connections from sensitive systems, configuration changes to security controls), and expand deliberately — reviewing false-positive rates regularly, rather than enabling every possible signal on day one.

Network segmentation: separating trust zones

Segmentation means grouping systems by trust level and restricting traffic between groups to only what's actually needed — not flattening everything onto one network where a compromised low-sensitivity system (e.g., a guest Wi-Fi device) has a direct path to a high-sensitivity one (e.g., a production database).

A common minimum segmentation model:

The point isn't the specific zone names — it's that a breach of the least-sensitive zone shouldn't grant a direct path to the most sensitive one. This is the network-level expression of the same principle behind environment separation (Foundation, 8.31) and least privilege (this roadmap, lesson 4).

Backup implementation: the 3-2-1 rule and tested restores

A widely used backup design principle is the 3-2-1 rule: keep 3 copies of data, on 2 different types of storage media, with 1 copy off-site (echoing Foundation's lesson 9/7.10 discussion of single-point-of-failure risk). But the single most commonly skipped implementation step is testing the restore, not just confirming the backup job completed. A backup that has never been restored is an untested assumption, not a verified control — the only way to know a backup actually works is to have successfully restored from it at least once, on a defined schedule (e.g., a quarterly restore drill), and documented the result.