Like the American middle class living paycheck to paycheck, organizations near or below the security poverty line are one big incident away from catastrophic bankruptcy. They got here through years of underinvesting in core capabilities and unified architecture, not stupidity, but a long series of decisions that prioritized shipping over sustainability. And now every smaller incident consumes the cycles that could have gone toward paying down that debt, making the hole deeper every time. Tech debt isn’t just a code quality problem. It’s an operational survival problem. The environment is too complex to reason about, too brittle to refactor, and too interconnected to safely improve. Every incident response leaves the org a little more exhausted and a little further behind. We’re rapidly approaching a security crisis that looks like the financial crisis of 2008. Thousands, maybe millions, of companies with business models that cannot afford proper security are about to get breached and go out of business. Like the families with mortgages they couldn’t afford, many of these companies were on borrowed time to begin with. The unsympathetic response will be “they shouldn’t have been in business at all,” but people will still be out of work, investors will still be out of money, and the ripple effects will be real. And AI is only going to make this worse.
(Co-Authored with Ariel Septon of Native) Security invariants are a critical component of your cloud and IT governance strategy. However, how can we apply this same thinking to the non-deterministic world of Generative AI?
For the last couple months I have been working with AI security. First with the general architecture and data flows for Generative and Agentic AI systems, and lately more with prompt & response security techniques. These later topics are where AI systems offer greenfield for attackers to apply all the old – and a select few new – attack techniques. I was researching how to coerce AI to misbehave, as part of my introduction to prompt engineering, I am stumbling across cases where we do not need attackers at all – the AI systems seem eager to misbehave all on their own.
It’s a perfect fall Sunday morning here in Phoenix. After a brutally hot summer the air is cool, the sky is clear, and the fresh air is drifting into the hotel ballroom while I wait for my daughter to take the stage in the Irish dance regionals competition.
We have a major problem. It isn’t really getting better, and soon a critical window of opportunity will close that we can’t afford to lose. I don’t say this lightly, and I think anyone who has read my prior work knows I am not prone to FUD. No one can possibly know the actual percentage of enterprise workloads and applications that have moved to cloud, but every statistic I could find estimates that, at most, it is somewhere in the range of 25% (here’s one Gartner take). I think under 25% is likely accurate, but I estimate that well over 90% of organizations have some production workloads in cloud, including SaaS and PaaS/IaaS. The lake is wide but only deep for a relatively small number of enterprises. This is natural and expected; it takes decades to transition existing workloads, especially when they are running happily in datacenters and there’s no major driver to move them out. This is our window. Most organizations are in the shallow end of the pool, staring wistfully at the adventurous kids jumping off the high dive and frolicking around in the deep end. We have a choice – wait, learn to swim, or strap on some floaties and hope for the best. Oh, and there’s no lifeguard and there are most definitely some sharks. With lasers. If organizations don’t improve their cloud governance, they have no chance of meaningfully improving their cloud security. That’s bad enough with today’s relatively limited cloud adoption, but as we gradually move more and more workloads to the cloud, without effective governance the problem will increase exponentially. Nearly every single cloud security issue and breach is the direct result of a governance failure, not a technology failure.
I just published a piece on Apple Intelligence at TidBITS that I’m pretty excited to release. I wrote it (literally sitting poolside on vacation) to try and explain why this matters to someone even if they don’t know anything about AI or security. For those of us in cloud security, some really interesting things are going on:
The next phase of cloud security won’t be about shiny new products or services, although we’ll have those. It won’t be about stopping the next world-ending cloud 0-day, but we’ll continue trying to prevent them. It won’t be about AI, but we’ll still have to do something with AI to appease our machine overlords. It will be about making cloud deployments more inherently secure through better, smarter defaults, and better, smarter, and yes, cheaper, built-in capabilities. Here’s why: When I first started researching and working with public cloud about 15 years ago, I realized that cloud providers have massive economic incentives to be better at security than your organization. A major breach of a cloud provider that affects all (or most) tenants would be an existential event which would destroy trust in that provider and crater their business. We’ve arguably had moderate multi-tenant events, and are witnessing events in real time — wondering whether my theory will stand, and a major CSP will suffer from a direct breach (as a result of Microsoft’s recent incidents and the CISA CSRB report). This was the origin of the shared responsibilities model. There’s a waterline in the technology: below it the cloud provider is responsible for ensuring the services you consume are inherently secure. Above it you are responsible for how you secure and configure what you use. Security is transitive. When I build on a service, I am only as secure as the underlying service. It turns out this plays both ways. It’s a two-way door. Security impacts are also transitive. If a customer on a cloud platform suffers a major security breach, every headline includes the name of the cloud provider. Sure, you can blame the customer for misconfiguring your service, but that doesn’t mean everyone won’t still think you’re responsible.