CCT 305: Practice CISSP Questions - Chrome Zero Days And Domain Eight Deep Dive

Check us out at:  https://www.cisspcybertraining.com/

Get access to 360 FREE CISSP Questions:  https://www.cisspcybertraining.com/offers/dzHKVcDB/checkout

Get access to my FREE CISSP Self-Study Essentials Videos:  https://www.cisspcybertraining.com/offers/KzBKKouv

Headlines about eight Chrome zero days aren’t just noise—they’re a prompt to act with precision. We open with the fastest, most reliable steps to reduce exposure: force updates with MDM, restart browsers to trigger patches, narrow to a hardened enterprise browser, and brief your SOC to tune EDR for active exploit patterns. You’ll get a focused checklist that’s quick to run and easy to defend to leadership.

From there, we turn the lens to CISSP Domain 8 with five questions that teach more than they test. We explain why strict schema validation for JSON beats blanket escaping, and how misuse and abuse case analysis during requirements gives you the strongest assurance that security is built into design, not bolted on. We also break down supply chain risk in CI/CD with a practical recipe: software composition analysis, cryptographic signature checks, internal artifact repositories, and policy gates that block malicious or license-violating packages before they ship.

Design flaws are the silent killers. We highlight a common mistake—putting sensitive business logic in the browser—and show how to move decisions server-side, validate every request, and protect against client tampering. Finally, we get tactical about containerized microservices: image signing plus runtime verification, read-only filesystems, minimal base images, and network policies that enforce least privilege. These are the controls that turn incident response into a manageable drill, not a firestorm.

If you’re preparing for the CISSP or leading an engineering team, you’ll leave with strategies you can apply today: browser patching that sticks, threat modeling that finds real risks, SCA that calms your pipeline, and container security that proves runtime trust. Enjoyed this conversation? Subscribe, share with a teammate, and leave a quick review to help more people find it.

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

Join now and start your journey toward CISSP mastery today!

SPEAKER_00: 0:00 

Welcome to the CISP Cyber Training. We provide the training and you need CISP exam. Hi, my name is Sean Gerber. I'm your host. Join me each week as I provide the information you need. CISP exam and grow your cyber checker in the knowledge. Alright.

SPEAKER_01: 0:25 

Good morning, everybody. It's Sean Gerber with CISSP Cyber Training and hope you all are having a beautifully blessed day today. Today is CISSP question Thursday, and we are going to be doing a deep dive into domain eight of the CISSP exam. But before we do, we want to go over just an article that I saw recently as in the bleeping computer, actually, as of this morning. The interesting part with this is Google fixes eight Chrome Zero Day Exploits in attacks for 2025. Now Chrome has been having some challenges lately, I should say in 2025. There was a few more of these that were high high viz patches that they had to update. And basically the vulnerability that there is a situation with this specific article is around there was a coding mistake within Chrome's graphics engine, which allows attackers to push more data into memory than the program would anticipate or expect. And as a result, what would end up happening is that this would intentionally, if they did this intentionally, it can break Chrome's the way it normally works, causing the browser to crash, or potentially, in the worst case scenario, run malicious code on the system if that were to be the case. So because they confirmed that this is already out there, it's already being used, they wanted to actually get ahead of this as fast as they could because of the zero days that are out there running right now. So it's it could happen specifically by someone just visiting a malicious website. So that's that's kind of a bad thing. And so therefore, if you have Chrome, there's some things we would I've obviously I would recommend you start doing. Uh that would be one is to upgrade the Chrome. That would be the minimum viable product at this point, but you'd want to make sure that you update the system. So until you update it, your systems will remain directly exposed. And so therefore, you really must get it done as soon as you possibly can. So, what are some things that obviously that we run into? And this is an axe aspect that I ran into in different uh when I wasn't part of my company that's with before, is how do you deal with Chrome and how do you deal with all these updates? And it could be Chrome, it could be Firefox, it could be Windows, uh, it doesn't really matter. But you anytime these browsers that are out there doing these aspects, what should you do to make sure that you're best protecting you, your company, and the individuals that are actually surfing the web? So, what you could do is if you have an MDM or mobile device management type of product, you could force updates. Uh, that would then force the Chrome update to these systems, and that would be a really good way for you to ensure that if you have uh them deployed, they're updated as quickly as possible. You can also set up as an enterprise browser if you have a specific browser, like say you have Firefox and Windows, maybe narrow that down to just having one uh browser as your options so you don't have multiple systems that are actually running. Uh, I would highly recommend that you would push something to them to restart your Chrome. So that should do the auto update if you don't update it yourself. Uh, one thing to also think about that I I saw we dealt with this once before is creating a um like Island IO actually has a really good product out there where they will it creates a bubble around your Chrome browser so that no malicious activity can get outside of what you actually see. So it's a really good product. Um evaluated it for a while, and that was it was pretty cool. It has great potential, I would say, depending upon what your financial situation is with your company, it may be something you want to do. I mean, browsers are one of the first things that people can actually get access to when you know for people surfing the web. So I would highly recommend maybe just considering some of these different uh systems out there. Now, Chrome can limit it to just itself. So you can have just the Chrome browser, you can harden it up, you can lock it down, uh, and then maybe that is just all you need as well. Maybe you don't need to have one of these other kind of fancy tools that are out there. Uh, what you might want to do with your security operations center obviously is let them know that you what's going on if they haven't already attuned to it. Uh and you may want to tweak your EDR uh endpoint detection response kind of rules to make sure that they are looking for this type of situation. So, again, that it's an important part of your overall plan. Since they are zero days out there and they are actively being exploited, um, I would highly recommend that you do upgrade your um your Chrome browser at this point. Push that out to your people if you haven't already done so. So, again, the bottom line is from the bleeping computer, it's basically states that eight Google fixes eighth Chrome zero day exploit. It's in the wild right now. So it's eighth one that has occurred uh since 2025. Okay, so let's get into what we're gonna talk about today. Okay, this is over domain eight. These are deep dive questions associated with domain eight. You can get all of these at CISSP Cyber Training. I've got a lot of great stuff available to you at CISSP Cyber Training. Just head on over there and check it out. A lot of free stuff. You can get my free essentials program, or you can actually, if you're interested in more of a deep dive, more concierge kind of plan to study in for the CISSP, look at some of my paid products as well. Those are all available to you at CISSP Cyber Training. And so including this deep dive question. So, what I'd like to do is I have I have thousands of questions at CISSP question cyber training. And so the point of it is those I want to do some deep dive into areas that I felt were really important. And as we go over each of the various CISSP domains, this is going to be five questions that are going to be tied to that. So you can get these access again through CISSP Cyber Training. Just head on over there and grab them. Okay, so deep dive, domain eight. Question one. A development team is designing an API that processes user to supply JSON objects. Which control most effectively prevents injection attacks during the JSON parsing? Okay, so we're gonna as we talk about it, CISSP cyber training, we want to get a little bit deeper into these, right? These are the goal of these is to get a little bit broader, a little bit tighter, uh, and not quite so broad in discussion. So A, implement strict schema validation with enforced data types and required fields and allowing value ranges before processing. B using HTTPS to encrypt all incoming JSON payloads, C logging all JSON parsing errors for troubleshooting, or D requiring or replacing all special characters in the payload with escape sequences. Okay, so let's break each of these down and let's just see what we come up with. So let's go with ones that I know I'm not gonna go to the ones we know are not correct. So let's go replacing all special characters in payload with escape sequences. Now, a blanket characters escaping is insufficient because the injections obviously will occur through the encoded, nested, and type-based ways that they're getting into this. And therefore, escaping does not address any of the controls that are tied to it. Now we'll go into C where logging all JSON parsing errors for troubleshooting. Logging will help, obviously, with the overall debugging piece of this, but it will not prevent exploitation. It's great to have the logs, it's great to be able to look at them, but if you're someone's exploiting these systems, it's not going to fix that problem at all. Using HTTPS to encrypt all incoming JSON payloads. Now, again, HTTPS is great. It does protect the data in transit, but it doesn't validate the content isn't malicious. So therefore, all you're doing is you're putting a nice wrapper on it. Again, it's a control, but it's not the most effective control that you would want to use in this situation. Implement strict schema validation with enforced data types, required fields, and allowing value ranges before processing. So this is the correct answer, and this would be A. So this the schema validation prevents malicious or unexpected fields that are put in there, right? So if someone puts a field in there or has data that's in a field that is incorrect, it will notice that, right? So that you're it's or it's not going to allow that to occur. Type manipulation, nested objects, and oversized values, these will not be allowed into it when you put this various tricks schema and it's validated before it's even put in. Strong type and range enforcement will also block common injection paths by record rejecting the malformed or dangerous structures before executing in the overall flow. So again, you want to make sure that having that data types and having that strictly brought down is going to be extremely valuable. Now, the problem this comes into is your development team is going to have to understand that so often, I mean, so often, they will put in validation types that are, they don't really even put them in. They just want it in there, they want it going, and they want the product up and running. And therefore, because of that, what ends up happening is they're just looking for vulnerabilities. They're not actually looking for some of the different types of malicious uh coding that someone could put in place. So again, you're gonna want to work with your development teams to make sure they understand the best process around this. Question two, which activity provides the strongest assurance that the security requirements are correctly incorporated before coding begins? Again, which activity provides the strongest assurance that security requirements are correctly incorporated before coding begins? A conduct static application security testing, or SAST. B perform misuse or abuse case analysis during requirements development. C running a dynamic application security test, or D A S T, that's Delta Alpha Sierra Tango, or D executing integration testing in pre-production environment. Okay, so which activity provides the strongest assurance that security requirements are correctly incorporated before coding begins. All right, so let's go to the ones that are not correct. So executing integration testing in a pre-production environment. So integration testing will verify obviously the interactions, but it does not add or does not understand the correctness in the situation with the code, especially in when you're dealing with early security requirements. So integration testing is great in the pre-production piece, but your code is going to change over time. And so, therefore, those are not actually the best way, the strongest assurance to ensure that your security is in place. SAST and DAST, these are this is will basically occur later when the code actually exists, but putting them in prior to the overall uh security situation, it's not the best option. So you're basically your option D, running dynamic security test and C, or should say A, are not the best option. So the best option is performing misuse or abuse case analysis during the requirements and the development phase. So when you're looking at different use cases around how could this be misuse or abused, it's important for you that to walk through your could with your team to so that they understand this. And the really the all ultimate, ultimate point on this is that as a person is you're you're doing threat modeling, you're going down, you're talking with people, you're talking to your developers, and you're mentioning to them, going, okay, if if you guys put this capability into the development world, into your application, what is going to happen? What could the bad guys or girls do if they were to gain access to this? And this is that threat modeling piece is where you're walking through it with them. So as you're walking through this, it helps them understand how the attackers could potentially violate the business logic in this, allowing the security requirements to be to be developed so that they know going into it, going, well, if this happens in this code, if this happens in this situation, these are the different outcomes that could occur. By doing this, this does help you put in place preventative controls that are embedded into the design. Again, reducing the expense of rework at a later time. So think about that. When you're trying to develop this code and it's coming out, what are some of the things you could consider and how could it potentially be misused? Question three Which practice most effectively reduces supply chain risk in DevOps pipeline where third-party libraries, not your open source libraries, are automatically pulled during builds? So using third-party libraries that were created, and now you're pulling those into your overall environment while during the build process. So A rely solely on open source libraries because their code is publicly visible. B enforces of software composition analysis, SCA stage, that checks for known vulnerabilities, license issues, and verifies cryptographic signatures and all dependencies. B or C allowing developers to approve dependencies informally during the sprint reviews, or D only using the latest version of each dependency to avoid outdated packages. Again, which practice most effectively reduces supply chain risk in DevOps pipeline where third-party libraries are automatically pulled during builds. Okay, so true to form, let's focus on systems or on questions that were not correct. A, or I should say A, yeah, a relying solely on open source libraries because their code is publicly visible. Open source does not guarantee safety, right? Just because the code is publicly visible does not necessarily mean that it's being looked at by everyone, and also malicious content can be added to it. Now, one of the things that I know developers I've been working with, uh they will go grab from just known trusted libraries that have never had any issues. That is a good way to start, at least, but at a minimum, you should have something else besides that to ensure that the code that's coming in uh is being properly evaluated. Then C, allowing developers to approve dependencies informally during the sprint reviews. Okay, so having a developer do this is manually is not consistent and is definitely not scalable. So you shouldn't have them approve dependencies during this process. It needs to be automatically done. Uh, and so therefore you need to have a way to basically manage the code that's coming into your environment. D, only trust the latest version of dependency to avoid outdated packages. Okay, using only the latest version can't introduce new vulnerabilities and does not validate trust, integrity, or licensing. So the answer would be B, right? Enforcing the software composition analysis or ECA stage that checks for known vulnerabilities, license issues, and verifies cryptographic signatures of all dependencies. So SEA solutions will detect vulnerable, malicious, or policy-violated third-party packages, which is great, right? So you may want to consider that, ensuring that they come from a trusted source. Uh, signature verification prevents the dependency hijacking and tampering of the specific artifacts. So it's an important part. SCA will again check for all the known vulnerabilities, but it also deals with pilot policies and any sort of uh that it comes from a trusted environment. Question four during a threat modeling of a payment application, which concern indicates a design level flaw rather than an implementation level bug? Okay, so a improper SQL query contentation in the checkout module, b lack of server-side validation of the credit card form. C, use of deprecated cryptographic functions in a single authentication component, or D sensitive business logic executed entirely on the client side browser. Again, so during the threat modeling piece of a payment application, which concern indicates a design level flaw, basically overall design, rather than an implementation level bug. Okay, so let's start with the incorrect answers. So SQL concatenation, missing server validations, and deprecated crypto, basically A, B, and C, they are very important, obviously, but they represent the coding slash implementation issues and are not architectural design flaws. So these are more of just implementing versus the actual overall design of the architecture itself. So design flaws can carry higher risk and are more expensive to correct later in the SDLC. So therefore, it's important to understand the overall design failures ahead of time. And the design failure would be D, a sensitive business logic executed entirely on the client side, server browser. So the client is going to get this information. It's going to then run it all on their browser. And by doing this, it's you're putting critical business logic on the client, i.e., pricing, discount rules, any of those things. That would be an architectural flaw. Why? Because that information could be compromised on the device itself. Because you're not dealing with it on your server side, you're dealing with it on the browser side, the client browser side. So the attackers can modify client code or bypass the checks completely. So that's an important part that that would be a design flaw that was done from an architectural standpoint and would need to be fixed immediately. Question five. The development team deploys a microservices application using containers. Which control best ensures the runtime integrity of the deployed services? So again, you have a cloud environment, they're deploying microservice applications using containers. Which control best ensures the runtime integrity of the deployed services? A using verbose debugging or debug logging in production. B performing unit testing on all containerized components. C, enforcing image signing and runtime verification so only trusted and cryptographically validated images can execute, or D allowing container images to be pulled directly from the public registries for agility. Okay, so which control best ensures the runtime integrity of the deployed services? So as we look at all of these, right, pulling directly images from the public registries, we kind of already highlighted the fact that that's not the right way to go about it. It can introduce significant tampering and potential malware risk. Performing unit testing on all containerized components, right? This improves code quality but does not protect the runtime integrity of those systems. And then using debugging or logging in production, debugging and logging will increase exposure and can leak sensitive information. So the more logging and buggy, debugging you have turned on can actually highlight more of a problem. So which control ensures runtime integrity for deployed services? And the answer is C, enforcing image signing and runtime verification so only trusted cryptographic validated images can execute, right? Image signing ensures only validated or untampered basically images can run. And then runtime verification prevents unauthorized or malicious containers from being executed. Obviously, mitigating any sort of risk, such as supply chain compromise or registry poisoning. So those are the questions. All right. Again, thank you so much for joining. That's all I've got for you today. Head on over to CISSP Cyber Training. Get the free stuff that's there. It's awesome. It's a lot of great free stuff that's available to you. Go check it out. CISSP Cyber Training. If you need some more concierge help or you need some just some direct help from me, go look at the other paid products that I have available to you all at CISSP Cyber Training. All right. Thank you so much, guys. Have a wonderful 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.

SPEAKER_00: 19:37 

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.