CCT 292: Analyze Test Output and Generate Reports (Domain 6.4)

One DNS bug shouldn’t take your business offline—but it did for thousands. We open with the AWS East outage to show how a single point of failure in DNS can cascade through critical systems, then get tactical about building resilience that actually holds up under stress. From multi‑region architecture and failover planning to budget trade‑offs leaders often dodge, we make the case for redundancy you can defend to finance and prove with tests, not promises.

From there, we translate CISSP Domain 6.4 into actionable steps. You’ll hear how to structure vulnerability reports that leaders read and teams use: crisp executive summaries, deep technical details, and remediation plans with owners and timelines. We contrast internal and external scans—what they find, where they break, and how to plan windows that won’t knock over production. Expect practical guidance on ranking findings by business impact, taming false positives, and using trend analysis to show improvement over time.

Validation and exception handling take center stage as we walk through verifying exploitability, aligning CVSS with real risk, and documenting exceptions the right way. When patching isn’t possible, we outline compensating controls like segmentation, WAFs, logging, and virtual patching that reduce exposure without halting operations. We close with ethical disclosure best practices—coordinated timelines, bug bounty channels, and the legal safeguards that keep researchers and organizations on the same team.

If you want resilient architectures, credible reporting, and a vulnerability program that leadership trusts, this conversation gives you the blueprint. Subscribe, share this with your team, and leave a quick review with your top takeaway—what’s the first resilience fix you’ll prioritize this quarter?

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!

Chapters

• 0:00 AWS DNS Outage Breakdown
• 2:00 Single Points Of Failure Exposed
• 5:30 Building Cloud Resilience
• 8:45 Free Training And Resources
• 10:30 Domain 6.4 Reporting Overview
• 14:30 Summary Vs Technical Findings
• 18:30 Internal Scans: Scope And Pitfalls
• 24:00 External Scans And Risks
• 30:00 Validating Vulnerabilities

Transcript

SPEAKER_00: 0:00

CISP sniper training training and CISP Hi, my name is Sean Griber. CISP exam and roll your cyber checker in the way. Alright.

SPEAKER_01: 0:25

Good morning, everybody. It's Sean Griber with CISSP Cyber Trading. And today is what? Today is Monday. And we are going to be talking about various aspects of the CISSP trading related to domain 6.4. That's what we're going to be focused on today. But before we do, just wanted to talk about an article that everybody, I do mean everybody, has talked about in the past couple days, basically last week. And it was the single point of failure for Amazon. And what actually occurred when it went down? Well, there's a bit of a challenge, right? So everybody kind of knew that it was related to DNS. And so according to Amazon, and actually this is on Rs Technica, the root cause of this was a bug, a software bug in the DNS management system for Dynamo DB. So that, along with the also a DNS enactor, they caused a critical failure in the DNS subsystem. So lots of things went down. And it was in uh AWS East that went down. Now one of my friends sent me a picture of a bunch of uh like the Jenga blocks, and then underneath it, it was like one block for AWS East and everything else. Once you pull that one block out from Jenga, yeah, it all fell down. But this is a series of issues that occurred. Uh they basically it lasted for about 15 hours and 32 minutes, according to Rs Technica. I did not know the exact amount of time, but it affected around 17 million different reports. We're all about that, and about 3,500 organizations were affected. Now, the big issue of this is obviously it's DNS. And as we all know, DNS really is the linchpin of how the internet works because we can't remember IP addresses to save our life, let alone what Google's IP address is, or Sean at CISSP Cyber Training's uh IP address is. So therefore, DNS is such a huge factor in all of our activities. Well, now as everything has been moving to the cloud, air quotes, but basically it's a third party managing everything, it is becoming a little bit more critical that you understand what's actually going on. And you also want to consider resiliency as it relates to your organization. And this is something that has come up and bit people numerous times around resiliency. Now, what does this mean? Well, what it really comes down to is that if you put all of your eggs in the AWS East bucket, when this outage happened, because they're like 99.9999%, always up. Well, but unfortunately, when they go down, they take everything with them. But if you have all of your eggs in the AWS East instance, um, now you have no way to be resilient in the event something bad were to happen. And this came up in numerous conversations I've had with senior leaders about how what should they do. And the ultimate point is that people didn't want to spend the money to actually go and have a new edition set up in AWS West, because you got to have that all built out and baked out. And guess what? It all costs money. So a lot of times that won't happen. So we recommendation I'm hoping out of this whole thing that's occurred is the fact that there's going to be some more resiliency built into your environment. So if you haven't done that, right, and you've been relying everything on AWS East, you need to really consider what is the most critical things of your organization. And with that being said, if you know what those critical systems are, then you need to make sure that you have the ability to flop over to them and put them in AWS West or some other location that's that can allow you to operate critical applications. So again, one of these aspects is really important for you to consider resiliency in any sort of aspect with your company. Because if it's up to about making money and you're not resilient, well, guess what? You're not making money, you're losing money. And then people get mad, people get upset. Yeah, it just never goes well. So the ultimate point of this is do not put all your eggs in that specific basket. Because if I was carrying the basket, I would drop it and I would break all of your eggs, and that would be bad. So we don't want that to happen. So again, AWS, it's all about them, and it's about that instance that occurred. Again, single point of failure, i.e. DNS, took out the internet, and people were screaming, going, What is happening? And I mean it, guys, you guys know this better than anybody, but everything runs off the internet, and rightly or wrongly, it does. So, you guys, as a security folks, you are you guys and gals, and you're ones that are out there helping make this happen, you need to truly use this as an example of how you need to have resiliency within your organization and what these companies should do to avoid the AWS outage. And this doesn't matter if it's AWS or Azure, they're still gonna have the same problem. So, plan for resiliency. Yes, cannot complain or cannot say that enough. Okay, let's move into what we're gonna talk about today. Okay, before we do, just wanted to quickly put a shout out for CISSP Cyber Training. Head on over there. I have got lots of free content for you. If you want free CISSP questions, got them. If you want the rapid review questions or rapid review documents and the rapid review videos, got them. All that is available to you at CISSP Cyber Training. It's free, doesn't cost you a dime. All I want is your email address. Yeah, that's it. And the reason is because I'll send you stuff. I just send you stuff. You can decide if you don't like it, you can unsubscribe. It's not a big deal. No harm, no foul. But go to CISSP Cyber Training and get access to all of my free content, blog, CISSP questions, you name it. If you want a little bit more detail and you want to basically be spoon fed and have a lot of information fed to you on how you should practice and prepare for the CISSP, you can purchase my products that I have. And that will give you either one time with me or two, it'll just give you the content that I have. It's all in video format, all curated, all available for you. I wish I would have had this when I was studying for the CISSP. Truly do, because it would have made life a whole lot easier. All right, so let's move into what we're gonna talk about today. This is domain six, six dot four, analyze, test, output, and generating reports. So, what does this entail? So we're gonna talk about different types of reporting, and you're gonna need to be aware of these. And they're the reason I say you're gonna need to be aware because I'm I'm doing uh with working with a company right now and they are a startup and they don't have a lot of this stuff in place. So you need to build this for them. Well, we're gonna talk about a security vulnerability scan reporting. These are really important, especially if you're dealing with an inside of your incident response process. You're also dealing with your security operations. All of these pieces are important. Now they communicate the findings from the various vulnerability assessments that occur. Now, this could be both a physical one where people are actually going there on site, it could be an automated one where you have a piece of equipment that's running. It could be a lot of different assets. It could be just somebody given a spreadsheet and just answering questions. But they provide actionable insights to technical teams and the management. These reporting documents do that. And they also meet the compliance and regulatory requirements that you are gonna run into. If you haven't lately, you will in the future. So availability to have some level of reporting is incredibly important. A lot of times people just don't pay much attention to it, but it really is. And especially if things go sideways and after you get done dealing with an incident, they're gonna start asking, well, what kind of reports did you have? How often were you fed these reports? What did you do with these reports? Again, it's all about evidence, and you gotta have it. So there's different types that are included in each of the reports. We're gonna talk about the summary section and the technical section. So your summary section is a high-level overview for management for them to understand exactly what is going on. The summary is it's basically a summary of critical findings, risk levels, and impacted systems. Now you can tailor this report however you want to help your leadership. And depending upon your leadership's involvement or maybe lack of involvement, you may depend on how much information you actually give them. You may want to begin, you may want to start just with critical findings and the risk that's associated with the company. Rather than just burying them with a bunch of details, which they'll just eyes will roll in the back of their head, they'll fall asleep, and then they'll pass out. So you don't want that, right? That's bad. So you want to be able to give them the information they need so that they can make critical and logical decisions. Then there's the technical details section. This is a detailed list of vulnerabilities, which includes obviously vulnerability IDs, severity levels, affected assets, any of those pieces that tie together. So your CVEs, your C VSSs, any IP addresses that are associated, uh, potentially any sort of security or accounts, maybe that you see as you're out there doing scans and you realize you have service accounts that have domain admin, you'd want to have some of that in the details section as well. So you want to have a remediation for all the recommendations or mitigation strategies because guess what? That is what they're gonna ask you. They're gonna potentially just come out and ask you, okay, so this looks bad. What should I do now? And you need to come with a plan on how you're gonna remediate these various issues. Now, we're also in this reporting, there's gonna be other types of information, could be trend analysis as well, comparison to previous scans to measure improvement, or potentially the deterioration of what you've got in place. Maybe you're falling backwards, you're sliding, going the wrong direction. They're gonna maybe want to know that. And then therefore, they will hold you and everybody else accountable for it. But what that's good because you want them to. And then the identification of recurring vulnerabilities, ones that are not getting patched. Now, I've used these reports as a basically as a stick in many ways, and I use not as a stick to go have Fido go fetch it, to basically rack knuckles of people and just kind of tap them on the knuckle saying, hello, I want you to fix this, and then if you don't fix it, I'm gonna take it to your boss. Yes, yeah, just that's very grade schoolish, I know, but it works. And you want to be able to have, but you have to have this report to do it. The reporting frequency, this is also based on your requirements that you may have for your organization. Could be monthly, quarterly, or after any significant system changes. You may want to do that. Ad hoc reporting may be necessary after high profile incidents or new vulnerability discoveries, i.e., you know, when you have the DNS goes down, maybe it was because of you, it probably was your fault. Um, then you know what? You're gonna want to have some sort of report about that specifically saying why it was your fault. There's audience, again, you want to tailor these reports specifically to the audience that's receiving them. The executives are gonna get a different report than your technical folks. So that is an important piece of this. Prioritization of vulnerabilities, you also want to rank them based on the list or the risk level to your company. They may not all be at a high risk, they may be all low. Maybe you've done a great job of patching everything up, and you know what? You got no issues. All you got is low stuff. That would be awesome. That would be incredible. It'd be highly unlikely, but it would be awesome and incredible. And you and if you are in that rarefied air, you are amazing. And just tell yourself that on a daily basis. Now, the concept of an internal scan, we got different kinds of scan reports as well. So, the internal scan, the purpose of this is to identify misconfigurations, outdated software, or vulnerabilities within internal systems. This is not something that's focused on external entities. This protects against insider threats or lateral movements done by the attackers once they gain access to your environment. So you want to make sure that you're scanning the internal side and the external side. Now, some scenarios where this is being used, you have routine security posture assessments, maybe pre-audit or compliance checkups, maybe a post-breach analysis for understanding what was exploited during these internal aspects. So all of that can be done with the various scenarios. And so you want to make sure that you have a good plan and yet you're doing that. Now, some common findings that you may see with an internal scan is misconfigured servers or network devices. Yes, you will find network devices that basically have admin admin. You will find servers that don't have passwords or their passwords never expire. Big problems that you will find. So, which is good though, you want to find these issues because then you can go and deal with them. Outdated patches or end-of-life software. All of those are big factors as well. You may have excessive permissions or weak internal controls, unauthorized applications or shadow IT. I've found lots of shadow IT, but basically Wi-Fi uh hotspots that are sitting in warehouses. And I've never really found one that was nefarious, right? Someone just stuck it in there to break in or hack in. No, I didn't really find that, but it was people trying to do their job and they didn't have good internet connectivity. So as I find out that there's this hotspot sitting in this warehouse, I start asking the question, going, why is this here? And they're like, Well, because we don't have internet. Well, have you brought that up? Well, yeah, but nobody does anything about it. So if you had internet, you wouldn't need the hotspot. Yeah, we wouldn't need the hotspot. Okay, let's get you internet. So the point was that they weren't doing anything bad. They were just trying to do their job. And therefore, you find a lot of shadow IT because of that. Unsecured, sensitive files or databases, that's another thing that you'll see. That's a common finding for internal scans. Now, a key concept around internal scans are there's challenges with these. They're larger scope of systems compared to external scans. What does that mean? Well, usually you just have one external X point or IP address that you're actually scanning. But when you're dealing with the internal systems, depending upon the size of your organization, they can be substantial and the enterprise can be huge. So there's also greater potential for false positives due to internal system complexity. You'll get a lot of different systems in there and they may come back and say you have Houston, we have a problem, and you really don't have a problem. There's a risk of overwhelming the teams with low severity findings if prioritization isn't clear. I had to do this. You you'll get to a point where if once you get through a lot of these, you may just start leaving some of the low ones alone because you guys got other stuff to worry about. But that doesn't mean that a low one can't become a severe problem in the future. You just want to plan for that as much as you possibly can. Remediation reporting, this includes actionable insights and timelines, recommendations, and your things that you can do now and immediately to help you. This highlights critical issues that could compromise your sensitive systems, such as HR or financial systems. So you want to really have a good remediation and reporting plan. When you're dealing with external scans, there's the purpose of these is to identify vulnerabilities in systems exposed to the internet, right? If your point of presence, such as web servers, API connections, any cloud-based resources, all of that is external scanning. You want to protect your organization's public-facing assets from unauthorized access or data breaches. So therefore, you need to understand what you're trying to protect. Now, some different scenarios that may come around this is regular perimeter security assessments, pre-launch scans for new interfacing or new face internet-facing applications, or even third-party risk that is coming into your organization as well. So you can find all kinds of stuff from unpatched web servers and software, open ports or services, weak encryption, weak application uh configurations, misconfigured firewalls, you name it, it's the gamut, right? Because what ends up happening, people have to put stuff in place. We have a timeline, we have a deadline, we gotta get it deployed. So they put it in place and they don't do what they're supposed to do to protect the information that's there and to make sure that it's configured properly before actually making it live. So common find these are a common set of challenges that run all the time within externally facing systems. Now, when you're dealing with externally scan external scan reports, the challenge with these is that balancing balancing comprehensive scans with minimal disruption to production. What does that mean? Well, usually when you're scanning something externally, like your main point of presence, you can run the risk of breaking things and causing a small denial of service. So that could impact your business. You don't want that to happen. So you really need to have a good plan on how you're going to deal with that. Coordinating scans across geographically distributed networks or third-party systems. That can be a challenge. You can come across as a hacker depending upon the system you're scanning. And you really got to have some good language in place from a legal standpoint to ensure that you don't get into yourself into a fix. And then addressing third-party or vendor vulnerabilities that affect your organization's exposure can be challenging because they may see it as you may see it as a problem, but they may not see it as such a big deal, and they may not address it quickly. So now you have to get the lawyers involved, and it's the legal teeth of your organization that you have to kind of figure out. So it can be a bit of a quandary. Remediation reporting, this is where you prioritize critical vulnerabilities, obviously, public exploit code that's available. If it's already out in the public and it's being exploited, you fix it, right? Don't wait with that one, right? This includes timelines for fixes such as accountability and assignments, and then you document long-term remediation strategies such as implementing web application firewalls or upgrading unsupported software. Now you're gonna get into situations where you will have unsupported software. You're gonna have to decide are you gonna update it or are you not? There might be situations where you will not update the software because you just really can't, and that's something you're gonna have to work through. And if it's a high enough risk, then you have to find the money and then upgrade the system. So those are some really big quandaries you're gonna have to deal with as a cybersecurity professional. So now when you're dealing with validating your findings, you there's some key concepts to truly understand. So what's the purpose of validating? Well, this is to confirm that you've detected the vulnerabilities are legit, right? Too legit to quit. Okay, that's terrible. You also want to avoid disruptions or misallocated resources caused by false positives, right? You send your people, hey, go fix this, and then it's a false positive, and they just wasted half of a day. You're right. That's that's opportunity cost that costs you money. You want to avoid that. You also want to build trust in the vulnerability management process. So if by validating these findings, hey, you now can say, yeah, my vulnerability management program is successful. It's doing what it's supposed to do, and therefore the money is well spent. Now, validating this process, you need to kind of have some steps you're gonna want to go through. One is analyze the findings. So you need to cross-check the vulnerabilities using multiple tools or manual verification. Is it actually legit that what you're seeing and is it the problem? You also want to validate the severity levels. Is the CVSS score match up with what your risk is for your company? So you need to make sure that the there's context around that. If CVSS is like 9.5, but you go, yeah, but this isn't really much for an effect. If somebody compromise it, that's bad, but it's in the middle of 10 different things and it would be extremely hard. They probably could compromise something else over that. Then you then you go, it's not a big deal. So those are things you're gonna have to work through, but that's you taking the initiative to kind of try to look at all these different issues and then kind of do an evaluation of where you're at. Now you want to evaluate the impact. This is assessing the vulnerability and how it affects the specific asset. You also want to turn the exploitability of the current environment. Is the system behind a firewall? You want to replicate the exploits, you want to see if these exploits actually do work. Now, you may want to use a tool such as Metasploit for this kind of capability, but I will tell you that you want to be very careful if you're trying to replicate this. You want to do it in a test environment. I would not do it in your production environment. You could run the risk of actually breaking things. So you want to avoid doing that at all costs. You also want to document the verified findings and record any evidence that you see, and then potential vulnerabilities and how you have validated them, and then also how you are going to remediate them. So that's an important part of all of this. Now, some common challenges when you're dealing with validating your findings, a high number of findings, especially during initial scans, can be overwhelming, and you're just like, ugh, throw your hands in the air and give up. Yep, that can happen. Been there, done that, got the t-shirt. Uh, you just get overwhelmed. So you have to really limit your resources for this. It also you want to limit limited resources for manual validation. You don't have a whole lot of people. And if you're gonna be doing manual validations, that's gonna take time and it's gonna take people, and you don't have that. Dynamic environments where vulnerabilities may change before the validation is complete can happen, right? So if you have this val this dynamic environment where things are getting spun up, spun down, all kinds of things that are going on within your environment. Well, you maybe you don't have time to validate it. And so as a result, it's fixed before you actually can validate the problem. So, some best practices. Use a tiered approach to focus on high severity vulnerabilities first. Leverage AI and machine learning tools for quicker validation, and then obviously update your scanners to reduce the likelihood of false positives. Some key things around validating, you just want to consider while you're doing this. Now, exception handling. There, every like everything out there, there are exceptions for everything. So you want to manage the purpose of this is to manage risks associated with unresolved vulnerabilities, and you need to document why, specifically why, these vulnerabilities cannot be remediated within what timeline you have scheduled. You also want to ensure that compensating controls are in place to reduce the risk to your organization. So you have situations come up where, like, say I was in a manufacturing uh area and they have a turnaround coming up, and a turnaround's a humongous deal. But the turnaround wasn't going to happen for another month. Well, I needed to make some changes immediately within that their network. But to do that, they would have to take down part of the site. Well, that's not acceptable. So what we did was is we had to delay, we made an exception, we delayed for a month while waiting for the turnaround to occur. Then once the site went down, we had everything pre-positioned, ready to go, and then we made the change very quickly when the site was down. So those are some things you're going to have to plan when you're dealing with exceptions. Now, there's a reason for these exceptions, right? You have technical constraints like legacy systems with no available patches. You have compatibility issues with critical applications or systems. You could have operational constraints where you have critical production systems, like I just mentioned, they can't be taken offline, or tight project timelines and resource limitations. The last thing is business constraints where you have risk tolerance aligned with business objectives, and then a cost-benefit analysis showing remediation cost outweighing potential impact. So all of those are different constraints you can have or reasons for exceptions that you'll want to do. Now, you want to have a deal with a process for this. You want to first do a risk assessment. You want to evaluate the risk of leaving the vulnerability unpatched. If I leave it alone, what is that going to entail? You want to calculate the likelihood and the severity of this situation to ensure that you're understanding the overall risk to your company. Then you need to document, like what we talked about earlier. Documentation is everything. If you don't document stuff, it didn't happen. So you need to state the reason for the exception and the potential consequences if it were to be vulnerable or if it would be exploited. This includes expiration dates for when it's going to be reviewed, and you need to follow those dates. It's all important that you, whatever systems you have, you are following them as well. Then you want to implement compensating controls. This is where you have alternate measures to mitigate the risks, such as segmentations, advanced logging and monitoring, IDS or WAFs, web application firewalls, all of those put in place. And then you have the approval processes where you secure authorization from stakeholders, i.e., maybe your senior leaders, or maybe even the board, to get these things done. And then follow up with periodic reviews to reassess the exception. Again, it's a process. You assess it, you document it, you implement the controls, and then you get the approval to make that happen. The last thing is compliance implications. Their exceptions must be documented to meet regulatory requirements, such as PCI DSS, GDPR, and so forth. And you need to maintain an exception register to ensure accountability and audit readiness. Then when the audit team comes in, they're going to ask you, where's your exceptions? Where are they stored? And you want to take very careful control of those. You don't want just everybody to know which ones are being ex that have exceptions because they are vulnerable. And if someone gets access to them, it could cause all kinds of chaos and hay or havoc within your organization. Ethical disclosure. Now there's some key concepts around ethical disclosure where the purpose of this is to ensure that vulnerabilities are remediated in a responsible and timely manner. You want to avoid public harm or misuse of the disclosed information, so you are going to do this in a way that is mannerful, right? It's great. It's awesome. The principles of ethical disclosure is where you protect the affected organization or vendor from unnecessary reputational damage due to this situation. And you want to limit the risk of exploitations by the malicious actors who might be trying to exploit this situation. But you have to balance the public's right to know with the organization's ability to mitigate the risk. Typically, you let people know, and if they don't do something about it, you let them know again. If they don't do something about it, whack them over the head with the vulnerability. Coordinated disclosure. This is where you work collaboratively collaboratively. Yeah, that big word. You work with other people, right? With the affected organization to fix the issue before public disclosure. So you want to work with them. You're working together, you're on a team, and you're kind of back and forth, getting it ready to go. Full disclosure is basically you release the complete details of the vulnerability to the public, which is less preferred, right? You don't want to do that. That's where you come out and say, you know, hey, that guy, they got a problem. Oh, hey, everybody, they've got a problem. Yeah, that just usually isn't the right thing to do. Uh, you want to give people the opportunity to fix the problem. Responsible disclosure is where you share the details with the affected party while providing a timeline for public disclosure to encourage remediation. This is where you draw the line in the sand and say, okay, you've got 30 days to come up with a plan. If you don't do that plan in 30 days or two weeks, depending on how bad it is, um, we're gonna release to the public. So it gets them going, right? But you get you can't just go say that arbitrarily. You gotta make sure legal is on board with that statement. That'll get you in trouble. Some of the key concepts, other key concepts around this. So steps for ethical disclosure. How are you gonna do this? Identify the responsible party. So you need to determine the organization or vendor responsible for the vulnerable system. So you got to know that first. Then you report the vulnerability using the official communication channels or a bug bounty program to do that, i.e., Microsoft, if you come up and say, yeah, you've got a problem, they have a bug bounty program to help with that and they will pay you for that. It includes technical details, proof of concept, and severity assessments, all of those things to kind of prove where is the actual issue. Then you need to set a remediation deadline. This provides a reasonable timeline, usually 60, 90 days for resolution. Um, I say just drop the hammer, baby. Give them 30 days, but no, you probably 60 to 90 is more reasonable. Again, it comes down to those how ugly the baby is. If this thing is really bad, you may want to go earlier than 60 to 90 days. Follow-up, you monitor remediation progress and provide additional assistance as needed. And then public disclosure, if applicable. If no action is taken within the agreed timeline, you then let the hammers fly, right? Again, talk to legal counsel, don't just go do this on yourself, right? Because you got to balance it all out. But if you do it wrongly, you will be liable and then things can go sideways super fast, like rocket speed fast. So, other challenges at risk when you're dealing with ethical disclosure. Legal ramifications. Haha, I can't been hitting that, beating on that drum. If the organization perceives a disclosure as an unauthorized access, maybe they thought you were doing something you shouldn't be, and now they're going to sue you. Can be very tricky. Misinterpretation of the intent by the affected parties, or delayed remediation due to bureaucracy or lack of resources. Those can be challenges with all of this. So, some best practices around this are the ISO or IEC 29147, which is vulnerability disclosure, or frameworks that are provided by MITRE or FIRST. Again, those are all different options that are available to you. But you know, use the reasonable person theory and work with legal team, you can figure it out. It's not difficult, right? Engage with industry-recognized platforms such as Hacker One and Bug Crowd, or and then also clearly document all communications for legal and ethical accountability. Your legal team will probably most likely want you to be uh everything that is shared will be retained for legal hold because it can go ugly, right? You know, it just you don't want to avoid all sort of legal issues that roll into this. So we're gonna talk about some different parts of this. I'm gonna give you some different scenarios around each of these. So we're gonna get into exception handling. So a scenario on this is a legacy system vulnerability. So I'm gonna walk you through a scenario and you can kind of see, have your brain work on this a little bit. A critical legacy system cannot be patched due to compatibility issues with a new security update. An exception is granted to allow the system to operate temporarily with compensating controls like enhanced monitoring, network segmentation, or a virtual patch via an IPS. So you can see this is being allowed because of that specific situation, right? It's being granted. They have other compensating controls in place. It is makes sense, right? You don't have to go out and say, go rip it all out. No, you're you're using your logical with this. It's a risk-based approach. You have to think about that. Scenario two, you have a third-party vendor delay. So a third-party application is known vulnerability, but the vendor has not yet released a patch. Boo. An exception is documented, and the temporary measures, i.e. disabling affected features or restricting access, are implemented until the patch is available. So what ends up happening is you have the ability to go and decide, hey, you know what, we're just not going to use that application in our environment until they fix it. Now, depending upon the size of your organization and the value, they may get on it right away. Then again, if you're a little guy, they may say, that's fine, don't use it. So you need to think about that and how you want to handle the situation. Scenario three a business critical application fails to test or fails a penetration test due to a medium severity vulnerability. But immediate remediation would disrupt operations. An exception is approved with a defined timeline. For remediation and additional controls like increased logging or user access restrictions have been enabled. Again, those are different scenarios that you might see on the exam. Okay, so while we're just going to talk about ethical disclosure real quick, and then we'll call her a day. So this is scenario one where we're talking about ethical disclosure. This is an independent security researcher. This researcher discovers a SQL injection vulnerability in a company's public-facing web application. Woo-hoo. They contact the company's security team, provide detailed evidence of the vulnerability, and give them 90 days to patch before publicly disclosing the issue. This would be followed. Is this following the responsible disclosure policy? And the answer is yes, it is. But you have to have a responsible disclosure policy within your company. Scenario two is a bug bounty program. This is where a tester is participating in a bug bounty program, identifies a cross-site scripting vulnerability, and then in a cloud service platform. They submit the findings through the program's designated portal, obviously their bug bounty program, and this adheres to the provider's disclosure timeline and guidelines, and they're rewarded for their efforts. Yay, money for all my friends. So again, that's something that you may want to consider. And then the last scenario is internal pen testing. So during an internal pen test, a security professional finds a critical vulnerability in an internal system. They report it to IT and the security team through a formalized process, ensuring that the issue is tracked and resolved without any unnecessary public exposure. So again, that's an internal that's where you deal with a pen test, and you're actually dealing with the overall issue. Okay, that is all I have for you today. Head on over to CISSP Cyber Training. Check out my stuff. I've got great stuff there for you. Lots of stuff to help you pass the CISSP, and it will, it's awesome. I mean, seriously. Where were you going to get this kind of training? This training is amazing. You need to sign up for at least the free stuff. Because you know, what's the point? Why not to? You need to pass the exam. You want to study for the exam. This is a great way to get all kinds of highly valuable security information as well as the information you need to pass the CISSP exam. And this part is free. If you want some more and you want some curated and you want some hands-on talking and all of those aspects, look at my paid services. They you will not go wrong. They are an incredible value. Guaranteed, they are. They're an incredible value. And so it's just kind of put it in perspective. All right. I hope that you guys have a wonderful, wonderful day, and we will catch you all on the flip side. See ya. Thanks so much for joining me today on my podcast. If you like what you heard, please leave a review on iTunes as I would greatly appreciate your feedback. Also, check out my videos that are on YouTube and just head to my channel at CISSP Cyber Training, and you will find a plethora or a conocopia of content to help you pass the CISSP exam the first time. Lastly, head to CISSP Cyber Training and sign up for 360 free CISSP questions to help you in your CISSP journey. Thanks again for listening.