Security leaders working on security sustainment programs should set three goals for their team:
- Implement controls that make it easy for development teams to consistently deliver high-quality outputs.
- Implement controls that test for the existence of known negative outcomes.
- Implement controls that prevent known negative outcomes.
VULNERABILITY MANAGEMENT programs are crucial for maintaining the security of your company. These programs involve various methods to track and address vulnerabilities associated with outdated and misconfigured systems. In less mature organizations, vulnerability management can be challenging. Some perceive patching as insignificant work, while others rely too heavily on automated vulnerability scanners, leading to complacency. However, obtaining funding for a vulnerability management program is just the beginning. Executing vulnerability management effectively is crucial to protecting customer data and maintaining trust, as regulatory fines can deplete resources.
To emphasize the importance of vulnerability management, it is essential to present a use case that demonstrates the consequences of neglecting vulnerabilities. You have to arm your audience with examples of failures that are relevant to your audience. The use case should also highlight the implications of an inadequate vulnerability management program. Although it may not be an exciting issue to address, it is necessary to help people understand the dangers of complacency. This is not a fun problem to tackle, Sisyphus. Vulnerability Management is never finished. You must help people understand the danger of complacency.
Why do we need vulnerability management?
Think of Vulnerability Management as regular car maintenance. Similar to checking the car’s oil, inspecting the brakes, and replacing worn-out tires to ensure optimal performance and safety, continuously measuring vulnerabilities in your enterprise environment is essential. You must also measure the mean time to resolution and aim to keep it within acceptable limits.
Software vulnerabilities exist, even before they are assigned CVE numbers and become widely known. Humans make mistakes that can be exploited. A simple way to view software vulnerabilities is as indicators of software quality. If you want to increase the chances of delivering high-quality work, you need to test for the existence of defects. Skilled tradespeople know where mistakes are likely to occur in projects and test for their presence.
How can you pitch a vulnerability management program?
Part of the challenge of launching a vulnerability management program is you need anecdotes that persuade funding sources of the importance of this boring & tedious activity. It is common for developers and managers to underestimate security impacts. You need a realistic use case that helps shortcut bad-faith discussions from parties whose execution demands improvement. So here is an example to build your argument for your quantifiable vulnerability management reporting program.
Don’t be like Equifax: Why you need a measurable, sustaining Vulnerability Management program with monthly reporting
The Federal Trade Commission Act (FTCA): The Federal Trade Commission (FTC) has the authority to bring enforcement actions against companies that engage in “unfair or deceptive acts or practices.” This authority has been used in the past to penalize companies that fail to adequately protect consumer data.
In 2017, https://en.wikipedia.org/wiki/2017_Equifax_data_breach. “Private records of 147.9 million Americans along with 15.2 million British citizens and about 19,000 Canadian citizens were compromised in the breach, making it one of the largest cyber crimes related to identity theft.”
“The total cost of the settlement included $300 million to a fund for victim compensation, $175 million to the states and territories in the agreement, and $100 million to the CFPB in fines”
Understanding the Equifax Breach
https://www.ftc.gov/legal-library/browse/cases-proceedings/172-3203-equifax-inc
- https://www.ftc.gov/system/files/documents/cases/172_3203_equifax_complaint_7-22-19.pdf
- March 8, 2017, (“US-CERT”) alerted Equifax to a new critical security vulnerability (referred to as 2017-CVE-5638) found in Apache Struts
- Security team received the US-CERT alert and, on or about March 9, 2017, disseminated the alert internally by a mass email to more than 400 employees. The mass email directed employees, “if [they were] responsible for an Apache Struts installation,” to patch the vulnerability within 48 hours
- The ACIS Dispute Portal contained a vulnerable version of Apache Struts. However, Equifax failed to apply the patch to the ACIS Dispute Portal for months. Although Equifax’s security team issued an order to patch all vulnerable systems within 48 hours, Equifax failed to send the email ordering a patch to the employee responsible for maintaining the ACIS Dispute Portal.
- On or about March 15, 2017, Equifax performed an automated vulnerability scan intended to search for vulnerable instances of Apache Struts that remained on Equifax’s network. But Equifax used a scanner that was not configured to correctly search all of Equifax’s potentially vulnerable assets. As a result, the automated scanner did not identify any systems vulnerable to 2017-CVE- 5638 and the ACIS Dispute Portal remained unpatched.
- On or about July 29, 2017, Equifax’s security team identified some suspicious traffic on the ACIS Dispute Portal after replacing expired security certificates.
- Equifax retained a forensic consultant who ultimately determined that between May 13, 2017 and July 30, 2017, multiple attackers were each able to separately exploit the 2017-CVE-5638 vulnerability in the ACIS Dispute Portal to gain unauthorized access to Equifax’s network. Once inside, the attackers were able to crawl through dozens of unrelated databases containing information that went well beyond the ACIS Dispute Portal, in part because of a lack of network segmentation. The attackers also accessed an unsecured file share (or common storage space) connected to the ACIS databases where they discovered numerous administrative credentials, stored in plain text, that they used to obtain further access to Equifax’s network.
- According to Equifax’s forensic analysis, the attackers were able to steal approximately 147 million names and dates of birth, 145.5 million SSNs, 99 million physical addresses, 20.3 million telephone numbers, 17.6 million email addresses and 209,000 payment card numbers and expiration dates, among other things.
Social Engineering your Corporate Colleagues to Embrace Vulnerability Management
When pitching the vulnerability management program, make it clear that it aims to protect the reputation of the person opposing your pitch. By avoiding predictable and repeatable situations like the Equifax breach, you help these individuals build sustainable and successful careers. Encourage a collaborative approach rather than adversarial thinking. You want to ensure that their name and reputation is not associated with unforgiving headlines like this:
We all know people who worked at these companies during times of strife. Their network will wonder if they were the person responsible. It is in their best interest to avoid a predictable, repeatable situation where they are associated with this level of headline news coverage.
Deliver vulnerability reports based on leaders and encourage healthy competition among them. Ensure that every leader sees their peers’ summary vulnerability reports, enabling them to assess their position within the organization. Are they in the top or bottom half in terms of performance? At the end of the year, provide team awards for the teams with the shortest mean time to detection and resolution, and highlight teams with the lowest total count of critical vulnerabilities as exemplary.
Tips for pitching your Vuln Management Program
- Implement tests to discover when a system is no longer getting scanned.
- Implement tests to discover new systems that have never been scanned.
- Implement tests to discover scanner misconfigurations that positively fail to discover relevant & new vulnerabilities.
- Implement tests to discover a scanner that’s stopped firing.
- Vuln Management programs should be assumed to be failing. Test for failures. Report on them. Implement mechanisms to systematically eliminate failures.
- Loudly & clearly communicate that following concept: The existence of a vulnerability management does not mean your business is secure. Vuln Management is a cost of a sustainable, long term business. Complacent companies get burned. If you fail to maintain a high quality Vulnerability Management program, your business’s “Check Engine” light will go off at the worst possible moment.
- Watching firewall logs is a good intention. You are not going to be the next equifax. You implement mechanisms for discovering vulnerability management non-compliance. You test your mechanisms for discovery gaps.
- You can have 100% of your vulnerabilities patched within your SLAs and still experience catastrophic breaches & ransomware events.
Your Vulnerability Management Program should measure KPIs
Here are some example KPI’s to consider (from https://www.cisoplatform.com/profiles/blogs/top-10-metrics-for-your-vulnerability-management-program):
- Mean Time to Detect
- Mean Time to Resolve
- Average Window of Exposure
- Scanner Coverage
- Scan Frequency by Asset Group
- Number of Open Critical / High Vulnerabilities
- Average Risk by BU / Asset Group etc.
- Number of Exceptions Granted
- Vulnerability Reopen Rate
- % of Systems with no open High / Critical Vulnerability
Additionally- note that NIST has some recommendations around vulnerability management reporting: https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-55r1.pdf
What’s your take? What else should be being measured & reported?