Maksim Kabakou - Fotolia
The need to keep software up to date with security patches without it costing too much or being too labour-intensive is a regular discussion topic.
The usual concern is that regression and integration testing patches require significant resource to support and address any issues. This is especially prevalent where heavily customised solutions are in place because it is difficult to assess the impact of patching on functionality that may not be known to the software supplier.
In general, large organisations tend to take a risk-averse approach to patching and testing, sometimes erring so far on the side of caution that it is difficult to streamline the process.
Long patch testing periods (potentially six months) place greater pressure on organisations adopting new technology, where service-points may be released multiple times per year. (This was recently noticeable with SAP Hana, in part due to the acceleration in SAP’s overall patching schedule.)
To address this, organisations need a patching strategy that will identify the required patches in a timely fashion. Dates and days when security patches are released for applications should be known – patch on Tuesday for Microsoft, or the second Tuesday of the month for SAP, for example.
Responsibility for validating patch applicability and impact needs to be agreed, along with whether the industry standard common vulnerability scoring system (CVSS) scores are prioritised. Without such prioritisation, knowing which patches should be accelerated through a fast track can be difficult to identify.
SAP customers also need to note that SAP has recently moved away from using the system-specific RSECNOTE transaction to a more enterprise-focussed, solution-manager based toolset.
Use of a vulnerability management program, of which several are available, can help to document an organisation’s current patch levels and quickly identify the patching that is required. In addition, more enterprises are subscribing to cyber threat intelligence services to share details of vulnerabilities and whether they have been exploited. Distributing this information among industry sectors that share common applications allows early identification of risk, and the necessary remediation, to be identified.
Read more from Computer Weekly's Security Think Tank about patching strategies
To streamline patching, large organisations often prioritise security patches using a “fast-track” approach. This requires a set level of integration testing, backed up by in-depth analysis of likely impact, but is less intensive than a full support pack upgrade.
By placing these security-critical patches into their own enterprise track, which can be independent of wider functional patching, or service-level upgrades, it is possible to reduce the level of testing required. However, it is necessary to strike the right balance; while this method is more targeted (and therefore requires less resource and investment), without a full upgrade, there will be limitations to the testing that can be undertaken.
Mature organisations are implementing tools that can automate many of the test elements, replicating what a team of people may take hours to complete in a far shorter time. However, these require that processes are fully understood, as well as an investment of time and effort to get these tools up and running with replicable tests.
Decisions around whether to commit to this investment will depend on the expected return. Newer applications are likely to have more patches released, in conjunction with documented processes, which may automate well. Testing and automation is easier at the early stage of the application process, rather than when working with legacy systems.
Finally, increased use of cloud-based IT service provision and outsourcing, which can be adopted as off-the-shelf tools, make patching someone else’s problem.
The key caveat is that contractual protections and a way to validate that the supplier is meeting those obligations are in place. ..... .. . . . . . ...