James W.

Oct 26, 2026

"Why would anyone bother targeting us?" might be one of the most expensive questions an organization can ask when it's being used to justify doing nothing. I've heard variations of that argument throughout my career, usually somewhere between a CTI assessment identifying a credible threat and a discussion about why remediation needs to wait until the next budget cycle. And I understand the temptation, because preventive security spending is immediate, visible, and relatively easy to question, while the cost of an incident that hasn't happened yet is hypothetical and conveniently absent from the balance sheet.

Unfortunately adversaries don't necessarily care whether we consider ourselves important enough to target. Sometimes we're valuable because of the information we hold, the services we provide, the organizations we're connected to, or simply because we're an accessible stepping stone toward something else. That's where dismissing CTI becomes a business decision, whether leadership recognizes it or not.

When intelligence identifies a credible exposure and the organization chooses to defer remediation, it isn't avoiding a cost. It's accepting a risk whose eventual price may include incident response, forensic investigations, legal expenses, operational downtime, lost revenue, customer attrition, regulatory scrutiny, and months of recovery work. Compare that with the often considerably smaller cost of preventive maintenance, targeted remediation, compensating controls, or architectural improvements before an adversary gets involved.

What bothers me isn't that organizations sometimes accept risk, because there are perfectly legitimate business reasons to do so. It's when they accept that risk without understanding the potential consequences, or dismiss the intelligence because the threat doesn't fit their perception of who would find them interesting.

CTI should help leadership distinguish between theoretical exposure and credible business risk, quantify the consequences where possible, and understand what they're buying with remediation versus what they're gambling by deferring it. And we should be measuring that decision over time, because a vulnerability left unresolved for six months isn't necessarily the same risk it was when the original assessment was written.

I wonder how many organizations would make different decisions if every deferred remediation carried an estimate of the operational and financial consequences of being wrong, alongside the actual cost of fixing it. If preventing a breach costs $50,000 and recovering from one could cost $5 million, are we really saving money by postponing remediation, or just betting the business that nobody notices before we get around to it? CTI may be classified as 'overhead' but if that same 'overhead' saves money in the long run shouldn't we begin to consider it more like flipping a cost center into a revenue generator?

View post

Oct 21, 2026

PHP2Shell points to a larger problem; how many organizations are about to discover that their biggest vulnerability isn't (recent current hot-button vulnerability), but the inability to understand what actually depends on it.

Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, have exposed something considerably more interesting than another emergency patching exercise. We're talking about flaws in PHP itself that can enable unauthenticated remote code execution and memory disclosure, potentially affecting everything from public-facing websites to business applications that nobody has thought about in years.

And while the technical implications are serious, I think the business implications deserve considerably more attention. From a CTI perspective, the interesting question isn't simply how many vulnerable instances we have, but which ones represent meaningful opportunities for an adversary and what happens to the business if those opportunities are exploited. A vulnerable marketing website, an externally accessible customer portal, and an internal application connected to sensitive business systems may share the same CVE, but they don't necessarily share the same risk profile or business consequences.

That's where intelligence should start influencing the response. Understanding adversary interest, exposure, exploitability, business dependencies, and potential downstream consequences should help determine what gets isolated, patched, hunted, or subjected to additional controls first. Emergency remediation still matters, but treating every affected asset as an identical business risk isn't particularly intelligent.

There's another aspect of PHP2Shell that I find fascinating, and definitely at least a "little" unsettling (making quotation marks in the air with my fingers). AI-assisted research helped turn longstanding, technically complex vulnerabilities into working exploits, challenging assumptions about how much protection exploit complexity actually provides. That should make us reconsider how we assess the practical likelihood of exploitation, especially as the cost of discovering and weaponizing previously difficult vulnerabilities continues to change.

Ultimately, the success of our response shouldn't be measured solely by how quickly we close the tickets. It should be measured by how effectively we protect the business capabilities that matter, reduce credible adversary opportunities, and avoid unnecessary operational disruption along the way. If PHP2Shell forced your organization to identify every business-critical dependency on PHP tomorrow, would your security team already know where to look, or would the vulnerability become the first time anyone asked?

View post

Oct 16, 2026

Cybersecurity has a buzzword addiction, and I'm starting to wonder how much actual strategy is hiding behind all that vocabulary. We talk about innovation, agility, transformation, and becoming intelligence-led, but none of those things mean much to a business that's losing revenue during an outage, spending millions defending the wrong assets, or discovering that its most critical operational dependencies were never part of the risk conversation.

There's a considerable difference between telling executives that CTI is improving organizational resilience and demonstrating that intelligence helped prevent a costly disruption, redirected investment toward a credible threat, eliminated unnecessary spending, or protected a business capability that actually generates revenue. One sounds good in a board presentation, while the other changes how the organization allocates capital, manages risk, and operates.

That's the distinction I think we need to get considerably more serious about, because the value of CTI shouldn't be measured by how sophisticated our intelligence products sound, but by whether the decisions they influence produce better business outcomes. If we stripped away every buzzword in your CTI program tomorrow, would there be enough measurable business impact left to justify its existence?

View post

Oct 9, 2026

Why are people still trying to defend tomorrow's infrastructure with yesterday's thinking? We've spent decades building careers, architectures, security programs, and entire industries around assumptions that made sense when we controlled the network, owned the infrastructure, and could reasonably identify where our boundaries existed but many of those assumptions have outlived the environments that made them useful. That disconnect is costing us.

We still have conversations about security boundaries as though geography determines trust, treat identity as something that belongs primarily to people, and build detection strategies around infrastructure that may only exist for a few minutes. Meanwhile, our businesses are operating across cloud platforms, APIs, third-party integrations, autonomous agents, and increasingly complex dependencies that don't particularly care where we drew the network perimeter.

What's interesting to me is that the technology isn't our biggest obstacle anymore; our reluctance to question the assumptions is. I understand why that happens, because experience creates confidence, and confidence can become a liability when the environment changes faster than our willingness to reconsider what we think we know.

From a CTI perspective, this becomes particularly concerning when we're still organizing defenses around yesterday's attack surface while adversaries are already exploiting the relationships between identities, services, data, automation, and business processes and the business impact goes well beyond missing an attack. We're investing in controls that protect diminishing portions of our environment, creating friction around legitimate innovation, misallocating security budgets, and making decisions based on risk models that no longer accurately represent how the organization operates.

I'm not suggesting we abandon foundational security principles, because identity, least privilege, segmentation, visibility, and defense in depth remain incredibly relevant. What needs to change is how we apply them, what we consider an asset, where we establish trust, and how we measure whether our investments are actually reducing risk.

Maybe we need to become a little less protective of the architectures we know and a lot more curious about the environments we're actually being asked to defend. The purpose of cybersecurity isn't to preserve the way we've always done things; it's to enable the business to operate, adapt, and grow without accepting unnecessary risk. I wonder how much of what we currently call a cybersecurity challenge is actually just inability to let go of an outdated mental model and embrace the unknown change of the future.

View post

Sep 29, 2026

People have suggested that I am a meat proxy (awesome phrase and concept BTW) before. It's hilarious, mostly because my biggest crime seems to be using the words "utilize" and "clarity" in casual conversation. But honestly, the evidence is starting to stack up against me.

Words like "leverage," "operationalize," and "alacrity" pop out of my mouth way too often. "Downstream analysis" has even leaked out of my cybersecurity day job and right into my kitchen. I blame more than 15 years of federal government contracting. When you spend that long churning out proposals, reports, and deliverables, you pick up a very specific dialect. Everything has to be actionable, measurable, aligned, and leveraged just to hit some obscure requirement buried on page 37 of an appendix nobody actually read.

Eventually, you don't just write like that, unfortunately you just thinking that way. It's like my brain accepted a weird corporate firmware update and pushed it straight to production and didn't do even a minimum of static code analysis.

My wife has this very specific look she gives me when the kids act up and I catch myself asking them why they didn't conduct a "downstream analysis" before making a bad choice. Apparently, normal parents just call that "possible consequences," who knew?

Being neurodivergent probably doesn't help. I've always loved precision, patterns, and picking that one oddly specific word when a normal one would do just fine. Mix that with years of risk analysis, cyber threats, and executive briefings, and my everyday chatter basically morphed into a ChatGPT prompt written by a bureaucrat.

It’s pretty ironic when you think about it, stressing out about AI learning to sound human, but some of us just end up spending two decades in a career that trained us to sound like machines.

Maybe the trick isn't obsessing over what "sounds like AI" but realizing that our language picks up the quirks of the places we work. Sometimes, a weirdly robotic phrase isn't proof of artificial intelligence but instead demonstrates you wrote way too many federal contracting reports.

Anyway, if you'll excuse me, I need to go operationalize bedtime with greater alacrity. My current stakeholders are showing absolutely zero concern for downstream impacts.

View post