CISSP Domain 8.2: The Malicious Workflow Was Already There (375)

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

Welcome And Domain 8.2 Setup 0:00

Good morning, everybody. It's Shon Gerber with CISSP Cyber Training, and hope you all are having an awesome day today. Today is Monday, and I've got as usual, we've got some really great stuff for you, and we're gonna be covering domain eight, and that is 8.2. Same as always, we've got an article we're gonna go over, followed by the training and then some CISSP questions, because you know you guys want to pass the exam, and nothing better than seeing some CISSP questions to help you with that. So, again, the goal is get you done, get you past the CISSP the first time. That is it, and that's the whole purpose of CISSP cyber training.

All right, so let's get into what we're gonna talk about today.

Ghost Action Workflow Secret Theft 1:06

A couple of weeks ago, Git Guardian published research on a campaign they call Ghost Action. Somebody is pushing malicious workflow files into GitHub repositories, and then those workflows read the project's own CI secrets and then post them out to an endpoint the attacker controls. So again, it's basically taking the stuff and it's pitching it all out there. Now here's the part I want you to sit with. That's 92 of those repositories. They didn't push anything. The malicious workflow was still in the repo from the previous wave. So nobody had removed it. So they basically edited the file, changed the X fill point, and then they moved on.

And here's the part I want you to sit with. In 92 of those repositories, they didn't push anything, right? So these mud they were basically infected, and these malicious workflows were still in the repo from the previous wave. So nobody had even touched them, nobody removed them. So they the attackers just edited the file, changed the X Fil endpoint, and they moved on. So today is domain 8.2. We're dealing with security controls in software development ecosystems, and this is the subdomain that owns the environment. Your code gets built in, as opposed to the code specifically itself. So now two more things before we jump in.

One, I've got a couple of slides at the beginning of this training on the CISSP changes that people have been asking me about. I know you've all heard about it. There's some different changes that ISC2 is putting out related to the CISSP exam in April. Now I will tell you, these are not confirmed, and there's some aspects, I think there's a lot of squishiness in this, but I'll go over some of those here once we get through with this incident discussion and we move on into the training.

How The Attack Chain Works 2:49

Okay, so as you can see, this is part of Get Guardian has posted this with a campaign that never stopped, tracking ghost action from 2025 to 2026. And this was published back in October of 2026. Okay, so let's walk through the chain because every step, the individual steps, is extremely boring. And you're like, oh my gosh, it's yawn, right? But when you bring it all together, the sum of it is something that's basically stealing everything from your secret store. So let's kind of walk through this. Step one, the bad guys and girls get a valid developer credential, which is not hard to do. Not a zero day, not a clever exploit.

They get access to a personal access token out of an info stealer log or an old dump. So the account is legitimate, the token is legitimate, and every control you have is going to treat it at that specific way. Again, they are supposed to be there, even though they're not. Step two, and this is the one I think gets underappreciated. They go read the repository's existing workflow files and the commit history of those files. And they pull out every all of the secret. name references they can find. So think about what that means. Your own repo is telling them which secrets that project has access to.

They don't have to guess. You basically publish the entire shopping list. Step three, they commit a workflow file, and the file names are deliberately boring. GitHub underscore, whatever the action is, underscore security dot YML, right? Your YAML files. All of those things are basically there. And you're like, what is this? It's just kind of some kind of file name that nobody ever opens because it doesn't look interesting. So what do they do? They just hide in plain sight. And we've talked about this a lot at CISSP Cyber Training, hiding in plain sight. And that's exactly what they do. Step four, that workflow then triggers on a push on a manual dispatch.

It hard codes the secret names they just scrapped in there on step two, and then it sends the values to a single HTTP post, right? To an attacker endpoint. So it posts the information to that attacker's endpoint. And then this round, that endpoint is a bare IP address over HTTP. So again, all this stuff is benign, right? But the interesting part is that they are siphoning data and information out. And the October versions went even further. They added regex codes scanning across working trees and the Git rehistory. About 11 patterns covering the ADF, AWS keys, IDs, GitHub, GitLab tokens, cloud provider keys, AI provider keys, all of those aspects were done in the October one.

So again, that's in pretty impressive, and all this is being siphoned out on a routine basis. And like the article says, it's a never a campaign that never ever stopped. So let's scale

Scale Numbers And The Real Lesson 5:40

this. The September wave had 772 public repositories, 373 users and organizations, and the workflows reference represented almost 2,577 secret names. That is a lot. And in the past when we I was working as a red teamer, if I had anything close to that amount of information, it was a field day. You could have everything you wanted. But let's talk about October. So it was in October, more than 30,000 repositories were targeted, roughly 3,000 orgs and about 1,900 compromised accounts. Yeah. Bada boom, bada bing. You now have access to whatever you want. Now I need to be careful with those numbers as you as so do you.

30,000 repositories were targeted. That's not 30,000 compromised. The compromise number is accounts, and that's about 1,900. And then the wave of researchers instrumented end to end, what actually infiltrated exfiltrated was 26 secrets from 13 repositories. So again, you went from 30,000 targeted, 1900 accounts. You ended up with 26 secrets and 13 repositories. So that's it's a lot, right? But you go, well, that's not that many. However, what were those repositories? What were those secrets? That is a big deal, actually. It's a huge deal. So targeted, attempted, and exfiltrated are three different numbers that you really need to keep in mind. And it's I highly recommend you go check out this article and read a little bit into it yourself so you have a better understanding of how this is all playing out.

However, the key thing to take away from all of this, again, lots of numbers, 30,000, 1900. Bottom line is there were 92 repositories where attackers had modified it, modified existing malicious workflows. So the workflows were already there. They went in and made changes to it and had it commit to a new one because these files had been sitting there from an earlier wave. The incident response removed the secrets and never removed the workflow. So let me get you to understand this right. They found the somebody had found the problem. They went in and they saw that the secrets were there. They removed the secrets so they couldn't be used.

However, they did not remove the workflows. The workflows would have stopped these folks from having any sort of access. So again, that's huge.

Rotation Is Not Enough 8:00

So again, you got to think about all of this from a standpoint of how would you deal with this as a manager? So let's look at this, how you would handle that. Everybody's first move here is to rotate the secrets, hence what we talked about, right? And that's all right, that's the right thing to do. And the researchers go out of their way in this article to say, though, that this is not sufficient. That's their words. You also have to find and revoke the GitHub credentials that was used to inject the workflow. So again, the secrets are one thing. Whatever GitHub credential was using that workflow, that is the one you have to go and revoke and then re-establish.

So I hope you understand what I'm saying there. The key on all of this is just because you see secrets out there and you remove the secrets, if there was a workflow involved, which in these this situation there was, you still have to make sure that the developers' credentials to run that workflow were also changed and or removed. And think about why this matters. If you rotate and you don't revoke, the attacker still has right access. So what happens? They just collect a new the new ones that are out there. You've automated their entire cleanup. It's imperative that you kind of think about it this way.

So again, rotation addresses what was taken. It does not address how they got in. Those are two separate investigations, and most post-incident reviews only run the first one. What has left the building? And I gotta make sure that it when it left, I tell the people about it. But you don't dig into how did it leave the building? Why did it leave the building? What were the mechanisms behind that?

Ownership And Pipeline Governance 9:31

Now here's the governance question underneath all of it. And this is the one that I take to your Monday, right? You guys listen to this on Monday. You take it on Monday or on your Tuesday, ask your folks this who owns this specific pipeline? Not who operates it, but who owns it. And we've talked about this over and over again in governance pieces of this. It doesn't matter who actually operates it, it matters who's responsible and who owns it. Who signs for it? Because that's the thing that holds production credentials. It executes code automatically, it can deploy to production, and in a lot of places, it's governed by nobody.

We see this all the time, right? No one has control because it's the tyranny of the fact that nobody has this. I wasn't gonna say tyranny of the urgent, but that's not the case. It's the fact that there is no accountability. And then because of that, it gets filed as developer tooling. And then because it gets thrown into that huge bucket, eh, everybody's good. No problems here. So to summarize all of this, the bottom line is that these tools are imperative that you have them for your organization, right? You need to use them. But think about the tools and think about how the credentials are actually stored.

One, what is happening from a secret standpoint to run your overall application? Two, what is the workflows that this application is using to run itself? And then are those credentials one and the same? Also understand that in the event that you do find a compromised account, are you going back through and revoking and removing the credentials? Not just looking for the secrets that have been exposed, but you're actually then revoking the credentials themselves. So again, another part in domain eight that gets a lot, trips a lot of people up is understanding the overall SDLC lifecycle. Software development lifecycle is imperative to for you to know and for you to be on top of it as it relates to that for the CISSP.

Okay, so as we get into 8.2 securing the development ecosystem, there are some great aspects that you need to be aware of related to the CISSP and how you should be ready and studying for the exam as it comes into 8.2. And so we're gonna be getting into that here in just a second.

CISSP Study Options And Cohorts 11:42

But before we do, I want to talk about two quick things and then we'll get into the overall training content. So there's ways to study with me. The bottom line is I have the accelerator, the pro, and the sprint cohort editions available to you. If you are interested in self-study, you need to look at the accelerator or the pro edition. If you're looking for some a little bit more hands-on or not hands-on, but more interaction with myself and we meet once a month for my office hours, as well as having some more direct interactions, the pro edition is for you. If you're just focused specifically on just how it takes for me to study and get ready for the CISSP exam and be ready to pass the exam, that would be the accelerator program.

But if you really want an ability to have an accountability amongst all of us, that is one of the things that I struggle with the most was accountability. Studying every night was hard, but having someone that held me accountable to it, that would have been amazing if I would have had it. But I didn't. So that's where I created the Sprint Cohort. That is a fast-paced, cohort-paced program that is specifically for you over eight weeks. Now, originally my one is going to be starting November 17th in the morning at Central Time. However, because of the demand and people reaching out to me, I'm actually going to have two sessions starting on November 17th, two cohorts beginning.

One in the morning, one in the evening. For those folks that can't get the mornings one, I have an evening one available for you as well. And that will be available on the site sometime this week. I just got to make some changes. The decision was made just this weekend to make do that. So you will be seeing that very, very soon. Again, I have a cohort starting November 17th at 8 in the a. m. at 7 a. m. , as well as another one at 7 p. m. that same evening. And again, if you're looking for some way to get your accountability and a the CISSP complete in the next eight weeks, the cohort is for you.

I can't express this enough. People have been taking it, have been passing it, and they all attributed to the fact that the accountability, as well as the content that's helped them become successful in passing the exam. So that's the first thing we want to talk about. The

CISSP Exam Changes And AI 13:40

second thing is what is actually confirmed off the CISSP changes. Now, there's a lot of people out there talking, some things that have changing related to the overall exam in April of 2027. Now, what has been confirmed is the outline that's currently out there is effective is of April 15th, 2024. It's still good, right? There's no changes to it. It's all the way it was since for the past couple years. But they have had some aspects that people have been asking around AI. What should they do? Should there be a ninth domain? How should this be done? Well, there is nothing on the ISC2 site about it, but you will see some different folks talking about it, and they will give out their opinions on what they feel has just been released from the ISC2.

I can't confirm or deny that, but I will say that the one thing that I'm hearing and I'm seeing as well on the different blogs is the fact that they are going to be adding AI within the overall test more as a capability, not just kind of as an add-on. Because we'll get into in just a second here, AI is built into 8.2 and there's different aspects related to it. However, the goal that they're seeing is a gap, and I see this myself in this space is governance is a huge issue, as well as some of the red teaming activities that you're going to be running into related to AI.

So I hear that that is going to be added in April of 27. They're going to be making some potential changes to the overall weight of each of these different aspects. I've heard that domain eight might be coming down in some of its relevance, but others will be going up, obviously, for something coming down. So there's just still a lot of things going on this. I would say that you're not going to see the ninth domain. Everything I'm hearing is that there's not going to be a ninth domain focused specifically on AI. They're going to interweave AI into the overall plan for the CISSP. So if you're taking the exam this year, I would recommend that, you know what, if you got the book, let's get it done, be a part of my cohort.

Otherwise, there will be some changes starting in April of 27 that you can anticipate related to AI. Now, granted, we all will do our best to make sure that we get these up to date prior to the August or April 27th date. And once we get more things that come out from ISC2, we will promote those to you and let you know. But as far as I can tell, there is no announced changes other than people that are probably in the know have been able to say a few things that they see coming out of it. Again, if you're wanting to get the CISSP done now, you've got now until April 15th of 2027 to let's just get it done focused on what you got and get become a part of one of my cohorts.

I can definitely help you there. Outside of that, just be prepared that you're going to be dealing with AI in various aspects here in the near future. We all are, we all see it. So now we're just that you can tell that the ISC2 team is going to be catching up with that. Now we're going to talk about some AI content that is already on the outline that you may run into related to 8.2. Now, AI assisted coding tools. So these are out there and available, and you're dealing with, we're dealing with domain eight specifically related to AI coding or to coding specifically, and there is a risk of hallucinated vulnerabilities, basically vulnerabilities that it thinks that are there and if they're not.

So that's an aspect that you may be tested on. Insecure code from the LLMs as well. So there's accidental inclusion of generated snippets that you may get from the LLMs. You're basically the large language models, your Clauds, your Open AI, all of those pieces, you could be getting different types of code from them that may have been insecure. So that's part of the overall exam as well. So you can expect to maybe hear that between now or see that between now and the April dates. AI automated security testing, again, integrated hot into your CICD pipeline. That is a valid question that you could very well be asked.

Also, your ML library supply chains. We've talked about that here just when we're dealing with GitHub and GitLab. You have various supply chains that are there. You might be getting poisoned MLs that are coming from those different types of libraries. So you need to understand that as well. And then model hijacking or inference attacks, targeting the software layer of these different types of LLMs and focusing on are you going to hijack the model so the model can do things for you? Um, or are you going to have an attack based on inference from the overall outputs that they get? So this is not, those are topics that are not what might be in 27.

Those are topics that you very easily could deal with in the current exam. And if you think about it, the AI, let's just really just bolt pull this back. AI is no different than anything else that you've done within the cybersecurity. The differences are that it's changing so quickly and it can be integrated so fast into our other applications, other different types of stacks. It is a part that's changing. And because of the change is so quick, it makes it feel like it has to be something special. But it really doesn't. It needs to take the same type of activity that you would normally do with any sort of software that you would put into any sort of security.

However, because of the quickness that occurs, you're going to need to maybe short circuit some of the thought processes around it and some of the bureaucratic aspects that you may run into because the AI technic technicalities are moving so much quicker than what you run into with traditional

Securing The Development Ecosystem 18:56

software. So there's five domains specifically on in domain eight. So the five subdomains, we're going to be focused on domain eight.2. This is security controls in development ecosystems. So when you focus on languages, libraries, tool sets, IDEs, runtimes, CICD pipelines, repositories, and the testing that goes with that. The big thing to think about here is in the dev space, your dev workstation has changed. And how is that done? And then what is it, what is it before and what is it now? So your bench at that time had some various tools. Many cases when you're dealing with a development world, a lot of those were passive.

Nothing happened unless a person actually forced it to happen. You have an editor, you have a compiler, you have files. All of these pieces are on that endpoint and that they all had a space and they had very aspects of it. They would just, you would chunk along step by step by step. Now, what it's now, the difference is that you have a bench, right? In the past you had bench and you have tools. You now have an apprentice that can help you. This person, or EAI, in different ways, that's embedded within these software type tools, can read untrusted content. It can hold production credentials, and it can make outbound network calls, and it can really act on its own without any sort of input from you.

And the same concept so we talked about before: you have an editor, you have compilers, these are considered an endpoint, and they're very manual basis. You now have the same concept, but it's a little bit autonomous, and it is also classified as an endpoint. So the asset classification follows what it can reach, not what it is called. So a workstation that holds production credentials and processes untrusted inputs is not a laptop. It's an endpoint. It's an important piece in all this. So you think about it. You have to consider when you're dealing with any of these types of tools, especially in the 8.2 space or in the development space, how are you gonna manage this capability and these challenges?

So, what you can expect to see in 8.2. So you've got programming languages, you're gonna understand the various aspects related to memory safety, type safety, what language you can is it that lets you get it wrong. Um, the tool sets and the IDEs. Is it an editor? Is it an extension? How is that agent inside working? The CICD pipeline, continuous improvement, continue, continuous or continuous integration and continuous deployment. And that can be your pipeline. That's when things go in, they get operated on, they work, and then that they come out the other end and they're ready to be pushed to production. So these production systems they can write specifically to production.

So you usually have a like a test environment, and that test environment will push to production and or staging, I should say. You'll have your test, your staging, and your production. If their staging environment is going to push to production, does it have the credentials to do that? If it does, it really is just an arm of production. Even if it if it has those credentials, then what is stopping it from pushing some of that development code into the production environment? Code repository. You understand the access, the history, and are any secrets committed to this repository that may have been done years and years ago.

Important part. Libraries, these are the things that you're pulling in. And I've talked about this before on CASSP Cyber Training. 80 plus percent of the development code out there, and I'm grabbing this number from I can't remember where, but it's it's no question about it. And I feel confident it's probably even higher than that now. But 80% of the development code out there is stuff that is shareware, that is, people are pulling into their sat their sat software platforms, and they're using RD code that's been built by somebody else. So these libraries are what you're pulling in and what you're doing. Now your runtime is your interpreters, your containers, and what it actually executing on.

You have your software configuration management. This is where you have your repositories, your branch protection, who can merge into and what. And then you have your application security testing pieces, your SAS, your DAST, your IAST, and your SCA. So what each one of them actually does, right? So it's important that you understand this list and these different types of pieces. Now, do you need to be an expert at these? No, but you need to understand how they work together because they're gonna ask you questions that unless you know that, it's gonna seem like you're just kind of uh clueless. And it's gonna it's understandable because most of you probably don't deal with the development space.

And so therefore, you need to get sharp on these different aspects. So when we look at ghost action, right, the incident that we're talking about, how did this actually work? And how did it fail? What actually failed in this overall process? So, what failed was there was a valid personal access token. So this was something from an infostealer dump that occurred, and it was a credential. Now, this was a valid token that allowing somebody access to it. So it was legitimate authorization, and it allowed them to do this, and so therefore, it wouldn't be flagged as a problem. The other part is a repo write access.

And if you have a repo repository or your they call it repo, your repo write access, this in this situation it is also a workflow write access. So there was no separate permission. So if the repo is allowed to write, then the workflow, because of the same credentials, was allowed to write as well. You need to think about that from a consideration standpoint. The workflow ran with the project secrets. Again, these CI CD pipeline secrets were there and it ran. And this is by design, this is expected. So this isn't something that would be unnormal for most CI CD pipelines, is you would have these secrets, they would be in place, and they were allowed to run.

Now, the big issues on why this failed. So the first two valid credentials, okay, that's a problem because they were pulled off of a dump. You know, there's got to be ways that you can validate that that's a problem, or rotate your access tokens on a routine basis for those specific situations. But what really took this to the next level was the fact that there was malicious workflow was never removed. And we talked about this earlier. There was over 92 repos that had this happen. So there was no change management process that was in place. They went and removed the secrets, but they didn't go back and remove the workflows that are the permissions to those specific workflows as well.

So because they didn't do that, they were still there and they just had to make modifications to them. And then secrets from earlier waves had not been rotated. So again, more issues. Repeated victims, same campaign, all the same. So you can see how this would this will rinse and repeat, rinse and repeat. And it's so often is when you're dealing with incident response aspects, you go in and you go, oh my gosh, we have a problem. What are we gonna do? And what do you do? You dig deep, you pull all this stuff out, and once you fix the problem, okay, then it is, yeah, shiny penny, shiny penny, squirrel.

And you bounce all over the place, but then you forget about going back and finish these last two aspects. So again, these are the bottom two parts are what made it repeatable. Everything above that was part of the incident, and some of those things are expected, but the last two, the malicious workflow never removed, and the secrets from earlier waves never rotated, is what kept this whole campaign alive.

Inventory, Extensions, And Auto Updates 26:07

So look at the inventory is what is installed? You know, you need to understand which editor, which version, which extensions, and on whose machine are they. Developers have a tendency to do you have you given them machines of your own? Do they using their own devices? What versions of the editors do they have on there? Are you allowing them access into your networks directly? That is an important part. If you don't have that inventory about those, and again, these are things that nobody has. Few people really truly get to that level of understanding. And the reason is it's hard. It takes time. They just want you to get up and run and start coding.

That's an important piece. And so, without that, if you could get this information, which we talk about the governance side, which is so important, this is the same thing. You also need to understand who publishes it. Now, the marketplace extensions are third-party codes running with your developers' permissions. You know, publishers' identity is a control, and you need to understand are they running this? As an example, I had it when I was a uh a leader of our development team, there were certain things that I could publish to the app store. The problem was when I left the organization, those credentials were still there, and they did not remove them.

And they took a little more little while to do that. Again, that's another part that you need to understand the permissions within your organization. What can it reach? Your file systems, your networks, your credential stores. How does the agents' tools, how does the permissions of those tools touch different systems? You need to truly understand that. And again, this comes back to understanding the overall life cycle of your company and the life cycle of your tools. How does it update? Auto update means a reviewed extension can become unreviewed overnight with no change window. Now, the question you have to ask yourself, do you want to do auto updates to ensure that it's updated, or do you want to make sure that you look at them and at least ensuring that before it's pushed, you understand exactly what's occurring?

So you cannot apply a control to software you have not inventoried. If you don't know it exists, it's really hard for you to apply any sort of control to it. If you do auto updates, which we talk about a lot in security, it's an important piece. Okay, the question then is is are you incurring potentially more risk in this? Now we know that asset management is domain too, but all of these things touch every domain. Asset management touches every domain.

SAST, DAST, IAST, And SCA 28:31

Now there's four different tools, and what each of one of those does, we'll talk about. SAS, this is a static application security testing tool. So it looks at your source code, but it is not but your source code not running. It just looks at the source code as a whole. Looks for any logic flaws, injection patterns, anything like that, but it's a static application. When you're dealing with dynamic application security testing, this is looking for running applications that you potentially could have problems with. You have your interactive application security testing. This is it's actually running the app, it's instrumented from the inside, and it works in different areas.

And it looks at runtime configuration flaws as well as any sort of things that are in the execution. And then you have software composition analysis. This is where it has declared dependencies, manifests, and lock files. Known CVEs and license risks fall with it are looked at from your software composition analysis or SCA. But again, you need to really, before you add any more tools, really understand what it is actually doing. I see this so often. People will come in and they will go, I'm gonna buy X tool, buy Y tool. And they maybe buy two or three of these different tools, and the tools kind of talk a little bit about DAST, but they mostly talk of focusing on static application security testing.

Well, what happens is the person just bought three specific tools that do mostly SAST, maybe with a little DAST, and no IST. So I you're going, oh my gosh, I just bought all these equipment and all this these software licenses, but now it's not fully meeting what you want. So it's imperative that if you're looking at software code that your software, some sort of software that's going to look at your code, you want to make sure that you have it for specifically passed for whatever your type that you're looking for. So again, think about it. If you have something with SAS, you should have one thing focused on SAS.

You have something that deals with DAS, it should focus primarily on DAST. I say primarily because sometimes they will bur they will go down the SAS model, but focused on what they are good at, what is their core competency for a software.

Pipeline Controls And Least Privilege 30:32

Now, your pipeline is a production system. It's a system with production rights. It holds the credentials, it executes code on every commit, and it can deploy straight to production. And in most organizations, this is owned by your engineering and governed by most cases nobody. Because your engineering team just takes it and runs with it. And it's just determined as a developer thing. So they just take it and go. Now, the controls that will help with this is that least privilege on build entities. So anything that's building that you have a build for, it should have least privilege. You don't want your whole development team to have access.

Short-lived scope credentials instead of standing keys. Do you have a way to check in, check out keys? Do you have some way to create them on a short-lived basis? Signed or pinned build steps. So when it runs, who is the approval? Who's actually going to be approving it? And is that person in the whole chain? Is there a log of that as well? Is there a separation of duties on the merge? If you're bringing two branches together and you're merging them, who has the separation of duties to do that? You bring somebody else in, or can one person do that? Again, we break these things down.

They all meet the same concept. Separation of duties, you want least privilege. If you can do those things, you're going to dramatically reduce the risk to your company. And then logging that somebody actually reads. Again, logs, is anybody actually looking at them? So if you think about it, these controls are not anything new that we haven't already talked about. Nothing is exotic with this. It is just the fact that you have a planned program approach to doing it. Okay, so the real blast radius. What can your developers do? What are they able to actually get access to? Environmental variables. Okay, so what are the things that developers can put keys in?

What do they have the availability for making changes within the environment? Configuration files on disks, cloud CLI profiles, database strings, service account files. These often have a long tail. They've been around for a long time. They often are not deleted. What do your developers have access to? The repository history, a secret committed in 2023 and then deleted in 2024, is still in the history today. Is that the case? Do you want to keep that or not keep that? That's an important part. And in reality, you'd have to ask yourself: is that information, that context, valuable to your company? Credential stores and tokens, session tokens for cloud consoles, the registry, and the identity provider.

Where are these tokens stored? Who has access to the tokens? Can someone copy the token and use it for some other aspect or activity? And then standing cloud access keys, the ones with no expiration and nobody rotates. These are an important part that many companies forget about. They create these cloud environments, they stand them up, they get them operational, but they, when it comes down to the roles and the keys that are tied to it, they never expire. And why do they not expire? Because they don't want to break stuff. And that's the big factor is they don't want these things to expire because when they do, things go down, things go south.

So it's just an important piece of all this. Key point in this, remembering short lifetime and tight scope are the only two controls that work on a path that you basically are going down. You need to have a short lifetime on all the credentials you have, and you need to have a tight scope on what they're allowed to connect to and what your developers are allowed to connect to. Now, controls for the agent in your editor. You need to treat generated code as an untrusted input. So again, any unreviewed contribution from a source has no accountability, you need to make sure that you review this one.

It's an important piece. Verify every package name. A model can invent dependencies that do not exist. Somebody can register that name and then just wait to see what happens. Scope the agent's permission. What files, what network, what commands. The permissions need to be scoped specifically on what that agent is supposed to do and the configuration related to it. You need to pin and review the tooling. Versions, publishers, extensions, auto update is an unreviewed change to a privileged tool. And you need to make sure that you don't do that unless you feel extremely confident that you are willing to allow any sort of auto updates and that anything that's coming in is coming from a trusted source.

I will say that there are even the Microsoft's of the world can be a trusted source, can be a little bit problematic. You need to keep the human accountable. Approval of a merge is an accountable act. It does not become less so because a model just wrote it. You need to have a human involved in this. Even if the model, the AI model of some kind writes this, there still needs to be a person who's accountable for it saying, yes, I'm going to allow this to be pushed to production.

Exam Takeaways And CISSP Questions 35:13

So now, three questions you need to ask yourself today, this Monday, right? What is installed on our developer's machines? What is the editor, the versions, the extensions, and the publishers? Do you have licensing for all that? So if nobody can produce this list, then you really are looking at a challenge you need to figure out. That is a finding you need to look at with a single control. What can a developer workstation touch? What can it reach? Can it touch the cloud? Can it touch your internal network? Can it touch a data store? What can it touch? I would be willing to bet you're probably looking at a lot of systems that these developer laptops or systems, endpoints can touch.

Number three, what does our asset inventory call it? If the answer is endpoint, the classification predates that what that machine became. So it's important for you to know what's installed, what can they touch, and does our asset inventory call it out specifically? So again, question three is the one that changes budgets. The other two are how you prove it needs to be changed. Some key takeaways when you go into the exam room. Okay, 8.2 owns the environment. 8.5 owns the code you write, and 8.4 owns the code you buy. So again, the environment is 8.2, the code you write is 8.5, the code you buy is 8.4.

A feature toggle inside an application is not an isolation boundary. Basically, saying I'm going to turn that off is not an isolation boundary. However, it reliably it will work, and it does work in many different ways. However, that's not the one thing. And if you do utilize that as an option, you need to make sure that this is well documented on why you did that. There might be reasons why, but when it comes to the auditors and the folks that are going to want to know, they're going to know why you made that decision. SAST reads source. SCA reads declared dependencies, and DAS reads the running application.

None read the overall tool chain. So again, SAST is a source, SCA is dependencies, DAST is running in the app. The fourth one is a pipeline holds credentials and can deploy to production. So it is production. If the pipeline has the credentials and can deploy, it is production. A build identity with standing production access is the same finding as a human with it. Even though the build and it's good using AI, it's still, if it has that standing production access and it has the credentials for it, it's no different than a human. Deleting a committed secret does not remove it from the history. Rotation is the only fix.

We talk about this. Just because you get rid of a secret that's stored out there in history or in your uh your overall GitHub repositories, that is not a situation where it's it's gone. Only fix for this is rotation. The seventh thing is patching closes the path that was found. Scope and lifetime govern the one that was not. So again, if you have a scope, narrow your scope, and you have your lifetimes narrowed, then that helps in the situation where if something was not scoped, it was not found, it was not patched, the limit of the blast radius is much, much less. And then the last one generated code is an unreviewed contribution.

Approving the merge is still an accountable act, and the hat the computer, HAL, cannot do it. You want humans to do this. Okay, so let's get into four CISSP questions and see if you guys can find the traps. Okay, so question your post-incident review finds a malicious workflow file was committed to four of your repositories using a developer's credentials. Not good. The workflow read the project's CI secrets and posted them to an external address. Your head of engineering argues this is purely a credential problem. The count was compromised, so the control that failed is authentication. What is the flaw in that specific reasoning? A, multi-factor authentication would not have stopped a stolen token, which bypasses interactive sign-in entirely.

B, the organization had no detection for new workflows or workflow files, so the gap in monitoring rather than authentication. C, write access to the repositories, also write access to what runs automatically in the project secrets. So authorization model is the failure. D, secret scanning was not enabled on those repositories, so the secret should have never been reachable in the first place. Okay, so we had an incident, right? And they looked for a malicious workflow file was committed to four of your repositories using a developer's creds. The workflow read the project CI secrets and then posted them to an external address, which is bad, right? You don't want it to do that.

So your head of engineering argues this is purely a credential problem. The account was compromised, so the control that failed is authentication. What is his flaw in reasoning? Okay, so the and you all think the answer is C. C, the right access to the repositories, also right access to what runs automatically with the project secrets. So the authorization model is the failure. That's the problem. The authorization model is the failure because it's allowing it to continue to use those secrets. The trap is though, people would see the MFA and they would have stopped and thought, hey, this is a stolen token. And once it's a stolen token, that is what people will reach for first.

But again, authentication control is not the issue here. Or I shouldn't say the MFA is not the issue here. It's the overall authorization model is the problem. So again, think about this a little bit different. I know it's a tough one, but think about the fact is that it comes onto your repository and how it's automatically run with the secrets. Next question. After September advisories, your application security lead proposes expanding static analysis coverage to every repository in the organization. Okay, so you're gonna do SAS to every uh repository in the company, arguing it would have caught this class of issue. Your pipeline already runs static analysis on first party code, basically code you made, and software composition analysis against declared dependencies.

So if it's dependencies, it's looking for the different CVEs that are tied to it. What should you tell them? A, the static analysis examines source code, and the exposure here is the developer's tooling and the runtime behavior with which no source scanner reads. B, dynamic analysis should be added alongside it because the issue only manifests when the application is executing. C, software composition analysis is the correct control because the editor and its extensions are our third-party components, or D, expanding static analysis across every repository would exceed the current license and require budget approval first. Okay, so we're looking at this not from a standpoint of what is the technical piece.

We want to understand the managerial side of this. And the answer you all think is A. Static analysis examines source code, and the exposure here is the developer's tooling and its runtime behavior, which no source scanner will read. Again, your static analysis reads the source code your developers write. SCA reads the dependencies they declare. So the editor and its extensions and the agents running inside it are none of those things. So can understand that. Again, this very challenging answer, and it's almost right, right? The extensions are third-party components, and the SEA is generally the control family for third-party components, but it reads what your project declares: the manifest, the lock file, and so forth.

Nobody declares their editor. This is where it's installed on the workstation. So if you go back, after the September Advisors, your application security lead proposes expanding SAS to every repository in the organization, arguing it would have caught this issue. Your pipeline already does it. Okay, so it already does this on first party code. And the software composition analysis, against declare dependency. So everything there is running well. So therefore, C would not be it because it doesn't look at the editor. All right, next question. Your post-incident review establishes the following: every secret the malicious workflow could read has been rotated. So they rotated all of those.

The workflow file has been deleted from all affected repositories. Secret scanning is enabled and your team has reviewed 30 days of audit logs. Six weeks later, a new malicious workflow appeared in the two of the same repositories. Okay, so what was missed? So we talk about this. Your post instance review the following secret from a malicious workflow could read that they had was rotated. The workflow file, workflow file has been deleted from all affected repositories. Then the secret scanning enabled on your team reviewed the 30 days of audit logs. So now six weeks later, you Have this problem again. What happened? What was missed? A.

They extend the audit log retention beyond 30 days so the original point of entry can be identified in future reviews. B. Rotate the secrets again on a defined schedule because a single rotation after an incident is not a sustainable control. C require branch protection and pull request reviews so that no file can be committed without a second person approving it. Or D, the credential used to commit the workflow was never found and revoked. So the attacker retained write access the whole time. Okay, so what was the answer in this situation? And it's D, right? The credential used to commit the workflow was never found and revoked.

So they kept write access the whole time. So if you go back to the question, the the overall question it's asking is is it established them? Every secret workflow has been rotated. The workflow file has been deleted from all the effective repositories that they knew. And the secret scanning is enabled for your review of every 30 days of audit logs. But it pops back up. Why does it pop back up? Because the credential used to commit the workflow was never found and revoked. So they went and deleted the workflow files. They went and deleted the secrets that were in there. But what credential used and create that specific workflow?

They didn't look into that. So the attacker retained write access and just created another workflow. So again, that's an important piece of this. You got to kind of think through it step by step by step. Okay, next question. Your board has read about AI coding tools and wants action this quarter. Two proposals are in front of you. Prohibit AI agents featuring organization-wide or approve a single vendor tools and standardize on it. As a security leader, what should you decide? Okay, so you got to do this for your board. And they want you to do two proposals. Shut them off, don't let them. Or two, approve a single vendor tool and standardize on it.

What should you do? A provide the agent feature or prohibit the agent features until the vendor can provide independent assurance on how the tooling handles untrusted content. B classify the development environment according to what it can now reach and set control requirements on classified demand. C authorize a limited pilot with instrument monitoring and can ensure risk before committing either way. Or D approve the single vendor and stabilize, which reduces the number of tools you have to be assessed and or monitored. Okay. But which one is it? Hmm. And the answer is B. Classify the development environment according to what can you can now reach and set the control requirements that classify the demands.

So again, both proposals on the table answer the question nobody's established. What is in the environment and what is it allowed to reach? A development workstation that holds production creds and processes untrusted content has a different class of asset from the laptop running just the editor. And again, nothing in the inventory says that at all. So classifying the doc development environment according to what it can touch and what it can reach, and then set the controls related to that is an important part. So let's go back and look at that question again. Your board read about AI coding tools and wants action this quarter. Two proposals are in front of you prohibit or approve it, right?

That's really basically what it comes down to. What should you decide? And the answer we talked about is B. Classify the development according to what it can now reach and then set the control requirements that the classifications demand. Now, this the trap in this is A, prohibit until vendor provides assurance. Now it's decisive. That's appropriate right to the point, and it's appropriately cautious when you're dealing with AI. But again, assurance against what standard? No one has one written. So unless you have one written, it's really hard for them, for the per vendor or vendor to provide you some level of assurance. And so they'll just move on to somebody else.

So again, you really need to classify the development environment according to what it can reach.

Wrap Up And Next Steps 47:57

Okay, head on out to CISSP Cyber Training. That's all I've got for you today. Go check out these odd different aspects. I got the accelerator, the pro, and the sprint cohort. Sprint cohort's going to be having two sprints. We're going to be dealing with one either at 7 a. m. or at 7 p. m. It is up to you. You go pick one. It'll be live this week. You can go select which one you need. We're about a month out. Time to go do it now. Because I guarantee you, just like before, these will sell out. They do. They sell out every time. And they've been, I'm just amazed at how well these things have been doing.

Something for you to consider as you're going down this path. But again, go check it out, CISSP Cyber Training. com. All right, have a great day, 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 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 to the Captain Foods.