Security – Page 16

How do you justify your security budget?

August 4, 2017 By Doug

dreamstime_m_18916214-1 — (c) Qingwaa | Dreamstime.com

As part of my day job, I get to talk with a wide range of organizations across many different industries, and annual budget time is just kicking off. This year I’ve seen two intersecting trends: a growing willingness (resignation?) from business owners that they have to pay much more attention to security and pay more for it, and second, a demand for some way to measure the effectiveness of that spend. As one business leader asked, how do you tell the difference between an effective program and just plain luck?

It’s a tough question for a number of reasons. After all, we have to be good 100% of the time, and our adversaries only need one solid success to undo all our work. Teams are reporting raw counts of attacks thwarted, malware remediated, time to discover, time to remediate, records lost, and so forth. Those are all important, but only show activity, not effectiveness and none get really to the cybereconomic case for the security investment.

The formal answer is that we should spend money less than or equal to the annualized loss expectancy for the asset involved: ALE = Single Loss Expectancy * Annual Rate of Occurrence. Sounds great, and you’re all set to pass the CISSP exam, but is that possible in the real world? At the moment, I’d argue no. While do have good data for some factors – the Ponemon Cost of a Data Breach study just came out (though the Anthem breach settlement will skew the next one), and a pretty good handle on the daily grind of malware, phishing and compromised accounts, the worst incidents don’t fall into those categories.

Both in severity and frequency, we are lurching from one black swan event to another. You know, those company-jeopardizing, class-action-attorney enriching breaches. I gave a keynote on cognitive security recently and attendance was down because NotPetya hit that morning. No one predicted it, and there’s no way to predict when, what, or how the next one will hit. Our best estimate is that things are getting worse, not better – more sophisticated, less frequent, more impactful, but as the SEC is fond of reminding us, past performance is no guarantee of future success – or failure. We simply can’t predict the future. Anyone who says differently should quit their security job and go work in the stock market.

All that makes the CISO’s life painful through the budgeting process – do you get more money if you were hit by Petya/WannaCry/NotPetya because you had insufficient capability, or do you get fired for blowing last year’s budget on an ineffective program? That’s one of the reasons most CISO’s are focusing heavily on incident response, not just detection and prevention. They’re also starting to step back and ask themselves if they’re getting good value for the investment – particularly in niche tools, or ones focused on yesterday’s threat (like signature based antivirus). As for the budget itself, what I see most organizations using is a combination of baseline no-brainer capabilities, regulatory requirements, peer best practices to find the sweet spot for the ‘commercial reasonable measures’ budget target. Right now, keeping up with the Joneses is a common target. Or put it another way, we don’t have to be faster than the bear – we just have to be faster than the next guy running.

150,000 election day hacking attempts? Calm down and step away from the keyboard

July 28, 2017 By Doug

Depositphotos_145987351_original-1 — © gsagi / www.depositphotos.com

In the past couple of weeks, there’s been a number of stories breathlessly proclaiming that one state endured 150,000 ‘hack attempts’ on election day, that another was hit five times per second, 24 hours per day prior to the election, and so forth. But notice how none of the articles talk about how many ‘hack attempts’ were made the day after the election? Or the month before? Or six months after?

Now I don’t have access to the actual data from those states, but I strongly suspect that these numbers, while legitimate, are being spun to grind a political axe. Any IP address is going to be hit with port scans on a regular basis. Government sites are absolutely hit with many thousands of both targeted and drive-by probes. Sure, there might have been an uptick in activity approaching the election, but what I really want to know is how many focused, targeted sophisticated attacks happened versus non-election season? Then we might actually know something. We need a baseline of both general and targeted attack traffic to be able to judge if there’s anything statistically significant in the data – and ideally, to have comparison data for the previous election too. Until then, well, folks should take partial data with a grain of salt.

One last note – I am surprised that only 39 states report hacking attempts. Either the bad guys were slacking, or we have 11 states that don’t have good monitoring in place.

1Password and the loss of local sync

July 12, 2017 By Doug

Depositphotos_13488215_original-1 — (c) www.depositphotos / Olivier Le Moal

Revised update:

I’ve had conversations with AgileBits via their support forum, and there’s been some back and forth, so let me revise my update and consolidate what I’ve learned.

For existing users on OSX and iOS, local vaults and local sync remains in place. Agile states no plans to remove, but will not commit to that functionality long term.
For users on Windows and Android, local vaults and local sync are not available.
New users must buy a subscription to 1Password.com, which forces them to create a web vault, master passphrase and such. Once signed up, OSX and iOS users can jump through some hoops and convert to a local vault. This will result in challenges, accidental use of the incorrect vault, and is generally a pain – it’s well hidden, by design.
As The Register put it, “1Password won’t axe private vaults. It’ll choke ’em to death instead.” That pretty well sums it up.

I understand that the company needs a more sustainable revenue model, and a subscription option is the way to go. Adobe and Microsoft are right there too. But the insistence on linking subscription to cloud vaults just makes no sense. We in the security industry are often painted as acting as if we are ‘smarter than the users’, and this is a prime example of it. While cloud vaults may make sense for the majority of users, it is by no means appropriate for everyone.

Our job as security professionals is not to say yes or no to a solution, it’s to present options, risks, and yes, recommendations, but then let each user make their own decision. Once they decide, then we tell them how to be safe given their own constraints and preferences. We do not own the risk, users do.

Until and unless AgileBits allows users to download the software, purchase a subscription, and use local vaults and local syncing without any cloud involvement, across all four major platforms, I can no longer recommend 1Password for new users. Again, let me be clear – I’m happy to move to a subscription model, but artificially linking that to a cloud service is an unacceptable downgrade in the security of the solution.

I welcome suggestions in the comments for alternative products that provide this important capability.

Original post follows:

Go to any talk or read almost any blog post on ‘keeping safe online’ and you’ll see a recommendation to use a password manager. They mitigate the impact of any individual site being breached and substantially upgrade defenses against password guessing. But they also consolidate all your passwords into a single place, which raises risk in a different way. When using one, you’re betting that the tradeoff is worth it (and it generally is). Security is all about making those tradeoffs – there’s no one-size-fits all solution for any security risk.

Which brings me to AgileBits, 1Password and the tradeoff they’ve decided to make for us. 1Password has long been a favorite of security professionals because of its reliable functionality, ease of use, solid crypto, and comprehensive set of features that address many different threat models. Now one of those key features is on the chopping block – as part of their move to a subscription model, they’re also forcing folks to their cloud service, and they will make no statements of continued support for local syncing. For anyone who manages risk for a living, it means we have to assume that it will die from neglect and start looking for alternatives.

Unfortunately, they are providing overly simplistic responses when objections are raised, and like many things in security, the nuances are important, so let me try to clear up a few things.

First, they’ve chosen to confuse two completely separate issues – the move to a subscription model (business decision) with the move to a cloud-only syncing solution (technical decision). They need not be linked. Adobe and Microsoft have both shown that a company can successfully move to a subscription model for locally installed software – neither require the use of their cloud service. And while Apple is intentionally making it more and more difficult to stay local, even there you still can. So let’s set aside subscriptions as irrelevant to the discussion.

The design of the new cloud based system appears robust, and they’ve had audits done on the code and service. Good so far. Then they state “We are advocating memberships since we feel it’s the best way to use 1Password.” Fair enough, and for a class of users, probably the majority, the threat model tilts towards convenience being a key feature. I know folks like that myself, and recommend that they use Dropbox or 1Password’s cloud service – but also tell them to use two factor everywhere they can, and be prepared to go change every single password if there’s a breach (more on that in a moment). For them, the tradeoff is worth it because the alternative is to not use a password vault at all.

But that statement is based an overly simplistic user base and threat model. The truth is far more nuanced, and for substantial minority of users it’s not a good option. These include folks who are prohibited by corporate policy from using non-contracted third-party cloud services (extremely widespread), and individuals willing to put up with the minor hassle of local syncing to reduce their risk. Having all the vaults in a single place makes it a tempting target for an attack, breach and disclosure. Unfortunately, Agilebits asserts in forum posts that compromised vaults are “useless” to an attacker. That’s grossly oversimplified, and I quickly came up with three ways they aren’t useless:

First, they are immediately useful as a business-level attack against Agilebits, as losing the vaults would be a material event to the company, undermining trust even if not compromised. If public trust is lost, and Agilebits goes out of business, or if a substantial portion of users leave for a less secure (or no) solution, then that’s a net gain for the bad guys.

Second, for users who’ve chosen a weak master passphrase they have some utility for decryption attacks using lists of common passwords. Granted that the computational defenses Agilebits has put in place make that more difficult, but attacks only get better with time. Most likely, especially if vaults are linked with specific individuals, is a targeted attack to discover a weak passphrase based on social media and other research.

Last, for those with robust passphrases (which I suspect is a minority of users), stolen vaults are likely safe until and unless a defect in the implementation of the crypto is discovered. While the math may be secure (a whole separate topic), that crypto is implemented by humans writing code. As with any and every software package*, there are defects in the code. Some of those may impact security. Full Stop. So all an attacker has to do is sit and wait – and if/when a vulnerability is found in the code that reduces the attack complexity, every vault and every password is at risk. The chance of that is non-zero, but it’d be a black swan, and there’s no real way to quantify those.

The fact that Agilebits doesn’t have access to decrypt vaults, or ever touch master passphrases is irrelevant to these particular threats. They generally respond to questions about code risks with a whitepaper about crypto risks. Even with auditing, that’s still the major concern in the last bullet, not a fundamental break in the underlying crypto (e.g. quantum cryptanalysis). If that happens, we have far more issues than our password vaults.

A breach of a password vault is catastrophic. And that’s why security professionals keep them local – a diffuse target is a harder target to economically exploit. If someone wants to go after an individual, an attacker is going to use a keylogger, at which point a password vault doesn’t help and cloud/local makes no difference. But concentrating all the vaults in a single place makes an attack worthwhile.

Agilebits may be making a business decision – that the cost of maintaining local sync isn’t worth keeping those users. That’s their call, but I wonder how many people use 1Password because it was endorsed by security professionals who do so because it does cover multiple threat models. That’s a lot of high-quality free advertising that may be lost.

I wish they would acknowledge that there are diverse use cases and stop painting users with a blunt brush (apologies for the mixed metaphor). For some users, ease of use is a security feature as the alternative is no vault at all. But for others, the tradeoff just isn’t worth it (or even possible under company policy).

If they want to end support for perpetual licenses, fine, I’ll step up day one and sign up for a subscription license. It’s easily worth a few bucks a month to my family. But they really need to stop with the weasel words, admit that there are multiple threat models in play, that cloud only answers one of them, and commit to local syncing long term regardless of the licensing model.

*Footnote: Yes, it’s theoretically possible to formally analyze a set of code and determine that it is complete and correct, but in practice that’s never done. EAL 7 rarely exists in the real world, and never does in consumer-grade products as the cost of validation for each and every configuration of hardware and software is far beyond any reasonable investment.