Security Engineering Winfried Kühnhauser

1. Security EngineeringWinfried Kühnhauser Winfried E. Kühnhauser Computer Science Institute Technical University of Ilmenau The methodical approach for the specification and implementation of security goals

2. Problem Statement Problem Statement Why is security an engineering problem? Why must security be approached methodically? Why not just plug together • authentication mechanisms • authorisation mechanisms • cryptographic protocols and algorithms?  The 30 Billion € Problem (= 1.500.000.000.000 Rupies) Problem Statement

3. The 30 Billion € Problem • year 2007: 20 Billion € loss due to industrial espionage (calculated by ASW*)) • year 2008: 30 Billion € loss (predicted) • attacks on IT systems play the most important role • attackers are mostly foreign intelligence services • social engineering  insider attacks • systems and communication attacks  outsider attacks *) Working Group for Security in Economics, 4 Mill. members  sophisticated people using sophisticated attack strategies Problem Statement

4. Attack Strategies: Root Kits Root Kits • tool boxes for automated attacks on IT systems • their goal: complete, invisible and everlasting control Tools in the Box • fully automated vulnerability detection • fully automated attack management • fully automated backdoor installation • fully automated camouflage Problem Statement

5. Step One: Vulnerability Detection • tools look for vulnerabilities of • active and privileged services and demons (from outside: by sophisticated port scans) • ssh/slogin, ftp, ntp, ... • maild, inetd, smbd, ... • configuration vulnerabilities • weak passwords, open communication ports • OS manufacturer and version • know implementation faults • knowledge base • large vulnerability data base Result • one or more vulnerabilities • attack method and corresponding tools (next step, toolbox section 2) Problem Statement

6. Step Two: Attack Management • exploit vulnerability so that • server or daemons • OS executes attacker´s tailored and prefabricated code with root privileges • install/exchange prefabricated software • servers and daemons • utilities • OS modules containing • backdoors • smoke bombs (next page) Results • high-privileged access to attacked system within fractions of seconds • system modified with attacker´s servers, utilities, and OS modules • smoke bombs that conceal these modifications Problem Statement

7. Smoke Bombs for Ongoing Attack • disinfect logfiles (don´t show root kit processes, connections) • syslog, kern.log, user.log, daemon.log, auth.log , ... • modified system management utilities • process management (don´t show running root kit processes) • Unix: e.g. ps, top, ksysguard; Windows: task manager • file system (don´t show root kit files) • ls, explorer • network state (don´t show root kit communication connections) • netstat, ifconfig, ipconfig, iwconfig • exchange OS modules (don´t show root kit procs, files, connections) • Unix: /proc/..., stat, fstat, pstat Result Root kit´s actions, processes, files, communication connections become invisible Problem Statement

8. Sustainability • backdoor installations for future calls • in servers (ssh) • in utilities (login) • in libraries (PAM, pluggable auth. modules) • in the OS • more smoke bombs for • concealing server, utitility and library modifications • concealing OS modifications • modifications of utilities and OS to prevent • killing of root kit processes and connections (kill, signal) • removal of root kit files (rm, unlink) Problem Statement

9. Results Attacker has access to infected system • at any time • untraceable • undiscoverable • highly privileged • extremely fast • unstoppable Problem Statement

10. The Message Risk and Damage Potential • chances of success: extremely high in today´s systems • speed • sophistication • methodical, automated approach • chances of defense: extremely low • speed • cause for vulnerabilities (programming errors, loop holes) • smoke bombs • chances of system disinfection after attack: approaching zero • smoke bombs, OS infection Chances of Prevention • reactive  use same weapons: vulnerability detection and elimination (carry on what we do for more than 20 years  the 30 Billion € problem...) • preventive  methodical security engineering Problem Statement

11. modelling goals • policy analysis (completenes, • consistency, invariants) • starting point for policy • implementation • modelling techniques policy implementation (correctness, total mediation, tamperproofness) in next talk (Anja Fischer): „A Web Services Security Architecture“ Security Engineering The Security Engineering Process START risk analysis avoid counter accept security goals informal security policy formal security model security mechanisms and architecture Security Engineering

12. Security Models They are Formal models of security policies Their Goal Rigorous analysis of • policy completeness • “Are there system states not covered by the policy?” • policy consistency • “Are there rules in the model that under certain circumstances may conflict?” • policy invariants • “Which security properties are guaranteed under any circumstances?” Security Engineering: Security Models

13. Dr. Brains Dr. Bones Nurse Kathy Brother Tuck Paul Bocuse Apothecary Roentgen Lab MR Lab Pathology Kitchen Billing An Example A Hospital Information Management System: Security Policy Excerpt EPR PatId Anamn. Sympt. Diag Therapy Care Kitchen >> 10.000 information flow rules > 100 obvious conflicts > 100 detected system states uncovered by policy Security Engineering: Security Models

14. Another Example The Lisa Files • test goal: point out dangers of intuition • candidates: top and medium level IT security management • goes like this: Linda is a clever, active student, ... , member of student organisations, ..., always in the first line when it comes to defending student rights, ... o Linda works at the counter of a bank o . . . o Linda works at the counter of a bank and is an active member of a female interests group o . . . X  huge difference between intuition and objective truth Security Engineering: Security Models

15. So once again: Security Model´s Goals Rigorous analysis of • completeness • “Are there system states not covered by the policy?” • consistency • “Are there rules in the model that under certain circumstances may conflict?” • invariants • “Which security properties are guaranteed under any circumstances?” Examples  dangers of vagueness, faulty intuition, complexity Next • design and analysis: how security models help • implementation: how they are integrated into a security architecture Security Engineering: Security Models

16. Dr. Brains Dr. Bones EPR PatId Anamn. Sympt. Diag Therapy Care Kitchen Nurse Kathy Brother Tuck Paul Bocuse Apothecary Roentgen Lab MagSpin Lab Pathology Kitchen Billing An Example: HRU-Models The Safety Property • proliferation of access rights “Can it ever happen in the future that information will flow from EPR.Symptoms into the apothecary?”  model invariants analysis Security Engineering: Security Models

17. HRU Security Models consist of • an access matrix, modelling information flow in a given system state • a state machine, modelling system state transitions Safety Analysis Given some system state: is there an input sequence that will put the system (= the state machine) into a state where information may flow from Alice to Bob? Not Easy • decidability: safety problem of general HRU models is undecidable  HRU model subclasses  heuristics for given models • automated safety (right proliferation) analysis: algorithms Security Engineering: Security Models

18. Another Example: Information Flow Models Implementaion Correctness The Problem Model´s abstraction level • problem level: information flow definitions  HRU-models: clumsy, just read/write operations • implementation level: OS access control primitives  loss of semantics  correctness of mapping The solution Information flow models • operate on problem level • use lattices for information flow modelling • use theorems to prove correctness of lattice  OS access control mechs mapping Security Engineering: Security Models

19. Security Model Implementation Security Architecture Subset of system architecture implementing the security properties • walls • turrets • doors • buildings (food repository, armory) Security Engineering: Security Architectures

20. Intc. Intc. Intc. Security Server policy The SELinux Security Architecture application process application process application process Application Programmer‘s Interface OS services processes . . . file systems sockets resource management processing resources storage resources communication resources Security Server • implemented within kernel protection domain  tamperproof Interceptors • controlling interface of kernel object managers  total mediation control Security Engineering: Security Architectures

21. Architeture Design Based on General Policy Integration Rules (the “reference monitor principles”) • total access mediation • tamperproofness • simplicity Security Architecture for distributed systems: Anja´s talk Security Engineering: Security Architectures

22. Summary A Case for Security Engineering • methodical attacks  methodical prophylaxis • one piece of the puzzle: the role of security models • complexity • faulty intuition  formal analysis of vital properties • completeness, consistency • invariants: safety, correctness • another piece of the puzzle: security model implementation • the role of security architectures • more than just theoretical work • our university´s examination management system • a Web Services security architecture for an industrial environment Summary