Security: At What Cost?

I was listening to the end of DtSR Episode 179 when a question was asked: would you (or someone you know) buy a “secure” router that cost $25 more? That wasn’t the exact question, but that was the gist.

The immediate question I thought in response was the following (which, of course, I tweeted with the #dtsr hashtag): “How much (more) security do you get for $25? How much (more) do you get for $250,000? And how can non-infosec folks evaluate that?”

The challenge, of course, is how do you quantify security and the value that security provides. There is definitely no one-size-fits-all answer to this question. It comes down to quantifying the various risk in monetary terms. You know, in terms of single-loss expectancy or annualized loss expectancy.

This assumes you know what assets you’re protecting, have some understanding about the value of those assets, and have some clue about the likelihood of a loss and what impact that might have to the asset’s value. Many organizatons I’ve talked to can’t articulate these things, and that’s a problem. You have no idea how much you should spend to protect those assets. You don’t want to spend $1000 to protect a $10 asset, but you might spend $10 to protect a $1000 asset.

And if you think information security professionals have a tough time figuring this stuff out, think about how everyone else approaches the same situation. Is there any wonder there is so much FUD in information security marketing?

Disclaimer: I do work for a vendor: Check Point Software Technologies. These thoughts are my own.

FUD and Cybersecurity Marketing

From Cockroaches Versus Unicorns: The Golden Age Of Cybersecurity Startups:

With increasing hacks, the CISO’s life has just become a lot messier. One CISO told me, “Between my HVAC vendor and my board of directors, I am stretched. And everyday I get a hundred LinkedIn requests from vendors. Their FUD approach to security sales is exhausting.”

More than 50 large security vendors exist, and the list is growing rapidly. More than 200 new security startups are funded each year, competing for the CISO mindshare and budget. And the sales pitches use FUD (fear, uncertainty, doubt) as a primary tactic:

A large part of the reason why the various cybersecurity companies use fear, uncertainty, and doubt (FUD) as part of their marketing strategy is largely because it still works. More specifically, it is because companies have no clue what “security” jobs need to be done. These companies are already afraid out of ignorance (willfull or otherwise).

Various cybersecurity companies simply speak to this fear: “There’s lots of bad things out there and our widget will protect you from it.” Which, is, of course, patently false. Even the best security products in the world are useless if they are not deployed as part of an overall strategy that includes people, policies, and process working towards a common goal.

It’s not enough for cybersecurity vendors to market and sell widgets. We must do better and actually help our customers understand the real threats to their business, not just the ones that make the news. We must help them take steps to integrate security as part of their business process, enabling new capabilities that weren’t possible before without significant risk.

Disclaimer: While I hate the word cybersecurity, I do work for a vendor: Check Point Software Technologies. These thoughts are my own.

The Security Industry: Lead By Example

If the security industry itself can’t be bothered to fix security issues in a timely manner, how can we expect customers to apply the patches in a timely manner? Shouldn’t we be leading by example?

Generally speaking, Check Point (where I work) is pretty quick to respond to reported issues. In some cases, fixes have been out in hours. Some of Check Point’s competitors? Not so quick. Here are a couple recent examples.

FireEye’s Year Old Vulnerability

A couple people from Check Point reported an issue to FireEye on 24 July 2014. While the issue was reported on one of their products (their ‘EX’ product), the issue actually affected several of their products. A “fixed” version of code for the product we reported on was issued on 7 July 2015, 349 days after it was first reported. This is how the issue was reported in their Q4 2015 Security Vulnerability advisory:

FireEye Vulnerability

To be fair, the issue was fixed in some products in a much shorter time, but for one product, it was about 15 months.

The acknowledgement by FireEye is misleading. First of all, the employer of the reporters was not mentioned as it was for others in the advisory (it’s Check Point, as noted previously). Second of all, the actual issues reported are more serious than the somewhat misleading description FireEye chose to provide. Even with the description provided, I disagree with the “low” severity rating. Social engineering attacks, anyone?

Palo Alto Networks Evading For Three Years

I’ve largely covered the vulnerability in question on a previous post. The one update I can provide is that 3 years after the original SANS Institude paper being published highlighting the deficiencies, Palo Alto Networks finally issued an update to their Application and Threat Content that addresses the issues. Or at least they addressed the issues demonstrated by the 666 different ways to bypass Palo Alto Networks video, which are based on the same principles.

More Examples

Check Point has actually found and responsibly disclosed a number of vulnerabilities in a number of common services and software products, including those of competitors. A presentation has been posted on SlideShare providing the details.

Conclusion

Every product out there is going to have security vulnerabilities found in it, including and especially products designed to keep your environments secure. What separates the mature, market-leading vendors from the others is how you respond to such reports.

Prevention vs. Detection: It's Not Either Or

From No, Virginia, It Does NOT Mean That!:

Here are my top 5 reasons why DETECTION excellence does NOT automatically mean you can have PREVENTION: [Uncertainty, Timing, Vague Signals, False Positives, and Detecting From Exploration]

This article, written by a VP of Research at Gartner, completely misses the most obvious element of a prevention stance: the ability to actually block the malicious traffic. That, of course, requires segmentation and some security control that can actually block the traffic in question.

(By the way: anyone who truly believes detection is better than prevention should turn off their firewalls right now. Go ahead, turn them off. Oh wait, you actually want to block some traffic you know you don’t want? That’s not what a “detect only” mindset allows for.)

I’ve seen several organizations use various “threat intelligence” (either internally gathered or a combination of internal and external intel) and simply using basic firewall functionality to block access to known malicious sites. This might be automated or it might not, meaning there is a gap between something “bad” being discovered and that configuration being implemented on your firewalls.

A much better approach would be to use tools that are able to understand in realtime what traffic is good or bad, consulting external threat intelligence that is updated automatically and continually to the enforcement points, and actually have the traffic blocked. Sure, you may get the occasional false positive, but is a false negative actually better?

Sure, no solution is going to stop 100% of all threats, because even preventative controls that consult the best threat intelligence in the world isn’t going to know about everything. By definition, it can only block known bad traffic and, with an inline malware sandboxing solution, a good percentage of the zero-day malware can be blocked too. It’s still not going to get everything. The silver lining is that a lot of the breaches that occur actually use known bad traffic. Thus, a comprehensive in-line threat prevention solution located at strageic points in the environment will be a net-positive for just about every organization.

For those things we can’t block that are bad and truly unknown, we still need to detect those things, and just as importantly, respond in a timely manner.

Disclaimer: Check Point (where I work) has a great next generation threat prevention solution. That said, the above are my own thoughts.

Third Party Validation Of Security Solutions Now More Important Than Ever

From Living On An Exponential Curve Of Breaches:

The knowledge that a major networking gear manufacturer’s product has been compromised will raise the question: just how does one trust that products one has purchased are not compromised by a government or sophisticated hacker? Are vendors prepared to submit their products to 3rd party testing labs for assurance purposes? At the very least that assurance should come from complete code reviews and broad spectrum fuzzing. This is an expensive proposition, one that will have to be incorporated in every vendor’s release schedules. At the end of the day will that level of assurance be enough?

Of course, we’re talking about the recent Juniper and Fortinet vulnerabilities that allow unauthorized administration access, and of course made the news.

I don’t know that you’ll get any security company to submit their source code to an external third party code review, but third party validation and assurance testing seems perfectly reasonable. In fact, vendors already do this with NSS Labs and Common Criteria testing.

Meanwhile, you have vendors with restrictive EULAs that forbid this kind of activity. Which, given that this particular vendor spends more than half of their revenue on marketing, makes you wonder if they’re in the security business or the marketing business.