CCT 090: Navigating Security Compliance and Vulnerability Management (CISSP Domain 4.5)

Ready to elevate your cybersecurity knowledge? Buckle up as we, your hosts, dig deep into the realm of security operations, focusing on the time-saving 80-20 rule. We're discussing how automation can handle 80% of benign events, leaving your SOC teams to tackle the crucial 20%. We also delve into the intriguing concept of detection as a code and the role of scalable business context in data ingestion.

How about understanding the essence of penetration testing and vulnerability scanning? We'll guide you through the diverse types of penetration tests - pre-deployment and post-engagement retesting. You'll get a handle on the criticality of both internal and external vulnerability scanning, as well as the need for an incident response plan to uncover unauthorized devices in your environment. That's not all! We'll explore how to leverage external resources for vulnerability scanning efficiently, highlighting threat intelligence services, vendor communication, and applicability assessments.

As we wind up, we'll share effective strategies for risk mitigation, emphasizing the need for documentation and risk-based decision-making in creating robust defense layers. You'll gain insights into the importance of service level agreements and proper management of expectations with service providers, verifying patches before deployment, and regular review of documentation. And because we believe in your growth, we cap it off with some essential tips for acing your CISSP exam and identifying top-notch content to excel in your cybersecurity role. This episode is packed full of expert insights and practical tips to help you step up your cybersecurity game!

Gain access to 30 FREE CISSP Exam Questions each and every month by going to FreeCISSPQuestions.com and sign-up to join the team for Free. 

TRANSCRIPT

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. Good morning, it's Sean Gerber with CISSP Cyber Training. How are you all doing this beautiful morning? Today is CISSP Monday and today we get to cover topics that are associated with the CISSP. If you all are just kind of tuning in, we on Mondays go over the CISSP basic not the questions, but the content itself and then on Thursday, you will have content specifically focused around the questions that were in the content on Monday. So it's great. We're going to have a great opportunity here to go over some awesome, awesome things, and it's stuff that's going to be helping you with your CISSP endeavor and your journey, and the ultimate goal is to provide you the information you need to pass the CISSP. Because, as we all are, if you're listening to this podcast or you know and it doesn't necessarily mean people that are listening to this podcast are focused only on the CISSP. But most people that are listening to this are focused on the CISSP and passing that exam, and so this is what we're here for we're here to help you pass that, rascal. So again, my name is Sean Gerber. I am a person who's been in the cybersecurity industry for a long time, been around for probably close to 20 some years, so that means I'm really old and I've got a lot of gray hair. But I've been able to see a lot from basically coming from a background of not having security into from flying airplanes to now leading an organization as their CISSP. So we're going to get into it. But one of the first things we talk about here today is a article that I saw just in the news, and it actually isn't about a security event per se. It's more of the 80-20 rule for security operations. Now, as you guys know, we are studying security operations within the CISSP. That's one of the core tenants is around SecOps and this is a great article. It's in the Hacker News and it talks about the 80-20 rule and that really does govern most things in life. Is this 80-20 rule? And this article basically comes down and says is that most SOC teams, the security operations center teams will spend a third of their day on events that don't pose any threat to their company or their organization and that's true. It was back when I was leading a SOC that was the case as well. We saw that routinely. And what they do is the thought process is that you will build some level of automation with your SIM and that your SIM is your security incident event management tool. You will build the automation around that that will handle those 80% issues you run into. I've seen it in the past where, especially when a SOC stands up, when you don't have that automation enabled, it can consume a gob of your time, so much so that it actually makes it overwhelming, and you have a hard time then keeping people because they just they're not into sitting there looking at a screen working on things that really have no effect whatsoever. So that's kind of a common interest there. That I thought was was kind of valuable. So you want again the 80% you want to try to put into some level of automation and that would get into data ingestion and normalization. They talk about how you deal with detection, investigation, response. All of those can be built in so that they're all automated as much as you possibly can, and I think that's a really valuable tool. I've seen it myself when working through various incidents I've had with my company. The automated factor really does help manage your people, especially when in today's world with finding security people can be very challenging. That is awesome that you have the ability to automate that piece. Now the last 20% is the customization aspects of it, and the customization piece is there. There is automation built into it, but it's more designed for those areas that need that specific or specificity of the 20%, and that's the top tier aspects that you're dealing with in relation to an event. So if something is more hands on that you have to address. So I'll give you an example where you have an incident that hits an endpoint, the endpoint has an alert that kicks off. Then an automation will roll to clean out that incident. But if there was somebody that was one, it was a fast spreading type of malware you may have to be involved. It also could be one where, if it's in dealing with an individual like so, basically you do have, you're dealing with a full up hacker that's in your environment that would need hands on approach to it as well. So that's an important part of that 20% customization and with that they talk about how you ingest custom data sources. That's part of what you'll do in a sock is you will work to have those custom sources that are coming into your SIM to basically customize that input so that it meets your criteria for alerting and monitoring. The other part is they talked about detection as a code and then they talk about scalability. As far as how your business context goes, what that basically means is, when you're dealing with detection as a code, in today's world of the cloud environment, there's code is running that is running all kinds of systems. You'll deal with serverless type architecture. That is the same concept when you're dealing with detection as a code. Now the other part when you're dealing with scalable business context, as a security person who works with a company, the context around how that data is ingested what is that data is extremely valuable. So you may think that, well, all data is the same, but it really isn't, because at some places that there may be information that comes in that I don't have a lot of value for and therefore I can let those automated processes work, but I'll have other information that comes in that's extremely valuable, that I don't want bad guys to have and therefore I need to be involved. That would fall in that 20%. So, again, it's a very interesting article. It kind of just talks about if you're dealing with a sock, what should you consider? So folks that listen to this podcast probably are on socks. They may be actually managing a sock. It's a really good article from the Hacker News. It's called the 8020 Rule. Okay, let's get started and let's roll right into today's podcast. Okay, so for today's podcast, we're going to roll into. We're going to talk about navigating security, compliance and vulnerability management. Now, this is part of domain 4.5 and this is the vulnerability management aspect of domain 4.5. So we're going to grab various pieces, we're going to kind of delve deep into this and you'll see part of this actually overlaps what we talked about with the Security Operations Center. But when you're dealing with a threat to your organization, now this is going to help you with the CISSP, but it'll also help you with your company as well. If you're looking to utilize security tools in your environment, there needs to be a process for identifying threats and vulnerabilities, and you can. This can be done through various tools. Now, obviously, we talked about the SIM, obviously your Secure Incident Event Management tool. That can be one of the tools, or you can have your, as well as your, intrusion detection and prevention systems. You can have various log files that are coming from various systems switches, routers and so forth. You can have various log files coming from your cloud infrastructure. All of that can be available to you and that's what you want to use your internal security tools to help you with that, and that will all be ingested into your SIM to help with these overall alerting. Now there's devices that are used again we talked about for detection. We talked about intrusion detection and prevention. Now, what you'll see in today's world, it used to be a hardware, a piece of equipment that you would have an intrusion detection or prevention pieces of equipment, and that IDS IPS system would then allow traffic in or out, based on just like a firewall, but what it would do is it also interrogate that information. It would tear it apart and look at what's actually occurring within that data packet that's moving across the wire. Now, depending upon if you have a system that's just going to alert, it would typically be an IDS. If you have a system that's actually gonna go in and do some blocking, that would be what we call an IPS or Intrusion Prevention System. Those will work both hand in hand and in many ways most people will have an IPS type of capability set on in their network, but it's set to alert and not necessarily block. One of the concerns that many people have around IPSs is the fact that they may start blocking traffic that you don't want them to start blocking. So it's important that you have your IPSs one tuned correctly, three monitored actually I don't know what number one went, but number one would just have it in place. But you need to make sure that those are set up correctly. There's also file integrity monitoring and then suspicious access monitoring. Now, file integrity monitoring they are these solutions. They alert on unauthorized access to file systems, your configuration files, content files and so forth. So if you have a piece of a file I shouldn't say a piece of a file you have a file and something is modifying that file, these file integrity monitors will let you know that somebody's managed it, somebody has modified it, and it will then alert you upon those situations. Now, suspicious access monitoring these are devices such as a NAC or a DOP type solution which will then look to identify and mitigate unauthorized access attempts or potentially bringing data out of your organization through policies that they may have in place. They'll deal with many times with DOP, and DOPs work really really well in the fact that they will help control the data that may or may not be leaving your organization. Now, they also can be very temperamental and they have a lot of overhead that goes with them. So if you deploy a data loss prevention tool of some kind, you need to make sure that you have the resources available to you to manage it properly, because it can be very, very costly, not just from the tool itself, but from the overall manpower required to make it run. Now you're dealing with penetration testing. So one thing we're gonna talk about is what is a penetration test? Now, I did this penetration test in a previous life with the military. It's changed a lot since then, I'm sure, but basically we would do is we would do a network vulnerability assessment remotely, go into an organization physically, and then we would all the information that we did from that remote network assessment. We would use that to help modify us and allow us onto the facility itself. It's a really great way to gain access to physical locations and it would prove to be very successful probably too much so. So that's a really cool. That's a red team activity, but a penetration test is an external network test that you basically come from the outside and you try to work your way into a network. Now this can be done utilizing real world tactics, techniques, tactics, procedures, ttps it's using those like the bad guy or girl would use, and they're very common. Now I will tell you that many people in the security world want to be a pen tester. They love it, they wanna be an ethical hacker, and that is great. If you want that, that's awesome. You can definitely do it. I will tell you, though, there's lots of opportunities. So here comes the, but here comes the negative. There's lots of other opportunities that can give you a lot of satisfaction outside of being a pen tester, and also your skills have to be the best of the best. To be a pen tester and I'm not saying that that's bad, I'm just saying from a skills standpoint I was a pen tester. Was I the key guy? No, I was not. Now, I led a team and I could do it, I can understand it and I could actually accomplish the tasks needed to become that, but I needed a lot of supervision just because of the fact that I was good, but I wasn't that good, and you need someone who's really, really good to do external network testing. You have your internal network testing. This is where you're done through. Staff can run security programs that will allow you to scan the environment. Who used to do this as well? We would go into a facility and into a location and we would do a network intrusion detection scan. Now we did all of this while we were basically trying to hide as well. We didn't want them to know that we were there, and the reason being is that if I'm doing a scan of an internal network as an assessor and they know that I'm scanning them, they're gonna make changes to their environment. So we would go in kind of basically black ops, right, and we would just sit in a room and we would scan the environment, one to see if we get caught, two to see what we would find. Now you're dealing with penetration testing. You have pre-deployment testing and then you have retesting after your engagement is over. So pre-deployment testing is basically before you deploy your new systems and applications. You will do a testing of that system in a controlled environment. Again, it's one is to ensure that you have no new vulnerabilities that you're introducing to their environment. But two is also to show that your system is actually monitoring correctly and it is working correctly. So the last thing you want is go in there and tell them they have all kinds of issues and when in reality, it was your system that had all kinds of issues and they're much safer than they thought. You lose a lot of credibility doing something like that Retesting after the end of it. Once you get all this done, they go in and they make the fixes. You then will go retest it after they have remediated the problems. That works really well. It does also help provide some level of accountability to ensure that, hey, I'm coming back. So you may think I'm gone, but I'm coming back, and it's a really good way to help the organization that you're working with. Now we deal with vulnerability scanning. That's again. It can be a lot like the pen testing. Think of it this way the pen test is a very narrow, targeted approach. Like a hacker, they're looking for one or two ways in A vulnerability scan is gonna look for scanning all over when is this at? And you will then scan external networks externally facing IPs and domains and detect vulnerabilities that could be exploited by attackers. That's the purpose of it. And again, you're looking for software insecurities. You're looking for configuration errors, anything you can find externally scanning. Your internal scanning is a regular scan that will occur. You should do this routinely within your organization to just find if there are any sort of vulnerabilities that may be in there. As an example, qalis is a great tool that's used internal. It tells you if you've got vulnerabilities with your applications, with your servers. It's a really good tool to help with that, and you'd want to do that's done internally to your organization. Now, after you make the changes, you'll then obviously want to go back and scan again and then just make sure that you are you've addressed the problems that you found. Then there's also wireless scanning. That's a really good tool for, especially in today's world where there are so many wireless access points that are being stood up I have seen it time and time again where you will let individuals within your organization have some level of autonomy. Well, by doing so, what ends up happening is they typically have a problem to solve. I'll give you an example of a situation that occurred many years ago where we had an individual that was trying to gain access there in their break room, and they couldn't gain access to the internet because they needed the internet for whatever reason. Well, they put a wireless access point in a location so that they could basically bridge between the network that was outside their standard cellular network to the break room, and they had a problem to solve, and so, because they had a problem to solve, they found a way to solve it. Well, if you have that level of scanning, you can now determine oh look, there's an access point here that should not be here, and so it's a great way for you to do some level of scanning within your environment, because people are people and they will bring stuff in Many cases. In most cases, it's not malicious, it's just they have a problem to solve. Sometimes you will get into somebody who is malicious, and then that's a whole different conversation. The other part around vulnerability planning is your incident response plan. This helps you look for unauthorized devices that might be in your environment. When you're dealing with an incident, you don't want devices that are in your environment that are not allowed and not authorized. There's other external resources that you can use as well for your vulnerability scanning. This is threat intelligence services, vendor communications and apple I can't say that word apple applicability See, yeah, it's my third grade. Education is coming out. Applicability there you go, took me a second. It is a senior moment. Applicability assessments, that's it. We'll come to that. So threat intelligence services you're gonna have various companies that will provide you real-time threat intelligent feeds to help you give you advanced warning of something that might be going on. So there's tons of them out there. There's more that are coming all the time and they will give you some sort of feed either from they pick stuff off the dark web. They have some sort of intelligence within a comp or within an organization or a country. They will provide that information to you. They may be having information based into big companies that have zero days, like Microsoft, that find them. They'll then provide you that intelligence before it hits the street so that you can make changes. The other part is vendor communications. There's vendor security advisories that patches that come out. You'll want to ensure that your organization is getting those, and so what I mean by that is that is, your organization has various vulnerabilities, various applications. You want your SAPs, you want your Microsofts, you want all these companies to send you information on what are some of the vulnerabilities associated with your applications or your systems so that you can go and address those problems, and so, therefore, you need that information coming in from these various vendors. Applicability assessments these are done, again, to ensure that your organization's posture is responsive to the current threats that are out there, and you should regularly assess your organization based on that. And this doesn't have to be a large, all company scan. This can be a very targeted scan internal to your network, just to make sure that they're doing what you want them to be doing. Now, when you're doing scans and any sort of communications, you want to make sure that you have approval and that people are aware of what's going on. If you're doing any sort of scan or test within your environment, especially as it relates to automated tests, you want to ensure that your company is aware of it At least the leadership is aware, because what tends to happen is these scans can be disruptive to an organization, and if they're disruptive and it causes operational issues, that can be extremely problematic for you and your cause. The last thing you need is your CEO tapping you on the shoulder saying, hey, can you talk to me about this? Why is this happening? It's important for you to make sure that they're aware of it. You also your IT operations communications. You want to make sure that people are aware of what you're trying to do within your IT organization, because they're usually the first ones to know if something is going sideways and they're the first ones that lets you know that it might be a problem. So they need to be aware of what you're trying to do from a security assessment standpoint. So, now that you do these vulnerability assessments, one of the things you want to understand is what do you do with the data? How do you handle the data? Well, when you have a vulnerability assessment and this happens with even your tools that operate on a scanning autonomous basis you want to have at least a monthly vulnerability management meetings. Now I will tell you that I have meetings as it relates to our vulnerabilities, more or less probably twice a month, and it's more or less a touch point to find out how are they doing, where are we at with them. But having vulnerability assessments done that are, your scanning tools and then looking at those results, seeing what they're finding, using those metrics for your company, are extremely valuable and important. Now this process can give you a long list of vulnerabilities. You're gonna have to garner that and you're gonna have to narrow it down. I will tell you that the list can be exhaustively huge, especially if you're just implementing this within your organization, and it can be overwhelming. So, just like anything else, they talk about this thing where you eat the elephant. I don't know if anybody who's ever eaten an elephant that would be really bad. Actually, I don't want to do that. But if you're gonna eat this big monster elephant, how do you eat it? You eat it one bite at a time, and so that's the same concept here Find out your highest risk systems and then start addressing those individually. You're gonna have risk criteria that will be defined. Now, in many of these applications I'll use QALUS as an example, but there's many of them out there they will give you some sort of rating on how your company is doing or how that application is doing. Is it an A, is it a B, is it a high risk, is it a low risk? And then you can define and sort based on that criteria and then delve deeper into it. They also give you the ability, with these scanning tools, to then go. You know what your scanner says it's a problem. Your scanner always says it's a problem. I go look at it and there's nothing wrong with it. You can then park that. You can go have it whitelist that specific server. Now, the downside of doing that is if something does come up in that specific system, sometimes you could overlook it, and so therefore, a lot of these whitelisting capabilities within these scanners will allow you to just only put it in for 90 days, 120 days, 180 days, and then it pops it back up like a little like a flower. It pops back up. So the point is is that I'm trying to make with that is, if you do whitelist a system, don't make it indefinitely, put a time limit on it, put a criteria around it so that it does come back up to you and you're able to address it in the future. Now it'll also produce you a risk mitigation list, and this would be an updated list with actions, completion dates and then the overall responsible owner, and you'll want to make sure that you have that defined and worked out. Now, as it relates to the frequency and how often do you do this, like I mentioned a little bit earlier, vulnerability scanning is usually done about once a month, and I feel that once a month is probably as soon as you want to do it. You could do it once every quarter. It just depends on the amount of manpower you have to deal with this situation. It also depends upon how far down this risk mitigation path you're at. If you're at the beginning, you probably want to scan it once a month. If you are been into this program for a long period of time and you've got a really good process in place and you're mitigating these risks as they come, you don't usually inject a lot of equipment into your environment on a real quick basis. It's usually a little bit over time. So you may even roll back to a scanning once a quarter. Once you feel that you have your systems in a good state, you know that they're being addressed. You find vulnerabilities. You then contact the people that deal with it. You then address the vulnerabilities. If you have auto-patching involved, all of those aspects could lead you down the path of only scanning once a quarter. So you have to weigh that out in your company and what you really want to do. But the people that are involved in this typically are obviously your cybersecurity folks, your IT department heads and others that are looking for these various security issues. The outcome, the overall outcome of all of this is you want to address specific vulnerabilities and improve the overall security posture of your company. Now, the good thing when you do these is it helps you create what we call procedures. These procedures will help you address and identify these issues and then address the issue when they come up. This helps you really work out well what are your procedures for your company so that, in the event of an incident, this is what I do. In the event that there is a vulnerability, this is what I do. These procedures are important for your company and your overall plan. You want this to ensure you integrate well with business operations, with your company overall. You want to ensure that whatever you do from a vulnerability standpoint, you are trying to incorporate within your company as well. And I work hand in hand with our operations folks. Now, if you're not familiar with what operations is, operations are the folks that are at the facilities. They're basically boots on the ground. They are the ones that are getting their hands dirty on the shop floor. They're the ones that manage all of that that creates it for a business. Now, if you are a basically deal with paperwork, say you're a paperwork company and that's all you deal with, then your operations folks would be the folks that are the key people that make all the paperwork work. If you manufacture widgets, then your operations folks are the folks that are making those widgets. So you want to incorporate yourself with them. You don't want to be IT sitting in its own little tower somewhere. You want to be able to be fully invested with your operations folks. Now one thing you want to consider is the risk criticality of these systems. What are they? How critical are they from your overall operations? And this can be broken down in a couple different ways. You're gonna need to define what is what we call business critical systems and what are business critical data, and we've talked about how do you label these systems. And one way to consider assessing this is the fact that if your system, their company, has equipment that is important to operations, then that would be a critical system potentially right. I use four criteria for my critical systems. One, does it have a significant financial impact on my company? Two, does it have a EHNS or an environmental, health and safety issue? And then the third option that I have is is it something that's regulatory, where somebody could potentially there'd be regulatory fines associated with it. So those are the big three criteria that I use specifically for if it is a business critical system. So one, if nobody, if you can't get hurt, that's positive. Two, if there's no government regulations that require the system to be up, that's positive. And then three, if it isn't a huge financial impact to my company, then I wouldn't. I'd still be important, but it wouldn't be critical, and that's what you need to understand when you're scanning these systems. If they are critical to your operations, you really wanna put more emphasis upon them and you want to focus on them more than you would a normal run of the mill system. You also wanna make sure you have properly secured environment, which would include encryption, access controls and then, obviously, these regular audits that you may have. We talked about ratings. Some of the typical ones in the market, you'll see, is critical, high, medium and low. Those are really the basics. I will tell you that anytime I get into more than three. If you go into critical, high, medium and low, what ends up happening is, in this situation where there's four, high either becomes critical or it becomes a medium, medium becomes a medium or a low, and then low obviously is low If you can stick with three and realistically to get your business going and what you're dealing with as it relates to security, I would stick with two. But this is kind of a life hack, this is a SISO hack. If you do more than three it's just too much and in reality, especially if you're getting your program started off and going, I would just focus on two. I would say is it high or is it low? And if it's high, address it. If it's low, don't address it right now. And then, once you get into a position where you've got that under control, you can get into a high, medium or low if you feel that that's important. Now, the mitigations of these systems. Much of it will depend upon, obviously, the criticality of these systems as well. So if you're gonna, like I say, for example, you have that critical system that is important to your company, you wanna make sure that that's a priority for you to respond and to mitigate it. Now this may you may have what we call service level agreements in place with a whomever is managing this system for you. So like, if you're managing it, you won't need an SLA, but if you have a third party, a managed service provider, that's managing it for you you may want. We call a service level agreement, and a service level agreement sets clear expectations on what should occur. Well, the service level agreement that you have with this company may say you have to address these vulnerabilities within X days or within X months, and you must do it to a level that is sufficient to ABCD. That is a service level agreement. Now you also need to have this criteria defined for these systems that have confidential data or business critical data, because there's different protections may be involved, especially as you're relating to regulations on what you should do to protect this information. So, if it contains confidential data, if that data that has is critical to your company, you're gonna wanna make sure that that has a different protection level than somebody's individual PC that they're working on. And if we talk about everything else, you wanna have layers of security defense in depth, multiple layers, to ensure that, with this data, that you have properly protected it. Now you take a risk-based decisions on all of these and I would say, depending on the company you work with, the risk will change. So we've talked about this through CISSP Cyber. You have to take a risk-based approach when you're implementing security tools because if you don't, you're gonna break your companies back with the amount of money that you're gonna need to secure everything and, at the end of it, you'll never be able to secure it all. So you have to take a risk-based assessment of what is the most important things you should be fixing and correcting now, and you need to analyze the likelihood and the potential impact for each of these to help you make good, informed mitigation decisions Of these strategies that you have. These would include active remediation, applying patches, monitoring for activities, and then you would then create a risk score based on how you feel the security of that system is and the vulnerability of that system is. Now, once you've fixed these systems, this is the next level. So you got a scan done, you've looked at, you started the monitoring, you've begun the scanning. Now you need to fix the issues, and this can be done in various ways you wanna look at. One is how do you verify this is the pre-deployment before you actually push out a patch? You wanna verify that this patch is going to be not gonna cause an issue with these crucial systems. I've seen this time and again where you may have a patch, you push out this patch to a bunch of systems and it starts breaking a bunch of computers. Now I will tell you this doesn't really happen as much in today's computer systems that are auto-patched. They usually, before that patch is pushed out, it's pretty solid before it goes out and hits the streets. So those I feel relatively confident in doing that, it isn't a bunch of a problem. Servers, on the other hand you may want to have a little bit better look at what's actually being pushed to these servers, because they tend to be a little bit more flaky when it comes to vulnerabilities. And what I mean by that is this the server itself will patch just fine, but the applications typically servers have lots of applications on them and when you push out a patch, these applications do not always act or respond well to these updates and they can break a lot of things. So it's important that when you're doing servers especially, you do some level of pre-diploment verification, that you've tested these patches. It is really important. And then when you do replicate this into your live production environment, it's best to do it in waves, in phases, because if you're gonna have something break, it'll break up, usually right away. You'll notice that there's a problem. So it's easier to break on a small subset of systems than on a very large subset of systems. You real quickly you can be having your CEO tapping you on the shoulder saying what did you do to my business? And you don't want that, believe me. Been there, done that, got the t-shirt not fun. Now, when you do these things, you wanna make sure that you track your changes that are occurring and you wanna have documentation around all of this. A lot of it comes down to documentation, documentation, documentation. And I say that and I'm pointing a finger at the screen right now saying you must do documentation, and I see three fingers pointing right back at me saying you don't do enough. Documentation is one of the hardest things to do, and the reason is is because you are going 90 miles an hour with your hair on fire most days and then coming back around to do the documentation is a challenge. So one of the challenges I had to myself is I have to do a better job of that and I will challenge you all. If you can do that and you have the teams to help you with that, it's extremely valuable, won't you do it Now? The key with documentation is, once you build it, don't just put it in a SharePoint site somewhere and forget about it. You wanna make sure that you come back and revisit this documentation over and over again. Now you're looking for authorize of emergency mitigations. If there's an emergency response, this would tie into your incident response team. How do you deal with that issue? How do you expedite and review those changes? How do you deal with pulling everyone together to help you mitigate and manage this risk? It's an important fact that you need to keep in mind. Another part is from the successful testing is you want you get this testing done. You want to ensure that you communicate this with the relevant parties and then ensure that it's all deployed in a way that is effective and efficient, because the last thing you need is to deploy this stuff out and now it all causes all kinds of issues within your organization and no one knows it's coming. All they know is that things broke. You'll see this with a lot within organizations is they will have a deployment strategy. That occurs the patch Tuesday of every month. That's when the updates will happen. They already have that plan. They've already communicated it, people know it's coming and then, if things start breaking, they know they're able to go ahead and recall or roll back those changes. And that's kind of rolls into the next part where you want to have a deployment process that will push these patches out to these individual systems in an automated, customizable format. But you also want to have the ability that in events, something goes sideways. You have a contingency that you then roll back that capability. So it's important that you have the ability to, once you apply it, you can unapply it, because I guarantee you that you will have to do that at some point in time. The last thing we're going to be dealing with is it relates to vulnerabilities and the overall plans is around monitoring. And what does that mean? We've kind of touched on it during this whole podcast. But your post fix measures. So once you've done this and you deployed your patches, you've monitored your patches, you've communicated with everybody, life is good. You're going to come back around after your one month and you're going to do it all over again Again. It's the you're in the hospital that you never, ever leave. So you re-scan, you'll go back out and you'll re-scan this entire environment. It may not be the entire environment, it might be pieces, depending on the size of your company and then you will go back through and what can you do to fix these upcoming patches that you have now? And you'll make adjustments based on the outcomes of these tests. So again, you scan, you fix, you scan, you fix, you scan, you accept, you may accept the risk that this company, that this system has, because you know what it's 1970 system. There is no way I'm going to fix it and I am just going to accept that risk. You have to decide. Then, if you accept that risk, you have to also decide what am I going to do to help mitigate some of that risk to my company? You go, I'll give you an example you have a 1980, whatever that runs a punch press on a conveyor belt and it's punching holes in metal. And this thing is Windows XP and that's how it runs. So it's early 90s kind of thing, and they're not going to buy a new one because they don't make this anymore. They like the way this one works and it costs when they first bought it. It costs $18 gazillion. So they're not going to buy a new one. You then have to decide okay, well, one, I can't really scan it because it's already a mess. Two is what am I going to do, because I don't like this thing sitting on our business network that could be vulnerable to everything else. So then you will have to work to implement other mitigations to help manage that risk. Maybe put it behind a firewall, maybe put it on its own system, take it off the network all of those aspects you're going to have to consider. And then you have to decide if I have to pull it off the network, how do I get access to it? Do you have to have someone log into a log into a console on it to make changes to it? So all of that has to be thought about, and this is important because your security team is going to need to manage all of those activities and understand the risk behind them. Your job as a CISO, your job as a security architect, is to basically manage risk for your company and therefore you are going to be the person they're going to come to saying is this risky? Yes, is it to the point where I've got to do something with it? Maybe, maybe not. Let me, let's talk about it, and then you can give them recommendations on which way to go. The other part when you're dealing with your security team is they need to have those procedures like we talked about before. How do you escalate if there's a risk? That is sufficient and sub, sub I can't think the word large, yeah, that substantial. You want to have the. How do you bring your senior leaders in? How do you have the, the procedure for basically establishing it and bringing up to their attention? All of those pieces need to be brought into this overall plan. Now, when you're dealing with the types of access for confidential information, again, you want to make sure that you have some sort of reconnaissance capability, that is, scanning these externally facing systems, looking for vulnerabilities. They're looking for various ways through FTP, http, smtp and then obviously your email, your pop servers. You want to ensure that all of that is being scanned. Now, you may not, you may have third parties do that for you. You may do that internally. That's really up to you and maybe your regulatory requirements that your company may have. There might be situations where you have to have third parties that do this for you and you're not allowed to do it. So just kind of kind of work through all of that, Okay, so real quick. I've only just got a few minutes and I know there's been a long podcast, but want to talk to you real quick about some of the regular regulations that may require this scanning and I'm just going to burn through these real quick that you may have to deal with as it relates to understanding overall vulnerability scanning. So the payment card industry data security standard, pci DSS that will require some level of testing. That requires quarterly internal and external vulnerability scans. So you're going to have to deal with that. Hipaa does as well. Also FISMA, the Federal Information Security Management Act. There will be periodic risk assessments that you have to occur and you will have to have some sort of scanning that is done for FISMA. Graham Leach Blyli, this is GLBA. This is a federal law that mandates the protection of consumers, financial information, and you will have to ensure that you do security scans to ensure that there is enough security on your systems to protect that information. Obviously, european GDPR General Data Protection Regulation does require you to regularly test and assess. Iso 2007,001 isn't really a law but it's more of a framework. But it does give you does require that. So if you work with a third party that requires the ISO 2007,001 certification, you will have to do review assessments and so forth on a routine basis. Same thing with this cybersecurity framework. If you're required to do that those are. There's in that framework. It talks about the various scans that you may have to do. Sarbanes Oxley, this is a federal, us federal law that's around the accuracy and reliability of corporate disclosures. That doesn't explicitly come out that you have to have a cybersecurity program, but it does say that you have to have proper controls over your financial reporting. So there's a lot of different areas in this space that do require this as well, and the last one is the NIS. This is the Network Information Systems Directive. This is out of the EU and it doesn't require you to do scanning, but it does require you to take security measures for severe or serious incidents. So bottom line is the scans are going to be one thing you should do as a due diligence, even if there isn't a regulation that requires you to do it per se, but there's plenty of regulations that do require it. So therefore, it's important that you get smart on it and you work to try to mitigate the risk within your company. Okay, that's all I've got for you today. I hope you guys enjoy this. I know it's a lot of content, and the goal is is to have you go over this information time and time again so that when you go and sit for your CISSP exam one it seems like, oh yeah, sean talked about this or two is when you, after you pass your CISSP, you're a cybersecurity professional. You want to be able to kind of pull back from that knowledge that is being gleaned from this podcast, because that's what it's also designed to do is to help you in your security per profession and be successful in that. If you're interested in what we've got, go to CISSP cyber training some great content, free content out there that's for you, as well as some paid content again trying to make money on this just like anything else. But there's a lot of great free stuff If you want it. If you want help with your cybersecurity career, there's options that are going to be coming out here very soon that you'll be available for you, and it'll be happening just before Black Friday. I've got some great things that are going to be for that as well. So great options for you in your cybersecurity career and, as well, to pass the CISSP exam. All right, have a wonderful day and we'll catch you on the flip side, see you.