wieerwill/Informatik
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Kapitel 2

Browse Source
This commit is contained in:
WieErWill 2021-05-06 17:22:51 +02:00
parent 9efdae9d88
commit ba729cc92c
5 changed files with 599 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
Assets/Systemsicherheit-Risk-Matrix-2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 91 KiB

BIN
Assets/Systemsicherheit-risk-classification.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 22 KiB

BIN
Assets/Systemsicherheit-risk-matrix-1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 58 KiB

BIN
Assets/Systemsicherheit-risk.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 36 KiB

627
Systemsicherheit.md
View File

@ -5,18 +5,32 @@
- [Security Engineering](#security-engineering)
- [Lecture Roadmap](#lecture-roadmap)
- [Security Requirements](#security-requirements)
- [Vulnerabilities](#vulnerabilities)
- [Human](#human)
- [Organizational](#organizational)
- [Technical](#technical)
- [Motivation](#motivation)
- [Vulnerability Analysis](#vulnerability-analysis)
- [Human Vulnerabilities](#human-vulnerabilities)
- [Indirect Information Flow in Access Control Systems](#indirect-information-flow-in-access-control-systems)
- [Organizational Vulnerabilities](#organizational-vulnerabilities)
- [Technical Vulnerabilities](#technical-vulnerabilities)
- [Buffer Overflow Attacks](#buffer-overflow-attacks)
- [Necessary Knowledge and Skills](#necessary-knowledge-and-skills)
- [Preparing the Attack](#preparing-the-attack)
- [Result:](#result)
- [Self-Study Task](#self-study-task)
- [Summary](#summary)
- [Threats](#threats)
- [Attackers](#attackers)
- [Threat Analysis](#threat-analysis)
- [Attack Objectives and Attackers](#attack-objectives-and-attackers)
- [Attack Methods](#attack-methods)
- [Damager Potential](#damager-potential)
- [Examples](#examples)
- [Root Kits](#root-kits)
- [Damage Potential](#damage-potential)
- [Summary](#summary-1)
- [Risk Analysis](#risk-analysis)
- [Summary](#summary-2)
- [Examples](#examples-1)
- [Risk Classification](#risk-classification)
- [Risk Matrix](#risk-matrix)
- [General Fact: Damage potential is highly scenario-specific](#general-fact-damage-potential-is-highly-scenario-specific)
- [Occurrence Probability Assessment](#occurrence-probability-assessment)
- [Advisory Board Output Example](#advisory-board-output-example)
- [Security Policies and Models](#security-policies-and-models)
- [Security Policies](#security-policies)
- [Security Models](#security-models)
@ -24,13 +38,13 @@
- [IBAC](#ibac)
- [RBAC](#rbac)
- [ABAC](#abac)
- [Summary](#summary-3)
- [Summary](#summary-2)
- [Information Flow Models](#information-flow-models)
- [Denning](#denning)
- [MLS](#mls)
- [BLP](#blp)
- [Biba](#biba)
- [Summary](#summary-4)
- [Summary](#summary-3)
- [Non-interference Models](#non-interference-models)
- [Hybrid Models](#hybrid-models)
- [Brewer-Nash](#brewer-nash)
@ -41,13 +55,13 @@
- [Model Specification](#model-specification)
- [CorPS](#corps)
- [SELinux Policy Language](#selinux-policy-language)
- [Summary](#summary-5)
- [Summary](#summary-4)
- [Security Mechanisms](#security-mechanisms)
- [Authorization](#authorization)
- [Access Control Lists](#access-control-lists)
- [Capability Lists](#capability-lists)
- [Interceptors](#interceptors)
- [Summary](#summary-6)
- [Summary](#summary-5)
- [Cryptographic Mechanisms](#cryptographic-mechanisms)
- [Encryption](#encryption)
- [Symmetric](#symmetric)
@ -61,7 +75,7 @@
- [Cryptographic Protocols](#cryptographic-protocols)
- [SmartCards](#smartcards)
- [Authentication Protocols](#authentication-protocols)
- [Summary](#summary-7)
- [Summary](#summary-6)
- [Security Architectures](#security-architectures)
- [Design Principles](#design-principles)
- [Operating Systems Architectures](#operating-systems-architectures)
@ -71,7 +85,7 @@
- [CORBA](#corba)
- [Web Services](#web-services)
- [Kerberos](#kerberos)
- [Summary](#summary-8)
- [Summary](#summary-7)
# Introduction
## Risk Scenarios
@ -133,12 +147,12 @@ Industry Control Systems
- Availability
- Non-repudiability
Specific Security Goals: Terms
- Confidentiality: the property of information to be available only to anauthorized user group
- Integrity: the property of information to be protected against unauthorized modification
- Availability: the property of information to be available in an reasonable time frame
- Authenticity: the property to be able to identify the author of an information
- Non-repudiability: the combination of integrity and authenticity
Specific Security Goals (Terms)
- **Confidentiality**: the property of information to be available only to anauthorized user group
- **Integrity**: the property of information to be protected against unauthorized modification
- **Availability**: the property of information to be available in an reasonable time frame
- **Authenticity**: the property to be able to identify the author of an information
- **Non-repudiability**: the combination of integrity and authenticity
| | Safety | Security |
| -------------------------- | ---------------------------------------------------------------- | ----------------------------------------------------------------- |
@ -171,18 +185,575 @@ Steps in Security Engineering:
# Security Requirements
## Vulnerabilities
### Human
### Organizational
### Technical
## Motivation
Goal of Requirements Engineering:
Methodology for
- identifying
- specifying
the desired security properties of an IT system.
Result:
- Security requirements, which definewhatsecurity properties a system should have.
- These again are the basis of asecurity policy: Defineshowthese properties are achieved
Influencing Factors
- Codes and acts (depending on applicable law)
- EU General Data Protection Regulation (GDPR)
- US Sarbanes-Oxley Act (SarbOx)
- Contracts with customers
- Certification
- For information security management systems (ISO 27001)
- Subject to German Digital Signature Act (Signaturgesetz), toCommon
- Criteria
- Company-specific guidelines and regulations
- Access to critical data
- Permission assignment
- Company-specific infrastructure and technical requirements
- System architecture
- Application systems (such as OSs, Database Information Systems)
General Methodology: How to Come up with Security Requirements
Specialized steps in regular software requirements engineering:
1. Identify and classifyvulnerabilities.
2. Identify and classifythreats.
3. Match both, where relevant, to yieldrisks.
4. Analyze and decide which risks should bedealt with.
-> Fine-grained Security Requirements
![](Assets/Systemsicherheit-risk.png)
## Vulnerability Analysis
Goal: Identification of
- technical
- organizational
- human
vulnerabilities of IT systems.
> Vulnerability
>
> Feature of hardware and software constituting, an organization running, or a human operating an IT system, which is a necessary precondition for any attack in that system, with the goal to compromise one of its security properties. Set of all vulnerabilities = a system’sattack surface.
### Human Vulnerabilities
Examples:
- Laziness
- Passwords on Post-It
- Fast-clicking exercise: Windows UAC pop-up boxes
- Social Engineering
- Pressure from your boss
- A favor for your friend
- Blackmailing: The poisoned daughter, ...
- An important-seeming email
- Lack of knowledge
- Importing and executing malware
- Indirect, hidden information flowin access control systems
> Social Engineering
>
> Influencing people into acting against their own interest or the interest of an organisation is often a simpler solution than resorting to malware or hacking.
> Both law enforcement and the financial industry indicate that social engineering continues to enable attackers who lack the technical skills, motivation to use them or the resources to purchase or hire them. Additionally, targeted social engineering allows those technically gifted to orchestrate blended attacks bypassing both human and hardware or software lines of defence. [Europol](https://www.europol.europa.eu/crime-areas-and-trends/crime-areas/cybercrime/social-engineering)
Real Cases
> Self Study Task
>
> Investigate the following real-world media (all linked from moodle). Find any potential security vulnerabilities there and give advice how to avoid them.
> - Watch (no listening required) the interview with staff of the French TV station TV5Monde
> - Read the lifehacker article about Windows UAC
> - Read the Washington Times article about Facebook Scam
> - Read the two eMails I received lately.
#### Indirect Information Flow in Access Control Systems
A More Detailed Scenario
- AlphaCompany has two departments: Research & Development(R&D) and Sales
- Ann is project manager and Bob is developer working in R&D on ProjectX, Chris is a busybody sales manager writing a marketing flyer about ProjectX
- All R&D developers communicate via an electronic bulletin board, including any preliminary product features not yet ready for release
- Bob is responsible for informing sales about release-ready features, using ashared web document
> Security Requirement
>
> No internal information about a project, which is not approved by the project manager, should ever go into the product flyer.
Access Control Configuration
- 3 users:ann,bob,chris
- 2 groups:
- crewx: ann, bob, ...
- sales: ann, bob
- Settings:
```
drw- --- --- 1 ann crewx 2020-04-14 15:10 ProjectXFiles
-rw- r-- --- 1 ann crewx 2020-04-14 15:10 ProjectXBoard
-rw- r-- --- 1 bob sales 2020-04-14 14:22 NotesToSales
-rw- --- --- 1 chris sales 2020-04-13 23:58 SalesFlyer.pdf
```
- Result:
- all users apparently set their permissions perfectly – from their own point of view
- all three together createda severe information flow vulnerability...
- Ann has read access to the folder ProjectX Files
- Ann legitimately writes news from these files to the ProjectX Board
- Bob legitimately updates NotesToSales with these news
- Human vulnerability: Bob’s laziness, friendship with Chris, blackmailing by Chris, ... (see above) make him write about unapproved new features
- -> Chris misuses this information in the Sales Flyer...
> Forbidden Information Flow
>
> Internal information about ProjectX goes into the product flyer!
Problem Analysis:
- Limited knowledge ofusers
- limited horizon: knowledge about the rest of a system configuration for making a sound decision about permissions
- limited problem awareness: see “lack of knowledge”
- limited skills
- Problem complexity -> effects ofindividualpermission assignments by users
(= discretionary) tosystem-widesecurity properties
- Limited configuration options and granularity: archaic and inapt security mechanisms in system and application software
- no isolation of non-trusted software
- no enforcement of global security policies
- -> Effectiveness of discretionary access control (DAC), configured by users?
### Organizational Vulnerabilities
Examples:
- Access to rooms (servers!)
- Assignment of permission on organizational level, e. g.
- 4-eyes principle
- need-to-know principle
- definition of roles and hierarchies
- Management of cryptographic keys
- -> e. g. for issuing certificates
- -> Master course on “IT-Sicherheitsmanagement” (in German)
### Technical Vulnerabilities
The Problem: Complexity of IT Systems
- ... will in foreseeable timenotbe
- Completely, consistently, unambiguously, correctly specified
- -> contain specification errors
- Correctly implemented
- -> contain programming errors
- Re-designed on a daily basis(many security mechanisms of today’s systems are older than 40 years)
- -> contain conceptual weaknesses and vulnerabilities
#### Buffer Overflow Attacks
Example for Exploitation of Implementation Errors
in privileged system software:
- Operating Systems (OSs)
- SSH demons
- Web servers
- Database servers
Consequence: Privileged software can be tricked into executing attacker’s code
Approach: Cleverly forged parameters overwrite procedure activation frames in
memory
- -> exploitation of missing length checks on input buffers
- -> buffer overflow
What an Attacker Needs to Know
##### Necessary Knowledge and Skills
- Source code of the target program (e. g. a privileged server), obtained by disassembling
- Better: symbol table, as with an executable not stripped from debugging information
- Even better: most precise knowledge about the compiler used w.r.t. runtime management
- how call conventions affect the stack layout
- degree to which stack layout is deterministic, which eases experimentation
Sketch of the Attack Approach (Observations during program execution)
- Stack grows towards the small addresses
- -> small whenever a procedure is called, all its information is stored in aprocedure frame = subsequent addresses below those of previously stored procedure frames
- in each procedure frame: address of the next instruction to call after the current procedure returns (ReturnIP)
- after storing the ReturnIP, compilers reserve stack space for local variables -> these occupy lower addresses
##### Preparing the Attack
Attacker carefully prepares an input argument msg:`\0 ...\0 /bin/shell#system `
```cpp
void processSomeMsg(char *msg, int msgSize){
char localBuffer[1024];
int i=0;
while (i<msgSize) {
localBuffer[i] = msg[i];
i++;
}
...
}
```
##### Result:
- Attacker made victim program overwrite runtime-critical parts of its stack:
- by counting up to the length of msg
- at the same time writing back over previously save runtime information -> ReturnIP
- After finishing processSomeMsg: victim program executes code at address of ReturnIP =address of a forged call to execute arbitrary programs!
- Additional parameter to this call: file system location of a shell
> Security Breach
>
> The attacker can remotely communicate, upload, download, and execute anything– with cooperation of the OS, since all of this runs with the original privileges of the victim program!
##### Self-Study Task
Do an internet research: Find a (more or less) recent example of a successful buffer overflow attack. Describe as precise as possible what happened during the attack and which programming error made it possible!
Commonplace search engines for news articles, but also web databases of software vulnerabilities such as https://cve.mitre.org/ may help you.
### Summary
## Threats
### Attackers
Vulnerabilities
- Human
- Laziness
- Social engineering
- Lack of knowledge (e. g. malware execution, DAC shortcoming)
- Organizational
- Key management
- Physical access to rooms, hardware
- Technical
- Weak security paradigms
- Specification and implementation errors
- -> A whole zoo of vulnerabilities!
How can we identify all during systems design and engineering...?
- Vulnerabilities catalogues: ISO 27001, ISO 27002
- Vulnerabilities databases, such as CVE
- Tools (we will see...)
## Threat Analysis
Goal: Identification of
- Attack objectives and attackers
- Attack methods and practices (a.k.a. “Tactics, Techniques, and Procedures (TTPs)”)
- -> know your enemy
Approach: Compilation of a threat catalog, content:
- identified attack objectives
- identified potential attackers
- identified attack methods & techniques
- damage potential of attacks
### Attack Objectives and Attackers
Attack Objectives
- Economical and political power
- Profit
- Wreak havoc (energy infrastructure, water plants, air traffic ...)
- Meet a challenge
Attackers
- Professional organizations (which may be hired by anyone, incl. competitors or governments)
- Active and former employees (“Remember that IT guy we fired last year ...?”)
- Terrorists
- Hackers (both good or evil)
Examples
- Economic Espionage
- Objective: economic and political power, profit
- Victims: high tech industry(companies that rely on the secrecy of their know-how to successfully compete)
- Attackers:
- Competitors, (foreign) governments -> professional organizations
- Insiders
- regular, often privileged users of IT systems
- statistically large share(> 40 %)
- often indirect -> social engineering (“Only amateurs target systems; professional target people.”)
- statistical profile: age 30–40, executive function (department heads, system administrators, lead programmers, ...)
- weapons: technical and organisational insider knowledge, technical skills
- -> Your own people.
- Personal Profit
- Objective: becoming rich(er)(expensive life style, ambitious projects, medical conditions)
- Attackers:
- Competitors
- Insiders
- profile: age 40–50, management function
- typically: career peak reached, midlife crisis, new boat, new house, new partner, ...
- weapons: organisational insider knowledge, organisational authority, management and leadership skills
- Wreak Havoc
- Objective: damaging or destroying things or lives, blackmailing, meeting a challenge (egomania, narcissism, sportive challange)
- Attackers:
- Terrorists: motivated by faith and philosophy, paid by organisations and governments
- Avengers: see insiders
- Psychos: all ages, all types, personality disorder (egomania, narcissism, paranoia, ...)
- -> No regular access to IT systems, no insider knowledge, butskills and tools.
### Attack Methods
### Damager Potential
Exploitation of Vulnerabilities
- Human: Social engineering, laziness, lack of knowledge
- Organizational: Rights management, key management, room access
- Technical: Weak protection paradigms, specification and implementation errors
#### Examples
Scenario 1: Insider Attack
- Social Engineering, plus
- Exploitation of conceptual vulnerabilities (DAC),plus
- Professionally tailored malware
Scenario 2: Malware(a family heirloom ...)
- Trojan horses: Executable code with hidden functionality.
- Viruses: Code for self-modification and self-duplication, often coupled with damaging the host.
- Logical bombs: Code that is activated by some event recognizable from the host (e. g. time, date, temperature, pressure, geographic location, ...).
- Backdoors: Code that is activated through undocumented interfaces (mostly remote).
- Ransomware: Code for encrypting possibly all user data found on the host, used for blackmailing the victims (to pay for decryption).
- Worms and worm segments: Autonomous, self-duplicating programs. Originally designed for good: to make use of free computing power in local networks.
Scenario 3: Outsider Attack
- Attack Method: Buffer Overflow
- Exploitation of implementation errors
Scenario 4: High-end Malware:Root Kits
- Goal: Invisible, total, sustainable takeover of a complete IT system
- Method: Comprehensive tool kit for fully automated attacks
1. automatic analysis of technical vulnerabilities
2. automated attack execution
3. automated installation of backdoors
4. automated installation and activation of stealth mechanisms
- Target: Attacks on all levels of the software stack:
- firmware
- bootloader
- operating system (e. g. drivers, file system, network interface)
- system applications (e. g. file and process managers)
- user applications (e. g. web servers, email, office)
- tailored to specific software and software versions found there!
> Self-Study Task
>
> Read about the following malware examples, both historical and up to date. Identify each as a virus, logical bomb, backdoor, ransomware, or worm; think about which necessary vulnerabilit(y|ies) make all of these threats so dangerous.
> - One of the most sophisticated pieces of malware ever discovered:Stuxnet
> - One of the first large-scale malware threats in history:Michelangelo
> - Two cooperating pieces of malware that put at risk numerous public institutional IT systems:Emotet and Ryuk.
#### Root Kits
Step 1: Vulnerability Analysis
- Tools look for vulnerabilities in
- Active privileged services and demons (from inside a network:nmap, from outside: by port scans) -> Discovers:web server, remote access server (sshd), file server (ftpd), time server (ntpd), print server (cupsd),bluetoothd,smbd, ...
- Configuration files -> Discovers: weak passwords, open ports
- Operating systems -> Discovers: kernel and system tool versions with known implementation errors
- Using built-in knowledge base: an automatable vulnerability database
- Result: System-specific collection of vulnerabilities -> choice of attack method andtools to execute
Step 2: Attack Execution
- Fabrication oftailored softwareto exploit vulnerabilities in
- Server processes or system tool processes (demons)
- OS kernel itself
to execute code of attacker withroot 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 (-> step 3)
- smoke bombs for future attacks (-> step 4)
- Results:
- Backdoors allow forhigh-privilege access within fractions of seconds
- System modified with attacker’s servers, demons, utilities, OS modules
- Obfuscation of modifications and future access
Step 3: Attack Sustainability
- Backdoors for any further control & command in
- Servers (e. g.sshdemon)
- Utilities (e. g.login)
- Libraries (e. g.PAM, pluggable authentication modules)
- OS (system calls used by programs likesudo)
- Modificationsof utilities and OS to prevent
- Killing root kit processes and connections (kill,signal)
- Removal of root kit files (rm,unlink)
- Results: Unnoticed access for attacker
- Anytime
- Highly privileged
- Extremely fast
- Virtually unpreventable
Step 4: Stealth Mechanisms (Smoke Bombs)
- Clean logfiles (entries for root kit processes, network connections), e.g. syslog,kern.log,user.log,daemon.log,auth.log, ...
- Modify system admin utilities
- Process management(hide running root kit processes), e.g. ps,top,ksysguard,taskman
- File system (hide root kit files), e.g. ls,explorer,finder
- Network (hide active root kit connections), e.g. netstat,ifconfig,ipconfig,iwconfig
- Substitute OS kernel modules and drivers (hide root kit processes, files, network connections), e.g. /proc/...,stat,fstat,pstat
- Result:Processes, files and communication of root kit become invisible
Risk and Damage Potential:
- Likeliness of success: extremely highin today’s commodity OSs
- High number of vulnerabilities
- Speed
- Refined methodology
- Fully automated
- Fighting the dark arts:extremely difficult
- Number and cause of vulnerabilities
- number of “security updates” last month?
- specification/implementation errors, weak security mechanisms
- Speed
- Smoke bombs
- Prospects for recovering the system after successful attack:near zero
Countermeasures - Options:
- Reactive: Well ...(even your OS might have become your enemy)
- Preventive:
- Counter with same tools for vulnerability analysis (we do this for years now -> 50 Billions € damage taken...)
- Write correct software (we try this for years now -> 50 Billions € damage taken...)
> Security Engineering
>
> - New paradigms:policy-controlled systems -> powerful software platforms
> - New provable guarantees: formal security models -> reducing specification errors and faultsby design
> - New security architectures -> limiting bad effectsof implementation errors and faults
### Damage Potential
Industrial Espionage:
- Loss of control over critical knowledge -> loss of economical or political power(high-risk technologies!)
- Economical damage (contract penalties, loss of profit, image damage)
Quantity: 50 000 000 000 €, 40%caused by IT⁶
Personal Profit: Individual loss of money(zero sum game)
Terrorism, hackers:
- Loss of critical infrastructures (energy, water, communication)
- Loss of sea, air, land transport infrastructure
- Damage of financial systems
### Summary
Know Your Enemy
- Attack goals and attackers
- Economical and political power, financial gain
- Professional organizations, insiders
- Attack methods und techniques: exploiting vulnerabilities
- human
- organizational
- technical
- -> A zoo of threats, practical assistance:
- National (Germany): BSI IT-Grundschutz standards and catalogues
- International:Common Criteria
Attacks on Public Infrastructure revisited:
> Self-Study Task
>
> Take a close look at those example scenarios for attacks on public infrastructure you read and researched about in chapter 1. For all of them, try to answer the following questions:
> - Who was the presumed attacker mentioned in the article? Classify them according to what you learned about attacker types.
> - What was the attack objective? Again, classify based on what you learned in this chapter.
> - How was the attack made possible? Identify the types of vulnerabilities exploited.
## Risk Analysis
## Summary
Goal: Identification and Classification of scenario-specific risks when designing an IT system
Approach:
- Risks⊆Vulnerabilities×Threats
- Correlation of vulnerabilities and matching threats
- -> Risk catalogue
- Classification of risks
- -> Complexity reduction
- -> Risk matrix
Correlation of Vulnerabilities and Threats
- Goal: Risk catalogue: $n:m$ correlation
### Examples
- Vulnerability: Implementation error in database access control -> Contents can be accessed by unauthorized users
- Threat: Professional team of attackers, contracted by competitor
- -> Risk: Confidentiality breach
- Vulnerability: Conceptual vulnerability: discretionary access control configuration only
- Threat: Employee in critical financial situation
- -> Risk:
- Disclosure and sale of corporate secrets
- Redirection of funds
- n Vulnerabilities
- m Threats
- -> x Risks
Usually: $max(n,m)≪ x ≤ nm$ -> quite largerisk catalogue!
### Risk Classification
Goal: Catalogue reduction -> major and minor risks
Approach: Qualitative risk matrix; dimensions:
![](Assets/Systemsicherheit-risk-classification.png)
### Risk Matrix
Damage Potential Assessment
Examples for risks:
- Cloud computing:“Loss of VM integrity” -> contract penalties, loss of confidence/reputation
- Industrial plant control:“Tampering with frequency converters” -> damage or destruction of facility
- Critical public infrastructure:“Loss of availability due to DoS attacks” -> interrupted services, possible impact on public safety (cf. Finnish heating plant)
- Traffic management:“Loss of GPS data integrity” -> maximum credible accident w. r. t. safety
#### General Fact: Damage potential is highly scenario-specific
Example: “Confidentiality breach of database contents”
- Articles in online newspapers
- -> small to mediumdamage due to lost paywall revenues
- Account data of banks
- -> mission-criticalloss of trust
- Plant control data of industrial production facility
- -> mission-criticalloss of market leadership
Depends on diverse, mostly non-technical side conditions
- -> advisory board needed for assessment:engineers, managers, users, ...
#### Occurrence Probability Assessment
Examples for risks:
- Cloud computing:“Loss of VM integrity”
- -> depending on client data sensitivity
- Industrial plant control:“Tampering with frequency converters”
- -> depending on plant sensitivity(cf.Stuxnet: nuclear centifuges)
- Critical public infrastructure:“Loss of availability due to DoS attacks”
- -> depending on terroristic threat level
- Traffic management:“Loss of GPS data integrity”
- -> depending on terroristic threat level
General Fact: Occurrence probability ishighly scenario-specific
Example: “Confidentiality breach of database contents”
- Articles in online newspapers
- -> smallfor articles that are publicly available anyway
- Account data of banks
- -> medium, due to high attack costs compared to potential gain
- Plant control data of industrial production facility
- -> high, due to high financial or political gain
Depends on diverse, mostly non-technical side conditions
- -> advisory board needed for assessment:engineers, managers, users, ...
#### Advisory Board Output Example
| Object | Risk | Dmg. Pot. | Rationale |
| ---------------------------- | ----------------------- | --------- | ------------------------------------------------------------- |
| Personal Data (PD) | Loss of Confidentiality | medium | (1) Data protection acts, (2) Violation of personal rights |
| | Loss of Integrity | low | Errors fast and easily detectable and correctable |
| | Loss of Availability | low | Failures up to one week can be tolerated by manual procedures |
| Technical Control Data (TCD) | Loss of Confidentiality | high | Loss of market leadership |
| | Loss of Integrity | high | Production downtime |
| | Loss of Availability | low | Minimal production delay, since backups are available |
| Object | Risk | Dmg. Pot. | Rationale |
| ---------------------------- | ----------------------- | --------- | --------------------------------------------------- |
| Personal Data (PD) | Loss of Confidentiality | medium | Certified software |
| | Loss of Integrity | low | Certified software, small incentive |
| | Loss of Availability | medium | Certified software |
| Technical Control Data (TCD) | Loss of Confidentiality | high | Huge financial gain by competitors |
| | Loss of Integrity | medium | Medium gain by competitors or terroristic attackers |
| | Loss of Availability | low | Small gain by competitors or terroristic attackers |
Resulting Risk Matrix
![](Assets/Systemsicherheit-risk-matrix-1.png)
Identify 3 Regions
![](Assets/Systemsicherheit-Risk-Matrix-2.png)
Form Risks to Security Requirements
- avoid: Intolerable risk, no reasonable proportionality of costs and benefits
- -> Don’t implement such functionality!
- bear: Acceptable risk
- -> Reduce economical damage, e. g. by insurance.
- deal with: Risks that yieldsecurity requirements
- -> Prevent or control by system-enforced security policies.
Additional Criteria:
- Again, non-technical side conditions may apply:
- Expenses for human resources and IT
- Feasibility from organizational and technological viewpoints
- -> Cost-benefit ratio:management and business experts involved
# Security Policies and Models
## Security Policies