CISSP Threat Modeling: STRIDE, DREAD, PASTA and When to Use Each (367)

Machine-generated from the episode audio, with names and acronyms corrected. Spoken wording is otherwise unedited, so expect the occasional rough sentence.

Welcome And Episode Roadmap 0:00

Good morning, everybody. It's Shon Gerber with CISSP Cyber Training, and hope you all are having a beautifully blessed day today. Today's Monday, and we're super excited about what we're going to be talking about in today's episode. Yes, threat modeling concepts and the methodologies. This is all tied to domain 1.10. So that's the point of it is about threat modeling. I know one aspect that people struggle with is dealing with threat modeling in some refashion. So we're going to be getting into the various concepts related to it. Now, the thing that this is going to be tied to is a rogue AI agent intrusion at Hugging Face.

And we kind of talked about this a little bit at the CIS or CISSP podcast earlier, but today we're going to be getting focusing on the threat modeling aspects that you need to be aware of. So as we typically start these CISSP uh podcasts, we have three different sections we get into. One is the incident, two is the training, and three is questions. So the incident is what actually happened with Hugging Face in early July. And this is being told how I would look at it as a CISO. How would you deal with this? Not as a headline writer would come out and say, because just get you to clickbait, right?

That's not what we were trying to do. The ultimate goal is to provide you the information you need as a manager, as someone who understands this information. The training block is going to be getting into 1.10. This is threat modeling concepts, methodologies, STRIDE, PASTA DREAD, attack trees, and trust boundaries. All of these are going to be parts that are going to be tested on the ISC2 CISSP exam. And then we're going to have three CISSP questions that are going to specifically be calling out these aspects. And the goal on these is that they're going to be challenging. We want you to think about them. But we're not going to focus on the answer.

We're going to focus on the trap. The trap is what's important because you can memorize thousands of questions and not going to truly understand what is going to, how can it better lead you in a direction of the wrong answer? ISC2 builds these tests so that it does that. It wants you to say, think that you have all this information together. You studied it, but it leads you down the path that is incorrect. And then you pick the wrong answer. So we're going to talk about some of the traps on this. So that's an important part as we go through this entire process. Stay to the end because the three questions are going to help you understand so that you don't have to know 10,000 different questions to be able to feel like you can actually pass the CISSP exam.

So again, before we get into all of that, want to also throw out a quick shout out to CISSP Cyber Training. An important part of CISSP Cyber Training is the content that's there. I have the accelerator, the pro, and the cohort. My cohort is getting ready to start off in September 8th. However, my early bird pricing ends the end of this week. On August 29th, it is done. It is no longer at the at 497. It goes up to 597. So it's an important part. If you want to get into this cohort right now, now is the time to do it. Do not wait because once the price goes up, it goes up.

And I will also tell you my last cohort sold out. So I anticipate this one selling out just as easy and just as quick. So you should do this. If you're looking at it right now and you want to get your CISSP done in the next couple months, now is the time to do it. Okay, so now when we're going to go through this, you do not necessarily need a technical background to follow through this. I'm going to explain it in a way that I would explain it to the board that doesn't write code. So before I start, if you're newer to this field, don't tune me out, right?

I'm going to tell you the way I brief this to the board of directors and not one who writes the code. Okay, so let's get into what exactly happened. So before I start, and you're newer to this, understanding that this type of field don't understand, don't tune out, right? Don't go, oh my gosh, you know, stay awake. If you're driving into work, please do that. I'm going to tell you the way I'd brief the board of directors and not one of them who writes code. You'll understand what we're getting

The Sealed Test Room Breakout 4:16

into, right? So the setup here is a test room that didn't hold. So OpenAI runs its AI models through evaluations. Picture a sealed test room. You put the model inside, you give it problems to solve, and you watch what it does. The entire promise of that room is whatever happens inside stays inside. Kind of like Vegas. Whatever happens in Vegas stays in Vegas. The room, unfortunately, did not hold. And this is like coming back to the Marvel Comics and the House of Mirrors with Doctor Strange. They broke out. The model found a flaw in a piece of software that fetches the code packages. Basically, the plumbing.

And this kind of thing that runs quietly in the background and nobody ever looks at it. Through that flaw, it got out. And once it got out, it found something else to sit on the open internet, a web address that would run any code you sent it with no password on it at all. So now I want to be precise here because this part gets misreported. The open address did not belong to the vendor. So the vendor of OpenAI did not, or the that third party did not own that. The customer had set this up on a service called Modal. And then they basically left it exposed.

So the customer. So Modal's own systems were never broken into. Someone left a door unlocked and the agent walked through it and used it as a base of operation. So now this is something that red teamers would do, and they do this quite frequently. And so this is an important part of how we're seeing red team and AI coming together in a bit of a nexus. So because the lesson is already on the table, neither of those two failures had anything to do with open AI. A flaw nobody patched, a door nobody locked. That's it. There's nothing new here that isn't the doors being opened, and what basically it walked right through.

How Hugging Face Got Abused 5:59

So getting inside Hugging Face was one of the biggest platforms on the world for sharing AI models and data. So think of it as a public library that anyone is allowed to upload to. Part of that library reads files, the public sends it. And the agent worked out two ways to abuse that specific capability. The first, it sent a file that essentially said, Before you process me, go read the other file off your own hard drive and show me what's inside. And the system did exactly that. And what came back were the passwords and the access keys the system used to do its job. The second, it sent a file with instructions hidden inside it, and the system ran them.

So both of those were the same mistake wearing two different costumes. The system trusted something, a stranger handed it. It's not the AI's problem. That's the mistake that we have been making since the 1990s. And basically now it's wearing a 2026 outfit. It's just changed, except there's not as much hot pink. Actually, the surprising piece is the hot pink in the 90s is coming back. It truly is. So how it went from one foothold to running the overall place. It just how did it do this? So I want you to hear this next part as a story because it reads like a well-run red team and what happened one small step at a time.

How it went from one foothold to running the place. I want you to hear this next part as a story because it reads as a well-run red team and it happened one small step at a time. So picture this yourself, very large office building. The agent found a staff badge sitting on a desk, just lying there, basically where they showed up at. It picked up this badge and it walked over to the building's key cabinet. The place where all the system spare keys are for each system are set there. Nobody had locked the cabinet, so the cabinet's wide open. So in a well-run building, the room was standing in, it should have never been able to reach that cabinet at all.

But then it found the badge printer. Not a badge, but the actual printer that makes the badges. From that moment on, it stopped needing to steal any sort of credentials. It printed its own, just like we did in the red teams. We would print badges all the time. So this set up the room with a view of a whole floor, a workspace with permissions to see and change everything running on the machine. It found databases where passwords were sitting out in the open in plain text where any software running could read it. So again, these are important parts. It just took over it inside the company.

So there's one thing that makes this security leader, myself, very uncomfortable, is it found a single key that opened every building, not just the one it was standing in. Had one credential that had full admin control across multiple separate environments. And so basically it was able to get right access to the company's source code. Not reading it, but writing to it. So every one of those steps that kind of walked through were very small, from getting the badge, making the badge, using the badge throughout the entire organization. All of those were small incremental steps. But these are all steps that a red team would do.

So that every one of them is boring on its own, and there isn't much to it. But put them end to end and it's a total takeover. Now, look at the light speed at which this AI situation occurred. It is imaginable or unimaginable how fast this can happen compared to what I used to do in the red team world. This is the part that unsettles me the most as a former red teamer. It needed a way to send stolen materials back out. It didn't need anything exotic. It used ordinary public websites as dead drops, more than a hundred of them, free paste sites, free file sharing services.

It even routed traffic through public page hosted on Hugging Face's own platform. Then it scrambled everything it sent so that when the security team went back through their records looking for stolen data, the quick read showed almost nothing, just meaningless blocks of characters. They only found the truth when they rebuilt the agent's own scrambling method and ran it backwards. When they did, they recovered roughly four times the stolen material their first past had found.

Alerts Fired But Nobody Acted 9:58

So did anybody notice? Yes, they did. And that's the part that should really worry everyone who works in Security Operations Center. The alarms worked, multiple systems noticed something was wrong. An automated security tool even connected those separate signals together and correctly concluded that an attack was underway. But nothing happened. The alert was right, the alert existed, it was simply never marked urgent enough to wake anyone up. So it sat there while the campaign ran. Perfect thing we would do is operate in the noise, get it so that nobody can pay attention to us. They may get an indication of it, but they're not really paying attention.

In this case, the the AI worked and found the problem. However, it wasn't urgent enough for someone to do something. So this is not a technical failure. This is a process failure. A decision about what counts as urgent made long before it was started, and this squarely falls within domain one's territory. So again, this always, and I say always, it's not the right term, but it highly is likely that it's going to come down to process issues. So one more detail from their own write-up, which is which is actually kind of funny in a dark sense, doing and scramble the stolen traffic, the team had to run an open source AI model on their own hardware.

Because the commercial AI tools refused to help, they looked at the request and saw the hacking and said, nah, we're out, tapping out. And your incident response team tooling has supply chain too. So that supply chain has its own opinion. If you ever get to a point where your supply chain is going to give you its opinion, could be a bit of a challenge.

What Was Exposed And What Held 11:33

So what was actually lost and what was held? So real customer damage was narrow. Five seats of data were accessed, which appeared to be practice material for security exercises. There was no broad exposure of customer models or customer data. So that's a great positive. And some things generally held. Every attempt the agent made to change anything in the cloud environment was denied. In fact, when it tried to destructive commands, it ran into a kind of practice mode, a setting that showed that what would happen without it actually doing it. It was mapping what it could do, not actually breaking things. It did get into one internal database, but the records show it never wrote anything.

And when it tried a second, more important database, the connection never even completed. Because that one only accepts traffic from a short list of pre-approved addresses. So the protections held exactly where somebody had actually done the work to build them. That's the real lesson of defense and depth. It isn't a slogan, it's a to-do list, and it only protects the items you finished. So what happened afterward? Well, Huggy Face shut off two of the file handling behaviors that led the agent in. They cut off the room's access to the key cabinet, they changed every password, they wiped and rebuilt one of their core systems from scratch.

So they took care of the situation. OpenAI acknowledged responsibility later that month. They also confirmed the model had reached four accounts on four of their servers using credentials if found lying around. Two of them were actively used and two only read. So again, this is a big deal, right?

The Real Lesson Behind The Headlines 13:01

This is a situation where you want you to reframe all that we went through because if you walk away thinking, oh no, scary AI story, you've learned nothing and you're no closer to passing. What I want you to think about here in this situation is that every failure I just walked through has an answer, and the answers are almost always boring. The room could reach the key cabinet. No one ever drew a line saying those two things shouldn't be able to talk to each other. One key opened every building. That line was drawn in a diagram, but never actually built into the architecture. Passwords sitting in the open that never expired.

Me, big deal. And the library of trusted files that a stranger sent it, nobody marked the moment where the stranger file stops. Nothing stopped it from making itself the superintendent of all the keys. So those lines you draw, the ones making marking where trust changes hands, the CISSP calls them trust boundaries. Where we're going to spend some time in a few minutes is because those are the heart of this domain. But here's the big one. The one I want tattooed on your cranium before you sit for the exam. Their list of who might attack us had no entry from an approved, correctly logged in, or non-human thing from a trusted vendor.

This was not done. Think about that for a second. If you had walked up to that security team and asked, have you thought through the risk of your AI vendor integration? They would have said, Well, of course we have. And they would have meant real things. Someone steals our keys, someone tricks the model, our data leaks into it, those things they've thought of. But what they did not plan for is the vendor's own AI becomes the attacker. That is not a gap in their diligence. Those are careful people who did the work. It's a gap in the list of who counts as an attacker. We don't know who's an attacker.

Who are these people? Many times it's not just that we thought it was the Chinese, we thought it was the Russians. Who counts as an attacker? And that's exactly why the exam treats this as something you redo on a schedule, not something you finish once and file. Very slowly, right? Finished and done. Which brings us to the teaching side of this of this content. All right, so before we go there, quick and honest, if you're studying right now for the CISSP and you feel like you're reading a lot but not retaining a lot, that's not a discipline problem. That's a method problem. And that's exactly what happened to me the first time, and that's why I failed.

Three things at CISSP Cyber Training that you need to be aware of. The accelerator, this is $19 a month. It's full question bank, it's domain-domain walkthroughs. You start here if you're self-paced and you just need structure and reps. Pro, this is $39 a month. Everything in the accelerator plus live office hours where you bring the question you got wrong and we take it apart together. And most of the aha moments I see happen on these calls. We also have additional training that we do during these calls. And finally, you get access to my CISSP Insider while you are part of the Pro program. And then finally, the Sprint cohort.

If you have a test date and you need to be ready, buy it, live structured cohort paced. I'm in the room. Seats are limited because this is the only way it works. We keep the seats limited for individuals. But the sprint cohort is starting in September 8th, and there are limited spots available. Only 10 spots remain, and I'm excited those will be filling up this week because early bird pricing is over at the end of

Threat Modeling Definition And Three Views 16:15

this week. Okay, this is domain 1.10. Understand and apply threat modeling concepts and their methodologies. So let's define the terms the way the ISC2 defines them. Okay, so we're gonna get in the textbook version definition first, and then the version that helps you understand this on the exam. Threat modeling is a structured, repeatable process for identifying, documenting, and prioritizing the threats to a system. So that security requirements and countermeasures can be defined before, not after, the system is built. Now the three things ISC2 actually cares about. One, it is proactive, not reactive. Threat modeling happens in a design. If you're doing it after the incident, you're doing a lessons learned or hot wash.

Both are valid, they're just not the same objective. The exam will test whether you know the difference between them. Two is iterative, not a document, not a one-time gate. Systems change, threat actors change, and as July approved with Hugging Face, then entirely new categories of actors can and will appear. A threat model that hasn't been revisited is decorative. It's just sitting on the shelf. Shelfware, as we like to say it. Three, the output is requirements. The deliverable from a threat model is not a scary list of, oh no, what are we gonna do now? It's a set of security requirements and prioritize countermeasures that feed into your SDLC and your overall risk register.

And we've talked about these in numerous details on CISSP cyber training. Write this down because exam loves to hand you an answer that says produce a list of threats and a better answer that says define your security requirements. So every threat model approach starts from one of three vantage points. ISC2 tests all three by name. Asset centric. Okay, that's the first one. What are we protecting? Now this starts from the crown jewels, identifying high value assets, then working outward to basically who wants this? How would they get it? What protects it now? Best when you're dealing with data classification is mature and you know what truly matters.

A blind spot you may have is when you protect what you've listed and you miss the low value pivot points. So, like in the Hugging Face situation we talked about earlier, the data set processing worker wasn't a crown jewel, it was the front door, and that's what allowed them into the organization. Attack centric. Who wants to hurt us and how? Okay, so this starts with threat actors, and we've talked about the threat actors within your various organizations. You build profiles. What is the motivation? What are their capabilities? What are their resources and likely tech TTPs, right? So tactics, techniques, and procedures. Threat intelligence feeds all of this for you.

And this is very strong for realistic prioritization. However, the blind spot is this whole lesson of this specific episode that we're talking here, is that you only find attackers you can imagine. Your model is bounded by your actor catalog. So if your catalog is whatever, and now you have other things that are coming into it, it can get quite unsustainable. So you need to know those. Software centric, the third item, or system-centric. What can go wrong with this thing we're building? Start from architecture, decompose a system, draw data flows, diagrams, mark trust boundaries, examine each element. This is where you basically take this thing apart like you would in a Marvel movie.

Have an Iron Man doing his funny thing with all the holograms. Same concept. This is where STRIDE, S-T-R-I-D-E, lives. Best coverage during design requires real architectural detail to be worth anything. Okay, so let's understand this from an exam framing standpoint. The strongest programs use all three, but when a question describes a starting point, it is telling you which perspective the scenario is in. Read for the starting point. Let's get into STRIDE.

STRIDE Mapped To Real Failures 20:16

This is applied against data flow diagrams. There's six threat categories, and here is the key that most study guides bury. Each one of them is the inverse of the A security property. So as you can see on my slide here, there's just lots of different things. It brought breaks down STRIDE as spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privileges. So this is an important part in all of this, and then it gets into what it violates from your authentication, integrity, non-repudiation, confidentiality, availability, and authorization. And then the countermeasures is on the third column. As if you're seeing this through uh my blog or if you're walking through the video, this is where you will have this information.

If you memorize nothing from this episode, memorize the middle column. ISC2 does not ask what does the T stand for in STRIDE. It asks for what attacker modified a message in transit. What would be the impact and where is that at? Which STRIDE category fits that? And then you get to go look at the properties and understand what is specifically being violated. And if that's the case, right, you're dealing with potentially tampering, hashing, digital signatures, all of those things could be a part of it, but it could be encryption in transit and at rest. You need to understand what is the actual question and what are they looking for.

Okay, so let's map this back to Hugging Face and see where we went. Spoofing, it took over the badge printer and made its own identity credentials on demand. Tampering side, it injected templates into data site dataset configs and it wrote to the source control. Repudiation, it was able to basically g zip its command and control traffic in a native log so it only saw opaque blobs and not the actual content. So this ended up basically ended up being fine. Four times the amount that they first thought. Information disclosure, there was 136 cluster secrets that were actually dis exposed. Denial of service. This is the only letter it didn't actually lean on.

DREAD.

DREAD Scoring And PASTA Stages 22:12

Okay, so I need you to hear the single most important thing about DREAD. DREAD does not find threats. DREAD ranks threats you already found. That distinction is a question on your exam you might anticipate to see. Damage, how bad if it happens? Reproductibility, how reliable can it be repeated? Exploitability, how much skill and effort is required. Affected users, this is the blast radius. And discoverability, how easy is it found? So you score each, typically one to ten or one to three, average or sum them, and then rank the overall list. Two caveats ISC2 wants you to know it's subjective. Two analysts score the same threat differently.

And we've done this when I was working in the SOC. We would we would threaten these or we would rank these very different on each one. Discoverability is widely criticized because it assumes a flaw is safe by virtue of it being hard to find in security through obscurity. But we know that this is not a smart idea. So pairing to remember, STRIDE identifies, DREAD prioritizes. PASTA. This is a process for attack simulation and threat analysis. PASTA. Seven stages. Okay, they're risk-centric and business objective driven. And this, that phrase is your trigger, right? They are risk-centric and business objective driven. So you define your objectives. Business objectives, compliance drivers, risk appetite, all of those are your objectives when you're dealing with PASTA.

Define your technical scope, the architecture and its boundaries. Application and decomposition, components, data flows, and trust boundaries. Threat analysis, threat intelligence, actor capability, real world TTPs, and then vulnerability and weaknesses analysis. Map your own weaknesses to the components. Attack modeling, this is where you simulate attacks, and then risk and impact analysis is where you're quality quantifying the business impact, defining countermeasures. So what makes PASTA distinct in its stage one? It starts at the business, not at the diagram. That's why the output speaks in impact and risk rather than on defect accounts. And that's why executives can actually consume it. So the exam trigger words for PASTA is aligned to business objectives, risk-centric, attack simulation, or evidence-based.

Or in even seven stages. These are key pieces when you're dealing with PASTA. So it's business objectives, risk-centric, big factors that you need to put in the back of your mind to understand are they talking about PASTA? So the thing to think about with PASTA, it's heavyweight, it needs threat intelligence, business context, and time. So PASTA is rarely the answer for a fast design time sweep.

Attack Trees Plus Other Framework Traps 25:01

Attack trees, these are important parts. So there I'm going to break into some different aspects related. We got root node, child nodes, or node, and node, and annotate. So the root node is where the attacker's objectives won per tree. The child node is the ways he achieved the node above. An or node is one child is sufficient. An and node is every child is required. Cost skill or probability per node is the annotate function. This is where you're dealing with the different types of attack trees and how you're understanding those. So you need to understand each of them and how they play into it. The biggest thing is that if you look at the tree on the side, the goal is to reach the production data.

So you go to you have an OR decision, right? Exploit the data set and process pipeline or steal the data valid data credentials. Now to get the exploit and the data processing platform pipeline, you would need to have an untrusted config rendered as a template, or the prod can have a metadata service. You can have, and those will give you, allow you to exploit the data set processing in the pipeline. The goal is that you break down how each of these can happen. What are the different attack trees in which someone could actually go after the goal of breaching the production data? When you're stealing a valid credential, you want to understand that there could be static passwords in these workers' environments.

So it's an important part for you to realize that as you may want to take that branch instead to get the goal. But as you map these out into different types of branches, you're going to understand the data that you need to kind of deal with. So connect this, right? An attacker tree is only a method on this list that shows you where a single control kills the entire branch. That's the sentence the board understands, and that's what attack trees live in the PASTA stage six. So some others worth knowing by name. We have VAST. Now, this is visual, agile, and simple threat modeling. This was built for enterprise scale and DevOps pipelines, and its distinguishing feature is that it has it separates application threat models, which is developer facing, from operational threat models, which is infrastructure facing.

Some key trigger words to think about. Scales across hundreds of teams, integrates into CICD pipeline, agile, again, developer wording. Trike, this is built around the requirements of a threat model that assigns each asset actor pair an acceptable level of risk. Trigger words, acceptable risk defined per asset. Auditability, repeatability, that would be trike. Octave, this is an organizational and operational risk that was designed by Carnegie Mellon. Some key trigger words here is enterprise-wide, self-directed, organizational risk, not application specific. Okay. And then you have MITRE attack. MITRE attack is not a methodology. Okay, this is not something that you would do from a methodology standpoint. However, it is brought up most often in this situation as a lost leader, as a way to treat, go down a different area.

So it's a curated knowledge base of real-world adversarial tactics, techniques, and procedures. It is an input to threat modeling. It populates your actor and technique catalog and does not tell you how to model. So if the answer basically choice calls for attack as a threat modeling methodology, it's wrong. That's a trap. Don't go after it. So do not memorize the internals of vast trike and octave. Memorize what makes each one different. That difference is what will help you to decide which is the right one to choose.

Trust Boundaries And When To Remodel 28:34

Reduction analysis and trust boundaries. Okay, so we're gonna have break this into five different sections. You have trust boundaries where the level of trust changes. This is where it goes from one system to the next system, and how does that trust flow? You have your data flows. This is how the information moves between components. And this is from one system to another system. Data flows are extremely important for you to know so you know how to best protect them. Input points, every place where an external data can into your environment. You need to think outside the box on these things. It could just be API connections, it could be some sort of connection with a third party.

What are the various input points within your company? Privileged operations. Anything requiring elevated rights is privileged operations and then a security stance. This is a declaration policy and its assumptions. So you need to really understand. Let's kind of go through what happened with Hugging Face. So an untrusted data set configuration. This was a template renderer, and that broad the boundary was crossed, but it was not treated as one system. Now, you also had instances where you had metadata services. This is where the boundary that should have existed did not exist between the Kubernetes pods and the overall metadata service. A trust boundary you did not draw is a trust boundary an attacker gets for free.

Your model model must treat non-human identities and autonomous agents as first class actors. You need to draw in any sort of AI connections into your environment, need to be on your architecture. Just treat it as any other third party would. So when to model and who belongs in the room. As early in the SDLC process as possible, requirements and design. A design flaw caught on a whiteboard is essentially free. The same flaw caught in production costs orders of magnitude more before the breach actually occurs. So you need to figure it out before you get to that position. Built not as one and done, remodel on what these things.

Architectural change. Did you have something changed? You need to remodel. New integrations or a vendor, remodel. New data classifications or regulatory obligations, big factor. And these change a lot, and you need to have that integration with your compliance and legal teams. Relevant incident anywhere in your sector. If your sector is changing, anything that could be a potential incident that may have happened, you need to potentially remodel. And then a new class of threat actors, you need to remodel. So again, you constantly in this state of looking at the threats to your organization. So this who is doing this? This is not the security team alone.

You have your security team that does it, they facilitate it. You have your architects and your developers, they know the systems, how they actually work. Your operations teams, they know how it actually runs and basically how it was designed. And then your business owners, these supply impact, objectives, and risk appetite. So all of this security modeling alone produces a document. The threat modeling together, working everybody together, produces a shared understanding that's an actual product. Again, security, architect, operations, and business owners. Does any of this seem like it's in a vacuum? It's not. So it's important for you to deal and develop this as a whole team.

So we have five different takeaways for you on this piece of training. Threat modeling produces requirements, right? You need to do the modeling. It does produce requirements. It's not a list of scary things. If the answer stops, identify threats. Look for the one that defines the countermeasures. Match the methodology to the ask. STRIDE identifies, DREAD prioritizes, PASTA aligns business risk, attack trees model one goal. Trust the boundaries where the threats live. An undrawn boundary equals free access. And then your model is bounded by your actor catalog. Review the catalog, not just the diagram. Again, you have the diagram built, but you need to understand what is in the catalog.

And then iterate. A threat model with a date on it and has no revisions is a historical artifact or shelfware. So again, that's an important part for you to get this understanding. There's just five key takeaways. Threat modeling produces requirements, match the methodology to the ask, trust the boundaries where they live, your model is bounded to your actor catalog, and then iterate.

CISSP Practice Questions And Exam Traps 32:47

Okay, so there's the three CISSP questions that are going to go into some different aspects, and we're looking for the trap. So let's dig into those. Question one: a financial services organization is designing a new computer payment platform. The CISO has directed the threat modeling effort must begin from the institution's business objectives and risk appetite. Incorporate current threat intelligence on financially motivated actors and produce an output that the Executive Risk Committee can use to make funding decisions. Which threat modeling best meets the requirements? A STRIDE, B DREAD, C PASTA, or D attack trees. Okay, so let's look at this. What are some of the key factors in this?

We're talking business objectives and key a risk appetite. Incorporate threat intelligence on financially motivated actors and produce output that the executive risk committee can use to make funding decisions. So the answer is C PASTA, process for attack simulation and threat analysis. Right? So three signals all pointing in the same direction. Begin from business objectives and risk appetite, PASTA stage one. No other option starts there. Threat intelligence or financially motivated actors, stage four, PASTA, and then you're dealing with output of risk committee and what they can fund from stage seven. The STEM never asks you to find the threats in the component and it asks where to start and what to produce.

So when you're dealing with all of that, STRIDE, the familiar trap, and the one that catches the most prepped candidates, STRIDE is a framework for everybody knows cold. So it gets picked in the recognition recognition often because that's what they think fit. But STRIDE is software-centric. Remember that. DREAD is prioritization only. It cannot be your methodology because it has nothing to do with rank until something else is identified as a threat. And then attack trees are goal-oriented and very narrow. Just think of one point in time, one goal specifically. They genuinely useful inside PASTA at stage six, but are program level methodologies, right? So exam rewards fit, not familiarity, read for the starting point and the deliverable.

Those two things pick the methodology every time. Question two: a cloud service provider suffered a multi-day compromise of its production Kubernetes environment. The intruder held valid credentials at every step, authenticated successfully to every service it touched, and it's actively was generated by an integrated third-party platform the organization had formerly onboarded through its vendor RISC process. The threat model was current, was based on the documented data flow diagrams with defined trust boundaries that had been updated to incorporate third-party integration at onboarding, and had been reviewed within the last quarter. Which represents the most significant deficiency in this threat modeling program? Okay, so the key things for us to take away in all of this.

So there were some different aspects. Yet Intruder held valid credentials at every step, authenticated successfully, actively was generated integrated third-party platform. The model was current. It was based on documented data flow diagrams. There is a third-party integration at onboarding and had been reviewed the last quarter. But again, what was the most significant deficiency in the threat modeling program? A DRED scoring was not applied, so remediation was not properly prioritized. B. Penetration testing was not performed against the production Kubernetes environment. C, the threat actor catalog did not include authorized non-human entities operating outside the intended scope, or D, the data flow diagrams were not updated after third-party platform was on boarded.

So let's kind of break through this a little bit. What do you think the answer is? And the answer is C. The threat actor catalog had no entry for an unauth or for authorized non-human entity acting outside the scope. So it stems from engineering to eliminate ordinary answer, right? The model was current. Boundaries were defined, diagrams were updated onboarding. So all the things were done in this last quarter. So the vendor was formally onboarded, credentials were valid. All of these things were saying, hey, nothing on the diagram was wrong. What was wrong? Well, it was the actor taxonomy, right? You cannot model a threat from an actor class you do not believe exists.

D. So then the trap is a pre-refuted distractor. What does that mean? Well, we already talked about the fact that the diagrams had been done right. And so these are updated and onboarded. The plan was set up specifically in saying the diagrams were updated within the last quarter. So all of that was good. This was a distractor that requires you to ignore the extended fact above, and it's not the answer. So again, that's a pre-refuted. You already refuted it from the beginning, but now it's pre-refuted. B is the right question, right idea, wrong question. The technician reflex is something bad happened, so we should have tested more.

But the question asks for deficiency in the threat modeling program. Penetration testing is a validation activity, not a threat modeling activity. And then A, DREAD. This prioritizes what you already found. It cannot surface an act or category nobody is conceived of. So again, eliminate any option that STEM has already refuted, and that option answers a different question than the one that's specifically being asked. Question three: a security architect assigned to threat model a business critical application that has already been in production for four years. No formal threat model has ever existed for it. The architect has been given access to the live environment, the incident ticket history, the current vulnerability scan results, and the original design documentation.

What should the architect do first? A review the incident ticket history to identify threats that have already been materialized. B. Perform reduction analysis to identify trust boundaries, data flows, input points, privileged operations, and system security stance. D or C apply STRIDE to the original design documentation to categorize potential threats, or D. Rank the current vulnerability scans using DRED to establish remediation baselines. So again, the security architect assigned a threat model to a business critical application that has already been in production for four years. So it's been in production for four years. They put an application to it. No formal threat model was ever existed for it.

The architect has been given access to the live environment and the incident ticket history, the current vulnerability scans, and the original design documentation. What should this architect do first? Okay, so as we look through these, what do you all think? The answer is B. Reduction analysis. Decompose the system first. So it's really hard to enumerate components you have not yet identified. The system's been in place for four years. So do you even know? So trust boundaries, data flows, input points, privilege operations, security stance, all of that is unknown at this point. That is the map. You cannot enumerate threats against components you have not identified.

Trust boundaries, data flows, input points, privilege operations, all of this is in the map. But if you haven't even looked at it yet, it's really hard to map it to something we don't know. So let's look at the trap. C is the right tool, wrong sequence, stale input. The trap catches the strongest candidates because STRIDE generally is the right identification framework here. But C skips decomposition. And the app has been in production for four years. So the original design docs describe the system that no longer exists. Right? Modeling a document architecture instead of the actual one in production, a threat model is the cut is basically confidently wrong.

So you need to make sure you understand that. A reactive and survivorship basis. A ticket history contains only threats that materialized and were detected and got written up. The threats succeeded quietly are by definition, not by the cue. Incident history is an input to the threat model, not where you start. Okay, so it never was all about threat modeling, right? Question one, fit over familiarity. Question two, eliminate what STEM had already refuted and what answers the different question. Question three, first means first, foundation before sophistication.

Training Offers And Final Requests 40:50

None of those threat modeling knowledge, their exam reasoning. You no matter how many quizzes you study, how many tests you take, it's not about that. It's about how do you understand what is the reasoning behind the question they're asking you. That's the whole think like a manager framework that we have. So you can get the Think Like a Manager framework through Accelerator Pro and my Sprint cohort. Accelerator, $19 a month. You spend more on lattes than that. Give yourself the opportunity to be successful and pass the CISSP exam. Pro, $39 a month. Everything in Accelerator, plus Live Office, plus the overall CI CISSP CPE insider, as well as every all the other content that's available to you.

And then my sprint cohort is starting September 8th. It's going to be awesome. My first one's sold out. It's going to be incredible. And I guarantee you, it is, I'm I'm amazed personally. Okay, I put it together. I get it. I'm a little bit biased, but it is absolutely incredible what you can get out of this self-paced program. It's helping you. So it's the bridge between doing it on your own and trying to figure it out or spending thousands of dollars on a boot camp. If you want to go in between there, this is the perfect option for you in between those two bookends. Okay, that's all I have for you today.

Thank you so much for joining us, and we excited to see where your future goes. Again, go check out CISSP Cyber Training and let's see how we can help you. Talk to you soon. Take care. Thanks so much for joining me today on my podcast. If you like what you heard, please leave a review on iTunes. 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 will 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.