Jan 7, 2014 ... "Only those who dare to fail greatly can ever achieve greatly.” — Robert F.
Kennedy. • "I can accept failure. Everybody fails at something.
9/8/15
CSE 825 Computer and Network Security Dr. Richard Enbody Computer Science & Engineering Michigan State University
Dr. Enbody
Computer Science & Engineering
1
9/8/15
My goal is to warp your mind: If you leave this class with a different way of looking at the world around you, I will have succeeded.
Computer Science & Engineering
3
Risk • "If things seem under control, you are just not going fast enough.” —Mario AndreK • "Living at risk is jumping off the cliff and building your wings on the way down.” — Ray Bradbury • "Only those who dare to fail greatly can ever achieve greatly.” — Robert F. Kennedy • "I can accept failure. Everybody fails at something. But I can't accept not trying. Fear is an illusion.” -‐-‐ Michael Jordan • "You'll always miss 100% of the shots you don't take.” -‐-‐ Wayne Gretzky Computer Science & Engineering
4
2
9/8/15
Computer Security is too broad a topic. I know only a small part. This course is not a “sage on the stage,” but rather a collabora]on among all of us.
Computer Science & Engineering
5
Overview In this course we will inves]gate the broad topic of CyberSecurity with an emphasis on studying intrusions & intrusion detec]on, and building secure so_ware to prevent intrusions. Since new intrusions occur regularly, we will also inves]gate new intrusions as they occur. Since intrusions are o_en based on small cracks in computer systems, students will be expected to have sufficient knowledge of computer systems to be able to understand the esoteric details of intrusion techniques.
Computer Science & Engineering
6
3
9/8/15
Project One of the goals of this class will be to gain some hands-‐on experience with how adacks are done—something I consider necessary for understanding how to defend against them. To accomplish this experience students will work in teams of four on a par]cular adack, and this will be a major project as a major component of the grade.
Computer Science & Engineering
7
Project continued The most important and hardest part of the project is crea]ng an assignment for the rest of the class: everyone must do every exploit.
Computer Science & Engineering
8
4
9/8/15
Past Topics – this year?? • • • • • • •
Man in the Middle Buffer Overflow SQL Injec]on XSS Protocol exploita]on: FTP, RDP, SSH Fuzzing Propose one of your own.
Computer Science & Engineering
9
All input is evil un]l proven otherwise. -‐-‐ Howard & LeBlac
Computer Science & Engineering
10
5
9/8/15
Prerequisites • CSE 410 (Opera]ng Systems) and CSE 422 (Networks) or equivalents • If you have not taken the prerequisites, it will be difficult to do well in the class.
Computer Science & Engineering
11
Text Free online Security Engineering 2nd Edi]on by Anderson hdp://www.cl.cam.ac.uk/~rja14/book.html
Computer Science & Engineering
12
6
9/8/15
Contact • Instructor: Dr. Richard J. Enbody • Instructor's Office: EB 3145 • Office Hours: A_er class and by appointment • Email:
[email protected] • Phone: (517) 353-‐3389
Computer Science & Engineering
13
Grading 5% Classroom Par]cipa]on 50% Team Project (presenta]on + writeup + assignment) 20% Homework 25% Exam
Computer Science & Engineering
14
7
9/8/15
Grading Course grade: 93% and above is a 4.0; 85% -‐ 92% is a 3.5; 80% -‐ 84% is a 3.0; 75% -‐ 79% is a 2.5, etc.
Computer Science & Engineering
15
Outline 1. Cover general security principles (Exam) 2. Student Demonstra]ons 3. Homework
Computer Science & Engineering
16
8
9/8/15
Teams • 4-‐person teams for project • You choose your team • Send me email by January 18 lis]ng the team members and an ordered list of preferred projects
Computer Science & Engineering
17
Homework Exercises on team projects, i.e. everyone does each technique.
Computer Science & Engineering
18
9
9/8/15
Plagiarism • Plagiarism is unacceptable and will result in a zero grade for the course. • While the defini]on of plagiarism is broader than this: if you use “copy-‐and-‐paste” without referencing, that certainly is plagiarism. • Note that if you can find it, so can I.
Computer Science & Engineering
19
Two Fewer Mondays • Sept. 7 is Labor Day, no class • Sept. 28, I am out of town (ABET)
Computer Science & Engineering
20
10
9/8/15
plus ça change, plus c'est la même chose The more things change, the more they stay the same. The Internet is simply a new medium. see The S]ng.
Computer Science & Engineering
21
“You can fool some of the people all of the ]me, and all of the people some of the ]me, but you cannot fool all of the people all of the ]me.” -‐-‐Abraham Lincoln The Internet makes it easy to find “some of the people all of the -me”
Computer Science & Engineering
22
11
9/8/15
Trust • Trust Boundary • It always ends up with trust.
Computer Science & Engineering
23
Threat Models
Computer Science & Engineering
24
12
9/8/15
Willie Sutton When asked “Why do you rob banks?” He replied: “That is where the money is.”
Computer Science & Engineering
25
Most Lucrative Theft?
Computer Science & Engineering
26
13
9/8/15
Scott Charney hdps://www.youtube.com/v/bTt_h-‐F1ETQ? version=3&start=190&end=2291&autoplay=0&hl=en_US&rel=0 30 min.
Computer Science & Engineering
27
Ten Commandments of Computer Ethics (Computer Ethics Institute) Thou shalt not use a computer to harm other people. Thou shalt not interfere with other people's computer work. Thou shalt not snoop around in other people's computer files. Thou shalt not use a computer to steal. Thou shalt not use a computer to bear false witness.
Computer Science & Engineering
28
14
9/8/15
Ten Commandments (cont’d) Thou shalt not copy or use proprietary so_ware for which you have not paid. Thou shalt not use other people's computer resources without authoriza]on or proper compensa]on. Thou shalt not appropriate other people's intellectual output. Thou shalt think about the social consequences of the program you are wri]ng or the system you are designing. Thou shalt always use a computer in ways that insure considera]on and respect for your fellow human being.
Computer Science & Engineering
29
Ten Security Principles • by various folk • IBM, MS, Albion
Computer Science & Engineering
30
15
9/8/15
Principle 1: Least privilege. The principle of least privilege states that only the minimum access necessary to perform an opera]on should be granted, and that access should be granted only for the minimum amount of ]me necessary.
Computer Science & Engineering
31
Principle 2: Defense in depth. The idea behind defense in depth is to manage risk with mul]ple defensive strategies, so that if one layer of defense turns out to be inadequate, another layer of defense will, ideally, prevent a full breach.
Computer Science & Engineering
32
16
9/8/15
Principle 3: Secure failure Avoid security problems related to failures. When systems fail in any way, they should not revert to insecure behavior.
Computer Science & Engineering
33
Principle 4: Secure the weakest link Security is a chain; a system is only as secure as the weakest link. One consequence is that the weakest parts of your system are the parts most suscep]ble to adack.
Computer Science & Engineering
34
17
9/8/15
Principle 5: Compartmentalization The basic idea behind compartmentaliza-on is that we can minimize the amount of damage that can be done to a system, if we break the system up into as many isolated units as possible.
Computer Science & Engineering
35
Principle 6: Simplicity The KISS mantra -‐-‐ "Keep it simple, stupid!". Complexity increases the risk of problems; this seems unavoidable in any system. Your designs and implementa]ons should be as straigh~orward as possible.
Computer Science & Engineering
36
18
9/8/15
Principle 7: Promote privacy Users generally consider privacy a security concern. You shouldn't do anything that could compromise the privacy of the user. And you should be as diligent as possible in protec]ng any personal informa]on that a user gives you. You can quickly lose the respect of your customers, if they think you handle privacy concerns poorly. Services on your machine tend to give informa]on about themselves that can help the adacker figure out how to break in. Computer Science & Engineering
37
Principle 8: It's hard to hide secrets It's incredibly difficult to keep the "secrets" secret. The most common threat to companies is the "insider" adack, where a disgruntled employee abuses access. It pays to be paranoid. "Security by obscurity" : whenever possible, you should avoid using this as your sole line of defense.
Computer Science & Engineering
38
19
9/8/15
Principle 9: Don't extend trust easily Be reluctant to trust your own servers, in case they get hacked. You should also be reluctant to trust yourself and your organiza]on. There have been tons of products from security vendors with gaping security holes.
Computer Science & Engineering
39
Principle 10: Trust the community Repeated use without failure promotes trust. Public scru]ny does as well. You get to leverage the experience of others. This principle only applies if you have reason to believe that the community is doing its part to promote the security of components you want to use.
Computer Science & Engineering
40
20
9/8/15
Ten Security Principles by Gary McGraw and John Viega 1. Least privilege: Do not give out more privileges than necessary, and do not extend privileges longer than necessary.
Computer Science & Engineering
41
Ten Security Principles (cont’d) 2. Provide defense in depth, which means you should manage so_ware risk by providing redundant security solu]ons. 3. Secure failure: Make sure that if the system could possibly fail, it will fail in a secure manner. 4. Iden]fy and reinforce the weakest link.
Computer Science & Engineering
42
21
9/8/15
Ten Security Principles (cont’d) 5. KISS: Keep it simple. 6. Privacy: Don't give out any unnecessary informa]on. 7. It's hard to hide secrets (NOT security through obscurity) 8. Don't extend trust easily. 9. Trust the community (open source) 10. Compartmentaliza-on: Try to keep failures in one part of a system from having an impact on the rest of the system. Computer Science & Engineering
43
The Ten Immutable Laws of Security by Scott Culp (MS) 1. If a bad guy can persuade you to run his program on your computer, it’s not your computer anymore. 2. If a bad guy can alter the opera]ng system on your computer, it’s not your computer anymore. 3. If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore. Computer Science & Engineering
44
22
9/8/15
Ten Immutable Laws (cont’d) 4. If you allow a bad guy to upload programs to your web site, it’s not your web site any more. 5. Weak passwords trump strong security. 6. A machine is only as secure as the administrator is trustworthy. 7. Encrypted data is only as secure as the decryp]on key.
Computer Science & Engineering
45
Ten Immutable Laws (cont’d) 8. An out of date virus scanner is only marginally beder than no virus scanner at all. 9. Absolute anonymity isn't prac]cal, in real life or on the web. 10. Technology is not a panacea.
Computer Science & Engineering
46
23
9/8/15
Ten General Security Rules (www.albion.com/security) 1. Security Through Obscurity Doesn't Work 2. Full Disclosure of Bugs and Holes Benefits Security 3. System Security Degrades in Direct Propor]on to Use 4. Do It Right Before Someone Does It Wrong For You 5. The Fear of GeKng Caught is the Beginning of Wisdom
Computer Science & Engineering
47
www.albion rules (cont’d) 6. There's Always Someone Out There Smarter, More Knowledgeable, or Beder-‐Equipped Than You 7. There Are No Turnkey Security Solu]ons 8. Good and Evil Blend into Gray 9. Think Like the Enemy 10. Trust is a Rela]ve Concept
Computer Science & Engineering
48
24
9/8/15
Anderson:Chapter 1 • Terminology • Hard: “It is important for the security engineer to develop sensi]vity about the different nuances of meaning the common words acquire in different applica]ons, and to be able to formalize what the security policy and target actually are.”
Computer Science & Engineering
49
Anderson:Chapter 3 Protocols: “If security engineering has a unifying theme, it is the study of security protocols.” “Security protocols are the rules.”
Computer Science & Engineering
50
25
9/8/15
Notation T
→ G : T, {T,N}KT
Think “LHS : RHS”
LHS is “T sends to G” RHS is “what is sent”
Computer Science & Engineering
51
Random “In fact, most of the widely used so_ware products that incorporate encryp]on – including Kerberos, Netscape, and PGP– have been broken at some ]me or another because their random-‐number generators weren’t random enough.”
Computer Science & Engineering
52
26
9/8/15
Formal Methods “Some history exists of flaws being found in protocols that had been proved correct using formal methods…” Problems External assump]ons. Real world vs. idealiza]on of protocol
Computer Science & Engineering
53
Formally Verified & Broken • hdp://www.cse.msu.edu/~enbody/ overflow.htm • 1987 paper by Young and Mchugh: "Coding for a Believable Specifica]on to Implementa]on Mapping"
Computer Science & Engineering
54
27
9/8/15
Favorite reads • Bruce Schneier hdps://www.schneier.com/ • comp.risks (since 1985) hdp://catless.ncl.ac.uk/Risks/ Read the digests • Dailydave hdps://lists.immunityinc.com/mailman/ lis]nfo/dailydave Computer Science & Engineering
55
28
