Week 3 Studio: Microsoft Email Breach
In the last few weeks or so, it has come to light that Microsoft has suffered from a rather bad breach. The short version is that hackers – most likely employed by the Russian government – were able to break into Microsoft’s email servers and read the email of most of Microsoft’s “senior leadership team” (aka executives) and numerous other employees also.
For today’s case, please read the following brief news articles:
- News article summarizing the breach: WSJ
- Another article with more technical details: ArsTechnica
- Embarrassing detail that just recently became public: ArsTechnica
- New-ish policy issue related to this breach: WSJ
For today, we are going to analyze this case study from Microsoft.
This is a real life situation, and has a lot of the complexity of real life. Today, we are going to practice taking this incident apart and trying to understand it, starting with the news articles linked above. By taking it apart in this structured way, it will help us to learn how to see these parts of incidents in the future. We have a number of goals for today to try to understand what happened here: 1) map out the set of people involved in this cybersecurity incident; 2) describe what actions people took that led to this incident; 3) try to understand the motivations of the people involved, and why they acted the way they did; 4) identify connections between actors; and 5) see what we might do differently in the future to prevent this.
The people involved (the actors)
First, we are going to identify the “actors” – the people who did things in this incident that are somehow important to the outcome. For this first step, go through the report and try to identify all of the actors. Actors are frequently people. If there is a person who is specified by name, they are probably an actor. We also often see actors identified by some role – e.g. this person is the CISO.
Actors can also be groups of people who share a common role and motivation. Sometimes a group of people will all work together to accomplish a common role, and generally share a common motivation. For example, “the police” might be an actor that is a group of people who all want to stop crime and respond to incidents. Or, “the Russian GRU” might be an actor that tries to attack specific groups. Sometimes groups like this have a name. Often (especially for attackers), we don’t know exactly who it was, so we make up a name (like “Fancy Bear”) for them.
As you go through this report, try to identify all of the actors. Many of them will have names that you can identify. Some of them will be groups, some will be individuals. If all of the people in a group have the same role and the same motivation
For each actor, you should create an actor worksheet. Put the name of the actor (or something you can use to identify the actor) on the line at the top of the page. Create one worksheet for each actor you identify. If you are working on paper, use a separate sheet for each actor. If you choose to work electronically, then create a new copy of the file for each actor.
Role(s) they play
Next, for each actor, try to identify the role or roles that the actor played in this cybersecurity incident. All cybersecurity incidents have attackers, victims, and defenders. Who was doing the attack, and who was being attacked?
But there are more roles than just that; there are accomplices that help the attackers, ancillary victims that are harmed somehow but were not directly attacked, incident responders who respond to attacks, etc.
Each actor plays at least one role, but sometimes they play more than one. Sometimes a victim is also a defender (they are responsible for defending themselves, but were attacked anyway), and sometimes the victim and defender are two different people. Also, many incidents have multiple actors playing each role; there can be more than one victim, and more than one defender, and even more than one attacker.
Start by deciding whether a person is an attacker or is being attacked (aka a good guy or a bad guy). This is the main distinction, and it is very rare to find someone who is both.
If you decide the actor is an attacker, then ask yourself whether they are responsible for the actual attack, or whether they are just helping out someone else who is responsible for the attack.
If you decide the actor is under attack, then start by trying to figure out whether they are a victim or a defender. A victim is someone who is harmed by the attack. Most attacks have a main victim who is directly attacked by the attacker – the intended target of the attack, who bears the brunt of the attacks. Some attacks also have ancillary victims – people who are also harmed in some way, but were not the intended target of the attacker.
Defenders are people who are responsible for preventing the attack. We often “blame the victim” – that is, we expect that the victim should have prevented the attack in some way. That’s OK if that is the situation, but often, it is the responsibility of someone else to do the protection. For example, in many large companies, it is the responsibility of a group of IT security professionals to pretect the company from cyberattack, even though the attack might target an individual in the company.
Finally, another type of defender is an incident responder. This is someone whose role is to investigate what happened, try to stop any ongoing harm that is happening, and possibly identify who did it and how to fix any problems that happened. For traditional crimes, police detectives are incident responders. For cybercrime, many large companies have professional incident responders who work with the company to deal with cybersecurity incidents as they happen.
The actions they took
Next, go through each actor, and write down any and all actions they took related to this attack. Be as specific as you can; details matter here. Don’t just say “they did the attack”; instead say “they used an exploit in Microsoft Word that they reverse enginneered from a patch to break into a computer that is currently unused but used to be used to store sensitive compnay data.”
The goal here is to be as specific as you can about what happened in this incident. We are trying to trace what happened, and details matter. We want to be able to notice when things don’t line up, or when we have pieces of the incident that are missing. To do that, we need to be specific about what we DO know about the actions.
Notice that the actions are all on a page for each actor. We are trying to identify WHAT each person (or group) did as part of this incident. This is important; I want you to recognize that cybersecurity incidents don’t just happen. Instead, it is people who do them, and people who try to stop them, and understanding who those people are and why they are behave the way they do is important.
You should have at least one action for each actor. Many actors will probably have multiple actions; when this happens, try to list the actions in chronological order if possible.
The motivations for those actions
Now this is where it gets interesting. Our next step is to try to identify motivations for actions. Why did this actor take these specific actions? If we want to really understand these cybersecurity incidents and why they happen the way that they do, we need to understand why people are acting the way that they are. Why was the attacker doing this attack? What were they hoping to gain? Why wasn’t the defender able to stop the attack?
To do this, we need to identify motivations. For each actor, go through the case report and try to see if you can identify what was motivating them to take the actions they did.
This is key: don’t guess. If you aren’t sure, then say “don’t know” or “unspecified”. But try really hard to identify motivations. It is OK to take things in the news articles at face value. If an attacker asks for money as part of the attack, it is reasonable to assume that their motivation was to make money (a financial motivation). Sometimes, actor’s motivations will be stated explicitly in the case report.
Don’t guess, but it is OK to make inferences based on evidence. Sometimes, you can piece together motivations from their actions. That’s OK, but be really careful to make sure you have evidence for the motivation. In particular, inferences should not be based on a stereotype or guess about what people like them usually want. If the motivation you write down follows a stereotype, which it often will because stereotypes exist for a reason, be sure that you have evidence that this particular actor actually has that motivation. And in my experience, it is almost never a good idea to infer that someone is stupid or an idiot or didn’t know something; cybersecurity has a lot of tradeoffs being made by professionals and experts, and few people are idiots. Additionally, “being an idiot” isn’t a motivation; even idiots have their reasons.
As you think about motivations, I encourage you to think about hypothetical alternative actions. What else could this person (or group) have done differently? Why didn’t they do it that way? For example, if a person left a computer unpatched, they could have installed the patch. Why didn’t they? What motivation did they have for not installing that patch? Thinking about hypothetical alternative actions help us to be more specific about motivations, and recognize the gaps in our thinking. For each action or motivation, try to identify one or more hypothetical alternatives, and see if the motivation you wrote down helps explain why they choose the action that they did, and not the hypothetical alternative action.
Understanding motivations is a great way to understand cybersecurity incidents. By looking at people’s motivations, you begin to understand why the incident happened. What gaps exist that were available to be exploited by the attacker, and why those gaps exist. Much of the rest of the semester will be spent looking more closely at different motivations and the challenges assocaited with them.
Connections: The expectations of others
I hope you found it interesting and enlightening to think through the motivations of the people involved. We have one more thing to think about: how these actors and motivations relate to each other. These are the connections between people.
For this case study, we are going to focus on expectations: when one person expects another person to do something or not do something (or, at least, hopes that they will do or not do that something). People have all kinds of expectations of each other. When an hacker steals credit card data, he usually expects to be able to sell it. Microsoft IT Security may expect employees to keep your computer patched, or to run anti-virus on your computer. These expectations form the relationships that people have in our incident. Imagine drawing lines between your sheets of paper; these are the connections.
For each actor, try to identify any connections they have in the form of expectations. On the back of each physical sheet for each actor (or the 2nd page for those working electronically), there is a place where you can specify expectations. These come in the form of a sentence that you can fill in: “This actor hopes/expects ___ to do ___”. The first blank is where you should put name of the other actor that they have an expectation of. The second blank is there you should put what they expect.
Many of these expectation will be fairly mundane and boring, but it is worth writing them down. If possible, it is great if you have evidence from the case report for these expectations, but that is somewhat rare. Try to do the best you can to specify these.
Preventing this in the future
OK, at this point, you’ve taken this 7 page case report, and broken it down and analyzed it in all kinds of ways. Hopefully you have a better idea of what happened, and why it happened, than you would have if you had just read the report.
As you worked, I hope you’ve got some ideas about why this happened the way that it did. Now, stop and take a step back. What can we do to prevent this attack from happening again in the future? Now that one attacker has successfully done this attack (though they didn’t get paid this time), other attackers know what to do to try again.
Grab a blank sheet of paper (or open a new word file if working electronically), and try to write down ideas for what Microsoft should do differently so that this attack, and attacks like it in the future, don’t happen again. Be specific for these ideas: for each idea, identify WHO should do something different, WHAT they should do differently, and WHY they should do it differently. If possible, try to figure out whether this new action would fit in with their existing motivations that you already identified.
As you work, try hard to avoid the “ignorance assumption”. Don’t just assume that people don’t know that this could happen, and that by telling them it can happen, they will automatically want to stop it. For example, don’t just say “the IT people shouldn’t leave their test account open to the public”. That is assuming that the IT people are simply ignorant of the possible attack, and that if they knew about the possibility of attack, they would patch it. Look at your motivations; there are reasons that they didn’t disable the account that are more complicated than simply that they didn’t know. If you don’t address the underlying motivations, then they may disable particular account, but are likely to leave the next account enabled and unprotected for the same reasons that this one was left enabled. The ignorance assumption is really common in cybersecurity, but it is dangerous and leads to all kinds of bad advice and repeat attacks.