Securosis

AI Will Accelerate Your Tech Debt

Sun, 22 Mar 2026 00:00:00 +0000

The Tech Debt Crisis Is Coming

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.

AI Security Invariants

Sat, 21 Mar 2026 00:00:00 +0000

(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?

Going to RSAC 2026? Disaster Recovery Breakfast and MORE!

Mon, 16 Mar 2026 00:00:00 +0000

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.

AI, have you been drinking?

Mon, 11 Aug 2025 00:00:00 +0000

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.

The 15th Annual Disaster Recovery Breakfast

Mon, 31 Mar 2025 00:00:00 +0000

It has survived recessions, obsessions, parenthood, natural disasters, pandemics, unnatural disasters, and the rise and fall of eateries great and small. That’s right, it’s the Securosis RSAC Disaster Recovery Breakfast! This year we’ve changed things up thanks to our new partner, 1Password, who reached out and offered to host the DRB in their event space just up the street from the Moscone center. With all the changes in the restaurant scene in that particular area of town… you can understand how this… reduced our annual organizational stress. As always this is a quiet hangout of an event. Drop in and out as you please to catch up with friends, strangers, and… well, whoever wanders in. An RSVP is appreciated to make sure we have enough food, but as always is not required. We hope to see you there! Optional RSVP at https://events.1password.io/RSA2025#

Announcing the CloudSLAW Patreon!

Tue, 25 Feb 2025 00:00:00 +0000

TL;DR: Support CloudSLAW Here!

I know that as most of you lay your weary heads to rest every night (or morning, for you night shifters), the last thought that fires through your synapses is, “I really wish I could get more CloudSLAW!”

And then a not-a-miracle occurs...

Sun, 24 Nov 2024 00:00:00 +0000

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.

Enterprise Governance Is Failing Cloud Security

Fri, 18 Oct 2024 00:00:00 +0000

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.

On TidBITS: My Take on Apple Intelligence and Private Cloud Compute

Mon, 01 Jul 2024 00:00:00 +0000

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:

Old Dog, New Tricks [Final Incite: June 24, 2024]

Mon, 24 Jun 2024 00:00:00 +0000

TL;DR: Back in December, I took a job as head of strategy and technology for a candy-importing company called Dorval Trading. To explain the move I dusted off the confessor structure, and also performed a POPE evaluation of the opportunity below. I’ll be teaching at Black Hat this summer, so I hope to see many of you there. Otherwise you can always reach me at my Securosis email, at least until Rich cancels my account.

It’s another sunny day in the spring. Mike walks into the building. It’s so familiar, yet different. It’s been over 4 years since he’s been here, and it seems lighter. Airier. But the old bones are there. He takes a look around and feels nostalgic. Mike knows this is probably the last time he’ll be here. It’s a very strange feeling. He steps into the booth, as he has done so many times before. He came here to talk through pretty much every major transition since 2006, as a way to document what was going on, and to consider the decisions that needed to be made and why. Confessor: Hi Mike. 4 years is a long time. What have you been up to? Mike: It’s nice to be back. I’ve kept myself occupied, that’s for sure. As we recovered from COVID, Rich and I were faced with some big decisions. DisruptOps was acquired, and Rich decided to join Firemon and lead the Cloud Defense product. I was initially going to keep on the Securosis path, but I got an opportunity to join Techstrong and jumped at it. Confessor: So you and Rich went your separate ways. How did that work out? Mike: Yes and no. Although we don’t work together full-time anymore, we still collaborate quite a bit. We’re in the process of updating our cloud security training curriculum, and will launch CCSKv5 this summer. So I still see plenty of Rich… (Mike gets quiet and looks off into space.) Confessor: What’s on your mind? It seems heavy, but not in a bad way. Kind of like you are seeing ghosts. Mike: I guess I am. This is probably the last time I’ll be here. You see, I’ve taken a real turn in my career. It’s so exciting but bittersweet. Security is what I’ve done for over 30 years. It’s been my professional persona. It’s how I’ve defined my career and who I am to a degree. But security is no longer my primary occupation. Confessor: Do tell. It must be a pretty special opportunity to get you to step out of security. Mike: Would you believe I’ve joined a candy-importing company? I’m running strategy and technology for a business I’ve known for over 40 years. It was very unexpected, but makes perfect sense. Confessor: How did you stumble into this? Mike: Stumble is exactly right. You see, Dorval Trading is a family business started by my stepmother’s parents in 1965. She’s been running it since 1992, and as she was looking to her future, she realized she could use some help. So I did some consulting last year after I left Techstrong, and it was a pretty good fit. The company has been around for almost 60 years, and a lot of the systems and processes need to be modernized. We don’t do any direct e-commerce, and since COVID haven’t really introduced a lot of new products. So there is a lot of work to do. Even better, my brother has joined the company as well. After over 20 years in financial services doing procurement operations, he’ll be focused on optimizing our data and compliance initiatives. So I get to see my family every day, and thankfully that’s a great thing for me. Confessor: Candy?!?! No kidding. What kind of candy? I’m asking for a friend. Mike (chuckling): Our primary product is Sour Power, the original sour candy, which we’ve imported from the Netherlands since 1985. We also have a line of taffy products, and import specialty candies from Europe. If you grew up in the Northeast US, you may be familiar with Sour Power. And now we sell throughout the country. Confessor: So, no more security? Really? Mike: Not exactly. I have been in the business 30 years, and still have lots of friends and contacts. I’m happy to help them out if and when I can. I’ll still teach a few cloud security classes a year, and may show up on IANS calls or an event from time to time. I joined the advisory board of Query.ai, which is a cool federated security search company, and I’m certainly open to additional advisory posts if I can be of help. Learning a new business takes time, but I’m not starting from scratch. In the short time I’ve been with Dorval, I’ve confirmed that business is business. You have to sell more than you spend. You need to have great products and work to build customer loyalty. But there are nuances to working with a perishable, imported product. I also leverage my experience in the security business. I learned a lot about launching products, dealing with distribution channels, and even incident response. In the candy business you need to be prepared for a product recall. So we did a tabletop exercise working through a simulated recall scenario. The key to the exercise was having a strong playbook and making sure everyone knew their job. The recall simulation seemed so familiar, but different at the same time. Which is a good way to sum up everything about my new gig. It turns out the biggest candy conference of the year was the week after RSA, so I couldn’t make it to SF for the conference this year. I did miss seeing everyone, especially at the Disaster Recovery Breakfast. I will be at Black Hat this year, where I’m teaching the maiden voyage of CCSKv5. I look forward to seeing many old friends there. Confessor: So this is it, I guess? Mike: It is. But that’s OK. I’ve preached about embracing change throughout my time here. Not to be afraid, and to look at every opportunity as a way to learn and grow. Not to just do things because you’ve always done them. But to move forward decisively and with intention. And to know that decisions are usually not final, but only different paths in the journey of life. The candy business represents my future, and I couldn’t be more excited. Godspeed to you and everyone in security. It’s a noble profession and critical to our increasingly tech-centric world. Oh, and one more thing. I couldn’t wrap things up without visiting the POPE for a quick analysis of my new job.

The Cloud Shared Irresponsibilities Model

Tue, 04 Jun 2024 00:00:00 +0000

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.

AWS Cloud Incident Analysis Query Cheatsheet

Mon, 20 May 2024 00:00:00 +0000

I’ve been teaching cloud incident response with Will Bengtson at Black Hat for a few years now, and one of the cool side effects of running training classes is that we are forced to document our best practices and make them simple enough to explain. (BTW — you should definitely sign up for the 2024 version of our class before the price goes up!) One of the more amusing moments was the first year we taught the class, when I realized I was trying to hand-write all the required CloudTrail log queries in front of the students, because I had only prepared a subset of what we needed. As I wrote in my RECIPE PICKS post, you really only need a handful of queries to find 90% of what you need for most cloud security incidents.

Let Your Devs and Admins See the Vulns

Mon, 13 May 2024 00:00:00 +0000

A year or so ago I was on an application security program assessment project in one of those very large enterprises. We were working with the security team and they had all the scanners, from SAST/SCA to DAST to vulnerability assessment, but their process was really struggling. It took a long time for bugs to get fixed, things were slow to get approved and deployed, and remediating in-production vulnerabilities could also be slow and inefficient. At one point I asked how vulnerabilities (anything discovered after deployment) were being communicated back to the developers/admins? “Oh, that data is classified as security sensitive so they aren’t allowed access.” Uhh… okay, So you are not letting the people responsible for creating and fixing the problem know about the problem? How’s that going for you? This came up in a conversation today about providing cloud deployment administrators access to the CSPM/CNAPP. In my book this is often an even worse gap, since a large percentage of organizations I work with do not allow the security team change access to cloud deployments, yet issues there are often immediately exploitable over the Internet (or you have a public data exposure… just read the Universal Cloud Threat Model, okay?). Here are my recommendations:

New Accidental Research Release: The Universal Cloud Threat Model (UCTM)

Tue, 23 Apr 2024 00:00:00 +0000

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.” Chris: “Sure, you want to write up the description and submit it?” Me: “Yep, on it!” [A couple months later] Chris: “So what’s this Universal Cloud Threat Model you put in the description?” Me: “Oh, I just thought we’d make fun of all the edgy cloud security attack research since nearly every attack is just the same 3 things over and over.” Chris: “Yeah, sounds about right, want to hop on a quick call to map out the slides?” [A two hour spontaneous Zoom call later] Chris: “Crap, I think we need to write a paper.” Me: “Really?” Chris: “Yeah, this is good stuff.” Me: “Fine. But only if we can put my cat in as a threat actor. He just broke a bowl and is making a move on my bourbon .” Chris: “Sure, what’s his name?” Me: “Goose” Chris: “Well what did you expect?” You can download the UCTM here. And read Chris’ absolutely epic announcement post in the voice of Winston Churchill!

Sisense: Learning Lessons Before the Body Hits the Ground

Fri, 12 Apr 2024 00:00:00 +0000

Look, we don’t yet know what really happened at Sisense. Thanks to Brian Krebs and CISA, combined with the note sent out by the CISO (bottom of this post), it’s pretty obvious the attackers got a massive trove of secrets. Just look at that list of what you have to rotate. It’s every cred you ever had, every cred you ever thought of, and the creds of your unborn children and/or grandchildren. Brian’s article has basically one sentence that describes the breach:

You are infected with Epstein-Barr. You are also infected with the next XZ.

Fri, 05 Apr 2024 00:00:00 +0000

Nearly everyone in the United States (and probably elsewhere) is infected with the Epstein-Barr virus at some point in their life. Most people will never develop symptoms, although a few end up with mono. Even without symptoms you carry this invasive genetic material for life. There’s no cure, and EBV causes some people to develop cancers and possibly Multiple Sclerosis, Chronic Fatigue Syndrome, and other problems. Those later diseases are likely caused by some other precipitating even or infection that “triggers” a reaction with EBV. Look, I have most of a molecular biology degree and I’m a paramedic and I won’t pretend to fully understand it all. The tl;dr is EBV is genetic material floating around your body for life and at some point it activates or interacts with something else and causes badness. (Me write good! Use words!) As I’ve been reading about the XZ Initiative (I’m using initiative deliberately due to the planning and premeditation) the same week that the CISA CSRB released their scathing report on Microsoft, it’s damn clear that our software supply chain issues are as deep as the emptiness of my cat’s soul. (I mean I love him, and I’m excited he’s coming back from the hospital this afternoon, but I couldn’t come up with a more-amusing analogy). If you aren’t up to date on all things XZ I suggest reading Matt Johansen’s rollup in his Vulnerable U newsletter. Here’s how EBV and XZ relate, at least in my twisted mind. XZ was clearly premeditated, well planned, sophisticated, and designed to slowly spread itself under the radar for many years before being triggered. There is absolutely no chance this approach hasn’t already been used by multiple threat actors. As much as I hate FUD and hyperbole, I am 100% confident that there is code in tools and services I use that has been similarly compromised. We didn’t miraculously catch the first ever attempt, because a Microsoft dev is anal-retentive about performance. XZ is the first such exploit which got caught. If I were a cybercriminal or government operative, I would already have several of these long-term attacks underway. You are welcome to believe our record is 1 for 1. I think it’s 1 catch of N attacks, and N scares me. I also do not believe we can eliminate this threat vector. I don’t think the best SAST/SCA tools and a signed SBOM have any chance at making this go away. Ever. That doesn’t mean we give up and lose hope — we just change our perspective and focus more on resilience to these attacks than pure prevention. I don’t have all the answers — not even close — but there are three aspects I think we should explore more. First, let’s make it harder on threat actors. Let’s increase their costs. How? Well, aside from all the improved security scanning over the past few years, I like the idea Daniel Miessler recently mentioned in a conversation and noted in his newsletter: use AI to automatically perform open source intel (OSINT) on OSS contributors. Do they have a history outside that code repo? Any real human interactions? This will be far from perfect, but will likely increase the cost of attack to build a persona which looks sufficiently real. We also have compromises in commercial software (hello Solar Winds). Vendors need to explore better internal code controls, sourcing, and human processes. E.g. require YubiKeys from all devs, side channel notifications and approvals of commits, and I suspect there are some new and innovative scanning approaches we can take as AI evolves (until it evolves past humanity and enslaves us all). E.g. “this may not be a known security defect, but it looks weird compared to this developer’s history, so maybe ping another ~~future energy source~~ human to review it”. I’m also a fan of making critical devs work on dedicated machines separate from the ones they use for email and web browsing, to reduce phishing/malware as a vector. No, I haven’t ever had anyplace I’ve worked approve that, but I have heard of some shops which pulled it off. The final part is preparing for the next XZ that slips through and is eventually triggered. Early detection, rapid remediation, and all the other hard expensive things. SBOM/SCA/DevSecOps are key here: you MUST be able to figure out where you are using any particular software package, and be able to implement compensating defenses (e.g., firewalls) and patch quickly. This is NOT SIMPLE AT SCALE, but it’s your best bet as the downstream customer for these things. None of what I suggested is easy. I think this is the next phase of the Assume Breach mindset. You can’t cure EBV. You can’t prevent all possible negative outcomes. But you can reduce some risks, detect others earlier, and react aggressively when those first cancer cells show up.

It's Time for a Microsoft Trustworthy Cloud Initiative

Wed, 03 Apr 2024 00:00:00 +0000

“All cloud security failures are IAM failures, and all IAM failures are governance failures." — me on Twitter (too many years ago to find)

The 14th Annual RSAC Disaster Recovery Breakfast Is on!

Wed, 03 Apr 2024 00:00:00 +0000

Over 15 years ago (pre-Blip) I wanted to do something fun and casual for friends and Securosis readers at the annual RSA Conference… that I, as a budding entrepreneur, could actually afford. I started calling around and found a little place called Jillian’s right near the conference willing to open up early and serve breakfast for a reasonable rate. We ended up with around 50 people dropping in and out over those few hours, just mostly sitting around a table talking about whatever. Little did I know that our Disaster Recovery Breakfast would outlast Jillian’s, and, it seems, downtown San Francisco? I also never thought it would peak out at one point at around 300 people and inspire dozens of copycats. But one thing never changed — the casual atmosphere, the chance to talk without having to scream into someone’s ear, and the great conversations fueled by coffee (and the occasional Irish coffee). Once again, we’re back! Like last year we are hosting at the Pink Elephant which is just a few minutes walk and totally worth it if you want breakfast burritos or an omelette. This year we have two of our long-standing partners helping us out, plus a new (old) face. Here are the details:

Resolve 90% of Cloud Incidents with RECIPE PICKS

Thu, 07 Mar 2024 00:00:00 +0000

As any long-time readers know, I constantly abuse my past experiences and hobbies to try and make my current work sound WAY more interesting than it probably is. Or maybe it’s just an ego thing, I don’t want to think too hard about it. But, on occasion, lessons from my parallel lives actually inspire some original work. As a paramedic and a pilot I have had to memorize many dozens of mnemonics, and I’ve forgotten many more. Mnemonics are proven to be highly effective memory devices even in the midst of intense stress, like flying a plane or working a 9-1-1 call. For example, I learned “SAMPLE” for taking a patient’s history probably 30 years ago and I still use it today because in the insanity that is some calls it can be easy to lose track and forget a fundamental. This I always remember to ask about Signs and Symptoms, Allergies, Medications, Prior medical history, Last oral intake, and Event (why did they call us today?). Having issues ventilating an intubated patient? Use DOPE. Accidentally put your airplane into a spin? Use PARE (Power, Aileron, Rudder, Elevator). The more you drill these the better they work. I memorized RAKETS for my private pilot checkride but I definitely need to look that one up (it’s used to figure out if you can still fly a plane with a broken part). We don’t really use these in infosec, and I think it’s time to change that. Thus I present to you RECIPE PICKS for cloud incident response. This one hit me yesterday on an internal dev review call in one window while finishing my paramedic recertification in an open browser tab. For 4 years now here is how I’ve taught what to look for first in a cloud incident: I have the students leave that one up when we start the scenarios and live fire exercises. But standing in the shower I came up with a much better way to remember what to do. NOTE: the order doesn’t matter, as with SAMPLE it’s to make sure you don’t miss anything (the format breaks a little at the end due to this sites rendering, sorry): R esource (current config/state) E vents (api call(s) on that resource) C hanges (diff plus associated API calls) I dentity (who made the triggering change or API call) P ermissions (of the identity; informs the blast radius) E ntitlements (of the resource: e.g. it’s IAM role or managed identity) P ublic (is it public?) I P (all API calls from that IP address) C aller (all other API calls from the calling identity) tracK(look for indications of a pivot; e.g. role chaining) forenS ics (on a resource, or digging into resource logs) These steps shouldn’t be done in order, except the last two probably need to be the last two (especially the forensics). This is all based on the process I’ve figured out over the years and I estimate you can probably close 90% of incidents relatively quickly by pulling this data. I’m definitely going to start trying to build more of these into my trainings, and I’ll do some more blog posts in the coming weeks on how to use RECIPE PICKS. I’d also be remiss if I didn’t link over to a work blog post on how our platform does most of this automatically on every incident. Let me know what you think and if I missed anything. Just email rmogull@securosis.com since I have comments turned off due to all the ridiculous spam.

Check out the shiny new Cloud Security Maturity Model 2.0!

Tue, 27 Feb 2024 00:00:00 +0000

I’m pretty excited about this one. We are finally releasing version 2.0 of the Cloud Security Maturity Model. This is the culmination of nearly 9 months of research and analysis, a massive update from the original released in 2020. The tl;dr is that this version is not only updated to reflect current cloud security practices, but it includes around 100 cloud security control objectives to use as Key Performance Indicators — each matched 1:1 (where possible) with a technical control you can assess (AWS for now— we plan to expand to Azure and GCP next).