The global outages caused by CrowdStrike’s update last week highlight an ongoing tension between cybersecurity and operations teams.
These teams certainly agree on the availability of systems as a top priority, but that can be adversely impacted when a patch or change is made within an environment to better secure it. The same goes for when a change is not made within an environment.
On one hand, we have CrowdStrike, where the downtime took place because an update took place without first being properly tested. The subsequent outage’s impact continues to ripple on a global scale. And let’s not forget the United software update from 2023, which resulted in canceled and delayed flights like what the whole airline industry saw over the last few days.
On the other hand, we have Change Healthcare, where the issue was an update that was not deployed. Change didn’t update its critical systems to implement and enforce multi-factor authentication — a well-known best practice and a frequent regulatory requirement, depending on the sector. The failure to make this update resulted in its systems’ vulnerability to a successful threat.
These outages represent two distinct, but related, challenges that require a delicate balancing act:
Do organizations make security changes as soon as possible to avoid suffering a cyberattack, or delay updates (sometimes, seemingly indefinitely) until they have time to test how a patch will affect their systems?
Cybersecurity teams focus on identifying vulnerabilities and weaknesses as soon as possible and fixing them, especially when they pose critical risks. These professionals are afraid of a breach or successful attack but usually don’t have the authority to deploy any changes.
That’s where the operations teams come in. They often fear a patch or other security change’s disruption of operations more than a successful breach.
Both fears are legitimate, as the CrowdStrike and Change Healthcare incidents demonstrate. Deploying patches without taking the time to properly test them can cause disruption and downtime; waiting too long to deploy changes can result in breaches and attacks that also generate disruption and downtime.
The National Institute of Standards and Technology’s (NIST) Special Publication 800-40rev4 talks about the tension this way:
“What needs to change in many organizations is the perception that an operational disruption caused by patching is harm that the organization is doing to itself, while an operational disruption caused by a cybersecurity incident is harm caused by a third party. While those may be true statements in isolation, they are misleading and incomplete as part of an organization’s risk responses. Disruptions from patching are largely controllable, while disruptions from incidents are largely uncontrollable. Disruptions from patching are also a necessary part of maintaining nearly all types of technology in order to avoid larger disruptions from incidents.”
But the question remains: How can organizations balance cybersecurity and operations?
The broadest answer is that organizations need to mature their vulnerability and patch management program, along with any supporting processes. That’s certainly easier said than done, but publications like NIST’s provide a good place to start. Getting to a place of maturity in these operations has a lot to do with how the environment is implemented — for instance, does the organization know its assets? Are those assets configured according to best security practices?
Again, the path to a secure environment requires balancing protection and operations. As organizations change systems to make them more secure, they have to test to see how these changes impact functions.
This incremental process mandates documenting any exceptions where the change and the system operations are simply incompatible, as well as some other compensating measure to ensure the balance. Testing to get to a place of maturity — and evaluating even after the vulnerability and patch management program reach that maturity, so that operations teams can take next steps with clarity and confidence — is key.
A lot of automation tools, like configuration scanners, help find issues that need remedy. Others can facilitate patch deployment and changes. But a glaring gap remains in the test automation arena for operations teams.
Evaluation often consumes operations teams and systems administrator’s time. It doesn’t have to, though, when using a remote, secure test environment with a digital twin of the systems; creating customized AI- and ML-driven functional tests; executing the tests before and after the environmental changes; reporting on the issues the update may cause; and providing a clear impact report.
My own company, CyDeploy, is trying to fix this gap. There is a future where changes can be made quickly, and with confidence.
Before you go...
Please consider supporting Technical.ly to keep our independent journalism strong. Unlike most business-focused media outlets, we don’t have a paywall. Instead, we count on your personal and organizational support.
Join our growing Slack community
Join 5,000 tech professionals and entrepreneurs in our community Slack today!
![](https://technical.ly/wp-content/uploads/2024/09/Screenshot-2024-09-05-at-8.49.06 AM-400x305.png)
No, Kamala Harris isn’t the official candidate of the Philadelphia Eagles – and the city’s ads didn’t get hacked
![](https://technical.ly/wp-content/uploads/2024/08/Copilot-Tight-Angle--scaled-449.912126538x300.jpg)
Tech to make biking safer with AI-powered alerts gets $200k in federal funding
![](https://technical.ly/wp-content/uploads/2024/09/IMG_0444-3-scaled-463.488231744x300.jpg)
Newly formed AI startup acquires Philly’s defunct LifeBrand, which still owes staff and investors
![](https://technical.ly/wp-content/uploads/2024/03/universityofbaltimore-02-scaled-449.912126538x300.jpg)