Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Firewalls remain one of the most foundational controls in any security program. Nearly every organization has at least one, and in many cases, hundreds. Despite widespread deployment, firewalls are frequently a source of unintended exposure rather than protection. The reason is almost always in how firewall rules are maintained over time, not the technology itself.

Firewall configuration is the set of rules, policies, and settings that define how a firewall behaves. Without configuration, a firewall is hardware and software waiting for instructions. With configuration, it becomes a control that determines what traffic is permitted, what is blocked, and what gets inspected before a decision is made. Get the configuration right, and the firewall does its job. Let it drift, and you have the appearance of protection without the substance of it. This is not an edge case.

Every security leader can describe their network security architecture in confident detail: how traffic should flow, where segmentation boundaries sit, which access should never be permitted. What almost none can tell me with certainty is whether their live controls are actually enforcing that design right now, at this very hour. That gap between what we intend and what is actually running in production is where modern breaches live, and it widens with every change we make.

Every security leader has a version of the network in their head. They know which systems should be segmented, which applications should be reachable, which ports should never be open, and which access paths should not exist. They know how the architecture is supposed to work. The harder question is whether the live environment is actually enforcing that design right now. That question is getting more difficult to answer.

Security teams spend enormous energy responding to threats, but many of the most damaging incidents trace back to a surprisingly simple failure: the organization didn't have an accurate picture of what it owned, what was exposed, and what its tools were actually doing about it. That gap between assumed coverage and actual coverage is where attackers operate, and adding more tools doesn't fix the underlying visibility problem.

Vulnerability scanning gives security teams a starting point, but it has never been the whole picture. Scan results capture known CVEs across applications and systems, yet they say nothing about whether a given weakness is actually reachable, whether the controls around it are functioning correctly, or whether the people with access to it represent a meaningful risk. Exposure management addresses all of that.

The Microsoft Defender Security Research Team and Microsoft Threat Intelligence documented a campaign in which Storm-2949 abused Microsoft Entra ID accounts to exfiltrate data from Microsoft 365 and Azure environments. The attack shows how cloud intrusions increasingly unfold through identity systems, administrative features, and legitimate platform capabilities rather than obvious malware or traditional endpoint compromise.

On April 22, 2026, Google's Threat Intelligence Group and Mandiant disclosed a campaign by a threat actor they're tracking as UNC6692. The group breached enterprise networks by impersonating IT helpdesk staff over Microsoft Teams, ultimately exfiltrating Active Directory databases and achieving full domain compromise. What's notable about UNC6692 is what they didn't do. They didn't use a zero-day. They didn't exploit a software vulnerability.