security engineering, iitg 2008 © wk - 1 - security engineering winfried kühnhauser winfried e....

Security Engineering, IITG 2008 © wk - 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


Problem Statement

Problem StatementWhy 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


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


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


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


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


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

ResultRoot kit´s actions, processes, files, communication connections become invisible

Problem Statement


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


ResultsAttacker has access to infected system at any time untraceable undiscoverable highly privileged extremely fast unstoppable

Problem Statement


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 engineeringProblem Statement


informal security policy

formal security model

security mechanisms and architecture

Security Engineering

The Security Engineering Process

security goals

risk analysis

counteravoid accept

START

modelling goals- policy analysis (completenes,consistency, invariants)

- starting point for policyimplementation

modelling techniques

policy implementation (correctness,total mediation, tamperproofness) in next talk (Anja Fischer):

„A Web Services Security Architecture“

Security Engineering


Security Models

They areFormal models of security policies

Their GoalRigorous 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


A Hospital Information Management System: Security Policy Excerpt

An Example

EPR

Anamn. Sympt. Diag Therapy Care KitchenPatId

Brother TuckNurse Kathy Paul Bocuse

Dr. Brains

Apothecary Roentgen Lab MR Lab Pathology Kitchen Billing

Dr. Bones


>> 10.000 information flow rules

> 100 obvious conflicts

> 100 detected system states uncovered by policy


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


So once again: Security Model´s GoalsRigorous 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



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

Brother TuckNurse Kathy Paul Bocuse

EPR

Dr. Brains

Anamn. Sympt. Diag Therapy Care KitchenPatId

Apothecary Roentgen Lab MagSpin Lab Pathology Kitchen Billing

Dr. Bones



HRU Security Modelsconsist of an access matrix, modelling information flow in a given system state a state machine, modelling system state transitions

Safety AnalysisGiven 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



Another Example: Information Flow Models

Implementaion Correctness

The ProblemModel´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 solutionInformation 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 Model Implementation

Security ArchitectureSubset of system architecture implementing the security properties walls turrets doors buildings (food repository, armory)

Security Engineering: Security Architectures


The SELinux Security Architecture

application processapplication process application process

resource management

processing resources storage resources communication resources

Application Programmer‘s Interface

OS services socketsfile systems . . .processesIntc. Intc. Intc.

Security Serverpolicypolicy


Security Server implemented within kernel protection domain tamperproof

Interceptors controlling interface of kernel object managers total mediation control


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



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

security engineering, iitg 2008 © wk - 1 - security engineering winfried kühnhauser winfried e....

Documents