CCT 206: Assess Security Impact of Acquired Software (Domain 8.4)
Dec 30, 2024Could you navigate the complexities of cybersecurity like a pro and walk confidently into the CISSP exam? Join us as Sean Gerber shares his expert insights on conquering common test pitfalls and emphasizes the crucial strategy of thinking like a manager. From mastering the art of pacing to trusting your instincts, you'll gain valuable knowledge on how to read questions methodically and manage your time effectively. Plus, we're not just examining theoretical knowledge—Sean breaks it down into practical applications, particularly when assessing the security risks associated with commercial off-the-shelf software.
In today's cloud-reliant world, understanding service evaluation best practices is essential. We explore the critical considerations in managing services like SaaS, IaaS, and PaaS. Learn which questions to prioritize when engaging with service providers, such as inquiring about their data protection strategies, encryption standards, and compliance with essential frameworks like SOC 2 and ISO 27017. Discover how the shared responsibility model for IaaS impacts your security measures, and unlock the secrets to secure API configurations. We also stress the importance of thorough risk assessment, threat modeling, and adhering to secure development standards like ISO 27034 and IEC 62443.
Software selection is a major decision, and due diligence can make all the difference. This episode unravels how to rigorously evaluate software vendors, focusing on credibility, security assessments, and compliance with industry standards. With Sean's guidance, you'll learn to conduct comprehensive code reviews, penetration tests, and evaluate vendor support. We also highlight strategic deployment planning, emphasizing API security, threat modeling, and a robust mitigation plan. Finally, we unveil the extensive cybersecurity services offered by Reduce Cyber Risk, paired with exciting news about an upcoming podcast designed to bolster your cybersecurity knowledge even further.
Gain access to 60 FREE CISSP Practice Questions each and every month for the next 6 months by going to FreeCISSPQuestions.com and sign-up to join the team for Free. That is 360 FREE questions to help you study and pass the CISSP Certification. Join Today!
TRANSCRIPT
Speaker 1:
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 Gerber 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. All right, let's get started. Let's go cybersecurity knowledge.
Speaker 2:
All right, let's get started. Hey, I'm Sean Gerber 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 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 current process I use with Video Ask. I'm going to stick with, I think, go move to Voxer, just because for my students that are part of my paid product. The reason I say that is because I haven't been getting some of the names that are tied to the overall 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. But, needless to say, we will be moving away from video ask, but one of the just going to do a couple of questions real quick from Video Ask. But I'm just going to 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 is 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.
Speaker 2:
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 going to go through some of those faster than 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 are going through 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.
Speaker 2:
The next question they had was I don't trust my gut, I don't trust my feelings on what is the actual, correct answer. And the answer to that is what do you do? 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 course, where 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 gut says and it will occur. It'll be a much better option for you.
Speaker 2:
And then, lastly, is the individual there struggles with thinking like a manager, and I think that's an important part that most people do take in 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 got to ask yourself how would my manager answer these questions If they would answer them different than you? Then odds are high. You want to go with 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. When you answer these questions, they understand risk a bit differently than you will. So, again, just some key concepts for you to consider.
Speaker 2:
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 any of my programs. You can gain access to all of this content, all the video content, all the written content, everything. If 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.
Speaker 2:
So what is commercial off-the-shelf software? Now, commercial off-the-shelf software is a pre-packaged proprietary software designed for mass distribution. Now the purpose of it is 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 microsoft's, your uni or not unix, your oracle, your industrial control systems, your Oracle, your industrial control systems all of them don't 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.
Speaker 2:
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? 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 update of the policies. How often do they do their 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 do analysis for compliance based on those situations.
Speaker 2:
The other part with dealing with open is. 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 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 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.
Speaker 2:
There are the security concerns that come with this is 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 who's contributing, what type of information they're 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.
Speaker 2:
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 situations, you may want to have 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.
Speaker 2:
Dependency analysis Ensure all libraries are secure and updated. Do you have your libraries? Are they in a place? Where? Do you know what libraries are being used? Are there hidden libraries? 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, nvd. Now, if you have a CICD pipeline in place to do your code reviews, 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 Are they updated? Is there patches for it? Who does that? Who provides those patches?
Speaker 2:
Again, open source software can be very, very valuable, but it also can be very wild westish. 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 organization's needs. So if you contract with a third party to develop you software for this specific widget, that would be the way it falls into this, again, very similar to some of the stuff that it's kind of a combination between the closed or regular COTS 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 concerns. 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 your software. You better have a plan for it.
Speaker 2:
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 anything? Did someone steal their source code? Did someone 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 With that? It 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, 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.
Speaker 2:
Now, managed services we're dealing with SaaS, iaas and PaaS. So SaaS is your software as a service. This is an end user applications hosted and managed by the provider. Right, so you'll get these out there in the cloud. They have the software available for you. Some things you want to consider when dealing with them is have they had any breaches, insider threats? 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 organizations that provide you a software is do I have the ability to lock them out? So, if they're hosting it for me or 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 provider's 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.
Speaker 2:
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 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? How do they update these potential issues? That's again back to patching and updating.
Speaker 2:
And then what about APIs? Do they allow APIs in? Are there apis that they're allowing to connect into their infrastructure? So again, if they're socked to iso 27 017 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 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.
Speaker 2:
You need to ask the providers of these infrastructure products and again, monitoring and shared resources 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. 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? What kind of developer security do they have in place for their folks?
Speaker 2:
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 the checkbox yes, you are good, then you may be 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.
Speaker 2:
Now, do you have a secure development process, though that utilizes different types of artifacts that are out there and then it is able to evaluate those? So, again, public, public documentation. Is there any sort of development process that they have? Is there any vulnerability response process that they have? Are there guides that they've created on how they secure the configurations? How do they secure the, 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, or IEC 62,443? 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.
Speaker 2:
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 there's potential impact and likelihood have been determined with that.
Speaker 2:
Then there's also threat modeling. This is where you map potential attack vectors and their mitigation strategies. You will focus on integration points when does it come into the software, where do they connect, and then also how this 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.
Speaker 2:
But you want to consider that when you're looking at various software Compliance and regulatory requirements, 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 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 may occur? Do you have an ability to coordinate with 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 important 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.
Speaker 2:
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 kind of comes into the UEBA type piece or even your endpoint detection and response type of capabilities. It's monitoring what does the software do? Is it going to 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. 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.
Speaker 2:
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 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. 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.
Speaker 2:
You need to maintain an inventory of acquired software and their risks. I will tell you right now if you have 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. Perform periodic reassessments, also to address the evolving threats. Again, want to do all of this. These are some key best practices when you're dealing with security.
Speaker 2:
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 will the software meet your organizational and business requirements. And this would have 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 going to buy it. You buy it and you don't do a functional fit. You're going to regret it because you may end up having spent a lot of money on a software that you cannot use.
Speaker 2:
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.
Speaker 2:
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 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.
Speaker 2:
A vulnerability assessment Use scanning tools such as Nessus, qualys, 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 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.
Speaker 2:
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 for data at rest and in transit. Again, 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 meets the compliance requirements of the organization that you're serving GDPR, hipaa, whoever it might be?
Speaker 2:
Now, in lieu of compliance and licensing, review again regulatory compliance is to 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 27001. 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, last thing 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. I have 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.
Speaker 2:
Licensing review. You want to understand 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, it'll 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.
Speaker 2:
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 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? Do they have managed services? Do 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?
Speaker 2:
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 in a 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 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.
Speaker 2:
System compatibility you'll validate for seamless integration with existing applications, databases and services and test for conflicts or dependencies that might disrupt your operations. 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 is going to go wrong. I guarantee you it will go wrong. Api is interface testing for all of your, for your sas, your pass, just I, as anything that's dealing with externally. You need to make sure that you have you assess the security and functionality of the apis that are being used and they're configured to prevent unauthorized access or data leakage.
Speaker 2:
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 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, 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.
Speaker 2:
If you have an issue, how are you going to address it? What are you going to do? Think through it Now. You're not going to 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 am I going to do? Even if you just what if'd 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.
Speaker 2:
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 you have failures? So, again, a rollout plan is great. I'm going to 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 going to fix it and keep moving. Or you're going to roll back to the old model, the old plan that you had. Think about what you want to do. 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 going to 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.
Speaker 2:
Performance monitoring again you want to make sure you track the performance. Is there going to be any sort of issues? Is it going to detect anomalies? Are there any baselines for normal operations and 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.
Speaker 2:
Long-term maintenance and review you need to understand the 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.
Speaker 2:
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 a 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 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 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.
Speaker 2:
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 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 on the side, but if you just want the content, I mean you're talking 50 to 100 bucks. 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, 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.
Speaker 2:
That being said, as well, I also a consultant and I have a team of people that are really good in all types of activities, from pen testing, ciso operations, working in industrial control environments, you name it. We've got a team at Reduce 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 going to get some more stuff on there as well, 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 is to help you long-term. That's the goal. Cissp is the training. Reduced cyber risk is the long-term capabilities 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.
CISSP Cyber Training Academy Program!
Are you an ambitious Cybersecurity or IT professional who wants to take your career to a whole new level by achieving the CISSP Certification?
Let CISSP Cyber Training help you pass the CISSP Test the first time!
