Speaker 1: Welcome to the deep dive. Today. We're really getting into
Speaker 1: the weeds of cloud penetration testing.
Speaker 2: Yeah, we're using Kim Crawley's book Cloud Penetration Testing for
Speaker 2: Red Teamers as our guide.
Speaker 1: Right, and the idea is to pull out the key stuff.
Speaker 1: You know how security pros actually test places like Aws, Azure, GCP,
Speaker 1: find the holes.
Speaker 2: Make things stronger, and we want to get you the
Speaker 2: core insights those sort of aha moments about cloud security.
Speaker 1: Testing exactly Crawley's book. It's pretty thorough good for experienced
Speaker 1: folks moving to cloud, but also if you're just starting out.
Speaker 2: It really maps out the tools the methods for each
Speaker 2: big cloud player because they are different.
Speaker 1: And for you listening, maybe you're prepping for a meeting,
Speaker 1: trying to get your head around this, or just curious.
Speaker 1: We're aiming to cut through the noise.
Speaker 2: We'll focus on like the big shift from old school
Speaker 2: pen testing to.
Speaker 1: Cloud, that shared responsibility thing. Definitely need to cover that.
Speaker 2: Oh yeah, and the kinds of attacks you see, the
Speaker 2: defenses that work.
Speaker 1: Without drowning you in Jurgen, just the actionable stuff. Okay,
Speaker 1: let's get started.
Speaker 2: So foundational point cloud platforms are well basically everywhere. Now.
Speaker 2: AWS kicked it off, what two thousand and six.
Speaker 1: Yeah, and then Azure GCP around two thousand and eight.
Speaker 1: Now most big companies use at least one, often more.
Speaker 2: It's easy to see why. Right. The scalability is huge.
Speaker 1: Oh, absolutely, spin up resources, spin them down, No need
Speaker 1: to build your own massive data centers.
Speaker 2: Think about services like Netflix or Dropbox. They couldn't exist
Speaker 2: like they do without the clouds flexibility.
Speaker 1: It really enables that kind of business agility.
Speaker 2: And it's not just using the cloud, it's how they're
Speaker 2: using it. You've got companies that are all in everything's.
Speaker 1: Cloud, right, the all cloud approach.
Speaker 2: Then there's hybrid mix of their own servers in cloud,
Speaker 2: maybe for compliance reasons or old systems they can't move easily.
Speaker 1: Makes sense. And then the other one you mentioned multi cloud, Yeah.
Speaker 2: Using services from say both AWS and Azure, maybe GCP too.
Speaker 1: Okay, that sounds complicated. Why add that layer?
Speaker 2: Good question. Sometimes one provider just has a killer service
Speaker 2: the others don't like. Maybe one's way ahead on AI tools.
Speaker 1: Ah, okay, best of breed for specific tasks exactly, Or
Speaker 1: maybe it's about not being locked into one vendor gives
Speaker 1: you more leverage, redundancy too.
Speaker 2: Right, avoiding that vendor lock in. Okay, so that maps
Speaker 2: out the landscape. Let's switch gears to security. This shared
Speaker 2: responsibility model feels like ground zero for understanding cloud security.
Speaker 1: It absolutely is. It's the framework defining who handles what.
Speaker 1: The basic idea the cloud provider Amazon, Microsoft, Google. They
Speaker 1: secure the underlying infrastructure.
Speaker 2: The physical buildings, the core network, that sort of thing.
Speaker 1: Yeah, security of the cloud itself, but this is non
Speaker 1: negotiable the customer.
Speaker 2: So your company, you're always responsible for your data period.
Speaker 1: Always, no matter what service you use. Where it gets
Speaker 1: nuanced is the other stuff, the apps, the network settings,
Speaker 1: inside your cloud environment, the operating systems, and.
Speaker 2: That changes based on whether it's iass, poly ass or
Speaker 2: sauce right infrastructure platform or software as a service.
Speaker 1: Precisely, the lines shift depending on that model.
Speaker 2: Okay, let's get specific, Like the book does, how does
Speaker 2: Azure break it down? People might assume it's the same everywhere. Well,
Speaker 2: with Azure, you're responsible for your info, your data obviously,
Speaker 2: also the devices people use to connecting the user accounts. Okay,
Speaker 2: Azure handles the physical hosts, the network, the data center security,
Speaker 2: but things like identity applications, network controls OS. That depends
Speaker 2: if it's PANS, we ouris.
Speaker 1: Got it and GCP. How do they draw the lines.
Speaker 2: GCP says you're always responsible for your content and your
Speaker 2: access policies. That's true across size pans.
Speaker 1: IGAs okay, consistent there.
Speaker 2: If you use PANS on GCP, you also take on
Speaker 2: responsibility for how you use it, deploy it and secure
Speaker 2: your web apps running on it. Go to ISS and
Speaker 2: you add even more identity management your operational stuff, access control,
Speaker 2: network security can fig the actual guest os and the
Speaker 2: data itself.
Speaker 1: So you're managing a lot more at the level what's
Speaker 1: left for GCP.
Speaker 2: Then GCP handles things like audit logging for their infrastructure,
Speaker 2: their network security, data encryption, the hard and NOS kernels
Speaker 2: they use secure boot the physical hardware.
Speaker 1: It really highlights that you need to know the specifics
Speaker 1: for your provider and your serf ball. You can't just.
Speaker 2: Guess absolutely not, and that leads right into actually testing
Speaker 2: the security. You can't just go wild ah the.
Speaker 1: Pen testing policies right. Each provider has rules and you.
Speaker 2: Have to follow them. It doesn't matter what your boss wants,
Speaker 2: you play by their rules. It's their playground essentially.
Speaker 1: Okay, so give us the rundown. What are the big
Speaker 1: dos and don'ts for AWS?
Speaker 2: With AWS, generally, you can pentist most services without asking first.
Speaker 1: Okay, that's fairly open.
Speaker 2: But big restrictions. No missing with root fifty three DNS,
Speaker 2: zone walking, hijacking, no DUFTA or DDOST attacks, mostly no
Speaker 2: protocol flooding.
Speaker 1: Right, don't break things for other customers.
Speaker 2: Exactly, And if you want to use things like command
Speaker 2: and control servers or network stress tools like IPER, or
Speaker 2: run phishing simulations or test malware, you need to get
Speaker 2: explicit permission first.
Speaker 1: Gotcha approval needed for the more aggressive stuff. What about
Speaker 1: Azure and the Microsoft Cloud?
Speaker 2: Microsoft's also pretty open. Most pen testing is okay without
Speaker 2: prior notice.
Speaker 1: But again there are lines.
Speaker 2: Oh yeah, Crucially, don't test anyone else's stuff. Only your
Speaker 2: own assets and data. No massive floods of automated traffic,
Speaker 2: no dusty dass standard stuff. Network fuzzing is okay, but
Speaker 2: only against your own vms. And if you find an
Speaker 2: infrastructure issue, just show a proof of concept, don't exploit
Speaker 2: it further, and definitely no trying to social engineer or
Speaker 2: Microsoft staff.
Speaker 1: Right, common sense really and g.
Speaker 2: GCP allows pen testing without notification, but you have to
Speaker 2: stick to their acceptable use policy and terms of service,
Speaker 2: which means no disrupting other customers, So no d doo ass,
Speaker 2: no malware spreading, no trying to access other people's projects,
Speaker 2: and obviously nothing illegal. You can do vulnerability scanning within
Speaker 2: your own projects, but you need your company's written permission first.
Speaker 1: So the takeaway is know the rules for the specific
Speaker 1: cloud you're testing. You're a guest in their house in
Speaker 1: a way.
Speaker 2: A guest with responsibilities. Now understanding those boundaries, let's talk
Speaker 2: about how attackers actually come after these cloud setups.
Speaker 1: Right where did the attacks usually start?
Speaker 2: You can broadly think about external versus internal attacks. External
Speaker 2: gets the headlines, you know, the hacker and a hoodie stereotype,
Speaker 2: but internal attacks leveraging someone already inside, someone trusted, those
Speaker 2: can be really damaging and harder to spot.
Speaker 1: The book had that kind of chilling example, the janitor
Speaker 1: with a USB stick.
Speaker 2: Yeah, it illustrates the insider risk perfectly. Imagine a janitor
Speaker 2: has legitimate access to the server room, not an impostor
Speaker 2: a real employee doing their job. Because they have that
Speaker 2: trusted physical access, they could theoretically plug in a USB
Speaker 2: drive with malware into a.
Speaker 1: Server bypassing all the external firewalls defenses.
Speaker 2: Completely, and suddenly that server could infect all the client
Speaker 2: machines it manages. Shows how exploiting trust can be a
Speaker 2: powerful attack vector.
Speaker 1: That's a really stark reminder. So besides physical access like that,
Speaker 1: what are the more common digital entry points the attack vectors.
Speaker 2: Often it's vulnerabilities and web applications facing the Internet or
Speaker 2: open ports that.
Speaker 1: Shouldn't be misconfigurations exactly.
Speaker 2: Or attackers might go after accounts trying to crack passwords
Speaker 2: or fish credentials, especially for accounts with high privileges.
Speaker 1: Gain a legitimate log in from their perspective right.
Speaker 2: And sometimes, though maybe less common, it's bribing or coercing
Speaker 2: an actual insider to help them get access or plant something.
Speaker 1: Okay, so they get in, what are they trying to
Speaker 1: do once they're inside? What's the goal?
Speaker 2: Most attacks boiled down to hitting one or more aspects
Speaker 2: of the CIA triad Confidentiality, integrity, availability.
Speaker 1: Right, the classic security principles, So confidentiality first, keeping secret secret.
Speaker 2: Pretty much preventing unauthorized access to sense in seative data.
Speaker 2: A data breach is a direct hit on confidentiality.
Speaker 1: The book mentioned the DC health Link breach from March
Speaker 1: twenty twenty three. What happened there?
Speaker 2: Yeah, DC health Link handles insurance for government folks. They
Speaker 2: reported that data for like fifty six thousand customers was
Speaker 2: exposed names, social security numbers, health plan info, really sensitive.
Speaker 1: Stuff, ouch and the likely cause. In a cloud.
Speaker 2: Context, the book suggests data from cloud storage based on
Speaker 2: the IATT and CK framework, which we should talk more
Speaker 2: about later. Basically, data stored in the cloud wasn't properly secured.
Speaker 1: A major confidentiality failure with real consequences. Okay, what about integrity?
Speaker 2: Integrity is about preventing unauthorized changes to data, making sure
Speaker 2: data is accurate and trustworthy.
Speaker 1: So a tax might involve what.
Speaker 2: Things like injecting malicious code into a website or database,
Speaker 2: or man in the middle attacks where they intercept and
Speaker 2: alter data as it travels. Stealing TLS certificates could also
Speaker 2: let them impersonate a legit service sing within integrity.
Speaker 1: Right, corrupting the data or the process. And the last
Speaker 1: one availability, Availability.
Speaker 2: Is just making sure authorized users can actually access the
Speaker 2: data and services when they need to.
Speaker 1: So denial of service attacks fit here exactly.
Speaker 2: DTOs distributed denial of service is the classic example, overwhelm
Speaker 2: the server with so much junk traffic that legitimate users
Speaker 2: can't get through.
Speaker 1: The book mentioned a huge one against a Google Cloud customer.
Speaker 2: Yeah, August twenty twenty two peaked at something crazy like
Speaker 2: forty six million requests per second an HTTPS d DOOS attack.
Speaker 1: Wow did it work?
Speaker 2: Fortunately, Google Cloud Armor, their protection service, managed to block it.
Speaker 2: But it shows the scale of threats trying to knock
Speaker 2: services offline.
Speaker 1: So attackers are constantly probing for ways to break confidentiality, integrity,
Speaker 1: or availability. Now, say they succeed in getting that initial foothold,
Speaker 1: what happens next? They don't just sit.
Speaker 2: There, No, rarely, that's where lateral movement comes in. Once
Speaker 2: they're inside, the goal is usually to move deeper, find
Speaker 2: more valvaluable targets.
Speaker 1: How does that work in the cloud?
Speaker 2: They might try to jump from one compromise service to
Speaker 2: another within the same cloud account, say from a web
Speaker 2: server to a database, or in a multi cloud setup,
Speaker 2: maybe pivot from Aws to Azure if there's a.
Speaker 1: Connection, trying to escalate privileges or find sensitive data stores exactly.
Speaker 2: Find accounts with more power access, more systems spread their control.
Speaker 1: That sounds really dangerous moving silently inside the perimeter. How
Speaker 1: do you defend against that kind of internal spread?
Speaker 2: This is really where the zero trust model shines. The
Speaker 2: old way was perimeter security, build a strong wall, assume
Speaker 2: everything inside is safe.
Speaker 1: The castle and mote approach right.
Speaker 2: Zero trust throws that out. It assumes no user or
Speaker 2: device is inherently trustworthy, even if it's already inside the.
Speaker 1: Network, So you verify everything all the time.
Speaker 2: Pretty much every request to access a resource gets checked
Speaker 2: for authentication and authorization continuously. It doesn't matter if you're
Speaker 2: coming from outside or supposedly inside.
Speaker 1: That must make it much harder for an attacker to
Speaker 1: just wander around after getting in.
Speaker 2: It does. They might compromise one thing, maybe steal some
Speaker 2: initial credentials, but to move laterally they have to keep
Speaker 2: passing these checks, keep reauthenticating and proving their allowed access
Speaker 2: to the next thing.
Speaker 1: More hurdles, more chances to get caught significantly more.
Speaker 2: It prevents a small breach from easily becoming a full
Speaker 2: network compromise.
Speaker 1: Okay, that makes sense, so we understand the threats the
Speaker 1: defenses like zero trust. Let's get back to the testing part.
Speaker 1: What are the core concepts pen testers need for the cloud?
Speaker 2: Well, first things first, before you launch any tools, you
Speaker 2: need a solid vulnerability assessment.
Speaker 1: Understanding the target.
Speaker 2: Yeah, mapping out what's there, what services are running, what's exposed,
Speaker 2: defining the scope, what are you actually testing and what's
Speaker 2: off limits? You need that clear picture.
Speaker 1: The book emphasizes the ININTI att and SK framework. You
Speaker 1: mentioned it briefly. Why is it so important for pen testers,
Speaker 1: especially red teams?
Speaker 2: Minor? ATT and CK is basically a massive, organized library
Speaker 2: of attacker tactics and techniques. It breaks down how real
Speaker 2: world cyber attacks happen, step by step.
Speaker 1: Like a playbook of bad guy moves.
Speaker 2: Kind of yeah. It gives everyone a common language. For
Speaker 2: red teams trying to simulate real attackers. Its gold. They
Speaker 2: can use ATT and CK to model their tests after
Speaker 2: specific threat groups or known attack patterns. Makes the simulation
Speaker 2: much more realistic.
Speaker 1: Very useful resource. What about cloud integrations systems talking to
Speaker 1: each other?
Speaker 2: Huge area. Most organizations connect different cloud services or link
Speaker 2: their on prem stuff to the cloud, and.
Speaker 1: The connections themselves can be weak points.
Speaker 2: Absolutely Often these connections use API's application programming interfaces. If
Speaker 2: those APIs aren't secured properly, they become a major vulnerability.
Speaker 2: They can be vulnerable to injection attacks like feeding the
Speaker 2: malicious commands, or they might have weak access controls, letting
Speaker 2: an attack, or do things they shouldn't. Testing these APIs is.
Speaker 1: Critical, so don't just test the services, test how they
Speaker 1: talk to each other. The book also talks about vulnerability
Speaker 1: databases like CVE right.
Speaker 2: CVE stands for Common Vulnerabilities and Exposures. It's a public
Speaker 2: list of known security flaws in software and hardware, so.
Speaker 1: If you find something, you can check if it's already
Speaker 1: known exactly.
Speaker 2: Each known vulnerability gets a unique ID like CVE twenty
Speaker 2: twenty three something something helps everyone track the same issue.
Speaker 1: And those CVSS.
Speaker 2: Scores CVSS Common Vulnerability scoring System. It's a way to
Speaker 2: rate how severe vulnerability is. Goes from point zero to ten.
Speaker 2: Point zero, higher is worse, much worse. Yeah, gives you
Speaker 2: a quick idea of how critical it is to fix.
Speaker 2: You often find CVE details and CVSS scores on the
Speaker 2: NIST National Vulnerability Database the NVD.
Speaker 1: Okay, so CVE identifies it, CVSS ranks its severity. Helpful
Speaker 1: context for a pen tester what about purple teaming? That
Speaker 1: sounds colorful.
Speaker 2: Huh Yeah, So usually have a red team the attackers
Speaker 2: the pen testers, and a blue team that defenders the
Speaker 2: security operations center.
Speaker 1: Folks, offensive ver's defensive.
Speaker 2: Right teaming is when they work together. Instead of the
Speaker 2: red team trying to be sneaky and the blue team
Speaker 2: trying to catch them, they collaborate during the test.
Speaker 1: How does that help?
Speaker 2: The red team finds vulnerability, they immediately share it with
Speaker 2: the blue team. The blue team can then test their
Speaker 2: detection and response in real time. It speeds up the
Speaker 2: feedback loop improves both offense and defense much faster.
Speaker 1: More collaborative, less adversarial. Makes sense. Yeah, And finally, the
Speaker 1: pentist report. Why is that so important?
Speaker 2: The report is the whole point. Really, it's the formal
Speaker 2: ride up of everything The pendester found.
Speaker 1: A list of problems.
Speaker 2: Oh no, much more. It details the vulnerabilities, explains the
Speaker 2: impact what could actually happen if an attack or exploited this,
Speaker 2: and crucially, it gives clear recommendations on how to fix things.
Speaker 1: So it's the roadmap for improvement exactly.
Speaker 2: It needs to be clear enough for managers to understand
Speaker 2: the risk and technical enough for the security team to
Speaker 2: actually implement the fixes. It's a critical communication tool.
Speaker 1: Okay, concepts covered, let's talk tools. The book lists quite
Speaker 1: a few. Can you give us some examples for say,
Speaker 1: AWS Sure On.
Speaker 2: The AWS side, there's AWS Security Hub. It's not exactly
Speaker 2: a pen testing tool, but it pulls together findings from
Speaker 2: aus's own security services i AM Access Analyzer, Guard Duty
Speaker 2: inspector MACY.
Speaker 1: Still like a dashboard for AWS security posture.
Speaker 2: Yeah, a good starting point to see what AWS itself
Speaker 2: is flagging. For more active scanning, Prowler is really popular.
Speaker 2: Prowler Yeah, open source. It scans AWS but also Azure
Speaker 2: and GCP looking for misconfigurations, hardening checks, following benchmarks like CIS.
Speaker 2: You can run it easily, install via pip or Docker.
Speaker 1: Multi cloud capable, nice, any others for AWS.
Speaker 2: Puku is another well known open source framework specifically for
Speaker 2: AWS pen testing. Again, installable via pip.
Speaker 1: So Prowler for broader checks, Pakuo for more focused AWS exploitation.
Speaker 2: Kind of yeah. Then you have simpler tools like cred scanner,
Speaker 2: just a Python script to hunt for exposed credentials line around.
Speaker 1: In files oooh finding those accidental secrets.
Speaker 2: Exactly, and cloud Front, which focuses specifically on finding misconfigurations
Speaker 2: in AWS cloud Front their CDN service.
Speaker 1: Okay, good examples for AWS. What about Azure or GCP
Speaker 1: For Azure?
Speaker 2: The book mentions MFA swoop it checks if multi factor
Speaker 2: authentication is enabled to cross different Azure services. Basic but
Speaker 2: really important.
Speaker 1: Can't stress MFA enough right.
Speaker 2: Scout Suite is another multi cloud tool like prowler. It
Speaker 2: audits AWS, Azure, and GCP, pulling config data and highlighting risks.
Speaker 1: Good forgetting that cross cloud view. What about containers? Docker
Speaker 1: Kubernetes are huge now?
Speaker 2: Definitely Trevia has mentioned it's a scanner for container images
Speaker 2: looking for known vulnerabilities. Works for Docker, Kubernetes images and
Speaker 2: other things.
Speaker 1: Too important for supply chain security.
Speaker 2: Absolutely for Kubernetes specifically, there's tools like cube hunter and
Speaker 2: Digger designed to probe Kubernetes clusters for security weaknesses.
Speaker 1: And GCP specific tools.
Speaker 2: Yeah, things like GCP bucket Brute for checking Google Cloud
Speaker 2: Storage bucket permissions and GCP Scanner for looking at credential
Speaker 2: access levels within a GCP project.
Speaker 1: Wow. Quite the toolkit seems like there's a tool for
Speaker 1: almost everything.
Speaker 2: There often is, but knowing how and when to use
Speaker 2: them effectively and how to interpret the results.
Speaker 1: That's the key skill right now, Let's quickly loop back
Speaker 1: to those service models, ISS, PASSSAS and how security differs.
Speaker 1: We touched on it with shared responsibility.
Speaker 2: Yeah, it's worth recapping. With SAS, think Gmail salesforce. The
Speaker 2: provider handles almost all the security. Your main job is
Speaker 2: managing your data within the app and user access. Pen
Speaker 2: testing SAS is often very restricted by the provider.
Speaker 1: Makes sense. You don't own the underlying app or infra.
Speaker 1: What about PASS.
Speaker 2: Platform is a service Here, the provider gives you the platform,
Speaker 2: maybe a database service or a Kubernetes environment like aws EKS.
Speaker 2: You build your apps on.
Speaker 1: It, so you secure your app. They secure the platform mostly.
Speaker 2: Yeah, you're responsible for your application code, it's configuration, how
Speaker 2: it uses the platform services. They handle the OA patching
Speaker 2: underneath the platform, resilience, etc. Pen testing focuses on your
Speaker 2: application and its interaction with the PASS Okay and I
Speaker 2: infrastructure as a service. That's where you have the most
Speaker 2: control and therefore the most responsibility. You get virtual machines,
Speaker 2: storage networking.
Speaker 1: Like renting the hardware.
Speaker 2: Essentially pretty much, you manage the operating system, patching it
Speaker 2: installing software, configuring firewalls within your virtual network, securing your
Speaker 2: data on those vms. The provider just secures the physical
Speaker 2: data center and the virtualization layer.
Speaker 1: So is pen testing looks more like traditional network pen
Speaker 1: testing closer?
Speaker 2: Yes, but you still need to understand the cloud provider
Speaker 2: specific services and control plane because that's part of your
Speaker 2: attack surface too, got it?
Speaker 1: And across all these zero trust remains.
Speaker 2: The best approach, definitely, because that perimeter is so blurry
Speaker 2: or non existent in the cloud. Assuming zero trust and
Speaker 2: verifying everything is the way to go, regardless of IAS,
Speaker 2: pass or sauce elements.
Speaker 1: And the book also brought up RBAC again, role based
Speaker 1: access control. Why is that fundamental?
Speaker 2: RBAC is how you manage who can do what in
Speaker 2: the cloud. Instead of giving permissions to individual users, you
Speaker 2: create roles like database admin or.
Speaker 1: Web developer and assigned permissions to.
Speaker 2: The roles exactly. Then you assign users to those roles.
Speaker 2: It's much cleaner, easier to manage, especially at scale, and
Speaker 2: it enforces the principle of least privilege poll LP. Giving
Speaker 2: users only the minimum permissions they absolutely need to do
Speaker 2: their job nothing more. Reduces the potential damage if an
Speaker 2: account gets compromised. RBAC is also native to Kubernetes, making
Speaker 2: it vital there too.
Speaker 1: Okay, this has been a really comprehensive look at cloud
Speaker 1: pen testing. If you had to boil it down, what
Speaker 1: are the absolute key takeaways for our listener?
Speaker 2: I'd say one, cloud pen testing is different and essential. Two,
Speaker 2: you must understand the shared responsibility model for your specific services.
Speaker 1: It's not just someone else's computer, not at all.
Speaker 2: Three the threats are real and varied, so continuous learning
Speaker 2: and using the right tools like those mentioned is crucial.
Speaker 2: And four always follow the cloud provider's rules of engagement
Speaker 2: for testing.
Speaker 1: And maybe the big aha moment is that the cloud
Speaker 1: shift doesn't mean less security work for your organization, just
Speaker 1: different security work and proactive testing is key.
Speaker 2: Precisely you have significant responsibilities. Effective pen testing helps you meet.
Speaker 1: Them, and as people listen, maybe they should think about
Speaker 1: their own setup, Like if they're multi cloud, yeah.
Speaker 2: Consider how does that complexity impact your security visibility? Can
Speaker 2: you manage zero trust effectively across different clouds or in
Speaker 2: a hybrid setup? These are tough but important questions.
Speaker 1: Absolutely well. That brings us towards the end of this
Speaker 1: deep dive. We've gone from the basics of cloud platforms
Speaker 1: to shared responsibilities, attack methods, core pen testing concepts, tools
Speaker 1: and models.
Speaker 2: Wellpe, it's given you the listener a much clearer picture
Speaker 2: of what cloud security testing involves, hopefully a solid base
Speaker 2: to build on, and an idea of what's critical for
Speaker 2: organizations using the cloud.
Speaker 1: Definitely, and we encourage you to dig deeper. Check out
Speaker 1: the umber eat t TCK framework online. Look up the
Speaker 1: security docs for AWS, Azure GCP. They have tons of information.
Speaker 2: Think about your company's cloud services, how does this apply?
Speaker 2: Which tools might be worth exploring for your specific needs?
Speaker 1: And may be a final thought to leave you with.
Speaker 2: With things like serverlests and containers becoming even more dominant,
Speaker 2: how is cloud pintesting going to change next? What new
Speaker 2: skills new tools will security pros need and say the
Speaker 2: next five years?
Speaker 1: Hmm, always evolving, something to definitely keep an eye on.
Speaker 1: Thanks for joining us on this deep dive.
Speaker 2: Yeah, thanks for listening. Until next time,