In this lesson,
we're going to discuss vulnerability reporting.
Vulnerability reporting is the process of documenting
and communicating details about security weaknesses
that were identified in systems or software
to the individuals or organizations that are responsible
for addressing the issues to be able to ensure
that these vulnerabilities are managed discreetly
and effectively to prevent exploitation.
Now, when it comes to reporting,
it's important that these reports use clear, concise,
and transparent language
to ensure that the vulnerabilities can be well understood
by all the key stakeholders.
Now at the same time, we also need to ensure
that communications and the reports themself
remain confidential because they contain an exhaustive list
of every known vulnerability
inside of our enterprise networks.
So as we focus on reporting vulnerabilities,
we are going to be discussing internal reporting,
external reporting,
reporting as part of responsible disclosure,
and the importance
of keeping vulnerability reporting information
confidential and safe from prying eyes.
First, we have internal reporting.
Internal reporting serves as the first line of defense
in the vulnerability management process.
Internal reporting involves the identification,
documentation, and communication
of your organization's vulnerabilities
within the organizational structure of your organization.
This kind of internal reporting may happen horizontally
inside of your organization, where a cybersecurity analyst
is providing the results of their vulnerability scans
over to your system administrators
so that those administrators can begin applying patches
or reconfiguring your devices
to remediate the vulnerabilities
that were found by the analyst.
Alternatively, you may also work in a vertical structure
where you're creating a weekly report
that's being sent upwards to your managers and executives
so they can understand the current security posture
of the organization's network.
In either of these cases, though,
the information needs to remain internal
to your organization, and in this case,
that makes it internal reporting.
When you're making an internal report,
it's important that your report provides
the details and clarity
about the vulnerabilities that were being discovered
during your scans.
Your report should also be timely
because rapid reporting can drastically reduce
the period of time
that your organization is going to be exposed
due to a known but unpatched vulnerability
inside of your network.
Now, another key concern
when you're doing internal reporting
is that you have properly established
the communication paths and protocols that are going to be used
when new vulnerabilities are discovered,
and the results of a new vulnerability scan
is going to be ready to be shared internally
across the system administrators, managers, or executives
through this new communication path.
Second, we have external reporting.
Now, external reporting occurs
when you need to discuss your vulnerabilities
outside of your own organization structure.
External reporting is usually going to involve discussions
with your vendors, your partners,
your customers, or the public at large,
depending on the specific vulnerability
that we're talking about.
Now, one of the most commonly used
external reporting methods
is to coordinate with your vendor.
By engaging with the vendor
of your vulnerable system or software first,
you're giving them a chance to rectify
and remediate the issue, not just for your organization,
but for all customers who rely on this vendor's product.
Another common form of external reporting and communication
is going to occur when you share non-sensitive aspects
of that vulnerability with databases like the CVE database
or the vendor's own knowledge base or support forum
to be able to increase
the cybersecurity community's knowledge
about this given vulnerability.
Also, when you're conducting external reporting,
it's important that you ensure that any sensitive details
about your systems and the data they contain
are not being disclosed
if that could put other people at risk.
For this reason, it's important to respect
the privacy of your employees, your customers,
and your vendors when you're discussing
potential vulnerabilities with other external organizations.
Third, we have to consider reporting
in terms of responsible disclosures.
Now, responsible disclosure reporting
is the art of disclosing vulnerabilities ethically
and judiciously to the affected stakeholders
before making the announcement to the public at large.
Responsible disclosures are focused on collaborating
with the entity responsible for the vulnerability
in the first place, such as a software developer,
so that they can develop a hotfix or a security patch
for the vulnerability that you discovered.
This is often going to be done as part of a bug bounty program,
which is a form of responsible disclosure.
Additionally, when you work with the vendor,
you should give them a grace period of a few weeks
or even possibly a few months in order for them to be able
to ensure that they can address the issue and deploy a patch
before you make any kind of public announcement.
Otherwise, a threat actor would hear your announcement,
create an exploit to attack the vendor's customers
who are now vulnerable
to the new attack that you discovered,
and this is going to cause all sorts of problems.
When you're conducting responsible disclosure,
you need to provide a detailed report to the vendor,
including the method you use to exploit the vulnerability
so they can reproduce your attack or exploit,
the potential impact of the vulnerability
if it was exploited,
and any proposed mitigations that you would recommend
until the vendor has time to release a patch
for the vulnerability.
For example, if I just discovered a new vulnerability
in the Windows File and Printer Sharing service,
I should first go ahead and notify Microsoft
as part of their bug bounty
or Responsible Disclosure Program.
When I do that, I'm going to tell them
about the vulnerability I discovered, what the impact is,
and any proposed mitigations for it.
So let's pretend that the vulnerability I discovered
is only effective against version one and version two
of the SMB protocol, but not version three.
So in this case, the mitigation might be
for Microsoft's customers
to disable version one and version two of the SMB protocol.
Or if this vulnerability was discovered
to be a remote code execution vulnerability,
we might make the recommendation that Port 445,
which is used by SMB,
is going to be blocked at the customer's firewall
because that way if Port 445 is closed,
only people internal to the organization
will be able to use it
and nobody from outside of the organization
will be able to access the servers using Port 445.
This will prevent an external threat actor
from exploiting this vulnerability
remotely over the Internet.
These are just some examples of mitigations
that could be used until the security patch to plug the hole
would be released by Microsoft
through the Windows Update service
to all of their customers.
Now, fourth and finally, we need to discuss the importance
of confidentiality in our vulnerability reporting.
Confidentiality in our vulnerability reports
really is a non-negotiable matter
because the details included in those reports
are basically going to give the attacker everything they need
in order to circumvent
your organization's security appliances and defenses.
Think about it like this.
You just took the time to drop some blueprints of your home
and then document exactly
where all the valuables are in your home.
In addition to that,
you listed all the security cameras you have,
which doors are locked and which ones aren't,
which windows are open and which ones aren't,
all that kind of stuff.
Now as you're going to work,
you accidentally drop that blueprint on the street,
and I picked it up.
Well, guess what?
Now I know exactly how to break into your house
and where all the valuables are located, right?
Well, the same holds true with our vulnerability reports.
After you conduct your vulnerability scans,
the report is going to be generated,
and it's going to contain a list of every vulnerability
in your networks,
as well as every misconfiguration it finds.
In the hands of a threat actor, this is a map
that will tell them exactly how to break into your networks
and wreak havoc all across your systems.
So when it comes to the confidentiality of your reports,
you always want to make sure
those reports are being encrypted,
and you should use secure storage spaces online
if you're going to give access to other people
instead of just emailing it around.
For example, I could create the report, encrypt it,
and then upload it to a password-protected portion
of our internal SharePoint or document repository,
and then I can send that link by email
to the people who need a copy of that report
instead of emailing them the PDF of the report directly.
This helps to ensure we have securely controlled access
to the report instead of people forwarding that email
internally or externally of our organization.
Additionally, you also want to ensure that your report
is only provided to those who have a need-to-know basis.
Again, this is another reason why you want to put it
on an internal SharePoint portal
or other document repository
that has access control rights.
For example, an accountant who works at your organization
probably doesn't need to see the detailed report
of all your vulnerabilities, but your system administrators,
they probably do
because they're going to be patching those vulnerabilities,
so they need to know they exist.
On the other hand, your executives do have a vested interest
and a need-to-know
about the security posture of your network,
but they probably don't need
the fully detailed 300-page report
of every vulnerability that exists in your network
because they're not a system administrator
and they're not going to be going line by line
through the report to patch and mitigate them.
Instead, these executives would rather have
a three to five-page executive summary
of your organization's vulnerabilities
that contains much less details
and can be shared to a slightly larger audience
while still being much easier for them to understand
because it relies on summarized information and graphs
to highlight your organization's current security posture.
Now, it is very important that your reporting
remains confidential, otherwise,
exploitation, reputational damage
and even legal repercussions
could occur for your organization.
After all, a malicious actor could use the report
to exploit your disclosed vulnerabilities
before they're patched by your system administrators,
so we want to make sure we keep those unknown.
If your vulnerability report gets posted on social media,
for example, this would actually damage your reputation
and have the public lose confidence
in your organization's ability
to securely protect its customers' data.
Finally, if that report does get out,
you may be subject to legal repercussions
due to your existing contracts, industry regulations,
or simply being sued by one of your customers
if their data is getting exposed
due to your negligence release of that vulnerability report,
especially if you're working as an external auditor
or a cybersecurity consultant for that customer.
So remember, vulnerability reporting is the last step,
but a really important step inside
of the organization's vulnerability management program.
Vulnerability reporting is the process of documenting
and communicating details about security weaknesses
identified in software systems
to the individuals or organizations responsible
for addressing the issue
to ensure that these vulnerabilities
are managed discreetly and effectively
to prevent exploitation.
This vulnerability reporting
can be performed internally or externally,
as well as part of a Responsible Disclosure Program.
Either way, though,
your vulnerability reports must be kept encrypted
to maintain their confidentiality,
and they should only be shared with other people
who have a need-to-know
in terms of your organization's existing vulnerabilities
and current security posture.