Pew should evolve its cybersecurity survey

Pew should evolve the questions they are asking and the advice they are giving based on how the threat environment is changing. But they should keep asking.

Last year, Pew Research surveyed just over 1,000 people to try to get a feel for how informed they are about cybersecurity. That’s a great idea because it informs us as a society as to how well consumers are able to defend themselves against common attacks. Let’s consider some ways that this survey could be evolved, and how consumers can mitigate certain common risks. Keep in mind that Pew conducted the survey in June of last year in a fast changing world.

Several of the questions related to phishing, Wifi access points and VPNs. VPNs have been in the news recently because of the Trump administration’s and Congress’ backtracking on privacy protections. While privacy invasion by service providers is a serious problem, accessing one’s bank at an open access point is probably considerably less so. There are two reasons for this. First, banks almost all make use of TLS to protect communications. Attempts to fake bank sites by intercepting communications will, at the very least produce a warning that browser manufacturers have made increasingly difficult to bypass. Second, many financial institutions make use of apps in mobile devices that take some care to validate that the user is actually talking to their service. In this way, these apps actually mark a significant reduction in phishing risk. Yes, the implication is that using a laptop with a web browser is a slightly riskier means to access your bank than the app it likely provides, and yes, there’s a question hiding there for Pew in its survey.

Another question on the survey refers to password quality. While this is something of a problem, there are two bigger problems hiding that consumers should understand:

Reuse of passwords. Consumers will often reuse passwords simply because it’s hard to remember many of them. Worse, many password managers themselves have had vulnerabilities. Why not? It’s like the apocryphal Willie Sutton quote about robbing banks because that’s where the money is. Still, with numerous break-ins, such as those that occurred with Yahoo! last year^*, and the others that have surely gone unreported or unnoticed, re-use of passwords is a very dangerous practice.
Aggregation of trust in smart phones. As recent articles about American Customs and Border Patrol demanding access to smart phones demonstrate, access to many services such as Facebook, Twitter, and email can be gained just by gaining access to the phone. Worse, because SMS and email are often used to reset user passwords, access to the phone itself typically means easy access to most consumer services.

One final area that requires coverage: as the two followers of my blog are keenly aware, IoT presents a whole new class of risk that Pew has yet to address in its survey.

The risks I mention were not well understood as early as five years ago. But now they are, and they have been for at least the last several years. Pew should keep surveying, and keep informing everyone, but they should also evolve the questions they are asking and the advice they are giving.

^* Those who show disdain toward Yahoo! may find they themselves live in an enormous glass house.

Krebs attacked: IoT devices blamed, and MUD could help

Cybercrime It’s rare that hackers give you a gift, but last week that’s exactly what happened. Brian Krebs is one of the foremost security experts in the industry, and his well known web site krebsonsecurity.com was brought down due to a distributed denial of service (DDoS) attack. Attackers made use of what is said to be the largest botnet ever to attack Akamai, Kreb’s content service provider.

Why would one consider this a gift? First of all, nobody was hurt. This attack took down a web site that is not critical to anyone’s survival, not even Krebs’, and the web site was rehomed and back online in a very short period of time.

Second, the attackers revealed at least some of their capabilities by lighting up the network of hacked devices for researchers to examine and eventually take town. One aspect of this attack is the use of “IoT” devices, or non-general purpose computers that are used to control some other function. According to Krebs, the attacks made use of thermostats, web cameras, digital video recorders (DVRs) and, yes, Internet routers. The attacks themselves created an HTTP connection to the web site, retrieved a page, and closed. That’s a resource intensive attack from the defense standpoint.

Let’s ask this question: why would any of those systems normally talk to anything other than a small number of cloud services that are intended to support them? This is what Manufacturer Usage Descriptions (MUD) is meant to defend against. MUD works by providing a formal language and mechanism for manufacturers to specify which systems a device is designed to connect with. The converse, therefore, is that the network can prevent the device from both being attacked and attacking others. The key to all of this are manufacturer and their willingness to describe these devices. The evolving technical details of MUD can be found in an Internet Draft, and you can create a test MUD file against that draft by using MUD File Maker. I’ll go into more detail about MUD File Maker in a later post.

Would MUD eliminate all attacks? No, but MUD adds an additional helpful layer of protection to those manufacturers and networks should use.

This time it was a blog that was taken down. We are in a position to reduce attacks the next time, when they may be more serious. That’s the gift hackers gave us this time. Now we just need to act.

What’s a “State-Sponsored Actor”?

Yahoo! [Updated thanks to an old friend.]

In Yahoo!’s announcement of the theft of 500 million accounts, the Chief Information Security Officer Bob Lord wrote that the company believes a “state-sponsored actor” was behind the attack. What does that mean and how would Yahoo! come to this conclusion?

The term “state-sponsored” is vague. It could means someone who works for a government, or it could mean someone who has in effect been contracted out by a government. Both Russia and China have been accused of this sort of behavior in the past. In the case of Russia, there are two well known hacking organizations, Cozy Bear and Fancy Bear that the Washington Post previously reported were involved in the cyberattack against the Democratic National Committee’s systems. In the case of China, the Elderwood Group was accused of taking part in a successful phishing attack against His Holiness, the Dalai Lama.

But why does Yahoo! believe that the culprit is one of these groups and not any other hacker? There are several possibilities:

Perhaps the botnet systems used used to gain access to the Yahoo! passwords were the same as those used in an earlier attack in which a state-sponsored actor was known to be involved; or
The code used to break into Yahoo!’s internal network was the same or similar to code used in an earlier attack that is known to be from one of these groups; or
The investigation has been able to determine where the control systems of an attack are and who is accessing them.
As my friend points out, governments aren’t in this for the money but for some other purpose. That means that stolen information isn’t likely to hit the black market anytime soon. In this case, by the time Yahoo! discovered the problem, the breach was two years old.

Finding proof beyond a reasonable doubt will be difficult. Consider this: it is possible for the Chinese to make use of a botnet run in Russia or America, or for America to operate a botnet in China to attack systems in Russia, just to lend the appearance as to who the source is, without revealing who the actual source is.

The only fundamental solution to this sort of attack is better end system security. Only when botnets have dried up can we establish the true source of attacks. Maybe in my lifetime this will happen. Maybe. But that means a lot of people have to do a lot of work.

The Yahoo! Breach: What it means to you

Steps you should take after the Yahoo! breach.

yahoo Yesterday, 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:

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.
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.
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.
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.
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!
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.
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:

Banks must perform annual risk assessments and penetration tests;
New York’s Department of Financial Services (DFS) must be notified within 72 hours of an incident (there are currently numerous timeframes);
Banks must use 2-factor authentication for employee access; and
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.