Three simple steps to improving security patching

The vulnerability scan results security departments issue to the operations teams typically contain hundreds of pages and thousands of vulnerabilities to address. It’s a massive list often containing some prioritization based on the criticality of the vulnerabilities observed; and for some more mature organizations, an assessment and opinion of the security team. Typically, operations teams care about security in the endpoints. But, their job is to guarantee uptime and user satisfaction, which often suffers when deploying patches requires reboots and application restarts. And then there’s the resource constraint issue, like the difficulty of prioritization in a world where everything seems to be urgent, the lack of visibility, questions around ownership and available time, and so on. It’s a tough ask to minimize the risk in the endpoints without a holistic, multi-departmental collaboration focused on specific risk policies and profiles.

Compliance pressure doesn’t help either, because frequently it ends up being just a check-box, and not a mechanism for improving security. Therefore, while the bare minimum is undertaken very reluctantly to satisfy the auditors, there’s still a significant amount of fire drill and distraction from the daily grind.

Perhaps this is why many IT departments only patch the top software applications such as Microsoft, Adobe and Browsers. It allows them to demonstrate that the business is compliant and that they’re satisfying the security needs of the organization. In reality however, this is a misconception -- one that leads to a reduced security posture and an unnecessarily high risk for a breach. And, it could cost millions of pounds to the business, as illustrated by the latest Ponemon Institute research on Cost of Breach.

To compensate for the lack of time and resources, IT professionals convince themselves that patching the most important applications is enough. The reality, as Flexera’s new Vulnerability Review report highlights, is that the vast majority of vulnerabilities are found in applications from vendors outside the top five or six that most IT departments are currently patching. Consequently, organizations that only patch vulnerabilities found in Microsoft, Adobe and Browsers, for instance, remain at high risk.

How should IT professionals practically address the problem? They should consider a three-pronged Vulnerability Risk Management program, which includes visibility, prioritization and automated remediation:

Visibility or risk-based assessment of patching needs

Foremost, IT departments need to understand what applications are running in the endpoints that require security mitigation -- i.e. patch or compensating control. Approaching this from a pure software inventory perspective is a mistake, because it takes time that nobody has. Instead, they should undertake a proper, risk-based assessment of the patching needs by automatically correlating the installed applications’ exact versioning data with known documented vulnerabilities that have been vetted and curated. This process will reduce false positives and let security professionals rank vulnerabilities in terms of risk to the business.

Prioritisation

Time is our most limited resource, and the bad guys are taking advantage of the situation. It’s extremely important that IT departments use a risk-scoring system that helps them move fast to remediate the highest-risk vulnerabilities first. Risk controls vary from organization to organization. But at a minimum, teams should evaluate vulnerability criticality, affected asset sensitivity and pervasiveness of the vulnerable software. With these three elements considered, IT can exercise judgement on where to concentrate efforts to achieve the most effective outcome.

Automated remediation

Some organizations are adamant about testing all the applications that get deployed to their end users. Others simply prioritize fast security roll-ups and publish every patch needed as soon as it’s released by the vendor. However, the middle ground is the most effective.

Some managed applications (i.e. those sanctioned by the organization) are more critical than others because some may run critical business processes. The most critical applications should be thoroughly tested before mass deployment. The other less critical managed applications should be patched regularly, preferably in a semi-automated way. The outlier problems can be dealt with afterwards.

IT should pay the most attention to the unmanaged applications sprawling across the organizations environment -- automatically patching them mercilessly. These applications are not sanctioned by the business and pose a great risk because they often either get ignored or bypassed for policy enforcement. Ideally, these applications should be removed from the wider IT environment and their deployment controlled by an enterprise App Store with stringent workflows for approvals. This will largely mitigate the risk they pose to the business.

10 years ago, it was easier for IT departments to manage vulnerabilities based on their criticality. There was less software installed in endpoints and there was a "perimeter." In 2018, with the amount of data generated, security incidents are affecting business viability, market competitiveness and even the life of ordinary citizens. We cannot afford to drown in noise and lose focus on what matters. Organizations should implement a thorough approach to patching to improve security -- and score an important win.

Image Credit: alexskopje / Shutterstock

Alejandro is the Director of Security Strategy for Flexera's Software Vulnerability Management portfolio. He has twenty years of consulting and business development experience in four countries, focused around enterprise software in cybersecurity, IT operations, IT service management and optimisation.