CCT 328: Security Impact for Acquired Software (Domain 8)

Stop guessing which software to trust. We break down a clear, repeatable path to evaluate commercial off-the-shelf tools, open source projects, custom third‑party builds, and cloud services so you can pass CISSP Domain 8.4 with confidence and protect your environment in the real world. We start with exam-winning tactics—how to slow down, read for intent, and think like a manager—then move into concrete practices that tame software risk without stalling delivery.

You’ll hear how to interrogate vendor claims, separate real certifications from marketing fluff, and judge patch cadences and incident response maturity. We dig into open source realities: vetting contributors, scanning dependencies against the NVD, building and maintaining an SBOM, and avoiding abandoned projects that explode under pressure. For third-party development, we outline what strong contracts look like—SLAs with teeth, security clauses, indemnity—and the proof you should see: code audits, SAST/DAST, penetration tests, and meaningful logging around integrations.

Cloud isn’t a shortcut; it’s a shift in responsibility. We map the questions that matter for SaaS, IaaS, and PaaS: data protection, tenant isolation, hypervisor hardening, API security, and event visibility into your SIEM. Then we stitch it all into an evaluation workflow you can run every time: functional fit, vendor validation, layered security assessment, compliance and licensing review, sandbox integration testing, and a deployment plan that defines fix‑forward and rollback before anything hits production. Wrap it with monitoring, periodic reassessment, and documentation that procurement, IT, and security can actually use, and you’ve built a trustworthy software supply chain.

If this helped you think sharper about software risk and the CISSP exam, subscribe, share it with a teammate, and leave a quick review telling us your top vendor vetting question. Your feedback shapes future episodes.

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 Listener Q&A

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. 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.

Test Strategy: Pace And Judgment

Thinking Like A Manager

Domain 8.4 Overview

COTS Software Risks And Reviews

Open Source: Benefits And Controls

Third-Party Custom Software Risks

Managed Services: SaaS, IaaS, PaaS

Cursory Tools Vs Real Assurance

Cross-Cutting Risk Practices

Software Evaluation Process

Threat Modeling And Supply Chain

Operational Readiness And Monitoring

Maintenance, Reassessment, And Patching

Documentation And Knowledge Sharing

Closing And Resources

SPEAKER_01 0:25

Hey, I'm Sean Gerbert with CISSP Cyber Trading, and hope you all are having a beautifully blessed day today. Today we're going to be getting into domain 8.4, and we're going to be focused on different types of software. But before we do, I had a couple uh questions that came from one of my students and wanted to kind of share that with the group. Now, I will tell you, I'm looking to move away from this uh current process I use with video ask. I'm gonna go stick with, I think go move to Voxer just because for my students that have a part of my paid prop product. The reason I say that is because I haven't been getting some of the names that are tied to the overall uh video ask, and so now it comes in anonymous. So if you're listening to this, guess what? You are you're probably going, oh, that's me. Well, I don't have a name. So if you can email me your name, I can probably answer some of these questions a little bit better. Uh but needless to say, we will be moving away from video ask. But one of the just gonna do a couple questions real quick, and one of them was is that the individual says they go through the questions too fast, which is causing them to miss key points, incorrectly assuming that the question that's being asked. So we've all struggled with this, right? We all struggle, we go, I got it, I know it, I know it, and we just zip through it, and then you end up answering it incorrectly. What I recommend, highly strongly recommend, is that you take your time. You do have time around two and a half minutes per question to be able to take the test. Now, you're gonna go through some of those faster than then needing the full two and a half minutes, but that being said, you want to make sure that you read the question in a slow, methodical way and answer the question accordingly. You also want to keep track of your time, right? You want to know what your time is, but at the same time, I'm saying time a lot, you want to make sure that you are going through it a steady clip. So again, slow yourself down, read it completely, understand the question before you answer it, and then it kind of rolls into the next question they had was I don't trust my gut or I don't trust my feelings on what is the actual correct answer. And the answer to that is what do you do? You slow down. If you immerse yourself in the CISSP cyber training, you immerse yourself in the different types of aspects that we've recommended in this courseware, you follow the blueprint, you will have immersed yourself in so much information that you will understand the content, your subconscious will understand the content, and you will feel much more in a better position to answer the correct question. Even if you're not totally sure, if you answer with what your air quotes gut says and what you feel inside, your odds are higher that you will get the most correct answer. It won't be right all the time, but your odds are better that if you go with what you feel it is after studying a lot. Again, if you don't study, well then hey, you're just you're guessing, right? But if you study a lot, go with what your your gut says and it will occur. It'll be a much better option for you. And then lastly, is the individual there struggles with thinking like a manager. And I think that's an important part that that most people do taking this test, is they come with a strong technical background, because you have to have that based on your years of experience. You have to have at least some level of background, and they sometimes rely on their technical background on how they would answer these questions. You gotta ask yourself, how would my manager answer these questions? If they would answer them different than you, then odds are how you want to go with what your manager would how your manager would answer them. If they would answer them the same, well then hey, you're both on the same sheet of music. It's just important that you want to think like a manager when you answer these questions. They understand risk a bit differently than you will. So again, that just some key concepts for you to consider. Okay, so let's get into domain 8.4, and this is around assessing the security impact of acquired software. Again, you get all this information at CISSP Cyber Training, just head on over there and you'll get uh any of my programs. You can gain access to all of this content, all the video content, all the written content, everything. Uh, if you you go to my website, you go to the blog, you'll actually have availability to see this recording as it's posted and go from there. So, what is commercial off-the-shelf software? Now, commercial off-the-self-shelf software is a pre-packaged proprietary software designed for mass distribution. Now, the purpose of it is that it has minimal customization options. It's maintained by vendors, it's set up specifically for the vendors, and you see this a lot with your Microsofts, your Unix, or not Unix, uh, your Oracle, your industrial control systems. All of them have much custom, don't have allow customization. So now there are various security concerns as it relates to commercial off-the-shelf software. This includes lack of insight on source code, dependency on the vendor's patching schedules, and potential for embedded vulnerabilities or backdoors. Again, those can happen because you don't have the insight or the visibility into this software to ensure that it meets certain standards to you. That being said, they don't want to share this maybe because of its intellectual property, whatever it might be. Those are some of the security concerns that can occur from a already pre-packaged commercial off-the-shelf type software. Now, how do you assess this? So, this can be done in a couple different ways. It can be done through security evaluations or like security assessments. This would look at the reputation of the software company. Do they have any certifications in place? Uh, do they allow some level of audit done on their software? And could it be done by you? So those are some different kinds of evaluations you can do. Review of patching and updates of the policies. How often do they do their patching and how often do they update the policies that are pushed out? Understanding that, if it happens routinely, then maybe that's a more trustworthy group. But if you're dealing with something that's very rare and infrequent, maybe that's something you don't want to put within your organization. Do they do testing and scanning, black box testing, vulnerability assessments, and so forth? Is that done? Do they have that kind of comes back to that certification at the top? If they have a cert, if they've been certified, especially like ISO 27001, they would probably have some level of this documented black box testing or vulnerability assessments behind it. And then also look at their licensing and end user license agreements or their Eulas. This again would help you to uh do analysis for compliance based on those situations. The other part with dealing with open is we we talked about commercial off-the-shelf software. Now we're going to talk about open source software. They're different in the fact that open source software is a source code that's freely available to review, modify, and distribute. Now, it doesn't mean it's all open for those things. Sometimes they have open source software that might be a little bit more proprietary, uh, and then they open up part of it for you to review. But bottom line is that that's what open source software allows, is that you can review it, modify it, and distribute it. Now it's developed and maintained by communities or individual contributors as well. There are the security concerns that come with this: the risk of unmaintained or abandoned projects, potential inclusion of malicious code by contributors, or lack of formal support and accountability. Again, you have to understand what who's contributing, what type of information are they contributing, is that something that could potentially cause you challenges if you were to use their software. I've seen it time and again where I've got individuals that are grabbing any sort of open source software and putting it in the enterprise. That can cause you challenges. It can cause you a lot of challenges. But it doesn't mean it's all bad. It just means that you need to have a good program in place to deal with open source software. Now, the assessment strategies around this is you have code reviews, right? So you have static analysis, community vetting, or history of commits. And I say air quotes commits. So if somebody commits software to a repository, do you know who they are? Does this person commit a lot of software to the community, or is it rare and one-off type of situations? If it's a rare and one-off type situation, you may want to have a better look at what ends up happening with their software. That doesn't mean that people's accounts can't be hijacked. There's a lot of things that go into it. But again, look at the breadcrumbs to help you determine do you want to use this software or not. Dependency analysis, ensure all libraries are secure and updated. Do you have your libraries? Are they in a place where uh do you know what libraries are being used? Are there hidden libraries? Or are there calls to these various libraries that are not very used very often? Also, you want vulnerability database checks using the National Vulnerability Database, the NVD. Now, if you have a CICD pipeline in place for to do your code reviews, uh, it could automatically do that for you. And it would then call to the NVD and see if there's any sort of known vulnerabilities with some of this code that's out there. It's not the be all end-all, it's not the catch to everything, but it's a good way to help this overall process. Then policy on updates and security patches. Do they have are they updated? Is there patches for it? Who does that? Who provides those patches? Again, open source software can be very, very valuable, but it also can be very Wild West-ish. It can be something that you don't know what you're actually getting, and it could cause you challenges in the future. Now, third-party software, this is software acquired from external developers or vendors with a distinct in-house or open source software. Now, this can use custom solutions tailored to meet specifically to your organizational need, organization's needs. So if you contract with a third party to develop you software for this specific widget, that would be the what falls into this. Again, very similar to some of the stuff that it's kind of a combination between the closed uh or regular COT software and open source, but they may let you have some visibility into it, they may not. But it's basically contracting with a third party to help you with developing software for your company. Now, there's a lack of visibility from a security concern, there's potential or weak supply chain security practices. I would highly recommend, they probably are, and there's dependency on vendor-provided software updates and support, which doesn't seem to happen very often. So again, you want to be very careful when you contract a third party to build you software. You better have a plan for it. Assessment strategies, is there a vendor risk assessment on this third party? Do they have certifications related to the software they develop? Have they had any past breaches or incidents related to uh anything? Right? Because did someone steal their source code? Did someone steal get access to their client list and so forth? Are there contractual agreements with SLAs, security clauses, and indemnity for breaches? Is that built into their contracts? Do they do security testing? That would include pen testing, code audits, or even application security testing. They need to be able to tell you what they do. If they can't tell you how this process works and how they go through vetting and they just say, we do security vetting, but they don't tell you how they do it and they don't demonstrate how they do it, you need to run away very fast, okay? Because the bottom line is they probably don't have something. Or they have a half-baked, not fully built-out solution. Do they have monitoring and logging for these third-party integrations? How are they watching? So if they have source code, they have code that they develop that interacts with other people, that maybe reaches into other organizations and pulls data out. Is there logging and monitoring on these? Is that in place? So again, some very key concepts, but some very quick questions you need to make sure you ask. If any of this stuff does not seem right, go with your gut. It might not be right. So it's something to consider. Now manage services. We're dealing with SaaS, IaaS, and PaaS. So SaaS is your software as a service. This is an end-user application hosted and managed by the provider, right? So you'll get these out there in the cloud. Uh, they have the software available for you. Uh, some things you want to consider when dealing with them is have they had any breaches, insider threats? Have they lit, do they have any sort of limited control over the configuration, or do you have control of the configuration? One of the things that we ran into with SaaS uh organizations uh that provide you a software is can do I have the ability to lock them out? So if they're hosting it for me, um, or they're they have that software out there as a service, can I lock them out from gaining access to the software? Do they have a golden ticket that allows them into my software? Some really important questions you need to ask. So, again, you need to review their their providers' data protection policies, encryption standards, and incident response protocols. It's an important part to think about when you're using software as a service. Now, infrastructure as a service, this would include your AWS, your Azure, anything that's providing you a service such as servers and storage out in the air quotes cloud or some other location. You need to make sure you answer they have a shared responsible model that they are responsible for the what are they responsible for? What are they not responsible for? That needs to be very well defined and detailed out. Do they have any, what are they using for a hypervisor? Are there vulnerabilities with that hypervisor? Are they how do they update these potential issues? That's again back to patching and updating. And then what about APIs? Do they allow APIs in? Are there insecure APIs that they're allowing to connect into their infrastructure? So again, if they're SOC2, ISO 27017, all of these different kinds of compliance requirements, if they can meet those requirements and they have certifications around that, that is awesome. And that's what you want. Do they have secure API configurations? Do they have a gateway that allows API connections in and API connections out? Do they have the ability to get to are they monitoring that actively? Do they put that into their SIM? All of those are some really key questions you need to ask the providers of these infrastructure products. And again, monitoring and shared resources. How are they sharing your infrastructure with somebody else? Are there multiple people? How are they doing that? How are they separating your infrastructure from somebody else that they're actually hosting as well? Platform as a service. This the characteristics around platform as a service is this is where it's designed for developing, running, and managing applications. So there's dependency on platforms from securing hosted applications, risk from third-party add-ons, and so forth. So again, you want to make sure that whatever platform they're bringing to the table, it's up, it's running, they have all of that, and they can then detail out what is their compliance strategy to meet the needs that you have around security. And this comes back to is understanding their security features, their integration monitoring, and how are they developing their security, uh, what kind of developer security do they have in place for their folks? So again, platform as a service, infrastructure as a service, and software as a service. Now, when doing software evaluations, you have a couple different options you have. You have a cursory type of evaluation. Now, this would be a binary analysis or other products testing looking specifically for security flaws. Now, it has a limited amount of capability, and a lot of it is dependent upon what product you purchase, but it won't give you the full suite of what you might need. In many cases, the tools do not have a full understanding of the application. And if you just rely specifically on the tool to give you a the checkbox, yes, you are good, then you may be giving falling down that trap of having that false sense of security. So using it as a cursory is not bad, but if you rely on it completely, it can put you in a position where you might be wishing you didn't. Now, do you have a secure development process though that has that utilizes different types of artifacts that are out there and then it is able to evaluate those? So again, public documentation, is there any sort of development process that they have? Is there any vulnerability response processes that they have? Are there guides that they've created on how they secure the configurations? How do they secure the code that goes into it? And again, you should also see are the developers striving to meet the standards of ISO 27,034, okay, and or IEC 62,443. These are this is where you know they have a really good secure development process in place. So that is an important part of what you want. And if you have that within your organization, that's even better. But you need to kind of understand how do they evaluate the software that one they're creating and two that you are creating or putting out to the public. Now, there's some costs or cross-cutting assessment practices that you want to kind of consider and that are really important. And we kind of already talked to them a little bit, but we'll just kind of go into a few of these. One is a risk assessment. Again, evaluate, you want to identify and evaluate any risks that might be associated with each of the software types. And then you want to put down what is the impact and the likelihood that these could occur. A lot of it comes down to is where is you where are you using this software? Is it internal to your organization? Is it on the web? Is it front-facing? Is it on a server that's sitting in the bowels of your system? Is it on a critical piece of equipment that's within your system that if it gets in trouble, something bad happens, that's bad. So you want to make sure you do a proper risk assessment of the software, and you want to ensure that it is there's potential impact and likelihood have been determined with that. Then there's also threat modeling. This is where you map potential attack vectors and their mitigation strategies. You will focus on integration points. Where does it come into the software? Where do they connect? And then also how the software works with your organizational systems. That's a threat modeling process. Now we talk about this in CISSP cyber training. There's plenty of opportunities for you to do threat modeling. We actually have a whole section just on threat modeling specifically, but you want to consider that within when you're looking at various software. Compliance and regulatory requirements. Are there, are you sure that the software aligns with the industry standards? HIPAA, GDPR, PCI, DSS doesn't meet with what those organizations are wanting. Are there regular audits? Are you completing regular audits or on software security practices and configurations? Are you doing it within your stuff or are you requiring that with a third party that you're working with? Is there incident response planning? Do they have a plan in place for contingency based on breaches or other types of incidents that they may occur? Have you do you have an ability to coordinate with the vendors for a timely resolution? Good example of this: industrial control systems. You may have to have a thing in place, a process in place already to deal with this in the event that your industrial control systems go down. So you may have to have those agreements in place prior to even going live. So it's an important thing you have already had that conversation both with the vendor and with your leadership on what are we going to do in the event of a situation, of an incident. That needs to be done ahead of time. Now we're talking about tools and best practices. There's various types of tools that are out there. So you have automated scanning tools that again are looking for vulnerability detection and source code and the binaries if they have access to it. Monitoring and logging solutions that are looking for real-time tracking of software behavior and anomalies. This comes kind of comes into the UEBA type piece or even your endpoint detection and response type of capabilities. It's monitoring what does a software do? Is it going, does it do one thing and it starts doing something different than that? That would be you'd want it to know. You'd want to know if that situation is occurring. So that's a monitoring and logging type of situation. Threat intelligence, you're leveraging different feeds to identify emerging risks related to the specific software. Those are in place and you have that done. So, what are some best practices to consider when putting in place for your organization? One, you need to establish a formal software acquisition policy. So, do you have this policy in place on how you're bringing software into your company? Do you have a plan? Do you do you force people to follow this process, whether it's putting in certain tickets, they contact security? What is that? You must have that formal software acquisition policy in place, both for open source and COTS type systems. Conduct regular security training for procurement and your technical teams. Anybody that's buying the software, you want to make sure they're aligned with what you're trying to accomplish here. You don't want to do this in a vacuum where you have this great policy, but no one knows about it. You need to make sure you train the people that are buying the software for your organization what you're looking for. To avoid this helps you avoid a lot of drama in the future. I mean, because drama happens all the time. This is no different. This will definitely bring drama if you start setting a policy around what kind of software can and cannot be purchased for your company. You need to maintain an inventory of acquired software and their risks. I will tell you right now, if you have the both, you're amazing. If you just have a list of all the software in your company, you're good. It's hard to keep tabs on this, but it's an important part of having an inventory. Again, inventory like equipment, same thing with your software. You need to have this set up, especially if you're dealing with licensing challenges, because that can get ugly real quick if you have software that is not licensed. Yeah, it gets really expensive really quick. Uh perform periodic reassessments also to address the evolving threats. Again, want to do all of this. These are just some key best practices when you're dealing with security. Now we're going to kind of get into the software evaluation process. So, what does this look like? One is an initial screening. This is the functional fit. Determine how well the software meets your organizational and business requirements. And this would come down to use cases and how would these different types of use cases work with your existing systems. If you don't do the functional fit and you set yourself up for failure immediately, you will go and just go, hey, this is great software. I'm gonna buy it. You buy it and you don't do a functional fit, you're gonna regret it because you may end up having spent a lot of money on a software that you cannot use. So you need to do your due diligence, don't be in a hurry, make sure that you find the right software to meet your specific needs. You also need to do vendor or source validation, make sure you have the Right vendors based on what they're going to provide you. If you have a COTS, do they have a good reputation? Do they have market share? Do they have customer reviews? Buying something that is a startup, is that a good idea? Maybe, depends, but it could also be a substantial risk. Open source, again, knowing the community activities, the governance, and the project maturity of whatever open source project you're going to use. And then third party, what do they have the credibility? Are these folks going to give you a good product or are they going to be a flash in the pan where they show up today and they are gone tomorrow? Again, it's an important part of any sort of software you purchase is that you have a good plan to deal with this. Now, you also need to do a security assessment. Now, as a security assessment, I'm just going to go through some key different topics, which we've already kind of touched upon. Code reviews. If you can, if you can get access to it, do a code review of the overall software. Again, you might or might not be have that ability, but if you can, take a look at it. Give it to somebody who knows what they're looking at to maybe provide you some level of understanding. A vulnerability assessment. Use scanning tools such as Nessus, Qualis, others that are out there to look for any weaknesses you may have in this software. And then check the vulnerability database of anything that deals with this software, especially as if it's a COTS type of software. But again, you're doing a little bit of due diligence around it. Now, again, it doesn't mean that if it shows up there's nothing there today, it won't be there tomorrow. You still need to understand that at least you've gone through and looked to see if this software is constantly being hacked. Maybe it's something you don't want to put in your organization. Or if you do, you then know you know the risk going into it. Pen test. Maybe do a penetration test on this specific software security defenses to ensure that you understand where is it strong enough. Maybe verify the exposure of sensitive data or exploitable configurations. What are those? Depending upon the regulatory requirements around it, you may have to prove that. Maybe some level of auditing that has to occur. Data handling and protection. You need to understand and review the encryption practices and for data at rest and in transit. Again, I we talked about this before. Data at rest is very rarely ever at rest, but how is it in transit? What are they using to protect the data in between the different locations? And then ensure that it reach meets the compliance requirements of the organization that you're serving, GDPR, HIPAA, whoever it might be. Now do a compliance and licensing review. Again, regulatory compliance, is it validate the alignment with the industry specific standards? Does it meet the standards? If it does, most likely they've used it on their marketing paraphernalia saying we meet ISO 27001 or PCI DSS. But you need to validate it, verify it, make sure that they understand what they're actually validating towards. I've seen this happen time and time again. They will give a certification, and it is their own certification that they meet this criteria, which means nothing. If they were ISO 27001 certified, that's a whole different animal than just saying we are certified by ourselves to meet 27,001. Okay, that doesn't mean anything. So again, ensure that you understand what you're getting into when it comes to regulatory compliance. And then it last bing on that is make sure it meets the legal requirements for data security and privacy. You better make sure your legal team is involved on any software you purchase because this stuff will come back and bite you. Our legal, I've had legal teams on all the software purchases I've done in the past, and that is no different. You always want to bring them in. Licensing review, you want to turn the understanding the COTS license and permitted uses as well as any sort of software that they're providing. You want to make sure you understand the terms and conditions that go along with it. If you have open source, you want to make sure you understand the licensing behind that and also the impact on intellectual property. If you create something that is open source and you create and use it for intellectual property, is the intellectual property that you created out of this open source software now supposed to be open to the public? Maybe it is, maybe it's not. Something to consider there. Managed services, again, understand your SLAs and what is the coverage and liability for breaching those SLAs. So again, licensing reviews, regulatory reviews, all important to have your right people on the calls with you. Now, community and support evaluations are community or vendor support evaluations. This is where you have support capabilities with your open source. Again, assess the responsiveness and activity of the community support forums. Are they engaged? COTS and third party, do these contracts to hold the vendors to their feet to the fire? What are their response times? Is it plus or minus 24 hours? Is it plus or minus 24 days? What is that? What is the availability? Are they have managed services? Are they have 24 by 7 support? Is there escalation procedures and what are those? Does it cost you more money to escalate? Those are important parts to understand when you're related to the support. Documentation, is there availability for comprehensive installation, configuration, and troubleshooting guys? Is all that available or are they in little small pamphlets and basically just kind of point you through the basics and the rest of it you have to figure out on your own. Understand that it's a really important part of what is how is your vendor there to support you. Integration and compatibility testing. We kind of talked about this briefly, but you need to have a sandbox environment or a testing environment where you can deploy and test the software in a controlled environment to ensure that it doesn't blow everything up, right? You want to deploy the last thing you want to do is deploy this to production and it causes drama. And it will cause drama and then you get drama and then everybody has drama and it's never fun. So you want to make sure you deploy and test this software in a controlled environment, particularly in a potentially test environment with the correct applications. You need to observe the performance, behavior, and the potential resource usage. Now, you can't always do that, right? So if you can't do that, you better make sure you have crossed your T's and dotted your I's and you understand the risk before rolling it into production. And I would make sure that you phone a friend and make sure everybody else is aligned with your thought process because if you don't and you deploy this and it goes sideways, which sometimes it does, you will be looking for new employment and it will hurt your company. It's just not fun. So make sure you do it on the front end so you don't have to worry about dealing with it on the back end. System compatibility, you know, validate for seamless integration with existing applications, databases, and services, and test for conflicts or dependencies that might disrupt your operations. Always be looking for that. If it can go wrong, it will. And you need to plan for when it goes wrong because baby, it's gonna go wrong. I guarantee you, it will go wrong. APIs interface testing. For all of your fear of SaaS, your passwords, IaaS, anything that's dealing with externally, you need to make sure that you have you assess the security and functionality of APIs that are being used and that they're configured to prevent unauthorized access or data leakage. The other thing to think about is threat modeling and risk assessments. How does this work? We talked about that a little bit earlier, is around what are the potential attack vectors and the impact if you were to have it run into an issue. Assess the risks associated with the supply chains. Do you have dependencies on these supply chains? Because if they go down and they get hacked or they get ransomed, whatever it is, what how does that affect you? Need to have a plan with that. You need to develop a mitigation plan. Again, define the actions and address the identified risk. If you have an issue, how are you gonna address it? What are you gonna do? Think through it. Now, it's you're not gonna be all-encompassing. There's no way you can think of every possible scenario. But the fact that you just took the time to think about a scenario takes you so much further ahead than most people in this space. If you thought about, hey, if this goes down, what's gonna what am I gonna do? Even if you just what if it a few times, that is so much better than doing nothing at all. Prioritize based on the criticality of the software and the potential threats as well. So again, you need to develop mitigation plans, think of your threats, and then understand the software and the potential threats around you. Also look at operational readiness and monitoring. When you deploy this, do you have a plan to deploy it correctly? What are your deployment plans? Are there configuration plans? Do you have ongoing management plans? Is this setup ready to roll out? And do you have a plan to roll back if the option if you have failures? So again, a rollout plan is great. I'm gonna do A, B, and C. But if things go bad, what are we doing? You can fix forward, which basically means I ain't rolling back, we're gonna fix it and keep moving, or you're gonna roll back to a new to the old model, the old plan that you had. Think about what you want to do. If in many cases, rollback is one option, but that to me is the last option. If you can fix forward, I would recommend it because once you start this process, if you try to, I mean, with change control, change management, approvals, it's gonna take you a month to go back and readdress it. So rolling back, in my mind, is the option of last resort. You want to go forward, fix it forward, try to get it in and done if you possibly can. Performance monitoring, again, you want to make sure you track the performance. Is there gonna be any sort of issues? Is it gonna detect anomalies? Are there any baselines for normal operations and then do you deviate from those baselines? Do you have an instant response preparedness? Are you prepared to deal with this in the event it goes sideways? Do you have a plan? Have you exercised that plan? Have you tried it? Have you looked to see? Hey, if I do this, what's going to happen? You need to make sure you have a good plan to deal with an incident when it does. Because if you roll out the software and things go sideways and it crumps, you better have a way to one, fix forward, roll back, and also communicate with leadership on what the heck just happened. Long-term maintenance and review. You need to understand the rev there are regular updates. Again, this open source, monitor for new releases and patches from the community. This is something that happens a lot where this gets missed. Why? Once it's in place, you forget. When you're dealing with COTs, you now have like Microsoft, for example, they have the patch Tuesdays, right? But it's automatic patching, automatic updating. You don't even have to think about it. So you want to consider that when you're dealing with open source, do you want to go through some sort of automated patching process? Or do you have a tickle or reminder to tell you, hey, go look at this source code, make sure it's been updated. Manage services, verify service providers, maintain infrastructure, and apply the security patches that are associated with that. And then again, do a periodic reassessment of your organization's software and the needs that it may have and how it may affect the performance of your organization. And then lastly, also look at the security threats and how those are changing in the space. Okay, last one, we're dealing with documentation and knowledge management. You need to understand the evaluation records behind this. How are you evaluating this from the process and findings? Are you including security assessments involved in this? Is there licensing information and is there compliance verification behind it? So again, getting all the software in place is great and it's wonderful, but do you got to come back and fill up the paperwork? Because if you don't do this, it just causes more drama down the road when you go, I don't remember how we did this whole thing. So you want to make sure that you keep the records one, how you evaluated the right software, because when things go wrong, you at least know what why you picked this specific software. But this also would include any sort of licensing information, assessments you did in the past, any sort of compliance verification you've done in the past, keep all of the evaluation records that go with it. And then you also want to share this knowledge with everybody to include procurement, IT, and the security teams as well. Building a repository that has an approved and vetted software for future use is a really good thing to do. I cannot stress this enough to an organization, and it gets overlooked all the time. But having an approved process to deal with open source and COTS and even third-party developed software is really just a critical part in the overall protection of your company. Okay, that is all I have for you today. Again, this is CISSP Cyber Training. I hope you guys are doing well. Head on over to CISSP Cyber Training, get access to this content. It's all there and available to you. Again, if you put you sign up for some of my products, you'll get it all. I mean, let's be honest, right? There's just some mentoring pieces and there's also some other ones that are I cut off on the side, but if you just want the content, I mean you're talking 50 to 100 bucks. I mean, seriously, this is the no-brainer. If you are taking this on your own and you're studying on your own, this information, this content is available to you at any time. And again, I it's the time of recording this, it was 50 to 100 bucks. By the time you guys get it, it may be more. I don't know. The ultimate point of it is this is if you're looking to get your CISSP, I am here to help you with that. That being said, as well, I'm also a consultant, and I have a team of people that are really good in all types of activities from pen testing, CISO operations, uh working in industrial control environments, you name it, we've got a team at reduced cyber risk, and that's available to you as well. Again, go check that out. All that stuff is available to you. Again, the site's just growing. We're gonna get some more stuff on there as well. But and there's also a podcast coming on reduced cyber risk, but that is coming soon. Bottom line is we are here to help you. Again, your CISSP help you get this thing done, but with reduced cyber risk, it's to help you long term. That's the goal. CISSP is a trading, reduce cyber risk is a long term capability is to give you what you need from a security standpoint and help you grow and protect your company. All right, that is all I've got. Again, have a wonderful day, and we will catch you all on the flip side. See ya.