Security in EIS. The Future. This lecture. Jonny Pettersson 29/4 2010

(1)

Security in EIS

29/4 - 10 Design av samverkande system - Jonny Pettersson 1

Jonny Pettersson

29/4 2010

The Future

The world is never going to be perfect,

either on- or offline; so let´s not set

impossibly high standards for online.

- Esther Dyson

This lecture

• System

• Security services

• Security policies

y p

• Assumption, trust, assurance, risk

• Authentication

(2)

Security in EIS

• What is a system?

– A product or component

– The above + OS, communications, etc – The above + one or more applications

pp – Any or all of the above + IT staff

– Any or all of the above + internal users and management – Any or all of the above + customers and other external

users

– Any or all of the above + the surrounding environment including the media, competitors, regulators, and politicians

EIS

Principle of Easiest Penetration

Principle of Easiest Penetration: An intruder must be expected to use any available means of penetration.

Thi i t il th t b i i

This is not necessarily the most obvious means, nor is it necessarily the one against which the most solid defence has been installed.

(3)

The Basic Components

• Confidentiality

– The concealment of information or resources – Also applies to the existence of data

29/4 - 10 Design av samverkande system - Jonny Pettersson 7 – Resource hiding

– Assumptions and trust underlie confidentiality mechanisms

Def. Let X be a set of entities and let I be some information. Then I has the property of confidentiality with respect to X if no member of X can obtain information about I.

The Basic Components (2)

• Integrity

– The trustworthiness of data or resources – Two classes:

• prevention mechanisms

• detection mechanisms

– Relies on assumptions about

• the source of the data • the trust in that source

Def. Let X be a set of entities and let I be some information or a resource. Then I has the property of integrity with respect to X if all members of X trust I.

The Basic Components (3)

• Availability

– The ability to use the information or resource desired

R li bilit

29/4 - 10 Design av samverkande system - Jonny Pettersson 9 – Reliability

Def. Let X be a set of entities and let I be a resource. Then I has the property of availability with respect to X if all members of X can access I.

(4)

Policy and Mechanism

• An example:

– Umeå University forbids copying some other student

A t d t th t th t d t h t

29/4 - 10 Design av samverkande system - Jonny Pettersson 10 – A student sees that another student have not

read protected its files and copies them. – Is anyone (or both) violating the security?

Policy and Mechanism (2)

Def. A security policy is a statement of what is, and

what is not, allowed. A security policy defines

“secure” for a system or a set of system.

• Purpose, goal, responsibilities, a foundation

for the choice of security mechanisms, …

• Mechanisms can be nontechnical

Def. A security mechanism is an entity or procedure

that enforces some part of the security policy.

The Role of Trust

• An example: A system administrator

receives a security patch

– Assumes that the patch came from the vendor and was not tampered in transit

A h h d d h h

– Assumes that the vendor tested the patch thoroughly

– Assumes that the vendor’s test environment corresponds to her environment

– Assumes that the patch is installed correctly

• Any

security policy, mechanism, or

(5)

Assumptions and Trust

• How does we determine if the policy

correctly describes the required level and

type of security for the system?

• Security rests on assumptions

• Policy and assumptions

– The policy divides the system in secure and nonsecure states

– The security mechanisms prevent the system from entering a nonsecure state

Assumptions and Trust (2)

• Trusting that mechanisms work requires

several assumptions

1. Each mechanism is designed to implement one

t f th it li

29/4 - 10 Design av samverkande system - Jonny Pettersson 14 or more parts of the security policy

2. The union of the mechanisms implements all aspects of the security policy

3. The mechanisms are implemented correctly 4. The mechanisms are installed and

administered correctly

Assurance

• An attempt to provide a basis for

bolstering how much one can trust a system

• Requires specific steps to ensure that the

system will function properly

– Detailed specifications of the desired behavior – An analysis of the design of the components – Arguments or proofs that all “implementations”

produce the desired behavior

Def. A system is said to satisfy a specification if the specification correctly states how the system will function.

(6)

Operational Issues

• Risk analysis

– The level of protection is a function of the probability of an attack occurring and the effects of the attack should it succeed

29/4 - 10 Design av samverkande system - Jonny Pettersson 16 effects of the attack should it succeed – Risk is a function of environment – The risks change with time

– Many risks are quite remote but still exist

Autenticering

• Användaridentifiering

– Kunskap - Något man känner till

– Tillhörighet - Något man har Säkrare

29/4 - 10 Design av samverkande system - Jonny Pettersson 17 – Egenskap - Något man är

• För säkrare

– Kombinera 2 eller 3

• Man kan även använda

– Var man är

Något man känner till

• Betyder för det mesta passwords

– Ofta grund för säkerheten

– Många passwords blir det…

• Psykologiska problem

• Social Engineering

• Operationella frågor

(7)

Password-attacker

• Titta över axeln

• Avlyssning

• Falskt log-on program

g

p g

• Loggar

• Stöld av password-databasen

• On-line gissning

• Off-line gissning

Password guessing

• “Humans are incapable of securely storing high-quality cryptographic keys, and they have unacceptable speed and accuracy when performing cryptographic operations. They are also large, expensive to maintain, difficult to manage, and

p g

they pollute the environment. It is astonishing that these devices continue to be manufactured and deployed, but they are sufficiently pervasive that we must design our protocols around their limitations”

– Network Security: Private Communication in a Public World

Något man har

• Passiva enheter

– Fysisk nyckel – Magnetkort

• Smart cards

– PIN aktiverat minne – Specialläsare

• Krypto på kort

(8)

Något man är

• Biometriska enheter

– Signaturverifierare – Ansiktsscanner

29/4 - 10 Design av samverkande system - Jonny Pettersson 22 – Fingeravtrycksläsare

– Ögonscanner – Röstigenkännare

Biometri

• Problem

– Noice, collusion, false repudiation, statistik, individuella skillnader, religon, …

• Begränsningar

Begränsningar

– Dyra

– Användarna gillar dem inte

– Ej användbart för nätverksautenticering

• Funkar bäst som komplement (bemannade)

• Avskräckande användning är bra

Säkerhetsprotokoll

• Det som håller ihop

Security Engineering

• Antaganden görs – kan inte skydda mot allt

• Utvärdera protokoll

p

– Är hotmodellen realistisk? – Hanterar protokollet hoten? – Har omgivningen förändrats?

– Små missar i protokollet kan ge allvarliga konsekvenser

(9)

Schneier om PKI och SSL

• Secrets and Lies, s239

– ”As it is used, with the average user not bothering to verify the certificates and no revocation mechanism SSL is just simply a

29/4 - 10 Design av samverkande system - Jonny Pettersson 25 revocation mechanism, SSL is just simply a (very slow) Diffie-Hellman key-exchange method. Digital certificates provide no actual security for electronic commerce; it’s a complete sham.”

Design principles

• Specific design principles underlie the design and implementation of security mechanisms

• Build on simplicity

– Makes it easier to understand

– Makes it easier to understand – Less can go wrong

– Reduces the potential for inconsistencies

• and restriction

– Minimizes the interaction of system component – Minimizes the power of an entity

Principle of Least Privilege

Def. The principle of least privilege states that a subject should be given only those privileges it needs in order to complete its task.

29/4 - 10 Design av samverkande system - Jonny Pettersson 27 • The function of the subject should control the

assignment of rights

• Rights should be removed when not needed any more

• Example:

(10)

Principle of Fail-Safe Defaults

Def. The principle of fail-safe defaults states that, unless a subject is given explicit access to an object, it should be denied access to that object.

29/4 - 10 Design av samverkande system - Jonny Pettersson 28 • The default access should be none

• In case of failure, changes should be undone • Example:

– Mail server and the spool directory

Principle of Economy of Mechanism

• Simple design and implementation Æ fewer errors Def. The principle of economy of mechanism states that security mechanisms should be as simple as possible.

29/4 - 10 Design av samverkande system - Jonny Pettersson 29 Simple design and implementation Æ fewer errors • Interfaces to other modules are suspect

– Implicit assumptions about input or output parameters or the current system state

• Example:

– Replace the fingerserver

Principle of Complete Mediation

R t i t th hi f i f ti

Def. The principle of complete mediation requires that all accesses to objects be checked to ensure that they are allowed.

• Restricts the caching of information • When a subject attempts to read a object

– First attempt: Allowed?

– Second attempt: a new check should be done

• Example:

(11)

Principle of Open Design

N ”s

it th

h bs

it ”

Def. The principle of open design states that the security of a mechanism should not depend on the secrecy of its design or implementation.

• No ”security through obscurity”

• (”Dumpster-diving”)

• Especially true of cryptographic software

and systems

• Example:

– DVD and the Content Scrambling System

Principle of Separation of Privilege

M th diti h ld b t

Def. The principle of separation of privilege states that a system should not grant permission based on a single condition.

29/4 - 10 Design av samverkande system - Jonny Pettersson 32 • More than one condition should be met

• Provides a fine-grained control over a resource • Provides additional assurance that the access is

authorized • Example:

– Banking

Principle of Least Common Mechanism

Li it h i

Def. The principle of least common mechanism states that mechanisms used to access resources should not be shared.

29/4 - 10 Design av samverkande system - Jonny Pettersson 33 • Limits sharing

• Sharing resources can provide a information channel

• Example:

(12)

Principle of Psychological Acceptability

Def. The principle of psychological acceptability states that security mechanisms should not make the resource more difficult to access than if the security mechanisms were not present.

29/4 - 10 Design av samverkande system - Jonny Pettersson 34 • Configuring and executing a program should be as

easy and as intuitive as possible

• Output should be clear, direct, and useful • The ”security” burden must be both minimal and

reasonable • Example:

– Password and error messages

This lecture

• System

– Including peoples

• Security services

– Confidentiality, integrity, availability

S it p li i s

29/4 - 10 Design av samverkande system - Jonny Pettersson 35 • Security policies

– Security mechanisms implements policies

• Assumption, trust, assurance, risk

– It is all about risk and trust

• Authentication

– First authenticate, then see what they are allowed to do

• Design principles