Patch me if you can: the six steps of vulnerability management

This is the second post in a three-part series on vulnerability management. In this post, elevenM’s Theo Schreuder describes the six steps of a vulnerability management program.

In the first post of this series, we explored why vulnerability management is important and looked at key considerations for setting up a vulnerability management program for success. In this post, we’ll step you through the six steps of vulnerability management.


The six steps of vulnerability management

The six steps of vulnerability management [Source: CDC]

Let’s explore each step in more detail.

  1. Discover vulnerabilities

The most efficient way to discover vulnerabilities is to use a centralised and dedicated tool (for example, Rapid7 InsightVM, Tenable, Qualys) that regularly scans assets (devices, servers, internet connected things) for published vulnerabilities. Information about published vulnerabilities can be obtained from official sources such as the US-based National Vulnerability Database (NVD), via alerts from your Security Operations Centre (SOC) or from external advisories.

Running scans on a regular basis ensures you have continuous visibility of vulnerabilities in your network.

 

2. Prioritise assets

Prioritising assets allows you to determine which remediation actions to focus on first to reduce the greatest amount of risk within the shortest time and with least budget.

Prioritisation of assets relies on having a well-maintained asset inventory (e.g. a Central Management Database or CMDB) and a list of the critical “crown jewel” assets and applications from a business point of view (for example, payroll systems are typically considered critical assets). Another factor to consider in determining prioritisation is the exposure of an asset to the perimeter of the network, and how many “hops” the asset is from an internet-facing device.

 

3. Assess vulnerability severity

After devices are scanned, discovered vulnerabilities are usually be assigned a severity score based on industry standards such as the Common Vulnerability Scoring System (CVSS) as well as custom calculations that — depending on the scanning tool — take into account factors including the ease of exploitability and the number of known exploit kits and plug-and-play malware kits available to exploit that vulnerability. This step can also involve verifying that the discovered vulnerability is not a false positive, and does in fact exist on the asset.

 

4. Reporting

When creating reports on vulnerability risk, it’s important to consider different levels of reporting to suit the needs of different audiences. Your reporting levels could include:

  1. Executive level reporting
    This level of reporting focuses on grand totals of discovered vulnerabilities and vulnerable assets, total critical vulnerabilities, and historical trends over time. The aim is to provide senior executives with a straightforward view of vulnerabilities in the network and trends.
  2. Management level reporting
    For individual managers and teams to manage their remediation work, it helps to provide them with a lower-level summary of only the assets they are responsible for. This report will have more detail than an executive level report, and should provide the ability to drill down and identify the most vulnerable assets and critical vulnerabilities where remediation work should begin.
  3. Support team level reporting
    This is the highest resolution report, providing detail for each vulnerability finding on each asset that a support team is responsible for. Depending on the organisation and the way patching responsibilities are divided, splitting out reporting between operating systems (below base) and application level (above base) can also be advantageous as remediation processes for these levels can differ.
A sample management-level vulnerability report generated using Tableau

 

5. Remediate vulnerabilities

“The easiest way to get rid of all of your vulnerabilities is to simply turn off all of your devices!”

– origin unknown

Remediation can take a variety of forms including but not limited to changing configuration files, applying a suggested patch from the scanning tool or even uninstalling the vulnerable program entirely.

There may be also be legitimate cases where a vulnerability may be exempted from remediation. Factors could include:

  • Is the asset soon to be decommissioned or nearing end-of-life?
  • Is it prohibitively expensive to upgrade to the newest secure version of the software?
  • Are there other mitigating controls in place (e.g. air-gapping, firewall rules)
  • Will the required work impact revenue by reducing service availability?

 

6. Verify remediation

Are we done yet? Not quite.

It doesn’t help if — after your support teams have done all this wonderful work — your vulnerability scanning tool is still reporting that the asset is vulnerable. Therefore, it is very important that once remediation work is complete you verify that the vulnerability is no longer being detected.

Stay tuned for the third and final post in the series, in which we discuss common challenges and considerations for a well-functioning vulnerability management program.


Read all posts in the series:
Patch me if you can: the importance of vulnerability management
Patch me if you can: the six steps of vulnerability management
Patch me if you can: key challenges and considerations

 

Standards – huhh! – what are they good for?

elevenM’s Cassie Findlay looks at getting the most out of standards. Cassie is a current member of the Standards Australia Committee on Records Management and a former member of the International Organization for Standardization (ISO) Technical Committee on Records Management. She was lead author of the current edition of the International Standard on records management, ISO 15489. 

“Standards are like toothbrushes. Everyone thinks they’re a good idea, but no one wants to use someone else’s.”

(origin unknown) 

Why pay attention to standards, national or international? Aren’t they just for making sure train tracks in different states are the same gauge? What do they have to do with managing and securing information or with privacy? Do we need standards? 

The value of standards for manufacturing or product safety is clear and easy to grasp.  

However for areas like privacy, recordkeeping and information security, with all their contingencies, the question arises as to how we can standardise when so often the answer to questions about what to do is ‘it depends’. 

The answer lies in what you seek to standardise, and indeed what type of standards products you set out to create. 

Of the domains elevenM works in, it could be argued that cyber security and information security have the clearest use cases for standardisation. The ISO 27001 set of standards have a huge profile and wide uptake, and have become embedded in contracts and requirements for doing business internationally. By meeting the requirements for a robust information security management system (ISMS) organisations can signal the readiness of their security capability to the market and to business partners. However this is a domain in which standards have proliferated, particular in cyber security. This was a driver for the work of the NSW Government-sponsored Cyber Security Standards Harmonisation Taskforce, led by AustCyber and Standards Australia, which recently released a report containing a range of recommendations for cyber security standards harmonisation and simplification. 

In the world of information management, specifically recordkeeping, strong work has been underway over the last couple of decades to codify and standardise approaches to building recordkeeping systems, tools and processes, in the form of the International Standard ISO 15489 Records Management and its predecessors. In the case of this standard, the recordkeeping profession is not seeking to establish a minimum set of compliance requirements, but rather to describe the optimal approach to building and maintaining key recordkeeping controls and processes, including the work of determining what records to make and keep, and ensuring that recordkeeping is a business enabler – whatever your business. The standard takes a ‘digital first’ approach and supports the work of building good recordkeeping frameworks regardless of format. Complementary to ISO 15489, the ISO 30300 Management systems for records suite offers compliance-focused standards that enable organisations to establish and maintain management systems that enable good recordkeeping, and that can be audited by third parties such as government regulators or independent auditors. 

In the privacy world, compliance requirements come, in most jurisdictions, directly from applicable laws (GDPR, Australia’s Privacy Act), and practitioners typically focus on these as opposed to seeking out standards. The United States has a patchwork of regulatory requirements affecting privacy, but has seen widespread adoption of the California Consumer Privacy Act (CCPA) for consumer privacy, with other States following suit with similar laws. The US National Standards body, NIST, does however, have a strong track record in standards development for security and now for privacy, in the form of its Cybersecurity Framework, and more recently, its Privacy Framework. However it is important to note that these are not standards, but are voluntary tools issued by NIST to help organisations to manage privacy risk. 

The next time your organisation is looking to align a standard, be sure to understand why, and whether:  

  • meeting the standard helps you establish bonafides to the market, such as via the adoption of the ISO 27001 standards;  
  • independent auditors and other third parties have signalled they will use the standard to guide their audits, such as the ISO 30300 suite;  
  • the standard provides your organisation with a useful tool or framework towards best practice, as found in the foundational standard for recordkeeping, ISO 15489; or 
  • whether regulatory or compliance requirements exist that supersede any standard – and are prescriptive on their own (for example through the Privacy Act and guidance from the OAIC). 

The toothbrush gag is one heard often in standards development circles such as ISO Committees, and it perhaps has a limited audience, but the point it makes is a good one in that standards are – and should be – tailored to users and uses. They do not, however, tackle plaque.  


Photo by Call Me Fred on Unsplash

Patch me if you can: the importance of vulnerability management

This is the first post in a three-part series on vulnerability management. In this post, elevenM’s Theo Schreuder explains why vulnerability management is so important and outlines some key considerations when establishing a vulnerability management program.

In 2017 the American credit bureau Equifax suffered a breach of its corporate servers leading to customer data being leaked from its credit monitoring databases. The fallout from the breach included the exposure of the personal information of almost 150 million Americans, resignation of the company CEO and a reputation battering that included a scathing report by the US Senate.

The breach occurred due to attackers exploiting a vulnerability in the Apache Struts website framework — a vulnerability that was unpatched for over two months despite a fix being known and available.

With a proper vulnerability management program in place Equifax could have prioritised remediation of the Apache Struts security patch and prevented huge impact on consumers, to its reputation, and saved US$575 million in eventual legal settlement costs.

It’s little wonder that vulnerability management features heavily in well-respected cyber security frameworks and strategies, such as the NIST Cybersecurity Framework and the Australian Government’s Essential Eight. Equifax has also come to the party, putting a program in place: “Since then, Equifax said that it’s implemented a new management system to handle vulnerability updates and to verify that the patch has been issued.”

So what is “vulnerability management”?

Vulnerability management is the end-to-to end process from the identification of vulnerabilities in your network to the verification that they have been remediated.

The first priority in vulnerability management is to scan the network. And by the network we mean everything. Servers, routers, laptops, even that weird voice-controlled air-conditioning system you have in your offices. Having visibility of unpatched vulnerabilities in your network allows you to prioritise patching and prevent potential breaches.

In subsequent posts in this series, we’ll step through the key elements that comprise the vulnerability management process and discuss some key challenges and considerations for a well-functioning program.

For now, here are two key consideration when starting to think about establishing a vulnerability management program:

Firstly, it is important to be clear and transparent about the true state of risk in your environment as nothing will get done if the risk is not pointed out. Even if a vulnerability is “risk accepted”, it needs to be continuously logged and monitored so that if a breach occurs you know where to look. Visibility of where the greatest vulnerabilities lie encourages action. It’s easy to fall into an “out of sight, out of mind” approach when you are not getting clear and regular reporting.

Secondly, In order to get this regular reporting, it is advantageous to automate as much as possible. This reduces the effort required to create reports on a regular basis, freeing up resources to actually investigate and analyse vulnerability data.

Stay tuned for the next post in the series.


Read all posts in the series:
Patch me if you can: the importance of vulnerability management
Patch me if you can: the six steps of vulnerability management
Patch me if you can: key challenges and considerations

The five trends driving ransomware tactics

Ransomware attacks continued to increase in 2020, and 2021 looks set to follow the trend. Unfortunately, the past 12 months has seen substantial evolution in ransomware tactics, as attackers look to improve their results.

In this post we look at 5 key ways this critical cyber threat is evolving.

Is supplier risk management useless?

 

So here we are again. Another supply chain attack which has led to the compromise of highly sensitive computer networks. Is this the point we draw a line under supplier risk management, put hands up and say ‘too hard’? Alex Stamos, Adjunct professor at Stanford University’s Center for International Security and Cooperation and former chief security officer (CSO) at Facebook seems to think so. In a tweet following the SolarWinds compromise he said,

“Vendor risk management is an invisible, incredibly expensive and mostly useless process as executed by most companies. When decent, it happens too late in procurement.”

For those of you who follow our blogs, you will know that this is a subject we also have strong views on. It is our view that supply chain risk is something companies cannot solve on their own. We were therefore delighted to see statements in the 2020 Australian Cyber Security Strategy that help is on its way:

“The Australian Government will establish a Cyber Security Best Practice Regulation Task Force to work with businesses and international partners to consider options for better protecting customers by ensuring cyber security is built into digital products, services and supply chains.”

What this Task Force looks like outside of the conceptual, we will need to wait and see. Given recent events however, we at elevenM hope whatever the action is, that it gets delivered sooner rather than later.