Speaker 1: You know, usually when we talk about moving into a
Speaker 1: brand new, state of the art luxury high rise, there
Speaker 1: is this expectation of well, total safety. Right if you
Speaker 1: walk in, you see the security guard stationed in the
Speaker 1: marble lobby, you see the key card scanners on the elevators,
Speaker 1: the thick concrete wall.
Speaker 2: Seems naturally assume, hey, I'm safe here. They have got
Speaker 2: those handled exactly.
Speaker 1: You just think it's covered. But then you realize something terrifying. Yes,
Speaker 1: the building management secures the lobby. I mean they check
Speaker 1: the IDs at the front desk, but you left your
Speaker 1: actual apartment door wide open. Oh yeah, and your personal
Speaker 1: safe city right there in your closet is just completely unlocked. Yeah.
Speaker 1: Suddenly that feeling of total security is well, it's just
Speaker 1: an illusion. You're looking at a security landscape that you
Speaker 1: have entirely misunderstood.
Speaker 2: It is the absolute definition of a false sense of security,
Speaker 2: and you know it perfectly mirrors the biggest misconception in
Speaker 2: digital infrastructure today. We see a massive, multi billion dollar
Speaker 2: tech company hosting our data, and we assume that because
Speaker 2: their lobby is secure, our apartment is too.
Speaker 1: Welcome to the deep dive. That illusion of safety you
Speaker 1: just described That is exactly what we are unpacking today.
Speaker 1: We're looking at Chris Dotson's guide Practical Cloud Security, a
Speaker 1: guide for secure design and deployment. It's such an essential read,
Speaker 1: it really is, and our mission today is to take
Speaker 1: his framework, strip away all that dense, intimidating jargon, and
Speaker 1: just uncover the practical, everyday strategies used to protect digital assets.
Speaker 1: We are going to explore everything from managing your risk
Speaker 1: to tracking down these ticking time bombs of forgotten servers.
Speaker 2: Because while the cloud fundamentally changes how we secure things,
Speaker 2: you know, stripping away those physical walls and concrete barriers
Speaker 2: we just talked about, the why remains deeply rooted in
Speaker 2: common sense. Yeah, the underlying logic of security hasn't changed
Speaker 2: at all, just the execution.
Speaker 1: So if you're listening to this and you have ever
Speaker 1: felt completely overwhelmed by the idea of cloud security, I
Speaker 1: mean you are definitely not alone. There is a twenty
Speaker 1: seventeen baracouta network survey referenced in our sources that is
Speaker 1: just wild to make.
Speaker 2: Oh the responsibility one.
Speaker 1: Yes, seventy seven percent of it. Decision makers wrongly believe
Speaker 1: that cloud providers are fully responsible for securing customer data.
Speaker 2: It's just a staggering statistic, seventy seven percent. It shows
Speaker 2: a fundamental industry wide misunderstanding of what we call the
Speaker 2: shared responsibility model.
Speaker 1: Right because in an old school on premises it environment,
Speaker 1: the company handles absolutely everything right exactly.
Speaker 2: You buy the servers, you hire the guards, you lock
Speaker 2: the doors. But in the cloud, there is a literal
Speaker 2: line of demarcation, and that line, well, it moves depending
Speaker 2: on what kind of service you were actually paying for.
Speaker 1: Okay, let's unpack this. Let's think about this like ordering pizza.
Speaker 1: I think this is the best way to visualize it.
Speaker 1: So imagine you want pizza tonight. Okay, let me keep
Speaker 1: the traditional on premises world is like making that pizza
Speaker 1: completely from scradge. At home. You buy the dough, the sauce,
Speaker 1: the cheese, You provide the oven, the dining table, the electricity,
Speaker 1: the soda, right, the soda. You have complete flexibility if
Speaker 1: you want an anchovy and cinnamon pizza, I mean gross,
Speaker 1: but you could do it. But you do all the
Speaker 1: work and you clean up the mess exactly.
Speaker 2: Now, let's step up to the first tier of the cloud,
Speaker 2: which is infrastructure as a service or I This is
Speaker 2: the taken bake model.
Speaker 1: Okay, taken bake.
Speaker 2: Yeah, you go to the grocery store and they provide
Speaker 2: the prepared dough, the sauce, and the cheese. In the
Speaker 2: digital world, that's the physical infrastructure and the virtualized environment.
Speaker 1: Got it.
Speaker 2: But you still have to take it home, bake it yourself,
Speaker 2: and provide the dining table and drinks. So you are
Speaker 2: responsible for patching the operating system, managing network security, and
Speaker 2: most importantly, protecting the data.
Speaker 1: Okay, So then we move to platform as a service pass.
Speaker 1: This is pizza delivery. Yeah, they bake it, they bring
Speaker 1: it to your door in a cardboard box. They're managing
Speaker 1: the operating system in the middle, where you just provide
Speaker 1: the table and eat it. Right. And finally, software is
Speaker 1: a service sauce. This is dining out at a restaurant.
Speaker 1: Everything is done for you, the physical infrastructure of the cooking,
Speaker 1: the table, service doing the dishes.
Speaker 2: But and this is the critical part where that seventy
Speaker 2: seven percent of it leaders get it wrong. Even in
Speaker 2: a sauce model, even when you are dining at the restaurant,
Speaker 2: there is still a shared responsibility.
Speaker 1: Right because they just make the food.
Speaker 2: Exactly the restaurant provides a safe, clean environment and fully
Speaker 2: cooked food, but they are not responsible for how you
Speaker 2: consume it.
Speaker 1: Right, if you are dining out at a fancy sauce
Speaker 1: restaurant and you just inhale your food too fast and
Speaker 1: choke on it, you cannot sue the chef. It is
Speaker 1: not the restaurant's fault. Meaning, if you set your data
Speaker 1: access controls incorrectly, the cloud provider cannot save you.
Speaker 2: Think about all those massive headline making data breaches we
Speaker 2: see involving open Amazon s three buckets.
Speaker 1: Oh, there have been so many.
Speaker 2: Hundreds of millions of voters data exposed, auto tracking records,
Speaker 2: sensitive credit report. People read those headlines and think, wow,
Speaker 2: Amazon got hacked.
Speaker 1: So if they didn't, No, they didn't.
Speaker 2: Amazon's physical servers, they're biometric scanners, their slab to slab barriers,
Speaker 2: those all held up perfectly. Those breaches were customers choking
Speaker 2: on their own pizza, basically by leaving their data access
Speaker 2: controls wide open to the public Internet.
Speaker 1: So before we can even begin to protect our specific
Speaker 1: slice of responsibility, we have to identify who actually wants
Speaker 1: to attack it. We need to visualize our defenses. We
Speaker 1: are dealing with four main thread actors here.
Speaker 2: Yeah, four main categories.
Speaker 1: First, organized crime who just want financial game, then activists
Speaker 1: who are looking to disrupt your operations or discredit you
Speaker 1: for ideological reasons, insiders which are usually discardled employees after
Speaker 1: money or revenge. And finally state actors who are looking
Speaker 1: to steal national secrets, corporate intellectual property, or just cause
Speaker 1: major infrastructure disruptions.
Speaker 2: And to defend against all four of those groups, you
Speaker 2: have to employ what we call defense in depth, meaning
Speaker 2: layers right layering your security controls so that if one
Speaker 2: single layer fails, you aren't completely exposed. You don't just
Speaker 2: put one flimsy lock on the front door. You have
Speaker 2: heavy dead bolt, you have a motion sensor alarm, and
Speaker 2: you have a fireproof safe hidden inside.
Speaker 1: Makes sense to plan this.
Speaker 2: Out effectively, you actually need to map your architecture. You
Speaker 2: can literally just draw simple stick figures for your standard
Speaker 2: user and your administrator, and then draw boxes for your
Speaker 2: components like a web server, an application server, and a database.
Speaker 1: And then you draw these dotted lines around certain boxes
Speaker 1: to create what are called trust boundaries.
Speaker 2: Precisely, a trust boundary means that anything inside that dotted
Speaker 2: line automatically trusts other things inside that same line, okay,
Speaker 2: but anything crossing that dotted line from the outside requires
Speaker 2: strict verification. If an attacker manages to breach a trust boundary,
Speaker 2: you have to assume they will eventually control every single
Speaker 2: thing inside it. By forcing an attacker to cross multiple
Speaker 2: verified boundaries, you slow them down significantly.
Speaker 1: Let me play Devil's Advocate for a second year. If
Speaker 1: I'm listening to this and I run a small local business,
Speaker 1: maybe I have a niche scheduling app for local bakeries
Speaker 1: to manage their delivery drivers. Do I really need to
Speaker 1: spend time and money worrying about well funded nation state actors.
Speaker 1: It sounds like absolute overkill.
Speaker 2: That is a very common objection, and the answer really
Speaker 2: comes down to the core concept of risk management. Security
Speaker 2: is not about being terrified of everything all the time,
Speaker 2: you know. It's about evaluating the mathematical likelihood of an
Speaker 2: event versus its potential impact. So a state actor specifically
Speaker 2: targeting your local bakery scheduling app very low likelihood, right.
Speaker 1: So why Bob, if it's a practically zero percent chance,
Speaker 1: am I really supposed to defend against a ghost.
Speaker 2: Because the impact is still catastrophic and the method of
Speaker 2: attack doesn't care who you are. State actors and organized
Speaker 2: crime rings. They don't always target specific companies manually. They
Speaker 2: use bots exactly, use automated scripts that scan the entire
Speaker 2: Internet twenty four to seven looking for open doors. They
Speaker 2: don't know you're a bakery app. They just see an
Speaker 2: unlocked database. And if that database holds thousands of users
Speaker 2: personal emails, phone numbers, and maybe reuse passwords, the impact
Speaker 2: of that automated brooch could permanently bankrupt your business. When
Speaker 2: you identify a risk like that, you generally have four choices.
Speaker 1: Right the four strategies avoid, mitigate, transfer, or accept exactly.
Speaker 2: You can avoid the risk entirely by just turning the
Speaker 2: system off or not offering the feature, just don't do
Speaker 2: it right. You can mitigate the risk, maybe by choosing
Speaker 2: not to store sensitive personal data in the app in
Speaker 2: the first place. You can transfer the risk, which is
Speaker 2: what we do when we pay a cloud provider to
Speaker 2: handle the physical data center security of Potato exactly. Or finally,
Speaker 2: you can accept it, meaning you document that you know
Speaker 2: the vulnerability exists, you get the business stakeholders to formally
Speaker 2: agree to the danger, and you just move forward.
Speaker 1: Makes a lot of sense. You just have to know
Speaker 1: exactly what you're dealing with and what you're usually dealing with.
Speaker 1: Inside those trust boundaries is the actual prize, which is
Speaker 1: the data, the crown jewels. We have to categorize this
Speaker 1: data so we know what needs the heaviest protection. You
Speaker 1: can break it down simply into low, moderate, and high sensitivity.
Speaker 2: Yep, the three tiers.
Speaker 1: Low might be your server's public IP addresses, stuff that
Speaker 1: wouldn't ruin you if it leaked. Moderate could be routine
Speaker 1: internal financial info or basic personnel data. How is your
Speaker 1: trade secrets or customer financial data that is subject to
Speaker 1: strict compliance laws.
Speaker 2: And once you know what level of data you have,
Speaker 2: you have to understand how attackers view it. They look
Speaker 2: at your data through the lens of the CIA triad,
Speaker 2: which stands for confidentiality, integrity, and availability.
Speaker 1: Let's break that down. Confidentiality is the obvious one. They
Speaker 1: want to breach confidentiality to steal the data read the email, sale,
Speaker 1: the credit card numbers. But integrity is well, it's more subtle.
Speaker 2: Integrity is a unauthorized modification. An attacker breaches integrity when
Speaker 2: they secretly change the data. Oh like altering records right.
Speaker 1: Imagine an attacker getting into a bank's database. They don't
Speaker 1: need to steal the money directly if they can just
Speaker 1: add three zeros to their own account balance. Wow. Yeah,
Speaker 1: they've compromised the integrity of the data and the final piece,
Speaker 1: availability is exactly what it sounds like. Ransomware is the
Speaker 1: classic example here, locking you out Exactly the attacker encrypts
Speaker 1: your data so you can't use it, completely, destroying its
Speaker 1: availability until you pay up.
Speaker 2: So to protect this data while it's just sitting there
Speaker 2: on a server, protecting it at rest. Encryption is the
Speaker 2: ultimate buzzword, but there is a massive flaw in how
Speaker 2: people deploy encryption.
Speaker 1: There really is.
Speaker 2: You can have the strongest encryption algorithm in the world,
Speaker 2: but if you leave the encryption key sitting on the
Speaker 2: exact same server as the locked data, what's the point.
Speaker 2: It's literally like installing a Titanium vault door and then
Speaker 2: leaving the key under the doormat.
Speaker 1: Which is incredibly common unfortunately, and this is where key
Speaker 1: management services or kms come into play. Think about how
Speaker 1: a realtor shows a house. Imagine your highly sensitive data
Speaker 1: is a house.
Speaker 2: Okay, tracking to get into the house, you need the
Speaker 2: house key. In cryptography, this is called the data encryption
Speaker 2: key or DET. It directly unlocks the data.
Speaker 1: Got it.
Speaker 2: But you don't want to just leave the house key
Speaker 2: lying around under the mat, so your realtor puts it
Speaker 2: inside a sturdy metal lock box attached to the front door.
Speaker 1: Knob Oh, I see where this is going.
Speaker 2: To open that metal lock box, you need a specific code.
Speaker 2: That code is the key encryption key or key EK.
Speaker 2: And the overarching realtor service that generates and hands out
Speaker 2: those lockbox codes to approved agents that is your key
Speaker 2: management service, the KMS.
Speaker 1: Here's where it gets really interesting. Because of this lock
Speaker 1: box system, we get this concept called cryptographic erasure. Think
Speaker 1: about this. Practically destroying a massive multi terabyte database securely
Speaker 1: used to be a total nightmare rticck forever. You had
Speaker 1: to spend hour, sometimes days, having a computer overwrite the
Speaker 1: physical hard drives with random zeros and ones just to
Speaker 1: make sure the data was gone, but in the cloud.
Speaker 1: Because that multi terabyte database is locked by the house key,
Speaker 1: and the house key is logging the realtor's box. If
Speaker 1: you want to permanently destroy the data, you don't even
Speaker 1: have to.
Speaker 2: Touch the house, right You don't overwrite the terabytes of data.
Speaker 2: You just go to the cams and instantly destroy the
Speaker 2: tiny two hundred and fifty six bit lockbox CAD the
Speaker 2: key encryption key.
Speaker 1: That is wild.
Speaker 2: The second you press delete on that tiny string of text,
Speaker 2: that data encryption key inside the lock box is permanently trapped,
Speaker 2: and without that, those terabytes of data become an unreadable,
Speaker 2: mathematically unrecoverable bag of bits instantly forever.
Speaker 1: That is just incredible. The efficiency of that is wild.
Speaker 2: And what's really fascinating here is how the cloud has
Speaker 2: democratized this level of security. In the old days, to
Speaker 2: have that kind of robust key management, a company had
Speaker 2: to buy a physical piece of hardware called a hardware
Speaker 2: security module or HSM.
Speaker 1: Those were not cheap, not at all.
Speaker 2: These are incredibly expensive, tamper proof, military grade devices. If
Speaker 2: someone tries to pry one open, or change the temperature
Speaker 2: or even X ray it, the device senses the intrusion
Speaker 2: and physically wipes its own memory.
Speaker 1: Wow.
Speaker 2: Now, through multi tenant KMS systems provided by cloud platforms
Speaker 2: like AWS or Azure, even a small startup with a
Speaker 2: modi budget can leverage the power of an HSM under
Speaker 2: the hood. It has completely shifted the paradigm of data protection.
Speaker 1: Okay, so we've secured the data, we've locked it in
Speaker 1: a cryptographic lock box, but what about the millions of
Speaker 1: virtual containers and servers actually holding it. This is where
Speaker 1: we run into the absolute chaos of cloud asset management.
Speaker 2: Chaos is the right word for it, because.
Speaker 1: In the old on premise it days, if a developer
Speaker 1: wanted a server, it was a capital expenditure. They put
Speaker 1: in a formal request, finance approved it. It bought a
Speaker 1: physical box, racked it in a cold room, and put
Speaker 1: a little barcode inventory sticker on it.
Speaker 2: It took months, yep, lots of red tape.
Speaker 1: Now it's an operational expense. A developer with a corporate
Speaker 1: credit card can spin up a server in three seconds.
Speaker 2: Which leads to one of the biggest headaches for any
Speaker 2: security team. Shadow it unapproved, untracked digital infrastructure. And it's
Speaker 2: not just a billing problem where you're wasting money. It's
Speaker 2: a profound security nightmare.
Speaker 1: Because you can't protect what you don't know exists exactly.
Speaker 2: Every forgotten server is a ticking time bomb waiting to
Speaker 2: miss a critical security patch and be exploited. And you
Speaker 2: have to deeply understand what kind of assets your team
Speaker 2: is actually spinning up. Take a virtual.
Speaker 1: Machine for instance, okay, VMS.
Speaker 2: A VM is a digital computer that shares a physical
Speaker 2: host machine a hypervisor with other customers. Because you are
Speaker 2: sharing that physical hardware, you are potentially vulnerable to side
Speaker 2: channel attacks like the famous specter and meltdown vulnerabilities.
Speaker 1: Let's pause on that. Because side channel attack on a hypervisor,
Speaker 1: I mean that sounds like a mouthful. How does that
Speaker 1: actually work? In reality?
Speaker 2: It's essentially like living in an apartment building. You have
Speaker 2: your own locked room, your virtual machine, but you share
Speaker 2: the foundation, the plumbing, and the walls with other tenants.
Speaker 1: Okay, and that shared foundation is the hypervisor.
Speaker 2: Right. In a side channel attack, a malicious neighbor on
Speaker 2: that exact same physical server doesn't try to pick the
Speaker 2: lock on your door. Instead, they listen very very closely
Speaker 2: to how the computer's processor is vibrating or consuming power,
Speaker 2: essentially pressing a glass to the apartment wall.
Speaker 1: Wait, really just from power consumption.
Speaker 2: Yes. By monitoring those subtle physical changes, they can actually
Speaker 2: guess the passwords or cryptographic keys you are typing.
Speaker 1: Wow, Okay, so that's the danger of virtual machines. But
Speaker 1: what about containers. A container doesn't even use a full
Speaker 1: operating system. It just shares a kernel. It spins up
Speaker 1: to do a job, runs for an hour, and then
Speaker 1: completely deletes itself. If a developer is spinning up thousands
Speaker 1: of these ephemeral containers a day, how on earth do
Speaker 1: you track a ghost?
Speaker 2: That is the exact challenge. The answer is that you
Speaker 2: don't necessarily track the fleeting container itself. You inventory the
Speaker 2: container images, the blueprint, ah the blueprint, right. A native
Speaker 2: container is meant to be immutable. It doesn't get updated
Speaker 2: or patched while it's running. When a security patch is needed,
Speaker 2: the running container is destroyed and instantly replaced by a
Speaker 2: new container spun up from a freshly patched image blueprint.
Speaker 1: So you control the source material exactly.
Speaker 2: You control the blueprints. But to manage all of this effectively,
Speaker 2: you have to find where your asset management pipeline is leaking.
Speaker 1: Okay, let's play this out in a real world corporate
Speaker 1: scenario to see how these plumbing leaks actually happen. Picture
Speaker 1: a rogue developer who is tired of waiting for it
Speaker 1: approval for a new project. We all know one right,
Speaker 1: they pull out their corporate credit card, bypass the official
Speaker 1: channels and just spin up a brand new AWS environment.
Speaker 1: The security team doesn't even know it exists. That's our
Speaker 1: first leak, right.
Speaker 2: At the sort exactly. We call that a procurement leak.
Speaker 2: You have cloud expenditures happening outside of the security team's visibility.
Speaker 2: But let's say secure pready catches that. Then you run
Speaker 2: into processing leaks. This is where you see the eight
Speaker 2: of US bill. You know the cloud environment exists, but
Speaker 2: you forgot to actually enumerate and track the specific servers
Speaker 2: being spun up inside it. You're paying for a database,
Speaker 2: but it never made it onto your official inventory list, which.
Speaker 1: Naturally leads to the next failure tooling leaks. So let's
Speaker 1: say the service finally on your official inventory list. The
Speaker 1: IT team knows about it, but nobody remembered to plug
Speaker 1: that server's IP address into your automated security scanners. It's
Speaker 1: on the list, but it's sitting in the dark, completely
Speaker 1: unchecked for vulnerabilities.
Speaker 2: And then the final and arguably most frustrating failure findings leaks.
Speaker 1: Let me guess they find the problem and ignore it.
Speaker 2: Basically, the servers on the list the scanner knows about it.
Speaker 2: The scanner runs, finds a critical vulnerability, generates a bright
Speaker 2: red alert, and a human being ignores the alert or
Speaker 2: just gets lost in an overflowing inbox. To fix this
Speaker 2: entire chain of leaks, especially the processing ones, manual tracking
Speaker 2: is just possible. You have to use cloud native automation.
Speaker 2: You must enforce tagging.
Speaker 1: Tagging like putting a label on every single moving box
Speaker 1: in your house data class coal in, high environment, colan
Speaker 1: production department, colon.
Speaker 2: Finance exactly, and you automate it. If you have an
Speaker 2: automated policy that every single asset must have an environment
Speaker 2: tag and a data classification tag, you can run a
Speaker 2: simple script to find violations instantly.
Speaker 1: Oh that makes it so much easier, right.
Speaker 2: If a developer accidentally spins up a server with a
Speaker 2: high data class tag but a development environment tag, your
Speaker 2: automation can flag it or even automatically shut it down.
Speaker 2: You should never ever have highly sensitive real customer data
Speaker 2: sitting on a flimsy experimental development server.
Speaker 1: So we've mapped our data boundaries, We've locked the data
Speaker 1: in a cryptographic lock box. We've fixed the plumbing of
Speaker 1: our shadow I by automatically tagging our assets. We've done
Speaker 1: a lot, we have, but absolutely none of that matters
Speaker 1: if an attacker just walks right through the front door
Speaker 1: using stolen valid credentials, which brings to the final and
Speaker 1: maybe most crucial piece of the puzzle, identity and access management.
Speaker 2: I AM Identity truly is the ultimate perimeter in the cloud.
Speaker 2: Physical walls are gone. But before we build that perimeter,
Speaker 2: we have to clarify two terms that get hopelessly mixed
Speaker 2: up even by professionals, authentication and authorization.
Speaker 1: The military base analogy clarifies this perfectly. Imagine you drive
Speaker 1: up to the heavily fortified gait of a military base.
Speaker 1: You roll down your window and hand the guard your
Speaker 1: driver's license. Yep. The guard looks at the photo, looks
Speaker 1: at your face, and decides, yes, you are exactly who
Speaker 1: you say you are. That is authentication. It is simply
Speaker 1: establishing your identity. Correct.
Speaker 2: But just because the guard knows exactly who you are
Speaker 2: doesn't mean you actually get to drive into the base.
Speaker 2: Authentication is not enough, right. The guard then turns around,
Speaker 2: checks a clipboard and looks to see if your verified
Speaker 2: name is on the approved visitor list and specifically which
Speaker 2: buildings you are allowed to enter today. That is authorization.
Speaker 2: It is establishing your ax t us who you are
Speaker 2: versus what you are permitted.
Speaker 1: To do, and managing that relies on the IAM life cycle. Request, approve, create, use, revalidate,
Speaker 1: and revoke and revoke is where organizations fail spectacularly.
Speaker 2: Oh absolutely.
Speaker 1: Let's look at a real world in nightmare scenario. Let's
Speaker 1: say you fire a highly privileged systems administrator on premise.
Speaker 1: This is easy. You deactivate their physical key card, you
Speaker 1: walk them out of the building. Maybe you forget to
Speaker 1: delete their server account right away, but it doesn't matter
Speaker 1: because they physically cannot get to a computer.
Speaker 2: Right They're physically blocked.
Speaker 1: But in the cloud they can access your entire infrastructure
Speaker 1: portal from their couch. If you forget to explicitly revoke
Speaker 1: their access, they are still a god in your system, and.
Speaker 2: It is actually much deeper and more dangerous than just
Speaker 2: disabling a log in page. In the cloud, many services
Speaker 2: use what are called long lived access token.
Speaker 1: Cooking's right.
Speaker 2: Think about how Gmail works on your phone. When you
Speaker 2: log into your laptop and change your Google password, your
Speaker 2: phone's email app doesn't instantly stop working and force you
Speaker 2: to type the new password.
Speaker 1: Ray, No, it just keeps working, it keeps sinking.
Speaker 2: That's because the phone relies on a token, a digital
Speaker 2: cookie that says, hey, I was already authenticated. If your
Speaker 2: security system doesn't explicitly hunt down and revoke all active
Speaker 2: tokens when someone is off boarded, that fired administrator might
Speaker 2: still have active API keys or browser sessions that completely
Speaker 2: bypass the login screen, so they don't.
Speaker 1: Even need a password to get back in. Exactly, that
Speaker 1: is legitimately terrifying. How do you even begin to manage
Speaker 1: that without losing your mind?
Speaker 2: You manage it by minimizing the number of distinct identity
Speaker 2: systems you have to watch over. The absolute best practice
Speaker 2: is leveraging single sign on or SSO provided by a
Speaker 2: major cloud.
Speaker 1: Provider, centralizing it.
Speaker 2: Think about it. You've already paid the fee of trusting
Speaker 2: Microsoft or Amazon or Google with your underlying infrastructure. Why
Speaker 2: introduce a massive new vulnerability by trying to build your
Speaker 2: own custom, likely flawed password data. Use their robust, highly
Speaker 2: funded IAM tools to manage your identities in one centralized place, and.
Speaker 1: For the love of everything, turn on multi factor authentication MFA.
Speaker 2: Absolutely non negotiable. MFA relies on combining different categories of
Speaker 2: evidence something you know, like a password, something you have
Speaker 2: like a smartphone app generating a code or a physical
Speaker 2: hardware token, right, And something you are like a fingerprint
Speaker 2: or facial biometric. By requiring just two of these, which
Speaker 2: is barely a two second inconvenience for the user, you
Speaker 2: instantly render Stolling passwords completely useless. Even if an attacker
Speaker 2: guesses your password, they don't have your physical phone so
Speaker 2: they can't get in.
Speaker 1: Wow. Okay, let's take a breath and synthesize this journey.
Speaker 1: We started by ordering pizza as a service to visualize
Speaker 1: our shared responsibilities, learning that we can never ever outsource
Speaker 1: the responsibility of our data access controls.
Speaker 2: Right, the chef isn't responsible if you choke.
Speaker 1: Exactly. Yeah. We du stick figures to map out our
Speaker 1: trust boundaries against automated scripts and state actors.
Speaker 2: We locked our high value data inside a cryptographic lock DOCS,
Speaker 2: utilizing the incredible power of key management services to perform
Speaker 2: instant cryptographic erasure without ever touching the hard drives.
Speaker 1: We track down our plumbing leaks, realizing we have to
Speaker 1: manage the blueprints of automated containers and enforce strict tagging,
Speaker 1: so a road developer's shadow, it doesn't sneak up on us.
Speaker 2: No more unlabeled boxes.
Speaker 1: And finally we established that identity is the new perimeter,
Speaker 1: relying on centralized SSO and MFA to ensure the front
Speaker 1: door is heavily guarded.
Speaker 2: It all comes down to recognizing a fundamental shift. The
Speaker 2: cloud removes the physical safety nets we used to rely on.
Speaker 2: Security is no longer about pouring thicker concrete walls. It's
Speaker 2: about rigorous logical controls.
Speaker 1: Which leaves us with a final provocative thought for you
Speaker 1: to chew on. In a cloud first world, physical walls
Speaker 1: are completely, one hundred percent gone completely, Identity is the
Speaker 1: only true perimeter life left. Think about the profound implication
Speaker 1: of that. If an attacker guesses your password and logs
Speaker 1: into your cloud environment, they aren't actually breaking in in
Speaker 1: the traditional sense. No they're not. No alarms go off,
Speaker 1: no doors are smashed. They were simply logging in. The
Speaker 1: system is doing exactly what it was mathematically designed to do,
Speaker 1: granting access to a verified identity. So take a hard
Speaker 1: look at your own digital shadow today. What forgotten cloud assets,
Speaker 1: outdated environment tags, or long lived access tokens? Do you
Speaker 1: have lingering in the background right now.
Speaker 2: Because while you might feel perfectly safe sitting in the
Speaker 2: lobby of your luxury high rise.
Speaker 1: It's time to ask yourself, did you remember to lock
Speaker 1: your own front door?
Speaker 2: A vital question to ask in this ever shifting landscape.
Speaker 1: Thanks for joining us on this deep dive into cloud security.
Speaker 1: Keep questioning your assumptions, keep locking those digital doors, and
Speaker 1: we will catch you next time.