Augusto Morales is a Technology Lead (Threat Solutions) at Check Point Software Technologies. He is based in Dallas, Texas, and has been working in cyber security since 2006. He got his PhD/Msc in Telematics System Engineering from the Technical University of Madrid, Spain and he is also a Senior Member of the IEEE. Further, he is the author of more than 15 research papers focused on mobile services. He holds professional certifications such as CISSP and CCSP, among others.

One of the burdens of CISO leadership is ensuring compliance with endpoint security measures that ultimately minimize risk to an acceptable business level. This task is complex due to the unique nature of each organization’s IT infrastructure. In regulated environments, there is added pressure to implement diligent patching practices to meet compliance standards.

As with any IT process, patch management requires planning, verification, and testing among other actions. The IT staff must methodically define how to find the right solution, based on system’s internal telemetry, processes and external requirements. A Proof of Concept (PoC) is a key element in achieving this goal. It demonstrates and verifies the feasibility and effectiveness of a particular solution.

In other words, it involves creating a prototype to show how the proposed measure addresses the specific needs. In the context of patch management, this “prototype” must provide evidence that the whole patching strategy works as expected — before it is fully implemented across the organization. The strategy must also ensure that computer resources are optimized, and software vulnerabilities are mitigated effectively.

Several cyber security vendors provide patch management, but there is no single one-size-fits-all approach, in the same way that there is for other security capabilities. This makes PoCs essential in determining the effectiveness of a patching strategy. The PoC helps in defining the effectiveness of patching strategy by 1) discovering and patching software assets 2) identifying vulnerabilities and evaluating their impact 3) generating reports for compliance and auditing.

This article aims to provide insights into developing a strategic patch management methodology by outlining criteria for PoCs.

But first, a brief overview of why I am talking about patch management…

Why patch management

Patch management is a critical process for maintaining the security of computer systems. It involves the application of functional updates and security fixes provided by software manufacturers to remedy identified vulnerabilities in their products. These vulnerabilities can be exploited by cyber criminals to infiltrate systems, steal data, or take systems hostage.

Therefore, patch management is essential to prevent attacks and protect the integrity and confidentiality of all users’ information. The data speaks for itself:

  • There are an average of 1900 new CVEs (Common Vulnerabilities and Exposures) each month.
  • 4 out of 5 cyber attacks are caused by software quality issues.
  • 50% of vulnerabilities are exploited within 3 weeks after the corresponding patch has been released.
  • On average, it takes an organization 120 days to remediate a vulnerability.

Outdated systems are easy targets for cyber attacks, as criminals can easily exploit known vulnerabilities due to extensive technical literature and even Proof-of-Concept exploits. Furthermore, successful attacks can have repercussions beyond the compromised system, affecting entire networks and even spreading to other business units, users and third parties.

Practical challenges with PoC patch management

When implementing patch management, organizations face challenges such as lack of visibility into devices, operating systems, and versions, along with difficulty in correctly identifying the level of risk associated with a given vulnerability in the specific context of the organization.
I’ll address some relevant challenges in terms of PoCs below:

1) Active monitoring: PoCs must establish criteria for quickly identifying vulnerabilities based on standardized CVEs and report those prone to easy exploitation based on up-to-date cyber intelligence.

2) Prioritization: Depending on the scope of the IT system (e.g. remote workers’ laptops or stationary PCs), the attack surface created by the vulnerability may be hard to recognize due to the complexity of internal software deployed on servers, end-user computers, and systems exposed to the internet.  Also, sometimes it is not practical to patch a wide range of applications with an equivalent sense of urgency, since it will cause bandwidth consumption spikes. And in case of errors, it will trigger alert fatigue for cyber security personnel. Therefore, other criteria is needed to identify and to quickly and correctly patch key business applications. This key detail has been overlooked by some companies in the past, with catastrophic consequences.

3) Time: To effectively apply a patch, it must be identified, verified, and checked for quality. This is why the average patch time of 120 days often extends, as organizations must balance business continuity against the risk of a cyber attack. The PoC process must have ways to collect consistent and accurate telemetry, and to apply compensation security mechanisms in case the patch process fails or cannot be completely rolled out because of software/OS incompatibility, drop in performance and conflict with existing endpoint controls (e.g. EDR/Antimalware). Examples of these compensation controls include: full or partial system isolation, process/socket termination and applying or suggesting security exclusions.

4) Vendor coordination: PoCs must ensure that software updates will not introduce new vulnerabilities. This situation has happened in the past. As an example, CVE-2021-30551 occurred in the Chrome Browser, where the fix inadvertently opened up another zero-day vulnerability (CVE-2021-30554) that was exploited in the wild.

Another similar example is Apple IOS devices with CVE-2021-1835, where this vulnerability re-introduced previously fixed vulnerabilities by allowing unauthorized user access to sensitive data, without the need for any sophisticated software interaction. In this context, a PoC process must verify the ability to enforce a defense in depth approach by, for example, applying automatic anti-exploitation controls.

Improving ROI via consolidation – The proof is in the pudding?

In the process of consolidating security solutions, security posture and patch management are under continuous analysis by internal experts. Consolidation aims to increase the return on investment (ROI).

That said, there are technical and organizational challenges that limit the implementation of a patch and vulnerability management strategy under this framework, especially for remote workers. This is because implementing different solutions on laptops, such as antimalware, EDR, and vulnerability scanners, requires additional memory and CPU resources that are not always available. The same premise applies to servers, where workloads can vary, and any unexpected increase or latency in service can cause an impact on business operations. The final challenge is software incompatibility that, together with legacy system usage, can firmly limit any consolidation efforts.

Based on the arguments above, consolidation is feasible and true after demonstrating it by the means of a comprehensive PoC. The PoC process should validate consolidation via a single software component a.k.a. endpoint agent and a single management platform. It should help cyber security practitioners to quickly answer common questions, as described below:

  • How many critical vulnerabilities exist in the environment? What’s the breakdown?
  • Which CVEs are the most common and what are their details?
  • What is the status of a specific critical CVE?
  • What’s the system performance? What/how it can be improved?
  • How does threat prevention works in tandem with other security controls? Is containment possible?
  • What happens if patching fails?

Failure in patch management can be catastrophic, even if just a small percentage fail. The PoC process must demonstrate emergency mitigation strategies in case a patch cannot be rolled out or assets are already compromised.

Managing this “mitigation” could limit the ROI, since extra incident response resources could be needed, which may involve more time, personnel and downtime. So, the PoC should demonstrate that the whole patch management will maintain a cyber-tolerance level that could be acceptable in conjunction with the internal business processes, the corresponding applicable regulations, and economic variables that keep the organization afloat.

Check Point Software Technologies offers Harmony Endpoint, a single agent that strengths patch management capabilities and hence, minimizes risks to acceptable levels. It also provides endpoint protection with advanced EPP, DLP, and XDR capabilities in a single software component, ensuring that organizations are comprehensively protected from cyber attacks while simplifying security operations and reducing both costs and effort.