To prevent data breaches, practice these two fundamentals: shift left (perform application security testing early and often in your SDLC), and always patch.
The original version of this post was published on Forbes.
It’s a pretty good bet that if a car dealership posted an ad announcing that the criminal underground was selling keys that could unlock owners’ vehicles, but that it was offering free replacement locks that wouldn’t be vulnerable, the responses would be quick and universal.
Apparently, we’re not quite there when it comes to software. Security firm Tripwire reported this week, based on a survey of 340 information security professionals, that 27% of organizations worldwide and 34% in Europe reported that they had been breached because of unpatched vulnerabilities.
The survey was conducted last month by Dimensional Research.
The results should be no surprise. The ever-lengthening list of headlines about breaches—some catastrophic like that of credit reporting giant Equifax—is because organizations still ignore patches for publicly reported vulnerabilities.
There is, of course, more than one way to view those statistics. “Only” one in four might sound like a positive—that means 75% weren’t breached. But most people’s expectation for physical security would be more like one chance in several hundred that a thief could defeat their home security system.
And keep in mind that these aren’t “zero-day” vulnerabilities that haven’t been seen before—these are known bugs or flaws, with patches available. The victims simply failed to apply the available patches.
The report also offers plenty of reasons why organizations are vulnerable.
Why is rigorous patching—a fundamental of good security—not close to 100%? That is the multi-million-dollar question. According to an IBM study, the average cost of a data breach last year was $3.86 million.
Indeed, breaches are costly in multiple ways. Among the potential damages are loss of reputation, a drop in market value, compliance fines and legal liability. While most companies survive them, they can be an existential threat.
The irony is that it doesn’t have to be this way. While bulletproof security is impossible, organizations are not defenseless. There are multiple tools and other measures available that can improve the security of networks, applications and systems enough to prompt all but the most expert and motivated hackers to look for easier targets.
Doing that comes down to two fundamentals:
First, application vendors need to build security into the software of their products before they ever hit the market. It won’t be perfect, but it can come close. And in application security, unlike in most sports, close matters.
Second, organizations that use software—and all of them do—need to know what they have, and keep it up to date. As has now become a cliché (because it is true), you can’t protect what you don’t even know you have.
The template for how to do the first is now well established. It is preached from the podiums of every security conference. The universal expression is “shift left,” which means conducting security testing from the beginning and throughout the software development life cycle (SDLC). Don’t “save” it for penetration testing at the end.
There is a comprehensive menu of tools to help developers find and fix bugs. They include (but are not limited to):
Of course, at the end of all that, even if software is close to perfect, vulnerabilities will inevitably be discovered, either by bad guys who’ll exploit them, or by good guys who’ll report them to the makers before going public.
And that leads to the second fundamental: Know what you have and keep it up to date—as in, patch, patch, patch. That applies both to vendors and their customers.
Tim Erlin, vice president of product management and strategy at Tripwire, said besides secure development practices, vendors need “a process for remediation of any discovered vulnerabilities. For vendors, the problem isn’t really fixed until their customers actually apply a patch or other mitigation.”
Justin Hutchings, senior product manager of security at GitHub, the code-sharing and publishing service that also manages and stores revisions of projects, agreed. Obviously, it is the responsibility of companies to disclose and provide fixes for vulnerabilities in their software.
But once the vulnerability has been disclosed, “it’s the responsibility of downstream software projects and IT organizations to patch vulnerabilities,” he said.
And the reality, which confirms the Tripwire findings, is that not all of them do. “In the last year, we’ve sent nearly 27 million security vulnerability alerts to vulnerable software projects on GitHub,” he said.
“While security vulnerability alerts provide users with information to secure their projects, industry data shows that more than 70% of vulnerabilities remain unpatched after 30 days, and many can take as much as a year to patch,” said Hutchings.
One way to improve on that, he said, is by moving business-critical software to the cloud. “Software-as-a-service apps tend to be patched much faster because they’re all centrally managed and don’t rely on thousands of customers’ individual upgrade cycles,” he said.
Yes, all of these measures cost money. But they are all much cheaper than dealing with the fallout from a major breach.