Act

The “act” stage prescribes the response to the vulnerability; vulnerability remediation, or fixing identified vulnerabilities, is the immediate and final response to vulnerability. If a patch cannot be applied, other options should be considered, including mitigation controls or even accepting the risk from the vulnerability (Figure 3).

Advantio_BlogSeries_VulnManagement_03_Diagram_V1.0

Remediate

Remediation causes friction between IT operations teams and the security team very often; a winning approach should a division of roles:

  • The security team is responsible for knowing about all the vulnerabilities and for managing the measuring and tracking process;
  • The IT operations team that is responsible for fixing vulnerabilities;
  • Business units exercise ownership of the information systems and can push for faster/slower remediation.

Furthermore being very useful specific meetings in which people from security, IT operations, and business units meet and review the scan results to decide on remediation priorities: This collaborative process reduces the risk in the best way. A letter of risk by a business application owner or an executive will still need to be employed when the various sides cannot agree on a remediation schedule.

Remediation SLAs

Organizations should establish SLAs for remediation to make this more structured and verifiable. SLAs are affected by the extent of the testing that is done to make sure that the patch is appropriate.

Remediation Policy

A good policy considers both the system type and a vulnerability priority measure; moreover, it is recommended an effective policy language often slices the systems by location and it assigns target percentages.

Popular patching timelines

The common recovery times are tied to the organization's IT maturity levels. Remediation should also include emergency processes for highly critical vulnerabilities. Organizations should be prepared for “two streams” patching: emergency patching procedures should be able to patch vulnerabilities within 24-48 hours of the release date; routine patching should occur within 7-90+ days corresponding to risk-based prioritization.

Achieving maximum patching speed

Organizations have an upper limit to routine patching speed, and it is related to IT operational maturity. This limit needs to be taken into account as there is a point at which the operational risk introduced by the rapid pace of changes outweighs the benefits of security risk reduction.

Remediation flow

The remediation process typically includes these steps:

  1. Acquiring a vendor patch/researching a required configuration change
  2. Analyzing the prerequisites, system compatibility, and known issues for the fix
  3. Establishing a rollback plan for defective patches and for changes that involve a potential negative impact
  4. Testing the remediation in the lab for quality assurance testing
  5. Additional testing through limited production deployment,
  6. Scheduling an update deployment to main production systems
  7. Deploying an update to all in-scope systems
  8. Analyzing the stability and performance of the modified systems, as well as systems that depend on them.

These steps should be documented in applicable remediation policies and operational procedures, maintained by the relevant operations teams, and checked by the security team.

Mitigate

Mitigation measures are temporary solutions to be used until the vulnerability is remediated, but for some scenarios, they might end up being the only solution organization have. Generally, it is not advisable to treat the mitigation as permanent; mitigation is also is very useful because one control may address a number of vulnerability instances. Unlike remediation, the mitigation controls may be fully under the control of the security team when they involve existing security tools.

Mitigation fundamentals

One of the most common ways to mitigate vulnerabilities is to use network Intrusion Detection and Prevention Systems (IDPSs), Host-based Intrusion Prevention Systems (HIPSs), or application control tools to shield the vulnerable assets. Some vulnerabilities can affect multiple servers or devices, making the application of a mitigation measure at a network control point the preferred solution over mitigating all individual systems from an effort point of view.

Architect for threat mitigation

Organizations should consider the need for applying mitigation measures when architecting networks and systems. For example, adding technologies and capabilities, such as NIPS, NGFW, and WAFs to the overall network architecture allows the security team to use those systems for mitigation measures.

Mitigation decision framework

Many dimensions of the system in question will influence the specific choice of the mitigation controls (e.g. system’s location, the vulnerabilities, and threats affecting it, etc.). More than one control may need to be applied and that nearly all mitigation carries a residual risk.

Mitigation can often be the first line of defense, especially if it can be implemented quickly. However, mitigated vulnerabilities are not gone, and they still need to be fixed eventually.

Accept risk

Sometimes, remediation or mitigation measures for a specific vulnerability or system are not available or feasible, or the side effects are too risky to be acceptable. These occurrences constitute policy exceptions.

If the organization neither remediates nor mitigates the risk stemming from vulnerability, it is making a de facto risk acceptance decision. The decision must be properly documented and signed off on by those who are ultimately affected and at the right level of management. Exceptions should show up on reports, and their use should be logged. Some areas of VM, such as PCI DSS compliance assets, do not allow exceptions.

All exceptions must have an expiration date and It is not advisable to allow exceptions for longer than one year. VA tool should continue to report on a problem unless something is done to solve it. The most appropriate way to handle an exception is to note within the tool that the risk is being accepted by the organization; it is also advisable to indicate the name of the individual making the decision, the reason for accepting the risk and the time frame for this decision to remain valid should also be noted. A clear and explicit business risk acceptance is required for all exceptions.

Advantio_BlogCTA_VulnerabilityManagement_V1.0

 

Column Header Text Column Header Text Column Header Text

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Performing a review of the media inventories at least annually

Performing a review of the media inventories at least annually

Performing a review of the media inventories at least annually

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Discover More

Advantio_Blog_DNS_Diagram_V1 Image caption goes here. This is HTML text.

Established in 2009, Advantio offers a comprehensive portfolio of professional, managed, advisory, and security testing services. Our subject matter expertise and services focus on cybersecurity, data protection, risk, and compliance with a distinct specialization in the ‘Payment Card Industry.’ We believe that for your organization to compete and grow in a rapidly evolving environment, investing in the right partner and technology is crucial to help you focus better on your core business. Our team works tirelessly to help you achieve, maintain, and demonstrate compliance against the most demanding cybersecurity standards and regulatory frameworks on time and on budget. With a strong presence across Europe and global reach on four continents, we have become the partner of choice for many large corporates and international enterprises. Our clients span a diverse range of fintech suppliers and fintech consumers in verticals such as travel, hospitality, telecommunication, financial, healthcare, education, entertainment, government, non-profit and more.

Schedule a call with an expert