Headline
Resolving Availability vs. Security, a Constant Conflict in IT
Conflicting business requirements is a common problem – and you find it in every corner of an organization, including in information technology. Resolving these conflicts is a must, but it isn’t always easy – though sometimes there is a novel solution that helps. In IT management there is a constant struggle between security and operations teams. Yes, both teams ultimately want to have secure
Conflicting business requirements is a common problem – and you find it in every corner of an organization, including in information technology. Resolving these conflicts is a must, but it isn’t always easy – though sometimes there is a novel solution that helps.
In IT management there is a constant struggle between security and operations teams. Yes, both teams ultimately want to have secure systems that are harder to breach. However, security can come at the expense of availability – and vice versa. In this article, we’ll look at the availability vs. security conflict, and a solution that helps to resolve that conflict.
****Ops team focus on availability… security teams lock down****
Operations teams will always have stability, and therefore availability, as a top priority. Yes, ops teams will make security a priority too but only as far as it touches on either stability or availability, never as an absolute goal.
It plays out in the “five nines” uptime goal that sets an incredibly high requirement – that a system is running and available to serve requests 99.999% of the time. It’s a commendable goal that keeps stakeholders happy. Tools like high availability help here by providing system or service level redundancies, but security goals can quickly get in the way of achieving "five nines".
For security teams, the ultimate goal is to have systems as locked down as possible, reducing the attack surface and overall risk levels to the absolute minimum. In practice, security teams can make a demand that a system must go down for patching right now and not two weeks from now, reducing availability in order to patch immediately – never mind what the consequences are for users.
It’s easy to see that this approach would create a huge headache for ops teams. Worse, where high availability really helped ops teams to achieve their availability and stability goals it can in fact make matters worse for security teams who now must take care of an exponentially increased number of servers, or services, all of which require protecting and monitoring.
****Which best practice to follow?****
It creates a conflict between operations and security which means that the two groups are quickly at odds on topics like best practices and processes. When thinking about patching, a maintenance window-based patching policy will cause less disruption and increase availability because there is a delay of multiple weeks between the patching efforts and associated downtime.
But there’s a catch: maintenance windows do not patch fast enough to properly defend against emerging threats because these threats are often actively exploited within minutes of disclosure (or even before disclosure, e.g. Log4j).
The problem occurs across all types of workloads and it doesn’t really matter whether you’re using the latest DevOps, DevSecOps, or whatever-ops approach as the flavor of the day. Ultimately, you either patch faster for secure operations at the expense of availability or performance, or patch more slowly and take unacceptable risks with security.
****It quickly gets really complicated****
Deciding how fast to patch is just the start. Sometimes, patching isn’t simple. You could, for example, be dealing with vulnerabilities at the programming language level – which in turn impact applications are written in that language, for example, CVE-2022-31626, a PHP vulnerability.
When this happens, there is another group that participates in the availability vs. security conflict: the developers that need to deal with a language-level vulnerability in two steps. First, by updating the language version in question, which is the easy part.
But updating a language version brings not just security improvements; it also brings other fundamental changes. That’s why developers need to go through a second step: compensating for the language-level changes brought by rewriting application code.
That also means retesting and even re-certification in some cases. Just like ops teams that want to avoid restart-related downtime, developers really want to avoid extensive code edits for as long as possible because it implies major work that, yes, ensures tighter security – but otherwise leaves developers with nothing to show for their time.
****The process breaks down****
You can easily see why current patch management processes cause a multi-layered conflict between teams. A top-to-bottom policy can deal with the problem to some extent, but it usually means that nobody is really happy with the outcome.
Worse, these policies can often compromise security by leaving systems unpatched for too long. Patching systems on weekly or monthly intervals thinking that the risk is an acceptable will, at the current threat level, lead to a sobering reality check sooner or later.
There is one route to significantly mitigate – or even resolve the conflict between immediate patching (and disruption) and delayed patching (and security holes). The answer lies in disruption-free and frictionless patching, at every level or at least as many levels as it is practical.
****Frictionless patching can resolve the conflict****
Live patching is the frictionless patching tool your security team should be looking out for. Thanks to live patching you patch much faster than regular maintenance windows could ever hope to achieve, and never need to restart services to apply updates. Fast and secure patching, alongside little to no downtime. A simple, effective way to resolve the conflict between availability and security.
At TuxCare we provide comprehensive live patching for critical Linux system components, and patches for multiple programming languages and programming language versions that focus on security issues and introduce no language-level changes that would otherwise force code refactoring - your code will continue to run as-is, only securely. Even if your business relies on unsupported applications, you won’t have to worry about vulnerabilities trickling into your systems through a programming language flaw – and you don’t need to update the application code either.
So to wrap up, in the availability vs. security conflict, live patching is the one tool that can significantly reduce the tension between operations and security teams.
Found this article interesting? Follow THN on Facebook, Twitter and LinkedIn to read more exclusive content we post.
Related news
Vulnerability in the Oracle Demantra Demand Management product of Oracle Supply Chain (component: E-Business Collections). Supported versions that are affected are 12.1 and 12.2. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Demantra Demand Management. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Demantra Demand Management accessible data. CVSS 3.1 Base Score 7.5 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N).
Gentoo Linux Security Advisory 202209-20 - Multiple vulnerabilities have been discovered in PHP, the worst of which could result in local root privilege escalation. Versions less than 7.4.30:7.4 are affected.
Red Hat Security Advisory 2022-5904-01 - PHP is an HTML-embedded scripting language commonly used with the Apache HTTP Server. Issues addressed include a buffer overflow vulnerability.
An update for php is now available for Red Hat Enterprise Linux 9. Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.This content is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). If you distribute this content, or a modified version of it, you must provide attribution to Red Hat Inc. and provide a link to the original. Related CVEs: * CVE-2022-31626: php: password of excessive length triggers buffer overflow leading to RCE
Ubuntu Security Notice 5479-3 - USN-5479-1 fixed vulnerabilities in PHP. Unfortunately that update for CVE-2022-31625 was incomplete for Ubuntu 18.04 LTS. This update fixes the problem. Charles Fol discovered that PHP incorrectly handled initializing certain arrays when handling the pg_query_params function. A remote attacker could use this issue to cause PHP to crash, resulting in a denial of service, or possibly execute arbitrary code. Charles Fol discovered that PHP incorrectly handled passwords in mysqlnd. A remote attacker could use this issue to cause PHP to crash, resulting in a denial of service, or possibly execute arbitrary code.
Ubuntu Security Notice 5479-2 - USN-5479-1 fixed vulnerabilities in PHP. This update provides the corresponding updates for Ubuntu 16.04 ESM. Charles Fol discovered that PHP incorrectly handled initializing certain arrays when handling the pg_query_params function. A remote attacker could use this issue to cause PHP to crash, resulting in a denial of service, or possibly execute arbitrary code. Charles Fol discovered that PHP incorrectly handled passwords in mysqlnd. A remote attacker could use this issue to cause PHP to crash, resulting in a denial of service, or possibly execute arbitrary code.
Red Hat Security Advisory 2022-5491-01 - PHP is an HTML-embedded scripting language commonly used with the Apache HTTP Server. Issues addressed include buffer overflow and privilege escalation vulnerabilities.
An update for rh-php73-php is now available for Red Hat Software Collections. Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.This content is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). If you distribute this content, or a modified version of it, you must provide attribution to Red Hat Inc. and provide a link to the original. Related CVEs: * CVE-2021-21703: php: Local privilege escalation via PHP-FPM * CVE-2021-21707: php: special character breaks path in xml parsing * CVE-2022-31625: php: uninitialized array in pg_query_params() leading to RCE * CVE-2022-31626: php: password of excessive length triggers buffer overflow leading to RCE
An update for the php:8.0 module is now available for Red Hat Enterprise Linux 8. Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.This content is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). If you distribute this content, or a modified version of it, you must provide attribution to Red Hat Inc. and provide a link to the original. Related CVEs: * CVE-2022-31626: php: password of excessive length triggers buffer overflow leading to RCE
An update for the php:7.4 module is now available for Red Hat Enterprise Linux 8. Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.This content is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). If you distribute this content, or a modified version of it, you must provide attribution to Red Hat Inc. and provide a link to the original. Related CVEs: * CVE-2022-31626: php: password of excessive length triggers buffer overflow leading to RCE
An update for the php:7.4 module is now available for Red Hat Enterprise Linux 8.4 Extended Update Support. Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.This content is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). If you distribute this content, or a modified version of it, you must provide attribution to Red Hat Inc. and provide a link to the original. Related CVEs: * CVE-2022-31626: php: password of excessive length triggers buffer overflow leading to RCE
Ubuntu Security Notice 5479-1 - Charles Fol discovered that PHP incorrectly handled initializing certain arrays when handling the pg_query_params function. A remote attacker could use this issue to cause PHP to crash, resulting in a denial of service, or possibly execute arbitrary code. Charles Fol discovered that PHP incorrectly handled passwords in mysqlnd. A remote attacker could use this issue to cause PHP to crash, resulting in a denial of service, or possibly execute arbitrary code.
In PHP versions 7.4.x below 7.4.30, 8.0.x below 8.0.20, and 8.1.x below 8.1.7, when pdo_mysql extension with mysqlnd driver, if the third party is allowed to supply host to connect to and the password for the connection, password of excessive length can trigger a buffer overflow in PHP, which can lead to a remote code execution vulnerability.