Download Computer Security Introduction, Lecture Notes - Computer Science and more Study notes Computer Security in PDF only on Docsity!
CS 161 Computer Security
Fall 2005 Joseph/Tygar/Vazirani/Wagner Notes 1
1 The scope of this class
Our goal in this class is to teach you the some of the most important and useful ideas in computer security. By the end of this course, we hope you will have learned:
- How to build secure systems. You’ll learn techniques for designing, implementing, and maintaining secure systems.
- How to evaluate the security of systems. Suppose someone hands you a system they built. How do you tell whether their system is any good? We’ll teach you how systems have failed in the past, how attackers break into systems in real life, and how to tell whether a given system is likely to be secure.
- How to communicate securely. We’ll teach you some selections from the science of cryptogra- phy, which studies how several parties can communicate securely over an insecure communications medium.
Computer security is a broad field, that touches on almost every aspect of computer science. We hope you’ll enjoy the scenery along the way.
What is computer security? Computer security is about computing in the presence of an adversary. One might say that the defining characteristic of the field, the lead character in the play, is the adversary. Re- liability, robustness, and fault tolerance are about how to deal with Mother Nature, with random failures; in contrast, security is about dealing with actions instigated by a knowledgeable attacker who is dedicated to causing you harm. Security is about surviving malice, and not just mischance. Whereever there is an adversary, there is a computer security problem.
Adversaries are all around us. The Code Red worm infected a quarter of a million computers in less than a week, and contained a time-bomb set to try to take down the White House web server on a specific date. Fortunately, the attack on the White House was diverted—but one research company is estimating the worm cost $2 billion in lost productivity and in cleaning up the mess caused by infected machines. One company estimated that viruses cost businesses over $50 billion in 2003. Hackers armed with zombie networks of tens of thousands of compromised machines sell their services brazenly, promising to take down a competitor’s website for a few thousand dollars. It’s been estimated that, as of 2005, at least a million computers worldwide have been penetrated and “owned” by malicious parties; many are used to send massive amounts of spam or make money through phishing and identity fraud. Studies suggest that something like half of all spam is sent by such zombie networks. It’s a racket, and it pays well—the perpetrators are raking in money fast enough that they don’t need a day job. How are we supposed to secure our machines when there are folks like this out there? That’s the subject of this class.
2 It’s all about the adversary
The early history of computer security is interwoven with military applications (probably because the mil- itary were one of the first big users of computers, and the first to worry seriously about the potential for misuse), so it should not be surprising that much of the terminology has military connotations. We speak of an attacker who is trying to attack computer systems, of defenders working to protect their system from these threats , and so on. Well, you get the idea.
It might be surprising that we are going to spend so much time studying attackers and thinking about how to break into systems. Aren’t the attackers the bad guys? Why on earth would we want to spread knowledge that will help bad guys be more effective?
Part of the answer is that you have to know how your system is going to be attacked, if you want to defend it properly. Civil engineers need to learn what makes bridges fall down if they want to have any chance of building a bridge that will stay standing. Software engineering is no different; you need to know how systems fail in real life, if you want to have the best chance of building a system that will resist attack. This means you’d better know what kinds of attacks you are likely to face in the field. And, because attacks change and get better with time, you’d better learn to anticipate the attacks of the future.
While learning about recent history is certainly a good start, it’s not enough to learn only about attacks that have been used in the past. Attackers are intelligent (or some of them are, anyway). If you deploy a new defense, they will respond. If you build a new system, they will try to find its weak points and attack there. Attackers adapt. This means that we have to find ways to anticipate what kinds of attacks might be mounted against us in the future.
Security is like a game of chess, only it is one where the attackers often get the last move. We design a system, and then it is very hard to change once it has been deployed. If attackers find a security hole in a widely deployed system, the consequences can be pretty serious. Therefore, we’d better learn to predict in advance what the attackers might do to us, so that we can eliminate all the security holes before the system is deployed. We have to practice thinking like an attacker, so that we will know in advance how secure the system is.
Thinking like an attacker is not always easy. Sometimes it can be a lot of fun to try to outwit the system, like a game. Other times, it can be disconcerting to think about what could go wrong and who could get hurt, and that’s not fun at all.
What happens if you don’t anticipate how you may be attacked? The cellphone industry knows the answer. In the 1980’s, they designed and deployed an analog cellphone infrastructure with essentially no security measures; cellphones transmitted all their billing information in the clear, and security rested on the assump- tion that attackers wouldn’t bother to put together the equipment to intercept it. That assumption held for a while, but sooner or later criminals were bound to catch on, and they did. Technically savvy attackers built “black boxes” that intercepted the radio communications and cloned phones, and criminals used these to make fraudulent calls en masse and to mount call-selling operations for profit. Cellphone operators were unprepared for this, and in the early 90’s, it had gotten so bad that the US cellphone carriers were losing more than $1 billion per year. At one point I was told that 70% of the long-distance cellphone calls placed from downtown Oakland on a Friday night were fraudulent. By this point the cellphone service providers were already well aware that they had a serious problem, but because it takes 5–10 years and a great deal of capital to replace the deployed infrastructure of cellular base stations, they were in a difficult position. This illustrates how failing to anticipate how your system might be attacked—or underestimating the threat—can be a costly mistake.
It is for these reasons that security design requires the study of attacks. Security experts spend a lot of time
their capabilities, motivations, and limitations. For instance, in the Cold War, the US military was oriented towards its main enemy, the Soviets, and a lot of effort was put into understanding the military capabilities of the USSR (how many battalions of infantry do they have? how effective are their tanks? how quickly can their navy respond to such-and-such threat?). When we know what adversary we will be facing, we can craft a threat model using that knowledge, so that our threat model reflects what that particular adversary is likely to do to us and nothing more.
However, all too often the adversary is not known. In this case, we need to reason more generically about unavoidable limitations that will be placed upon the adversary. As a light-hearted example, physics tells us that the adversary can’t go faster than the speed of light—I don’t care who they are, they can’t violate the rules of physics. That might be useful to know. More usefully, we can usually look at the design of the system and identify what things an adversary might be in a position to do. For instance, if the system is designed so that secret information is never sent over a wireless network, then we don’t need to worry about the threat of eavesdropping upon the wireless communications. If our system design is such that people might discuss our secrets by phone, we had better include in our threat model the possibility that an insider at the phone company might be able to eavesdrop on our phone calls, or re-route them to the wrong place, or fool people into thinking they are talking with someone legitimate when actually they are speaking with the attacker.
A good threat model also specifies what threats we do not care to defend against. For instance, if I want to analyze the security of my home against burglary, I am not going to worry about the threat that a team of burglars might fly a helicopter over my house and rappel down my chimney to get into the house, Mission Impossible style. There are far easier ways to break into my house, without going to all that trouble.
One can often classify adversaries according to their motivation. For instance, consider adversaries who are motivated by financial gain. It’s a pretty safe bet that a financially-motivated adversary is not going to spend more money on the attack than they stand to gain from it. For instance, no burglar is likely to spend thousands of dollars to steal my car radio; my car radio is simply not worth that much. In general, motives are as varied as human nature, and it is a good idea to be prepared for all eventualities.
It’s often very helpful to look at the incentives of the various parties. This is probably a familiar principle. Does the local fast food joint make more profit on soft drinks than on the food? Then one might expect some fast food places to take steps to boost sales of soft drinks, perhaps salting its french fries heavily. Do customer service representatives make a bonus if they handle more than a certain number of calls per hour? Then one might expect some representatives to be tempted to cut lengthy service calls short, or to transfer trouble customers to other departments when possible. Do spammers make money from everyone who responds to the spam, while losing nothing from those who didn’t wish to receive the spam? Then one can expect that some spammers might be inclined to send their emails as widely as possible, no matter how unpopular it makes them. As a rule of thumb, organizations tend not to act against their own self-interest, at least not too often. Incentives influence behavior—not always, of course, but frequently enough to help illuminate the motivations of potential adversaries.
Incentives are particularly relevant when two parties have opposing interests. When incentives clash, conflict often follows. In this case it is worth looking deeply at the potential for attacks by one such party against the other.
If threat assessment sounds difficult, just remember the three W’s: Who? How? Why? In other words: Who are the adversaries we might face? How might they try to attack us, and what are their capabilities? Why might they be motivated to attack us, and what are their incentives?
Finally, once we have the security goals and a threat model, the last step is to perform a security analysis. The goal of the security analysis is to see whether there is any attack encompassed within the threat model
that can successfully violate the security goals. Security analysis is often highly technical and depends on the details of the particular system being analyzed. We will show you many methods for security analysis in the rest of the course, without saying more now.
An analogy: The security goals and threat model defines the game, and the security analysis amounts to figuring out who can win the game. The threat model defines the set of moves the adversary is allowed to make, and the design of the system defines how the defender will play the game. The security goals define the success condition: if the adversary violates any security goal, he wins; otherwise, the defender wins. The security analysis involves examining all moves and counter-moves to see who has a winning strategy.
Another analogy: Mystery writers like to talk about means, motive, and opportunity. That’s not a bad way of thinking about what we do during a security evaluation. The threat assessment examines the means and motive; the security analysis examines what opportunity the adversary might have to do harm.
To sum up, evaluating the security of a system involves three steps:
- Identify the security goals. What are we trying to protect?
- Perform a threat assessment. What threats does the system need to protect against?
- Do a security analysis. Can we envision any feasible attack that would violate the security goals? This is the place where it can get pretty technical.
The same process can be used for designing new systems. The security goals and threat assessment is especially relevant to system design, since it is usually easier to ensure security when you know what security goals you are trying to achieve and what threats you must protect against. And, as we perform our security analysis, we can refine the system design to defend against each new attack we discover.
4 An example
Enough slogans. Let’s do an example. Let’s analyze the security of my home against intruders.
What are my security goals? I’d like to protect the assets in my home from theft or from being tampered with by unauthorized parties (integrity). I’d like my personal safety to be protected; for instance, if someone does break in to steal money, I’d much prefer to know, so that I don’t surprise them and get shot. I’d like my house and its contents to remain in full working order whenever I want them (availability). My home is my castle, and I sometimes want a certain measure of privacy when I’m home (confidentiality). We could probably identify other security goals, but that’s more than enough to get us started.
Time for the threat assessment. Who am I trying to protect against, and how might they be motivated? A burglar might be motivated by financial gain. A peeping Tom might be motivated by curiousity. Someone who holds a grudge against me might want to secretly get revenge. And so on.
What capabilities (tools, skills, knowledge, access, etc.) might an adversary have? What threats might I face? A burglar might have lockpicks and the know-how to use them, or a crowbar to smash in the door, or the capability to cut my phone lines. A repairman might have unaccompanied access to the house for a time. Peepers might have binoculars or a telescope. One of my neighbors might have line-of-sight to my living room window, while another might be blocked by trees. But there are probably some kinds of threats I’m willing to ignore. For instance, I’m not worried that the Navy ships here for Fleet Day are going to start shelling my house. My house has no effective way to defend against such an attack, but I doubt very much that any officer dislikes me enough to throw away his career over it. We could go on for pages, assessing
