How Continuous Security Monitoring Exposes Blind Spots

There is a framework for thinking about what you know and don't know about the security state of your environment that I find consistently useful. It comes from intelligence practice: known knowns, known unknowns, and unknown unknowns.

• Known knowns are the threats your detection architecture was built to find. When these appear, your tools surface them. Your team knows how to respond.
• Known unknowns are the gaps you are aware of - techniques in your threat model that you haven't built detection for yet, data sources you know you're not collecting, attack surfaces you know you're not monitoring. These can be addressed systematically with coverage gap work.
• Unknown unknowns are the threats you don't know you're not seeing. Novel techniques not yet in your threat model. Attack paths through your specific environment that your architecture didn't anticipate. Adversary activity generating no signal because it doesn't match any pattern your detection logic looks for.

Alert-based security operations handle known knowns well. Coverage gap work addresses known unknowns. Unknown unknowns are the hard problem - and they are the category where many significant intrusions originate. The adversary who finds an unknown unknown in your environment has found a path where no defender is watching.

Mapping Threat Visibility Across the Enterprise

Building Real Situational Awareness

Situational awareness is the operational capability that addresses unknown unknowns. It means developing and continuously maintaining an analytically grounded understanding of your environment - what is in it, what is normal, what is changing - that creates the context needed to recognize anomalies that don't match any known threat pattern.

Situational awareness does not come from alert queues. It comes from exploratory analytics on the full telemetry set, guided by current threat model knowledge and genuine investigative curiosity.

It means regularly asking open-ended questions of the data:

• What changed in this environment in the past 24 hours?
• Which entities are behaving differently from their peer groups without an operational explanation?
• Which new services or assets appeared that weren't present before?
• Which internal communication patterns have no historical precedent?

The Speed Requirement for Hypothesis Testing

These questions require two things that most security programs don't have together: an analytical infrastructure fast enough to support exploratory query without scheduling overnight jobs, and analyst time protected from alert queue pressure to actually run the exploration.

At Netenrich, the sub-second retroactive search on BigQuery across years of UDM-normalized telemetry was built specifically to make situational awareness operationally practical. When a hypothesis can be tested in seconds, analysts test hypotheses. When a query takes hours, hypotheses wait for a slow day.

The discipline of protecting analyst time for exploratory work is a leadership decision. The most important findings from our customers' situational awareness work - the active intrusions found weeks before detection would have fired, the exposures that created serious risk before any adversary had exploited them - came from analysts with the time and the tools to look.

*Part of my ongoing series on data science and the future of security operations.*

 
About the Author