Perspective: The Future of Security Is Context, Not More Alerts

Adding alerts does not make an organization safer. Adding context to the alerts it already has does. The next gain in detection and response comes from joining what the security team sees to what the business knows.

Alerts describe events. Decisions need meaning.

A detection tells you something happened. It rarely tells you whether it matters.

Take a hypothetical case. Two hosts trigger the same rule for an encoded PowerShell command. One is a build server holding the credentials a deployment pipeline uses to push to production. The other is a reception kiosk. The rule, the severity and the position in the queue are identical. The consequences are not. An analyst who has only the alert must work out which host is which by hand, ticket by ticket, while the queue grows.

This is the pattern behind most complaints about alert fatigue. The volume is real. The deeper problem is that every alert arrives without the information needed to rank it. Tuning helps. More sensors, with no way to rank what they produce, add to the pile.

What context means in practice

Context is not a dashboard or a product category. It is the set of facts that change what you do next. Five layers matter most.

None of this is new. NIST’s zero trust architecture (SP 800-207) already assumes that access decisions draw on several inputs. Device state from continuous diagnostics, threat intelligence, activity logs, data access policy, identity management and SIEM data all feed the policy engine. NIST’s Cybersecurity Framework 2.0 makes a similar point for detection: events should be correlated across sources and assessed for impact and scope, not only recorded. Doing that by hand does not scale.

What this changes in the architecture

1. Treat context as shared infrastructure. Enrichment built separately into each tool gives each tool a different answer about the same asset. Asset, identity and exposure data need owners, agreed definitions and one place where the SOC, identity, vulnerability and cloud teams read the same facts.

2. Choose the decisions first. Context costs effort to maintain. Spend it on the decisions that matter most: alert priority, who may authorize containment, access policy and remediation order. A context layer built for its own sake becomes a project without a customer.

3. Put context where the decision is made. An enriched record in a data lake does not help the analyst at 2 a.m. The facts have to be on the alert, in the access policy and in the change ticket.

4. Set freshness rules. Stale context misleads. A decommissioned server still marked critical wastes attention. A new payment service missing from the inventory gets none. Decide how old each fact can be before it stops being trusted.

5. Use context to raise priority as well as lower it. The common use is to suppress alerts on unimportant assets. Attackers often start on those assets and move to critical ones. A low-value host holding a credential that reaches a high-value system is not low priority.

6. Keep a person on irreversible actions. Automated containment built on bad context takes down production. Automate where the context is reliable and the action can be reversed.

Where the argument fails

Three limits apply. Context can be wrong, and confident but wrong context is worse than none. It can turn into one more long program: a graph nobody maintains is an expensive drawing. And vendors use the word loosely. A useful test is whether the context changes a decision inside the incident timeline. If it only improves the report written afterwards, it is documentation.

Context also does not fix coverage. It ranks what you see. It does not reveal what you cannot see, and telemetry gaps stay gaps.

A practical starting point

Pick one decision and one family of detections. Identity-related alerts are a sensible first choice because identity context is concrete and the response paths are well understood. Define the minimum facts the decision needs: asset owner, criticality, account type, internet exposure and privileged reach. Get those facts onto the alert. Then check whether analysts decide faster and more consistently. Time to decision and agreement between analysts on priority are simple measures. Widen the scope only after this works.

Next step

Architecture reviews that begin with a tool inventory tend to end with a tool recommendation. Begin instead with the five decisions your security team makes most often, and list what each one lacks. That list is your architecture backlog. It will change as the business and the threat picture change, which is the point of treating architecture as something that evolves.

Sources

1. NIST, Special Publication 800-207, Zero Trust Architecture.

2. NIST, The NIST Cybersecurity Framework (CSF) 2.0, Cybersecurity White Paper 29.

3. MITRE, ATT&CK knowledge base of adversary tactics and techniques.