CCT 202: Understanding Vulnerability Scans, Risk Management, and Cyber Threat Mitigation Strategies (Domain 6.4)
Dec 16, 2024Unlock the secrets to safeguarding your organization against cyber threats as we explore critical components of cybersecurity. Join me, Sean Gerber, on this enlightening episode of the CISSP Cyber Training Podcast, where we dissect domain 6.4 of the CISSP exam. Discover the latest insights into cyber threats that target U.S. critical infrastructure, with a particular focus on an Iranian-linked group's custom cyber weapon. Learn how understanding your organization's technology, both hardware and software, can be pivotal in mitigating potential threats, especially in industries like oil and gas.
Navigate the labyrinth of vulnerability scan reporting and analysis as we dive into the challenging yet rewarding art of communicating security assessment findings. Whether done internally or through third-party services, the objective is to translate technical data into actionable insights for technical teams. We tackle the complexities of overwhelming scan results and highlight the value of automated reporting, ensuring an efficient and effective approach to vulnerability management. Learn how to prioritize risks, provide clear remediation recommendations, and utilize trend analysis to track progress and tackle recurring vulnerabilities.
Finally, explore the strategies needed for executing effective internal and external security scans. Discover the importance of thorough preparation and strategic planning, managing insider threats, and safeguarding public-facing assets. We delve into the complexities of third-party scans, emphasizing the need to understand and manage network connections to prevent unauthorized access. Throughout this episode, we stress the critical role of alignment and collaboration in cybersecurity efforts, providing you with the tools and guidance needed to enhance your security posture in today's complex landscape.
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 all Sean Gerber with CISSP Cyber Training, and hope you all are having a beautifully blessed day today. Yes, we are excited to talk to you today about some awesome stuff in domain 6.4 of the CISSP, so it's going to be awesome. We're also getting close to Christmas, so if you are one that has an elf on a shelf, make sure you have moved your elf, otherwise your children will find you with pitchforks and burn you at the stake. Yes, we have an elf on the shelf. All my kids as they grew up, and moving that little elf around actually added more stress and anxiety in our family than anything else, because we would forget where we put the elf. And then, when you put the elf in the same spot overnight, overnight, the children get a bit upset. So, yes, it makes it hard when you're trying to deal with that. And Santa? Now, if you're listening to this podcast and you still believe in Santa, well then I just kind of let the beans out of the bag and yeah, there's no such thing, but anyway. But that's okay, let's move on, because you know what? There is a Santa in the CISSP? Yes, there is, and it's me. I'm giving you. Yes, I'm Santa, oh no. So we're going to move on to this and the bottom line is we're going to get into 6.4 of the CISSP. But before we do right, we have just a little article that came out in the news that I thought you guys might be interested in, and we talk about this a lot in the CISSP training that we have at CISSP Cyber Training, and it is around IT and OT, right? So information technology and operational technology. This one is around OT and it's related to the Iranian-linked crew that uses a custom cyber weapon to attack US critical infrastructure infrastructure. Now, we've mentioned this time and again that the OT environment within many organizations because I used to work in the manufacturing space is a very substantial amount of our overall world ability, right? So if you're looking at from manufacturing to airlines to whatever it might be, there is some level of IoT in all of that and we become very dependent upon it.
Speaker 2:
Well, this group, io control uh, they created this, this. That's not the group, but it's basically. They created this back door uh what's? It's a custom back door for hijacking iot devices and allows them to have air quotes direct impact on ot systems, including fuel pumps at gas stations. So, so the goal is that it can attack this specific one, can attack PLCs at gas stations where you go and you fill up your car with petrol.
Speaker 2:
Well, this group, they say, is tied to the Islamic Revolutionary Guard, which is IRGC, and they've been around for quite some time and they have an arm. Obviously it's the Republican Guard of the Iranian-backed military, but they have a cybersecurity group that reaches out and does these types of things on a routine basis. Now, they do in a lot of ways. They target everything, but they really truly go after the oil and gas industry. Hence, a lot of reasons is because they have oil and gas in Iran and that's one of their chief exports, so they have a lot of knowledge around that overall space. They're one of their chief exports, so they have a lot of knowledge around that overall space. But they're targeting Israeli-backed PLCs that have been created that are in the United States. That's the ultimate goal of those and they're on Linux-based IoT systems that are in Basecells D-Link, hikvision, red Lion, opac, phoenix Contact, teleconica and Ultronix and other vendors. But I've worked in Hikvision stuff and so that makes sense, obviously, where they're at Now.
Speaker 2:
As you guys all know, plcs can be used in many different ways. Now, these are specifically focused on the oil and gas, but a lot of times, plcs can migrate to other areas within the overall OT environment, so it's not necessarily just in the oil and gas industry. So something to keep in mind. That's why it's important that, as we talk about with you getting your security background, you're getting your CISSP and you becoming more of a security professional, it's imperative that you have a good understanding of what is the hardware within your organization, and the podcast we talked about last week dealt with hardware and software. Your organization and the podcast we talked about last week dealt with hardware and software, and so that way, it's important that you keep a good running tally of what you actually have, because when things like this come up, you actually know what you have in your organization.
Speaker 2:
Now they're using and, based on a couple of podcasts we had back about a couple of weeks ago I think, we talked about DNS over HTTPS and they're using that. They're using it over Cloudflare's DNS over HTTPS, which is what they call obviously, we mentioned the acronym DOH and that basically translates host names into IP addresses right, because we know what DNS does, but it's working it over HTTPS, so therefore it is encrypted. They're using the MQTT servers. If we've talked about mqtt before, it's a messaging, it's a messaging queuing. I can't remember what the t stands for, but it's basically uh, allows these different plc systems to communicate with each other through messaging through. Basically, I would say the easy way of saying is through sms. Right, you would. They're not actually sending an sms message to another guy and another guy and and hey, they're looking at it. No, but it's sending that type of message format to each of these different PLCs and it's using that in a way that helps them communicate in their overall infrastructure. So if you have a PLC that's sitting out there and it's communicating back to the MQTT server, there's an automated job that does that. There's an automated job that does that. Well, they're using MQTT to basically push out their different software and to allow it to have communications with the robot and to allow it to be able to exfiltrate data. If they want to, they potentially could maybe make it blow itself up. All of those different types of aspects are being done through MQTT, which makes total sense, and if I was a bad guy or girl, that's what I would do as well. So it does. It has the ability to execute self-delete port scan. Many other things it can do as well.
Speaker 2:
Why is this important? Well, obviously it's targeting the oil and gas industry. So that's a challenge. Two is those kind of tendencies. Those things can go boom and cause lots of havoc and pandemonium and people can die. And three is the fact that we become reliant upon them, and it's a great I mean it's really great psychological operations where, if you then can start shutting down gas pumps around the country, people need gas to operate. What do they do? Well, they'll pay attention to that. So if you start shutting down gas pumps and you do this at a whim, it's a great psychological weapon for attackers to be able to attack the adversary. So, again, it's a multi-sphere kind of thing that goes on here.
Speaker 2:
With the cybersecurity piece of this, it isn't just hey, I'm going to go out and break something type of activity and this type of hack to really cause fear in people's minds. Good example New Jersey drones that are flying over New Jersey right, this is a lot in the news as of the recording of this podcast. Well, what is that? Who knows? It could be a helicopter, I don't know. It's probably not, but it could be something that is legit. Well, people are freaking out and some people are going to pull out guns and start shooting at themselves.
Speaker 2:
Why Psychological operations? You start messing with people's minds and they do all kinds of crazy things. I'm not saying that these little flying things over New Jersey aren't little green men, but, that being said, it makes people react in ways that are not conventionally the norm that you would expect people to do. Hence, this is where the psychological operations comes in. So, again, I've kind of belabored that issue just a bit, but US security professionals need to understand this that it's just so much more than justa flipping a switch on things go boom. It's a whole litany of things that can cause challenges.
Speaker 2:
Okay, so let us get into what we're going to talk about today. Okay, so today we're going to be getting into again this is domain six and this is 6.4, analyzing test output and generating reports for different vulnerability type assessments. And this is an important part of when you get your organization. You start working there. You're going to want to create vulnerability assessments and vulnerability scans of your environment. So we're going to just kind of go through this and pull down what 6.4 gets into, and it'll help kind of add a little color and context to your study.
Speaker 2:
So, security scan reporting this is where you communicate the findings of a vulnerability assessment, basically a scan. It could be multiple different things that are occurring, but you're communicating these findings from there and providing some level of actionable insight to the technical teams to go and fix these issues. Now you may be the person that goes in and actually determines the assessment, determines what's the problem, and goes in and fix it, but you also may have this being done and pass it on to somebody else. You also could have a situation where you have a third party that's doing this for you, and then they will pass that information on to you. The ultimate goal, though, is you take this information. You then pass it on to the folks that are technically savvy to go in and make the changes and report back to you on this. Now there's a lot of requirements. These could be compliance and regulatory requirements to help you meet that require you to meet these needs.
Speaker 2:
I see it a lot in the healthcare industry, and I see it in the financial industry. They have put these requirements in place to force individuals to do this work. Now, why is that? Well, no offense, but unless you have in many cases. You are diehard, you're going to follow the rules, you're going to make these vulnerability scans as you should and you take the utmost care doing it and you believe that in your overall profession that it should be done. Most people aren't there, and I don't mean that they don't want to do it. I mean the fact is that they're pulled in 8 million different directions and now they run a scan and the scan says they have 8,000 things they have to go fix and they're like, oh my gosh, I'm overwhelmed, what am I going to do? And so, therefore, vulnerability scans in many cases do not get the same level of love that a lot of other things do. So, therefore, compliance and regulatory requirements have been established to force you to do it, so that you actually at least have to attempt to get it done.
Speaker 2:
Now there's types of information that is included in these various reports. These are, and the report you'll get may be a generated report. It may be something that you hand, jam and put together and provide to somebody, but at the end of it, you should have a summary section, basically a high-level overview for your management on what exactly is happening. This is the critical findings, risk levels and impacted systems. I highly recommend that you find some automated way of doing this. If you're doing this manually at this point, find another way, because it'll consume too much time and it's not worth the time. You need to have the ability to provide a report that can spit it out. That you can, then it's actionable and you can do something with Now. In many cases, this should have listed the vulnerability IDs, which would be your CVE numbers. We talked about the critical vulnerability exploitation number. It has your security levels, which is your CVSS numbers, affected assets and then exploitability and potential impacts.
Speaker 2:
Now, these being said a lot of times, the automated system will generate these, and it takes you as the individual to then go through and decipher whether or not they actually truly are a huge risk to you or not. Sometimes it may come in as a critical risk, but then you realize, well, okay, this thing is buried in the bowels of my organization, and for you to get to it, to actually exploit against it, you're going to have to go through the seven layers of hell before you can actually do it. And so you may ask yourself going well, there's really no reason for that. It's critical, yes, but if they exploited all these different things. If they got down there and then they finally try to exploit something, they're already down there, so it's really not a critical thing anymore. So, again, you have to really put an eye on that and you have to have alibis for those situations in which you go. You what? It's okay, it's all right, because you just have to be able to explain it. That's the thing.
Speaker 2:
As a security professional, you're going to have to be able to explain the risk and why. You either one agree with the risk or you then push it back and say, no, I don't agree with it. You need to provide some remediation recommendations on for mitigation and again, you either accept it or you don't. So, as a continuation of this, your trend analysis is an important part. You need to compare previous scans that you had. So, for one scan to the next scan, it's imperative that you have a plan based that you will go and your overall scan is this and you now are increasing and you're making changes.
Speaker 2:
I would recommend that as you do this, because when you start especially if you have never done this within your organization you'll begin this whole scanning process and you'll go oh my gosh, this is too much. How am I going to deal with all this? What you should do is then you start off with month one. You remediated X. Month two, you remediated Y, and then you see the trend and where it's going. Now you remediated why? And then you see the trend and where it's going.
Speaker 2:
Now it may get to a point where you go I'm leveled off, I haven't made any more progress, and that may be the case because of a couple different reasons. One, it could be the risk isn't there. Two, it could be that some of these changes are so complicated and so challenging that it's going to take an overall project to help you get to this point. So those are things you're going to have to work through as it relates to fixing these vulnerabilities, and you're going to identify the reoccurring vulnerabilities that keep popping up. And that's going to be an important part because, if they continue to show up, you need to really understand the overall processes of why they keep showing up. Because, again, it could be a situation where they keep showing up because you don't have an adequate patch program in place and therefore it's all manually driven, and if that's the case, then it takes even more work. So, again, think about your trend analysis and understanding the metrics behind it.
Speaker 2:
Now, reporting frequency is based on your organizational requirements and, potentially, based on the regulatory requirements for your organization. This could be monthly, quarterly or after any significant change that requirements for your organization. This could be monthly, quarterly or after any significant change that occurs within your company. Ad hoc reporting may be necessary, specifically when you're dealing with a high-profile incident that may occur or new vulnerability discoveries. Had this happened multiple times right where you discover something you're like, omg, this is not good and so, as a way to fix it, you fix the problem. But you also then immediately had reporting ad hoc reporting about once a week, once a month or once every two weeks. However, you wanted to set it up so that you could keep tabs on how this vulnerability is being mitigated. It also, then, is helpful if you, for some reason, are working with, like an infrastructure team Say, you're the cyber team, you're working with infrastructure and then you go, hey, where are we at with this? This is where we were last week, where are we at this week, where are we at next week?
Speaker 2:
You have that ability to keep moving the ball forward. It can be very challenging because you have to feel like you have to hold a lot of hands and help move the children along and I'm not saying people are children, but I'm saying it's like having kids. You've got to move them, point them in the direction you want them to go, help guide them in that direction and be there for them when they need you. That's the ultimate part you're going to have to deal with when dealing with these various vulnerabilities that you're having to fight through Audience.
Speaker 2:
You need to understand who are these reports going to. Who's the audience? Is it the CIO, ceo, is it a C-level person or is it, like me, just Billy Bob, joe? And depending upon the person, who's doing it, if it's more technical, the report needs to be technical. If it's high level for senior leaders or auditors, it needs to be high level. So you need to understand that report. You may have to, because your report doesn't provide a high level report of what's going on. You may have to actually have the report generated and then you would have to put a cover sheet to it of going.
Speaker 2:
What exactly occurred. What does this mean? And again, it adds a lot of time and a lot of complexity for you. This is really something you may see specifically when you're dealing with the auditors and the more regulated environments, because again I'll go back to that I've had to talk to many auditors and they explain. I've had it just like a little brief cover page of what the risks were. The auditors like that because they didn't have to come and tap me on the shoulder and say, hey, what does this mean? They understood it. And now, with chat, gpt, you guys could actually make a cover page pretty simply to highlight some of the risks you may have. So something to consider there.
Speaker 2:
Prioritization of vulnerabilities you need to rank them based on the risk level to help focus, simply to highlight some of the risks you may have. So something to consider there. Prioritization of vulnerabilities you need to rank them based on the risk level to help focus the remediation efforts on your high impact issues. Again, focus on the big elephant that you need to eat first. That being said, it's really easy to go focus on some of these. I say it's easy it's not really that easy but to go focus on areas where there is high risk and then negate or not pay attention to the lower risk items. Now you may not want to deal with the low risk items, but what I'll tell you is that sometimes those low risk items can be really easy to take care of, and if they are easy to take care of, there's some value in knocking out things and getting them off your plate.
Speaker 2:
I go to Dave Ramsey and his overall money makeover plan that he has. I know it's a little bit of a digression, but the point of it is you pay off your debt, right, you don't want to have debt as much as you can, unless it's good debt of some kind. So you pay off your debt and you may do this in small increments, like you pay off a little bit here, a little bit there. The goal is that in these low-risk issues, you may want to pay them off quickly. Now we're going to deal with internal scans. What does that mean? So the purpose of an internal scan is to identify misconfigurations, outdated software or vulnerabilities within internal systems. That's the purpose of it, right, and it's to protect against some sort of insider risk that you may have or lateral movement by an attacker attacker. So one example would be like we just talked about with the MQTT servers if you have a risk involved and you're able to mitigate it, the internal stuff it may limit to what they can actually do and what they can see, Because understand someone who's coming from the outside into your organization it typically isn't as easy as I see in the movies where, hey, I got command line, I'm in, I'm running the place right, I'm going to bring everything down.
Speaker 2:
I like to use the analogy of you're communicating with on the dark side of the moon you send a command, you let the thing go, you let it do its business, it comes back with what it found and then, if it doesn't come back with what it found, you got to figure out why it didn't come back with it. So there's lots of stuff. It's not as easy as just run the command line and it happens. Now, sometimes that does work like that, but for the most case it's not that simple. So therefore, you need to be able to protect against these insider issues. Scenarios that you may deal with is routine security, posture assessments, pre-audit or compliance checkups or potentially a post-breach analysis. So all of those routine audit, post-breach those are really the big three rocks that you're going to have to fight with. If you work with creating those scenarios and fixing those, that can go a long way to help you get a good program in place and looking for these internal risks.
Speaker 2:
Some common findings you may find with an internal scan misconfigured servers a lot, you'll see that a lot. Or network devices that happens routinely. Or, and one of the things of misconfiguration is admin, admin, yeah, your username's admin and your password's admin, admin, admin Works great, really great. To leverage Outdated patches, end-of-life software a lot of that. You'll get a lot of end-of-life software, especially when you do a JavaScript or not JavaScript, but Java itself. You've got all kinds of stuff I went through that was like Windows 95 kind of stuff. You'll see that. Excessive permissions, weak internal controls those are another one that will come up. Unauthorized applications or shadow IT that does come up quite a bit and you should have a program in place to try to deal with these unauthorized apps. And then unsecured or sensitive files and databases Again, all of those you will find with the scan.
Speaker 2:
Now what I say is that again it will be overwhelming. So you have to figure out how to eat this elephant, one little bite at a time, do not try to eat it all at one point. I would recommend for the year, if you have just taking over this program from somebody else, schedule something for the year that you want to accomplish and then focus on it for the entire year and after a couple of years you'll be surprised at where you are at. So just kind of focus on that, don't try to do it all at one time. Some other key concepts around internal scans is that the challenges with these internal scans they typically have a larger scope compared to what you would deal with external scans. They typically have a larger scope compared to what you would deal with external scans Because, again, you've got all kinds of devices from potentially PLCs all the way up to cell phones.
Speaker 2:
It depends on the size of your network and how that architecture is laid out. It's greater potential for false positives yes, lots of false positives due to the internal system complexity. You'll get that a lot. So then that's where you have to triage it. But you want to spend the time to come up with a really good plan and then execute on that plan. Now it may take.
Speaker 2:
We talked about this year thing. Right, you may want to consider thinking about doing that in the first couple months of coming up with a good strategy. Then, after the couple months and you have your strategy, you have your processes in place, you have the people that know what their jobs are. You then begin to implement the strategy. So don't be in such a hurry that you want to try to get it done immediately. You don't want to do that. You're just going to overwhelm yourself and people and then it'll go away and you'll be vulnerable and you won't have done anything with it. Again, risk of overwhelming teams. We just kind of talked about that with low severity findings if prioritization isn't clear. So you need to make sure that you prioritize what you can Now remediation reporting.
Speaker 2:
This includes actionable insights, timely recommendations and then highlighting critical issues that could compromise your overall company. Those are big, important parts within your internal scans. It's a very important thing. This is not sexy, it's not. It really can be very laborious, but you got to do it If you really want to protect your company. You really got to do it. So now we're going to deal with external scans. So when you're dealing with external scans, these are designed for vulnerabilities and systems to expose that are to the Internet, such as web servers, api calls, cloud-based resources and so forth exposed that are to the internet, such as web servers, api calls, cloud-based resources and so forth. This will protect your organization's public-facing assets from unauthorized access and potential getting a data breach or data incident right Scenarios that may run into this right Regular perimeter scans. Now you have to understand again. This comes down to your organization. Where is your data lying? How much external stuff do you have? Where is it sitting? You may want to pre-launch scans for new internet-facing applications or servers.
Speaker 2:
One that this bites people with that I caught when we had I was working with my various companies is M&A. M&a is nasty man. I mean it's great for your company. Mergers and acquisitions are awesome. You always like to have M&A. You feel like, oh, my company's doing awesome. The problem is that you don't know where all their dead bodies are at. You literally don't know where all yours are, and now you definitely don't know where theirs are, and so understanding the infrastructure of an M&A environment is extremely important, and especially I mean especially the externally facing stuff. I would focus on that. I also would not bring in if you're going to do bring in a new company into your overall ecosystem I would not bring them in right away unless you have, I mean, incorporate them within your network, unless you have a good mitigation strategy and you have a way to mitigate and triage any sort of nastiness that they have in their network, because the moment you jump in bed with them, you're going to get all the wonderful bugs they got, just as much as they're going to get what you've got. So it's really important to have a good strategy when you're dealing with your m&a piece of this. So, again, perimeter scans and assessments pre-launch scans for new internet-facing applications and then ongoing third-party risk management evaluations.
Speaker 2:
Third parties are a big factor as well, especially if they're storing your data. You want to probably do external scans with them. See if you can get that worked out through legal. The second thing you also want to consider doing is if they're going to be doing third-party integrated into your company. Sometimes they may have VPN connections into your organization, due to whatever reason. You're going to want to understand their network as well, because you pwn the third party. Potentially they pwn you, especially if you have VPNs that are connecting back into your company. Don't do it, just don't do it.
Speaker 2:
Common findings with external scans is unpatched web servers and software, a lot of that. Open ports of services, unnecessary exposure that happens quite frequently and, again, a lot of that's within your web servers and the various software there. Weak encryption protocols, your SSL, your TLS. Obviously those can come up and bite you and I think a lot of that is you don't know they exist and the certificates never get updated and so therefore you're running with old, outdated SSL certs. That can be very challenging Web application vulnerabilities If you deal with a web application, a lot different types of injections that can occur with, especially if you have any sort of web facing type of front end, and then misconfigured firewalls or cloud storage buckets your Amazon S3 buckets, azure blob, storage blobs if those are misconfigured, I mean.
Speaker 2:
So consider it this way A lot of times. You would see. I dealt with where they said that the blob or the bucket is an internal bucket. Be realistic. The same with SharePoint. You may have internal routing that is set up to go directly to that bucket or that blob, have internal routing that is set up to go directly to that bucket or that blob, but if it's misconfigured incorrectly that blob, potentially you could have it exposed to the internet. So even though, yeah, it's internal routing, but it still sits on the internet.
Speaker 2:
So you've got to make sure that your architects truly understand what they have in place. I'll tell you that there's nothing worse than having an architect who doesn't truly understand his network and you are living your life out there, kind of at the whim. You're hoping that something bad doesn't happen. Hold your architects accountable. Definitely, if you are an architect and you're a security person, hold yourself accountable and make sure they challenge you, because things are changing so fast that it's important that you stay up as much as you possibly can, but you need to rely on them because you can't do it. You just have to be able to trust them but be able to challenge them as well. Now some key challenges when you're dealing with external scans balancing comprehensive scans with minimal disruption to your production systems. So again, you want to scan these, but understand any sort of scan that occurs especially on internal scans, but it can happen on external ones as well is it can affect your production systems.
Speaker 2:
Scans across geographically distributed networks and third parties can be challenging. Scans across geographically distributed networks and third parties can be challenging. I told you the story that I had where we accidentally scanned the Japanese government when we were doing an assessment and that almost caused World War III. No, not quite that dramatic, but it caused a lot of drama. That didn't need to happen because we scanned across a geographic location and they weren't't anticipating it and they thought it was an attack. So, again, you have to be very careful with what you do and if you have a third party that's doing this for you, make sure they understand what the heck they're doing, because, yeah, you don't want to just let the cowboys run loose and just start scanning everything.
Speaker 2:
Addressing third party and vendor vulnerabilities Again, like we mentioned before, if you have your data with them, have your legal language set up so that you can scan them, understand their vulnerabilities. Again, vpns you need to know this stuff. You need to know how they're connected into your environment and any sort of data sharing that's occurring. Remediation and reporting you need to prioritize critical vulnerabilities. This would include public exploit codes available, include timelines or fixes for accountability and assignments, and then document long-term remediation strategies, such as your web application firewalls, you know, put those in place or upgrade unsupported software, and you want to make sure that you have that done.
Speaker 2:
There's a lot I'm throwing at you here. This is a ton of information, of information, but the point of it is, if you're going to be going and putting this in your organization, pick on something. Your most highly riskable. Riskable that's not even a word, but your highest risk thing and focus on it. If you have a lot of stuff that's on the web, focus on the web. Come back to the internal stuff. Internal is important, don't question it. But if you don't have limited bandwidth, focus on the stuff that's the highest risk to your company and your organization.
Speaker 2:
So we're going to talk about validating the findings. How do you validate these? Now, again, we've kind of talked about this as we've gone through this, but you need to confirm that the detected vulnerabilities are legit. They may not be, it may be a false positive, and you need to make sure you avoid disruption with your organization and then also misallocation of resources potentially caused by false positives. If you send people off on a wild goose chase, yeah, you're going to come back and they're all going to be frustrated and they haven't got anything done, and then the trust in your organization, the trust in your findings and your ability to do this, goes down. So, again, you want to build trust with your program, with the people, by doing it the right way.
Speaker 2:
The first time Validation process, you need to analyze these findings right, cross-check them against CVSS, against CVEs, and validate that they're actually a security issue. Then, once you know that you need to also evaluate the impact, what can happen If Billy Bob gets access to this? What occurs? Well, the toilet paper that's routinely ordered through SAMS does not get ordered, so therefore that's terrible. Well, okay, it could be terrible, but it won't be necessarily the biggest thing in this case. Whereas, if it doesn't get fixed, your PLCs that control your gas supply lines, that take care of the pipelines up and down the East Coast, get shut off. Yeah, risk versus the other risk yeah, toilet paper versus gas yeah, it depends on the situation, right, yeah, but the ultimate goal, though, is you want to evaluate the impact that it could have within your company. You need to replicate the exploits Again, conduct controlled tests to verify the vulnerabilities.
Speaker 2:
This could be pen testing, red teaming, and so forth. I would be very challenging with. I'd be very careful with doing this. Don't just let your. If you're going to allow this within your organization, you need to have very clear guidelines. There's teams that do red teaming within companies. I was on a contract recently where they have a whole team dedicated specifically for red teaming their company. Great, that's awesome, but they have very specific guidelines and directions on which they do this red teaming. It isn't just go and shoot from the hip and just make it happen. They will actually have a good plan around this.
Speaker 2:
You avoid testing in production environments to minimize the overall risk. Again, you want to do this in your test versus hitting it in production. You go into production. What ends up happening? Things go sideways. You need to document the verified findings. This is recorded, the evidence screenshots, all of these aspects and then annotate false positives for or low priority issues. Those are important parts you have to go through.
Speaker 2:
Some other common challenges you run into is a high number of findings, especially during initial scans. You may have this go, oh my gosh, this thing lit up like Christmas right, all your Christmas tree lit up and you're like, oh, I can't do this. This is overwhelming. Again, you're going to have a high number of findings. You may have to tweak it down a bit to make sure that you understand what you're actually getting, but then focus on what you can do. Don't focus on the numbers. Focus on what you can accomplish. Eat this little elephant, one bite at a time. Again, also dynamic environments where vulnerabilities may change. This is also another part where, depending upon where you find the vulnerability if it's in a very dynamic environment that may change in time between the time that you discovered it to the time you remediate it. So you need to really understand if it's in an area that's high dynamics that are going on, you need to determine how am I going to address those immediately or very quickly. So that's a common challenge you run into when you're dealing with these findings as well.
Speaker 2:
Limited resources oh, if you're doing any sort of manual validation, having limited resources can be a challenge. Now, best practices Use tiered approach. Focus on high severity vulnerabilities first Makes sense, common sense. Go that route and leverage artificial intelligence and machine learning for quicker validation. This is, I think, going to be a really great thing for us all in the future. The use of AI and the ability to validate these risks and to also prioritize them which one should you work on now versus later? I think is going to be an extremely important part of the cybersecurity space. Important part of the cybersecurity space If they can build this into their capabilities, where you mash a button and it says, yeah, you've got a lot of challenges. However, these three are super bad. Go fix them now. That is huge. That will be extremely important for a company. So if you're a guy out there thinking about making that I don't know, maybe it's already exists, but something to consider making it, or go work for a company that can help make it Continuously update scanners to reduce the likelihood of false positives Again, another part that's important.
Speaker 2:
Okay, so key concepts around exception handling. You're managing the risks associated with any unresolved vulnerabilities. You may want to document why these vulnerabilities cannot be remediated, and start with the standards, timelines that are there, and then you also want to ensure that you have compensating controls in place to reduce the risk. So this is when you're dealing with some sort of exception that you may run into. So now some reasons for exceptions.
Speaker 2:
There's a few of those Technical constraints. Right, you have a legacy system with no available patch that you can get into. That would be a technical constraint. So then you have to figure out how am I going to mitigate that? Compatibility issues with critical applications or systems. You may have a critical system or application that is extremely old and it runs on a very old server and because of so, it needs to run a very old piece of a very old application and therefore you can't update the application because if you do, it breaks the server or breaks the overall critical system. So you may have to deal with that. And so then you have to understand well then do I put that in a segregated location and I watch it as best I can? Those are different kinds of considerations you're going to have to deal with when dealing with exceptions.
Speaker 2:
Operational constraints obviously the system, the production systems, cannot be taken offline, so therefore you can't take them off to fix them. How do you deal with that? Tight project timelines or resource limitations that's a big one. You're not going to have the people or the money to do it. So how do you end up taking these critical production systems and updating them? So typically you would go okay, well, I'm just going to set up a new server, I'll push everything to this new server, I'll update the old server, blah, blah, blah. But that takes a lot of time and a lot of coordination and therefore it doesn't always happen. In many cases people just kind of walk away from it.
Speaker 2:
Business constraints you have risk tolerance aligned with your business objectives. Maybe the risk tolerance with your organization is a very low risk tolerance and you need to take this critical system down and they're going to go. No, you cannot do that because we do not allow risk and therefore you taking it down will incur more risk to our company. So therefore, you cannot do that, which then you could come back with a counter that if I don't do it, it could be bad for everybody. Cost benefit analysis showing remediation, cost outweighing, potential impact as well. So those are all different areas that you need to consider.
Speaker 2:
Another key concepts around exception handling risk assessments Evaluate the risk of leaving the vulnerability unpatched. You need to calculate the impact and likelihood of the overall severity. This is an important part of any sort of risk assessment that you're going to do. You also need to document this exception. Do not I repeat, do not just let the exception sit out there and cook. You need to remember that. You have to go and fix it. This includes expiration dates for review and so forth. The other thing is implementing compensating controls. You need to understand this can be done through network segmentation and advanced monitoring or logging or IDS type systems put in place to monitor these different areas. So you're going to have to consider how do I put these compensating controls in place to mitigate this?
Speaker 2:
And then, finally, the approval process Secure authorization from stakeholders and to ensure that they are all aligned with doing what your plan is. Now the last thing around there is approval process. You need to ensure that you have authorization from the stakeholders to give you what you need, and this would include periodic reviews and reassess the overall exception. Last thing is compliance implications. You really truly need to have these exceptions documented, especially when you're dealing with PCI DSS or GDPR. It's important you have this documented. From a regulatory standpoint, you need to maintain an exception register or like a risk register, to ensure that you have accountability and you have some level of audit readiness for that. So you need to have some level of audit readiness for that. So you need to have all those things in place. So those are just a lot of different aspects when you're dealing with exception handling.
Speaker 2:
The last topic we're going to get into is ethical disclosure. Now, the purpose of this is to ensure that you have vulnerabilities remediated by in a responsible or timely manner. You find a problem, you fix it quickly. That's the overall goal, and the goal is to avoid public harm or misuse because of the disclosed situation. You see this a lot, where folks will come in and go. I got a problem, I saw it, they disclosed it to Microsoft. Microsoft had time to fix the problem and then they disclosed it to the rest of the public. That's the overall goal that you want to try to do Now. The principles of ethical disclosure is to protect the affected organization or vendor from unnecessary reputational damage they may get and limit the risk of exploitation by the malicious actors as well. This balance includes the public's right to know versus the organization's ability to mitigate the risk. So you have to have all of this in place before you're doing your ethical disclosure.
Speaker 2:
Now the types of disclosure are coordinated disclosure, full disclosure and responsible disclosure. The coordinated is that you're working with somebody else to fix the issue before you actually come forward with it. Full disclosure means you complete details of what's going on. Okay, ideally we wouldn't want to do that, because you're telling everybody where the bad things are at. That's where full disclosure comes into is not the best. Responsible disclosure is you share details with the affected parties while providing a timeline for a potential public disclosure to encourage the remediation. That's the Microsoft aspect. That's a responsible one. You come out, you tell Microsoft hey, you guys got to fix this. You got two weeks, fix it or I'm going to let everybody know and then from there you would do a coordinated disclosure. But ideally you wouldn't want to do a complete, full disclosure just because that would be bad. Some steps that you consider doing is identify the responsible party Again, determine in the organization who is responsible for this vulnerable system, report the vulnerability, use an official communication channel or some sort of bug bounty program to report this vulnerability out there Maybe get some extra cash if that's the case and then include the technical details, how you came up with it, what was a proof of concept that you did all of those aspects.
Speaker 2:
You need to kind of come around to Set a remediation deadline, pick a date 60, 90 days usually more than 90 days is too long, but I would pick a date that's in there. Usually between that. 60, 45 to 90 days is good. You need to follow up, monitor the remediation process and provide any sort of assistance they may need. And then a public disclosure, if applicable. You may not want to disclose this and, depending upon the situation, it may not be the best to do so Now. Some people will do it because they're trying to get their name out there, but you want to consider your public disclosure if that is something that you actually want to go through with your organization. If it is your company, you need to really get counsel, guidance before you do any sort of public disclosure. I highly recommend it. Don't do it. Just don't go off and just do it. It would be a bad thing and you will not be a happy camper. You may be looking for new employment, so don't do that.
Speaker 2:
Key concepts for ethical disclosure again, challenges and risks. There's legal ramifications, like I just mentioned. Misinterpretation of intent by the affected parties that can come out depending on if you feel like one party is trying to do something. They have some sort of bad intent that can come across that way. They may not, but it may come across that way. Delayed remediation due to bureaucracy or lack of resources Again, that can happen. A lot. People don't want to make a decision, especially legal. If you've got to go to legal and get legal approval, good luck. They may take you a while to get that done. Best practices again, follow ISO IEC 29147 around vulnerability disclosure important part and then also you can see these through MITRE and or FIRST and then engage in the industry-recognized platforms such as HackerOne or BugCrowd. You should clearly document all communications for legal and ethical accountability.
Speaker 2:
Legal baby, know your legal stuff.
Speaker 2:
Do not go rogue on this. I highly recommend it. If you do, you will not be happy. Again, I'm not a lawyer, but I will tell you from experience don't do it. Make sure you have everybody aligned. I will tell you from experience don't do it. Make sure you have everybody aligned. And even after everybody's aligned, they still will disagree. So just telling you, just saying All right, that's all I've got for you today.
Speaker 2:
Go to CISSP Cyber Training and check out this podcast. You can see this information. All of it's available to you. You can also go and purchase the products that I have at CISSP Cyber Training and you gain access to all of my content. You bet, baby, all of it. If you need some help with some mentoring, I've got that product available to you as well. And the last thing is, if you are looking for a cybersecurity consultant of any kind, just reach out to me at ReduceCyberRiskcom and I can help you with that too. If I can't do it, I've got other folks that I work with that can help you as well. Again, I'm here to help give you what you need to help make everybody secure, because, as you all see it, we need it. All right, have a wonderful, wonderful day, and we will catch you all on the flip side, see you.
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!
