Yahoo! This will happen again

Yahoo!The breach of over 500 million accounts at Yahoo! has caused a number of my friends to deride the company for not applying sufficient protections of private consumer data.  While it’s hard to argue with that claim, one thing is certain: this will happen again.  Maybe not to Yahoo! but to some other giant web site, like Amazon or Facebook or Google or Twitter.

We have concentrated so much trust into so small a percentage of sites that if any one of them has a breach, it can impact hundreds of millions of people.  Americans have previously spoken of banks that are too big to fail.  Social networking sites are similarly so big that when they have an incident, it perturbs our lives in all sorts of ways that we only begin to understand after the fact.

These sites have an interest in maintaining their customer interest, and the network effect helps them: the more people who visit Facebook, the more people Facebook will attract.  This is how the Internet and telephone networks came to be in the first place.

This vast concentration of consumers into a small number of sites also has its upsides: because they are regularly attacked, they have developed very strong expertise to fend off bad guys.  That’s something the average consumer – and even most enterprises – will never have.

This form of market concentration is not an easy problem to solve.  Imagine a world in which we all had software that sat on in our homes instead of in Facebook’s cloud (for instance).  If the software were all the same, then one bug would impact everyone in much the same way as if the software were centrally located.  The only question is how long it would take for an exploit of a vulnerability to propagate, and how long it would take someone to notice.

We know that such distributed software is a problem because one of the key vectors for infection these days is unused and out of date virtual machines or WordPress instances.  This puts aside all the issues of cost of maintaining a WordPress site.  How much does it cost you to maintain your Facebook account today?

One approach would a healthy exchange of social information across a reasonable number (perhaps in the thousands) of well managed sites.  That requires a rethink about how we consider privacy and who is responsible.  It also requires that incentives be aligned for that sharing to occur.  We would in essence be suggesting that Facebook advertisers go elsewhere.  That doesn’t seem like something Facebook would want to see.

The Yahoo! Breach: What it means to you

Steps you should take after the Yahoo! breach.

yahooYesterday, Yahoo! announced that at least 500 million accounts have been breached.  This means that information you gave Yahoo! may be in the hands of hackers, but it could also mean a lot more. The New York Times has an excellent interactive tool today that demonstrates how much of your information may have leaked, not just from Yahoo! but from other breaches.

Not only should people change their Yahoo! passwords, but it is also important for people to review all passwords and information shared with Yahoo!  In particular:

  1. Many people use the same password across multiple accounts.  If you did this, you should change passwords on all systems where that password was used.  When you do, you should see to it that no passwords are shared between two systems.
  2. Hackers are smart.  If you only tweak the same password just a little bit for use on multiple systems, a determined hacker or more likely a determined script may well break into other accounts.  For example, if your Yahoo! password was DogCatY! and your E-Bay Password were DogCatEBay, you should assume the E-Bay account is broken as well.
  3. This means you should keep a secure record of what passwords are used where, for just this sort of eventuality.  By “secure” I mean encrypted and local.  Having two pristine USB keys (one for backup) is ideal, where the contents are encrypted at the application layer.  I also make use of Firefox’s password manager.  That in itself is a risk, because if Firefox is hacked your passwords may be gone as well.
  4. Unfortunately passwords may not be the only information hackers have. Yahoo! has previously made use of so-called “backup security questions”.  Not only is it important to disable those questions, but it is important to first review them to see where else you may have used them.  Security questions are a horrible idea for many reasons: they may reveal private aspects of your life, much of which might be discovered anyway.  Sites like United Airlines recently implemented security questions.  My recommendation: choose random answers and record them in a secure place that is separate from your passwords.
  5. It is possible that hackers may have read any email you received on Yahoo!  In particular, one should review any financial accounts where information is transmitted to Yahoo!
  6. Use of cloud-based storage as a backup for your passwords should be viewed with great suspicion.  There have been a number of such tools that themselves have been found to be vulnerable.
  7. Hackers may have your cell phone number, for those who use SMS as secondary authentication.  While SMS is not secure communication, the chances of it being hacked are relatively low.  The safest practice is not to rely solely on SMS for authentication.  My bank uses both a secret and an SMS message, relying on the tried and true two-factor authentication approach of something you have and something you know.  A better solution is a secret and an app with a secure push notification.  This is what MasterCard has done in Europe.

These suggestions are good for the sort of mass breach that we are seeing with Yahoo!  In addition, one has to be careful with the amount of trust placed in a cell phone.  If the phone is lost, you should assume that hackers will be able to get into it.  Keeping a record of the applications you use, particularly those that have financial or security implications, will help you recover from the loss.

These suggestions are written with the notion that Yahoo! is not going to be the only site that will have had this problem.  Although not to this scale, we’ve seen this sort of thing before, and we will see it again.  I’ll have more to say about this from an industry perspective in a while.


Yahoo picture by Sebastian Bergmann – originally posted to Flickr as Yahoo!, CC BY-SA 2.0

Will New NY Banking Regulations Actually Tighten Cybersecurity?

Proposed New York banking regulations might not help that much.

New York is proposing new cybersecurity rules that would raise the bar for banks over which they have jurisdiction (wouldn’t that be just about all of them?).  On their face, the new regulations would seem to improve overall bank posture, but digging a bit deeper leads me to conclude that these regulations require a bit of work.

A few key new aspects of the new rules are as follows:

  1. Banks must perform annual risk assessments and penetration tests;
  2. New York’s Department of Financial Services (DFS) must be notified within 72 hours of an incident (there are currently numerous timeframes);
  3. Banks must use 2-factor authentication for employee access; and
  4. All non-public data must be encrypted, both in flight and at rest.

The first item on that list is what Chief Information Security Officers (CISOs) already get paid to do.  Risk assessment is in particular the most important task on this list, because as banks evolve their service offerings, they must ascertain both evolving threats and potential losses.  For example, as banks added iPhone apps, the risk of an iPhone being stolen became relevant, thus impacting app design.

Notification laws exist already in just about all jurisdictions.  The proposed banking regulation does not say what the regulator will do with the information or how it will be safeguarded.  A premature release can harm ongoing investigations.

Most modern banks outside the United States already use two-factor authentication for employee access, and many require two-factor authentication for customer access.

That last one is a big deal.  Encrypting data in flight (e.g., transmissions from one computer to another) protects against eavesdroppers.  At the same time, absent other controls, encryption can obscure data exfiltration (information theft). Banks currently have many tools that rely on certain transmissions being “in the clear”, and it may require some redesign of communication paths to address both the encryption in flight requirement and auditing needs.  Some information is simply impractical today to encrypt in flight.  This includes discovery protocols such as DHCP, name service exchanges (DNS), and certain other network functions.  To encrypt much of this information would require yet lower layer protection such as IEEE 802.1AE (MACSEC) hop-by-hop encryption.  The regulation is, again, vague on precisely what is necessary.  One thing is clear, however: their definition of non-public information is quite broad.

To meet the “data at rest” requirement banks will either have to employ low level disk encryption or higher level object-level encryption.  Low level encryption protects against someone stealing a disk or taking it from the trash and reading it, but provides very little protection against someone breaking into a computer when the disk is still spinning.  Moreover, banks generally have rules about crushing disks before they can leave a data center.  Requiring data at rest to be encrypted in data centers may not provide much risk mitigation.  While missing laptops have repeatedly been a source data breaches, how often has a missing data center disk caused a breach?

Object-level encryption, or the encryption of groups of information elements (think Email messages) can provide strong protection should devices be broken into.  Object-level encryption is particularly interesting because if done right, it can address both data in flight and data at rest.  The challenge with object-level encryption is that the tools for it are quite limited.  While there are some tools such as email message encryption, and while there are various ways one can use existing general purpose mechanisms such as OpenSSL to encrypt objects at rest, on object-level encryption remains a challenge because it must be implemented at the application level across all applications.  Banks may have tens of thousands of applications running at any one time.

This is an instance where the financial industry could be a technology leader.  However, all such development must be grounded in a proper risk assessment.  Otherwise we end up in a situation where banks will have expended enormous amounts of resources without having substantially improved security.

Looming wireless problems with IoT security

Security experts have two common laments:

  • Security is an afterthought, and
  • Security is hard to get right.

No place else has this been more true than in wireless security, where it took the better part of two decades to get us to where we are today.  “Wireless” can mean many different things.  It could mean 3G cellular service or Wifi or Bluetooth or something else.  In the context of Wifi, we have standards such as WPA Personal and WPA Enterprise that were developed at the IEEE.  Similarly, 3GPP has developed secure access standards for your phone through the use of a SIM card.  With either WPA Enterprise or 3G, you can bet that if your device starts to misbehave, it can be uniquely identified.

Unfortunately that’s not so much the case with other wireless standards, and in particular for IEEE’s 802.15.4, where security has for the time being been largely left to higher layers.  And that’s just fine if what we’re talking about is your Bluetooth keyboard.  But it’s not fine at all if we’re talking large number of devices, where one of them is misbehaving.

mesh-insecurity

Here we have a lighting network.  It might consist of many different light bulbs.  Maybe hundreds.  Now imagine a bad guy breaking into one of those devices and attacking the others.  Spot the bad guy.  In a wired world, assuming you have access to the switch, you can spot the device simply by looking at which port a connection came into.  But this is wireless, and mesh wireless at that.  In the case where each device has its own unique key, you can trace per session per device.  But if all devices use a shared key, you need to find other means.  A well hacked device isn’t going to give you many clues; it’s going to try to mimic a device that isn’t hacked, perhaps one that isn’t turned on or one that doesn’t even exist.

These attacks can be varied in nature.  If the mesh is connected to other networks, like enterprise networks, then attacks can be aimed at resources on those networks.  This might range from a form of a so-called “Snow Shoe” attack, where no one device generates a lot of traffic but the aggregate of hacked devices overwhelm a target, to something more destructive, like attempts to reconfigure critical infrastructure.

Some attacks aren’t even intended as such, as Raul Rojas discovered in 2009, when a single light bulb took down his IoT-enabled house.

What to do?

The most obvious thing to do is not to get into this situation in the first place.  From a traceability standpoint, network managers need to be able to identify the source of attacks.  Having unique wireless sessions between leaf and non-leaf nodes that are bound to source addresses is ideal.  Alternatively, all communications in a mesh could tunnel to non-leaf nodes that have strong diagnostic capabilities, like IPFIX and port spanning.  At that point administrators can at least log traffic to determine the source of attacks.  That’s a tall order for a light bulb, but it’s why companies like Cisco exist- to protect your infrastructure.

If none of these alternatives exist, poor network administrators (who might just be home owners like Mr. Rojas)  are forced into a position where they might need to consider the entire mesh a single misbehaving device, and disconnect it from the network.  And even that might not do the job: a smart piece of malware might notice and quiet itself until it can determine that the mesh has been re-connected.

Some careful thought is required as these capabilities develop.

Comey and Adult Conversations About Encryption

What does an adult conversation over encryption look like? To start we need to understand what Mr. Comey is seeking. Then we can talk about the risks.

AP and others are reporting that FBI director James Comey has asked for “an adult conversation about encryption.” As I’ve previously opined, we need just such a dialog between policy makers, the technical community, and the law enforcement community, so that the technical community has a clear understanding of what it is that investigators really want, and policy makers and law enforcement have a clear understanding of the limits of technology.  At the moment, however, it cannot be about give and take.  Just as no one cannot legislate that π = 3, no one can legislate that lawful intercept can be done in a perfectly secure way.  Mr. Comey’s comments do not quite seem to grasp that notion.  At the same time, some in the technical community do not want to give policy makers to even evaluate the risks for themselves.  We have recently seen stories of the government stockpiling malware kits.  This should not be too surprising, given that at the moment there are few alternatives to accomplish their goals (whatever they are).

So where to start?  It would be helpful to have from Mr. Comey and friends a concise statement as to what access they believe they need, and what problem they think they are solving with that access.  Throughout All of This, such a statement has been conspicuous in its absence.  In its place we have seen sweeping assertions about grand bargains involving the Fourth Amendment.  We need to be specific about what the actual demand from the LI community is before we can have those sorts of debates.  Does Mr. Comey want to be able to crack traffic on the wire?  Does he want access to end user devices?  Does he want access to data that has been encrypted in the cloud?  It would be helpful for him to clarify.

Once we have such a statement, the technical community can provide a view as to what the risks of various mechanisms to accomplish policy goals are.  We’ve assuredly been around the block on this a few times.  The law enforcement community will never obtain a perfect solution.  They may not need perfection.  So what’s good enough for them and what is safe enough for the Internet?  How can we implement such a mechanism in a global context?  And how would the mechanism be abused by adversaries?

The devil is assuredly in the details.