As you can see, things around here have changed a little. This site will celebrate its 20th anniversary next month. Due to site migrations and Rich’s advancing age, we’re not quite sure the date of the first post. It was either August 7th or August 20th 2006. That was several database migrations ago. Attribution is hard and the timeline doesn’t entirely line up with BourbonKitten.
When you ran inference on AWS Bedrock, the deal was explicit: prompts and completions stayed inside the AWS boundary, and model providers never saw your data. That guarantee is why regulated shops and European organizations route their AI workloads through Bedrock instead of going straight to the model vendor.
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?
Someone asked me last week if I was going to RSAC. I replied that I’m pretty sure after I die they’ll prop my body up in a corner of Moscone, Irish wake style. Eventually I’ll retire or move on, but this year isn’t THAT year. I still get tremendous value out of RSAC. Personally I spend nearly no time on the show floor, a lot of time in meetings, and a bit of time in sessions. As a review committee member I see all the content for my track before I show up and I think most people who complain about the conference get blasted by the show floor and don’t go to sessions. The content has improved materially over the past decade, with more deep technical content than most people realize. This year I’m presenting in four sessions (unexpectedly). I’m co-presenting with Aaron Turner on some IANS content on MCP/agent architectures we collaborated on. I’m running a cloud incident analysis workshop with Ryan Bergsma, one of my Cloud Security Alliance co-workers. I’m giving a new presentation on K-12 and “below the security poverty line” orgs with a first-time collaborator, Michael Klein, and I’m facilitating a Fundamentals Forum. I’m also presenting at our CSA Summit on Monday (on the Governance hierarchy… and announcing a new CSA initiative), participating in a panel on OpenClaw, and… yeah, busy week. For the first time we are offering 1-on-1’s to CSA members at the Summit! Yes, I am voluntarily packing my schedule every 30 minutes like back in Gartner days. Just email me for more info on that. But I saved the best for last. The 16th annual Disaster Recovery Breakfast! And for the second time this is hosted by our friends over at 1Password (like, actual friends I’ve known for decades). My kids are on spring break this week and all my content is approved, so I’m off for some family time before my four day marathon, I hope to see you there, and email me at rmogull@securosis.com if you want to catch up or snag one of those 1-on-1 slots on Monday.
Chris & Rich’s session at RSAC 2025 The Coming Cloudpocolypse: Disrupting the Cloud Shared Responsibility Model.
You can also find the Slides here
Note: This post has been revised to include the new capabilities released by AWS prior to re:Invent 2024.
You can also check out the re:Invent presentation we did with Securosis: “Security invariants: From enterprise chaos to cloud order” slides - video
I’ve spoken a lot about Security Invariants, but all of them have been implemented using Organizational Policies. That’s great, but organizational policies don’t apply to the Organizational Management Account (aka “payer”). So how does one implement invariants in a payer account?
AWS would tell you that you shouldn’t be giving anyone access to the payer account, so the need for invariants should be minimal. However, that doesn’t reflect the reality that AWS never protected its customers from themselves and prevented the enabling of Organizations or Control Tower in an account with existing workloads. I would say this is a failure of Customer Obsession and demonstrates Security is not the Top Priority. AWS would hide behind shared responsibility and blame the customer.
Regardless, there are many cases where workloads are in a payer account, and as a security person, you need to live with those workloads while protecting the rest of the AWS Organization. So, how do we build invariants into a payer account when SCPs and RCPs don’t apply?
Enter Permission Boundaries.
Rich and Chris’s session at re:Invent 2024 on Security invariants: From enterprise chaos to cloud order
Slides and an accompanying Blog Post that included the re:Invent releases that didn’t make it into our talk.
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.
Chris & Rich’s session at RSAC 2024 CloudSec Hero to Zero: Self-Obsolescing Through Prolific Efficiency.
You can also find the Slides here. Read more about the Universal Cloud Threat Model in the research library.
The conversation went something like this:
Me: “Hey Chris, want to co-present at RSA? I have this idea around how we fix things when we get dropped into a new org and they have a cloud security mess.”
Most organizations have a preferred cloud provider. This is the provider where they have the most engineering expertise, have negotiated the best discounts, and have built the paved road experience.
tl;dr - here is a link to the scripts
In a typical ransomware attack, a threat actor will attempt to encrypt files on critical machines belonging to the victim. In exchange for a cryptocurrency payment, the threat actor will provide the decryption key and software to the victim, who then has to go through the arduous process of restoring their machines. The encrypted data is typically lost forever if the victim refuses to pay the ransom.
This is a revised version of the original post Leveraging AWS SSO (aka Identity Center) with Google Workspaces based on the new announcement AWS IAM Identity Center now supports automated user provisioning from Google Workspace The original post is still valid, and in someways may be better, but this version has it’s own advantages.
Setting up AWS IAM Identity Center (successor to AWS Single Sign-On), hereafter called AWS SSO (because I have to pay AWS for egress on this site), is an excellent service to help you get rid of IAM users and enforce identity best practices around second-factor authentication, on and off-boarding employees, and assigning the right level of access depending on job function.
Companies using Google Workspaces for email and collaboration can also leverage their Google accounts to access AWS via AWS SSO. The process isn’t clearly documented, and the provisioning support isn’t integrated, so here is a post to help you set it all up.
Setting up AWS IAM Identity Center (successor to AWS Single Sign-On), hereafter called AWS SSO (because I have to pay AWS for egress on this site), is an excellent service to help you get rid of IAM users and enforce identity best practices around second-factor authentication, on and off-boarding employees, and assigning the right level of access depending on job function.
Companies using Google Workspaces for email and collaboration can also leverage their Google accounts to access AWS via AWS SSO. The process isn’t clearly documented, and the provisioning support isn’t integrated, so here is a post to help you set it all up.
Setting up AWS IAM Identity Center (successor to AWS Single Sign-On) henceforth called AWS SSO (because AWS charges for egress), is an excellent service to help you get rid of IAM users and enforce identity best practices around second-factor authentication, on and off-boarding employees, and assigning the right level of access depending on job function.
This past weekend I spoke at BSides Nashville on offensive operations in AWS: Get outta my host and into my cloud. While I was finishing the talk, Nick Jones published a blog post of his own: On AWS Penetration Testing.
At BSides Atlanta today I gave a talk on how to handle an incident in AWS. The talk and this post is intended to help those already familiar with the principles of Incident Response to understand what to do when the incident involves the AWS Control Plane. You can find the Slides here.
Chris’s presentation to BSides Augusta in 2021 - The Cloud is Dark and Full of Terrors
Slides and Blog Post are available.