CH07-05: Security Operations, Evidence, and Cost Trade-Offs

Goal

Security services do not create much value simply by existing. A Key Vault needs access reviews and rotation planning. A WAF needs rule tuning. Defender for Cloud recommendations need owners. Sentinel incidents need responders. Logs need retention decisions. Policies need exception paths.

This section compares security service choices through the operating model around them.

The durable idea for this section is:

Security services create value only when teams operate the controls, alerts, logs, evidence, and response paths.

The Short Version

The easy security answer is:

Turn on the strongest security services everywhere.

The better architecture answer is:

Match the control depth to the workload risk, then define ownership, evidence, response, and cost.

Critical, regulated, internet-facing, and sensitive-data workloads usually need stronger controls than low-risk internal experiments. But stronger controls bring operational work. Someone must approve access, rotate secrets, tune alerts, review posture, respond to incidents, manage exceptions, control cost, and explain evidence.

Security selection is therefore not only a service decision. It is an operating decision.

The Security Operating Loop

Security controls should form a loop, not a one-time setup:

flowchart LR
    A["Control objective"]
    B["Service enabled"]
    C["Logs and alerts"]
    D["Owner investigates"]
    E["Response action"]
    F["Evidence retained"]
    G["Control improved"]

    A --> B --> C --> D --> E --> F --> G --> A

If the loop breaks, the control weakens. A service can be enabled but unowned. Logs can be collected but never reviewed. Alerts can fire but have no responder. Compliance evidence can exist but fail to show real response readiness.

What Teams Must Operate

Different security controls create different ongoing responsibilities:

Control Area	What Must Be Operated
Identity and RBAC	Group membership, role assignments, privileged access, access reviews, break-glass accounts, separation of duties.
Managed identities	Permission scope, lifecycle, ownership, assignment to workloads, review of over-permissioned identities.
Key Vault	Secret rotation, certificate renewal, key access, vault permissions, access logging, private access where needed.
WAF	Policy mode, rule exclusions, false positives, blocked request review, application release coordination.
Azure Firewall	Rule ownership, routing, change control, logging, troubleshooting, resilience, cost.
DDoS Protection	Protected resource scope, telemetry, alerting, incident response, public endpoint architecture.
Defender for Cloud	Recommendation ownership, remediation tracking, workload protection plans, exceptions, secure score interpretation.
Sentinel	Data connectors, analytics rules, incidents, playbooks, hunting, retention, ingestion cost, responder workflow.

This is why a "turn it all on" security strategy can backfire. It may create cost, noise, and confusion faster than it creates protection.

Evidence Is Not the Same as Readiness

Compliance evidence is important. A regulated workload may need proof of access control, policy enforcement, vulnerability management, logging, incident handling, encryption, and change history.

But evidence is not the same as readiness.

Evidence answers questions such as:

Which controls were configured?
Which alerts fired?
Which access assignments existed?
Which recommendations were remediated or accepted as exceptions?
Which incident records and response actions were retained?

Readiness answers different questions:

Who responds at 2:00 AM?
Which alerts are urgent?
How does the team contain a compromised identity?
How does the application team rotate a leaked secret?
How does the network team change firewall rules during an incident?
Who decides whether to disable an integration, block a source, or take a workload offline?

A mature design connects both. Evidence should come from real controls and real operations, not a manual scramble before an audit.

Cost and Noise Trade-Offs

Security tooling can create meaningful cost. Logs may be charged by ingestion volume and retention. Advanced protection plans may be priced by resource type, workload, or protected scope. Firewalls, gateways, WAF policies, DDoS options, private endpoints, and analytics tools can all affect the bill.

Cost is not a reason to avoid security. It is a reason to design security deliberately.

Use workload risk to guide depth:

Workload Type	Security Depth Direction
Temporary learning environment	Keep controls simple, prevent obvious exposure, limit privileges, control spend.
Internal low-risk tool	Use identity, scoped access, basic logging, and reasonable guardrails.
Production internal application	Add stronger monitoring, access review, secret management, backup and recovery controls, and incident ownership.
Internet-facing customer workload	Add edge protection, stronger detection, private dependencies, traffic logs, and response readiness.
Regulated or sensitive-data platform	Add layered controls, formal evidence, alert ownership, retention strategy, posture tracking, and tested response processes.

Alert noise is a cost too. If every low-value signal becomes an urgent incident, responders stop trusting the system. Good security design includes tuning, severity, escalation, and ownership.

Example: Regulated API Operating Model

A team enables Key Vault, WAF, Defender for Cloud, and Sentinel for a regulated customer API. The service choices are only half the design.

The operating model should answer:

Service	Operating Decision
Key Vault	Who can read secrets? Who can rotate them? How are access logs reviewed? What is the emergency rotation process?
WAF	Who owns rule tuning? What happens when a legitimate request is blocked? Which logs feed incident investigation?
Defender for Cloud	Which recommendations are mandatory? Who owns remediation? How are exceptions approved and reviewed?
Sentinel	Which logs are ingested? Which analytics rules create incidents? Who responds? Which playbooks can run automatically?
Azure RBAC	Who reviews production access? How are privileged roles granted and removed?

Without these answers, the platform may look secure in a diagram but behave poorly during an incident or audit.

Balancing Control and Delivery

Security controls can block delivery when they are too broad or poorly explained. Weak controls can leave risk unmanaged. The architecture job is to make the secure path usable.

Good control design includes:

Clear default rules.
Narrowly scoped exceptions.
Visible ownership.
Useful logs and alerts.
Review dates for temporary access.
Documentation that tells teams how to comply.
Automation for repeatable tasks.
Escalation paths for urgent cases.

This is the same idea Chapter 2 used for governance: guardrails should enable safe autonomy, not freeze delivery.

Common Mistakes

Turning on every security service without budget, ownership, or response paths.
Keeping every log forever without a retention strategy.
Creating alert noise that hides real incidents.
Treating compliance reports as a substitute for response readiness.
Blocking teams with controls that have no exception or review path.
Designing security only for auditors and forgetting daily operations.

If Someone Asks You

What trade-offs matter when choosing Azure security services?

A good answer is:

I look at risk, ownership, response, evidence, cost, and delivery impact. Stronger controls are often necessary for regulated, sensitive, or internet-facing workloads, but they create operational work. Teams must manage access, secrets, policies, logs, alerts, retention, incidents, and exceptions. A good design defines who owns each control and how evidence and response will work before production.

What You Should Remember

Security tooling is only as strong as the operating model around it.

Questions to Check Your Understanding

Why can security services increase cost and operational load?
What is the difference between evidence and actual response readiness?
Why should alert ownership be defined before production?