CS 5700 –Computer Security and Information

Assurance

Section 5: Security in Networks – Part 2

This version of Section 5 includesOPTIONAL slides that you may SKIP

Dr. Leszek LilienDepartment of Computer Science

Western Michigan University

Slides based on Security in Computing. Third Edition by Pfleeger and Pfleeger.Using some slides courtesy of:

Prof. Aaron Striegel — course taught at U. of Notre DameProf. Barbara Endicott-Popovsky and Prof. Deborah Frincke (U. Idaho) — taught at U.

WashingtonProf. Jussipekka Leiwo — taught at Vrije Universiteit (Free U.), Amsterdam, The Netherlands

Slides not created by the above authors are © 2006-2010 by Leszek T. LilienRequests to use original slides for non-profit purposes will be gladly granted upon a written request.

2Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Covered earlier (in Section 2):Security in Networks – Part 1 – Outline (1)

Outline of Part 1 of Security in Networks (covered in Section 2)

2.1. Network Conceptsa) Introductionb) The networkc) Mediad) Protocolse) Types of networksf) Topologiesg) Distributed systemsh) APIsi) Advantages of computing networks

2.2. Threats in Networksj) Introductionk) Network vulnerabilitiesl) Who attacks networks?m) Threat precursorsn) Threats in transit: eavesdropping and wiretappingo) Protocol flaws

3Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Covered earlier (in Section 2): Security in Networks – Part 1 – Outline (2)

2.2. Threats in Networks - ctd

g) Types of attacksg-1) Impersonationg-2) Spoofingg-3) Message confidentiality threatsg-4) Message integrity threatsg-5) Web site attacksg-6) Denial of serviceg-7) Distributed denial of serviceg-8) Threats to active or mobile codeg-9) Scripted and complex attacks

h) Summary of network vulnerabilities

4Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Security in Networks – Part 2 – Outline (1)Outline of Part 2 of Security in Networks (covered here)

5.1. Network Security Controlsa) Introductionb) Security threat analysisc) Impact of network architecture/design and implementation on

securityd) Encryption

i. Link encryption vs. end-to-end (e2e) encryptionii. Virtual private network (VPN)iii. PKI and certificatesiv. SSH protocolv. SSL protocol (a.k.a. TLS protocol)vi. IPsec protocol suitevii. Signed codeviii.Encrypted e-mail

e) Message content integrity controlsi. Error correcting codesii. Cryptographic checksum

f) Strong authenticationi. One-time passwordsii. Challenge-response systemsiii. Digital distributed authenticationiv. Kerberos authentication system

5Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Security in Networks – Part 2 – Outline (2)5.1. Network Security Controls—ctd.

g) Access controlsi. ACLs on routersii. Firewalls

h) Intrusion Detection Systems: alarms and alertsi) Honeypotsj) Traffic flow securityk) Review of network security controls

5.2. Network Security Tools5.2.1. Firewalls

a) Introductionb) What is a firewall c) Firewall designd) Types of firewalls

i. Packet filters(i-1) Simple packet filters(i-2) Stateful packet filtersii. Application proxies(ii-1) Guards (“top model” subcategory)iii. Personal firewalls

e) Comparison of firewall typesf) Example firewall configurationsg) What firewalls can—and can’t—block

6Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Security in Networks – Part 2 – Outline (3)5.2. Network Security Tools—ctd.

5.2.2. Intrusion Detection Systemsa) Introductionb) Types of IDSs

i. Signature-based IDSsii. Anomaly-based IDSsiii. Other IDSs

c) Goals for IDSsd) IDS strengths and limitations

5.2.3. Secure E-Maile) Introductionf) Security for e-mailg) Design of PEM (Privacy-enhanced Electronic Mail)h) Example secure e-mail systems

i. PGPii. S/MIME

7Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

5. Network Security – Part 2

Part 1 of Security in Networks was covered in lecture Section 2

Part 2 of Security in Networks is covered in this lecture Section 5, as follows:

5.1. Network Security Controls5.2. Network Security Tools

8Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

5.1. Networks Security Controls Outline

a) Introduction b) Security threat analysisc) Impact of network architecture/design and

implementation on securityd) Encryptione) Content integrityf) Strong authenticationg) Access controlsh) Alarms and alertsi) Honeypotsj) Traffic flow securityk) Controls review

9Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

a. Introduction There are many security controls:

For program security (incl. s/w engineering issues)

For OS security

Many of these strategies are useful for network security as well

We will now look for security controls designed specifically for computer networks

10Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

b. Security threat analysis (1) Threat analysis steps :

1) Analyze system components and their interactions2) Analyze possible damage to C-I-A3) Hypothesize possible kinds of attacks

Network elements to be considered: Local elements

Nodes / comm links / data storage / processes / devices / LANs

Non-local elements Gateways / comm links / control resources / routers /

network resources (e.g., databases)

11Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Security threat analysis (2)

Network threats: Accessing pgms or data at remote host Modifying pgms or data at remote host Running a pgm at a remote host

Interception of data in transit Modifying data in transit Insertion of data into communication traffic

Incl. replaying previous communication Blocking selected/all traffic

Impersonation of entities

Attack enablers: Size / anonymity / ignorance / misunderstanding Complexity / motivation / programming skills

12Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

c. Impact of network architecture/ design & implement. on security (1)

Security principles for good analysis, design, implementation, and maintenance (as discussed in sections on Pgm Security and OS Security) apply to networks

Architecture can improve security by:1) Segmentation2) Redundancy3) Single points of failure4) Other means

13Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Impact of network architecture/ design & implement. on security (2)

1) Segmentation Architecture should use segmentation to limit scope of

damage caused by network penetration by: Reducing number of threats Limiting amount of damage caused by single

exploit Enforces least privilege and encapsulation

Example 1: component segmentation Placing different components of e-commerce

system on different hosts Esp. put on separate host most vulnerable

system components E.g., separate host for web server (w/ public

access) Exploit of one host does not disable entire

system

14Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Impact of network architecture/ design & implement. on security (3)

Example 2: access separation Separating from each other:

Production system Testing system Development system

E.g., no developer has access to production systemand no customer has access to development system

15Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Impact of network architecture/ design & implement. on security (4)

2) Redundancy Architecture should use redundancy to prevent losing

availability due to exploit/failure of a single network entity

Example: having a redundant web server (WS) in a company

Types of redundancy include: Cold spare – e.g., when WS fails, replace it

manually with spare WS Warm spare – e.g., failover mode = redundant

WSs periodically check each other Hot spare – e.g., 3 WSs configured to perform

majority voting

16Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Impact of network architecture/ design & implement. on security (5)

3) Single points of failure (SPF) Architecture should eliminate SPFs to prevent losing

availability due to exploit/failure of a single network entity

Using redundancy is a special case of avoiding SPFs

Network designers must analyze network to eliminate all SPFs Example of avoiding SPF (without using

redundancy) Distribute 20 pieces of database on 20

different hosts (so called partitioned database)

Even if one host fails, 95% of database contents (19/20=95%) still available

Elimination of SPFs (whether using redundancy or not) adds cost

17Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Impact of network architecture/ design & implement. on security (6)

4) Other architectural means for improving security Will be mentioned below as we discuss more

network security controls

18Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

d. Encryption Arguably most important/versatile tool for network

security

We have seen that it can be used for: Confidentiality/Privacy Authentication Integrity Limiting data access

Kinds of encryption in networks:i. Link encryption vs. end-to-end (e2e) encryptionii. Virtual private network (VPN)iii. PKI and certificatesiv. SSH protocolv. SSL protocol (a.k.a. TLS protocol)vi. IPsec protocol suitevii. Signed codeviii. Encrypted e-mail

19Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

(i) Link vs. end-to-end encryption (1)

1) Link encryption = between 2 hosts Data encrypted just before they are placed on

physical communication links At OSI Layer 1 (or, perhaps, Layer 2)

Fig. 7-20, p. 445 (ed.4) Properties of link encryption (cf. Fig. 7-20)

Msgs/pkts unprotected inside S’s/R’s host I.e., unprotected at OSI layers 2-7 of S’s/R’s

host (in plaintext) Packets protected in transit between all hosts Pkts unprotected inside intermediate hosts

I.e., unprotected at OSI layers 2-3 of interm. hosts=> unprotected at data link and network layers at intermediate hosts (if link encryption at Layer 1) Layers 2-3 provide addressing and routing

20Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Link vs. end-to-end encryption (2)

Link encryption is transparent (invisible) to users, their applications, and their OSs Encryption service provided by physical (or

data) layer Can use encryption h/w (link encryption device)

Message under link encryption Fig. 7-21, p. 446 (ed.4)

See which portions encrypted, which exposed Only part of data link header & trailer created

after encryption is exposed

Link encryption is useful when transmission line is most vulnerable in a network I.e., when S’s host, intermediate hosts, R’s host are

reasonably secure (so msgs/pkts at their Layers 2-7 can be exposed)

21Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Link vs. end-to-end encryption (3)

2) End-to-end encryption = between 2 user applications Data encrypted as „close” to app as possible

At OSI Layer 7 (or, perhaps, Layer 6)

Fig. 7-22, p.447 (ed.4) Properties of e2e encryption (compare vs. Fig. 7-

20-ed.4) Msgs/pkts protected all the way once they

„exit” S’s app & before they enter R’s app Msgs/pkts protected (in ciphertext) inside

S’s/R’s host Packets protected in transit between S’s &

R’s hostsIncluding protection inside intermediate hosts I.e., protected at OSI layers 1-3 of interm. hosts

Layers 1-3 provide physical connectivity, addressing and routing for packets

22Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Link vs. end-to-end encryption (4)

E2e encryption is visible either to users or their apps Encryption service provided by app or OS

Possibly provided only upon explicit user’s request => visible to user

Encryption by s/w

Message under e2e encryption Fig. 7-23, p.447 (ed.4) (compare vs. Fig. 7-21-

ed.4) See which portions encrypted, which

exposed Only user’s msg (user’s data) encrypted All headers & trailers exposed (all created after

encryption)

E2e encryption is useful when transmission lines and intemediate hosts are insecure

23Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Link vs. end-to-end encryption (5)

Comparison of link vs. e2e encryption Encryption of msgs/packets (whether link or e2e

encryption) is no silver bullet No guarantees of msg/packet security

1) Link encryption — encrypts all traffic over physical link Typically host H has one link into network

=> link encryption encrypts all H’s traffic Every H —incl. intermediate hosts— receiving

traffic via link encryption must have decryption capabilities Either (pairs of) hosts share symmetric keyOR Hosts use asymmetric keys

All hosts along a path from S to R must provide link encryption to prevent („partial”) packet exposure=> usu. link encryption provided on all network links

24Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Link vs. end-to-end encryption (6)

2) End-to-end (e2e) encryption — encrypts traffic only between 2 apps („virtual crypto channel between 2 apps”) Interm. hosts don’t need to decrypt-encrypt

pkts=> interm. hosts don’t need encryption facilities All interm. hosts save time/processing

Can encrypts only some msgs between 2 apps If no need to encrypt all msgs => even S’s and R’s

hosts save time/processing If needed, can encrypt all msgs

Using asymmetric keys requires fewer keys than using symmetric keys (n key pairs vs. n*(n-1)/2 keys)

25Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Link vs. end-to-end encryption (7)

Comparison conclusions Link encryption:

Faster Easier to use Uses fewer keys (1 K pair per host pair vs. 1 K pair per

app pair)

End-to-end (e2e) encryption: More flexible More selective (can select only some msgs for

encryption) User-level, can be integrated with app

Optimize whether link or e2e encryption better for youIf needed for higher security, use link and e2e encryption together

E.g., user not trusting network link encryption can use app with e2e encryption

26Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

(ii) Virtual private network (VPN) (1)

Virtual private network (VPN) = connection over public network giving its user impression of being on private network

It could be viewed as „logical link” encryptionCould be viewed as e2e encr. between client & server

Protecting remote user’s connection with her network

Greatest risk for remote connection via public network:

Between user’s workstation (client) and perimeter of „home” network (with server)

Firewall protects network against external traffic (more later)

Physically Protected Network Perimeter

Firewall Internal

Server

User’sWorkstatio

n(Client)

27Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Virtual private network (VPN) (2)

Example VPN connection scenario

VPN restricts / filters access to „home” server/network

Only „private” accesses allowed=> public network access feels like private network

1 – C authenticates to firewall (firewall passes user’s authentic. data to authentic. server [not

shown], which decides whether authentication is OK) 2 – Firewall replies with encryption key (after negotiating with C a session encryption key)3 – C and S communicate via encrypted tunnel

Physically Protected Network Perimeter

Firewall

1

2

3

Internal

Server

User’sWorkstatio

n(Client)

28Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

(iii) PKI and certificates (1)

Public key infrastructure (PKI) = enables use of public key cryptography (asymmetric cryptography)

Usually in large & distributed environment

Elements of PKI:1) Policies (higher level than procedures)

Define rules of operation E.g., how to handle keys and sensitive info E.g., how to match control level to risk level

2) Procedures (lower level than policies) Dictate how keys should be generated,

managed, used

3) Products Implement policies and procedures

Generate, store, manage keys

29Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

PKI and certificates (2) PKI certificate services:

1) PKI creates certificates Certificate binds entity’s identity to entity’s public key

Entity = user or system or application or ...

2) PKI gives out certificates from its database3) PKI signs certificates

Adding its credibility to certificate’s authenticity

4) PKI confirms/denies validity of a certificate When queried about it

5) PKI invalidates/revokes certificates For entities that are no longer certified by PKIOR For entities whose private key has been

exposed

30Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

PKI and certificates (3) PKI sets up:

1) Certificate authorities (CAs)2) Registration authority

1) Certificate authority (CA) CA can be in-house or external

E.g., commercial TTP as the trusted third party CA is trusted

Entities delegate to CA creation, issuance, acceptance, and revocation of their certificates

CA actions: Managing public key certificates (whole life cycle) Issuing certificates by binding entity’s identity

to its public key Binding is done via CA’s digital signature

Determining expiration dates for certificates Revoking certificates when necessary

By publishing revocation lists

31Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

PKI and certificates (4) Example of CA analog: credit card company

(CCC)Certificate analog: credit card (binds identity to account)Revocation list analog: lists of invalid credit cards

CCC is trusted Customers delegate to CCC creation, issuance,

acceptance, and revocation of their credit cards CCC actions (cf. “CA actions” on the previous

slide): Managing credit cards (whole life cycle) Issuing credit cards by binding customer’s

identity to customer’s account Binding is done via CCC’s protected databases

Determining expiration dates for credit cards

Revoking credit cards when necessary By checking list of invalid credit cards

(before computer-verification transaction era, CCC published booklets of invalidated credit cards)

32Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

PKI and certificates (5)

2) Registration authority (RA) = interface between user and CA

Duties: Capture and authenticate user’s identity Submit certificate requests to appropriate CA

Analog: U.S. Citizen applying for passport and U.S. Postal Service (USPS)

Passport (official U.S. authentication) <-> certificate

USPS authenticates citizen By verifies citizen’s driver license + other proofs of

identity USPS submits passport request forms to

appropriate passport office of the U.S. Gov’t Passport office <-> CA

USPS brings passport to customer’s home Note: Trustworthiness of USPS authentication

determines level of trust that can be placed in passports

33Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

PKI and certificates (6) PKI efforts stateside and overseas

Building PKI for various purposes E.g., Federal PKI Initiative – to provide secure

communication to U.S. gov’t agencies It also specifies how commercial s/w using

PKI should operate (so gov’t can use off-the-shelf products)

Major PKI product vendors in the U.S.: Baltimore Technologies Northern Telecom/Entrust Identrus

Certificates can bind: Identity to public key – classic, most common Other bindings under research

E.g., binding financial status to key (credit card companies)

Draft standards: ANSI X9.45, Simple Public Key Infrastructure (SPKI)

34Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

PKI and certificates (7)

PKI is not yet mature Many outstanding issues

Cf. Table 7-6, p. 453 (ed.4)

Still, many points are clear: CA should be approved/verfied by independent

body CA’s private keys must be stored in tamper-

resistant security module (maybe with h/w support)

Access to CAs and RAs should be tightly controlled

Using strong authentication (e.g., 2FA or 3FA with smart cards)

35Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

(iv) SSH protocol (SSH = Secure SHell)

SSH protocol (newer: v.2) – provides authenticated and encrypted communication with shell/OS command interpreter

Originally defined for Unix Replaced insecure utilities for remote access

Such as Telnet / rlogin / rsh

Protects against spoofing attacks (falsifying one end of communication, incl. masquerading, sesssion hijacking, MITM) & message modification / falsification

Involves negotiation between local and remote sites

Negotiate which encryption algorithm to use E.g., DES? IDEA? AES?

Negotiate which authentication technique to use E.g., public key? Kerberos?

36Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

(v) SSL protocol (a.k.a. TLS prot.) (1)

SSL protocol (v3) = (approx.) TLS protocol - interfaces betwen app on client C and TCP/IP protocols

Provides: (1) server S authentication, (2) optional C authentication, and (3) encrypted communication channel between C and S for session between C and S

SSL = Secure Sockets Layer / TLS = Transport Layer Security

Originally defined by Netscape to protect browser-to-server communication

Simple but effective – most widely used secure commu-nication protocol on Internet (incl. WWW browsers/servers)

Involves negotiation between C and S Negotiate which encryption suite to use for

session E.g., DES? RC4 w/ 128-bit/40-bit key? RC2? Fortezza?

[Bishop] Negotiate which hashing technique to use for

session E.g., SHA1 or MD5?

37Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

SSL protocol (a.k.a. TLS protocol) (2) SSL use scenario (handshake protocol)

C requests an SSL session by sending: Hello-C, Rand-C (random nr), list of cipher (encryption) algorithms & hash algorithms known to C

Hash used to checksum messages S responds with msgs including: Hello-S, Rand-S,

cipher & hash algorithm selected by S (from C’s list) , S’s certificate, KPUB-S, [SKIP: request for cert. fr. C]

C can use S’s certificate (X.509v3 cert.) to verify S’s authenticity

[SKIP: C replies with: C’s certificate] C returns „pre-master secret” encrypted under

KPUB-S

Pre-master secret - e.g., 48 random bytes if selected cipher is RSA [Bishop-CompSec-A&S, p.296]

...continued...

38Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

SSL protocol (a.k.a. TLS protocol) (3)

...continued...

C and S calculate „master secret” using: „Pre-master secret” Constant strings ‘A’, ‘BB’ and ‘CCC’ Rand-C and Rand-S, SHA hashing algorithm [ibid, p. 294]

C and S switch to encrypted communication using „master secret” as session key

C and S exchange application data for the duration of the session (i.e., for as long as they stay connected)

TLS is potentially vulnerable to MITM attacks[Conklin et al., p.163]

39Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

(vi) IPsec protocol suite (1)

IPsec (IP Security Protocol Suite) = standard for securing IP communications by encrypting and/or authenticating all IP packets

IPsec is public (published / scrutinized)

By design, protects against threats including: spoofing (incl. session hijacking) / eavesdropping

Choice of ciphers/hash protocols Communicating parties negotiate which ones

to use IPsec defines some ciphers/hash as required in

every IPsec implementaion

40Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

IPsec protocol suite (2)

IPsec provides security at IP layer in IPv6 or IPv4 [Stall.p.499]

IP versions: IPv4 = v.4 — older IP protocol version (still in

use) IPv6 = v.6 — newer IP protocol version

IPv6 — larger address space Developed (1992-1998) since IPv4 runs out of address

space— IPv4 has 32-bit source/destination addresses— IPv6 has 128-bit source/destination addresses

IPv6 — also other functional enhancements To accommodate faster networks To accommodate mix of multimedia data streams

IPsec protects all layers above IP layer (where it „resides”)

In particular, protects TCP or UDP protocols Protects „automatically” Protects transparently (no modifications to TCP, UDP

needed)

41Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

IPsec protocol suite (3)

Basis of IPsec: security association (SA) = set of security parameters for a secured 1-way communication channel

2 SAs needed for 2-way communication [St,487]

Components of SA:1) Encryption algorithm and „mode”

E.g., for DES, mode = CDC – cipher bloc chaining

2) Encryption key3) Encryption params (e.g., initialization vector for

encryption)

4) Authentication protocol and key5) SA lifespan

Allows long-running sessions to select new crypto key

6) Address of opposite end of SA (source <---> destination)

7) Sensitivity level of protected data (e.g., unclassified / restricted /

confidential / secret / top secret)

42Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

IPsec protocol suite (4)

Security parameter index (SPI) - data structure Resides on each host H running IPsec Used to select 1 of nH SAs that exist on H

Different SAs for concurrent communications with different remote Hs

Fundamental IPsec data structures / protocols1) AH = authentication header / AH protocol

For authentication-only IPsec service: Authenticates S (sender )

2) ESP = encapsulated security payload / ESP protocol

For encryption-only IPsec serviceOR For combined encryption/authentication

IPsec service

43Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

IPsec protocol suite (5)

IPsec can be used for various crypto sessions: VPN e2e (incl. app 2 app) For network mgmt (e.g., for routing)

IPsec scenario TCP layer passes conventional TCP Header & Data

down to IP layer IP layer calls upon IPsec to encapsulate

conventional TCP Header & Data into ESP (encapsulated security payload)

Fig. 7-27, p. 455 (ed.4) IP layer: - adds IP Header - passes packet down to physical layer Physical layer adds Physical Header & Physical

Trailer

44Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

[---SKIP---] IPsec protocol suite (6)

ESP structure – includes more than just TCP Header & Data Fig. 7-28, p. 456 (ed.4)

„authenticated” — portion authenticated by IPsec with Authentication Data (Auth. Data = kind of signature)

„encrypted” — portion encrypted by IPsec Fields within ESP:

1) SPI (unencrypted) – index for security association to be used for this pkt

2) Sequence Number (unencrypted) – sequential number, prevents pkt replay attacks

3) Payload Data – (part of) data passed fr. TCP Layer

4) Padding / Padding Length – padding necessary to inflate pkt to required fixed size (e.g., size required by block cipher used for encryption)

5) Next Header – type of data in Payload Data field

6) SKIP: Authentication Data (unencrypted) – authenticates all above fields

45Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

IPsec protocol suite (7) ISAKMP (Internet Security Association Key

Management Protocol) = key mgmt protocol for IPsec

Key mgmt is always a critical element in crypto apps ISAKMP is simple, flexible, scalable Distinct key for each IPsec’s SA (security association)

In IPsec, ISAKMP implemented via IKE (ISAKMP Key Exchange)

IKE properties Provides ways to agree on protocols, cipher and

authentication algorithms, and keys E.g., agree as follows: protocol = EPS, cipher = triple

DES; authentication alg. = SHA-1; key used for session Provides ways to manage protocols, cipher and

authentication algorithms, keys Uses key exchange protocol (based on Diffie-Hellman

scheme)

46Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

[---SKIP---] IPsec protocol suite (8)

IKE key exchange scenario (using Diffie-Hellman scheme)

X and Y know number g X and Y choose large primes x and y,

respectively X send gx to Y / Y send gy to X X calculates (gy)x / Y calculates (gx)y

Since (gy)x = (gx)y => X and Y share secret Actual calculation is mod(n) — a bit more complex

X and Y exchange identities & certificates Certificates authenticate identities

X and Y derive shared crypto key X and Y enter security association

=> they establish session

IKE key exchange is very efficient Can be done in 2 messages if w/o authentication Can be done in 4 messages if w/ authentication

47Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

vii. Signed code Problem: malicious active code

E.g., malicious code on a web site for downloads

Partial solution: code signed by TTP (trusted third party)

TTP appends digital signature to piece of code PKI can be used by prospective code users to

validate signature

Still code security not guaranteed E.g., March 2001 mistake of Verisign (CA)

Erronously issued two code-signing certificates to impostors masquerading as Microsoft employees

Verisign detected mistake after almost 2 months

Customers who didn’t validate certificate (by checking Verisign’s certificate revocation list) could still trust bad certificates

48Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

[---SKIP---] viii. Encrypted e-mail E-mail msgs – like a postard that everybody who

handles it between S and R can readPeople use envelopes for confidentiality (C in C-I-A)

We can „envelope” e-mail msgs by encrypting them

Encryption protects C and can protect I

Encryption is easy, establishing good key mgmt is difficult

2 basic key mgmt approaches:1) Hierarchical certificate-based PKI solution

E.g., S/MIME

2) Use of flat, individual-to-individual key exchange E.g., PGP

E-mail security (incl. PGP and S/MIME) will be discussed soon

49Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

[---SKIP---] e) Msg content integrity controls (1)

Content integrity verification provided „for free” with encryption

Since can’t perform meaningful data modification w/o decrypting it

But attacker can modify encrypted data to make it useless

E.g., changing a bit of data in packet Threats to msg content integrity

1) Malicious modification that changes contentin a meaningful way

2) Nonmalicious modification that changes contentin a way that is not necessarily meaningful

3) Malicious modification that changes contentin a way that is not meaningful NOTE: Different cases than in text!

Encryption can solve the toughest case: Case (1) above

EASIERTO PREVENTOR DETECT

50Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

[---SKIP---] Msg content integrity controls (2)

Msg content integrity controls #1: DETECTError detection and error correction codes

As discussed before („Intro to Cryptology” section) Simplest error detection code: even/odd parity check More complex error detection codes:

Hash codes or Huffman codes Some detect multiple bit errors

Some also pinpoint which bits are incorrect For detecting/correcting nonmalicious changes

Does not matter whether accidentally „meaningful” or not Can also stop some malicious attacks

Again does not matter whether msg changes „meaningful” or not E.g., attackers not knowing which code used => can’t

fool it E.g., attacker manipulating 2 bits & thinking that we

have 2–bit correction code fails if we have 3-bit correction code

More complex error detection codes can stop tougher attackers

51Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

[---SKIP---] Msg content integrity controls (3)

[SKIP] Msg content integrity controls #2: PREVENT or DETECTCryptographic checksum / msg digest / hash

To prevent or malicious attacks on data — As discussed before („Intro to Cryptology” section)

Can also detect malicious errorsCan also detect nonmalicious errors

Note that attacker can modify: Modify only data bits Modify error prevention/detection mechanism

52Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

f) Strong authentication Networked environments as well as both ends of

communication need authentication

Strong authentication controls include:i. One-time passwordsii. Challenge-response systemsiii. Digital distributed authenticationiv. Kerberos authentication system

53Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

[---SKIP---] i. One-time passwords (1)

One-time password (OTP) method Controls wiretapping and spoofing

Prevents reuse of pwd captured by wiretapper Strong authentication prevents spoofing (incl.

masquerading, session hijacking, MITM) Each password used only once

„Thrown away” after use

OTP uses secretly maintained pwd listOR User has password token (PT)

= device to randomly generate new pwd (e.g.) every minuteE.g., SecureID device from Security Dynamics – random # every minute

54Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

[---SKIP---] One-time passwords (2)

Pwd generation for user U is based on time synchronization with PT of this particular user U

Pwd changed in sync by both U’s PT and system authenticating U

PTs of different users produce different pwd sequences

Problems with OTP1) Attacker can steal/find PT (device)

2) One-minute window of vulnerability Wiretapper can reuse password for one minute

If PT generates new pwd once per minute

55Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

[---SKIP---] ii. Challenge-response systems

Challenge-response systems solve OTP problems1) Solve problem of stolen/lost password tokens (PTs)

Solution: PT requires a PIN Even if stolen by attacker, PIN protects „responses”

2) Solve problem of window of vulnerability Solution: New challenge for each use

Does not matter whether new use within one minute window or not

Challenge-response systems can be viewed as more sophisticated version of OTP

Problem: Neither OTP or C-RS protect user from rogue system

56Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

[---SKIP---] iii. Digital distributed authentication (1)

„Digital” from „Digital Equipment Corporation” (DEC)

Once a powerful computer company Acquired (1998) by Compaq, which subsequently merged with

Hewlett-Packard (2002) As of 2004 their product lines were still produced under HP

name

In 1980s DEC recognized need for authentication of nonhuman entities in distributed environment

E.g., mutual authentication of user query processor and DB manager (process)

Goals of Digital distributed authentication: Prevent server impersonation (e.g., DB mgr

impersonation) Prevent interception/modific. of msgs between

entities Prevent replay of previous authentication

[Wikipedia]

57Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

[---SKIP---] Digital distributed authentication (2)

Architecture of Digital distributed authentication (1989):

Each server S has KPRIV-S

Corresponding KPUB-S available to any process that might need authenticated channel to S

A to B communication uses KPUB-B

B to A communication uses KPUB-A

A and B use sequence #s to msg replay

B can establish secret (symmetric) session key K for communication with A by:

Selecting key K Sending E(K, KPUB-A) to A From now on, A and B can exchange data

encrypted with K

58Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

iv. Kerberos authentication system (1)

Kerberos – system for authentication between intelligent processes in distributed systems (incl. C-S authentication)

[K. = guard dog in Hades (Greek mythology)] Developed at MIT (1988+)

Design goal: Enable systems to withstand attacks in

distributed systems

Basic idea of Kerberos: Central server provides tickets to requesting app

Ticket is authenticated, non-forgeable, non-replayable token=> Implemented as encrypted data structure naming user U and service for which U has access permission (also contains time value, control info)

59Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Kerberos authentication system (2a)

Nodes involved: User U (client) Server S (with File F that U wants to read) Kerberos Server KS – distributes “pre-tickets”

Having pre-ticket is needed before asking for ticket

Ticket-Granting Server TGS – distributes tickets Real-life analogy:

U = a fan that wants to watch World Championship

Many more Us than available tickets S = game that U wants to watch

Pre-ticket = right to buy a ticket KS = lottery that gives a “pre-ticket” to each

winner Pre-ticket = right to buy a ticket

TGS = box-office that sells tickets only to Us that have pre-tickets

60Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Kerberos authentication system (2b) User’s Step 1: Establishing session w/ Kerberos — Fig.

7-29, p. 462 (ed.4) - TGS = Ticket-Granting Server / KS = Kerberos server

U’s workstat’n sends U’s identity to KS KS verifies that U is authorized KS sends 2 msgs:

1) Msg to U, which contains: E(STGS + TTGS , pwd) STGS — U’s session key for session with TGS TTGS — U’s ticket for TGS

Enables U to request service from TGSwhere pwd = user’s pwd (Note: used as encr. key by KS)

2) Msg to TGS, which contains: E(STGS + U’s identity, shared KS/TGS key) (i.e., encrypted under key shared by KS &

TGS) STGS — TGS’s session key for session with U

(same as U’s session key for session with TGS)

If U’s workstation can decrypt E(STGS + TTGS , pwd) using its pwd, then U’s authentication succeeds

U

U

U

U

U U

U U

61Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Kerberos authentication system (3)

Note: KS stores users’ pwds => no need to pass pwds over network between U’s workstation and KS

Security advantage!

User’s Step 2: U accesses services of distributed system — e.g., access file F — Fig. 7-30, p. 463 (ed.4)

Using U’s ticket for TGS (received fr. KS in Step 1), U sends to TGS:

E(„request R for U’s ticket for accessing F” , STGS)

Note: STGS (U’s session key for session with TGS obtained fr. KS

in Step 1) is used to encrypt R TGS verifies U’s access permission

...continued...

U

U

62Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Kerberos authentication system (4)...continued...

If verified OK, TGS returns to U message encrypted under STGS, which contains:

1) U’s session key for session with F (really: with F’s file server) = SF

2) U’s ticket for accessing F Ticket is encrypted under secret key („TGS/F

key”) known only to TGS and F’s file server Ticket contains:

U’s authenticated identity (TGS knows that STGS is U’s key —and nobody else’s— because KS sent to TGS STGS and U’s identity tied together in Step 1)

Identification of file F Access rights (e.g., read permission) F’s session key for F’s session with U = SF

(same as U’s session key for session with F) Ticket expiration date

U

U

U

U

U

63Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Kerberos authentication system (5) Strengths of Kerberos:

1) No pwds communicated over network Pwd sent by user to Kerberos server only once

& sent outside the network (e.g., in a letter) User’s pwd is not sent from user’s workstation when

it initiates a session User’s pwd stored only at Kerberos server

2) Provides crypto protection against spoofing (e.g., masquearding, session hijacking, MITM)

Each access request mediated by a ticket-granting service (TGS)

TGS knows user’s identity based on authentication performed initially by the server

64Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Kerberos authentication system (6) Strengths of Kerberos – cont.1

3) Limits period of ticket validity (this disables some long-term attacks—e.g., brute force cryptanalysis)

Tickets contain timestamps used by servers to determine ticket’s validity

Ticket validity period limits duration of „window of opportunity” for attacker

4) Prevents replay attacks Each user’s request stamped with time of

request Servers compare timestamps of requests w/

current time, accept requests only if they are close enough to current time

Time-checking prevents most replay attacks Since presentation of tickets by attackers will be

delayed more than presentation of tickets by legitimate users

65Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Kerberos authentication system (7) Strengths of Kerberos – cont.2

5) Provides mutual authentication Service user can be assured of any server’s

authenti-city by requesting an authenticating response from S

6) Uses public key technology for key exchange

66Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Kerberos authentication system (8)

Weaknesses of Kerberos system1) Requires continuous availability of trusted ticket-

granting server (TGS)2) Server S’ authenticity requires trust between TGS

& S3) Requires timely transactions (too quick ticket

expiration will result in rejecting legitimate requests)4) Subverted workstation can replay user pwds5) Pwd guessing works (attacker can send initial —Step 1

— authentication request to Kerberos server, receive response, try to decrypt response by guessing at pwd)

6) Kerberos does not scale well (due to system size might need > 1 KS and/or TGS server; coordination and security problems if more than one KS and/or more than one TGS is needed; cf. Fig. 7-31, p.450-ed.4)

7) Use of Kerberos requires compatibility of all apps in a given computing environment (to date few apps are compatible with Kerberos; modifying apps to make them compatible is not feasible)

67Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

g) Access controls (1) Before user is allowed access to network resources,

must know: Who needs access => authentication What and how will be accessed => access

controls

Access controls include:1) ACLs (Access Control Lists) on router2) Firewalls

68Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Access controls (2)

1) ACLs on routers (ACL = Access Control List) Router directs traffic:

To subnetworks it controlsOR To other routers (for delivery to other

subnetworks)

Routers convert external (network-wide)IP address to internal (subnetwork-wide) MAC address

Recall that MAC address is unique physical address of device’s NIC—network interface card

Can put ACL on a router to deny access to particular host D from particular host S

E.g., to prevent spam (flooding) of D with packets from S, router can delete all packets from S to D

It’s OK if router uses ACLs in a limiteded way Use sparingly: only for specific & known threatsBUT...

69Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Access controls (3) ... Problems with putting too many ACLs on

routers:(i) Packet-checking overhead for router

Router must check each packet against each ACL – a lot of work=> degraded performance More ACLs on router => more work

Routers are already busy just routing all packets ingoing/outgoing to/from their subnets

(ii) Logging overhead for router To be able to detect spam, router must log

source addresses of packets Then can analyze to see which source addresses

produce floods Routers are designed to do only essential

work — anything else is inefficient => logging on router is inefficient => adds workload

70Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Access controls (4)

... Problems with putting too many ACLs on routers-CONT.

(iii) Inability of router to detect all spams Because source addresses in datagrams

(UDP packets) can be easily forged (by attacker using UDP protocol)

If attacker sends many datagrams with the same (repeated) forged address, router with ACL can detect & block themOtherwise (i.e., if attacker sends datagrams with few repeated forged addresses), router with ACL will not even detect being flooded=> can not block flooding datagrams

71Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Access controls (5)

2) Firewalls Designed to do screening that routers can’t do

efficiently Because routers designed for routing (of course!)

Firewalls designed for access filteringAND auditingAND examining whole packets (not only source/destination IP/ MAC addresses—which is what routers do)

Firewalls will be discussed in detail later (but very soon)

72Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

h) Intrusion Detection Systems: Alarms & Alerts

Example of 2-layer network protection Provided by router (Layer 1) AND firewall (Layer

2) Fig. 7-32, p. 469 (ed.4)

We can add one more layer of protection: intrusion detection systems (IDS) = device placed within protected network for monitoring for illegitimate actions in order to detect attacks in progress (beginning, advanced) or after they have occurred

E.g.: Can detect reconaissance & alert sysadmin or secadmin, raise alarm, thus preventing „real” attack

OR Can detect that attack has already occurred & raise

alarm, starting system recovery actions IDS is a.k.a. IPS = intrusion protection system

A marketing gimmick? IDS can be Layer 3 of layered network protection To be discussed in detail soon

73Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

i) Honeypots Honeypot – system built as a bait attracting

attackers Once attackers take the bait:

They are observed to learn how they behave/operate New attacks / Prefered targets / ...

They are traced to catch them or scare them off Or at least trace enough to be able to threaten them

with identifying them if they don’t stop They are diverted from really valuable attack

targets E.g., diverted to phony credit card database while

real credit card database remains obscure to them

User lessons learned (thanks to honeypots) to build better countermeasures

74Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

j) Traffic flow security (1) Threat: attacker infering occurrence/location of

some event / structure from intensity of encrypted network traffic

(If not encrypted, no need to infer – attacker can simply read all)

Example 1: Inference that traffic between Thinges Corp. and bankruptcy lawyer precedes declaration of bankruptcy by Thinges

Example 2 (old): Battlefield network: Busiest network node is at enemy’s HQs

Solution 1: Masking by steady traffic volume X and Y always send the same volume of

encrypted traffic between them If X has nothing to communicate to Y, X sends

meaningless padding packets to Y (Y behaves analogously)

75Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Traffic flow security (2)

Solution 2: Masking by onion routing Example: W wants to send packet to Z in a

hidden way W wraps „real” packet to Z into packet

addressed to Y, which asks Y to send it toZ W wraps packet to Y into packet addressed to

X, which asks X to send it to Y

Send packet to Z

Send packet to Y

Onion-like packet sent by W to X

Full route: W X Y Z W sends green packet to X X unwraps it, gets red

packet X sends red packet to Y Y unwraps it, gets blue

packet Y sends blue packet to z Z unwraps it, gets blue

packet

76Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Traffic flow security (3) Why „onion” routing? Layers of wraps around

„real” packet to Y– like layers of an onion Note: (Recall the full route: W X Y Z )

X knows that packet came from W & should be forwarded to Y But X does not know if W is source or intermediate

host, does not know if Y is destination or intermediate host

Y knows that packet came from X & should be forwarded to Z But Y does not know if X is source or intermediate

host, does not know if Z is destination or intermediate host

Z knows that packet came directly from Y & knows that W is its source Z knows that Y is just an intermediate host

=> Intermediate nodes do not know source/destinationThey only know host that forwarded packet to them &know host to which they should forward packet

77Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

k) Review of network security controls

Table 7-4, p. 439 (ed.4) provided classification of network vulnerabilities (during our earlier discussion of threats)

Table 7-7, p. 471 (ed.4) lists controls for each of these classes of network vulnerabilities — it shows that:

There are many great network security controls Most are used also in environments other than

networks (including applications and OSs) Three of these controls are specific to networks:

Firewalls / IDSs / encrypted e-mailWe shall discuss them in some detail next

Table 7-7 is a great reference for network security controls!

Use it often If you can get copyright permission from publisher, I’d

advise you to copy it and post above your desk Otherwise, make your own notes based on it

78Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

5.2. Network Security Tools

Network security tools5.2.1. Firewalls5.2.2. Intrusion Detection Systems5.2.3. Secure E-Mail

[Fig: B. Endicott-Popovsky]

79Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

5.2.1. Firewalls Outline

a) Introductionb) What is a firewall c) Firewall designd) Types of firewalls

i. Packet filters(i-1) Simple packet filters(i-2) Stateful packet filters

ii. Application proxies(ii-1) Guards (“top model” subcategory)

iii. Personal firewallse) Comparison of firewall typesf) Example firewall configurationsg) What firewalls can—and can’t—block

80Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

a. Introduction Firewalls

Invented in the early 1990’s But idea related to reference monitors from

1970’s

What is reference monitor? OS includes kernel / core / nucleous – responsible for

lowest-level functions Incl. synchronization, inter-process

communication, msg passing, interrupt handling

Security kernel – provides security mechanisms for entire OS Incl. security interfaces among h/w, OS, other

parts of computing system Typically, security kernel is a part of OS kernel Reference monitor is portion of security kernel that

controls access to objects (controls „references” to objects)

81Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

b. What is a firewall (1a)

Firewall = device (h/w), or software, or combination of both designed:

1) to prevent unauthorized outside users from accessing network and/or single workstation

2) to prevent inside users from xmitting sensitive information or accessing insecure resources

It is a wall between protected local (sub)net & outside global net

Inspect each individual inbound or outbound packet of data sent to / from protected system

Check if it should be blocked or allowed to enter

82Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

b. What is a firewall (1b)

Firewalls keep „bad things” out, keep sensitive info in

Security policy specifies what are „bad things” E.g., requires that traceroute & ping -o can't see

internal hosts

F. protect against security threats from external network

F. are effective in protecting local subnet incl. itssensitive info

83Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

What is a firewall (2)

Examples of security policy requirements w.r.t. firewalls:

Block any access from the outside, allow all accesses to the outside

Allow”from” accesses only for certain activities OR only to/from certain subnets/hosts/apps/users E.g., prevent outside access to subnet hosts except for

mail server accesses

Choice of default firewall behavior1) Default permit

„That which is not expressly forbidden is allowed”

2) Default deny „That which is not expressly allowed is forbidden”

Users prefer default permit, security experts prefer default deny

Sysadmin must make the choice

84Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

c. Firewall design (1) Firewall design principles:

Small / simple enough for rigorous analysis KISS principle (= „Keep It Simple, Stupid”) Simple firewall functionality

Tamperproof Typically well isolated (=> highly immune to

modifications) On a separate computer With direct connections only to the outside networks

and to the inside network

Designed to be always invoked Efficient enough not too be a bottleneck Placed strategically

All network accesses that we want to control pass through it

85Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Firewall design (2)

General firewall techniques:1) Service control

Type of service: inbound or outbound2) Traffic filtering — based on IP address & TCP port

nr Provide proxy software to receive or interpret

service request before passing it on Could also host server software (e.g. Web or mail

service) Not recommended

Complicates it (more code => more vulnerabilities)

3) User Control Control access to service using ACLs

4) Behavior Control E.g. filter e-mail for spam

86Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

++SKIP++ Firewall design (3) Basic firewall characteristics

All traffic (incoming / outgoing) must pass thru firewall

Only authorized traffic allowed to pass Firewall itself must be immune to penetration

I.e. must use trusted system w/ secure OS (min. size/complexity)

Usually implemented on dedicated device Dedicated = only firewall functions performed on this

device Firewall code must be very well protected

Basic kinds of firewalls: Hardware firewalls

More common Implemented on router level

More expensive / more difficult to configure Software firewalls

Used in single workstations Less expensive / Easier to configure

87Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

d. Types of firewalls (1) Types of firewalls

i. Packet filters / packet filtering firewallsControl packets based on packet’s IP adresses and

port #s

(i-1) Simple packet filters / (simple, stateless) packet filtering gateways / screening routers (stateless = ignore history)

(i-2) Stateful packet filters / stateful inspection firewalls

ii. Application proxies / proxy firewalls / application-level gateways

More sophisticated than packet filters.Control packets based on any data within a packet

(not only basedon packet’s IP adresses and port # as packet filetres

do) =>=> can detect/derail more sophisticated attacks (e.g.,

can filter out harmful commands in pkt stream)

(ii-1) Guards (a special case of app proxies)

iii. Personal firewallsProtect single hosts (not subnetworks R like regular firewalls do)

For small business / home office / home

88Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Types of firewalls (2)

++SKIP++ Firewall properties: Packet filter properties:

Transparent Does not change traffic, only passes it (or blocks

some)

Proxy properties: Active Intercepts traffic & acts as an intermediary

Different firewall types needed for different needs„Different strokes for different floks” — e.g.:

Simple packet filters / screening routers – implement simplistic security policies

Simple is best if sufficient to counter exisiting threats well

App proxies – much richer capabilities

89Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Types of firewalls (3)

Firewall is a type of hostEven some routers are host-basedTo have better tools available (editors, programming tools)

Programmable Minimal functionality

Reduces vulnerabilities Small = > less complex => fewer vulnerabilities

Reduces motivation for attacks No password files to steal, etc.

90Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

(i) Packet filters (1) Packet filters — a.k.a. packet filtering firewalls

(i-1) Simple packet filters („memoryless”)

(i-2) Stateful packet filters (with „memory”)

Basis for packet filtering1) Packet IP addresses

Filtering based on both source/destination addresses

2) Port number determines TCP transport protocol type

Recall “portprotocol” mapping in TCP: 21FTP, 23Telnet, 25SMTP, 80HTTP, 110POP, 161 SNMP, etc.

Filtering based on port nr

Packet filtering firewalls do not „see” other packet fields

See only IP address ‘ transport protocol type E.g., can not allow only some Telnet commands OR

exclude only some other Telnet commands

91Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

(i) Packet filters (2)

Examples of packet filtering – see text1) Packet filtering based on packet address

1a) Can block and/or allow traffic from/to specific subnet, i.e., all its addresses (cf. Fig. 7-34, p. 476-ed.4)

1b) Can block and/or allow traffic from/to specific IP addresses (cf. Fig. 7-35, p. 476-ed.4)

2) Packet filtering based on transport protocol type – e.g., HTTP or Telnet (cf. Fig. 7-34, p. 476-ed.4)Can block traffic using Telnet protocol (port 23) but allow HTTP traffic (port 80)

To avoid overburdening router, firewall can run on device behind router (on subnet side)

92Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

(i-1) Simple packet filters (1) Simple packet filters / (simple) packet filtering

gateways / screening routers — simplest firewall type

Simple packet filters (PFs) are memoryless=> can not perform attack detections that require remembering state (history/context) of ≥ N last pkts

++SKIP++ what follows E.g., can not see that prev. & curr. pkt indicate

attack “Attack signature” (i.e., attack pattern) would be

clearly visible if both pkts were put together Example: Certain attack script known to use Telnet

(port 23) and then SNMP (port 161)The same source address in previous pkt, using port 23, and in current packet, using port 161, constitutes attack signature

Why need to remember ≥ N last pkts? TCP pkts arrive in order different than sending

order=> remembering ≤ N last pkts is not enough

93Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

++SKIP++ (i-1) Simple packet filters (2)

Cheating simple (memoryless) PF: Attacker divides pkt (including attack signature)

into many v. short pkts Attack signature (pattern) would be visible

in original long pkt Even memoryless simple PF would detect it

Pattern of attack is completely invisible in any single short pkt => memoryless simple PF is unable to detect

attack Additionally, TCP pkts arrive in order

different than their sending order=> remembering just last packet would not be enough – must remember N last packets

94Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

++SKIP++ (i-1) Simple packet filters (3)

One very important task for simple packet filtering gateways: Validating inside IP addresses

Inside hosts trust more other inside host Simple filtering assures that no external source

can masquerade as internal source Blocks any packet coming from outside network that

claims to be sent by internal host Cf. Fig. 7-36, p. 477 (ed.4)

95Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

++SKIP++ (i-1) Simple packet filters (4)

Simplicity of inspection is both disadvantage & advantage

Disadvantage because of high granularity E.g., can block all Telnet coomands, but can

not block only selected telnet commands Advantage beacuse reduces complexity

Filtering rules to block, e.g., only selected Telnet traffic would have to be much more detailed=> more complex=> more vulnerable

96Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

(i-2) Stateful packet filters

Stateful packet filters — a.k.a. stateful inspection firewalls

Keep state/history/context of N previously seen pkts

=> stateful packet filters have memory This allows detection of some attacks that simple

PFs can not detect Still limited to detection based on IP address &

TCP transport protocol type (port nr)

97Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

(ii) Application proxies (1) Application proxies / proxy firewalls / application-

level gateways / application proxy gatewaysNote: The term bastion host (used in text) should not be used as a

synonym. Bastion host is a host that serves as a platform for app proxy or circuit-level proxy [Stallings, Crypto&Net.Sec, p.625].

Application proxies include — as a special case(ii-1) Guards

App proxy firewalls fix basic problem with packet filtering firewalls because they:

See all pkt data (not just IP adresses and port #s) (In addition, they are stateful => can analyze

multiple pkts) => can detect/derail more sophisticated attacks

Can filter out harmful commands in pkt stream

98Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

++SKIP++ (ii) Application proxies (2)

For example, app proxies can prevent: Use of back door open to pkts inbound to SMTP

port (Port 25) Flawed application run by user U (e.g., an e-mail

agent) has all U’s privileges => can cause damage

99Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

++SKIP++ (ii) Application proxies (3) Act as mediators/censors (!) of app-level traffic –

like benevolent „woman-in-the middle” (not an official term!)

They “censor” insecure actions Maybe a rare case of a truly benevolent censor

Ex. scenario of using app proxy gateway G: [cf. ibid, p.624]

Extern. user U tries to Telnet to host H protected by G

G intercepts U’s packets G acts as H would: asks U for id+pwd U replies w/ id+pwd G logs in into H on behalf of U G relays H’s msgs to U Etc., etc.

100Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

++SKIP++ (ii) Application proxies (4)

Examples of app proxy activities Preventing outsiders from modifying company’s

online price list More - see bulleted list on p. 478 – 479 (ed.4)

App proxy must implement code for given app (e.g., for Telnet) to be able to perform service to this app

Netadmin can configure app proxy to support only selected features of an app

Unsupported features are considered too risky => not available

101Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

++SKIP++ (ii) Application proxies (5)

App proxies provide higher level of security than packet filters (PFs)

PFs try to deal with all potentially deployable applications that could use TCP/IP (default permit philosophy)

App proxy considers only few allowable apps among ones actually deployed in a given system (default deny philosophy)

App proxy can easily log/audit traffic at app level (vs. transport level for PFs)

Prime disadvantage of app proxies: Processing overhead for each app-level connection

1 connection split into 2 logical connections With “woman-in-the-middle” Circuit-level gateways (another proxy subcategory) splits

1 TCP connection into 2 TCP connections

102Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

(ii) Application proxies (6)

(ii-1) Guards = most sophisticated category of app proxies (“top model”)

Limited only by what is computable (& by human creativity)

No sharp boundary between app proxies and guards

At some point of upgrading app proxy, it becomes a guard

--SKIP-- ----> Examples of guard activities

Limiting nr of msgs (or nr of msg characters) that a student may e-mail per week Easiest if done by gurad monitoring mail

transfer protocol More - see bulleted list on p. 480 (ed.4)

103Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

(iii) Personal firewalls Regular firewalls protects subnetworks

Personal firewalls protect single hosts For small business / home office / home Can be used to complement conventional firewall

Next line of defense Customized to user(s) of particular host

Firewall capabilities at a lower price

Personal firewall is application program Products include: Norton Personal Firewall (Symantec),

McAfee Personal Firewall, Zone Alarm (Zone Labs)

Personal firewall also enforces certain security policy

E.g., if you’re using default personal firewall’s policy on your computer, see its rules

Combine it with antivirus software for more effective protection & with automatic (or very frequent manual)OS and antivirus s/w updates

104Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

++SKIP++ e. Comparison of firewall types

Comparison of firewall types See Table 7-8, p. 482 (ed.4) Criteria:

Complexity Part of packets visible to firewall Difficulty of auditing Basis for screening Difficulty of configuring

105Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

f. Example firewall configurations Example firewall configurations

Subnet with screening router (simple packet filtering)— Fig. 7-38, p. 482 (ed.4)

Subnet with proxy gateway (app proxy)— Fig. 7-40, p. 483 (ed.4)

Subnet with screening router (a simple packet filter) & proxy firewall (app proxy)

— Fig. 7-40, p. 483 (ed.4) Note:

The LAN between the outer firewall (“screening router” in the fig) and the inner firewall (“proxy firewall” in the fig) constitutes DMZ (demilitarized zone)

106Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

g. What firewalls can—and can’t—block

Firewalls are not a panacea - only a perimeter protection

Points 2 remember about firewalls — see text, p.483-484

Can protect environment only if control its whole perimeter Do not protect data outside the perimeter Are most visible subnet component – attractive attack

targets Must be correctly configured, & config must be periodically

updated Firewall platforms should not have any s/w that could help

attacker who penetrates firewall in subsequent exploits Firewalls exercise very limited control over content they let

in Other means of verifying/enforcing accuracy/correctness

must be used inside perimeter

107Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

5.2.2. Intrusion Detection Systems

Outline a) Introductionb) Types of IDSs

i. Signature-based IDSsii. Anomaly-based IDSsiii. Other IDSs

c) Goals for IDSsd) IDS strengths and limitations

108Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

a. Introduction (1) It is better to prevent attack than to detect it after it

succeedsUnfortunately, not all attacks can be prevented

Some attackers become intruders — succeed in breaking defenses

Intrusion prevention — first line of defenseIntrusion detection — second line of defense

Intrusion detection system (IDS) - a device (typically a seprate computer) monitoring system activities to detect malicious / suspicious events

IDSs attempt to detect Outsiders breaking into a systemOR Insiders (legitimate users) attempting illegitimate

actions Accidentally OR deliberately

109Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Introduction (2)

IDS runs constantly in the background Alarms when it detects something suspicious

We’ll be talking only about real-time IDSs Ignoring off-line IDSs (early IDSs reviewed logs after th fact)

IDS should operate in stealth mode — be invisible to outside world

IDS interfaces (cf. Fig. 7-42, p.488-ed.4)

1) Alarm interface through which raises alarm On a completely separate control network

2) Monitoring interface to protected (sub)network Never sends msgs on this interface! Preferably, IDS has no published address

through the monitored subnetwork=> router does not even know IDS platform exists=> router can not send anything to IDS

directly

110Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Introduction (3)

IDS terminology Anomaly — abnormal behavior

Might either be still legitimate OR illegitimate

Misuse — activity that violates the security policy

(subset of “anomaly” – anomaly that is illegitimate)

Intrusion — misuse by outsiders or insiders

Audit — activity of looking at user/system behavior, its effects, or collected data

Profiling — looking at users or systems to determine what they usually do

111Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

---[SKIP]--- Introduction (4)

Superset of IDS functions Monitoring users and system activity Auditing system configuration for vulnerabilities

& misconfigurations Assessing integrity of critical system and app

files Recognizing known attack patterns Identifying abnormal activities through statistical

analysis Managing audit trails (logs) and highlighting

misuses or anomalies in user activities Correcting system config errors Installing & operating traps (honeypots) to learn

about intruders

112Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

b. Types of IDSs (1a)

IDS types w.r.t. scope: Host-based

Runs on a host Monitors activities on this host only

Network-based Stand–alone device Monitors entire (sub)network

113Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

b. Types of IDSs (1b) IDS types w.r.t. their operation

i. Signature-based IDSs (optimistic: “block only ‘blacklisted’ behavior”)

Models & looks for unacceptable system activities (= an attack) Each known attack characterized by its „signature”

(pattern) To detect attack, matches current activities to known

attack signatures Problem: Unable to detect new attacks (unknown

signatures!)

ii. Anomaly-based (heuristic) IDSs(pessimistic: “allow only permitted behavior”)

Solves the above problem (but might generate more false alarms)

Uses model of acceptable user activities Not models (signatures) of unacceptable system activities

Raises alarm upon detection of deviation from model behavior Alarm even if this deviation is legitimate

iii. Other IDS types E.g., hybrid IDSs (combining signature- and anomaly-

based IDSs), immune-system-based IDSs

114Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Types of IDSs (2)

i. Signature-based IDS Looks for unacceptable system activities (considered

an attack)

Each known attack characterized by its „signature” (pattern)

To detect attack, matches current activities to known attack signatures

Even attack with signature „similar” to signature of a known attack can be detected

Example signature for port scan attack Syn to port 80 Syn to port 25 Syn to port 161 ...

115Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Types of IDSs (3)

Problems with signature-based IDSs(1) Can not detect attack with unknown signature

Must know (exact or very similar) attack signature to detect attack

(2) Attacker can „pad” attack with packets that break known signature into unknown patterns

(3) False alarms occur When legitimate data accidentally match

attack signature

Solution to (1) and (2): anomaly-based IDSs

116Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Types of IDSs (4)

ii. Anomaly-based IDS (heuristic IDS) Uses model of acceptable user behavior

Recall that signature-based IDS uses models (signatures) of unacceptable system activities (system behavior)

Watches user activities Watches for deviations from model behavior

Raises alarm upon detection of suspicious behavior If false alarm, admin can „teach” IDS to accept

such behavior in the future

117Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Types of IDSs (5)

Example model of acceptable user’s behavior Logs in Reads e-mail Use word processor ...

Note: Use of sensitive system management utilities

by a user would be a deviation from the above model of acceptable user’s behavior, causing an

alarm- Even if such use is legitimate

118Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Types of IDSs (6)

(ii-1) Misuse IDS — can be considered a subset of anomaly detection IDS (since misuse is a subset of anomaly – see above)

Uses model of unacceptable user behavior Recall that „regular” anomaly-based IDS uses models

of acceptable user behavior Recall that signature-based IDS uses models

(signatures) of unacceptable system activities (system behavior) Could misuse IDS be considered a subset of

signature-based IDS? Only if consider user behavior a subset of

system behavior

Example model of unacceptable user’s behavior Attempt to copy pwd file Attempt to open pwd file ...

119Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Types of IDSs (7)

iii. Other IDSs E.g., hybrid IDSs (combining signature- and

anomaly-based IDSs), immune-system-based IDSs

++SKIP++ Under a more liberal definiton of IDS, the following are called IDSs:

Tripwire program — cf. p. 488 (ed.4) Produces hash value for each file when installed,

values saved in secure place Later can be called to verify that file was not

compromised Vulnerability scanners Honeypots

120Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

c. Goals for IDSs (1)

IDS goals 1) Detect all attacks correctly

Avoid false positives (false alarms) False alarms annoy sysadmins, users, ...

Avoid false negatives (not recognizing attacks)

2) Little overhead / performance impacts

++SKIP++ Range of IDS alarms Write a record to audit log ... Page security administrator

Urgency

121Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

++SKIP++ Goals for IDSs (2) Categories of IDS responses

1) Monitor, collect data, collect more data For attacks with modest impact Invisible to attacker Can be used to study attacker’s actions (like

honeypot)

2) Protect, reduce exposure E.g., making certain files unavailable to any

access May be very visible to attacker

3) Call a human For attacks with highest impact potential Calling a human usually preceded by some

automatic actions Since humans take very long time (compared to

computer time) to respond

Any combination of (1), (2) , (3) into single response is possible

122Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

--SKIP-- d. IDS strengths and limitations

IDS strengths Becoming more effective (e.g., DBs of attack

signatures grow) Becoming cheaper Becoming easier to administer

IDS limitations Attackers use avoidance strategies to avoid

detection by IDS IDS sensitivity is difficult to measure and adjust

Must strike a balance false alarms and missing attacks Only as good as the process/people using it

123Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

5.2.3. Secure E-Mail

Outlinea) Introductionb) Security for e-mailc) Design of PEM (Privacy-enhanced Electronic Mail)d) Example secure e-mail systems

i. PGPii. S/MIME

124Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

a. Introduction E-mail is the most heavily used network-based

applicationYet, ordinary email is very public, exposedIt has no C / I (confid./integ)

Unencrypted message contents can be peeked at either in transit or by privileged users at destination host

125Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

b. Security for e-mail (1)

--SKIP-- Threats to e-mail Controls Msg interception (confidentiality) encryption Msg interception (blocked delivery) no S/R controls Msg interception+replay encryption (+seq.nr) Msg content modification encryption Msg origin modification encryption

Msg content forgery by outsider encryption Msg origin forgery by outsider encryption

Msg content forgery by recipient (R) publ.key encr. Msg origin forgery by recipient publ.key encr.

Repudiation (denial) by sender (S) publ.key encr.

126Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Security for e-mail (2)

Secure e-mail requirements: Msg confidentiality (protection from disclosure)

Msg integrity (protection from modification) Sender authentication Non-repudiation (preventing denial by sender)

Not every msg requires all 4 capabilitiesbut all 4 needed to cover requirements of all kinds of msgs

127Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

c. Design of PEM (1) Standard for encrypted e-mail:

Privacy-enhanced Electronic Mail (PEM) [Bishop-CS-A&S, p.286]

Developed by Internet Society (1985-1993)

A design goal: Allowing PEM msgs travel as ordinary mail msgs

For legacy reasons Protection occurs within msg body

We’ll look in turn at:1) Confidentiality in PEM2) Other security features in PEM

128Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Design of PEM (2)

1) Confidentiality in PEM Scenario: S sends msg M to R (using PEM)

S picks random symm.encr. key K (corr. to session key)

S creates new cleartext header [a] S encrypts K with KPUB-R: E(K, KPUB-R) [b]

Additionally, unprintable characters are converted into „regular” characters Since unprintable characters used as control signals by

e-mail handlers S encrypts M with K: E(M, K) [c]

Entire M, with original header is encrypted

=> Summarizing, „enveloping” msg sent by S to R is:

[a] = new „external” header (plaintext)

[b] = encrypted symm. key K

[c] = encrypted msg M(cf. Fig. 7-43, p. 492-ed.4)

129Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

---SKIP--- Design of PEM (3)

Example of subfields within field [b]: (M = original msg)

Proc-Type:indicates applied privacy-enhancement services (e.g., „ENCRYPTED”)

DEK-Info: (DEK=data encipherment key, corr. to session key)

includes symmetric key K (used to encr. M)

ANDindicates kind of corresponding symmetric key encr. alg. (e.g., DES-CBC)

Actually not just K but whole field [b] (including K) is encrypted under KPUB-R,that is, E([b], KPUB-R )

Variant of PEM standard: Using only symmetric key encryption

Requires establishing common secret before sending e-mail

130Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Design of PEM (4)

2) Other security features in PEM PEM msgs always carry a digital signature in [b]

Provide S’s authentication & non-repudiation Hash within digital signature assures msg

integrity S can be anonymous in external header [a]

S’s identity encrypted in [c]

Multiple encryption algorithms are supported by PEM

„Unenhanced” & and PEM msgs can be mixed by sender at will

131Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

Design of PEM (5)

Problems with PEM Problem 1: key mgmt (as always with public key

exchange) Solution 1a: Using certificate scheme Solution 1b: Using PGP (to be discussed next)

Problem 2: endpoint vulnerability (S and R ends) Attacker penetrating S’s or R’s host can

subvert PEM code or install Trojan for leaking keys

132Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

++SKIP++ d. Example secure e-mail systems (1)

Many encrypted e-mail systems exist (both academic and commercial)

Two popular encrypted e-mail systems:i. PGP (Pretty Good Privacy)ii. --SKIP-- S/MIME

133Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

++SKIP++ Example secure e-mail systems (2)

i. PGP (Pretty Good Privacy) Widely used, de facto secure email standard

Available on most operating systems Originally free Commercial versions available

Confidentiality — IDEA encryption (IDEA = International Data Encryption Algorithm; popular in Europe)

Integrity – RSA-encrypted MIC (Message Integrity Check/hash, MD5)

Authentication & non-repudiation – RSA-encrypted MIC

Uses common key distribution channels Trusted „introducers” used to validate keys

No CA (certification authority) hierarchy needed

134Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

++SKIP++ Example secure e-mail systems (3)

PGP in practice The application must be integrated into

existing email Each user exchanging keys with all potential

recipients Establishing a keyring - a ring of trusted

recipients User’s keyring of known keys

Containing public and private keys (protected

by a password) Public keys given to you directly by a friend Public keys signed by trusted introducers

Keys used for signing or encrypting messages to be sent and validate messages received

135Sect

ion

5 –

Com

pu

ter

Secu

rity

an

d In

form

ati

on

Ass

ura

nce

© 20

06

-20

10

by L

esz

ek

T. L

ilien

--SKIP-- Example secure e-mail systems (4)

ii. S/MIME Internet standard for secure e-mail attachments Very much like PGP Principal difference: method of key exchange

PGP: user exchanging keys with all potential recipients Establishing ring of trusted recipients

S/MIME: uses hierarchically validated certificates for key exchange Usually in X.509 format=> S and R do not have to exchange keys in advance if have a common trusted certifier

Supports many ciphers, incl. DES, AES, RC2 Integrated into many commercial e-mail

packages=> likely to dominate the secure e-mail market

The End of Section 5 (Ch. 7 - Part 2): Network Security

(incl. OPTIONAL details that you may SKIP)

Google Earth.lnk