Have you ever been the victim, I mean, read a vulnerability report? It looks like the world is about to end with all of the red tens and lots of numbers all over the place. Technical humans trying to make sense of the information mumble things like, “I guess we have to patch” or “um, where should I focus?”
Most of these vulnerability reports don’t take the reader or business need into account. This leads to hours of frustrating work creating, explaining and understanding a report that is supposed to bring clarity to what needs to be fixed with the organization’s cybersecurity.
If you read the news, you understand why companies are concerned with uncovering and fixing their security vulnerabilities. Frequent vulnerability scans are one of the ways to mitigate these risks. They should be an integral part of any organization’s cybersecurity program. Normally, such tests generate a lot of information, this raw data can be difficult to manage (most of it even useless) if not reported and presented properly. Vulnerability scans and assessments are an important part of discovering, identifying and fixing security issues across your network, servers, applications, and other security targets.
This article will give you the tools to make your vulnerability assessment reports better meet your readers’ needs.
CVSS != Risk
Common Vulnerability Enumeration (CVE) and Common Vulnerability Scoring System (CVSS) are some of the most commonly misunderstood aspects of patching. CVSS is a nominal scale with a range of 0 (least concerning) to 10 (most concerning). It is useful, but focusing solely on CVSS will likely lead to organizations allocating resources on unnecessary things. The problem is the missing applicability context of the identified vulnerability such as what is the business importance of the asset. Besides, too much technical jargon may mask the true meaning of the vulnerabilities. It comes down to someone bridging the communication gap that exists between the world-view of the business operator and the minutely-detailed, technical world of the technologist.
So, how should you report vulnerabilities?
Vulnerability assessment should be written in a way that can be quickly absorbed by technical and non-technical personnel. The structure of the vulnerability assessment report should be such that the important elements are clear and actionable, even to the most non-technical security professionals. You shouldn’t have to be a ‘seasoned security person’ to make sense of the vulnerability report.
A good vulnerability assessment report needs the below-mentioned details.
-
Scope
The scope should list all domains, functionalities, and modules included in the assessment. Describe the scope of vulnerability assessment- networks, hosts, wireless network, application, database.
Something simple like- “A vulnerability scan was performed on public IPs…(list the IPs here)” or “A network scan was performed on the guest network (list IPs), corporate network (list IPs) was performed” should do the job.
Be sure to include a complete list of the IPs!
-
Limitations and Constraints (if any)
Due to time constraints, limited application availability and access issues, some elements may not have been included in the test. This may limit some of the findings and recommendations due to the assumptions made by the assessment team during the analysis. All these details must be included in the vulnerability assessment report.
-
Summary
Provide a glance into how the systems and applications have fared during the scan. Highlight the overall risk level to the organization based on the number of vulnerabilities discovered. It is also an overview of what major changes have been made since the last time the scan was run.
“XYZ’s external cybersecurity posture has made several improvements in the past x months…” and go on to list the material improvements made.
“The vulnerability assessment of XYZ Company’s network and applications from an external perspective revealed an average security posture. The company uses several older services that display high chances of being compromised. The network is well segmented and shows a high level of resilience to compromise from internal related threats.”
These statements give an overview of what is working for the company’s cybersecurity program and what needs to be fixed without going into any overwhelming technical details.
-
Methodology
The Methodology should summarize the reconnaissance and processes followed as part of the vulnerability assessment. Enlist the tools used to conduct the assessment. These might be custom, commercial and open-source tools as well as the approach to traversing the target.
-
Key Recommendations
This section is the heart of the vulnerability report. The key recommendations are meant to guide you in addressing the most serious issues first.
Your recommendation may say something like “Use encryption for login pages- If they do not need to be exposed, hide them!”. While this does not explain what encryption to use or how to do it, the reader will know that they must have secure login pages.
It is also helpful to include reference links for additional information.
Make sure to prioritize the recommendations.
-
Key Findings
There might be some seriously concerning things that you find during the assessment… Maybe the port structure is very permissive or they don’t have certificates for their webpages. This would be the perfect place to talk about such issues. Describe the kinds of security issues or problems that were found and also pinpoint where they were found- on what system, server or where in a particular application.
Provide screenshots, code or other images as proof.
-
Additional Findings
Several times the vulnerability scans will show a lot of other vulnerabilities and issues. These may not necessarily be a high priority on your list of things to fix. This can be something like- missing updates, internal unencrypted login page or improper permissions on a trivial machine or system. Make sure this is a prioritized list of vulnerabilities.
-
Additional Recommendations
This would be a list of recommendations to mitigate the above mentioned low priority vulnerabilities. These are issues that do not require immediate attention but should be fixed eventually.
-
Appendix
Include the referenced additional technical details from the findings here. This would include reports from Nmap and/or Nessus.
The Appendix might also include additional important information that you came across during the vulnerability assessment that doesn’t necessarily fit in any other category.
Sharing the vulnerability report
The contents of the vulnerability assessment report are highly sensitive and hence it is extremely important to share the report in a secure manner. The most secure way to send those files would be to hand-deliver in person. Unfortunately, that isn’t very practical. You also don’t want to send the file as an email attachment giving additional parties access to it. So how can you safely share such files? A few ways to safely share the report would be:
- Create a password-protected file and share it via secure email. Send the password/key via a different secure medium, such as Signal.
- Have the organization own a folder on a cloud-storage service of their choice (hopefully they’ll have the right access permissions set on it). Upload the file and use the built-in file-sharing feature to send them the link to the file. Once they have downloaded the file, you can remove it.
- Share the file using apps like Signal that provide end-to-end encryption.
Summary – vulnerability report
Vulnerability assessments are an essential component of your company’s cybersecurity program. A well-written vulnerability report will make a major difference in your company’s ability to improve its cybersecurity posture.
Cybersecurity can be a lot of work. If you would like help with your cybersecurity strategy or program, give Fractional CISO a call for a complimentary consultation. We can be reached at (617) 658- 3276 or by email at [email protected].
