Systems Security - Technische Universität IlmenauSystems Security, Summer 2018 ©wk -4-Influencing...

Systems Security, Summer 2018 © wk - 1 -

Winfried E. KühnhauserCSITechnische Universität Ilmenauwww.tu-ilmenau.de

Systems Security Chapter 2: Security Requirements

Winfried E. KühnhauserSummer 2018


Security Mechanisms

Security PoliciesModeling and Specification

Security Architectures

Security Requirements

2 Security Requirements


GoalMethod-driven� Identification and� Specificationof an IT system’s security properties



Influencing Factors� Codes and acts (depending on applicable law)

◆ German Data Protection Act (BDSG), US Sarbanes-Oxley Act (SarbOx)� Contracts

◆ With customers� Certification

◆ For information security management systems (ISO 27001)◆ Subject to German Digital Signature Act, to Common Criteria

� Company-specific guidelines and regulations◆ Access to critical data, permission assignment

� Company-specific Infrastructure and technical requirements◆ System architecture◆ Application systems




Vulnerability Analysis Threat Analysis

Risk Analysis

avoid deal with bear

Chapter OverviewTechnical Security Requirements Identification



GoalIdentification of� Technical� Organizational� Humanvulnerabilities of IT systems

2.1 Vulnerability Analysis

2.1 Vulnerability Analysis


Examples� Laziness

◆ Passwords on Post-It◆ Vista pop-up boxes

� Social Engineering◆ Your boss, your friend, poisoned daughter, important email

� Lack of knowledge◆ Importing malware◆ Indirect/hidden information flow in access control systems →

2.1.1 Human Vulnerabilities



Hidden Information Flow in Access Control Systems

ProjectXFiles

SalesFlyer

R&D

Sales

BobsNotes

To Sales

ProjectXBulletinBoard

Chris

Ann

Bob

X



Linux system, 3 users: Ann, Bob, Chris

2 groups:� CrewX: Ann (PM), Bob� Sales: Bob, Chris

Context: Linux access control system

rw- --- --- 1 Ann CrewX 2014-04-23 17:10 ProjectXFilesrw- r-- --- 1 Ann CrewX 2014-04-23 17:10 ProjectXBoardrw- r-- --- 1 Bob Sales 2014-04-23 17:10 BobsNotesToSalesrw- --- --- 1 Chris Sales 2014-04-23 17:10 SalesFlyer

Result■ All 3 users did set the permissions of their files perfectly - from their point of view■ All 3 together constructed a severe vulnerability

ProjectXFiles

SalesFlyer

R&D

Sales

BobsNotes

To Sales

ProjectX

BulletinBoard

Chris

Ann

Bob



ProjectXFiles

SalesFlyer

BobsNotes

To Sales

ProjectXBulletinBoard

Chris

Bob

AnnAnn

Bob

Sales

Chris

Ann

CrewX



Well? Effectiveness of Discretionary Access Control Systems?

Reasons� Limited knowledge of users

◆ Limited horizon◆ Limited problem awareness◆ Limited skills

� Problem complexity◆ Effects of individual discretionary access control to system-wide security

� Limited options of users◆ Archaic and inapt security mechanisms

→ No isolation of non-trusted software→ No enforcement of global security policies



Examples� Access to rooms

� Assignment of permissions◆ 4-Eyes principle

◆ Need-to-know principle

◆ Definition of roles

� Management of cryptographic keys

→ for issuing certificates

2.1.2 Organizational Vulnerabilities

2.1.2 Organizational Vulnerabilities


The Problem: Complex IT-Systems ...... will in foreseeable time not be � Specified completely, consistently, unambiguously, correctly

→ contain specification errors� Implemented correctly

→ contain implementation errors� Rebuilt every day (many security mechanisms of today’s systems are

older than 40 years)→ contain conceptual weaknesses and vulnerabilities

2.1.3 Technical Vulnerabilities



Example: Implementation Errorsin privileged system software� OS� sshd demons, Webservers etc.

ConsequencePrivileged software can be tricked into executing attacker‘s code

ApproachCleverly forged parameters overwrite procedure activation frames→ ”Buffer Overflow“ attack



Necessary knowledge� Source code (e.g. of a privileged server)� Symbol table of its executable� Compiler’s procedure call runtime management

It goes like this →



Method

ReturnIP

localBuffer

smalladresses

FramePtr

msgSize

*msg

i

.

.

.

environmentframes

currrentprocedure frame

Stack Layoutafter procedure call

largeadresses


void processSomeMsg(char *msg, int msgSize);

{ char localBuffer[1024];int i=0;while (i<msgSize) {

localBuffer[i] = msg[i];i++;

}...

}


smalladresses

Method

Stack Layoutafter procedure call

largeadresses

msg: “\0 … \0 / b i n / s h e l l #system“

1024 characters

void processSomeMsg(char *msg, int msgSize);



}...

}


ReturnIP

localBuffer

#system

\0 … \0“/bin/sh“

FramePtr

msgSize

*msg

.

.

.

environmentprocedure frame

currentprocedure frame

= system(“/bin/sh“)

i


Example: cgiBin attack on nullhttpd (simple Web server)� CGI (Common Gateway Interface): interface between Web server and trusted

auxiliary programs (“plugins”)

� Trusted CGI programs located in special directory („cgiDir“)� Code in nullhttpd for calling CGI program:

� Attack method: choose msg and msgSize such that cgiDir is overwritten

char cgiCommand[1024];char cgiDir[1024]=“/usr/nullhttpd/bin/cgiBin“;

void processCgiRequest(char *msg, int msgSize);{ int i=0;

while (i<msgSize) {cgiCommand[i] = msg[i];i++;

}execCgiRequest(cgiCommand, cgiDir);

}



Vulnerabilities� Human

◆ Laziness◆ Social Engineering◆ Lack of knowledge (e.g. malware attack methods, DAC)

� Organizational◆ key management, server room access

� Technical◆ Weak security paradigms◆ Specification and implementation errors

→ A zoo; practical assistance:Vulnerabilities catalogs ISO 27001, ISO 27002

2.1.4 Summary

2.1.4 Summary




Risk Analysis


2.1.4 Summary


GoalIdentification of� Attack objectives and attackers� Attack methods and practices→ know your enemy

ApproachCompilation of a threat catalog; content:� Identification of attack objectives� Identification of attackers� Attack methods and techniques� Damage potential

2.2 Threat Analysis

2.2 Threat Analysis


The Top-4 List

Attack Objectives� Economical and political power� Profit� Wreak havoc (water plants ...)� Meet a challenge

Attackers� Professional organizations (hired by competitors, foreign nations)� Active and former employees� Terrorists� Hackers

2.2.1 Attack Objectives and Attackers



Example: Economic Espionage� Attack objective: Economic and political power, money� Victims: High-tech industry� Attackers

◆ Competitors, foreign nations

◆ Insiders• Regular, often high-privileged access to IT systems• Large share (>40%)• Often indirect (”Only amateurs attack systems; professionals target

people“)• Age 30-40 years, male• Department heads, system administrators, programmers

→ Threats: Your own people!!

◆ Outsiders

→ Threats: Professional organizations



Example: Economic Espionage� Attack objective: Economic and political power, money� Victims: High-tech industry� Attackers

◆ Competitors, foreign nations

◆ Insiders• Regular, often high-privileged access to IT systems• Large share (>40%)• Often indirect (”Only amateurs attack systems; professionals target

people“)• Age 30-40 years, male• Department heads, system administrators, programmers

→ Threats: Your own people!!

◆ Outsiders

→ Threats: Professional organizations



Example: Personal Gain� Objective: to become rich (expensive life style, medical conditions)� Attackers

◆ Competitors◆ Insiders

• Age 40-50 years, peak of career reached, midlife crisis• Male

→ regular access to IT-Systems, insider knowledge

Example: Wreak Havoc� Objective: to destroy, to blackmail, to meet a challenge� Attackers: terrorists, avengers, psychos, hackers

→ no regular access to IT-Systems, no insider knowledge



Exploitation of Vulnerabilities (see 2.1)� Human

◆ Laziness, lack of knowledge, financial emergencies → Social Engineering

� Organizational

◆ Key management, server room access

� Technical

◆ Weak security paradigms, specification and implementation errors

2.2.2 Attack Methods



4 Example Szenarios

1st Scenario: Insider AttackAttack Method (see example in 2.1.1):� Social Engineering plus� Exploitation of conceptual DAC vulnerabilities plus� Tailored malware


ProjectXFiles

SalesFlyer

R&D

Sales

BobsNotes

To Sales

ProjectX

BulletinBoard

Chris

Ann

Bob

X


2nd Scenario: Malicious Programs; a Family Heirloom� Trojan horses

Programs with hidden functionality

◆ Computer virusesCode sequences in Trojan horses that contain a modification and duplication function, often accompanied by a function causing damage

◆ Logical bombsCode sequences in Trojan horses whose execution is triggered by a concrete event (→ Michelangelo, Chevron)

◆ BackdoorsCode sequences in Trojan horses whose execution is bound to a hidden functionality(→ login, ssh)

� Worms and worm segmentsAutonomous programs, self-duplicating; originally designed to make use of free computing power in local networks



3rd Scenario: Outsider AttackAttack Method (see example in 2.1.3):� Exploitation of Implementation Errors


ReturnIP

localBuffer

smalladresses

FramePtr

msgSize

*msg

.

.

.

environmentframes

currrentprocedure frame

largeadresses

#system

\0 … \0”/bin/sh“

system(”/bin/sh”)

ivoid processSomeMsg(char *msg, int msgSize);



}...

}


Professionalized Attacks

4th Scenario: Root Kits� Goal: Invisible, complete, and sustainable takeover of an IT system� Method: Tool kit for fully automated attacks

Tools for� Fully automated analysis of technical vulnerabilities� Fully automated attack management� Fully automated installation of backdoors� Fully automated stealth system



First Step: Vulnerability Analysis� Tools look for vulnerabilities in

◆ Active privileged services and demons (from outside: by port scans)

• Web server, remote access server (sshd), file server (ftpd), time server (ntpd), cupsd, bluetoothd, smbd, ...

◆ Configuration files

• Weak passwords, open ports

◆ Operating systems

• Versions with known implementation errors

� Using knowledge base

◆ Comprehensive vulnerability data base

Result� System-specific collection of vulnerabilities

→ choice of attack method and appropriate tools → second step

Attack Procedure



Second Step: Attack Management� Pre-phase: Fabrication of specialized software modules for vulnerability

exploitation such that◆ Some server or demon◆ The OS

will execute code of attacker with root privileges� This code

◆ First installs smoke-bombs for obscuring attack◆ Then replaces original system software by pre-fabricated modules

• Servers and demons• Utilities and libraries• OS modules

containing• Backdoors• Smoke-bombs for future attacks



Results� Backdoors allow for high-privilege access within fractions of seconds� System modified with attacker’s servers, demons, utilities, OS modules� Smoke-bombs in place for obscuring modifications as well as future

attacks



Smoke-bombs for ongoing attacks� Clean logfiles (entries for root kit processes, network connections)

◆ syslog, kern.log, user.log, daemon.log, auth.log, ...� Modify system admin utilities

◆ Process management (hide running root kit processes)• Unix: e.g. ps, top, ksysguard; Windows: task manager

◆ File system (hide root kit files)• ls, explorer, finder

◆ Network (hide active root kit connections)• netstat, ifconfig, ipconfig, iwconfig

� Substitute OS modules (hiding of running root kit processes, files, network connections)

◆ Unix: /proc/..., stat, fstat, pstat

ResultProcesses, files and communications of root kit become invisible



Sustainability� Backdoors for future visits anywhere in

◆ Servers (ssh demon)◆ Utilities (login)◆ Libraries (PAM, pluggable authentication modules)◆ The OS (system calls used by programs like sudo)

� Modifications of utilities and OS to prevent◆ Killing of root kit processes and connections (kill, signal)◆ Removal of root kit files (rm, unlink)

� More smoke-bombs for obscuring◆ Modifications of servers, demons, libraries, utilities, OS



ResultsHidden access to attacked system� Anytime� Well obscured� Highly privileged� Extremely fast� Virtually unpreventable



Messages

Risk and Damage Potential

� Prospect of success: Extremely high in today’s commodity OSes

◆ High number of vulnerabilities

◆ Speed

◆ Refined methodology

◆ Fully automated

� Defense against the dark arts: Extremely difficult

◆ High number of vulnerabilities(number of “security updates” last year?)

◆ Cause of vulnerabilities (specification/implementation errors, weak security mechanisms)

◆ Speed

◆ Smoke-bombs

� Prospects for recovering the system after successful attack: Near zero

◆ Smoke-bombs, OS modifications



Options for Prophylaxis� Reactive

◆ Well … (even your OS might have become your enemy)� Preventive

◆ Use same tools for vulnerability analysis(we do this for years now → the 50 Billion € problem...)

◆ Write correct software(we try this for years now → the 50 Billion € problem...)

→ Security Engineering◆ New paradigms

→ policy-controlled systems◆ Formal security models

→ reduction of specification errors and faults◆ Security architectures and small TCBs

→ reduction of implementation errors and faults2.2.2 Attack Methods


Industrial espionage

� Loss of political power, of control over critical knowledge

→ high-risk technologies

� Economical damage (contract penalties, loss of profit, damage to image): the 50.000.000.000 € problem, 40% IT *)

→ patent holders, technological leaders, exclusive providers

Personal gain

� Loss of money

Terrorism, hackers etc.

→ Critical infrastructures (energy, water plants, communication)

→ land/air transport infrastructure

→ financial systems

2.2.3 Damage Potential

*) Sources:Corporate Trust Business Risk & Crisis Management GmbHUniversität LüneburgVerfassungsschutz Report 2007, BfV

2.2.3 Damage Potential


Know Your Enemy� Attack goals and attackers

◆ Economical and political power, financial gain◆ Professional organizations, insiders und outsiders

� Attack methods und technics◆ Exploitation of human/organizational/technical vulnerabilities

→ a zoo; practical assistance:◆ national: BSI IT-Grundschutz Standards and Catalogues◆ international: Common Criteria

πάντα ῥεῖYoung topic→ numerous scientific publications (Risk Engineering)

2.2.4 Summary

2.2.4 Summary




Risk Analysis


2.2.4 Summary


Goal� Identification and

� Classification

of effective risks

Approach� Correlation of threats and vulnerabilities

→ Risk catalogue

� Classification of risks

◆ Goal: Catalogue reduction

→ Risk matrix

2.3 Risk Analysis

2.3 Risk Analysis


GoalRisk Catalog

Correlation of Threats and Vulnerabilities


Risk

?

2.3 Risk Analysis


Example 1


Risk

?

Implementation errors in AC Scheme of DBMs:Data can be accessed without authorization

Professional attack teams

Confidentiality breach

2.3 Risk Analysis


Example 2


Risk

?

Conceptual vulnerability: DAC only

Sale of corporate secrets, redirection of funds

Employee in critical financial

situation

2.3 Risk Analysis


ResultRisk Catalog

Is often quite large ...


Risk

2.3 Risk Analysis


Goal� Catalog reduction

ApproachRisk matrix; correlates� Damage potential� Occurrence probability

Risk Classification

Dam

age

pote

ntia

l

Occurrence probability

2.3 Risk Analysis


Damage Potential Assessment

Examples for Risks� Cloud Computing: „Loss of VM Integrity“

→ Contractual penalties, loss of confidence� Industrial plant control: „Tampering with frequency converters“

→ Downtime or destruction of plant� Critical infrastructures: „DoS attacks“

→ Interrupted services� Traffic management: „Integrity of GPS data“

→ Maximum credible accident

Damage Potential

2.3 Risk Analysis


In General: Damage Potential is Scenario-specific

Example: „Confidentiality breach of DB data“� Articles in online newspapers

→ Small damage� Account data of banks

→ Critical loss of trust� Plant control data of industrial control systems

→ Loss of market leadership, mission critical

Depends on many different parameters → advisory board

2.3 Risk Analysis


Occurrence Probability Assessment

Examples for Risks� Cloud Computing: “Loss of VM integrity“

→ depends on client data sensitivity� Industrial plant control: “Tampering with frequency converters“

→ depends on plant sensitivity (e.g. Stuxnet attack)� Critical infrastructures: “DoS attacks“

→ depends on danger by terrorists� Traffic management: ”Integrity of GPS data“

→ depends on danger by terrorists

Occurrence Probability

2.3 Risk Analysis


In General: Occurrence Probability is Scenario-specific

Example: „Confidentiality breach of DB data“� Articles in online newspapers

→ Small; Articles available by public interfaces� Account data of banks

→ Medium; high cost, low gain� Plant control data of industrial control systems

→ High; high financial or political gain

Depends on many different parameters → advisory board

2.3 Risk Analysis


Damage Potential Assessment

Example

2.3 Risk Analysis

Object Security Goal Damage Pot. Argumentation

Personal data (PD)

Confidentiality normal 1. Data protection acts2. Violation of personal rights

Integrity low Errors detection and correction quick and easy

Availability low Failures up to one week can be tolerated by manual procedures

Technical control data (TD)

Confidentiality high Loss of market leadership, mission critical

Integrity normal Production downtime

Availability low Production delay, but backups available


Occurrence Probability Assessment

Example

2.3 Risk Analysis

Object Security Goal Damage Pot. Argumentation

Personal data (PD)

Confidentiality normal Certified software

Integrity low Certified software, small incentive

Availability normal Certified software

Technical control data (TD)

Confidentiality high Huge financial gain by competitors or foreign countries

Integrity normal Medium damage potential, potential attackers are competitors or foreign countries

Availability low Small damage potential


Resulting Risk Matrix


Dam

age

Pote

ntia

l high

norm

allo

w

low normal high

2.3 Risk Analysis

Loss ofConfidentiality PD

Loss ofAvailability TD

Loss ofAvailability PD

Loss ofConfidentiality TD

Loss ofIntegrity PD

PD

Loss ofIntegrity TD


Management Decision: Risk Classification

Additional Criteria� HR and IT expenses� Organizational and technical feasibility

→ cost/benefits relation; management & business unit people involved

2.3 Risk Analysis


Dam

age

Pote

ntia

l

very

hig

hhi

ghno

rmal

low high very high

Loss ofConfidentiality PD

Loss ofAvailability TP

Loss ofAvailability PD

Loss ofConfidentiality TP

Loss ofIntegrity PD

Loss ofIntegrity TP

avoid

deal with

bear


� Intolerable risk, no commensurability of costs and benefits→ Don’t implement such critical functionality

� Acceptance of risks→ Reduction of damage e.g. by insurance

� Definition of security requirements→ Reduction of damage probability by system-enforced security policies

2.3 Risk Analysis

deal with

avoid

bear


2.4 Summary

2.4 Summary



Risk Analysis


Security Policy


Next Step

RequirementsEngineering

SecurityRequirements

SecurityPolicy

PolicyEngineering

ModelEngineering

ArchitectureEngineering

SecurityModel

SecurityArchitecture


Date post:	17-Mar-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Systems Security - Technische Universität IlmenauSystems Security, Summer 2018 ©wk -4-Influencing...

Documents