CSE 825 Computer and Network Security

(1)

CSE 825

Computer and Network Security

Dr. Richard Enbody

Computer Science & Engineering Michigan State University

(2)

2

My goal is to warp your mind:

If you leave this class with a diﬀerent 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 oﬀ the cliﬀ 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

(3)

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.

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 suﬃcient knowledge of computer systems to be able to understand the esoteric details of intrusion

(4)

4

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.

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.

(5)

Past Topics – this year??

•  Man in the Middle

•  Buﬀer Overﬂow

•  SQL Injec]on

•  XSS

•  Protocol exploita]on: FTP, RDP, SSH

•  Fuzzing

•  Propose one of your own.

All input is evil un]l proven otherwise. -‐-‐ Howard & LeBlac

(6)

6

Prerequisites

•  CSE 410 (Opera]ng Systems) and

CSE 422 (Networks) or equivalents

•  If you have not taken the prerequisites,

it will be diﬃcult to do well in the class.

Text

Free online

Security Engineering 2nd_{Edi]on
by
Anderson}

hdp://www.cl.cam.ac.uk/~rja14/book.html

(7)

Contact

•  Instructor: Dr. Richard J. Enbody

•  Instructor's Oﬃce: EB 3145

•  Oﬃce Hours: A_er class

and by appointment •  Email: [email protected]

•  Phone: (517) 353-‐3389

Grading

5% Classroom Par]cipa]on

50% Team Project (presenta]on + writeup + assignment) 20% Homework

(8)

8

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.

Outline

1.  Cover general security principles (Exam) 2.  Student Demonstra]ons

3.  Homework

(9)

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

Homework

Exercises on team projects,

(10)

10

Plagiarism

•  Plagiarism is unacceptable and

will result in a zero grade for the course.

•  While the deﬁni]on of plagiarism

is broader than this:

if you use “copy-‐and-‐paste” without referencing, that certainly is plagiarism.

•  Note that if you can ﬁnd it, so can I.

Two Fewer Mondays

•  Sept. 7 is Labor Day, no class

•  Sept. 28, I am out of town (ABET)

(11)

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.

“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 ﬁnd

(12)

12

Trust

•  Trust Boundary

•  It always ends up with trust.

Threat Models

(13)

Willie Sutton

When asked

“Why do you rob banks?” He replied:

“That is where the money is.”

(14)

14

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.

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 ﬁles. Thou shalt not use a computer to steal.

Thou shalt not use a computer to bear false witness.

(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.

Ten Security Principles

•  by various folk

(16)

16

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.

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.

(17)

Principle 3: Secure failure

Avoid security problems related to failures. When systems fail in any way, they should not revert to insecure behavior.

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

(18)

18

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.

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.

(19)

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 ﬁgure out how to break in.

Principle 8:

It's hard to hide secrets

It's incredibly diﬃcult 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

(20)

20

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.

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.

(21)

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.

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.

(22)

22

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.

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,

3.  If a bad guy has unrestricted physical access to your computer,

(23)

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.

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.

(24)

24

Ten General Security Rules

(

www.albion.com/security

)

1.  Security Through Obscurity Doesn't Work 2.  Full Disclosure of Bugs and Holes

Beneﬁts 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

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

(25)

Anderson:Chapter 1

•  Terminology

•  Hard: “It is important for the security

engineer to develop sensi]vity about the diﬀerent nuances of meaning the common words acquire in diﬀerent applica]ons, and to be able to formalize what the security policy and target actually are.”

Anderson:Chapter 3

Protocols: “If security engineering has a

unifying theme, it is the study of security protocols.”

(26)

26

Notation

T

→

G : T, {T,N}_KT

Think “LHS : RHS”

LHS is “T sends to G”

RHS is “what is sent”

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.”}

(27)

Formal Methods

“Some history exists of ﬂaws being found in

protocols that had been proved correct using formal methods…”

Problems

External assump]ons.

Real world vs. idealiza]on of protocol

Formally Verified & Broken

•  hdp://www.cse.msu.edu/~enbody/ overﬂow.htm

•  1987 paper by Young and Mchugh:

"Coding for a Believable Speciﬁca]on to Implementa]on Mapping"

(28)

28

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