Zapier Breach Lessons For Cloud Security and Setting Up TPRM Program in 15 Minutes

The breach that takes down a company often does not kick in the front door. It walks in through a “simple” integration you set up months ago, powered by a token no one remembered to rotate. We start with a real-world Zapier-style scenario and unpack how researchers chained together a harmless-looking code block, an AWS Lambda environment, and a misconfigured IAM role to reach private repository files and ultimately an NPM token that could enable a supply chain attack.

From there, we zoom out to the bigger cloud security problem: non-human identities. Service accounts, API keys, and OAuth tokens multiply fast, and they are frequently overprivileged, poorly tracked, and left active long after an integration is retired. We also talk about why SaaS-to-SaaS connections are so hard to secure, and why agentic AI makes visibility even more urgent. If you do not know what systems are connected, what data crosses those links, and who owns the risk, you are effectively trusting an invisible tunnel into your environment.

To make this actionable, we lay out a four-phase third-party risk management (TPRM) framework you can apply immediately: build a vendor and integration inventory with tiering, run real due diligence (SOC 2 Type II, ISO 27001, data access scope, subprocessors and fourth parties), lock protections into contracts (DPA language, right to audit, breach notification expectations), then enforce ongoing monitoring and governance with quarterly token reviews, logging, and incident response playbooks. If you are studying for the CISSP, you will also see exactly how this maps to Domain 1, Domain 3, Domain 4, and Domain 5.

Subscribe for more practical CISSP training, share this with a teammate who owns vendor approvals, and leave a review so more security pros can find it. What is the one integration you would audit first?

Gain exclusive access to 360 FREE CISSP Practice Questions at FreeCISSPQuestions.com and have them delivered directly to your inbox!  Don’t miss this valuable opportunity to strengthen your CISSP exam preparation and boost your chances of certification success.

Join now and start your journey toward CISSP mastery today!

TRANSCRIPT

SPEAKER_00 0:00 

Welcome to the CISSP Cybertraining Podcast. Where we provide you the training and tools you need at the CSSP exam first. Hi, my name is Sean Gerber. I'm your host of the Action Packing Format Podcast. Join me each week as I provide the information you need at the CISSP exam and grow your cyber security knowledge. Alright, let's get started.

SPEAKER_01 0:25 

Hey all Sean Gerber with CISSP Cyber Trading, and hope you all are having a beautifully blessed day today. Today is Thursday, and today we're going to be getting into a couple different items. One is going to be related to an article that I saw around complex cloud integrations and how small errors can lead to major compromises. And we've talked about this numerous times on the podcast, but we're going to kind of get in an article that will bring it to life. In top of that, after that, we're going to be talking about third-party risk management. And I've got just about a 15-minute little overview of that with some slides that you, if you go to CISSP cyber training, you can get access to the slides as well. And all of that is available to you. So third party risk management is a key part of the CISSP exam. And rather than just kind of going over questions, we're going to go over some key concepts related to third-party risk management. So one of the things you're going to talk about here, let's get in this

The Zapier Attack Chain Explained

SPEAKER_01 1:22 

article. And this is an article around, again, complex cloud integrations and how these breaches could take down your company. The breach that's going to take down your company, it's not going to come through the firewall. No, it's going to walk right in through a zapier integration. Yeah, and I'm not kidding. And if you haven't heard of this, it's going to be interesting to see how this all plays out. But I've sat on the other side of that table as a CISO trying to explain to the board why a vendor we trusted is just cost us a six-figure incident response. Yeah. And that's the kicker. It wasn't some sophisticated nation state, it was a misconfigured IAM role, right? So we're talking about identity and access management. And it's token nobody bothered to clean up. Huge deal. Huge deal. And we're talking about a third-party risk specifically. And that's kind of why we're going to also talk about third-party risk management. So these small configuration errors do have a in complex cloud environments do lead to major compromises right now. And there are basically at the end of this episode, I'm going to give you the four-phase TPRM framework to help you mitigate this issue. So the article we're getting into comes right out of dark reading. And this was published just a few days ago. And you can get into this and kind of walk through it as you'll see the show notes will also be available to you as well. So basically, Reachers from Token Security recently demonstrated a five-steck step attack chain that nearly compromised Zapier, one of the most widely used automation platforms in the world. Now, if you haven't used Zapier, it's basically a no-code automation tool. It connects apps together, and you can think of it like digital duct tape. So basically, just as the Zaps say, you fill out this form, and what happens is this form automatically sends an email in Gmail, creates a row and a spreadsheet, does all kinds of automation to it. So every one of these connections is a potential attack surface. So this is how it played out. Step one, the researchers started with the ability to write code in a code block, right? So a code block you've dealt with in the past, if you haven't, it's seemingly it looks pretty harmless, right? Right from there, they queried the sandbox operating system and discovered it was running an AWS Lambda. Now, if you're not familiar with Lambda, Lambda is called a serverless compute service from Amazon Web Services. And instead of running a dedicated server, 24 by 7, costing you tons of money, this has got just a little piece of code that's running instead of it. So it's actually very effective, very efficient, and it is also extremely inefficient, I should say, uh cost prohibitive. No, I'm not saying that right. It's it's cheap. That's what it's coming down to. It's really cheap. It's cheap, it's scalable, and it's very popular. Now, these Lambda functions often need permissions to access other AWS services. And these permissions are controlled by an IAM role, an identity and access management role. If that role is misconfigured, now this is something you will want to check routinely as a CISSP, as a CISO, you're gonna want to do some level of assessments. And if this role was misconfigured, it becomes too permissive. The attacks then they can exploit it. So this is what ends up happening. Step two. Ironically named Allow Nothing role. Along with, and I again being this in the previous life that I had, if you labeled something allow nothing, uh that would be you they're just trying to hide it, right? They're trying to do obfuscation in the open. And in the case of this, they found this role and it had additional uh allowances that it basically provided. So along with the failure to securely delete the credentials, I'm like, well, this is a bad idea, right? That's just IAM nothing role, what it comes right down to. So in AWS, the IAM role is like the badge. It tells the system what service or application is allowed to do. A well-designed role follows the principle of least privilege. It can only do exactly what it needs to and nothing more. The role in this story was named Allow Nothing role, which sounds super restrictive, right? But it was configured for more access than it should have had. And again, the obfuscation piece of this. So this is a classic misconfiguration, and people do this all the time. Happens especially in companies, I will just say this, small companies where a person who's doing IT is doing it all themselves. So again, big, big factor. Step three, using a Python script they wrote themselves. The researchers extracted secrets from memory. And again, Python's one of the most popular programming languages in the world, especially in cybersecurity and data work. I see it all the time, right? It's Python is because it's very easy. It's not, it's a very simple product. It works really, really well. Now, you don't have to be a Python expert for the CISSP, because guess what? I'm not one. I had to copy Python scripts off the web to be able to teach my class that I had because I didn't really understand it fully. But now with products like Claude and so forth, it's extremely simple, right? But this Python are standard tools for both attackers and defender toolkits. And here's why this worked. AWS Lambda does not proactively delete tokens and the other secrets until the container is recycled. So now what is a container? A container is a lightweight, isolated computing environment that you'll get within the AWS environment. And then AWS Lambda is your code that runs inside the container. So when the Lambda finishes executing, it doesn't immediately destroy that container. It keeps it warm, right? To be able to be reused in a future time. And do the secrets set in memory? Yes, they don't get wiped away. So it allows attackers, they can climb through and just do what they need to do. Now, step four, using that role, the researchers listed and requested over 1,100 files from Zapier's private repository. Now, this is an important part. So they have this repository that are out there. And these are different, different kinds of code that is available to you as well. Now, the private repositories are supposed to be inaccessible to the public, but they got unauthorized access. This is a huge deal. It can expose source code, credentials, configuration files, and in this case, something even more dangerous. So in step five, they found the MPM token. Now the NPM token is the node package manager token. It's the largest software registry in the world. And the MPM token is essentially a password. It allows someone to publish or modify packages. And if an attacker gets your NPM token, they can push Melissa's code into your software packages, and you will not be the wiser. Now the code then gets downloaded and run, and if anybody uses these packages, that is a supply chain attack. And we see these all the time. So their attacker doesn't go after you directly, they poison the well upstream. Now, one thing we always talked about in the world when I was flying, you never drink water downstream. Yeah, because all kinds of critters do things upstream that you do not want. So there's a problem there, right? So Zapier was responsible and patched this super quick, right? But the lesson here is enormous. And again, it's not theoretical scenario. It's happening right now in organization just like yours. So it really, it's an important part that you have to be aware of and understanding your cloud infrastructure.

Non Human Identities And Agentic AI

SPEAKER_01 8:45 

So non-human identities have become a major source of vulnerabilities in enterprises. And I've seen this time and again. You'll have folks that will put this together and they don't really know what they're doing. And they don't mean this not in a bad way, but they configure it based on making it work. And it works, great, let's move. The problem is it's not always not configured in the most secure manner. So when we talk about identities and security, most people picture usernames and passwords for people. But in modern cloud environments, machine services, applications, they all have identities. And these non-human identities, otherwise known as NHIs, these include service accounts, API keys, all kinds of different aspects around this. So there's far more non-human identities than human ones because why? They're easy. They're easy to proliferate, they're easy to make, and they just continue to grow and grow and grow. The problem is, is in many cases, these are not tracked. They have overprivileged, poorly tracked, they never get rotated. Now we've talked about this in the past where if you have a service account or some level administrative account that doesn't ever get the password changed, you have a vulnerability. You're now in the same situation here. So accelerating the push for agentic, this is where the SaaS infrastructure is becoming more and more complex, and it's harder to secure every single day. So as we're dealing with agentic, the biggest thing issue that we're struggling with as well is the industry is still trying to figure out how to secure it. And here's a stat that really should should concern you. And I saw this and I was like, what? What are you what this is crazy? What it comes down to is 56 of companies that are using agentic AI in some form do not have a process to track SaaS to SaaS connections. So these companies are connecting these things and they're not able to watch them. We've talked about this with API connections in the past. When you have an API connection in your organization and it's connecting to something outside of your organization, and you have no idea what's crossing that connection, you now have created a tunnel between you and another organization. And you're allowing that to be a trusted organization. It's scary, right? I guys, you gotta really think about this before you go and start throwing a gen tick or any of these types of LLMs into your environment that are doing these processes. You need to truly have a good understanding of what are the connections behind them. So I cannot stress this enough. Again, it's an important part that you really truly must be prepared for.

CISSP Domains Hidden In The Story

SPEAKER_01 11:10 

Okay, so why does all this matter? So let's get this connected back to your your the exam. Because this story touches multiple domains along with the CISSP, you need to kind of understand what's going on. So yeah, domain three, security architecture, and engineering. This is a core domain here. And it's at least privilege is a big thing in them in this article. And this is a allow nothing role that actually allowed everything. So this is a textbook situation of a failure that has occurred. And it's didn't need to happen this way, right? And there's also now you're dealing with a principle one or domain one of security and risk management. This is where TPRM lives on the exam. Every vendor connecting that has is connecting to you is a risk to you. If they get breached, their breach becomes your breach. I mean, it's that simple. It's you you catch something. You're catching a virus from them. If they don't take care of themselves, and then the thing we were flying is it de-louse themselves. If they don't de-louse themselves, you're gonna catch it as well. So risk treatment options are accept, mitigate, transfer, avoid. All of these apply here, right? And you need to know them strongly. Now, domain four, this is where you get in network security. The lateral movement between cloud services. This is a big part. There, it's a network security conversation. Segmentation, monitoring, logging, third-party API activities, all of these fall within domain four. And then domain five, you got identity and access management, non-human identities, OAuth tokens, service accounts, all of these are part of domain five. So these are aspects you're gonna have to be aware of. So again, it's an important part. It's a really important part. And you need to understand that when you're coming with complex cloud integrations, it's extremely imperative that you have a good plan. And now with AI that's available, you actually can be in a much better position of putting some of these kind of thought processes into AI to help you make sure that your cloud environment is secure. Okay, so that's all I've got about that article.

Four Phase Third Party Risk Framework

SPEAKER_01 13:07 

Let's roll into what I'm gonna talk about today and related to the TPRM program. Okay, so this is the third-party risk management program, basically building your TPRM framework in 15 minutes. That's the whole part of this. Now, as we talk about CISSP cyber training and the podcast of this is extremely important. I'm just not gonna teach you how to pass the test. I want to walk you into help you go into work on the next day, on Monday, Tuesday, sometime this week, and know what to actually do. Right? This is an important part, realistically. I just gotta be honest with you. Passing the test is the first part of this entire endeavor. We want to help you grow your knowledge so that you can become a better cybersecurity professional and consultant in today's world, right? And if you don't know this information, which it isn't inherent, right? You you work at a company, you don't just automatically know this stuff. It's an important part of you gaining knowledge so that you can be a better resource and asset to your company. And as we talk about in CISSP cyber training, as far as all you're getting your CISSP, it also the more knowledge and experience you have will also help you command a better salary as well. So we're gonna go into a four-phase framework for third-party risk management. And this phase one is gonna be getting into the various aspects of knowing what you need to do. So you gotta know your third parties. Then then we're gonna get into phase two, which is due diligence and assessment. Phase three is ongoing monitoring and governance, and phase four is your policy ownership. So those are all the key things that we're gonna get into. So knowing your third parties, step one, you need to build your vendor inventory. Now, this is a list of every SaaS app, API connection, integration. I mean every single one. Now, remember the stat 56% of the organizations do not have any process to track SaaS to SaaS connections. So if you can't protect, you can't protect something when you don't even know it exists. So you need to build out this completely. Now I'm gonna be very transparent with you. When you just start this, you're gonna go, oh my gosh, this is overwhelming. You're gonna want to start small with this and you're gonna want to build upon it, and knowing full well that when you go into this, you're gonna miss some. You're not gonna have them all right away out of the gate. And you also may not want to put all of them down here right out of the gate. You may want to break these down into different types of tiers. You know, tier one would be critical, tier two is high, and tier three is low. So again, high critical is their access to sensitive data or core systems, high is significant integration, limited data exposure, and then low is minimal access, low sensitivity. So, right here, what are you gonna do? You need to go start in the when you decide to do this and you work with your CISO, you need to map every vendor and start with tier ones. That's it. Stop there, don't go any further. That's step one. Now, phase two is the due diligence and the assessment. Now, the due diligence and the assessment, before you connect a single vendor, ask these questions. Do they have SOC 2 type 2, ISO 27,000 one, or are they equivalent? Are they certified? Now, here's a key thing. They may say, I am SOC 2 type 2, I am ISO 27,001. They may say those things, but are they certified? There's a big difference. Getting certified in those two types of aspects are much more important than actually saying, I am that, because I can say I'm six foot five and I'm built like a rock or like Hulk Hogan. Right, God rest his soul. But are you right? I'm not, but I can say I am. The thing is, is I'm not certified to be Hulk Hogan. If I was certified to be Hulk, yeah, that's a different story. Now, the data, what you need to understand what data will they access? It does it allow for least privilege. How do they handle subprocessors and fourth parties? Yes, fourth parties. Yeah, that's your vendor's vendor, right? There, that's their vendor. That's their third party, is your fourth party. This is how deep that rabbit hole can go. And on a contract side, you need data processing agreements, and these are required under GDPR and state privacy laws. You need to have a right to audit clause for your tier one vendors. Did this multiple times, and this clause was in our contracts with them that if I was gonna they're gonna be my tier one vendor, I had the right to audit them. Now I had to give them a certain period of time in which I would do that, but I had could audit them at any point in time. They need to have breach notification requirements. 72 hours is the GDPR standard, and it is for a lot of different companies is 72 hours. Now that's the breach notification. Again, we've talked about that in CISSP cyber training in this podcast numerous times. You need to define what breach means. And again, due diligence is not a one-time event. You reassess annually. The bottom line on all this is if your vendor gets breached and you don't have these contractual protections, you are exposed. Now, again, I'm not a lawyer, I'm not your legal counsel, but knowing what I know, you are in a world of hurt. And so you need to work with your legal counsel and understand that. So this could be both legally and operationally. Now, phase three. What are we gonna do with phase three? Phase three is ongoing monitoring and governance. This is where the organizations drop the ball. They do the due diligence up front, they do all the aspects they need to, but then this is where they forget about it. Here's what's gonna what ongoing monitoring looks like. You audit all your OAuth tokens, you audit your API keys and your service account permissions quarterly. Yes, quarterly. And so this is why you need some level of automation to do this. It's gonna start small and work your way up, but you also want to think about this as you're growing this out. How do you automate this process? Now you need to revoke access immediately when integrations are discontinued. Non-human identities need lifecycle management just like user accounts, and they need to be an automated process for this. And on the monitoring side, you need to subscribe to vendor security bulletins. Log and monitor all third-party API activities, and include third-party scenarios in your incident response playbooks, because odds are high that's where it's gonna come from. It probably is not gonna come from someone attacking and kicking down the front door. It's gonna be somebody in your third party and a scenario that they have that's gonna be affecting you. So you need to have it in your playbooks, right? Because if Zapier style breach happens, you need to know what is your IR plan says. Obviously, before it happens, not after. Now, the CISSP exam tip right here, right? TPRM falls in domain one. Know your risk treatment options cold. Understand what those are. Phase four, let's get into that. What is that one? So phase four, governance and policy. Now, this is where it all comes together. You need to assign ownership. If somebody doesn't own it, nobody owns it. And so if nobody owns it, nobody's gonna protect it. So the TPRM program owner, often the CISO or the procurement lead, each tier one vendor should have an internal business owner. Okay, so no new vendor approved with should be approved at all without security sign-off. So if your CISO is involved, they need to be understanding what they're actually signing off on. Period. They just have to do that. A TPRM policy must include minimum security standards by tier. So your tier one needs to have standards that are specifically published that are available to your third parties. You need to have your tier two and your tier three as well. Now you're gonna want to be a little bit flexible in some of these because again, as you go tier one, you should have a very small list of applications, SaaS applications, all of those should be relatively small. And so therefore, you can be maybe a little bit more granular. But once you get into tier two and tier three, that list expands quite substantially. And if you get extremely granular there, it can cause you all kinds of drama. So you're gonna have to weigh that out to see how that plays for you. Now, onboarding and offboarding procedures, especially access revocation on termination, acceptable use of vendor provided, non-human identities, all of these I've had to deal with before, and you get the vendor offboarded and nobody revokes the token. How often has that happened? You've had people you terminate from your organization and they still have access. Now, you hopefully you have you've you revoked some of their other aspects, their computers, their tokens, all those things, but how often does that actually occur? A lot. Right? Three months later, the token's still active. That's just basically a breach waiting to happen. I mean, that's that's just what happens. So governance builds the muscle memory that prevents the Zapier style breaches. And this is the bottom line. Here is your action plan right