Vulnerability identification and remediation are critical to maintaining a secure environment. Today, most organizations are using one or multiple vulnerability scanning tools to identify vulnerabilities on endpoints such as business critical servers, laptops and desktops. They also have processes in place to apply security patches (provided by platform or application software vendors) to remediate vulnerabilities quickly. However, many security teams remain concerned that their IT infrastructures may still be vulnerable to attacks from newly emerging malware or exploitation vectors (e.g., WannaCry, Petya/NotPetya and Apache Struts), simply because some machines contain vulnerabilities that have not been identified or patched and could be manipulated by these threats.
So, what is missing in the current vulnerability identification and patching processes and tools? We carefully analyzed vulnerability and patch management processes and interacted with multiple customer teams involved in these areas to learn more. We discovered that insufficient patch posture reporting, a lack of data, and operational inefficiency in these processes and tools actually cause great challenges with the various teams. We also found that these challenges are why many organizations still cannot establish a high degree of confidence in protecting their IT infrastructure and valuable business assets using their current vulnerability identification and remediation capabilities.
Here are some of our key findings:
Aggregate Patch/Vulnerability Posture Data Is Lacking
Typically, security teams perform vulnerability scanning periodically and report current security posture, mainly from a vulnerability discovery perspective. IT operations/infrastructure teams are then responsible for applying security patches to all business-critical machines to address the identified vulnerabilities. Unfortunately, there is usually no data available to give a comprehensive and cumulative view of all the patching actions that have been performed over time and how the vulnerabilities have been remediated by these applied patches. Customers have told IBM that without visibility to a complete and timely patch posture of the entire IT infrastructure with a focus on vulnerability remediation, it is difficult to assess the overall risk level of an organization and the effectiveness of the patching activities.
Vulnerability Remediation Is Not Prioritized
IBM frequently hears that IT operations teams do not have access to the vulnerability data produced by security teams. And even if they do have access, there is no data readily available to link the discovered vulnerabilities with the required security patches to be applied. As a result of this data gap and lack of integration between the tools used by the two teams, when the IT operations teams apply security patches, they have no idea of exactly what vulnerabilities are being remediated and thus how the patching is going to impact the overall security posture.
In today’s IT environments, there is a large number of machines and there are always many patches to apply across the entire software stack on each machine (e.g., virtual machines, operating system, middleware, applications, etc.). It is becoming increasingly important for IT security and operations teams to work together to prioritize remediation efforts to address the biggest vulnerabilities first (the vulnerabilities that could cause the greatest damages), thereby optimizing their remediation impact. This will also help raise the organization’s overall security posture in a timely manner and help reduce costs.
Demonstrating Compliance Is Difficult
Many regulations and corporate security policies require high severity security patches to be applied within a relatively short time period. The Payment Card Industry Data Security Standard (PCI DSS), for example, , requires installing applicable, critical security patches within one month of release. However, it is usually a manual, time-consuming process for compliance teams to collect all the needed information such as when a security patch was released; when it was applied to each applicable machine; and whether all the machines have had the patch applied. Compliance teams have told IBM that they need this data to be collected and reported in a more automatic way to more effectively demonstrate compliance during regulatory or corporate policy audits.
Things to Look for in Patch Posture Reporting
To address these challenges, look for solutions that offer patch posture reporting as either a standalone tool or a capability that is incorporated within an existing solution focused on vulnerability management, patch management and/or compliance. The primary goal of patch posture reporting should be to empower the IT security and operations teams to better meet their vulnerability identification, patch management and compliance responsibilities by providing the ability for:
- Security or IT operations managers to get the current status and historical trend of all patches applicable to all machines, so they can get a complete risk posture or assess patch effort efficiency at any time;
- IT operations specialists to sort/filter all applicable patches based on severity and/or current remediation status to prioritize patching actions, so they can maximize their impact to security posture improvement; and
- Compliance specialists to track and report when security patches are released and applied to each machine, so they can more effectively demonstrate compliance with regulatory/organizational policies.
Let’s look more closely at some of the specific functions that should be provided by a patch posture reporting tool.
Comprehensive Patch Posture Assessment
Patch posture reporting should help IT operations managers assess patching effort efficiency and security operations center (SOC) managers assess how related vulnerabilities have been remediated by patching. The posture data needs to be made available in near real time to provide a current and comprehensive picture. Specific types of data to be reported should include:
- For each patch, all the machines that have been remediated, the remediation percentage (among all the applicable machines) and how the data has changed over time (a historical trend); and
- For each machine, all the patches that have been applied, the remediation percentage (among all the applicable patches) and how the data has changed over time (a historical trend).
To provide benefits to various teams with different responsibilities, the posture data should also be presented in multiple views including:
- Per-machine views showing all the patches applicable to each machine;
- Per-machine group views (e.g., all the machines running Windows) showing all the patches applicable to a group of similar machines;
- Per-patch views showing all the machines applicable by a particular patch; and
- Aggregated posture views showing all the patches across all the machines.
With this type of comprehensive patch posture data, it would be fast and easy for security or IT operations managers to answer frequently asked questions, such as:
- What machines do not have a particular patch applied yet (e.g., for a critical security patch that can fix vulnerabilities exploited by malware as bad as WannaCry)?
- What is the current remediation status of all the patches applicable to a business-critical server?
- What are the top 10 machines that have the greatest number of patches yet to be applied?
Remediation Task Prioritization
In addition to a complete patch posture, look for tools that provide data filtering and sorting functions to help IT operations specialists efficiently determine their next remediation priority. Data that can be filtered or sorted should include:
- The severity of a patch (a patch with a higher severity usually needs to be applied first);
- When the patch was released (usually an older patch needs to be applied sooner, especially for compliance purposes);
- Whether a patch has been superseded (applying a newer, superseding patch may reduce the total patching effort);
- The number of machines the patch can be applied to (applying the more broadly applicable patch can have a larger impact to the overall posture); and
- The current remediation status (a lower remediation percentage may mean a higher security exposure).
Patch management usually needs to take into account additional factors, such as when the machines are available for offline maintenance (patching), and that requires coordination with machine owners. Nonetheless, a complete patch posture and efficient filtering/sorting functions can definitely enable the IT security and operations teams to make much more informed decisions on patching prioritization so they can help remediate vulnerabilities more effectively.
Patch Compliance Demonstration
As mentioned earlier, complying with a regulation or a corporate policy for security patching usually requires tracking of very tedious data, because compliance specialists usually need to be able to answer the following questions during an audit:
- When was a patch released by the vendor?
- When was it applied to each applicable machine?
- Did the elapsed time (between release and applying) exceed the regulation/policy requirement?
Consider using tools that track and store this type of data automatically (which may mean integration with patch management tools and patch action logs) and that can generate related reports that compliance specialists can leverage to pass audits. It’s also important to note that historical trend data for patching can demonstrate the progress being made by the IT security and operations team over time. In some cases, even if 100 percent compliance has not been achieved, this historical trending data may be useful in demonstrating the organization’s desire to achieve compliance (and thereby avoid potential fines or repercussions).
Patch Posture Reporting Is Key to Identifying Risks, Reducing Costs and Demonstrating Compliance
In summary, many organizations still struggle with getting full visibility of aggregated patch/vulnerability posture, prioritizing vulnerability remediation and effectively demonstrating compliance. This is primarily due to insufficient data and missing capabilities in existing vulnerability discovery or patch management solutions. Patch posture reporting addresses these gaps by delivering the functions described in this blog to the IT operations/infrastructure and security teams who need them. This, in turn, enables these teams and organizations to much more effectively identify and mitigate security risks, reduce operational costs and demonstrate policy/regulation compliance. IBM BigFix Compliance has recently been enhanced to include patch posture reporting to provide these benefits to organizations. For more information, please refer to this solution brief.
The post How Patch Posture Reporting Improves Security Landscapes appeared first on Security Intelligence.
