News

IDC Provides Strategies for Orgs to Protect Against Security Incidents

• By Kurt Mackie
• 05/26/2017

This week IDC offered some advice on how enterprises should handle security issues.

In a recently published article, the Framingham, Mass.-based analyst and consulting firm argued that attempts to stay up to date with software patching haven't been up to the task of providing security for organizations. In addition, most attacks (90 percent) arrive through e-mail and phishing attempts rather than through software exploits.

Instead of betting on patching to keep networks safe, IDC argues that organizations should keep regular backups and harden their network endpoints. They can also use software and other techniques to thwart malware within networks. The high-level arguments are outlined in an IDC article, "Pursue Patch Independence: Latest WannaCry Events Prompts Need for Risk-Based Defenses," which offers a strategic view that's perhaps aimed more toward chief information security officers or other internal policy makers.

The WannaCry ransomware was spread through a security flaw in the Server Message Block version 1 protocol that's used in Windows systems. Possibly, Microsoft wasn't aware of the flaw, since the hack was sourced to an alleged cache of espionage tools that leaked from the U.S. National Security Agency. It's an example of a so-called "zero day" software flaw where up-to-date patching wouldn't necessarily have saved the day.

And that notion fits within IDC's "patch independence" perspective, as explained by Pete Lindstrom, vice president of security strategies at IDC, and one of the report's coauthors. He argued that the estimated 200,000 nodes said to have been affected by the WannaCry malware represented just a small number across the Internet. Most enterprises likely never even saw the attack.

"Part of my realization is that we're talking about that last mile of security," Lindstrom said, in a phone call on Thursday. "And security folks have been working their asses off trying to cover that last mile and do a great job with patching and do a great job with security awareness -- the top two things everyone keeps saying we should be doing. But when you're talking about Internet-scale kinds of problems, you end up being stuck with that final mile actually being fairly big numbers."

He argued that organizations already know that they should be doing patching. However, patching just can't be 100 percent all of the time. It calls for other actions.

"We're stuck in a box, and the box is 'patch,' and everyone thinks you have to patch but there are plenty of other things you can do," Lindstrom said. "For example, some sort of application control or white-listing, an integrity-based approach to protection that gets you to patch agnosticism, if not independence."

Organizations should apply patches, but it's just "dumb advice" to suggest that organizations should work harder at patching, he added.

"For some reason, our fallback position is 'find vulnerabilities and patch them,'" Lindstrom said. "By the way, the math doesn't work on any of that."

More software vulnerabilities are created each day than are found, he added. There are social engineering attacks that are more important to consider from a strategic level, Lindstrom said.

He advised IT pros to just mentally get off the patching bandwagon and thinking it's a way to assure security.

"It [patching] works in the human world, but this is the Internet world. It doesn't scale -- that's the bottom line."

Moreover, waiting for the next patch disclosure can be said to just increase risks for organizations.

"Certainly, we see over and over again with academic work, that disclosure of the existence of the patch and disclosure of the vulnerability increases incidents," Lindstrom said. "It doesn't decrease them. So the aggregate risk is higher."

Lindstrom offered a couple of examples of alternative security measures to try. He said that organizations might aim to block what happens after a click in e-mail phishing campaigns as one strategic approach. Another possible approach is for a mail server to block e-mails with domain names that are less than 48 hours old, which can be used to stop spam.