BlueTeamCon 2026: Better Security Comes From Better Paths

In 1900, Chicago engineers reversed the flow of the Chicago River.

The city’s drinking water came from Lake Michigan, while the river carried sewage toward the same lake. Chicago eventually addressed the problem by changing the direction of the system itself. The Metropolitan Water Reclamation District built the Chicago Sanitary and Ship Canal, sending the river away from Lake Michigan and toward the Mississippi River system. The Metropolitan Water Reclamation District has the full history.

More than a century later, that is still a useful model for solving hard problems. Sometimes the system needs a better path.

That idea showed up repeatedly at BlueTeamCon 2026, held September 10 through 13 in Chicago. Across talks about vulnerability management, AI agents, identity, incident response, malware, AppSec, containers, and security operations, speakers kept returning to the same basic principles. Reduce unnecessary exposure. Make secure behavior easier. Put clear boundaries around powerful systems. Practice before the crisis. Give people enough context to make good decisions.

AI is making many security problems move faster. The underlying work remains very familiar.

Security Still Depends on People Knowing How to Work Together

Keynote speaker Ian Coldwater opened the conference with “We Keep Us Safe,” a talk grounded in community defense and the response of people in the Twin Cities to a crisis.

The security lesson was direct. Relationships need to exist before they become critical.

Organizations need people across departments and levels who already know how to communicate. Teams need an understanding of how information moves through the organization, who can make decisions, and who can help when normal processes stop working. Those skills become muscle memory through repeated use.

Security is part technology and part Layer 8, the unpredictable human layer. People get tired. They get scared. They misunderstand each other. They also improvise, share information, solve problems, and care for people around them. Technical systems still depend on those human networks.

That same idea appeared later in Nousheen Begum’s talk on building security awareness before people ever enter the workplace. Password habits, oversharing, manipulation, urgency, and trust become part of daily digital life long before an employee sits through corporate security training.

Security awareness works better as literacy than ceremony. People build habits over years. Organizations eventually inherit those habits.

Both talks put people directly inside the security architecture.

Vulnerability Management Needs Less Stuff to Manage

Lenny Zeltser started his vulnerability management talk with SATAN, the Security Administrator Tool for Analyzing Networks, and the panic it generated when it appeared in the 1990s.

Today, AI vulnerability discovery is creating another surge of anxiety. The number of vulnerabilities continues climbing, while defenders still have finite testing windows, engineers, maintenance windows, and attention.

Patching speed has a ceiling.

Lenny proposed a broader leadership strategy: shrink what needs protection, look beyond scanner output, prioritize with organizational context, and apply pressure where it will actually change the environment.

An abandoned SaaS pilot, an old test environment, an unused account, or an overlapping tool creates work simply by continuing to exist. Removing that asset removes an entire category of future decisions.

That also means CVSS should begin a conversation rather than finish one. An internet-facing authentication service holding customer data carries a very different risk from an isolated test system with no sensitive information and no reachable path from the internet. Exploitation signals, reachability, compensating controls, data sensitivity, and the risk of making the change all belong in the decision.

Security teams know their own terrain better than attackers do. That is a defender advantage worth using.

The same lifecycle problem appeared in Justin Murphy’s session on OpenEoX. End of life, end of maintenance, end of security support, and similar product lifecycle events are often trapped in web pages, PDFs, and vendor-specific formats. OpenEoX is working toward a machine-readable standard that can connect lifecycle data to SBOMs, VEX, and vulnerability management workflows.

Better prioritization starts with knowing what exists, what still matters, and what can disappear.

The Governed Path Should Be the Easy Path

Security becomes a bottleneck when every decision requires a security team to manually inspect somebody else’s work.

Adam Schaal described that problem from his time managing AppSec at AWS. His team faced roughly 1,400 security reviews a year. Developer productivity had accelerated, while the review process remained heavily dependent on people moving tickets back and forth.

The response was secure-by-default golden paths.

AWS CDK was already where developers worked, so the team pushed security controls into that workflow. Default properties could be injected automatically. Deterministic checks could run before human review. Tasks with clear right and wrong answers could be automated.

Adam said those deterministic automations produced a 30 percent time savings in one year and saved 1,480 pentester days. Human attention could move toward work that actually required human judgment.

Johnathon Rhoades approached the same problem from agent governance.

His central rule was simple: shape the path.

A useful guardrail intercepts the action, expresses the policy clearly, enforces it consistently, logs what happened, and keeps human approval separate. A block should also explain enough that the person or agent can move toward the acceptable path.

Controls also need to fail loudly. A security mechanism that silently stops working creates false confidence. A control that creates so much friction that people disable it has created another failure mode.

Britton Hayes and Joakim Pedersen reached the same conclusion while describing the work behind an AI-driven security team at Notion.

Their first attempts at agent-driven infrastructure exposed weak process foundations. Terraform state locking was missing. Applies happened from laptops. Feature branches became stale. Parallel work became dangerous.

They fixed the road first.

Terraform applies moved into CI/CD. State locking and a merge queue established deterministic boundaries. Agents could generate plans and guide checks, while deployment remained inside the controlled workflow.

The same lesson carried into detection engineering and alert triage. When they needed deterministic output, they built deterministic tools and constrained agents to use them. Smaller agents received bounded jobs. Humans kept the final call for consequential actions.

The agents became useful because the surrounding system became clearer.

AI Makes Permissions and Trust Boundaries More Important

AI appeared in nearly every part of the conference, usually attached to a familiar security problem.

Aria Langer used Scrooge McDuck’s Demon Dog to explain defense in depth and excessive privilege.

Her formula for the Demon Dog was an identity, excessive privilege, and ambiguity.

That identity could belong to a human, a non-human workload, or an AI system. The same risk appears when permissions accumulate over time, ownership becomes unclear, and an identity can reach far more than its current purpose requires.

AI increases the speed and reach of those permissions. Access control still determines the blast radius.

A system with excessive privilege can move through segmentation while every individual security control behaves exactly as configured. Least privilege therefore becomes part of the architecture, rather than cleanup work around the edges.

Ofir Balassiano and Golan Myers pushed that discussion down to the endpoint.

Developer machines now contain browsers, plugins, coding agents, MCP servers, skills, local configuration files, repositories, caches, and multiple applications capable of influencing each other.

Configuration files have effectively become control planes.

A file that changes how an agent executes commands carries a different security meaning from an ordinary preference file. The operating system’s traditional user-level trust model gives both files access through the same user context, even though one may shape the behavior of a powerful autonomous tool.

That creates a need for more granular trust boundaries inside the user’s environment. File integrity, configuration auditing, application-level controls, and visibility into which applications can modify agent behavior all become part of endpoint security.

AI gives excessive privilege, confused deputies, unsafe configuration, and weak trust boundaries more ways to act.

Identity Security Continues After Login

A successful authentication event tells only part of the story.

Mark Orlando described the “second front” of detection as the activity that happens after authentication.

A user may authenticate successfully and then appear from a different geography. A session token may be replayed. An attacker may abuse OAuth consent. Device code phishing can lead a victim through a completely legitimate login flow while the attacker controls the transaction around it.

The difficult part is that much of this activity uses legitimate traffic and legitimate identity infrastructure.

Mark’s approach centers on understanding where each technique actually executes and ensuring telemetry exists there. Session replay belongs in identity and session data. Browser attacks require browser context. OAuth abuse requires visibility into grants and application relationships.

High-impact techniques with zero coverage deserve attention first.

Andrea Ibiassi showed the architecture side of the same problem through real-world Zero Trust incident response.

In several incidents, a breach created the organizational clarity needed to map application dependencies, enforce least privilege, segment access, and replace flat network trust with identity-aware access.

One case moved 30,000 users through containment and recovery in under two weeks. Another expanded Zero Trust enforcement from hundreds of developers to 1,700 users while introducing YubiKeys and risk-tiered segmentation.

Identity becomes the decision point. Least privilege determines what happens after authentication.

Tom Cross focused on another identity boundary that receives far less attention: credential reset.

Help desks operate under pressure to restore access quickly. Attackers know it. Public information, SIM swapping, deepfake voice tools, compromised sessions, and convincing social engineering can all target the moment an identity is re-issued access.

A stronger reset process can include cool-off periods, multiple approvals for exceptions, richer verification, and monitoring immediately after a reset. The reset itself deserves the same security engineering as authentication.

GitHub Is Part Development Platform, Part Adversary Infrastructure

Justin Borland opened day two with “The Malware Is Coming from Inside the Repo.”

GitHub provides attackers with almost everything needed for a convincing developer lure: free hosting, fast distribution, a trusted developer domain, and workflows such as git clone, opening a project in VS Code, and running package installation commands that developers perform constantly.

Some DPRK campaigns use repositories as part of fake job interviews. A developer clones the lure, opens it locally, and malicious configuration such as tasks.json helps trigger the next stage.

Justin’s research system continuously pulls public GitHub activity, applies queries and YARA signatures, enriches the results, preserves useful history, and then uses AI to assist with triage.

The important piece is the deterministic spine underneath it.

AI output has to show evidence. Findings must be fact-checkable. A rule firing provides a lead, while repository context, provenance, runtime-delivered payloads, and decoded infrastructure help establish the verdict.

That distinction becomes particularly important when researchers, victims, attackers, and malware analysts may all publish copies of similar malicious code.

Advait Patel made a closely related point about containers.

Single events create noise. Sequences create meaning.

curl inside a container can be routine. curl followed by a write into /usr/bin carries far more signal. A shell, metadata endpoint access, writes to system paths, runtime package installation, and privileged execution become much more useful when the sequence and container context are considered together.

Every risky runtime shape prevented at admission also removes a future class of alerts.

Detection improves when evidence has context.

Incident Response Has to Be Practiced Under Pressure

Richard Suls used the analogy of learning to drive with traffic cones. Reading the driver’s manual does not create the physical and mental habits needed to operate a vehicle under real conditions.

Incident response works the same way.

Richard separated crisis management exercises for senior leadership from technical tabletop exercises for responders. Executives need to practice decisions around ransom payments, regulators, communications, business continuity, and authority. Technical teams need to practice detection, containment, eradication, and recovery.

Good injects force decisions. They escalate. They introduce ambiguity. They involve regulators, media, legal teams, unavailable staff, broken dependencies, and outdated assumptions.

The exercise ends, then the actual work starts. Hot debriefs capture immediate observations. Cold debriefs turn those findings into owners, deadlines, updated playbooks, and remediation work.

Ron Dilley pushed that concept further by examining panic and choking during real incidents.

Panic causes people to think too little. Choking causes experienced people to overthink actions they already know how to perform.

Pressure can create both.

Exercises therefore need a clock, uncertainty, real decision makers, changing conditions, and measurable outcomes. The scenario should react to what the team actually does. Teams should practice frequently enough that skills survive between incidents.

An incident response plan serves as a reminder. The team needs enough practiced skill to operate when reality stops matching the document.

“You do not rise to the occasion. You fall to the level of your training.”

That principle connected directly back to Ian Coldwater’s opening keynote. Readiness comes from relationships and skills established before they are urgently needed.

Better Security Changes the Flow

BlueTeamCon 2026 covered a huge range of defensive security work, but the same architectural pattern appeared again and again.

Shrink the attack surface before creating another queue.

Build secure defaults into the tools people already use.

Put deterministic controls around work that has deterministic answers.

Give AI bounded jobs, reliable tools, and limited authority.

Treat identity, sessions, configuration, and permissions as part of the security boundary.

Collect evidence where the attack actually happens.

Practice crisis decisions before the crisis arrives.

Build relationships before the organization needs them.

Chicago once solved a massive public health problem by changing the direction its system flowed. Security teams can apply the same principle on a smaller scale every day.

Make the governed path clear enough that people can follow it, make dangerous paths harder to reach, and build enough practice into the system that everyone knows where to go when the pressure arrives.