In a recent blog entry, Nancy Kramer discussed the need for “incorporating risk management into strategic planning, and decision-making at all levels” to consider the “potential impact from possible future events on the organization’s ability to achieve its objectives.” The purpose of this blog entry is to discuss with some level of details why software security patches are relevant when considering operational risks. In other words, we will attempt to answer the fundamental question as to whether security patch management remains a critical element of effective risk management.
What are security patches?
Security patches typically encompass software updates that are released to address security vulnerabilities in software. While software developers will generally attempt to produce secure code, software vulnerabilities will ineluctably make their way into released code. There are various reasons for this. Software can be very complex, and with complexity comes the potential for coding and design errors. Changes in how software is used over time can result in new vulnerabilities. Additionally, modern application development often involves re-using open-source components and the producers of applications need to pass through security updates for the open-source components that are included in the applications they developed and maintain. This is one of the reasons Oracle is very focused on contributing to the security of open-source software.
At Oracle, the Critical Patch Update (CPU) is the primary mechanism for the backport of security bug fixes for all actively-supported on-premises products. Critical Patch Updates are released on the third Tuesday of January, April, July, and October. In parallel, Oracle retains the ability to issue out-of-schedule patches or workaround instructions in case of particularly critical vulnerabilities and/or when active exploits are reported in the wild. This program is known as the Security Alert program.
Do software vulnerabilities create risk?
In the “Risk Management Essentials” blog entry, Nancy described the expected risk formula. Using this method, assessing risk is the result of combining the likelihood of an event and the potential impact if such an event was to occur.
(Source: Risk Management Essentials )
Adverse events in the context of software vulnerabilities generally result from the successful exploitation of the vulnerabilities by malicious perpetrators. It is important to keep in mind that software vulnerabilities can adversely affect both elements of the risk formula:
- Software vulnerabilities can increase the likelihood of an adverse event: for example, when the presence of software vulnerabilities allows perpetrators to bypass software security controls or enable the leakage of sensitive configuration information enabling (or greatly simplifying the ability of) perpetrators to perform attacks.
- Software vulnerabilities can increase the impact of an adverse event: for example, when the presence of software vulnerabilities allows perpetrators to gain increased privileges on the targeted system, or when the vulnerabilities enable the attacker to expand attacks to neighboring systems.
Paradoxically, while organizations generally acknowledge that software vulnerabilities create risk, organizations often struggle with justifying security patch management activities.
Difficulties with justifying security patching are generally related to operational concerns. Security patching requires scarce IT resources and personnel for the planning, testing and deployment of patches. Maintenance windows can adversely impact production and business requirements (for example, when production systems need to be temporarily brought offline).
There can also be a more emotional objection to security patching particularly for complex business applications. This is often voiced by business managers as “the application is too important.” This “emotional” objection can be somewhat considered through the lens of the risk formula: in the eye of these business managers, the risk resulting from the patching activity exceeds the potential risk of a malicious exploitation of the vulnerabilities contained in the business application. Arguably, determining the likelihood of the exploitation of a security bug is very hard (and often under-estimated). In addition, this position is reinforced when the organization has historically suffered outages or delays in the implementation of the business application, thus prompting decision makers to believe that the likelihood of something going wrong during patching is very high. It is also a natural tendency for many individuals to ignore high expected risks when the likelihood of the event is low (“Who will want to hack us? We’re not a target!”) and the possible impact is very high (“Our organization will never need to pay a $50 million ransom. We don’t need to take this risk into consideration!”).
Does security patching still matter?
In another blog entry, we discussed the distinction between “mitigation” and “remediation.”
While “a mitigation” generally provides for temporary or partial relief against the exploitability or potential impact of a software vulnerability, a “remediation” provides a complete and permanent relief against the vulnerability as a result of changes in code. Remediation of security bugs in code usually involves the application of a security patch.
We have noted that organizations very often struggle to inscribe security patching in frequent and consistent maintenance windows. When the application of a patch that provides a permanent remediation about a given vulnerability is not possible or considered too difficult or expensive, organizations are tempted to explore temporary mitigation measures. Such mitigation measures may include, for example, updating firewall policies to limit access to vulnerable ports or software components. However, the practice of relying on temporary mitigations (when patches for publicly-known vulnerabilities are available) can convey significant risks. This is because IT environments are very complex and dynamic, and it becomes very quickly impossible to properly “keep the big picture in mind” when the organization relies on an ever-increasing number of temporary mitigations. It is relatively common to find as a contributing factor to a security incident that changes in a production environment unintentionally removed previously implemented mitigations. It is poor IT governance to “apply and forget mitigations.” The timely application of security patches is the only way to provide effective remediation of security issues in software and maintain a security in depth posture across the IT environment.
There is also another dimension to the question as to whether software security patches remain relevant.
The release of a software update (patch) by a vendor (for commercial software) or a maintainer (for open-source components) typically involves the disclosure of technical information related to the vulnerability being addressed (for example, identification of the affected component). This disclosure is intended to allow organizations to make educated patching decisions, however it can also provide a “hint” to malicious perpetrators on where to find the flaw or how to successfully exploit the vulnerability. In addition, malicious actors will often reverse engineer security patches to discover how to exploit the vulnerability. The availability of exploit frameworks/tools can allow for a quick weaponization of newly released patches. Tying this back to the expected risk formula, we see that the release of a patch, by potentially informing threat actors, increases the likelihood of occurrence of the adverse event.
What about the cloud?
In the blog entry “Compliance implications of operating in the cloud vs. on-premises,” Nancy Kramer discussed how the roles of the vendors and users vary when technology is operated on-premises and in the Cloud. She also noted that there are role differences among the different classes of cloud services (for example, IaaS, SaaS).
The same distinction is relevant to security patching considerations (i.e., who is responsible for patching individual software components in the cloud). Generally, whoever deploys and maintains the software will be responsible for applying security patches. This means that on-premises customers are responsible for ensuring timely security patch application for their own-premises deployments. This also means that cloud users must apply security patches in their IaaS instances, such as within their OCI tenancies, under their control. While IaaS cloud services often provide security features to help customers control security around their deployed cloud services, customers generally remain responsible for the timely application of security updates for the software they have deployed within their instances. By contrast, the cloud service providers of SaaS services are generally on the hook for the maintenance of the technical environment used in the delivery of the SaaS services (including security patching). However, the SaaS vendor patching responsibility does not extend to the possible customizations deployed and managed by the customers.
Call to action
The timely application of software security patches is a critical element of good IT governance. It is also a required element for organizations to minimize risks. Organizations need to make sure that they have strong security patch management discipline. This means that, among other things:
- Maintenance windows need to be formally defined allowing for security patching activities to take place on a timely basis. Adequate resourcing for these activities is also required.
- An accurate inventory should be maintained and systems critical to business operations properly identified across on-premises and cloud use cases. This is particularly important to determine what needs to be patched and with what priority, and by whom.
- Security teams need to be familiar with the security advisories of key vendors so that they can accurately determine the relevance of released security updates and prioritize patching efforts. Note that in a future blog entry, we will discuss how to interpret Oracle’s security advisories to assess the relative severity of vulnerabilities at a technical level. Instructions on how to subscribe to Oracle security notifications are published on the Oracle web site.
- Accurate and realistic risk analysis should be performed when determining the right balance between temporary and partial mitigation responses and remediation activities (which may temporarily impact systems availability).