CCT 345: Practice CISSP Questions - Domain 8.4 (Replay)

A single compromised identity can turn your whole environment into a hallway of unlocked doors and cross-domain attacks are built to exploit exactly that. We start with a timely real-world breach theme and use it to explain how adversaries move between endpoints, cloud platforms, and third-party connections by abusing identity and privileged access, not just by running noisy malware. If your organization relies on a patchwork of identity tools, limited visibility, and “normal looking” logins, you may not see the threat until it has already jumped domains.

From there, we pivot into CISSP Domain 8.4 thinking: how to evaluate acquired software without guessing. We break down what to look for in open source software (community activity, maintenance signals, orphaned project risk), what makes COTS software uniquely hard to assess (no source code visibility for deep vulnerability assessment), and what matters most for SaaS and managed services (encryption for data at rest and in transit, plus clear SLAs that define performance metrics and incident response expectations). We also cover why the shared responsibility model is non-negotiable for cloud security clarity, especially around account management and access control.

We round it out with hands-on evaluation methods that map to both the exam and real security programs: threat modeling to uncover dependency risk, dependency scanning to catch vulnerable libraries, sandbox testing in a controlled environment, and periodic reassessments as threats evolve. If you’re studying for the CISSP or building a safer vendor and software intake process, this one gives you a practical checklist mindset. Subscribe for more CISSP training, share this with a study partner, and leave a review with the software risk topic you want us to cover next.

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

Join now and start your journey toward CISSP mastery today!

Transcript

Welcome And 2025 Kickoff

SPEAKER_00 0:00

Welcome to the CISSP Cyber Training Podcast, where we provide you the training and tools you need to pass the CISSP exam the first time. Hi, my name is Sean Gerbert, and I'm your host for this action-packed informative podcast. Join me each week as I provide the information you need to pass the CISSP exam and grow your cybersecurity knowledge. Alright, let's get started.

Treasury Breach And Cross-Domain Attacks

Identity-Centric Defenses For Modern Networks

CISSP 8.4 Software Evaluation Questions

Open Source Health And Community Signals

COTS Risks And Source Code Blind Spots

Managed Services Encryption And Data Access

Threat Modeling Dependencies And Attack Paths

SaaS SLAs And Shared Responsibility

Third-Party SDLC Risk And Dependency Scanning

Sandbox Testing And Ongoing Reassessment

Pen Testing Versus Static Code Analysis

Open Source Licensing And SLA Wrap-Up

Resources, Consulting Links, And Goodbye

SPEAKER_01 0:25

Hey, I'm Sean Gerber, CISSP Cyber Training, and hope you all are having a beautifully blessed day. We are after the first of the year. So you know what? It's great. It's awesome. We are into 2025, so it's pretty exc pretty cool. Honestly, I'm pretty excited about 2025. I think it's going to be an awesome year for everybody. And uh, I hope you all had a blessed New Year's Day and you were safe. Uh, I hope also that you had a great Christmas and that you are enjoying time with your family, and hopefully now you're probably getting ready to go back to work. So, as we do that, I hope you are also getting ready to study for your CISSP exam. And to do so, we've got some great content for you today, and it's based on 8.4 of the CISSP ISC Squared uh manual book, whatever you want to call it. Yeah. So we're gonna go ahead and get into that in just one second. But before we do, uh we I don't know if you all saw in the news just recently, there was a cross-domain attack that occurred with the Department, I think it's the Department of Treasury, uh, that there was based on some Chinese individuals that hacked into the Department of Treasury and they had used the uh Beyond Trust as their method of gaining access into it. Uh if you're not familiar, Beyond Trust uses identity and access management to help manage accounts. I think it's also a PAM solution as well. So getting access to a PAM solution, which is your uh password access management type of tool, is a very big deal. So it's pretty amazing that they were actually able to do that. And to do so, they it does allow them to gain access directly using identity and access management tools into their environment. And this article I have in here is about uh cross-domain attacks. Now, obviously, it's sponsored, I believe, by CrowdStrike, but one of the parts that I thought was really good in here, and this kind of relates back to the Beyond Trust uh incident that occurred, is they're saying that these cross-domain attacks have gained prominence, obviously, in emergency tactics and adversary from adversary's perspective. And so I'll use this from a red team point of view. If I don't have to, in the past, I would try to steal people's credentials. Uh, you would, you know, obviously try to log in when they're logging in and then utilize their certificates to be able to gain access to whatever credentials they have, and then you would then scale that on and go to another person and try to gain their access and then scale to another person and so on and so forth. Well, with the fact that these payam solutions, or in the case of just having passwords, I know that happened when I was on the red team, where we would just find a username and password that was out there and we would then gain access to it, and then we would just walk basically walk in the front door of these networks. Well, now that's happening as well across many different domains, and because there's there's so much proliferation between domains, you know, so if you have your your company and it's connected to Azure, and then it has uh a third party that logs into it and it has, let's say, activity within AWS, it's got uh networks in there, it now has the ability to move from one network to another network, and if you don't have a really good robust identity and access program, uh it could be very hard to even notice the real traffic from the potential bad traffic. Uh and so they're talking about this with the various weak points across multiple domains to include endpoints and identity systems. And their point was is that instead of breaking in, you now are logging in and you're leveraging compromise credentials to gain that access to the network. So it's it's a very interesting part. I think it's a really good article about in the Hacker News. Uh, and they talk about how that the you need to look for gaps within your security tools that are specifically so focused around identity and access management and ensuring that your security operations teams have visibility into these different gaps. Now they break it into three essential steps that you need to use to protect against cross-domain type attacks. One is identity at the core, right? So what you have a main identity provider at the core of your enterprise needs to be defined, it needs to be done. And you need to this helps by understanding limiting eliminating inefficiencies, also fragmenting tools. I've seen it time and again where you'll have multiple identity tools within an organization because they didn't go to just one at the core. So you need to get figure out which one you want to use and then deploy that. Now, I will tell you if you're deploying that to a larger enterprise, it doesn't even really matter if it's large, it will take time. Uh obviously, a large enterprise will take much longer with a lot more resources, but putting it in even in a medium-sized business, changing any sort of identity access uh for your people to help them go from just username and passwords to an actual identity provider will take time and it will take money. But it's going to be an important part of your overall security plan going forward. You also have to have identity visibility, and this is where you see the entire picture. This is end-to-end. They're talking anything from hybrid environment sprinting on-prem to then the cloud or cloud-to-cloud identities as well. And there's, I know one of the identity providers like Entra or Okta, that Okta just got recently hacked not too long ago. It was part of a breach that occurred. So again, you're you're gonna you you're opening up yourself some risk potentially with some of these identity providers, especially if they're providing you that specific guidance for all the identities within your organization. But at the same time, uh without it, you're now relying on individuals and their passwords, and it's just not a good option. So you really need to consider what you want to do with your identity. And then real-time identity protection. Now they're recommending obviously the AI Cloud Strike. Uh it's basically is always looking at your various endpoints. It's working for the telemetry between your identity, your endpoints, and your cloud environments, and it's looking for anything that would be anomalous. So I I like Cloud Strike, Cloud Strike, CrowdStrike, I like CrowdStrike, but um I would also make sure that whatever one you are looking for within your organization is something that uh will meet your specific needs. So it it looks for identity systems, blocking attacks before they escalate, and so forth. Uh, you can also use their managed service product as well that will help you with managing different types of activities. So, that again, great article around cross-domain attacks. It's in the Hacker News, and it's the rise of cross-domain attacks. Okay, so let's get started on today's questions. Okay, so as we get into this, this again is a dot four of the CISSP, and we're gonna be focused on a lot of different things around open source software, commercial off the shelf, and this is all tied back to the podcast that we had uh on Monday. Now, if you're listening to this, you may say, well, why does it sound a little different? Yes. So my family is still in town from the holidays, and so I am recording this in my garage. Yeah. So uh it unfortunately I have this fortunately, I have a lot of children and I have grandkids and all those things running around the house. So me talking in another room would probably wake up even the dogs. So I don't need to be waking children up. So we are talking in the garage. So sorry for the audio quality, but it'll be cool. All right, so question one which of the following best explains why evaluating open source software requires assessing community activity? So again, what is the following best explains why evaluating open source software requires assessing community activity? A to ensure that the software will remain actively remain will remain actively maintained and supported. So this is understanding the community in which you're you're looking at the software with. To determine if the software will integrate seamlessly with proprietary systems, to verify compliance and licensing terms with proprietary redistribution, to confirm that all contributions are tested by the software's original developers. So again, which of the following best explains why evaluating open source software requires assessing community activity? And the answer is A, to ensure that the software will remain actively maintained and supported. Again, you don't want some orphan software sitting out there that then somebody does something with. Question two, what is the primary security concern unique to commercial off-the-shelf software or COTS software? What is the primary security concern unique to commercial off-the-shelf software? A exposure to vulnerabilities from unmaintained dependencies. B obligation to disclose proprietary code under certain licenses. C. Difficulty in managing shared responsibility models with vendors, or D. The lack of visibility into source code for vulnerable assessments. Again, what is the primary security concern with COTS software? It is D, lack of visibility into open source or vulnerability assessments. Again, COTS software is proprietary, meaning that the source code is typically not accessible, right? Making it very difficult to determine or to do a in-depth vulnerability assessment. So therefore you can't look into it, and so you may not have the ability to see what's actually going on. Question three When conducting a security assessment of the managed services, which of the following is the most critical to evaluate? So when conducting a security assessment of managed services, which of the following is the most critical to evaluate? a the provider's frequency of community contributions, B the encryption algorithms used for data storage and transmission. C the availability of source code for static code analysis, or D the licensing terms for redistributing the service. Again, question three. When conducting a security assessment of a managed service, which of the following is the most critical to evaluate? And the answer is B, the encryption algorithms used for data storage and transmission. So you want to understand when you're dealing with a managed service who's a SaaS or an IaaS, how are they going to handle the data? How are they going to put it in storage? Are they going to use what kind of encryption algorithms are they going to use? Is an important part. Another thing to think about, though, kind of back to our main point that we had about the article, is your identity and access. Who within the company has the access to your data? So that's almost as important, if not in some cases, more important than the data at rest or the data transmissions of the encryption algorithms. The reason I say that is because most people are using some very similar encryption algorithms and they they kind of pride themselves on using military grade encryption. So just consider that as well. But identity is an important part. Question four, which step is critical during the software evaluation process for identifying risks introduced by software dependencies? In which of the following critic is critical during the software evaluation process for identifying risks introduced by software dependencies? A pen testing, B licensing review, C threat modeling or D functional fit assessments. In which of the following is a critical is critical during the software evaluation process for identifying risks introduced by software dependencies? And the answer is C. Threat modeling. Threat modeling again helps map for potential attack vectors. And it doesn't include everything, but it does give you an idea of what they could could possibly do as well as software dependencies. The ultimate goal with all of this is to think about it, is to sit down, kind of play the game of risk with your all of your software and try to understand what are the dependencies. And if someone attacks this, how is it going to affect my company? Question five, why is reviewing SLAs critical when evaluating SaaS solutions? Why is reviewing SLAs critical when evaluating SaaS solutions? A to confirm data protection policies and incident response times. B to ensure the provider adheres to open source licensing requirements. C to validate all sources or all source code that is available for auditing. And D to determine if the community supports the overall service. Question five. Why is reviewing an SLA critical when evaluating SAS solutions? The answer is A. To confirm data protection policies and incident response times. Question six, what is the primary risk when integrating third party software into an organization? Okay, what's the primary issue you run into when you integrate third party software into your company? A noncompliance with open source licenses. B increased attack surface due to insecure APIs. C. Dependency on community driven support, or D the lack of control over software development lifecycle. Again, third-party integration of software into your company. Which one is the primary risk of these four? And the answer is D. Lack of control over software's development lifecycle. Again, I've seen this time and again where people have developed software, maybe vendors have done it, they bring it into a company, and when you start asking some key questions around how it is developed, you realize they do not have a really strong software development lifecycle built up, and their developers are probably outsourced to some other country somewhere. So it's an important part to try to understand that when you bring somebody on, especially if you're running a critical type of software within your company. Question seven, what is the primary goal of dependency scanning during the software evaluation? Again, what is the primary goal of dependency scanning during software evaluation? A to identify functional limitations in software. B to ensure compliance with regulatory standards. C to detect vulnerabilities in libraries and frameworks used by the software. Or D to test the integration compatibility with existing systems. Question seven again, what is the primary goal of dependency scanning during software evaluations? And it is C to detect vulnerabilities in libraries or frameworks used by the software. Again, you gotta want to look for these vulnerabilities with you dealing with libraries. They can be very sneaky and they can be hidden. So it's important for you to understand where the libraries go and what is actually being pulled from those libraries. Question eight, which of the which type of acquired software is most likely to introduce risks related to unmaintained code? So which type of acquired software is most likely to introduce risks related to unmaintained code? A. Open source. B COTS. C. Managed Services or D. Third party software. Open source projects often rely on voluntary contributions, and some may abandon or for a lack of regular maintenance. Or they may be abandoned for that because if they don't actually have the maintenance. Somebody starts a project up, they use it, they like their software, and then life gets busy and they move on, and people keep us utilizing this software, but yet it has not been maintained in some time, and therefore it becomes orphaned. And once it becomes orphaned, then who knows what's going to happen with the software. And then I've seen it where that software gets put within organizations and they use it as a critical type of software within their company. Question nine, what type of what is the key reason for performing sandbox testing during software evaluation? So again, what is the key reason for performing sandbox testing during software evaluations? A to validate licensing terms, b to test the software's performance in a controlled environment, C to identify threats of insider attacks, or D to measure community engagement for open source projects. And the key reason for performing sandbox testing is B to the test the software's performance in a controlled environment. Question 10. Which of the following is the most important when evaluating long-term viability of open source software? So again, what's most important when evaluating long-term viability of the open source software? A the licensing model. B the frequency of vendor updates. C community activity and contribution or contributor engagement. Or D SLA response times. Well, we're dealing with open source, what is it? It's community activity, C and contribution or contributor engagement. Again, the more the people contribute, the more activity you have around it, the better and potentially more secure the software is. Question 11. In evaluating SaaS security, why is the shared responsibility model significant? So in evaluating SaaS security, why is the shared responsibility model significant? A, it ensures that encryption is the sole respon is sole responsibility of the provider. B, it absolves the organization of securing the software. D, it divides security responsibilities between the provider and the customer. Or D, it applies to only third-party software integrations. Question 11 is in evaluating SaaS security, why is the shared responsibility model significant? And the answer is C. It divides security responsibilities between the provider and the customer. So the shared responsibility model basically delineates which security tasks are managed by the provider and which the customer's responsibility. So again, you ensure that way there's clarity in the SaaS solution. Who's got what and who's flying the jet and who's not flying the jet. The shared responsibility model clarifies which security tasks are managed by the provider and which fall to the customer, i.e. account management. So again, the infrastructure security is for the provider, and then your account management, make taking care of your accounts, is with the customer. This helps delineate who is responsible for what and can help mitigate some potential issues you may have. Question 12. What is the primary reason for conducting periodic reassessments of acquired software? Again, what is the primary reason for conducting periodic reassessments of acquired software? A to address the new security threats and evolving risks. B to identify updates in licensing terms. C to ensure compatibility with organizational goals, or D to evaluate community engagement trends. And as these new threats come up and become evolve more, if you have an understanding of your software and you are continually reassessing it, it helps you ensure that you've got the best protections in place as possible. Question 13 What key factor distinguishes penetration testing from static code analysis? Again, what key factor distinguishes penetration testing from static code analysis in the software evaluation process? A penetration testing simulates real-world tactics. B penetration testing focuses on licensing compliance. D static or C static code analysis issue or tests runtime behavior. And D static code analysis detects API vulnerabilities. So the key distinguishing pen factor between pen testing and static code analysis is A. Pen testing simulates real-world attacks. Again, that's the purpose of that is to help you with the potential attack that may occur from the outside. While static code analysis inspects the code for vulnerabilities, obviously looking for any issues that they may be having when it is executed. So something to consider when you're looking at the difference between pen testing and static code analysis. Question 14. Why is licensing review critical during software evaluation for open source software? So why is the licensing critic review critical during software evaluation for open source software? A to identify software functional requirements. B to determine if the software is actively being maintained. C to confirm the encryption standards for sensitive data, or D to ensure compliance with legal and intellectual property obligations. So the licensing review is what? Why is it important? Because D. You want to ensure that it's compliance with legal and intellectual property obligations. Seen it again and again. People will put open source products out there and they didn't do a real good job with their EULA, and they ended up giving away some really good software, but because they didn't tie it into any sort of licensing agreement around intellectual property. So you want to make sure that you look at it because it puts you on the hook if you're using it. And as a developer, you want to make sure that your licensing, your terms in your licensing meets or exceeds what you're looking for. So if you're putting something out there that could potentially make money for you and you want to keep it to make money for you, you better make sure that your end user license agreements are, your terms and conditions are right because it will open you up. Okay, the last question. Question 15. What is the primary role of SLAs in a managed service evaluation? What is the primary role of SLAs in a managed services evaluation? A defining performance metrics and incident response expectations. B. Guaranteeing that source code will be available for review. C. Providing open source licensing information, or D establishing community participation guidelines. Again, the primary role of SLAs is defining performance metrics and incident response expectations. You really want to have that defined because if you don't and something goes bad or goes sideways, now you have everybody's pointing fingers at everybody else saying, Well, you said this. Well, no, that's not what my SLA says. Well, you said that. Well, that's not what my agreement says. And then it just becomes a bitter mess, and you're not dealing with the actual problem. You're you're you're you're trying to deal with the problem, but then you're also dealing with the legal issues that go with it. So it's very, very important that you have this decided and set prior to uh getting everything signed and in place. So these SLAs are really, really important. Okay, that is all I have for you today. I hope again you guys had a great new year. Head to CISSP Cybertraining.com and you can check out all the free stuff that's there. You can also check out some of the paid stuff that's there. Amazing. It's all available to you. Again, this video will be available on the website itself on CISSPcybertraining.com. So you can see the video as well as the audio stuff is there as well. Also, if you are looking for a security professional to help you with your organization, head on over to reduce cyberrisk.com and check it out. There's a lot of partners that are there. I've got everything you could get you would need. If I don't have it, I can find somebody for you because we've got some really great partnerships with various organizations. If you're looking for software, I have the ability to get you software at a really good price as well. So all of these things are at Reduce Cyber Risk. So again, CISSP Cyber Training, head on over there, get some free stuff, and then go over to Reduce Cyber Risk if you need some consulting work done for you and your organization. All right, have a wonderful day, and we will catch you all on the flip side. See ya.