Presentation is loading. Please wait.

Presentation is loading. Please wait.

Computer Security Primer CSE 291 Fall 2005 October 5, 2005 Geoffrey M. Voelker.

Similar presentations


Presentation on theme: "Computer Security Primer CSE 291 Fall 2005 October 5, 2005 Geoffrey M. Voelker."— Presentation transcript:

1 Computer Security Primer CSE 291 Fall 2005 October 5, 2005 Geoffrey M. Voelker

2 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer2 Administrivia l Communication u Add yourself to the mailing list u Join the wiki, contribute to the discussion l Groups u Use the breaks today to start finalizing groups u Email Jeff Bigham your group info tonight u For those unassigned, we’ll match with groups on Friday l Red Team project u Exploit buffer overflow vulnerability, discuss policy implications u Overview on course page, programming details on Friday u Out Friday 10/7, due Monday 10/24

3 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer3 Today l Two goals u Overview of computer security topics u Provide context for remaining cybersecurity talks l Your opportunity to ask computer security questions u I’ve always wondered what X is… u Who knows, maybe I can answer it l Standard disclaimer u I’m not a computer security expert, but I play one on ConfXP u Channeling Steve Zdancewic, Dan Boneh, Butler Lampson, and John Mitchell via Stefan’s CSE 127 slides

4 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer4 Game Plan l Computer security issues u Identity, risks, trust, … l Basic cryptography u Encryption, authentication, … u What is the crypto behind SSL? l Stepping back: Overall system security u We have systems like SSL…why aren’t we done? l Evolution of security concerns u Why are we all in a huff about cybersecurity now? u Set the stage for future cybersecurity talks in class

5 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer5 Computer Security l Definition: The reasoning, mechanisms, policies, and procedures used to deal with someone else doing something that you don’t want them to do l There are a handful of key issues here (paraphrasing Butler Lampson) u Identity u Policy u Risks/Threats u Deterrence/Policy u Locks

6 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer6 Identity l What is it? u One def: The distinct personality of an individual regarded as a persisting entity; individuality (courtesy Black Unicorn) l Why valuable? u Unique identifier – distinguishing mark (courtesy A.S.L. von Bernhardi) u Needed to establish an assertion about reputation

7 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer7 Reputation l What is it? u A specific characteristic of trait ascribed to a person or thing: e.g., a reputation for paying promptly l Why valuable? u Potentially a predictor of behavior, a means of valuation, and as a means for third-party assessment l Issues u Reliable identifiers u Binding identity to reputation

8 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer8 Due Diligence and Trust l Due Diligence u Work to acquire multiple independent pieces of evidence establishing identity/reputation linkage; particularly via direct experience u Problem: Expensive l Trust u Reliance on something in the future; hope u Allows cheap form of due-diligence: third-party attestation u Economics of third-party attestation? Cost vs limited liability u What is a third-party qualified to attest to? u Thompson: “Trusting Trust” u “Trust” vs. “Trustworthy” (Bruce Schneier)

9 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer9 Policy l What is a bad thing? l Sometimes simple u Steve and Ed can read my files u Never execute downloaded code l Often remarkably tricky to define u There are >100 security options for IE u How should you set them?

10 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer10 Risks and Threats l Risk u What is the cost if the bad thing happens? u What is the likelihood of the bad thing happening? u What is the cost of preventing the bad thing? u Example: Visa/Mastercard fraud l Threats u Who is targeting the risk? u What are their capabilities? u What are their motivations? l These tend to be well understood/formalized in some communities (e.g., finance sector) and less in others (e.g., computer science)

11 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer11 Deterrence l There is some non-zero expectation that there is a future cost to doing a bad thing u going to jail, having a missile hit your house, having your assets siezed, etc. l Need meaningful forensic capabilities u Audit actions, assign identity to evidence, etc u Non-reputation u Must be cost effective l Again channeling Butler: “lots of good locks on the Internet, few police” u We’ll come back to this at the end

12 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer12 Locks l Mechanisms used to protect resources against threats u This is most of academic and industrial computer security u Anderson: Necessary, but not sufficient l Several classes of locks u Cryptographic u Software security u Protocol security

13 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer13  (Cryptography) l Greek for “secret writing” l Cryptographer: Invents cryptosystems l Cryptanalyst: Breaks cryptosystems l Cryptology: Study of cryptosystems l Cipher: Mechanical way of encrypting text l Code: Semantic translation u “eat breakfast tomorrow” = “attack on Thursday” PlaintextCiphertextPlaintext encryption decryption

14 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer14 Cryptographic Properties l Confidentiality u Obscure a message from eaves-droppers l Integrity u Assure recipient that the message was not altered l Authentication u Verify the identity of the source of a message l Non-repudiation u Convince a 3 rd party that what was said is accurate

15 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer15 “Secure” Cryptosystems l If enemy intercepts ciphertext, cannot recover plaintext l What else might your enemy know? u The kind of encryption function you are using u Some plaintext-ciphertext pairs from last year u Ciphertext for plaintext the enemy selected u Some information about how you choose keys l What do we mean by “cannot recover plaintext”? u Ciphertext contains no information about plaintext u No “efficient” computation could make a reasonable guess

16 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer16 Computational Security l 10,000 foot idea: not impossible to crack cipher, but very difficult to do so u Thus, an attacker with only bounded resources is extremely unlikely to crack it u Example: Assume attacker has only polynomial time, then encryption algorithm that can’t be inverted in less than exponential time is computationally secure l This is 99% of crypto u Key issue: how sure are you about difficulty? u Relies on assumptions in theoretical computer science

17 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer17 SSL Motivation l What is a secure cryptosystem that we all use daily? l Secure Socket Layer (SSL) u “Web Encryption” used to protect credit card data u Note: Compare with using credit card in real world (which is riskier?) l Use SSL to illustrate basic crypto properties

18 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer18 Shared Key Cryptography l First step: Confidentiality (protect credit card) u Shared key & public key cryptography l Sender & receiver use the same key l Key must remain private (i.e., secret) l Also called symmetric or secret key cryptography l Examples u DES, Triple-DES, Blowfish, Twofish, AES, Rijndael, …

19 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer19 Shared Key Notation l Encryption algorithm E : key x plain  cipher Notation: K{msg} = E(K, msg) l Decryption algorithm D : key x cipher  plain l D inverts E D(K, E(K, msg)) = msg l Use capital “K” for shared (secret) keys l Sometimes E is the same algorithm as D

20 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer20 Shared Keys Secure Channel K AB AliceBob K AB {Hello!}

21 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer21 Shared Keys Secure Channel K AB AliceBob K AB {Hello!} K AB {Hi!}

22 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer22 Shared Key Issues l Compromised key means interceptors can decrypt any ciphertext they have acquired u Change keys frequently to limit damage l Distribution of keys is problematic u Keys must be transmitted securely u Use couriers? u Distribute in pieces over separate channels? l Number of keys is O(n 2 ) where n is # of participants l We don’t have many “proofs” of computational security for shared key systems

23 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer23 Public Key Cryptography l Sender encrypts using a public key l Receiver decrypts using a private key l Only the private key must be kept secret u Public key can be distributed at will (still tricky, though) l Also called asymmetric cryptography l Best known example: RSA u Ron Rivest, Adi Shamir, Leonard Adleman »Proposed in 1979 »They won the 2002 Turing award for this work u Has withstood years of cryptanalysis »Not a guarantee of security… »But perhaps a strong vote of confidence

24 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer24 Public Key Notation l Encryption algorithm E : keyPub x plain  cipher Notation: K{msg} = E(K, msg) l Decryption algorithm D : keyPriv x cipher  plain Notation: k{msg} = D(k,msg) l D inverts E D(k, E(K, msg)) = msg l Use capital “K” for public keys l Use lower case “k” for private keys l Sometimes E is the same algorithm as D

25 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer25 Public Key Secure Channel K A,K B k A K A, K B k B Alice Bob K B {Hello!} K A {Hi!}

26 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer26 Public Key Crypto Pros/Cons l More computationally expensive than shared key crypto u Algorithms are harder to implement u Require more complex machinery u RSA 1000x slower than DES (hardware implementations) l More formal justification of difficulty u Hardness related to complexity-theoretic results l A principal needs one private key and one public key u Number of total keys for pair-wise communication is O(n)

27 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer27 Diffie-Hellman Key Exchange l Shared key systems are fast, but require pairwise secret key exchange l Public key systems are slow, but allow easier distribution of keys l Diffie-Hellman: Hybrid system l Idea: Use public key system to distribute shared key

28 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer28 Crypto Summary l We now have Confidentiality u Shared keys, public keys for encryption, decryption u Combine them for ease-of-use, efficiency u No one can eavesdrop and obtain credit card info l Integrity property next u How does Alice know that what she received is what Bob sent? u How does Amazon know that no one corrupted credit card info in transit?

29 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer29 Message Authentication l Issue: An attacker can reorder blocks in RSA u Decryption succeeds, but result is not what was encrypted l You want some “evidence” that a message hasn’t been changed l You’d prefer if the evidence wasn’t too expensive u To create, verify, or transmit l It should be hard to forge the evidence l The evidence should be unique

30 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer30 Cryptographic Hashes l Map variable length string into fixed length digest u Sometimes called a Message Digest l Hash functions h for cryptographic use fall in one or both of the following classes u Collision Resistant Hash Function (unique): It should be computationally infeasible to find two distinct inputs that hash to a common value (i.e., h(x) = h(y) )  One Way Hash Function (unforgeable): Given a specific hash value y, it should be computationally infeasible to find an input x such that h(x)=y l Examples u Secure Hash Algorithm (SHA) u Message Digest (MD4, MD5)

31 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer31 Cryptographic Hash Uses l Modification Detection Codes (MDC) u Compute and store hash (securely) of some data u Check later by recomputing hash and comparing u Has this file been tampered with? u Has this message stream been altered? l Message Authentication Code (MAC) u Cryptographically keyed hash function u Send (msg, hash(msg, key)) u Attacker who doesn’t know the key can’t modify msg (or the hash) u Receiver who knows key can verify origin of message

32 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer32 Crypto Summary l Confidentiality u Shared keys, public keys for encryption, decryption u Combine them for ease-of-use, efficiency u Credit card is private l Integrity u Keyed hash (MAC) authenticates message u Credit card not corrupted l Authentication next u How does Alice know that she is actually talking with Bob? u Are you actually sending your credit card to Amazon?

33 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer33 Signatures l Consider a paper check used to transfer money from one person to another l Signature confirms authenticity u Only legitimate signer can produce signature (true?) l In case of alleged forgery u 3 rd party can verify authenticity (maybe?) l Checks are cancelled u So they can’t be reused l Checks are not alterable u Or alterations are easily detected

34 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer34 Digital Signatures l Only one principal can make, others can easily recognize l Unforgeable u If P signs a message M with signature S{P,M} it is impossible for any other principal to produce the pair (M, S{P,M}) l Authentic u If R receives the pair (M, S{P,M}) purportedly from P, R can check that the signature really is from P l Not alterable u After being transmitted, (M,S{P,M}) cannot be changed by P, R, or an interceptor l Not reusable u Duplicate messages will be detected by the recipient

35 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer35 Digital Signatures Using Public Keys l Opposite from normal use as cipher u Let K A be Alice’s public key u Let k A be her private key u To sign msg, Alice sends D(msg, k A ) u Bob can verify the message with Alice’s public key l Assumes encryption algorithm is commutative u D(E(M, K), k) = E(D(M, k), K) u RSA is commutative

36 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer36 Digital Signatures Using Public Keys k A, K A, K B AliceBob k A {msg} k B, K B, K A l Authenticity: Only Alice has k A l Non-repudiation: Bob can keep msg, k A {msg}, which only Alice could produce

37 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer37 Variations l Timestamps (to prevent replay) u Signed certificate valid for only some time. l Add an extra layer of encryption to guarantee confidentiality u Alice sends K B {k A {msg}} to Bob l Combined with hashes for performance u Send (msg, k A {hash(msg)})

38 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer38 Authentication Protocols l How do A and B convince each other that they are each A and B? u Despite the fact that A and B are paranoid l Cryptographic authentication protocols u Participants can detect cheating, cannot dispute outcome u Resilient to attackers u Attacks: Replay, impersonation, usurpation, man-in-the- middle, transferability… u Techniques: nonces, sequence numbers, timestamps…

39 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer39 Crypto Summary l Confidentiality u Shared keys, public keys for encryption, decryption u Combine them for ease-of-use, efficiency l Integrity u Keyed hash (MAC) authenticates message (efficient) l Authentication u Digital signatures authenticate participants u Non-repudiation, too (log signed messages) u We know we’re talking with Amazon (almost) and can prove it l Subtle problem, though… u These properties are for keys, not identities!

40 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer40 Key Establishment l How do we establish a trusted binding between keys and identities? (That the key is Bob’s key?) u Goes back to initial issues of identity, reputation, and trust l Bilateral out-of-band: Meet, exchange secret key l Centralized 3 rd party: Trusted party gives secret keys u Needham-Schroeder, Kerberos l Hierarchical: 3 rd party public key crypto u PKI, SSL l Distributed: Chained trust for public key crypto u PGP l Anarchistic: Variety of options u SSH

41 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer41 Public Key Infrastructures l Trusted third party, Certification Authority (CA), binds authentication data to a public key: Certificate l The PKI Certificate X.509 u Structured message with: »Public key »Identifier(s) »Lifetime u Digitally signed by a trusted third party l Certification Authority (CA) u Binds identifiers to a public key u Expected to perform some amount of due diligence before vouching for this binding u Popular CA’s: Verisign, Thawte

42 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer42 Crypto Summary l You now know the crypto basics behind SSL u Client contacts server u Server identifies itself (digital signature) and provides certificate to client u Client authenticates certificate (server public key) with CA u Client validates certificate u If valid, client uses server public key to encrypt random session key (shared key) and sends to server u Client and server use session key to encrypt communication (protect your credit card number) l Note: Server does not authenticate client u Why might this be ok? Why might it be a problem?

43 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer43 Overall System Security l We have successful cryptosystems like SSL, so what’s the problem? l Clearly, appropriate use of cryptography is essential u Even that is hard to get right (frequently problems are with implementations) l …but even if cryptography is used appropriately, there are still plenty of possible vulnerabilities u 85% of CERT vulnerabilities could not be prevented with cryptography

44 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer44 When Is a System Secure? l Claim: Perfect security does not exist u Security vulnerabilities are the result of violating an assumption about the software (or, more generally, the entire system) u Corollary: As long as you make assumptions, you’re vulnerable. u And: You always need to make assumptions! (or else your software is useless and slow)

45 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer45 What Can You Assume? l Eavesdropping on light from CRTs (Kuhn) l Light emitted by CRT is u Video signal combined with phosphor response l Can use fast photosensor to separate signal from HF components of light l Even if reflected off diffuse surface (wall)

46 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer46 Source Signal

47 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer47 Bounced Off a Wall

48 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer48 Practical Security l Anderson: “Designers focused on what could possibly go wrong, rather than on what was likely to” u Not all threats are equal: What are the attacks being used? u Need data (tough, no one wants to admit it) u 2001: First published report of Denial-of-Service activity u 2001–today: Worms (hard to deny their existence…) l Lampson: “The best is the enemy of the good” u Doing nothing until a perfect solution found is a bad idea »Especially since nothing is perfect…back to risk assessment u “I can think of a way to break your system” u IDS, worm defense, buffer overflow defense all have flaws u But we still want them

49 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer49 Kinds of Attacks l Direct attacks u Attacks against the cryptosystem »e.g., timing attacks on SSL (Brumley and Boneh) u Typically requires high expertise l Indirect attacks u Attacks on assumptions (light bouncing off walls) u Attacking interface to system, identity u Anderson: “most security failures are due to implementation and management errors” »Management of keys, usability of system »Buffer overflow, format string attacks u May not require much expertise

50 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer50 Identity, Reputation, Trust l When using SSL, who are you trusting? u Ultimately, that Verisign did due diligence u You are trusting Verisign’s reputation to do the right thing u How do you know Verisign did? l Establishing identity to a cyptosystem u User authentication is critical

51 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer51 Authenticating Humans l Need to securely authenticate people into systems u If you get the keys, cryptosystem doesn’t know differently l Authentication is based on one or more of the following: l Something you know u Password l Something you have u Driver’s license l Something inherent about you u Biometrics (fingerprint, retinal, voice, face), location

52 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer52 Text Passwords l Shared code/phrase l Client sends to authenticate l Simple, right? l How do you… u Establish them to begin with? u Stop them from leaking? u Stop them from being guessed? l Brute force attacks can frequently break passwords

53 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer53 Usability l No one wants security u Not the user, programmer, service, or attacker l If security is burdensome to use, will be bypassed u Windows: always run with Administrator privileges u Anderson: “products are so complex and tricky to use that they are rarely used properly” u Whitten: users cannot encrypt mail (6 th generation product) u Even password management a hassle l Even the most secure system is defenseless if people do not use it correctly, or bypass altogether u Clicking on executables in email

54 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer54 Implementation Attacks l Most common implementation attack is buffer overflow u 50% of all CERT incidents related to these l Assumption (by programmer) that the data will fit in a limited-size buffer l This leads to a vulnerability: Supply data that is too big for the buffer (thereby violating the assumptions) l This vulnerability can be exploited to subvert the entire programming model u i.e., execute arbitrary code l You will do precisely this in the Red Team project

55 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer55 Why CyberSecurity Now? l Ever since the first computer we have had security u Why are we all in an uproar now?

56 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer56 Why CyberSecurity Now? l Ever since the first computer we have had security u Why are we all in an uproar now? u Transformation of threats and capabilities

57 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer57 Problem: Internet Succeeded l Large, homogeneous software base u 300 million Internet hosts (7/04) u 80% run same OS family (Windows) l Software vulnerabilities u Software is complex and it has bugs (weekly security updates) l High-performance network (unrestricted connectivity) u Low latency: 16ms to UCB, 28ms to UW, 80ms to MIT u High bandwidth: UCSD has a multi-gigabit Internet connection »DSL and cable increasingly replacing dialup l Incentives u Bragging, delinquency, anger, profit, terror u No deterrence: easy to do, difficult to get caught

58 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer58 The Threat Landscape (courtesy David Aucsmith) National Interest Personal Gain Personal Fame Curiosity Script-Kiddy Hobbyist Hacker Expert Specialist Vandal

59 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer59 The Threat Landscape (courtesy David Aucsmith) Author National Interest Personal Gain Personal Fame Curiosity Script-Kiddy Hobbyist Hacker Expert Specialist Vandal Spy Trespasser

60 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer60 The Threat Landscape (courtesy David Aucsmith) Author National Interest Personal Gain Personal Fame Curiosity Script-Kiddy Hobbyist Hacker Expert Specialist Vandal Spy Trespasser

61 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer61 The Threat Landscape (courtesy David Aucsmith) Author National Interest Personal Gain Personal Fame Curiosity Script-Kiddy Hobbyist Hacker Expert Specialist Vandal Thief Trespasser

62 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer62 The Threat Landscape (courtesy David Aucsmith) Author National Interest Personal Gain Personal Fame Curiosity Script-Kiddy Hobbyist Hacker Expert Specialist Vandal Thief Spy Trespasser

63 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer63 The Threat Landscape (courtesy David Aucsmith) Author National Interest Personal Gain Personal Fame Curiosity Script-Kiddy Hobbyist Hacker Expert Specialist Vandal Thief Spy Trespasser

64 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer64 National Interest Personal Gain Personal Fame Curiosity Hobbyist Hacker Expert Specialist Script-Kiddy Fastestgrowingsegment AuthorVandal Thief Spy Trespasser The Threat Landscape Hacking and the bad guys

65 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer65 National Interest Personal Gain Personal Fame Curiosity Hobbyist Hacker Expert Specialist Script-Kiddy Vandal Spy Trespasser The Threat Landscape Author Tools created by experts now used by less skilled attackers and criminals Thief Hacking and the bad guys

66 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer66 National Interest Personal Gain Personal Fame Curiosity Hobbyist Hacker Expert Specialist Script-Kiddy Vandal Spy Trespasser The Threat Landscape Author Tools created by experts now used by less skilled attackers and criminals Thief Hacking and the bad guys

67 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer67 New Consequences l New types of attacks u Viruses, DoS, worms, botnets, spyware, phishing, spam, extortion… l With potentially severe consequences u Hundreds of thousands of infected machines u Worm propagation alone clogs Internet, down for day l Billions of dollars lost u Lost data, commerce, communication u System management nightmare l Spillover into other essential infrastructure u Public utilities, ATMs, 911 call centers, air traffic control…

68 © 2005 Geoffrey M. Voelker May 11, 2015CSE 291 – Computer Security Primer68 Summary l We can build cryptosystems u We use SSL daily l But we cannot build perfect systems u Flaws in assumptions, implementation, usability, management u Practical security must address these l Recent transformation of threats and capabilities u Software homogeneity + high-performance Internet = global risk u Buffer overflows + automated exploit software = lowers the bar l Global scale attacks and consequences u DDoS, worms, spyware, viruses u Spillover into physical critical infrastructure l Topics of remaining cybersecurity talks


Download ppt "Computer Security Primer CSE 291 Fall 2005 October 5, 2005 Geoffrey M. Voelker."

Similar presentations


Ads by Google