breaches – Adam Shostack & friends

Yahoo! Yippee? What to Do?

[Dec 20 update: The first draft of this post ended up with both consumer and enterprise advice, which made it complex. The enterprise half is now on the IANS blog: Never Waste a Good Crisis: Yahoo Edition.]

Yesterday, Yahoo disclosed that attackers broke into Yahoo in 2013 and stole details on a billion accounts. Brian Krebs summarizes what was taken, and also has a more general FAQ.

The statement says that for “potentially affected accounts, the stolen user account information may have included names, email addresses, telephone numbers, dates of birth, hashed passwords (using MD5) and, in some cases, encrypted or unencrypted security questions and answers.”

Yahoo says users should change their passwords and security questions and answers for any other accounts on which they used the same or similar information used for their Yahoo account.

The New York Times has an article “How Many Times Has Your Personal Information Been Exposed to Hackers?”

The big question is “How can you protect yourself in the future?” The Times is right to ask it, and their answer starts:

It’s pretty simple: You can’t. But you can take a few steps to make things harder for criminals. Turn on two-factor authentication, whenever possible. Most banking sites and ones like Google, Apple, Twitter and Facebook offer two-factor authentication. Change your passwords frequently and do not use the same password across websites.

I think the Times makes two important “mistakes” in this answer. [Update: I think mistake may be harsher than I mean: I wish they’d done differently.]

The first mistake is to not recommend a password manager. Using a password manager is essential to using a different password on each website. I use 1Password, and recommend it. I also use it to generate random answers to “security questions” and use 1Password’s label/data fields to store those. I do hope that one day they start managing secret questions, but understand that that’s tricky because secret questions are not submitted to the web with standard HTML form names.

The reason I recommend 1Password is that it works well without the cloud, and that means that a cloud provider cannot disclose my passwords. They also can’t disclose my encrypted passwords, where encrypting them is a mitigation for that first-layer information disclosure threat. (One of these days I should write up my complete password manager threat model.) These threats are important and concrete. 1Password competitor Lastpass has repeatedly messed this up, and those problems are made worse by their design of mandatory centralization.

It’s not to say that 1Password is perfect. Tavis Ormandy has said “More password manager bugs out today and more due out soon. I’m not going to look at more, the whole industry is crazy,” and commented on 1Password with a GIF. Some of those issues have now been revealed. (Tavis is very, very good at finding security flaws, and this worries me a bit.)

But: authentication is hard. You must make a risk tradeoff. The way I think about the risk tradeoff is:

If I use a single password, it’s easily compromised in many places. (Information disclosure threats at each site, and in my browser.)
If I use a paper list, an attacker who compromises my browser can likely steal most of my passwords.
If I use a cloud list, an attacker who breaks into that cloud can steal the list. If the list is encrypted, then they can still attack it offline. If the cloud design either sends my master password to the cloud, or javascript to the client, then my master password is vulnerable to an attacker who has broken into the cloud.
If I use a paper list, I can’t back it up easily. (My backups are on my phone, and in a PGP encrypted file on a cloud provider.)

So 1Password is the least bad of currently available options, and the Times should have put a stake in the ground on the subject. (Or perhaps their new “Wirecutter” division should take a look. Oh wait! They did. I disagree with their assessment, as stated above.)

The second big mistake is to assert that you can’t fully protect yourself in a simple, declarative sentence at the end of their answer. What’s that you say? It’s not the end of their answer? But it is. In today’s short attention-span world, you see those words and stop. You move on. It’s important that security advice be actionable.

So: use a password manager. Lie in your answers to “secret questions.” Tell different sites different lies. Use a password manager to remember them.

The Breach Response Market Is Broken (and what could be done)

Much of what Andrew and I wrote about in the New School has come to pass. Disclosing breaches is no longer as scary, nor as shocking, as it was. But one thing we expected to happen was the emergence of a robust market of services for breach victims. That’s not happened, and I’ve been thinking about why that is, and what we might do about it.

I submitted a short (1 1/2 page) comment for the FTC’s PrivacyCon, and the FTC has published that here.

[Update Oct 19: I wrote a blog post for IANS, “After the Breach: Making Your Response Count“]

[Update Nov 21: the folks at Abine decided to run a survey, and asked 500 people what they’d like to see a breach notice letter. Their blog post.]

Threat Modeling Crypto Back Doors

Today, the Open Technology Institute released an open letter to the President of the United States from a broad set of organizations and experts, and I’m pleased to be a signer, and agree wholeheartedly with the text of the letter. (Some press coverage.)

I did want to pile on with an excerpt from chapter 9 of Threat Modeling: Designing for Security:

For another example of comparative threat modeling, consider the two systems shown in Figures 9-2 and 9-3. Figure 9-2 depicts an e-mail system, and Figure 9-3 is a version of 9-2 with a “lawful intercept” module added. (“Lawful intercept” is an Orwellian phrase for “thing which allows people to bypass the security features of your system.” Setting aside any arguments of “should we as a society have such a mechanism?” it’s possible to assess the technical security implications of adding such mechanisms.)

It should be obvious that Figure 9-2 is more secure than Figure 9-3. Using software-centric modeling, Figure 9-3 adds two data flows and a process; thus, by STRIDE-per-element, it has an additional 12 threats (tampering, information disclosure, DoS with each flow, for 6; and the six S,T,R, I, D, and E threats against the process for a total of 12). Additionally, Figure 9-3 has two apparent groupings of elevation-of-privilege threats: those posed by outsiders and those posed by software-allowed, but human-policy-violating, use. Thus, if Figure 9-2 has a list of threats (1…n), then Figure 9-3 has a list of threats (1…n+14).

If instead of software-centric modeling you use attacker-centered modeling on the systems shown in Figures 9-2 and 9-3, you find two sets of threats: First, each law enforcement agency that is authorized to connect adds its employees and IT systems as possible threats, and possible threat vectors. Second, attackers are likely to attack these features of the system to abuse them. The 2010 “Aurora” attacks on Google and others allegedly did exactly this (McMillan, 2010, and Adida, 2013). Thus, by comparing them you can see that the addition of these features creates additional risk. You might also wonder where those risks fall, but that’s outside the scope of this example.

More subtly, the addition of the code in Figure 9-3 is an obvious source of security vulnerabilities. As such, it may draw attention and possibly effort away from the rest of the system. Thus, the components that comprise Figure 9-2 are likely to be less secure, even ignoring the threats to the additional components. In the same vein, the requests and implementations for such back- doors may be confidential or classified. If that’s the case, the features may not go through normal tracking for implementation, testing, or review, again reducing the odds that they are secure. Of course, because such a system is designed to bypass other security controls, any weaknesses are likely to have outsized impact.

The technical arguments are simple. All other things being equal, systems with backdoors are unavoidably less secure, and probably worse than that. American companies cannot be competitive if the government forces us to add them.

[Update, July 7, 2015: A group of experts has released a longer paper, “Keys Under The Doormat.” Blogs from Ross Anderson and Steve Bellovin give additional perspective.]

The Onion and Breach Disclosure

There’s an important and interesting new breach disclosure that came out yesterdau. It demonstrates leadership by clearly explaining what happened and offering up lessons learned.

In particular:

It shows the actual phishing emails
It talks about how the attackers persisted their takeover by sending a fake “reset your password” email (more on this below)
It shows the attacker IP address (46.17.103.125)
It offers up lessons learned

Unfortunately, it offers up some Onion-style ironic advice like “Make sure that your users are educated, and that they are suspicious of all links that ask them to log in.” I mean, “Local man carefully checks URLs before typing passwords.” Better advice would be to have bookmarks for the sites you need to log-in to, or to use a password manager that knows what site you’re on.

The reset your password email is also fascinating. (“The attacker used their access to a different, undiscovered compromised account to send a duplicate email which included a link to the phishing page disguised as a password-reset link. This dupe email was not sent to any member of the tech or IT teams, so it went undetected. “) It shows that the attackers were paying attention, and it allows us to test the idea that, ummm, local man checks URLs before typing passwords.

Of course, I shouldn’t be too harsh on them, since the disclosure was, in fact, by The Onion, who is now engaged in cyberwar with the Syrian Electronic Army. The advice they offer is of the sort that’s commonly offered up after a breach. With more breaches, we’ll see details like “they used that account to send the same email to more Onion staff at about 2:30 AM.” Do you really expect your staff to be diligently checking URLs when it’s 2:30 AM?

Whatever you think, you should read “How the Syrian Electronic Army Hacked The Onion,” and ask if your organization would do as well.

MD5s, IPs and Ultra

So I was listening to the Shmoocon presentation on information sharing, and there was a great deal of discussion of how sharing too much information could reveal to an attacker that they’d been detected. I’ve discussed this problem a bit in “The High Price of the Silence of Cyberwar,” but wanted to talk more about it. What struck me is that the audience seemed to be thinking that an MD5 of a bit of malware was equivalent to revealing the Ultra intelligence taken from Enigma decrypts.

Now perhaps that’s because I’m re-reading Neal Stephenson’s Cryptonomicon, where one of the subplots follows the exploits of Unit 2702, dedicated to ensuring that use of Ultra is explainable in other ways.

But really, it was pretty shocking to hear people nominally dedicated to the protection of systems actively working to deny themselves information that might help them detect an intrusion faster and more effectively.

For an example of how that might work, read “Protecting People on Facebook.” First, let me give kudos to Facebook for revealing an attack they didn’t have to reveal. Second, Facebook says “we flagged a suspicious domain in our corporate DNS logs.” What is a suspicious domain? It may or may not be one not seen before. More likely, it’s one that some other organization has flagged as malicious. When organizations reveal the IP or domain names of command and control servers, it gives everyone a chance to learn if they’re compromised. It can have other positive effects. Third, it reveals a detection method which actually caught a bad guy, and that you might or might not be using. Now you can consider if you want to invest in dns logging.

Now, there’s a time to be quiet during incident response. But there’s very real a tradeoff to be made between concealing your knowledge of a breach and aiding and abetting other breaches.

Maybe it’s time for us to get angry when a breach disclosure doesn’t include at least one IP and one MD5? Because when the disclosure doesn’t include those facts, our ability to defend ourselves is dramatically reduced.

Indicators of Impact — Ground Truth for Breach Impact Estimation

Ice bag might be a good Indicator of Impact for a night of excess. — Ice bag might be a good ‘Indicator of Impact’ for a night of excess.

One big problem with existing methods for estimating breach impact is the lack of credibility and reliability of the evidence behind the numbers. This is especially true if the breach is recent or if most of the information is not available publicly. What if we had solid evidence to use in breach impact estimation? This leads to the idea of “Indicators of Impact” to provide ‘ground truth’ for the estimation process.

It is premised on the view that breach impact is best measured by the costs or resources associated with response, recovery, and restoration actions taken by the affected stakeholders. These activities can included both routine incident response and also more rare activities. (See our paper for more.) This leads to to ‘Indicators of Impact’, which are evidence of the existence or non-existence of these activities. Here’s a definition (p 23 of our paper):

An ‘Indicator of Impact’ is an observable event, behavior, action, state change, or communication that signifies that the breached or affected organizations are attempting to respond, recover, restore, rebuild, or reposition because they believe they have been harmed. For our purposes, Indicators of Impact are evidence that can be used to estimate branching activity models of breach impact, either the structure of the model or key parameters associated with specific activity types. In principle, every Indicator of Impact is observable by someone, though maybe not outside the breached organization.

Of course, there is a close parallel to the now-widely-accepted idea of “Indicators of Compromise“, which are basically technical traces associated with a breach event. There’s a community supporting an open exchange format — OpenIoC. The big difference is that Indicators of Compromise are technical and are used almost exclusively in tactical information security. In contrast, Indicators of Impact are business-oriented, even if they involve InfoSec activities, and are used primarily for management decisions.

From the Appendix B, here are a few examples:

Was there a forensic investigation, above and beyond what your organization would normally do?
Was this incident escalated to the executive level (VP or above), requiring them to make resource decisions or to spend money?
Was any significant business process or function disrupted for a significant amount of time?
Due to the breach, did the breached organization fail to meet any contractual obligations with it customers, suppliers, or partners? If so, were contractual penalties imposed?
Were top executives or the Board significantly diverted by the breach and aftermath, such that other important matters did not receive sufficient attention?

The list goes on for three pages in Appendix B but we fully expect it to grow much longer as we get experience and other people start participating. For example, there will be indicators that only apply to certain industries or organization types. In my opinion, there is no reason to have a canonical list or a highly structured taxonomy.

As signals, the Indicators of Impact are not perfect, nor do they individually provide sufficient evidence. However, they have the very great benefit of being empirical, subject to documentation and validation, and potentially observable in many instances, even outside of InfoSec breach events. In other words, they provide a ‘ground truth’ which has been sorely lacking in breach impact estimation. When assembled as a mass of evidence and using appropriate inference and reasoning methods (e.g. see this great book), Indicators of Impact could provide the foundation for robust breach impact estimation.

There are also applications beyond breach impact estimation. For example, they could be used in resilience planning and preparation. They could also be used as part of information sharing in critical infrastructure to provide context for other information regarding threats, attacks, etc. (See this video of a Shmoocon session for a great panel discussion regarding challenges and opportunities regarding information sharing.)

Fairly soon, it would be good to define a light-weight standard format for Indicators of Impact, possibly as an extension to VERIS. I also think that Indicators of Impact could be a good addition to the up-coming NIST Cybersecurity Framework. There’s a public meeting April 3rd, and I might fly out for it. But I will submit to the NIST RFI.

Your thoughts and comments?

New paper: "How Bad Is It? — A Branching Activity Model for Breach Impact Estimation"

Adam just posted a question about CEO “willingness to pay” (WTP) to avoid bad publicity regarding a breach event. As it happens, we just submitted a paper to Workshop on the Economics of Information Security (WEIS) that proposes a breach impact estimation method that might apply to Adam’s question. We use the WTP approach in a specific way, by posing this question to all affected stakeholders:

“Ex ante, how much would you be willing to spend on response and recovery for a breach of a particular type? Through what specific activities and processes?”

We hope this approach can bridge theoretical and empirical research, and also professional practice. We also hope that this method can be used in public disclosures.

Paper: How Bad is it? – A Branching Activity Model to Estimate the Impact of Information Security Breaches

Infographic from the example in the paper

In the next few months we will be applying this to half a dozen historical breach episodes to see how it works out. This model will also probably find its way into my dissertation as “substrate”. The dissertation focus is on social learning and institutional innovation.

Comments and feedback are most welcome.

Paying for Privacy: Enterprise Breach Edition

We all know how companies don’t want to be named after a breach. Here’s a random question: how much is that worth to a CEO? What would a given organization be willing to pay to keep its name out of the press? (A-priori, with at best a prediction of how the press will react.) Please don’t say a lot, please help me quantify it.

Another way to ask this question: What should a business be willing to pay to not report a security breach?

(Bonus question: how is it changing over time?)

HHS & Breach Disclosure

There’s good analysis at “HHS breach investigations badly backlogged, leaving us in the dark”

To say that I am frequently frustrated by HHS’s “breach tool” would be an understatement. Their reporting form and coding often makes it impossible to know – simply by looking at their entries – what type of breach occurred. Consider this description from one of their entries:

“Theft, Unauthorized Access/Disclosure”,”Laptop, Computer, Network Server, Email”

So what happened there? What was stolen? Everything? And what types of patient information were involved?

Or how about this description:

“Unauthorized Access/Disclosure,Paper”

What happened there? Did a mailing expose SSN in the mailing labels or did an employee obtain and share patients’ information with others for a tax refund fraud scheme? Your guess is as good as mine. And HHS’s breach tool does not include any data type fields that might let us know whether patients’ SSN, Medicare numbers, diagnoses, or other information were involved.

What can I say but, I agree?

Disclosures should talk about the incident and the data. Organizations are paying the PR cost, let’s start learning.

The incident should be specified using either the Broad Street taxonomy (covered in the MS Security Intel Report here) or Veris. It would be helpful to include details like the social engineering mail used (so we can study tactics), and detection rates for the malware, from something like VirusTotal.

For the data, it would be useful to explain (as Dissent says) what was taken. This isn’t simply a matter of general analysis, but can be used for consumer protection. For example, if you use knowledge-based backup authentication, then knowing that every taxpayer in South Carolina has had their addresses exposed tells you something about the efficacy of a question about what address you lived in in 2000. (I don’t know if that data was exposed in the SC tax breach, I’m just picking a recent example.)

Anyway, the post is worth reading, and the question of how we learn from breaches is worth discussing in depth.

New York Times gets Pwned, Responds all New School

So there’s a New York Times front page story on how “Hackers in China Attacked The Times for Last 4 Months.”

I just listened to the NPR story with Nicole Perlroth, who closed out saying:

“Of course, no company wants to come forward and voluntarily say `hey we were hacked by China, here’s how it happened, here’s what they took’ because they’re probably scared of what it will do to their stock price or their reputation. In this case, what was interesting was that it was my own employer that had been hacked. We felt that it was very important to come out with this and say ‘this is how easy it is for them to break into any US company and here’s how they’re doing it. [Link added.]

On Twitter, Pete Lindstrom suggested that “seems they are highlighting successes, not woes.” Zooko suggested several things including “perhaps since it is news, the NYT is happy to print it, because *any* news sells papers?” and “Or is this a cultural change, where people stop attempting trying to secure their perimeter and hiding their failure to do so?”

Me, I believe it’s culture change, but am aware of the risk of confirmation bias. When I think back to 2008, I think the peanut gallery would have been pointing and giggling, and I think we’re over that.

Thoughts?