Wenn Sie die Schlagzeilen des letzten Jahres gesehen haben, dann wissen Sie, dass nicht gepatchte Software für einige der schädlichsten Cyberangriffe verantwortlich ist, denen Unternehmen ausgesetzt sind.
In fact, according to a recent study by ServiceNow, nearly 60% of organizations that suffered a data breach in the last two years were attacked via a vulnerability for which they hadn’t deployed a patch for yet.
It gets worse: 34% also said they knew their systems were vulnerable prior to the attack. That’s the equivalent of receiving a police bulletin that known burglars were spotted in your neighborhood, yet leaving your front door unlocked anyway.
This reflects a major misconception when it comes to patching. The popular view is that a vulnerability is discovered, and then there’s a race between hackers to weaponize it and software companies to patch it. Once it’s patched, the race is over.
However, in reality that’s when the race truly begins. A patch only works when it’s installed, not just available. In a report by Flexera, they found that 86% of all vulnerabilities in 2017 had a patch available on the day of disclosure. While deploying a patch the same day it’s available seems like it should be the standard operating procedure, in reality it can take weeks, months or sometimes even years to deploy a patch.
What’s the hold up?
A manual patch deployment process plays a large role. According to the ServiceNow study, 12 days are lost just in coordinating across teams for every vulnerability they patch. Reasons for this include:
1. Having no common view of assets and applications across security and IT (73%)
2. Things slipping through the cracks because emails and spreadsheets are used to manage the patching process (57%)
3. No easy way to track if vulnerabilities are being patched in a timely manner (62%)
Given these statistics, it’s hard to believe that some or even many companies are meeting their security level agreements (SLA). An SLA is commonly used to get in writing the security requirements and expectations for either an outsourced vendor or internal resource like the IT department. This includes scanning for vulnerabilities, code quality control and patching.
Beim Patching deckt ein SLA normalerweise Patching-Standards ab für Dinge wie:
Partner erwarten schnelle Patches, damit es nicht zu Datenverlusten kommt, die leicht hätten verhindert werden können.
Just one device can lose massive amounts of data. An SLA will often state that 100% of devices must be patched within a certain period after patch release.
It’s not enough to patch everything quickly. It must be verified with agreed-upon reporting standards.
Given the prominence preventable data breaches have been given in the news thanks to the Equifax breach and the WannaCry attack, SLAs are being more strongly enforced or rewritten to make patching a priority. That means a data breach won’t only mean a loss of data; it will also mean a breach of contract and all the fines, penalties and litigation that can go along with it.
There’s no standard for SLA targets; depending on the severity of the vulnerability it can range from hours to sometimes months or even years. However, we can be sure these policies will be given a close look to determine if they’re timely enough.
If they’re not, or even if they are, do you or your vendors have the tools in place to achieve them? The answer might determine if it’s your company’s name that makes it in the next headline.