The Same Ten Passwords, Twenty Years Later

Posted on by

We’ve been logging the credentials that bots throw at an SSH honeypot (our HoneyPoint Security Server™). Nothing exotic: listeners that accept the handshake, record the username/password pair, and the source IP. After letting this run for a bit, the first thing we noticed was how little the dictionary has changed.

HoneyComb

The numbers

Top usernames over the capture window:

Username Tries Sources
root 45,302 350
admin 3,254 256
user 1,978 132
enable 1,863 12
test 1,414 101
ubuntu 1,142 125
user2 452 26
debian 433 39
deploy 387 47
support 372 104

root alone accounts for more attempts than everything else combined, by a factor of about four. That’s not surprising. What’s worth noticing is the sources column: 350 distinct IPs tried root, 256 tried admin. This is the broad, low-effort campaign layer to find the most basic common hanging fruit.

Continue reading →

Authentication Is Not the Finish Line: Secure the Token Lifecycle

Posted on by
Reply

A user signs in with a passkey. The authentication is phishing-resistant. The identity provider records a successful challenge. Every dashboard says the login worked as designed.

Hours later, an attacker reuses a stolen session token.

No password is entered. No push notification appears. No new authentication ceremony occurs. The application sees a valid artifact and accepts it.

Both facts can be true at the same time: the authentication was strong, and the session was compromised.

That is the identity problem security programs need to address next.

Passkeys, hardware security keys, conditional access, and stronger account recovery are essential. They protect the process of establishing identity. But modern applications rarely ask a person or workload to prove identity again for every action. They rely on tokens and assertions that carry the result of an earlier decision across applications, APIs, clouds, and sessions.

The security boundary therefore does not end at login. It moves with the token.

NIST and CISA made that point operational in the final September 2026 release of NIST IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse. The report addresses the keys that create trust, the systems that validate it, the lifetime of tokens, session monitoring, revocation, workload identity, and the division of responsibility between cloud providers and their customers.

The practical lesson is straightforward:

Treat every token as a live authorization decision, not as a receipt proving that authentication once succeeded.

An award winning portrait of a beautiful red headed woman bokeh lights in background cinematic lighting realistic very sharp 8k 3d render

Continue reading →

Three Field Guides for the Security Problems Showing Up Right Now

Posted on by
Reply

Over the last several months, we have released three longer-form guides around problems we keep seeing in real environments:

  • The Antifragile SOC Book
  • The AI Agents Management Framework
  • The Security Leader’s Operating System

They cover different areas, but they share a common theme: how to operate effectively as complexity, automation, and pressure increase.

Books

Why We Created These Materials

These guides did not begin as content projects.

They came from working problems.

Over the years, we have accumulated a lot of models, processes, questions, and operating approaches that we use when helping organizations solve difficult security problems. Some came from client work, some from research, and plenty came from lessons learned the hard way.

Much of that knowledge lived in conversations, notes, presentations, and experience.

We decided it was time to write more of it down.

Not as theory, and not as another collection of cybersecurity predictions.

As practical field material people can use, challenge, adapt, and apply.

Continue reading →

The Top Three Things Security Teams Need to Understand About AI-Driven Attacks

Posted on by
Reply

The easiest mistake security teams can make about AI-driven attacks is to imagine a completely new species of adversary.

That is not what most organizations are facing.

The objectives remain familiar: steal credentials, gain access, persist, move laterally, collect data, commit fraud, extort the victim, or conduct espionage. What AI changes is the economics of the attack. It reduces the time, expertise, and attention required to move from one step to the next.

That distinction matters because it tells defenders where to act.

Google Threat Intelligence Group reported this week that it has observed adversaries moving beyond basic prompting into agentic workflows and AI-enabled automation. In one Q2 2026 case, a threat actor used an AI coding chatbot and agent instructions to help plan, build, and execute a mass credential-harvesting campaign in less than six hours. The framework automated scanning, troubleshooting, and IP rotation with limited human involvement. (Google Threat Intelligence Group, September 8, 2026)

That does not mean every attacker has become an autonomous machine. It means the constraints that used to slow attackers down are weakening.

OnlineScammer

Security teams need to understand three things.

Continue reading →

Introducing The Security Leader’s Operating System

Posted on by
Reply

There is one sentence I hear from information security leaders more than almost any other:

“I don’t have time to do what I need to do.”

The problem usually isn’t motivation, discipline, or effort. Security leaders already work hard. The deeper problem is that their ability to handle difficult work attracts more difficult work.

Questions, approvals, exceptions, vendor reviews, audit requests, incidents, meetings, unfinished decisions, and executive concerns all flow toward the person who has demonstrated that they can carry them. Eventually, being able to handle almost anything becomes the reason the leader has time to think about almost nothing.

I wrote The Security Leader’s Operating System to help change that.

Thinking

Security Leaders Don’t Need Another Productivity Trick

Most productivity systems concentrate on organizing work after it has already been accepted.

This field guide starts earlier.

Before deciding where a task belongs, it asks whether that work should exist in its current form at all. It applies the EDSAM mental model:

  • Eliminate work that does not need to happen.
  • Delegate outcomes that do not require the leader’s authority or judgment.
  • Simplify work until it produces the smallest useful result.
  • Automate the predictable parts of the work that remains.
  • Maintain only what must remain under the leader’s direct care.

The objective is not to help security leaders process an endlessly growing queue more quickly. It is to redesign the system so that less work requires the leader in the first place.

Continue reading →

When the Security Control Plane Fails: Build a Minimum Viable Defensive System

Posted on by
Reply

At 2:13 a.m., the SOC receives an alert involving a cloud administrator.

At 2:16, analysts lose access to the SIEM because authentication depends on the identity provider now under investigation.

At 2:19, the incident collaboration channel disappears.

At 2:23, the on-call engineer discovers that the break-glass credentials are stored in the privileged-access platform—which also authenticates through the suspect identity provider.

At 2:27, the cloud console still shows green status indicators, but nobody can establish whether the logs are complete, delayed, or manipulated.

By 2:35, the organization has two incidents.

The first is the security event.

The second is the loss of its ability to respond to the security event.

That second incident is the one most response plans do not adequately address.

3Errors

Incident Response Has a Hidden Assumption

Continue reading →

Architecture Ages. Security Programs Should Plan for That

Posted on by
Reply

Every security architecture has an expiration date.

Most organizations simply do not know when it arrives.

An architecture may have been carefully designed, properly documented, and well defended when it was introduced. It reflected the business, technology, threat environment, and operational assumptions of its time.

Then the organization changed.

It adopted cloud services. It acquired another company. Employees became more distributed. Vendors received deeper access. Applications became API-driven. Automation expanded. AI entered business workflows. Identity became the connective tissue between systems that no longer shared a traditional perimeter.

The architecture did not suddenly fail.

It aged.

80sIBM

Continue reading →

The Hidden Cost of “Temporary” Security Exceptions

Posted on by
Reply

Nothing is more permanent than a temporary security exception.

The emergency administrator account created during a production outage remains active months later.

The firewall opening approved for a launch is never removed.

The vendor access granted for troubleshooting quietly becomes the normal support model.

The policy exception accepted until a legacy application is replaced survives three budget cycles.

None of these conditions usually begins with negligence.

They begin with urgency.

That is precisely why they are dangerous.

E compliance

Exceptions Are Designed for the Present

A security exception is a decision to tolerate a known weakness because another business need is temporarily more important.

That may be entirely reasonable.

Continue reading →

Stop Measuring Security Controls. Measure Decision Latency.

Posted on by
Reply

The attacker already made a decision.

Your organization is still scheduling the meeting.

For years, security programs have measured the presence and performance of controls. We count vulnerabilities, patching percentages, phishing failures, endpoint coverage, open findings, audit exceptions, and incident response times.

These metrics can be useful.

They can also create the illusion that security outcomes are primarily determined by control quality.

In many consequential events, the organization does not fail because it lacks information or technology.

It fails because it cannot make a confident decision quickly enough.

Cyberleader

Continue reading →

Security Debt Compounds Faster Than Technical Debt

Posted on by
Reply

Organizations rarely wake up insecure.

They slowly inherit yesterday’s exceptions.

A firewall rule is added to support an urgent launch. A service account is created for an integration that will supposedly be replaced next quarter. A vendor receives elevated access during troubleshooting. A legacy application remains connected because the migration became more difficult than expected.

Each decision appears manageable in isolation.

Over time, they begin to interact.

That is when security debt starts to compound.

Thinking

Security Debt Is More Than Unpatched Software

Technical debt generally refers to the future cost created when teams choose a faster or easier implementation today.

Continue reading →