Managing security risks in an organization requires dedicated efforts across numerous departments, teams, systems, and people. One essential part of an enterprise security solution is vulnerability management and remediation.
Vulnerability management is important because you cannot fix what you do not know. To learn more about their risk profile, organizations perform vulnerability scans (or “vulnerability assessments”) annually, semiannually, or quarterly, depending on their size, industry, and other factors.
It is best practice to have outside entities perform these assessments so that testing is independent of management. In fact, many insurance, security, and certification providers mandate that businesses hire outside consultants for regular testing.
For example, one of our clients recently had a third-party vendor perform an external assessment to satisfy a cyber insurance requirement. This firm identified several systems that utilized (or could utilize) transport layer security (TLS) 1.0 and TLS 1.1 for secure communications. While this is rated as a “medium” vulnerability by most experts, it should still be resolved, especially when it involves external exposure.
In this article, I’ll discuss the basics of vulnerability management and walk through an example where I resolve a similar TLS vulnerability in my home lab environment.
What Is Vulnerability Management?
Vulnerability management is a framework that IT professionals can follow to find and remediate vulnerabilities within their organization. While this framework is often related to vulnerability scans and assessments, it can also be utilized in other domains, such as physical, environmental and policy.
A successful vulnerability management framework will include five important steps:
Scan Assets
Network tools or vulnerability management systems can scan for and identify assets.
Identify a Security Vulnerability
Specialized vulnerability scanners are used to identify risks on discovered assets.
Research Solutions
Often, known solutions can be found from the vendor who developed and built the asset.
Remediate the Vulnerability
Remediation can be as simple as updating to new version or changing a configuration file, but fixes can be as complex as designing and implementing a brand new system. No matter your size, the remediation process should be documented, tested, and then implemented.
Document the Outcome
Documentation should be organized and tied to the asset in question. This can be done via shared folders or your configuration management database. Keep in mind that you should create documentation even if you accept the risk of the vulnerability and do not remediate it.
When all these steps are complete, it’s time to scan again and continue the process.
Identifying and fixing security issues is a continuous process. Risks change daily, and bad actors are not taking a break from innovating new ways to exploit vulnerabilities. This is why many organizations outsource part, or most, of their vulnerability management to trusted partners like Vervint.
Example: How to Resolve a TLS Vulnerability
Let’s walk through this process using a real-world example.
Scan and Identify
Our first step is to assess our environment with a vulnerability scanner. A wide variety of tools can be used for vulnerability scanning and detection, and when you work with Vervint, we are product-agnostic. We want to find solutions that fit your unique business needs and environment.
Because this is just a personal example for illustrative purposes, I’m using Tenable Nessus. In this case, I scanned my home lab network, and the tool identified several vulnerabilities that should be mitigated. We are going to focus on resolving the transport layer security (TLS) 1.0 and TLS 1.1 issues below.
TLS 1.0 and 1.1 are older versions of TLS that have been deprecated, which means they have been replaced by newer versions of the technology. Instead, services and applications should utilize TLS 1.2 or 1.3. For reference, TLS 1.2 has been recommended since 2008, and it is 2022 at the time of writing this article.
Malware Is Inevitable — But Beware of IT Fatalism
Research
Now that we have identified the vulnerabilities, we need to do some research. We’ll want to answer important questions like:
- What assets are affected by this vulnerability?
- What applications or services are affected by this vulnerability?
- Are there known remediations for those applications or services?
First, let’s identify the assets that are affected by this vulnerability. From the report, I can clearly identify the affected assets.
From the report, my affected assets are 192.168.86.203 and 192.168.86.205. I can also see that the application or service is likely an email server since TCP/IP port 25 is used by the simple mail transport protocol (SMTP).
Now I can refer to my configuration management database (CMDB) to uncover more information about these assets. From my CMDB, I know that these two assets are Ubuntu servers. And since these are Ubuntu servers, the mail server is likely Postfix.
Ideally, I would simply need to update the installed version of Postfix. Unfortunately, that is not the case for this asset. But the good news is that further research on the Postfix website shows that there is a method for enabling and disabling protocols in the configuration file.
Remediate
We have concluded the research step of the vulnerability management process, and we have a remediation plan. Now we need to update the Postfix configuration file to enable TLS 1.2 and disable the deprecated protocol versions.
Because I’m working with my home lab, making these updates will be streamlined. At many organizations, however, fixes like these can require more complex procedures or even significant change management. For example, in a larger organization, it may take several iterations of change requests, change board meetings and final approvals before the remediation step can be completed.
How to Leverage Change Management for Your Business
Before getting started with the fix, I made sure to back up the configuration file I was going to work on.
The default configuration file did not specify the TLS parameters, so I need to add them. I used the following lines, which will work for my home lab, but be sure to do thorough research before implementing changes like these in your organization.
smtp_tls_mandatory_protocols=!SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols=!SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_protocols=!SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_protocols=!SSLv2, !SSLv3, !TLSv1, !TLSv1.1After updating the configuration file, the Postfix service needs to be restarted. A potential outage should be communicated and coordinated with anyone who is affected when scheduling this kind of work at your own organization.
After the restart, the vulnerability should be resolved.
Document
At this point, we can consolidate our documentation (scanning reports, reference documents, changelogs, etc.) and verify that our updates successfully eliminated the vulnerability. How? We go back to the beginning of the process and scan again to validate that our remediation plan was successful.
We have now successfully remediated this vulnerability!
Struggling to Keep Up With Your IT Security Backlog? Contact Vervint.
At Vervint, we provide IT security assessments, incident response, change management consulting, cyber security solutions, vCISO and a variety of other IT security services to our clients. If you want help, all you need to do is start a conversation with Vervint’s experts. We look forward to hearing from you!
