CCT 359: ShinyHunters vs. Oracle — Supply Chain Risk Every CISSP Must Know

A vendor gets breached and suddenly your perimeter does not matter, because the attacker does not need to “hack” you. They just reuse the access you already approved. That’s the core lesson behind the Shiny Hunters campaign targeting Oracle PeopleSoft servers at colleges and universities, where compromised access led to large-scale theft of student data and a messy, high-impact supply chain incident.

We walk through what supply chain security really means for modern cybersecurity and for the CISSP exam: it’s not only the software you buy, but also hardware vendors, cloud service providers, managed service providers, open source libraries, and contractors with privileged access. I break down the four supply chain attack vectors you need to know cold: compromised credentials and OAuth tokens, malicious code injection in CI/CD pipelines, open source package attacks like typosquatting and maintainer compromise, and hardware tampering. Along the way, we map the ideas to CISSP Domains 1, 3, 5, and 8 so you can answer questions like a manager, not just a technician.

Then we go deeper on two concepts that keep showing up in both real breaches and exam questions. First, SBOM (Software Bill of Materials), the “nutrition label” that tells you exactly what’s inside your software so you can respond fast when a new CVE hits. Second, OAuth token governance, where long-lived or overly broad tokens can become silent master keys if you do not scope, expire, inventory, revoke, and monitor them properly. We finish with three practice questions and the reasoning behind the best answers and the common distractors.

If this helps, subscribe so you do not miss the next training, share the episode with a CISSP study partner, and leave a review to help more security pros find the show.

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

Welcome And Today’s Focus

SPEAKER_00 0:00

Welcome to the CISSP Cyber Training Podcast. Where we provide you the training and tools you need to pass the CISSP exam first. Hi, my name is Sean Gerber. I'm your host of the Active Active Formative Podcast. Join me each week as I provide the information you need to pass the CISSP exam and grow your cyber sector in knowledge. Alright, let's get started.

SPEAKER_01 0:26

Good morning, everybody. It's Sean Gerber with CISSP Cyber Training and hope you all are having a beautifully blessed day today. Today is Monday, and Monday we typically go over all the aspects related to the CISSP to include training as well as some CISSP questions. So it's going to be a great episode today. I'm pretty excited about this. We are going to be getting into supply chain risks. We're going to be talking about the Shiny Hunters exploits on Oracle's PeopleSoft, and then we're going to roll into some basic supply chain risks that are tied to the various domains that are out there. This is all part of the CISSP cyber training's ability to help you get and study for the CISSP exam. So before we get into that, one thing I actually want to bring up to you all if you've all seen it or not is related to the mythos release. I saw this maybe just yesterday, where Mythos is now going to be released to the US government for critical infrastructure protection. So it'll be interesting to see when this actually hits the streets for the rest of us, but uh it's it's looking pretty awesome. So I'm pretty excited about that and then how that can be implemented within the various security tools and practices that are out there. So pretty cool, pretty awesome.

Shiny Hunters Hit Oracle PeopleSoft

SPEAKER_01 1:41

But let's get into the article I'm going to talk about today that I thought was very interesting uh related to the Shiny Hunters exploits, Oracle's People Soft Zero Day to breach universities. Okay, so this hits close to home because it's a lot of first for a lot of different organizations where this could be a problem. So we're talking about the Shiny Hunters Group and their latest campaign targeting Oracle's People Soft servers and colleges and universities across the country. Over 100 organizations have been compromised and hundreds of thousands of student records have been stolen. So what's the worst part about all this? Well, it wasn't a zero-day exploit. This was a supply chain attack. If you don't know the Shiny Hunters, well, you need to. This group has been one of the most active and destructive threat actors for the last several years. They've gone through Salesforce, Sales Soft, Snowflake, Infrastructure Canvas, and now they're on to Oracle's PeopleSoft. So what makes them so dangerous? Isn't that they're not using exotic malware, it's that they don't need to. The Shiny Hunters are proving something that every security manager needs to hear. You do not need malware or zero days to cause massive damage. All you need is access, right? We've talked about this over and over again at CISSP Cyber Training. It's the access. And that access, they're getting through to from everything to your vendors. And that's where we talk about how you need to have a third-party risk management program in place at any of your companies that you're working with. So here's how it went down. Shiny Hunters claimed to have compromised Oracle's PeopleSoft servers across more than 100 different organizations. So with the bulk of the victims being colleges and universities. The group contacted one of the affected schools directly and shared a sample of the data that they stole to prove that they actually had it. So what was in that data? Student names, home addresses, phone numbers, emails, data births, you name it, it keeps going on, right? GPAs, all of those aspects. So this isn't just embarrassing, it's a FERPA regulated data. And this data can be used for identity theft, targeted phishing, and financial fraud. So depending on what else they pulled, it could potentially be even more damaging. So Oracle published a security advisory on June 10th, the same day the attacks were reported, urging immediate mitigations and noting that only supported versions of the people tools were tested for the flaw. So unsupported versions out there, you can assume they will be as vulnerable as well. So this is a big deal, right? This is something that you all have to be aware of related to supply chain risks. So here's what I really want you to understand. This attack isn't just about Oracle or PeopleSoft. This is part of a year-long campaign from Shiny Hunters, hunting for shared vulnerabilities in widely deployed enterprise solutions. Think about that for just a minute. So when an attacker compromises a platform that thousands of organizations use, they don't have to attack you directly, right? That's all done through these third parties. They get access to your vendors. And through that vendor, they walk right into your environment. And this is the exact pattern we saw with Salesoft and with Drift, right? Where the attackers use compromised OAuth tokens to access Salesforce customer environments. And we talk about OAuth tokens a lot in CISP Cyber Training. And I'm also going to get into just a little bit about OAuth tokens later on in this episode. So it's the same playbook. Trusted vendor gets hit, OAuth tokens or credentials get stolen, attacker then pivots your organization without you ever touching your perimeter. So Verizon's 2026 data breach investigation report continues to call out the vendor-mitigated intrusions as the leading attack pattern. So why is this the case? Well, why would I go attack somebody from the front when I can attack all the people from the rear? That is it's just it's a really great attack tactic, but it is something that you all are vulnerable. We all are vulnerable to this. So this is not a fluke, this is a strategy. So what is the takeaway in

The Real Lesson: Vendor Oversight

SPEAKER_01 5:58

all of this? So what does it mean for you? Whether you're studying for the CISSP or you're already a security leader, the lesson here is the same. Build a veteran management and third-party oversight program into your security program and make sure this is not an option anymore. You have to do it. You need to make sure that you have a third-party risk management program, you have a vendor management program, all of those are in place within your organization. You need to build this. You need to build it. It's not you you think about it, you really must build it. So you have to know what vendors have access to in your environment. If you don't know that, that's a gap. That's a true gap. What level of access do they actually have? And what data can they specifically reach? This is what happens to your organization if they get breached. Most orgs I talk to cannot answer those questions quickly, and that's the gap. These threat actors are exploiting. If you don't know this information, you do have a problem and you need to address it quickly. The great news though is that you can. It's not a problem to do so. You just need to have a structured, coordinated effort in doing that. So, as someone who's studying for the CISSP, this maps directly domain ones and domain three, risk management and security architecture. And we're going to go deep into that in the next section here related to the training piece of this coming up next. All right, so a quick recap before we move on. So Shiny Hunters hit Oracle's PeopleSoft, 100 plus organizations, student data is involved, thousands of records, hundreds of thousands of records, supply chains attacked through trusted vendors, and no malware needed, just access, right? So this is part of a larger campaign that you all need to be aware of. All right, so if you are studying for the CISSP and you want structured help across the getting across the finished land, go to CISSP Cybertraining.com and check out what I've got. Uh, just a quick shout out. I am almost full with my Sprint CISSP cohort. Eight weeks for you to complete the CISSP exam. All the training you need to be ready to take the exam at the end of that eight-week course. So yeah, I've only got two slots left. That was my first cohort that we've been doing to try to figure this out and to go, how is this a need? And it has definitely proven there is a substantial need there. So we're excited about that. Having the first cohort will begin July 7th. So if you are interested, two more slots left. That's all I have, and they will be taken here soon. I know it. Uh so again, go check out CISSP Cyber Training and look at the cohort that's available so that you can be ready to take the exam the end of August, first part of September. Okay, so let's move on to our training for today.

Training Roadmap For CISSP Domains

SPEAKER_01 8:37

So, what we're gonna be covering today, what supply chain security risks actually means and why it's the biggest, bigger than you think, how attackers are exploiting it right now, how the CICP exam maps it across all four domains that are there, one, three, five, and eight, and then the controls that stop these attacks before, during, and after the vendor relationships. There'll also be a deep dive into S bombs and how what they are, how to store them and what tools you need to know, and then on OAuth tokens, how they work, how they get abused, and the controls the exam will test you on specifically. And then I'm gonna throw you three practice tech question exam practice exam questions with a multiple choice walkthrough, right? So you're gonna kind of get into those pieces related to the CISSP and the exam questions you can potentially expect. So let's get into what is supply chain security.

What Supply Chain Security Really Means

SPEAKER_01 9:27

So let's start with the fundamentals. What is supply chain in cybersecurity? And I want you to think much bigger than that it's the vendor we buy our software from, right? That's what a lot of us think. But if you look at this slide, your supply chain includes six different categories with external dependencies. So those that are listening, we'll just go through it. But if you're watching it, you'll be able to see the six dependencies as well. So hardware vendors, the companies that are making your servers, your routers, and your chips. Your software vendors, the companies whose code is actively running on your systems in your system right now. So all of that code, whether it's stuff that you've created with using dependencies and libraries or stuff from third parties. Cloud service providers, the platforms where your data lives and where it operates. And then managed service providers, the companies that have admin-level access to your environments and your infrastructure. These MSPs can be a huge way into your company. Open source libraries, the code your developers pulled from GitHub or NPN or PY, PI, and your baked-in applications. And then the contractors and consultants, the humans with privileged access who are not on your payroll. And that is where I run, right? You run as a consultant. I deal with this all the time. So every single one of those is a link into your supply chain, and every single one of them can specifically be compromised. It's not just a matter of if, it's a matter of when. So now here's a key concept from the bottom of the slide that I want you to keep in mind. And I want you to lock this in before we go any further. Implicit trust in vendors is the vulnerabilities attackers exploit. So again, implicit trust in vendors is the vulnerability attackers will exploit. So if you trust the Oracle PeopleSoft is secure, and you trust that your open source library, your dev team pulled last week is clean, which we've talked about multiple times, your trust you're in that MSP is protecting their admin credentials, that is implicit trust. That is an attack surface. That's what they're going to come after. So Shiny Hunters didn't attack your firewall. They exploited the implicit trust that universities have placed in their PeopleSoft environment. So from a CISSP domain one standpoint, this is a risk management problem. Before anything else, that's it. You cannot manage risk you haven't identified. And in most organizations, they have not done a thorough job of mapping their supply chain risk exposure. And that's going to be on the exam. It truly will, because it's becoming one of the number one ways that people are getting access into the various different types of companies. So it's going to show up in your career and it's going to be on the exam. So let's start planning for it right now. All right, so let's talk about how these attackers, attacks, actually

Four Supply Chain Attack Vectors

SPEAKER_01 12:16

work. So because the CISSP is going to test you on the mechanics, not just whether you know that a supply chain attack exists, there are four primary attack vectors that you need to know stone cold, right? Number one, compromised credentials and OAuth tokens. This is the Shiny Hunters playbook. They did not hack your firewall. They compromised a trusted vendor that already had OAuth tokens connected into your or their environment. And they use these tokens to walk right in. So there's your tokens. These are shared secrets that are stored. No malware, no brute force, no alerts triggered. Why? Because they're expected. Because the access looked completely legitimate. This is a tape textbook thing of what we did as a hacker. When I did this as a red team, we looked for credentials because we wanted to get lost in the noise. But I want you to understand right now that this is the number one supply chain vector active in the real world today. So number two, malicious code injection. Now this is the SolarWinds model. This is where the attacker doesn't target you directly. They compromise a software vendor's build pipeline, right? So they're over CI CD pipeline, they actually compromise that. They insert malicious code into legitimate software updates. You download the update date, you run it, and you just install the attacker's backdoor. It wasn't somebody else doing it, you did it to you. So the CISSP exam will test you on the controls that catch this code signing, software bill of materials, or also known as the SBOM, and secure software development practices. We'll be covering the SBOM in detail on the next slide as we go into this after the domain mapping and control sections. But you're going to get into an SBOM and kind of give you a little bit more of a heads up on that. Number three, open source package attacks. So developers are using open source packaging constantly. All of your developers are using it. If you have developers in your team, they are using it. No question about it. So NPM, PYPY, Maven, all of these are repositories that our modern software is built on. And attackers compromise these packages through typosquatting. So this is registering a package name one character off from a legitimate library and waiting for the developer to fat finger the install command. They're also doing it through expired domain takeovers, buying up a domain of a dead package and pushing malicious updates to anyone still using it. And maintainer account compromise. This is taking over an account of a legitimate package maintainer and pushing malicious code through a trusted channel. So this is domain eight territory, software development security. And as we talk about the CISSP, you can see just in this situation, there are multiple domains being covered at any one point in time. And your software development piece, this is growing super fast. I mean, we talk about it almost every episode. There's some level of development work that's being compromised. So number four, hardware implants and tampering. This is one is more common in government and defense environments, but it's absolutely on the CISSP exam. Nation state actors have tampered with hardware during manufacturing or shipping processes. These controls are trusted supply chain programs and the hardware verification processes that are baked all into this. NSA and CISA both have guidance on this. So you need to know those four vectors cold. Compromised credentials and OAuth tokens, malicious code injection, open source of package attacks, and hardware tampering. Every one of these is going to show up in some form or fashion on the CISSP exam. So you need to be prepared to understand those. Again, this is all based on the fact vectors that we're talking about. This is for hardware verification process. And the four that you need to understand are compromised credentials and OAuth tokens, malicious code injection, open source package attacks, and hardware tampering.

How Supply Chain Maps To CISSP

SPEAKER_01 16:28

Okay, so now let's map all of these to the CISP domains because this is where a lot of candidates get tripped up on the exam. Supply chain shows up across multiple domains. It's not just one domain. And the test is going to put in situations where you have to think across boundaries of the domains. So domain one, security and risk management. This is a primary domain for supply chain and third-party risk management, vendor due diligence, contractual security requirements, and risk assessments for vendors. This is a key piece that you will we will talk about at CISSP Cyber Training, as well as in my Sprint cohorts. So the classic exam questions here you put you in a manager's seat and ask you what should you do first? When onboarding a new vendor, the answers almost always start with a risk assessment. Yes, do not sign the contract, not connect them to your network, not trust their security attestations, because they will put those out there. It's no, you need to do a risk assessment. So you really need to assess the risk first. Then get your security requirements into the contract as well. Now, if they don't want to let you do that, you're gonna want to then see if they have done any other security assessments that are they're certified for and kind of go down that path. But try to get the security assessment done of them before you sign any contract, especially a long-term, long-term contract. Domain three, security architecture and engineering. Defense in depth applies to the supply chain. You should not assume a vendor's code is clean. No, do not. It's full of lice. I guarantee you it's gonna have some challenges. You definitely should test it. Network segmentation does matter. If a vendor has access to your network, that access should be scoped to only what they need. And you're gonna need to do that. It's it's so easy just to go, you know what, we'll give you a VPN and let you run on in here and have a good time. Don't do that, please don't. They need to have their own segmentation within their network. This needs to be principles of leave privilege, applies to vendors exactly as much as it applies to employees. Domain five, that's identity and access management. This is where OAuth tokens live. This is where the vendor privileges access live. So, questions here will focus on how do you control what a vendor can access? How do you revoke that access when your relationship ends? And it will end. It ends with everybody. How do you audit that vendor activity? This would be just in time access, privilege access workstations, session recording for vendor remote access. These are the controls the exam loves. Now, domain eight, software development security. SBOM, software bill of materials. The SBOM is cool. It's the BOM. So that's really dated me. Security, uh secure SDLC practices, code signing, and integrity verification, and as well as defendency scanning. So as you read at the bottom of the slide, I call out I put out there for a reason. The CISSP is not testing whether you can react to a supply chain attack, it is testing whether you can build a program that prevents and detects them. Again, build the program. Think program. It's not just an incident. This is the think like a manager manager mindset that separates the candidates who pass from the candidates who do not pass, or should I say fail. We don't want to fail. Do not fail. Failing is bad. Okay, so let's get into the supply chain controls.

Controls Before During After Vendors

SPEAKER_01 19:51

So I want you to think about this in three different phases. So before you bring a vendor in, while the vendor relationship is active, and after the relationship terminates, you no longer are dating, you're no longer engaged, you have been divorced. Okay, so before due diligence, do a security questionnaire, review the SOC2 type 2 report or equivalent third-party audit. Those are a big factor. And I would use those audits in many cases when I was uh part of a larger organization. We would use those audits as a way of allowing them into the environment. Because if you can pass a SOC 2 type 2 audit, you are in a much better position to have your lease security controls in place. That doesn't always mean that that's correct, but in many cases, having that audit completed gives a really big step forward. So get your security requirements in the contract and make sure that the contract includes the right to audit. Without the right to audit, every other requirement is just words on paper. And again, we're really good at putting words on paper, but following through is a key factor. You cannot verify compliance if you cannot audit. Ongoing monitoring during this situation, there's the most organizations fall short. They do the upfront due diligence, but then they never again look at it. They wait until something breaks and then they address it at that point. So it's continuous vendor risk monitoring, it is an important part of your organization. And you can actually get third parties that are actually actively looking at vendors, that's an option, as well as you just monitoring their access into your environment. So least privilege for all vendor access, scope it to exactly what they need and nothing more. Audit logs for all vendor activity and session recording for any privileged remote access. If they have remote access, you should be recording it. If a vendor needs to touch your production environment, you should be recording that session no matter what. After offboarding, this is the phase that organizations fail most consistently. So when a vendor relationship does end, and they all do end, all access must be revoked and all credentials must be rotated. All OLAuth tokens must be invalidated. Big gotcha there. Data returned or destroyed per your data classification policy. This is where the shiny hunter attack that we talked about. Earlier exploited a legacy credential. A credential that should have been decommissioned a long time ago. That is an off-boarding failure. And the call out at the bottom of the slide, SBOM. Software build of materials. Know every library in your software before a zero day forces you to find out. We're going to cover SBOM in detail in the next slide, but you need to really understand your S Bomb for your organization. Okay, so if you've never been introduced to SBOM, this is a great little introduction that will be helpful

SBOM Basics Plus Tools To Know

SPEAKER_01 22:28

for many. And I do I want to kind of highlight the fact that all I ever heard this once was I heard someone say soft bomb or SBOM. And I'm like, what the heck is an S-Bomb? Well, let's get into that a little bit. So the Software Bill of Materials is what they call the S Bomb or S or Sierra Bravo Oscar Mike. This is one of those topics that shows up on the CISB exam, and candidates either know it cold or they completely just go blank on it and they don't know what to do. So you're gonna know it cold after today. So what is the SBOM? Think of it as the nutrition label for your software. A complete inventory of every component, every library, every dependency, every version used in your product. All of it is there in the SBOM. So just like the food label tells you exactly what's in your meal, the S Bomb tells you exactly what's inside your application. So why does this matter? Because when a zero day drops, and it will drop, right? We talk about it, it's not a matter of if, it's a matter of when. The first question your C Cell asks you is do we use this in our library? So often I'll send out, hey, this article happened here, this article happened here. Do you actually know if that is sitting in your library? If you have an SBOM, you can answer this in minutes. If you do not have an S Bomb, you're going to spend days tearing through your code base, calling your vendors, and hoping nobody is already exploiting you. So it's an important part that you need to plan for. So where should your SBOM live? Your source code repository along with your build artifacts, your CI CD artifact registry, or a dedicated S Bomb registry that's tied to your CI CD pipeline, or a vulnerability management platform that has all that information into it. There's different Qualas and different companies out there that have that. And here's a critical rule about SBOM maintenance. It must be regenerated every single build. Not quarterly, not annually, every time a dependency changes. If you have a good automated CI CD pipeline, this is a very easy process. If you do not, it's going to be kind of painful. So a stale bus SBOM is almost as dangerous as no SBOM at all. Because it gives you false confidence that you have all the information in place and you know what's going on in your organization. But it's only as good as the last time you updated it. So now let me give you the tools you need to know. Because the CISP and real world employees expect you to know these names. So it's an important part for you to understand, at least from a mentorship standpoint as well. You have SIFT from Ancor. This is an open source product that generates S-bombs from containers and file systems. You have GRIPE, it's also from Ancor, and it's a vulnerability scanner that consumes S-BOMs and maps components to known CVEs. Sneak, this is dependency scanning, license compliance, and integrates directly into CICD pipelines. You have OWASP dependency check, this is an open source product that maps your components to your CVEs. And then you have Black Duck by Synopsys. This is an enterprise grade solution for open source risk management. And then finally we have Renovate and Dependabot. I can't never say that word. Automated dependency update tools that pull open pull requests when vulnerable versions are detected. And then you need to lock this exam tip in. This is a big, big factor. Exam tip plus its life's tip. The U.S. government now requires S bombs from software vendors selling to federal agencies. So that's an executive order 414028. So you need to know that that is something that is being required by the US government for anybody that is selling to agencies. So if you're getting CMC CMMC certified, you will need an SBOM. So this does show up in exam questions on software supply chain.

OAuth Token Abuse And Governance

SPEAKER_01 26:06

Okay, so now let's get into the little bit of a deep dive on OAuth tokens. So this is an attack vector that Shiny Hunters used in Oracle's People Soft campaign. And it's one of the most important concepts you need to understand for both the CISP exam and for real-world defenses. So what is an OAuth token? Think of it like a valet key. When you give a valet your car, you don't just hand them your master key, you give them a valet key. A key that opens the car door and starts the engine, but not open the glove box or the trunk. Now I don't have a valet key because I don't have go to valet places, but those guys that have really nice cars, they have those. So it's scoped access, it's limited time access, it's specific access. That is what OAuth is designed to do. It grants access to resources without sharing the actual password. So when your organization connects a SaaS provider, software as a service provider, this to your like to your Salesforce environment or whatever that might be, you give that vendor an OAuth token, not your admin password, a scope token that allows them to read or write to a specific data they need to get the job done. That's the decision. So it's the actual good design when it comes and it's implemented correctly. But here's how it gets abused. Just like everything we talk about, as an attacker, I did in the past from a red team standpoint, we abused all the good stuff that we could because we knew abusing the positive things would give us an outcome that we wanted. So step one, the attacker compromises a trusted vendor. So in the Shiny Hunter's case, the SaaS platform that your organization is connected to, that is what they go after. Step two, they extract the OAuth tokens that the vendor holds from your environment. These tokens are sitting on the vendor's servers. Step three, they use these tokens to access your Salesforce, your HR system, or your cloud storage. No password required, and they are allowed right in. Step four, and this is really the dangerous part: the access looks completely legitimate to your audit logs, completely, right? No failed login attempts, no brute force alerts, no geolocation anomalies. They are you. They are somebody within your organization that has the rights to do so. So just as a valid OAuth token being used across to access data, that is why OAuth token abuse is so powerful. And it's why it's so hard to detect with traditional security tooling. So now let me walk you through why tokens are dangerous when they are mismanaged. Long lived tokens. Yes, so long live the token, said a Caesar. How many organizations grant OAuth tokens that never expire? Right, a token created two years ago from a vendor you stopped working with 18 months ago might still be active. And yeah, it could still allow somebody into your environment. That's a legacy credential waiting to be exploited. Overly broad scopes, the scope of what they're allowed to do. So instead of being very narrow scoped, they have a very wide scope. So instead of granting a vendor read access to specific tables they need, someone clicked grant all. It's easier. I'd have less problems during the setup process. Now that vendor and anyone who compromises that vendor has read at write access to everything. No audit trail, won't even know it because they're just part of the organizations. So most organizations I talk to cannot quickly answer this question. What vendors currently have active OAuth grants into your environment? And many just kind of smile and wave and go, I have no idea. So if you can't answer this question, you cannot manage that risk. And that gap is exactly what Shiny Hunters exploited. All right, so now let's talk controls because knowing the attack is only half the battle. The CICP exam is going to ask you what to do about it. There are five controls you need to know for OAuth token governance, and they all live in domain five, identity and access management. So control one, token scoping. Least privilege, just think least privilege. Grant the vendor only the permissions their integration actually requires. If they need to read invoice data, they get to read the access, they get read access to invoice data. Not read write, only read. They don't get read write to your entire customer database, only to that specific table, only to the invoice data there specifically. Control two, token expiration. Short-lived tokens with forced rotation. Hours or days, not years. And this doesn't expire in a hundred years thing, right? I've seen this in production environments. I have. They have no expiration date or they just put it out to 100 years. Build token expiration into your integration architecture so that rotation is automatic. Do not do a manual process. No one ever actually goes and does the manual process. Control three, token inventory. Maintain a register of every active OAuth grant in your environment. What the vendor has it, what permissions it carries, and when it was issued, when it expires, and who approved it. All of those are key factors in what you need to do when you're dealing with OAuth environments and the register for someone who's maintaining it. The review that inventory, you should review it at least quarterly, because monthly is too soon, but quarterly most definitely. Because things change, people change, integrations change. You get new vendors and relationships will end. So when this happens, you need to know immediately which token to invalidate. Control four, revocation and offboarding. When a vendor relationship ends, the first security action is to invalidate all tokens associated with that vendor. Not eventually, not when someone gets around to it. It's immediately. It's like when a person leaves your organization who's been fired. What happens to their access? It's terminated immediately. Same thing with your vendors. Once they've been terminated, they immediately lose access. The Shiny Hunters Attack exploited this legacy credential, which means somebody ended up in a relationship and forgot to revoke the access. So this is an off-boarding failure. And do not let it happen on your watch. You're studying for the CISSP, you're going to be taking the test, you're going to be a security professional, which you already probably are, within the organization. Use this. This is a great opportunity for you to grow something within your company. Control five, anomaly detection. Even with all the other controls in place, build detection logic for token abuse patterns. Token used outside of normal business hours is a great thing that you can alert on. Token used from an unusual IP or geography location. Great place to alert from. Token pulling volumes of data from outside your normal patterns. That's not normal. That should be stopped. The goal is to catch the cases that slip through because no access control is perfect. And here's your exam tip. At the bottom of this slide, it's talking OAuth token abuse maps both to domains five and one. Domain five for the IAM controls in identity and access management, and domain one for vendor risk management program. And on the exam, the distractors will try to confuse you between token scoping and token expiration and token revocation. Know the difference between all three and which one applies. Again, token scoping, token aspiration, and token revocation. Know the differences between

Three Practice Questions Walkthrough

SPEAKER_01 33:14

those. Okay, so question number one. A payroll vendor announces they are experienced a breach. API credentials used to access your HR system may have been exploited. What should be your first response? Again, so payroll announced vendor announces experienced a breach. Your API credentials used to access your HR system may have been exposed. What should be your first response? A notify your HR department of a potential breach. B revoke and rotate the affected API credentials immediately. C conduct a forensic investigation of the vendor system, or D. Update your vendor risk assessment document. Okay, so think about that a little bit. So when you're dealing with the question, is it what a look at what it's asking? So it's asking you what do you do first? Not what you do eventually, not what you do when you have time. What do you do first? So the answer is B. Revoke and rotate the credentials, and here's the reasoning. If the credentials are compromised, the attacker may already be using them right now, this moment. So every second of the credentials are active is another second the attacker has the live connection into your HR system. Notifications matter, investigations matter, risk updates matter, but none of this stops an active attacker. So if you have to stop the bleeding first, rotate, revocate, and then investigate. Actually, it's just the other way around. Revoke. You need to stop the bleeding first. Revoke, rotate, and then investigate. Now let me walk you through why the others were wrong. Because the understanding of the distractor is just as important as knowing the right answer. So notify your HR department. This feels right because HR manages the data being threatened. But notification while their credentials are still active means you're alerting people to a problem you have not yet controlled or contained. So stop the access first. C. Conduct a forensics investigation of the vendor systems. Forensics will be critical, but the forensics comes after containment. You do not investigate while the door is still open. The horse is leaving the barn. You gotta close the door. Think of it like a house fire. If you don't get a lot of the damage while it's burning, you know, okay, my new chair just started on fire. No, you actually stopped the fire. D, update your vendor risk management assessment. This is an after action step. Updating documentation does not protect you right now. B is correct. Stock the active threat first. Okay, so practice question two. Your organization is evaluating a new cloud-based ERP vendor. Which of the following is the most important control to include in the vendor contract? A mandatory encryption of all data at rest and in transit. B the right to audit the vendor security practices. C a specific patch management and remediation timeline, or D prohibition of the vendor using any subcontractors. Okay, so think about what makes the vendor contract control actually meaningful. The answer will be B, the right to audit, right? So we talked about these again, real quickly go through them. Mandatory encryption of all data at rest in a transit, the right to audit the vendor security practices, that's B, a specific patch management and remediation timeline, that's C, or D, prohibition to the vendors using any subcontractors. And we said the answer will be B, the right to audit. So here's the principle. Every other requirement in that contract, encryption, patch timelines, subcontractor restrictions, all of those are only as good as your ability to verify that they are actually complying. You cannot audit. If you don't audit, if you cannot audit, you are trusting the vendor's word. And trust, as we established in the beginning of this session and this discussion, is a vulnerability. Trust is not good, right? You've but trust is good, but you gotta have to be able to trust but verify. The right to audit is the control that makes all other controllables controls verifiable. And without it, all you have is a list of promises. And list of promises don't go very far, right? With it, you actually have a program. So now let's walk through the distractors a bit. The mandatory encryption, this is an excellent security requirement. But if you have no right to audit, how do you know encryption is actually happening? Yes, I have encryption. I'm using it. Uh yeah, you don't know that, right? So the right to audit is what makes encryption requirement enforceable. Patch management timeline, C. This is also a great requirement, but again, without the right to audit, you cannot verify the vendor is actually patching on schedule. Patch timelines without audit rights are just wishful thinking in contract form. D, prohibition of subcontractors, this is often impractical. Most enterprise vendors are use subcontractors for hosting, support, and development. A blanket prohibition is more likely to kill the deal than to actually improve the security. So a better approach is to require that subcontractors meet the same security standards and verify that through the right to audit. So B is correct. All right, so let's move on to the next question. Alright, last question, the last melon. Practice question three. Here, here we go. This specifically is testing whether you know the distinctions between similar sounding attack techniques and the CISSP just loves these. So a developer accidentally installs a malicious package from a public repository. The package name was one character off from a legitimate commonly used library. Aha, we've talked about this before. Which supply chain attack technique does this represent? A dependency confusion. B typosquatting. C watering hole attacks or D maintainer account compromise. So think about the mechanism and what exactly happened. The package name was on one character off. So the developer mistyped it. So if they mistyped something, the answer would be B. Typosquatting. So the attacker registered a package name that almost looks identical to the legitimate library, counting the developers to mistype during install. This name is just different. The name looks almost the same. Here's why the distractors matter. Because all these four techniques are all in the same family. The exam will definitely use them to trip you up. A dependency confusion. This is not typosquatting, and they are commonly confused. In dependency confusion, the attacker uploads a public package with the exact same name as a private internal package. The package manager often resolves the public version over the private one. So the attacker code runs inside the organization's build as expected. Same name, different repository, that's the key distinction. If the name is different, typos squatting. If the name is the same, dependency confusion. C watering hole attack. Completely different category. A watering hole attack targets sub websites or online resources that users frequently visit, and then compromises those sites to deliver malware to the victims that has nothing to do with package repositories. D. Maintainer account compromise. So in this attack, the legitimate maintainer of a popular package has an account hijacked. The attacker then pushes the malicious update through a real trusted package. If the real package name with a real maintainer's reputation is all there, the package name is correct. Maintainer is the same. The update continues with malicious code. So again, everything goes according to plan. So four different attacks, all in the supply chain family, all potentially on your exam. You need to know the distinctions cold. You gotta know the differences between them when you're going into this exam.

Manager Mindset And Final Takeaways

SPEAKER_01 40:39

Okay, so let's bring it all home. Supply chain security is one of the most critical and fastest growing attack services in cybersecurity today. As we saw in Shiny Hunters, this is not theoretical, it's real. Real universities, real student data, real credentials stolen through real vendor trust relationships. So for the exam, remember cross-domain picture. Risk assess every vendor, build a program, not just a checklist. Domain three, least privilege, defense in depth, scope vendor access, segment the network. Domain five, control and audit vendor access, OAuth tokens, privilege access and revocation offboarding. And then domain eight, S bombs, code signing, secure SDLC, and know what's in your software before the zero day tells you what's going on. Okay, so again, you need to think like a manager. You don't need to be a technician, you need to be a manager. And you need to design a program that prevents this incident from occurring, right? All right, that's all I've got for you today.

Where To Get More Help

SPEAKER_01 41:35

I hope you've enjoyed this. I hope there's been a lot of great information for you. Head on over to CISSP Cyber Training. Lots of free stuff that's available for you. You can sign up for all my free essentials. And if you're a self-study person, it'll give you what you need to be able to get prepared for the CISSP exam. There's other paid products that are there and available for you. If you really want to get the level of detail that you really want, go there to get that level of detail. It's going to be able to provide you for that. Or finally, if you plan on getting your CISSP and you want help doing this and you want to have people that can be there and hold you accountable for your self-study plan, go to look at my sprint cohort. Only two slots left, two left for this cohort that ends in begins in July 7th of this year. And then I'll be doing another cohort starting in September. So if you're interested in getting your C I SP knocked out, now is the time to do it. Only two spots left. All right. Thank you guys so much for joining me today, and we'll catch you on the flip side. See ya. Thanks so much for joining me today on my podcast. If you like what you heard, please leave a review on iTunes as I would greatly appreciate your feedback. Also, check out my videos that are on YouTube and just head to my channel at CISSP Cyber Training, and you'll find a plethora or a conocopia of content to help you pass the CISSP exam the first time. Lastly, head to CISSP Cyber Training and sign up for 360 free CISSP questions to help you in your CISSP journey. Thanks again for listening.