Security in EIS Jonny Pettersson 29/4 2010 29/4-10 Design av samverkande system - Jonny Pettersson 1 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 29/4-10 Design av samverkande system - Jonny Pettersson 2 This lecture System Security services Security ypolicies Assumption, trust, assurance, risk Authentication Design principles 29/4-10 Design av samverkande system - Jonny Pettersson 3 1
Security in EIS What is a system? A product or component The above + OS, communications, etc The above + one or more applications 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 29/4-10 Design av samverkande system - Jonny Pettersson 4 EIS 29/4-10 Design av samverkande system - Jonny Pettersson 5 Principle of Easiest Penetration Principle of Easiest Penetration: An intruder must be expected to use any available means of penetration. This is not necessarily the most obvious means, nor is it necessarily the one against which the most solid defence has been installed. Pfleeger, 1997 29/4-10 Design av samverkande system - Jonny Pettersson 6 2
The Basic Components Confidentiality The concealment of information or resources Also applies to the existence of data 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. 29/4-10 Design av samverkande system - Jonny Pettersson 7 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. 29/4-10 Design av samverkande system - Jonny Pettersson 8 The Basic Components (3) Availability The ability to use the information or resource desired 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. 29/4-10 Design av samverkande system - Jonny Pettersson 9 3
Policy and Mechanism An example: Umeå University forbids copying some other student A student t sees that t another student t have not read protected its files and copies them. Is anyone (or both) violating the security? 29/4-10 Design av samverkande system - Jonny Pettersson 10 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, Def. A security mechanism is an entity or procedure that enforces some part of the security policy. Mechanisms can be nontechnical 29/4-10 Design av samverkande system - Jonny Pettersson 11 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 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 procedure is based on assumptions 29/4-10 Design av samverkande system - Jonny Pettersson 12 4
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 29/4-10 Design av samverkande system - Jonny Pettersson 13 Assumptions and Trust (2) Trusting that mechanisms work requires several assumptions 1. Each mechanism is designed to implement one 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 29/4-10 Design av samverkande system - Jonny Pettersson 14 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. 29/4-10 Design av samverkande system - Jonny Pettersson 15 5
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 Risk is a function of environment The risks change with time Many risks are quite remote but still exist 29/4-10 Design av samverkande system - Jonny Pettersson 16 Autenticering Användaridentifiering Kunskap - Något man känner till Tillhörighet - Något man har Säkrare Egenskap - Något man är För säkrare Kombinera 2 eller 3 Man kan även använda Var man är 29/4-10 Design av samverkande system - Jonny Pettersson 17 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 29/4-10 Design av samverkande system - Jonny Pettersson 18 6
Password-attacker Titta över axeln Avlyssning Falskt log-on program Loggar Stöld av password-databasen On-line gissning Off-line gissning 29/4-10 Design av samverkande system - Jonny Pettersson 19 Password guessing Humans are incapable of securely storing highquality cryptographic keys, and they have unacceptable speed and accuracy when performing cryptographic operations. They are also large, expensive to maintain, difficult to manage, and 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 29/4-10 Design av samverkande system - Jonny Pettersson 20 Något man har Passiva enheter Fysisk nyckel Magnetkort Smart cards PIN aktiverat minne Specialläsare Krypto på kort Hemligheten behöver aldrig lämna kortet 29/4-10 Design av samverkande system - Jonny Pettersson 21 7
Något man är Biometriska enheter Signaturverifierare Ansiktsscanner Fingeravtrycksläsare Ögonscanner Röstigenkännare 29/4-10 Design av samverkande system - Jonny Pettersson 22 Biometri Problem Noice, collusion, false repudiation, statistik, individuella skillnader, religon, 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 29/4-10 Design av samverkande system - Jonny Pettersson 23 Säkerhetsprotokoll Det som håller ihop Security Engineering Antaganden görs kan inte skydda mot allt Utvärdera protokoll Är hotmodellen realistisk? Hanterar protokollet hoten? Har omgivningen förändrats? Små missar i protokollet kan ge allvarliga konsekvenser 29/4-10 Design av samverkande system - Jonny Pettersson 24 8
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 (very slow) Diffie-Hellman key-exchange method. Digital certificates provide no actual security for electronic commerce; it s a complete sham. 29/4-10 Design av samverkande system - Jonny Pettersson 25 Design principles Specific design principles underlie the design and implementation of security mechanisms Build on simplicity 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 29/4-10 Design av samverkande system - Jonny Pettersson 26 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. The function of the subject should control the assignment of rights Rights should be removed when not needed any more Mail server and file access 29/4-10 Design av samverkande system - Jonny Pettersson 27 9
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. The default access should be none In case of failure, changes should be undone Mail server and the spool directory 29/4-10 Design av samverkande system - Jonny Pettersson 28 Principle of Economy of Mechanism Def. The principle of economy of mechanism states that security mechanisms should be as simple as possible. Simple design and implementation fewer errors Interfaces to other modules are suspect Implicit assumptions about input or output parameters or the current system state Replace the finger server 29/4-10 Design av samverkande system - Jonny Pettersson 29 Principle of Complete Mediation Def. The principle of complete mediation requires that all accesses to objects be checked to ensure that they are allowed. Restricts t the caching of information When a subject attempts to read a object First attempt: Allowed? Second attempt: a new check should be done Unix and file descriptors 29/4-10 Design av samverkande system - Jonny Pettersson 30 10
Principle of Open Design 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 h obscurity ( Dumpster-diving ) Especially true of cryptographic software and systems DVD and the Content Scrambling System 29/4-10 Design av samverkande system - Jonny Pettersson 31 Principle of Separation of Privilege Def. The principle of separation of privilege states that a system should not grant permission based on a single condition. More than one condition should be met Provides a fine-grained control over a resource Provides additional assurance that the access is authorized Banking 29/4-10 Design av samverkande system - Jonny Pettersson 32 Principle of Least Common Mechanism Def. The principle of least common mechanism states that mechanisms used to access resources should not be shared. Limits it sharing Sharing resources can provide a information channel One universal smart card or many smart cards 29/4-10 Design av samverkande system - Jonny Pettersson 33 11
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. 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 Password and error messages 29/4-10 Design av samverkande system - Jonny Pettersson 34 This lecture System Including peoples Security services Confidentiality, integrity, availability Security policies i 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 Things to think about 29/4-10 Design av samverkande system - Jonny Pettersson 35 12