CISSP Cyber Training Podcast - CISSP Training Program

CCT 320: OT Attacks And CISSP Domain 6.4 Essentials

• Shon Gerber, vCISO, CISSP, Cybersecurity Consultant and Entrepreneur • Season 3 • Episode 320

Share episode

Send us a text

What happens when custom malware turns IoT into a springboard for OT, and gas pumps become levers for panic? We open with a timely look at Iranian-linked operations targeting PLCs and use that story to ground a full, practical tour of CISSP Domain 6.4: how to analyze scan output and generate reports that actually drive action.

We break down the anatomy of a high-value vulnerability report—clean executive summaries, CVE and CVSS clarity, and the business context that separates theoretical risk from real-world impact. From there, we map a repeatable cadence for internal scans full of misconfigurations, default creds, and end-of-life software, plus a strategy to turn noisy findings into steady wins through prioritization, trend metrics, and small, fast fixes that build momentum.

On the perimeter, we focus on external scans across web apps, APIs, cloud edges, and third parties. You’ll hear hard-earned tactics for handling M&A exposure, vendor VPNs, misconfigured buckets, and certificate drift without breaking production. We share validation steps that avoid false positives and chaos in prod, then show how to formalize exceptions with risk assessments, compensating controls, and an auditable register that satisfies PCI DSS, HIPAA, SOX, and GDPR expectations.

We close with ethical disclosure done right—timelines, ISO/IEC 29147 alignment, and when to coordinate versus publish—so you protect users and your organization without stepping into legal traps. If you’re studying for the CISSP or building a vulnerability management program that survives contact with reality, this guide will help you prioritize what matters, communicate clearly, and keep improving.

Enjoyed the show? Subscribe, share with a teammate, and leave a quick review so others can find it. Tell us: what metric best proves your remediation progress?

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

Join now and start your journey toward CISSP mastery today!

SPEAKER_00:

Welcome to the CISSP Cyber Training Podcast, where we provide you the training and tools you need to pass the CISSP exam the first time. Hi, my name is Sean 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. Alright, let's get started. Hey I'm Sean Gerber with CISSP Cyber Training and hope you all are having a beautiful and 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, they uh we have an elf on the shelf with all my kids as they grew up, and moving that little shelf around was 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 over night overnight, the children get a bit upset. So, yes, it makes it hard when you're trying to deal with that in Santa. Now, if you're listening to this podcast and you still believe in Santa, well then I just kind of let this 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. Ho ho ho no. So we're gonna move on to this, and the bottom line is we're gonna 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 would might be interested in. Uh, 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 U.S. critical infrastructure. Now, we've mentioned this time and again that uh the OT environment within many organizations, because I used to work in the manufacturing space, uh, 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've become very dependent upon it. Well, this group, uh IO control, uh that they created this, this that's not the group, but it's basically they created this backdoor. Uh it's it's a custom backdoor for hijacking IoT devices, and it allows them to have air quotes direct impact on OT systems, including fuel pumps at gas stations. So the goal is that it can attack this specific one, can attack uh PLCs at gas stations, where you go and you fill up your car with petrol. Well, this group they say is tied to the uh 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, and a lot of reasons is because they have oil and gas in Iran, and that's what they're one of their chief exports, so they have a lot of knowledge around that overall space. But they're targeting Israeli-backed uh PLCs that have been created that are also that are in the United States. That's the ultimate goal of those. And they're on Linux-based IoT OT systems that are in BaseL's, D-Link, Hike Vision, uh, Red Lion, OPAC, Phoenix Contact, Telekonika, and Eltronics and other vendors. But I've I've worked on Hike Vision stuff, and so that that makes sense, obviously, where they're at. Now, as you guys all know, PLCs uh 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 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. And so that that way it's important that you keep uh 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. Now they're using uh, and based on a couple podcasts we had back uh about a couple 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, you obviously we mentioned the acronym DOH. Um, and that's 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, and 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 they're not actually sending an SMS message to another guy and another guy, and hey, they're looking at it. No, they're it's 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 uh 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. Well, they're using MQTT to basically push out their different uh software and to allow it to have communications with their um 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 that's 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. Why is this important? Well, obviously, it's targeting the oil and gas industry, so that's a challenge. Two is those kind of tendency, 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 uh gas pumps around the country, people need gas to 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 from for attackers to be able to attack the adversary. So again, there's it's a multi-sphere kind of thing that goes on here with the cybersecurity piece of this. It isn't just, hey, I'm gonna go out and break something. It's you can use this type of activity and this type of hack to really cause fear in people's minds. Good example, New Jersey um drones that are flying over New Jersey, right? You says a lot in the news as of the right uh the uh 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 gonna pull out guns and start shooting at it themselves. Why? Psychological operations. You start messing with people's minds, and they do all kinds of crazy things. I'm not saying that these these little flying things over New Jersey aren't little green men, but that being said, you just 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 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 just a flipping a switch on, things go boom. It's a whole litany of things that can cause challenges. Okay, so let us get into what we're gonna talk about today. Okay, so today we're gonna 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 gonna want to create vulnerability assessments and vulnerability scans of your environment. So we're gonna 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 studying. So, security scan reporting, this is where you're you're communicating 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 it 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. 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 if if unless you have in many cases, you're a you are diehard, you're going to follow the rules, you're going to make these vulnerability scans as you should, and and that you take the utmost care in 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 they're pulled in eight 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 gonna 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 are have been established to force you to do it, so that you actually at least have to attempt to get it done. Now, there's types of information that is included in these various reports. These are any of the report you'll get maybe 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 you can spit it out, that you can then it's actionable and you can do something with. Now, in many cases, this should have lists the vulnerability IDs, which should be your C VE numbers. You know, 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. Now, these being said, the 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 gonna 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 they could, 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 know what, it's okay. It's all right. Because you just have to be able to explain it. That's the thing, as a security professional, you're gonna 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 rec uh 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 your overall scan is this, and you now are increasing and you're making changes. I would recommend that as you do this, because it 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 gonna 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 it may get to a point where you go, I 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 gonna take an overall project to help you get to this point. So those are things you're gonna have to work through as it relates to fixing these vulnerabilities. And you're gonna identify the reoccurring vulnerabilities that keep popping up, and that's gonna 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. 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 any 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 happen multiple times, right? Where you discover something, you're like, oh MG, 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? You keep 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 gotta 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 gonna have to deal with when uh dealing with these various uh vulnerabilities that you're having to fight through. Audience, 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 if it 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 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 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 uh something you may see specifically when you're dealing with the auditors and the more regulated environments. Uh, I've because again, I'll go back to that. I've had to talk to many auditors and they explain I've had it just a 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 ChatGPT, you guys could actually make a cover page pretty simply uh to highlight some of the risks you may have. So something to consider there. Uh, prioritization of vulnerabilities, you need to rank them based on the risk level to help focus the remediation efforts on your high impact issues. Right 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. Oh, I'm gonna I say it's easy, it's it's not really that easy, but to go focus on areas where there is high risk and then negate and mitigate or 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 uh knocking out things and getting them off your plate. Uh 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 gonna 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. So one example would be is 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 gonna bring everything down. It's 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 gotta 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, it does 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, right? Routine, audit, post-breach, those are the really the big three rocks that you're gonna have to fight with. If you work with creating those scenarios and fixing those, that can go a long way to help you get your a good program in place and looking at for these internal risks. 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 one of the things of misconfiguration is admin, admin. Yeah, you username's admin and your password's admin. Admin admin works great. Uh, really great to leverage. Outdated patches, end-of-life software, a lot of that. You'll get a lot of end-of-life software, uh, especially with 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. Um, excessive permissions, weak internal controls, those are another one that you'll that'll 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. 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 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. Uh, because you're again, you've got all kinds of devices from potentially PLCs all the way up to cell phones, right? It depends on your 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, 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 again, don't 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 gonna overwhelm yourself and people, and then it'll go away and you'll be vulnerable and you won't have done anything with it. Uh 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, this includes actionable insights, timely recommendations, and then highlighting critical issues that can 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's it's really can be very laborious, but you gotta do it. If you really want to protect your company, you really gotta do it. So now we're gonna 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. 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. One that this bites people with that I caught when we had, I was with working with my various companies, is MA. MA is nasty, man. I mean, it's great for your company. Getting a uh mergers and acquisitions are awesome. It's you always like to have MA. You feel like, oh my, 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 MA 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 gonna do bring in a new company into your overall ecosystem, I would not bring them in right away unless you have, I mean, I incorporate them within your network, with 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 gonna get all the wonderful bugs they got, just as much as they're gonna get what you've got. So it's really important to have a good strategy when you're dealing with your MA piece of this. Uh so again, uh perimeter scans and assessments, pre-launch scans for new internet-facing applications, and then ongoing third-party risk management evaluations. Third parties are a big factor as well. Uh, 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 gonna be doing third-party uh integrated into your company. Sometimes they may have VPN connections into your organization due to whatever reason, you're gonna want to do 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. Uh, 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 uh come but come up and bite you. And I think a lot of that is is you don't know they exist and the certificates never get updated, and so therefore you're running with old outdated SSL certs. Uh, that can be very challenging. Web application vulnerabilities, if you deal with a web application a lot, uh 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 your Amazon S3 buckets, a Azure uh blob storage blobs. If those are misconfigured, I mean so consider it this way. A lot of times you would see, I dealt with where they said that the the blob or the bucket is an internal bucket. Be realistic, the same with SharePoint. It may be you may have internal routing that is set up to go directly to that bucket or that blob. But unless 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. So you've you've got to make sure that your architects truly understand what they have in place. Um there's 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 waiting, you're hoping that something bad doesn't happen. Hold your architects accountable, definitely. If you are an architect and you're in your 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 you can't 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, uh, but it can happen on external ones as well, is it can affect your production systems. Scans across geographically distributed networks and third parties can be challenging. I told you the story that I had where we accidentally scanned uh the Japanese government when we were doing an assessment, and that like almost caused World War III. Well, not quite that traumatic, but it it was it caused a lot of drama that didn't need to happen because we scanned across a geographic location and they weren't anticipating it and they thought it was an attack. So again, you 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. Uh 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. Uh again, VPNs, you need to know this stuff. You need to know what 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. Um, 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. There's a lot I'm throwing at you here. This is a ton of information. But the point of it is if you're gonna 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 in on the web, focus on the web. Come back to the internal stuff. Internal is important, don't 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. So we're gonna 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, 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 gonna come back and they're all gonna be frustrated and they haven't got anything done. And then the trust in your organization or 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 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 uh 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 control tests to verify their vulnerabilities. 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 gonna allow this within your organization, you need to have very clear guidelines. There's teams that do red teaming within companies. Uh I was on a contract with them 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 they will actually have a good plan around this. You avoid testing in production environments to minimize the overall risk. So, 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 record the evidence, screenshots, all of these aspects, and then annotate false positives for or low priority issues. Those are important parts that you have to go through. 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? Y'all your Christmas tree lit up, and you're like, oh, I can't do this. This is overwhelming. Uh again, you're gonna 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 the little elephant one bite at a time. Uh 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, uh 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 there's a if it's in an area that's a 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. 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, gonna be a really great thing for us all in the future. Uh, 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 gonna be an extremely important part of the cybersecurity space. If we can, if they can build this into their capabilities where that 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, maybe I don't know, maybe it's already exists, 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. 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 standard 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, there's a few of those. Technical constraints, right? You have a legacy system with no available patch that you can get into. That's 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. It break or breaks the overall critical system. So you may have to deal with that. And so then you have to understand, well, do 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 gonna have to deal with when dealing with exceptions. Operational constraints, uh, 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? Uh type project timelines or resource limitations. That's a big one. You're not gonna have the people or the money to do it. So, how do you end up taking these critical production systems and updating them? So, you know, typically you would go, okay, well, I'm just gonna 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. 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 gonna 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, um, it could be bad for everybody. Uh, cost-benefit analysis, showing remediation, cost outweighing potential impact as well. So those are all different areas that you need to consider. Another key concepts around exception handling, risk assessments, evaluate the risk of the leaving the vulnerability unpatched. You need to calculate the impact and likelihood of the overall severity. Uh, 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 gonna have to consider how do I put these compensating controls in place to mitigate this. 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 all those things in place. So those are just a lot of different aspects when you're dealing with exception handling. The last topic we're going to get into is ethical disclosure. Now, the purpose of this is to ensure that your vulnerabilities are 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 disclose 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 the 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. 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 leads you complete details of what's going on. Okay? Ideally, we do 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 rep 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. Yeah, two weeks, fix it, or I'm gonna 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 of that would be bad. Some steps that you consider doing is identify the responsible party. Again, determine on 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 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, that 60, 45 to 90 days is good. Uh, you need a 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. You it would be a bad thing and you will not be a happy camper. Uh, you may be looking for new employment, so don't do that. Uh, key concepts for ethical disclosure, again, challenges and risks. There's legal ramifications, aha, like I just mentioned. Uh, misinterpretation of intent by the affected parties. That can be 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 got to go to legal and get legal's approval, ha ha, good luck. Um, they they may take you a while to get that done. Best practices, again, follow ISO IEC 29147 around vulnerability disclosure, important part. Uh, and then also these you can see these through MITRE and or first. And then engage in the industry recognized platforms such as Hacker One or Bug Crowd. You should clearly document all communications for legal and ethical accountability. Legal, baby. Know your legal stuff, do not go rogue on this. I highly recommend it. If you do, you will not be happy. Uh again, I'm just I'm not a lawyer, but I will tell you from experience, don't do it. You 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. Go to CISSP Cyber Training and check out this podcast. You can see this information, all of it's available to you. Uh, 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 uh 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, uh just reach out to me at reach reducesyberisk.com and I can help you with that too. Got lots of if I can't do it, I've got other folks that I work with that can help you as well. Uh again, we're I'm here to help give you what you need to help make everybody secure because uh we, 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 ya.

Contributor

Shon Gerber

Host