1 Principle of Easiest Penetration Principle of Easiest Penetration: - PDF document

The Course So Far • Middleware • Time • Global states • Coordination • Multicast • Consensus • Replication • Transactions 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 1 Security in the Course • Lectures – Introduction (today) – Threat analysis (today) – Introduction to access control matrix (today) – Security policies – Cryptography – Key management – Authentication – Design principles – Access control mechanisms – Assurance – The future • Literature 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 2 Security in Distributed Systems • 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 surronding environment including the media, competitors, regulators, and politicians 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 3 1

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 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 4 The Basic Components • Confidentiality – The concealment of information or resources – Supported by access control mechanisms – Also applies to the existence of data – Resource hiding – Assumptions and trust underlie confidentiality mechanisms 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 5 The Basic Components (2) • Integrity – The trustworthiness of data or resources – Includes both data integrity and origin integrity – Two classes: • prevention mechanisms • detection mechanisms – Relies on assumptions about • the source of the data • the trust in that source 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 6 2

The Basic Components (3) • Availability – The ability to use the information or resource desired – Reliability – System design – Hard to detect 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 7 Threats • Threat – a potential Information Information source destination violation of security A B Normal flow • Attacks, attacker A B Interruption • A classification of A B Interception threats (Shirey) C – Disclosure – Deception A B Modification – Disruption C – Usurpation A B Fabrication C 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 8 Threats (2) • Some threats – Snooping (disclosure) • Confidentiality – Modification, alteration (deception, disruption, usurpation) • Integrity – Masquerading, spoofing (deception, usurpation) • Integrity – Delegation • One entity authorizes a second entity to perform functions on its behalf • Not a violation of security 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 9 3

Threats (3) • Some threats (cont.) – Repudiation of origin (deception) • Integrity – Denial of receipt (deception) • Integrity and availability – Delay (usurpation, deception) • Availability – Denial of service (usurpation, deception) • Availability 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 10 Threats (4) Release of message contents • Passive attacks Passive threats Traffic analysis – Hard to detect – Prevent • Active attacks Masquerade – Easier to detect – Hard to prevent Replay – Detect - Recover Active threats Modification of message contents Denial of service 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 11 Policy and Mechanism • An example: – Umeå University forbids copying some other student – A student sees that another student have not read protected its files and copies them. – Is anyone (or both) violating the security? 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 12 4

Policy and Mechanism (2) Def. A security policy is a statement of what is, and what is not, allowed. • Policy language? • Two cooperating entities? Def. A security mechanism is a method, tool, or procedure for enforcing a security policy. • Mechanisms can be nontechnical 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 13 Goals of Security • Prevention – Preventive mechanism are often a hinder • Detection – Do not prevent compromises of the system • Recovery – Stop an attack – Assess and repair any damage – Recovery is complex – Retaliation? 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 14 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 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 15 5

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 administred correctly 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 16 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. 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 17 Assurance (2) • A specification is a statement of the desired functioning of the system – Formal or informal – Can be low-level – The set of requirements relevant to the system’s planned use 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 18 6

Assurance (3) • The design of a system translates the specifications into components that will implement them – The design must satisfy the specification 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 19 Assurance (4) • Given a design, the implementation creates a system that satisfies that design – Difficult proving that a program correctly implements the design (and, in turn, the specifications) – Proving correctness is hard, often testing is used instead Def. A program is correct if its implementation performs as specified. 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 20 Operational Issues • Cost-Benefit analysis – Depends on the mechanism chosen to implement a particular security service and on the mechanisms chosen to implement other security services – Adding security mechanism is more expensive than designing them into the system in the first place 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 21 7

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 – Analysis paralysis – making risk analyses with no effort to act on those analyses 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 22 Operational Issues • Laws and customs – Restrictions on availability and use of technology – Laws of multiple jurisdictions – Legal vs. acceptable practices – Psychological acceptability 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 23 Human Issues • Organizational problems – Security provides no direct financial reward – Security controls often add complexity – Is security worth it? – Clear chains of responsibility and power – Which people are trained in security? – Lack of resources 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 24 8

Human Issues (2) • People problems – The heart of any security system is people • Insiders – More access to resources – Careless/untrained users and system administrators – Users that steal – Users assisting external attacks • Outsiders – Social engineering 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 25 Tying It All Together Threats Policy Specification Design Implementation Operation and Maintenance 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 26 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 4/10 - 05 Distributed systems - Jonny Pettersson, UmU 27 9