The role of the CISO and the Equifax Breach

CISOs don’t eliminate risk- they help companies manage it. Equifax made poor choices as a company. The CISO was ineffective.

 

I do not know Susan Mauldin, the now-former Chief Security Officer of Equifax, nor can I even tell you what her job was.  That is because the role of Chief Information Security Officer (CISO) remains ill-defined: each company implements the role in different ways and has different expectations.  It may well be that this person did not have the authority to implement policies that would have prevented the breach that revealed records of over 143 million US consumers.

What I can say is this:

The only way you can entirely secure a computer is to destroy it and melt down its components beyond the point that any recovery tool can glean information.  Otherwise, there is always some security risk.  You might be able to sufficiently secure a system such that the risk is so low as to be almost negligible, but to do that usually requires more resources than it will cost to mitigate a breach.

The goal of a CISO is to reduce the expected loss of a security breach to a level acceptable to the management.  Expected loss has many components.  It can include direct financial losses, losses in sales, reputation loss (and thereby future sales losses), stolen IPR, thus impacting product differentiation, and liability associated with stolen customer and partner information.  In a world where information is worth its weight in gold, holding any information secret means that there is a risk it will be revealed.  The decisions of a CISO or her management do not amount to loss due to a single event, but may be recurring losses, either due to expenses to mitigate risk or due to losses from breaches.

Equifax’s business is information about consumers.  That means that they must retain the information necessary to report their findings to their customers, such as banks or employers who are assessing the trustworthiness of an individual.  That can be a lot of information, such as credit card, mortgage, and utility payment histories.  Equifax is a big fat target for information thieves, much the same way the US Office of Personnel Management is (they were breached in 2014).

It has been reported that the information thieves in this case made use of a vulnerability in Apache Struts that had been announced in March.  Equifax stated that they detected anomalous behavior on the 29th of July.  That left a period of roughly four months of exposure. In the grand scheme of things, this is not a long long time for an exposure.  However, because the value of information that was at risk was actually quite high, and because the vulnerability in question was exploitable on the open Internet, there should have been a process in place to rapidly close the bug.  There exist any number of patch management tools that spot open source software updates, and alert the customer.

Should Susan Mauldin have known all of this?  Yes.  Did she?  I don’t know.  Did she have the authority to effect change?  I don’t know, but to be sure she was ineffective because the necessary processes were not in place.  Will this sort of failure happen again?  You can bet on it, but when and how much the loss will be is where CISOs make their money.

Addressing the Department Gap in IoT Security

People in departments outside of IT aren’t paid to understand IT security. In the world of IoT, we need to make it easy for those people to do the right thing.

So, Mr. IT professional, you suffer from your colleagues at work connecting all sorts of crap to your network that you’ve never heard of?  You’re not alone.  As more and more devices hit the network, the ability to maintain control can often prove challenging.  Here are your choices for dealing with miscreant devices:

  1. Prohibit them and enforce the prohibition by firing anyone who attaches an unauthorized device.
  2. Allow them and suffer.
  3. Prohibit them but not enforce the prohibition.
  4. Provide an onboarding and approval process.

A bunch of companies I work with generally aim for 1 and end up with 3.  A bunch of administrators recognize the situation and fit into 2.  Everyone I talk to wants to find a way to scale 4, but nobody has, as of yet.  What does 4 involve?  Today, it means an IT person researching a given device, determining what networking requirements it has, creating firewall rules, and some associated policies, and establishing an approval mechanism for a device to connect.

This problem is exacerbated by the fact that many different enterprise departments have wide and varied needs, and the network stands as critical to many of them.  Furthermore, very few of those departments reports through the chief information officer, and chief information security officers often lack the attention their concerns receive.

I would claim that the problem is that incentives are not well aligned, were people in other departments even aware of the IT person’s concerns in the first place, and often they are not.  The person responsible for providing vending machines just wants to get the vending machines hooked up, while the person in charge of facilities just wants the lights to come on and the temperature to be correct.

What we know from hard experience is that the best way to address this sort of misalignment is to make it easy for everyone to do the right thing. What, then, is the right thing?

Prerequisites

It has been important pretty much forever for enterprises to be able to maintain an inventory of devices that connect to their networks.  This can be tied into the DHCP infrastructure or to the device authentication infrastructure.  Many such systems exist, the simplest of which is Active Directory.  Some are passive and snoop the network.  The key point is simply this: you can’t authorize a system if you can’t remember it.  In order to remember it, the device itself needs to have some sort of unique identifier.  In the simplest case, this is a MAC address.

Ask device manufacturers to help

Manufacturers need to make your life easier by providing you a description what the device’s communication requirements are.  The best way to do this is with Manufacturer Usage Descriptions (MUD).  When MUD is used, your network management system can retrieve a recommendation from the manufacturer, and then you can approve, modify, or refuse a policy.  By doing this, you don’t have to go searching all over random web sites.

Have a simple and accessible user interface for people to use

Once in place you now have a nice system that encourages the right thing to happen, without other departments having to do anything other than to identify the devices they want to connect.  That could be as simple as a picture of a QR code or otherwise entering a serial #.  The easier we can make it for people who know nothing about networking, the better all our lives will be.

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.

Yet another IoT bug

Miele could have benefited from MUD, as well as the experience of the Internet security community.

The Register is reporting a new IoT bug involving Miele PG 8528 professional dishwashers, used in hospitals and elsewhere.  In this case, it is a directory traversal bug involving an HTTP server that resides on port 80.  In all likelihood, the most harm this vulnerability will directly cause is that the dishwasher would run when it shouldn’t.  However, the indirect risk is that the device could be used to exfiltrate private information about patients and staff.  The vulnerability is reported here.

Manufacturers expect that it will be very simple to provide Internet services on their devices.  To them, initially, they think that it’s fine to slap a transceiver and a simple stack on a device and they’re finished.  They’re not.  They need to correct vulnerabilities such as this one.  They apparently have no mechanism to do so.  Manufacturers such as Miele are experts within their domains, such as building dishwashers.  They are not experts in Internet security.  It is a new world when these two domains intersect.

We need MUD

And yes, Manufacturer Usage Descriptions would have helped here, by restricting communication either to all local devices or to specifically authorized devices.

MUD sliding along

Your chance to try and chime in on Manufacturer Usage Descriptions, a way to protect IoT devices.

You may recall that I am working on a mechanism known as Manufacturer Usage Descriptions (MUD).  This is the system by which manufacturers can inform the network about how best to protect their products.  The draft for this work is now about to enter “working group last call” at the IETF.  This means that now would be a very good time for people to chime in with their views on the subject.

In the meantime, MUD Maker has also been coming along. This is a tool that generates manufacturer usage descriptions.  You can find the tool here.

MUD isn’t meant to be the whole enchilada of IoT security.  Other tools are needed to authenticate devices onto the network, and to securely update them.  And manufacturers have to take seriously not only their customers’ needs, but what risk they may impose on others, as Mirai reminded us.  Had MUD been around at the time, it’s possible that Mirai would not have happened.