---
# System prepended metadata

title: 'BA-Inf: Glorreiche Krypto/Sicherheit Zusammenfassung 2.0'

---

# BA-Inf: Glorreiche Krypto/Sicherheit Zusammenfassung 2.0


# Allgemeine Definitionen


## Ziele der IT-Sicherheit


Authenticity

:   Echtheit und Glaubwürdigkeit eines Subjekts, Überprüfbar durch charakterische Eigenschaft

Integrity (Integrität)

:   Unterbindung der Manipulation und Veränderung der Daten => Veränderungen sollen nachvollziehbar sein

Confidentiality (Vertraulichkeit)

:   Daten dürfen nur von autorisierten Subjekten gelesen und verändert werden

Availability (Verfügbarkeit)

:   Keine unautorisierte Beeinträchtigung für authentifizierte und autorisierte Subjekte

Non-Repudation
:   Eindeutige Zuordnung einer Aktion zu einem Subjekt

Anonymisierung
:   Veränderung von personenbezogenen Daten, sodass keine bestimmte Zuordnung stattfindet





# Schwachstellen, Bedrohungen, Angriffe

Weakness
:    Schwäche eines Systems, verwundbarer Punkt

Vulnerability
:    Schwachstelle, die über die Sicherheitsdienste eines Systems umgangen, getäuscht werden können

Threat
:    Ausnutzung von Schwachstellen und Verwundbarkeiten, um einen Verlust der Integrität, Vertraulichkeit, Verfügbarkeit zu erreichen

Risk
:    Wahrscheinlichkeit des Eintritts eines Schadensereignisses, Höhe des potenziellen Schadens

Attack
:    Nicht autorisierter Zugriff auf ein System





# Buffer-Overflow

Buffer Overflow
---------------
### Bug
Buffer Overflows sind Bugs die in Programmen vorkommen können, welche in Sprachen geschrieben sind, die keine automatische Speicherverwaltung haben (meist C/C++). Der Programmierer weist also selber Speicher zu und gibt ihn nach Nutzung wieder frei.  

Ein Fehler aber tritt dann auf, wenn weniger Speicher zugeteilt wurde, als später benutzt wird. Dann läuft der Inhalt über die angedachten Grenzen hinaus und es kommt zu undefiniertem Verhalten, da willkürlich Speicher außerhalb der Grenzen überschrieben wird.

### Vom Bug zur Sicherheitslücke
Vor allem Sicherheitskritisch ist ein solcher Bug, wenn ein Nutzer (Angreifer) ungeprüft bestimmen kann welcher Inhalt in einen Buffer geschrieben werden soll. Er kann dann also kritische Punkte wie Variablen oder Return Pointer überschreiben um so unberechtigt Daten zu überschreiben oder eine Shell zu starten.


### Verteidigungen
- Verwendung von Sprachen mit höherer Programmsicherheit
- DEP (Date Execution Prevention) - Speicherbereiche werden als "nicht ausführbar" deklariert
- ASLR (siehe nächster Abschnitt)


ASLR
----
ASLR (Address Space Layout Randomisation) dient dazu eine (pseudo-)zufällige Adressierung für den Speicherraum anzulegen, damit ein Angreifer nicht vorhersagen kann, an welchen Adressen im Speicher der Programmcode und die eingebundenen libraries liegen werden. Dies erschwert z.B. ein überschreiben des Return-Pointers(1) mit einem sinnvollen Wert(2) (z.B um Shell zu starten).
(1) die Funktionen werden zufällig auf den freien Speicher verteilt es ist also schwer eine anfällige Funktion zu addressieren.  
(2) die gelinkten libraries (speziell libc) sind zufällig im freien Speicher verteilt (PaX), sodass beispielsweise der system() command, mit dem eine Shell gestartet werden kann, praktisch nicht zu finden ist. (siehe 32bit Einschränkungen)
Dies hilft hauptsächlich bei x64 Systemen, da es bei 32bit Systemen nur 16 bits zur randomisierung gibt, welche einfach gebrute-forced werden können.


SQL Injection
-------------
Eine SQL Injection ist eine Sicherheitslücke bei der User input fälschlicherweise als Teil eines SQL Statments behandelt wird.

Differenzierung von SQL-Attacken in:
 * First-Order Attack: Attacker kann bößartigen String direkt eingeben und den modifizierten Code direkt ausführen lassen (durch User-Input, Cookies, Server Variablen).
 * Secon-Order Attack: Attacker fügt etwas in persistenten Speicher ein (Table, Row) welche als vertrauenswürdig gilt. Eine Attacke wird hierbei erst bei einer anderen Aktivität ausgeführt, zum Beispiel speichern neuer Login-Daten und anschließender Login durch diese.
 * Lateral Injection: Implizite Manipulation der To_Char() Funktion, indem environment variables verändert werden.

Ziel solcher Attacken ist es das Datenbank-Schema herauszufinden, Daten zu extrahieren, hinzuzufügen oder zu modifizieren, oder Authentifizierung zu umgehen.



Kryptographie
=============

Kryptographie wird benötigt um Nachrichten zu übermitteln und trotzdem
Vertraulichkeit (Verschlüsselung), Integrität (Hashes) und Authentifizierung (Signaturen) zu gewährleisten.  

- Vertraulichkeit: Ein Abhören der Daten wird verhindert - nur bestimmte Personen sollen die Nachricht erhalten/ lesen können --> Realisiert durch symmetrische und asymmetrische Verschlüsselung
- Authentizität: Ein Empfänger möchte die Sicherheit darüber von wem die Information stammt --> Bsp.: Zugangsdaten (Personalausweis, persönlicher Token, digitale Signatur, ...)
- Integrität: Daten vor Veränderung schützen --> Bsp.: Fingerabdruck (MAC), bei Veränderung passen Fingerabdruck und Nachricht nicht mehr zusammen
- Verbindlichkeit (Nicht-Abstreitbarkeit): Der Urheber ist eindeutig und jedem Empfänger bekannt --> Bsp.: digitale Signatur


Symmetrische Verschlüsselung
---------------------------

### Schwierigkeiten / Nachteile

Da die Schlüssel in den meisten Fällen wesentlich kürzer als die Nachrichten sind, muss die Nachricht in mehreren Blöcken verschlüsselt werden.  

Allgemeines Problem von Symmetrischen Verfahren: Schlüssel muss übertragen werden.   

### Modes
Verschlüsselt man allerdings jeweils nur kleine Blöcke wie __Electronic Codebook (ECB)__ so kann ein Muster erkannt werden und ein knacken ist wesentlich einfacherer. Es gibt verschiedene Methoden dieses zu verhindern. Eine davon ist __Cipher Block Chaining (CBC)__.
(Andere: Cipher Feedback CFB, Output Feedback OFB, Counter CTR, Galois/Counter GCM)

![](https://i.imgur.com/Idd4U4G.png)


Alternativ gibt es zu Blockcipher Methoden auch noch Streamcipher Methoden.
Periode des Streams muss lange sein, keine Bias die von Random Noise abweicht, keine Möglichkeit um Seed oder (Initialisierungs-Key) zu entdecken.  

![](https://i.imgur.com/m6GGl72.png)

### One Time Pad ((M + K) % 26)
Probleme mit One-Time-Pad ist, dass der Key so lange wie die Nachricht sein muss. Außerdem versichert One-Time-Pad nicht die Integrität nur die Vertraulichkeit.  



Asymmetrische Verschlüsselung
----------------------------

Bekannte Verfahren sind RSA oder Diffie-Hellmann. 

Vorteil: Schlüssel muss nicht zuerst ausgetauscht werden
Nachteil: Ineffizienter

Man benutzt deshalb oftmals asymmetrische Verfahren um den Key auszutauschen und verwendet ab dann ein symmetrisches Verfahren.  

Pefekte Sicherheit
------------------
Ein Angreifer darf durch Kenntnis der Verschlüsselten Nachricht nicht auf den Klartext schließen können  
Pefekte Sicherheit wird genau dann erreicht, wenn aus einem gegebenen Klartext durch Verschlüsselung jeder mögliche Chiffretext mit der gleichen Wahrscheinlichkeit entsteht.  


RSA
---

Angriffe
:    Faktorisierung, Eulersche Totientfunktion ohne Faktorisierung, Chosen Siphertext Attack, Timing- und Leistungsaufnahme (Seitenkanalangriffe)

Lösungen
:    Nicht alles / nur Hashes signieren, Unterschiedliche Schlüssel für Signatur, Unterschiedliche Verschlüsselung nutzen, n nicht wiederverwenden, Klartext padden, Keine kleine Werte für e und d verwenden


Kryptografische Hashfunktionen
------------------------------

Ziele: 
+ Komprimierte Darstellung einer Nachricht, "Fingerabdruck"
+ Unumkehrbar, keine Rückschlüsse auf Original möglich
+ Keine praktische Kollisionen
+ Zufällig erscheinendes Ereignis

Beispiele: MD2, MD4, MD5, SHA1, SHA2, SHA3, RIPEMD-160, Tiger, HAVAL, Whirlpool


Digitale Signatur
------------------
DSS Standard von NIST (Sammlung von Algorithm, genaues Design nicht bekannt)
+ einzig Wichtig:  Private Key brauch einen random Anteil, ansonsten gäbs die Möglichkeit von Signatur auf Private Key zu schließen.  

Mit den privaten Schlüsseln können auch Nachrichten etc. signiert werden. Die Voraussetzung ist hierfür, dass man aus der Signatur den privaten Schlüssel nicht auslesen kann, jedoch eine gültige Signatur nur mit einem privaten Schlüssel erzeugt werden kann.\
  

Authentifikation
================

Identifikation
:    Behauptung einer Identität

Authentifikation
:    Verifizierung / Beweis der Identitätsbehauptung

Autorisierung
:    Einräumung oder Verweigerung von Rechten

Credentials
:    Nachweis einer Identität

Rollen
:    Gruppen von Benutzern mit bestimmten Aufgaben und Funktionen

Delegation
:    Erlaubnis auf Systemänderungen von lokalen Administrator ohne globalen Administrator

Interchange
:    Austausch von identitätsinformationen zwischen zwei Domänen


Ablauf mit Passwort: 
1. System verlangt von Nutzer Kennung und Passwort
2. Passwort wird mit kryptografischer Hashfunktion verschlüsselt
3. Passwort wird mit Passworddatei verglichen
4. Benutzer wird autorisiert



PKI Strukturen
==============
Damit ein Vertrauensverhältnis aufgebaut werden kann sind sogenannte PKI Strukturen notwendig. Diese Sorgen dafür dass in einem System klar ist, welcher Public Key zu welcher Identität gehört.  


Zertifikate (Hierarchische Struktur)
------------------------------------

### Was ist ein Zertifikat?
Ein digitales Dokument, ordnet öffentlichen Schlüssel einer Entität (Privatperson oder Organisation) zu.  
Keine Aussage über Inhalt des signierten Dokuments.  
Ein Zertifikat muss, um gültig (und sinnvoll) zu sein, krypotgraphisch signiert werden. Entweder vom Besitzer selber (self-signed) oder von einer Zertifizierungsstelle (CA) passieren.   
Self-signed Zertifikate machen allerdings in PKI Strukturen nicht viel Sinn, da jeder Teilnehmer den Schlüssel des Signierenden haben muss um das Zertfikat zu überprüfen, was den Sinn einer PKI hinfällig macht.  

### Vertrauensketten
Problem ohne lokale RA's: 
+ Wer entscheidet, welche globale Authorität das macht?
+ Namespace ist global, einzigartige globale Identifikationsmöglichkeit benötigt
+ Hoher Workload für globale CA, Angriffe sind dadurch einfacher
+ Identifizierungsprozess kann nicht nach lokalem Recht ablaufen

Eine Lösung: Lokale CA's. Problem bleibt: Sind Rechtssysteme vergleichbar ? Kann ich ausländischens CA's trauen ?
Um letzteres Problem zu lösen (also wie traue ich überhaupt einer CA) verwende Root Store des Browsers/OS
![](https://i.imgur.com/YwDhPPC.png)
Damit eine Empfängerin einem Public Key trauen kann, muss jemand für die darin angegebene Identität bürgen.  

In hierarchischen PKIs:
+ Certificate Authority (CA, Trusted Third Party, trusted in dem Sinne, dass "richtig" zertifiziert wird) gibt Zertifikate aus und signiert (Es kann, wie im Fall von HTTPS, mehrere geben). 
+ Alle Teilnehmer des Systems trauen dann Zertifikaten die von dieser CA signiert wurden. So muss nur der Schlüssel der CA bekannt sein (Root CA).  
+ Alle CAs haben gleiche signing authority, schwächste CA bestimmt also Stärke der gesamten PKI
+ Es können Zwischenzertifikate genutzt werden, die Zertifikate signieren können (um das eigentliche Root-Zertifikat zu beschützen) und es ermöglicht Sub-CAs
+ Ein Nutzer muss dann die Signaturen der Zertifikatskette bis ans Ende verfolgen und wenn dort eine Vertrauenswürdige Root-CA steht, ist auch das erhaltene Zertifikat vertrauenswürdig.
+ Die Root CAs werden von Betriebssystemen und Browsern ausgeliefert und bestimmen somit die Autoritäten des Systems. 

Domain Validation: Simple mail von der Domain reicht aus oder aber auch Challenges (siehe unten)
Extended Valdiation: Hoher Aufwand, gründliche Untersuchung der Identität  
 
![](https://i.imgur.com/d5WhOWh.png)

Beispiel: Domainbetreiber schickt einen Certification Signing Request (CSR) an eine CA. Diese stellt dem Betreiber eine Challenge, deren Lösung beweist, dass die Anfrage vom Domainbetreiber kommt.  
Bei Antworten auf Anfragen von Clients kann nun das signierte Zertifikat mitgeschickt werden um SSL Verschlüsselung zu verwenden.  


### X.509 Standard
X.509 ist ein weitgenutzter Zertifikatstandard, der z.B bei TLS (HTTPS) zum Einsatz kommt.  
Die definierten Komponenten eines solchen Zertifikats sind:  
1. Version: version of X.509 used;
2. Serial number: unique among certificates issued by this issuer;
3. Signature algorithm identifier: identifies the algorithm and params used to sign the certificate;
4. Issuer’s distinguished name: with serial number, makes all certificates unique;
5. Validity interval: start and end times for validity;
6. Subject’s distinguished name: identifies the party being “vouched for”;
7. Subject’s public key info: identifies algorithm, params, and public key;
8. Issuer’s unique id: used if an Issuer’s distinguished name is ever reused;
9. Subject’s unique id: same as field 8, but for the subject;
10. Extensions: version specific information;
11. Signature: identifies the algorithm and params, and the signature (encrypted hash of fields 1 to 10).

Um als Empfänger die Validität eines Zertifikats zu überprüfen muss man:  
- den öffentlichen Schlüssel bekommen
- die Signatur verifizieren 
- den Hashwert berechnen und mit übertragenem vergleichen
- das Gültigkeitsintervall prüfen

### Zertifikate Widerrufen
Ein Zertifikat kann manuell widerrufen werden, wenn beispielsweise ein Schlüssel geleakt ist, oder das Zertifikat in einer Weise nicht mehr vertrauenswürdig ist.
Außerdem kann ein Zertifikat ablaufen und deswegen nicht mehr gültig sein.  
Ein Zertifikat kann nicht als gültig angesehen werden, bevor es nicht auf Widerruf geprüft worden ist.  
Dies kann auf die folgenden zwei Arten passieren (CRLs, OCSPs)  

#### Certificate Revocation Lists (CRL)
CRLs stellen eine Liste aller widerrufener Zertifikate einer CA dar. (Jede CA sollte eine solche Liste betreiben UND signieren)  
Der Client kann also anhand des Gültigkeitszeitraums, eines Zeitstempels der das nächste Update des Zertifikats angibt und einer Seriennummer prüfen ob ein Zertifikat noch gültig ist.  
##### Probleme mit CRLs
- Zwischenzertifikate müssen auch geprüft werden (dauert lang, viel Datenaustausch)
- Listen werden sehr lang
- CRL Anfragen können von Man-in-the-middle abgefangen werden
- Update Fenster sind gefährlich
Wird also von Browsern kaum genutzt
#### Online Certificate Status Protocol (OCSP)

Query-Response-Model
Query:
+ Anfrage über mehrere Hash-Werte und Seriennummer des Zertifikats
+ Durch Noncen Schutz vor replay-Angriffen
+ Anfrage kann signiert sein
+ Benötigt keine Verschlüsselung

Response:
+ Enthält den Zertifikatsstatus: gut, widerrufen, unbekannt
+ Muss signiert sein

#### Probleme mit OCSP
- Latenz durch Anfrage/Antwort übers Internet (nicht eine Liste alle 14 Tage (CRL) sondern ständig traffic)
- Die OCSP Server müssen hohe Verfügbarkeit haben
- OCSP Server wissen welche Seiten du benutzt
- Browsers nehmen es als "gut" an, wenn OCSP keine Antwort gibt

#### OCSP Stapling
+ Domain selbst fragt regelmäßig Status ab und schickt diesen beim (i.e. TLS) Handshake gleich mit (natürlich Signiert vom CA)

### Cross Signing
Eine CA *A* kann mit dem sogenannten Cross-Signing Verfahren die Zertifikate einer anderen CA *B* 'quer-signieren' sodass Benutzer die A vertrauen,  auch dem Zertifikat vertrauen können ohne B vertrauen zu müssen.
Benutzt wird das hauptsächlich von Firmen bei einer Übernahme oder bei einer Kooperation. Die eine Firma signiert dann das root CA der anderen Firma.
Nicht benutzt werden sollte das Verfahren im WWW da es dort das Prinzip des Trust Stores zunichte macht.

Web-of-Trust
------------
Eine Alternative zur hierarchischen PKI Struktur bildet das Web of Trust. 
![](https://i.imgur.com/W1etDQg.png)
Hier werden keine Zertifikate von einer zentralen Stelle ausgegeben sondern jeder Teilnehmer des Netzes bürgt für die Identitäten seiner Bekannten indem er deren Schlüssel signiert. Ein Schlüssel der von vielen vertrauenswürdigen Personen signiert wurde, gehört demnach wahrscheinlich auch zu der Person, die als identifier im sogenannten identity certificate hinterlegt ist.

Owner Trust: Vetrauen, ob jemand sinnvoll die Identität überprüft/überprüfen kann.
Signatory Trust: vertrauen, ob eine Identität zu einem Key gehört.
Key Legitimacy Wert: Braucht mehrere Marginal oder ein Full Trust Key Zertifikat um neuen Key als vertrauenswürdig einzustufen.

## PGP
+ Services: Authentication, Confidentiality, Comprresion, Email kompatibel, Segmentierung
+ Nutzt standard-Signatur Verfahren, aber mit web of trust zur Zertifizierung
+ In Kombination, am besten immer zu erst Hashen und Signieren, dann erst Verschlüsseln. Andernfalls kann nicht garantiert werden, dass der signierende Akteur die unverschlüsselte Nachricht kannte.
+ PGP nutzt standardmäßig ZIP Algorithmen (Zippen sollte nach signieren erfolgen, dann ist Signatur unabhängig von ZIP Algorithmus. Verschlüsseln erst nach Zippen, verstärkt Verschlüsselung, da weniger Redundancy in der Nachricht)
+ Obige Prinzipien und Reihenfolgen gelten eigentlich Allgemein
+ Encryption könnte zu willkürlichen email commands in manchen Systemen führen. Daher Umwandlung zu Radix64. (Die zusätliche Größe wird durch zip kompensiert) Dieses fügt auch Kontrollsumme hinzu.
+ Kümmert sich um aufteilen in Blöcke wenn email zu groß und zusammensetzen am anderen Ende
+ Nutzt Private, Public, Session Keys sowie Passphrase Keys. Dabei kann jeder Nutzer mehrere Private/Public Pairs haben. Passphrase und Session keys werden on the fly generiert, der Rest selten.
+ Da jeder mehrere Private/Public Pairs haben kann, least significant 64-bits of the key als ID mit.
+ Jeder hat einen Private Key Ring (da ist auch der passende Public Key drin gespeichert, die Key ID und die User ID) für eigene Pairs und einen Public Key Ring für fremde Pairs (inklusive key legitimacy field).
+ Hier revoked man mit einem signed key revocation certificate, andere müssen dann ihren Public key Ring updaten.


Forward Chain Validation
------------------------

Y << Z >> ist gleich "Y impliziert Z"
Kette von A (mit X << A >>) zu B (mit Z << B >>) :
X << W >> , W << V >> , V << Y >> , Y << Z >> , Z << B >>





Netzwerksicherheit
==================

Firewall
--------
  
> Kontrolle und Filterungen bei Datenpaketen
> Abwehr und Kontrolle von Zugriffen
> An mehreren Übergängen zwischen unterschiedlichen Netzen
> Besitzt eine oder mehrere Hard- und Softwarekomponenten
> DoS Angriffe abwehren
> Manipulation von internen Daten verhinden (zB Angreifer ersetzt Website von FBI)

Es gibt verschiedene Arten von Firewalls.

zustandsloser Paketfilter
:   - Filterung der Datenpakete nach vorgegebenen Kriterien
    - Weiterleitung basiert auf Quell- und Ziel- IP, TCP / UDP-Quell- und         Zielportnummern (Regeln in ACL)

zustandsbehafteter Paketfilter
:   Dieser Typ verfolgt den Zustand der TCP-Verbindungen und kann die
    Sinnhaftigkeit bestimmter Verbindungen bestimmen. Auch können alte
    Verbindungen über TimeOut gekappt werden.
    + Verfolgt Zustand der TCP-Verbindung
    + Liest Verbindungsaufbau und -abbau mit
    + Umsetzung: Erweiterung der ACL

Anwendungs-Gateways
:   Pakete werden basierend auf Anwendungsdaten ebenso wie aufgrund von         IP/TCP/UDP-Feldern untersucht
    Beispiel: nur bestimmte User dürfen Telnet nutzen
    Lösung: 
    + verlangen, dass alle Telnet Verbindungen über das Gateway laufen
    + für autorisierte User baut das Gateway eine Verbindung auf, Gateway         vermittelt die Daten zwischen den beiden Verbindungen
    + Router-Firewall blockiert alle Telnet-Verbindungen, die nicht vom           Gateway stammen

Grenzen von Firewalls
:   + Hilft alles nichts gegen IP Spoofing
    + Abwägung: Kommunikationsmöglichkeiten mit der Außenwelt vs.                 Sicherheitslevel

Klassische Firewalls sind Paketfilter, die Daten unterschiedlicher Sitzungen nicht korrelieren können.


### Intrusion Detection System

+ Deep Packet Inspection: betrachtet Paketinhalt (vergleicht zB ob im Paket verdächtige Zeichenketten vorkommen)
+ Korrelation mehrerer Pakete (gegen Port-Scanning, Netzwerk-Mapping, DoS-Angriffe)
+ Ergänzung zur Firewall

Anwendung: Mehrere IDSs mit verschiedenen Tests an verschiedenen Stellen im Netz6


Message Integrity
-----------------

Es muss sichergestellt sein, dass Nachrichten tatsächlich vom Absender
stammen und auch unverändert sind.Hierzu werden Hash-Funktionen benutzt.
+ Eine Hash-Funktion ist bijektiv
+ Aus Nachricht und einem Schlüssel wird ein einzigartiger Hashwert gebildet
+ Dieser wird an die Nachricht gehängt und anschließend versendet
+ Kommt nun die Nachricht beim Empfänger an bildet er aus Nachricht und der Hashfunktion wieder den Hashwert und vergleicht diesen mit dem angehängten Hashwert
+ Sind diese verschieden so wurde die Nachricht verändert. 
+ NACHFOLGENDES WICHTIG

Kann man so machen, ist dann aber dumm. Daher kann man entweder den Message Authentication Code (MAC) verwenden, hier verwendet man noch ein symmetrisches Geheimnis. {Oder aber in Kombination mit einer Signatur und man muss dem Public Key zu 100% vertrauen.}

![](https://i.imgur.com/9g5gM2m.png)

Hashfunktionen
--------------

Ablauf: Sende Text, gehashten Text und welche Hashfunktion verwendet wurde an den Empfänger. Dieser Hasht den Text erneut und vergleicht die beiden Hashwerte. Sind diese gleich dann wurde der Text nicht verändert, andernfalls schon.
Für einen Angreifer soll es quasi unmöglich sein mit einem gefälschten Dokument den selben Hashwert zuerzeugen wie mit dem original Dokument. 

SHA-1
- Nachricht wird in Blöcke von 512 Bits unterteilt (letzter Block wird aufgefüllt)
- besteht aus einem zyklischen Links-Shift um eine Stelle und Addition stellenweise mod 2 (XOR)
- 2005 wurden Angriffe bekannt, die allerdings nicht alamierend waren trotzdem Weiterentwicklung zu SHA-2

SHA-2
- Nachricht wird in Blöcke von 512 Bits unterteilt (letzter Block wird aufgefüllt)
- Modifiziert die Blockverschlüsselung

SHA-3
- 2015 Veröffentlicht nach Wettbewerb
- grundlegend anders als SHA-1 und SHA-2 aufgebaut, nämlich als sogenannte Sponge-Konstruktion

Endpunkt Authentication
-----------------------

Das Verfahren wird in der Grafik erklärt. Jedoch ist dieses Verfahren ohne Zertifikate immernoch unsicher, da ein Angreifer in der Mitte das Prozedere zweimal ausführen könnte und dann über alle Daten verfügt die Nachricht zu lesen und so weiterzusenden als wäre die Authenfizierung noch intakt. Dadurch, dass beide 'offizellen' Teilnehmer, alle Informationen aus dem Gespräch haben ist der Angriff schwer zu entdecken. Durch Zertifikate kann dieses Problem gelöst werden.
(Nonce wird verwendet um Playback Angriff zu verhindern, eigentlich nicht notwendig bei Public-Key Verfahren mit Zertifikaten sobald eine message gesendet wird. Denn auch bei einem Playback Angriff fehlt dem Angreifer der private Key von Alice.)

![](https://i.imgur.com/u8fGMsz.png)


TLS/SSL
-------

TLS, früher SSL, ist ein Protokoll, welches z.B den sicheren Austausch von Daten zwischen Web-Browsern und Web-Servern sicherstellt. TLS besteht aus zwei Protokollen, dem Handshake um Keys auszutauschen, und dem Record um die Kommunikation zu schützen.

(Ergänzung zum Schaubild: Beim Handshake werden Algos und Versionen ausgetauscht, ermöglicht es über alle Varianten hinweg zu kommunizieren.)
Wie bei allen symmetrischen (wenn ich den Spaß signiere, braucht man das nicht) Verfahren, muss hier ein MAC "Message authentification Code" verwendet werden um integrität Sicherzustellen. (Key ist der, der auch für die Verschlüsselung verwendet wird.) SSL arbeitet mit Segmenten die noch komprimiert werden, im Gegensatz zu PGP wird aber nach dem Kompremieren gehashed.

![](https://i.imgur.com/lFGxqxJ.jpg)


Networklayer Security
---------------------

IPsec
:   Protokoll-Suite, welche eine gesicherte Kommunikation über potentiell unsichere IP-Netze ermöglicht


Die Sicherheit auf der Netzwerkschicht wird von IPSec übernommen.\
Es gibt bei IPSec zwei Protokolle. 
1. Authentication Header Protokoll (AH)
    + bietet Quellauthentifizierung, Datenintegrität, keine Vertraulichkeit
3. Encapsulating Security Payload (ESP)
    + bietet Hostauthentifizierung, Integrität, Vertraulichkeit

Anders ausgedrückt: ESP authentifiziert nicht die äußeren Header (gäbe sonst probleme mit NAT), man kann aber einfach beide Protokolle gleichzeitig verwenden.\
Beide Protokolle lassen sich in zwei Modi nutzen. Es gibt den Tunnel Mode und den Transport Mode. 
+ Im Transportmodus wird der IPSec-Header zwischen dem IP Header und den Nutzdaten eingefügt. Verwendet wird der Modus wenn Kryptographische Endpunkte auch Kommunikationsendpunkte sind. 
+ Im Tunnelmodus werden die Pakete gekapselt und die Sicherheitsmechanismen auf die ganzen Pakte angewendet. Dazu wird ein neuer IP Header mit den Adressen der Kryptoendpunkte erstellt wo die Verschlüsselung entfernt wird und die Pakete normal weitergesendet werden. Dementsprechend kann der Tunnelmode auch im Host-to-Host Szenario eingesetzt werden, ist aber nicht notwendig.

Es wird immer eine Security Association hergestellt (unidirektional, Sichere Verbindung). Für den Handshake wird das Internet-Key-Exchange-Protokol verwendet, es basiert auf Diffie-Hellman.


## Security at what level?

Application Layer
:   PGP, Kerberos, SSH, etc.

Transport Layer
:   TLS

Network Layer
:   IP Security, Firewalls, DPI

Data Link Layer
:   Hardware Encryption


## VPN

Aufgabe
:   Authentifizierung von Nutzern, Garantie der Vertraulichkeit von übertragenen Daten, Erzeugung/Erneuerung der erforderlichen Schlüssel

Tunneling - Sicherheitseigenschaften eines privaten Netzes wird im öffentlichen aufrecht erhalten -> Gewährleistet logische Verbindungen

VPN-Verbindungen basieren auf IPsec und TLS








Security Engineering
====================
Security Engineering ist ein kontinuierlicher Prozess, der auf Threat Identifikation und Threat Verminderung zielt


**Sicherheit durch Design** bedeutet, dass eine Software von grundauf so entwickelt wird das sie sicher ist. Man geht also von Anfang an von bösartiger Nutzung aus.  

**Sicherheit durch Undurchsichtgekeit** hat sich als nicht Sinnvoll herausgestellt. Gute Sicherheit bedeutet meistens, dass jeder wissen und verstehen darf wie sie aufgebaut ist, ohne dass dadurch die Sicherheit beinträchtigt wird.  

Auf Sicherheit von Anfang an achten, weil...
:   + Später sind es zu große Kosten oder nicht mehr komplett möglich
    + Sicherheitsmerkmale unterscheiden Produkt von Mitbewebern
    + Durch Sicherheit auch neue Produktmerkmale (zB Apple Pay)



## Security Engineering Cycle

Tools, Visualisierungen und Diagramme sind wichtige um komplexe Systeme auf einer nutzbaren Abstraktionsebenen darzustellen.  
Änderungen an der Art und Weise von Bedrohungen und an Geschäftsmodellen erfordern eine Prüfung und gegebenfalls Erneuerung bei der Erkennung, Eindämmung und Validierung von Bedrohungen.

Im Vision Teil werden Use Cases und Szenarios entwickelt. Im Idealfall sollte für jedes Szenario ein Diagramm bzw ein Zykel angestoßen werden 

![](https://i.imgur.com/GsLTS6f.jpg)

Prozessorientierter Blickwinkel des Security Engineering (Elemente der Security werden in folgenden Abschnitten behandelt).
Secure Development Cycle

![](https://i.imgur.com/kQnMORY.jpg)

SECURITY OBJECTIVES
-------------------

CIA Triade
:   + Confidentiality
    + Integrity
    + Availability
    für Erklärung der einzelnen, siehe "Ziele der IT-Sicherheit"

Zu "Security Objectives" gehören auch andere Ziele der IT-Sicherheit rein

SECURITY DESIGN GUIDELINES
--------------------------

**Design Guidelines** gibt es für
- System Konfiguration
- Datenbank-Sicherheit
- File Management
- Memory Management

**Code Guidelines** gibt es für
- Input Validation
- Output Encoding
- Authentication and Password Management
- Session Management
- Access Control
- Cryptographic Practices
- Error Handling and Logging
- Data Protection
- Communication Security  

Dies verhindert leicht vermeidbare Angriffe wie Buffer Overflow oder Format String Angriffe  

ACCESS CONTROL MODELS
---------------------

### Authorization, Authentication, Audit Trail/Log

Authorization
:   ist die Funktion der Festlegung von Zugriffsrechten/Privilegien auf         Ressourcen

Authentication
:   ist der Akt der Bestätigung des Wahrheitsgehalts eines Attributs eines einzelnen Datensatzes das von einer Entität als wahr behauptet wird

Audit Trail/Log
:   ist ein Sicherheits-relevante chronologische Aufzeichnung


### Mandatory (~Obligatorisch) Access Control

Das System soll Beschränkungen beinhalten für den Zugriff auf Objekte oder genrelles ausführen von Operationen auf dem System.  
Auf Schutz der Confidentiality fokussiert


### Discretionary (~Ermessungsgemäß) Access Control

Beschränken des Zugriffs auf Objekte basierend auf der Identität der Subjekte, denen sie angehören.  
Hier ist zu nach Ermessen zu entscheiden ob Zugriffsrechte an andere Subjekte weitergegeben werden können, solange diese nicht sowiso durch 'Mandatory Access Controls' eingeschränkt sind.  


Beispiele für  Access Controlls (mit MAC oder DAC dranstehend):  

**Bell LaPadula**
+ MAC
+ Kommt aus dem Militär. Eine hirarische Struktur in der folgende Regeln gelten:
+ No read up / No write down.
+ Dies kann natürlich zu Problemen führen, da Prozesse meist komplexer sind.
+ Vertrauensbasiert
+ Beispiel: Top Secret -> Secret -> Confidential -> Unclassified

**Biba Model**
+ MAC
+ Genaues gegenteil von LaPadula
+ no read down, no write up
+ Ist ein Zustandsmodell. Es gibt keine einzelne High-Level-Integritätsrichtlinie.
+ Subjekten und Objekten werden Integritäts-Funktionen zugeordnet die bestimmt auf was für einem Level diese miteinander kommunizieren dürfen.
+ Integritätsbasiert

**Chinese Wall Model**
+ MAC
+ Einfache Sicherheitseigenschaft:
+ Zugriff wird nur gewährt, wenn das angeforderte Objekt ...
    + ... sich im selben Unternehmensdatensatz wie ein Objekt, auf das dieses Subjekt bereits zugegriffen hat befindet
    + ... keiner der Interessenkonfliktklassen von Objekten angehört, auf die bereits von diesem Subjekt zugegriffen wird.  

**Role Based Access Control**
+ Restricting system access to authorized users
+ Can implement MAC or DAC

**and Access Control List**
+ A list of permissions attached to an object
+ An ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed on given objects


### Matrix Access Control

Ist das meist genutzte Konzept.
MAC oder DAC

**Storage-Methoden**

Subject focused 
:   Zugriffsrechte werden mit Subjekt gespeichert

Object focused
:   Zugriffsrechte werden mit Objekt gespeichert

Operation focused
:   Mit dem referenzierenden Überwacher gespeichert (stored with the reference monitor)

Große Gruppen von Objekten oder Subjekten kann zu Fehlern führen, was das Konzept der Gruppierung benötigt.

![](https://i.imgur.com/d3wyjN0.jpg)



THREAT MODELLING
----------------

Die Idee hinter Threat Modelling ist es zu verstehen welche potentielle Sicherheits-Gefahren ein System aufweist. Diese sollen identifiziert werden und geeignete Maßnahmen ergriffen werden.  
Außerdem soll das Threat Modelling dabei helfen Software-Gefahren zu managen und eine generelle Vorstellung von Zusammenhängen der IT-Sicherheit zu bekommen um diese als Gefahren des Geschäfts zu verstehen.  

## Attack Trees

In einem Angriffsbaum müssen für die speziellen Angriffe (Blätter), bzw Auswirkungen/Aussehen dieser, die Parent-Knoten erfüllt sein.  
Ein Angriff ist also erfolgreich, wenn eine Kaskade von Bedingungen von Blattebene bis zur Wurzel 'true' ist? Nein, denn Teilangriffe können schon erfüllt sein, falls nur Teilbäume erfüllt sind. Schaden ist dann trotzdem nicht auszuschließen. Durch a priori Wahrscheinlichkeit ist es modellierbar, wie Wahrscheinlich einzelne Teilbäume sind. Daher gut um Eintrittswahrscheinlichkeiten zu bestimmen. 

## DREAD
Im Gegensatz zu Trees eher geeignet, um Risko in Kombination mit Kosten zu bestimmen.
$D$amage - wie schlimm ist ein Angriff?  
$R$eproducibility - wie einfach ist es, den Angriff zu reproduzieren?  
$E$xploitability - wie viel Arbeit ist es, den Angriff zu starten?  
$A$ffected users - wie viele Menschen sind betroffen?  
$D$iscoverability - wie leicht ist es den Angriff zu entdecken?  

Jedem 'Threat' wird mit DREAD eine Bewertung zugeteilt um die gefahren einordnen zu können.  
Dieses Threat Modelling gilt aber inkonsistent und subjektiv.


## Attack Surface
+ Alle "Öffnungen" in das System rein und raus, sowie alle Vorkehrungen zum Absichern
    + Summe aller Pfade für Daten/Befehle in und aus der Applikation
    + Code, der diese Pfade beschützt (authentication, authorization, data       validation, data encoding, activity logging, etc)
    + jegliche wertvolle Daten, die in der Applikation genutzt werden, wie         zB secrets und keys
    + Coder, der diese Daten schützt (encryption, access auditing,               Datenintegrität, etc)
+ Alle Daten im System sowie alle Vorkehrungen zur Absicherung


## STRIDE

Ist eine Methode um mögliche Threats zu identifizieren

$S$poofing identity - Angreifer gibt sich als jemand anderes aus
$T$ampering with data - Angreifer verändert Daten bei der Übetragung
$R$epudiation - Angreifer behauptet er war es nicht 
$I$nformation disclosure - Kann Angreifer Daten sehen die er nicht sehen darf?
$D$oS - Angreifer kann Zugriff auf die Applikation für Nutzer unterbinden
$E$levation of privilege - Angreifer hat Möglichkeit sich höhere Rechte zu geben

Die Idee ist es zu verstehen, welche potentielle Bedrohungen die Sicherheit des Systems bestimmen.
Es sollen Riskien entdeckt und geeignete Maßnahmen ergriffen werden.  

Somit können Software-Risiken eingeordnet werden.
Diese sind über die Modellierung leicht ersichtlich.  


### STRIDE Modelling Process

Threat Modeling Artifacts
:    Use-Scenarios, External Dependencies, Security Assumptions, External Security Notes

Building the Threat Model
:   + Prepare: Informationen werden gesammelt und DFDs definiert
    + Analyze: Alle Threats werden aufgedeckt
    + Determine Mitigation: Nach grundlegender Fertigstellung des Models           wird nach Abhilfemaßnahmen gesucht

1 Define Use Scenarios 
:    Einsatzkonfigurationen und breite Customer-Uses (Consideration of insider threta scenarios, Type of user, Level of experience)

2 Gather list of External dependencies
:    Produkte, Komponenten oder Services auf das sich das System bezieht. Dies können Datenbanken, Web-Server, Java Runtime Environment, etc. sein.  

3 Define Security Assumptions
:    Es soll eine Liste erstellt werden in der alle Mittel die der Sichherheit der einzelnen Komponenten (Deploying Enviroment) dienen aufgelistet werden.
Gibt es noch Annahmen zur Sicherheit, die noch unklar oder unakkurat sind, so wirkt sich dies auf die globale Sicherheit aus.  

4 Create external security notes
:    Erstelle eine Sicherheits-Dokumentation wie das System zu nutzen ist. Diese soll an Nutzer und Administrator gerichtet sein.  

5 Create Data Flow Diagrams (DFDs)
:    - Double Circle – Complex Element
Ein Prozess in dem mehrere innere Operationen eingeschlossen sind.  
    - Circle – Process  
Ein Prozess der eine diskrete Aufgabe beinhaltet  
    - Rectangle – External entity  
Jemand der die Appliaktion unkontrolliert benutzen kann.  
    - Parallel Line – Data Store  
Datenspeicherung, zB Datenbanken. Kann auch cashed information beinhalten.  
    - Arrow Line – Data flow  
Aktionen bei den Daten über diese Verbindung fließen  
    - Dotted Line – Privilege Boundary  
Kennzeichnet Verbindungen bei denen die eine Seite höheres Vertrauen bzw. Berechtigungen besitzt.  

![](https://i.imgur.com/nUFlX9M.jpg)  

#### 6. Determine threat types

Unterteile das System in relevante Komponeten.
Untersuche diese nach Anfälligkeiten/Bedrohungen und mildere diese.  
Beachte dabei folgende Arten von möglichen Angriffen:  

- Spoofing - Angreifer gibt sich als jemand anderes aus
- Tampering - Angreifer verändert Daten bei der Übetragung
- Repudiation - Angreifer behauptet er war es nicht (klingt komisch, ist aber so - siehe Folien)
- Information disclosure - Kann Angreifer Daten sehen die er nicht sehen darf?
- Denial of service - Bedrohung tritt auf wenn ein Angreifer den Zugriff auf die Applikation für Nutzer unterbinden kann.
- Elevation of privilege - Wenn ein Angreifer die Möglichkeit hat höhere Privilegien zu bekommen, als die er normal hat.  

#### 7. Identify the threats to the system

- Liste alle Elemente aus der DFD auf.
- Eliminiere komplexe Prozesse in dem die Elemente dieser Prozesse gelistet werden.
- Vermerke für die Einzelnen Elemente in und aus welchen anderen Elemente Daten ausgetauscht werden.  

#### 8. Determine risk

Eine deterministische Einschätzung der Sicherheit ist komplex und es existiert keine vollständige Datenbank zur Sinnvollen Kennzeichnung dieser.  
Trotzdem sollen hier die einzelnen Bedrohungen (immer noch in einzelne Komponenten aufgeteilt nach Schritt 6) eingeschätzt werden. Dafür muss erstmal geklärt werden, wie sich die einzelnen Threats in den speziellen Fällen bemerkbar machen.  

Risk = Chance of Attack x Damage Potential  

#### 9. Plan mitigation

Mögliche Verhinderung der Risiken (aus Sicht der Firma):  
- Mache nichts (ist am kostengünstigsten)
- Verwerfe die Erweiterung 
- Schalte die Erweiterung aus 
- Warne den Nutzer (Wenn Erweiterung essentiell ist, dass man das Programm nutzen kann)
- Entgegne dem Prozess mit Technologie  

SECURITY ARCHITECTURE AND DESIGN REVIEW
---------------------------------------

Wird in drei Bereiche unterteilt:
- Bereitstellung und Infrastruktur
    - Überprüfen Sie das Design Ihrer Anwendung in Bezug auf das Ziel und die zugehörigen Sicherheitsrichtlinien.
- Sicherheitsrahmen
    - Überprüfen Sie kritische Bereiche Ihrer Anwendung. Effektiver Weg dazu: Fokus auf die Menge der Kategorien, die den größten Impact auf Security, besonders auf architectural level und design level
- Layer-by-layer Analysis
    - Überprüfen Sie die logischen Schichten Ihrer Anwendung und bewerten Sie Ihre gewählten Sicherheitsoptionen ob sie die gewünschte Darstellung, Business Logik oder Datenzugriffspattern beeinträchtigen.  

### Tools for Reviews 
Checklisten wie BSI Grundschutz, MS Checklist for Web Applications, OWASP Guidelines.  
Visualisierung wie in STRIDE.  

SECURITY CODE REVIEW
--------------------

Der Prozess beinhaltet:
- Das Analysieren von Code für Sicherheitsmängel beinhaltet, zu wissen, wonach gesucht wird und wie es gesucht wird (auch code-audit genannt)
- Security Code Reviews optimieren den zu überprüfenden Code für allgemeine Sicherheitsprobleme
- Erfordert eine ordnungsgemäße Vorbereitung

SECURITY TESTING
----------------
- Discovery - Die Versionserkennung kann veraltete Systeme hervorheben.
- Vulnerability Scan - Nach bekannten Sicherheitsproblemen suchen
- Vulnerability Assessment - Beurteilung der Verletzlichkeit des Systems aufgrund der beiden vorherigen Punkte
- Security Assessment - Hinzufügen einer manuellen Überprüfung zur Bestätigung der Gefährdung, aber nicht die Ausnutzung von Schwachstellen, um weiteren Zugriff zu erhalten
- Penetration Test - Attacken simulieren (Bekannte Attacken, Dictionary Attack, Fuzzing zum Beispiel [Randomisierter Input; kann passend modifiziert werden])
- Security Audit - Angetrieben mit einer Audit / Risk function um auf ein spefizisches Kontrollproblem oder Problem mit Einhaltung der Vorgaben zu schauen
- Security Review - Schauen ob Standards umgesetzt wurden

SECURITY DEPLOYMENT REVIEW
--------------------------
- Statistiken beim Deployen zur Runtime auswerten um gefährliche Charakteristiken zu erkennen
- When you deploy your application during your build process or staging process, you have an opportunity to evaluate runtime characteristics of your application in the context of your infrastructure
- Deployment reviews for security focus on evaluating your security design and configuration of your application, host, and network.




Certification
=============

Credentialing
-------------

Credentialing ist der Prozess der Feststellung der Qualifikationen von lizenzierten Fachleuten, Organisationsmitgliedern oder Organisationen, und die Beurteilung ihres Hintergrunds und ihrer Legitimität

Vier Quellen, die den Aussteller von Credentials, Lizenzen und Certifications kategorisieren. 
:   + Schulen und Universitäten
    + "Vendor" sponsored credentials (e.g. Microsoft, Cisco)
    + Association and Organization sponsored Credentials
    + Von staatlichen Stellen sponsored (geförderte) Lizenzen,                     Zertifikationen, Credentials


Federal Information Processing Standard (FIPS)
----------------------------------------------

Der Standard FIPS 140-2 ist ein Informationstechnologie-Sicherheits-Zulassungsprogramm für kryptografische Module, die von Anbietern aus dem privaten Sektor hergestellt werden, die ihre Produkte für den Einsatz in Regierungsbehörden und regulierten Branchen (z. B. Finanz- und Gesundheitseinrichtungen) zertifizieren lassen wollen, die sensible, aber nicht klassifizierte (SBU) Informationen sammeln, speichern, übertragen, weitergeben und verbreiten.





ISO/IEC 27000
========= 

### TLDR
![](https://i.imgur.com/ljOm2q1.jpg)

Die ISO 2700x Reihe sind Standards für Informationssicherheit. Entwickelt wurden diese von der International Organisation for Standardisation (ISO, nicht staatiliche Organisation) und der International Electronical Comission (IEC).
Über alle Standards hinweg wird das Plan-Do-Check-Act Prinzip implementiert.

![](https://i.imgur.com/ouzG6sj.png)


ISO 27000
---------
Enthält die Begriffe und Definitonen für die ISO 2700x-Reihe  

ISO 27001
---------
Die neuste Version ist von 2013 (ISO/IEC 27001:2013)
Spezifiziert Anforderungen an ein Information Security Management System (ISMS). Anhand dieses Standards kann ein ISMS beurteilt und zertifiziert werden.  
Vorgehensweise bei der Zertifizierung: 
1. Dokumentiere den Umfang des ISMS:
2. Dokumentiere ISMS Policiy unter Betrachtung von:
    - Richtlinien
    - Organisationsstruktur 
    - Assets der Firma
3. Wähle passende Risikobewertung und Risikobehandlung
    - 27005 gibt hier Richtlinien, müssen aber nicht genutzt werden
    - Risiken erkennen
    - Kriterien festlegen
    - Risk Treatement Plan
    - Priorisieren und Risiken verwalten
    
4. Bestimme Kontrollziele und passende Kontrollen (ist ISMS nach Richlinien designed und umgesetzt)
    - die 14 Überwachungsbereiche der ISO 27001 sind in 35 Hauptkategorien unterteilt die auch Kontrollziele genannt werden.
    - unabhängiger, detailierter audit ("Überprüfung") durchgeführt
    - nötige Sicherheitsmaßnahmen festlegen
    
5. Statement über die Anwendbarkeit
    - Gibt für jede der 113 Kontrollen an ob und wie implementiert wird bzw ob Implementierung schon vorhanden

(6. [Überwache und verbessere](#ISOIEC-27005-Information-security-risk-management))

Generelle vorgehensweise zum Aufbau eines ISMS
+ Identify assets and requirements
+ Assess and treat risks
+ Select and implement controls
+ Monitor and improve effectiveness


ISO/IEC 27002
-------------
Beinhaltet eine Beschreibung der Kontrollziele und  Implementierungsleitfäden. Eine Zertifizierung nach diesem Standard ist nicht möglich, da es sich nur um Vorschläge handelt die Richtlinien aus 27001 umzusetzen.

- Informationssicherheitsrichtlinien (Information Security Policy)
    - Richlinien sollten sich nach Geschäftsstrategie, Verträgen, Rechtsvorschriften und nach der aktuellen Bedrohungssituation richten, klare Verantwortungsverteilung definieren, Prozesse definieren für Abweichungen/Ausnahmen
- Organisation der Informationssicherheit
    -  INTERN: sensibilisieren des Personals durch IT Security Spezialisten
    - EXTERNE ORGANISATIONEN: die Sicherheit der Daten muss auch bei Geschäftspartnern gewährleistet sein, sodass die Infrastruktur sicher bleibt auch wenn externe zB. mit dem Prozessieren der Daten beauftragt sind
- Personal Sicherheit (Human Ressources Security)
    - PRIOR TO EMPLOYMENT: klare Terms and Conditions, Screening von Bewerbern, dritte Nutzer sollen einen Einigungsvertrag unterschreiben
    - DURING EMPLOYMENT: Management sollte auf Einhaltung von IT Security Richtlininen achten, Personal sollte geschult werden, Bestrafung für Sicherheitsverstoße
    - TERMINATION OR CHANGE OF EMPLOYMENT: Sicherstellung, dass alle Ausrüstung von den Ex-Mitarbeitern zurückgegeben wird und alle Zugangsberechtigungen entfernt
- Asset Verwaltung (Asset Management)
    - RESPONSIBILITY FOR ASSETS: für alle Assets sind Verantwortliche bestimmt die für deren Schutz verantwortlich sind
    - INFORMATION CLASSIFICATION: Information klassifizieren um  das angemessene Schutz Level zu gewährleisten
    
- Zugriffskontrolle (Access Control)
    - BUSINESS REQUIREMENT: Zugangskontrolle zu Information
    - USER ACCESS MANAGEMENT: Kontrollierte Zuweisung von Zugangsrechten, ZUgriffsschutz auf Sensible Daten
    - USER REPONSIBILITIES: clear desk/clear screen Richtlinien um nicht autorisierten Zugriff/Schaden auf/von Daten zu vermeiden, Passwortschutz
    - SYSTEM AND APPLICATION: Zugangskontrolle auf Informationssysteme
- Kryptographie
    - CRYPTOGRAPHIC CONTROLS: richtige Anwendung von Kryptography
- Physical and environmental security - Physische und Umweltsicherheit 
    - SECURE AREAS: unautorisierten Zugriff/Schaden auf hardware verhindern durch Sicherheitsbarrieren und Zugangskontrollen
    - EQUIPMENT: Ausstattung vor (Umwelt-)schäden schützen so wie zB. die elektrische Versorgungsinfrastruktur, angemessene Entsorgung
- Betriebssicherheit (Operations security) 
    - OPERATIONAL PROSEDURES AND RESPONSIBILITIES: Verantwortung für Wartung und Management von allen Informationssystemen, geteilte Verantwortung um Vernachlässigung und Missbrauch zu verhindern
    - PROTECTION FROM MALWARE: Personal Schulungen, angemessenen schüzten
    - BACKUP: routinemäßige Backups vornehmen
    - LOGGING AND MONITORING: IT Sicherheit events aufzeichnen und Beweise sammeln zur Verbesserung (in legalem Rahmen)
    - CONTROL OF OPERATIONAL SOFTWARE: Steuerung von der Installation von Software
    - TECHNICAL VUNERABILITY: Schwachstellen im System erkennen, Gefährdung durch diese bewertet, Maßnahmen zur Bewältigung
    - AUDIT CONSIDERATION: Ablauf des Zertifizierens geplant, damit so wenig wie möglich Firmen Prozesse unterbrochen werden
- Kommunikationssicherheit (Communications security)
    - NETWORK SECURITY MANAGEMENT: Kontrolle von Netzwerken damit in diesen Daten geschützt sind
    - INFORMATION TRANSFER: interne Prozesse und Richtlinien zum sicheren transfer von Daten sollte bestehen
- System Erwerb, Entwicklung und Wartung (System acquisition, development and maintenance)
    - SECURITY REQUIREMENTS: Betriebssysteme, Infrastruktur, eingekaufte Services müssen sicher implementiert werden
    - SECURITY IN DEVELOPMENT, SUPPORT PROCESS: Sicherheit bei Entwicklung und Support von Systemen kontrolliert
    - TEST DATA: keine vertraulichen Daten zum testen verwenden
- Lieferantenbeziehungen (Supplier relationships)
    - INFORMATION SECURITY: Richlinien die die Risiken, die durch den Zugriff des Suppliers auf die Assets entsteht, mindern werden vereinbart und documentiert
    - SUPPLIER SERVICE DELIVERY MANAGEMENT: regelmäßige Überwachung, Überprüfung und Zertifizierung von dem Lieferantenservice
    
- Informationssicherheitsvorfallmanagement (Information security incident management)
    - INFORMATION SECURITY INCIDENTS AND IMPROVEMENTS: Gewährleistung eines konsistenten und effektiven Ansatzes zur Verwaltung von Informationen (Vorallem Kommunikation). Vorgehen sollte festgelegt werden, um eine schnelle, effektive und geordnete Reaktion zu gewährleisten

- Informationssicherheit Aspekte der Geschäftskontinuitätsmanagement und präventive Maßnahmen zur Bewältigung von Krisensituationen (Information security aspects of business continuity management)
    - INFORMATION SECURITY CONTINUITY: Die Organisation sollte ihre Anforderungen an die Informationssicherheit in ungünstigen Situationen (z.B. während einer Krise oder Katastrophe) bestimmen.
    - REDUNDANCIES: sind gewünscht damit die angeforderten Daten immer zur Verfügungen stehen können!
    
- Einhaltung (Compliance)
    - LEGAL AND CONTRACTUAL REQUIREMENTS: Man verhindert, dass man gegen jegliche Gesetze verstößt. Man muss bei der Gestaltung der Software darauf achten, ob man gewissen gesetzlichen Vorschriften unterliegt. Ratschläge von Rechtsberatern sollten befolgt werden. Wenn man einen Länderübergreifenden Datenverkehr hat, ist es zwingend notwendig die jeweiligen Regeln des Landes anzuerkennen.
    - INFORMATION SECURITY REVIEWS: Die Verwaltung der Informationssicherheit sollte unabhängig in geplanten Intervallen oder bei signifikanten Änderungen überprüft werden, zur Sicherheit der Informationssicherrung.


ISO/IEC 27004 Information security management - Measurement
-----------------------------------------------------------
Nicht allzu wichtig...
![](https://i.imgur.com/kI9opxO.png)


ISO/IEC 27005 Information security risk management
--------------------------------------------------
![](https://i.imgur.com/k9hHjRl.png)
![](https://i.imgur.com/pGJp9uC.png)

ISO/IEC 27001 - 27005 Takeaway
------------------------------
* Risikoorientiertes Informationssicherheitsmanagement: Die Auswahl und Implementierung von Kontrollen basiert auf einer Risikobewertung

* Kontinuierliche Verbesserung entspricht einer sich verändernden (Risiko-) Umgebung

* Dokumentationszentrierter Ansatz (vgl. ISO 9000)

* Integrierte Leistungsbewertung (Prozess und Kontrollen)

* Anwendbarkeit:
  - generisch, anpassungsfähig, flexibel
  - Domänen- und Experten-Know-how notwendig
  - skaliert mit unterschiedlichen Sicherheitsanforderungen
  - anwendbar außerhalb von IKT und Operationen
 
* Zertifizierungsschema verfügbar und zunehmend populär

RTP - gibt an wie Risiken behandelt werden, hier muss auch keine Kontrolle aus ISO 27002 ausgewählt werden. Ignorieren oder Feature abschalten sind genauso valide. Es wird jedes Risiko einzeln betrachtet.

SoA - Listet alle 113 Kontrollen einmal auf und begründet warum oder warum nicht diese Kontrolle relevant für das ISMS ist.

AP - Spezifiziert was, wie, von wem und wann umgesetzt wird.

NIST SP 800 im Vergleich zu ISO 27000
-------------------------------------
(National Institute of Standards and Technology, Bundesbehörde der USA, Standards für Bundesbehörden und Vertragspartner)
Wie die ISO 27000-Serie bietet auch die SP 800-Serie Informationen über die Sicherheitspraktiken in Bezug auf Management und betriebliche Information, jedoch in einer größeren Anzahl von Dokumenten detailreicher und kostenlos.
Zum Beispiel wird in der SP 800-53 zum Risk Assesment eine Methodik vorgeschrieben, wobei in der ISO 27001 keine definiert, aber verlangt ist.
Die SP 800-53 und die ISO 27002 sind kompatibel, aber der NIST Standard ist einschränkender und umfangreicher.

Payment Card Industry Data Security Standard (PCI DSS)
------------------------------------------------------
Der PCI-DSS, ist ein Regelwerk im Zahlungsverkehr, das sich auf die Abwicklung von Kreditkartentransaktionen bezieht und von allen wichtigen Kreditkartenorganisationen unterstützt wird.
Die Regelungen bestehen aus einer Liste von zwölf Anforderungen an die **Rechnernetze** der Unternehmen:

1.  Installation und Pflege einer Firewall zum Schutz der Daten
2.  Ändern von Kennwörtern und anderen Sicherheitseinstellungen nach der Werksauslieferung
3.  Schutz der gespeicherten Daten von Kreditkarteninhabern
4.  Verschlüsselte Übertragung sensibler Daten von Kreditkarteninhabern in öffentlichen Rechnernetzen
5.  Einsatz und regelmäßiges Update von Virenschutzprogrammen
6.  Entwicklung und Pflege sicherer Systeme und Anwendungen
7.  Einschränken von Datenzugriffen auf das Notwendige
8.  Zuteilen einer eindeutigen Benutzerkennung für jede Person mit Rechnerzugang
9.  Beschränkung des physikalischen Zugriffs auf Daten von Kreditkarteninhabern
10. Protokollieren und Prüfen aller Zugriffe auf Daten von Kreditkarteninhabern
11. Regelmäßige Prüfungen aller Sicherheitssysteme und -prozesse
12. Einführen und Einhalten von Richtlinien in Bezug auf Informationssicherheit

Bei Nichteinhaltung können Strafgebühren verhängt, Einschränkungen ausgesprochen, oder ihnen letztlich die Akzeptanz von Kreditkarten untersagt werden







BSI Grundschutz
===============

    BSI Grundschutz (mit ISO 27001 kompatibel) bietet einen Satz 
    aus standartisierten Lösungen und Anleitungen um gut bekannte 
    Bedrohungen zu bekämpfen. Ist aber nur für bekannte 
    Betriebsumgebungen anwendbar.

### Gemeinsamkeiten mit ISO/IEC
+ Satz von Verfahren, um Sicherheit bei Systemen zu erreichen
+ Feste Vorgehensweise bei Konzeption von Systemen
+ Vorschläge und Leitfäden bei Implementierung
+ Anforderungen an Dokumentation

### Unterschied zu ISO/IEC
+ BSI Grundschutz liefert Risiken und Bedrohungen mit
+ ISO/IEC bezieht diese aus fallbezogener Risikoanalyse

![](https://i.imgur.com/ISPFHCU.jpg)

### BSI-Standards
Inzwischen eigentlich 200er Serie. Die 100er gibts nicht mehr.
**BSI 100-1 Information Security Management Systems**  

Beinhaltet allgemeine Informationen über das, was für ein solches Sicherheits-Mamagment benötigt wird.  

Dies betrift Managment-Prinzipen, Ressourcen in der IT (IT-Sicherheit im Speziellen) und deren Prozesse und Konzepte.  

Komplementiert die ISO/IEC 27001 und beinhaltet auch vergleichbare Inhalte zu ISO/IEC 27002 und weiteren Standards.  

**BSI 100-2 IT-Grundschutz Methodology**

Hilft dabei eine Grundsicherheit zu schaffen durch standardmäßig Sicherheitsmaßnahmen.  

Man versucht mit standard Safeguards normale Sicherheitsvorkehrungen zu treffen  

Diese können erweitert werden für mehr Schutz.  

**BSI 100-3 Risk Analysis Based on IT-Grundschutz**

Vereinfachte Methoden zur Risiko-Analyse aus dem IT-Grundschutz Katalog.  

Dies zielt vor allem auf Prozesse die hohe Sicherheit benötigen oder Prozesse die noch garnicht durch den Katalog abgedeckt sind. Dies können Operationen in untypischer Umgebungen sein.  

Daraus gehen Sicherheits-Regeln für die jeweiligen Prozesse oder für eine Umgebung hervor.  

**BSI 100-4 Business Continuity Management**

Systematischer Weg, ein Notfallmanagement in einer Behörde oder einem Unternehmen aufzubauen, um die Kontinuität des Geschäftsbetriebs sicherzustellen.  

Ein Notfallmanagements soll die Ausfallsicherheit erhöhen und die Institution auf Notfälle und Krisen adäquat vorbereiten, damit die wichtigsten Geschäftsprozesse bei Ausfall schnell wieder aufgenommen werden können.  

Es gilt, Schäden durch Notfälle oder Krisen zu minimieren und die Existenz der Behörde oder des Unternehmens auch bei einem größeren Schadensereignis zu sichern

Mit dem ISO 27035 existiert ein vgl. Standard der Iso-Familie.

### BSI-Katolog

Der BSI Katalog wird für die Erstellung eines Sicherheitskonzept verwendet.  

**Bausteine**  
- B1 Übergreifende Aspekte
- B2 Infrastruktur
- B3 IT-Systeme
- B4 Netze
- B5 Anwendungen  

**Gefährdungskataloge**  
- G0 Elementare Gefährdungen
- G1 Höhere Gewalt
- G2 Organisatorische Mängel
- G3 Menschliche Fehlhandlungen
- G4 Technisches Versagen
- G5 Vorsätzliche Handlungen  

**Maßnahmenkataloge**  
- M1 Infrastruktur
- M2 Organisation
- M3 Personal
- M4 Hardware und Software
- M5 Kommunikation
- M6 Notfallvorsorge  

**Hilfsmittel**  
- Checklisten und Formulare
- Muster und Beispiele
- Tools zur Unterstützung des Grundschutzprozesses
- IT-Grundschutz-Beispielprofile
- Dokumentationen und Studien
- Informationen externer Anwender
- Archiv  

### Erstellung eines Sicherheitskonzepts

![](https://i.imgur.com/aeEU2vj.jpg)  

**Structure analysis**

- Dokumentiere Firmen-Prozesse und deren Anwendungen
- Netzwerkplan vorbereiten
- IT-System dokumentieren
- Räumlichkeiten dokumentieren  

**Protection Requirements Categories**

Schwerpunktsetzung für den benötigten Schutz für Anwendungen, IT-System, Räumlichkeiten und Kommunikaitonswege.  

Dafür wird ein möglicher Schaden in verschiedene Szenarios (zB. Gesetze, Natureinflüsse, Finanzielles,...) beschrieben.  

Folgende Prinzipien zur Betrachtung der Elemente gelten:
- Schäden mit den größten Konsequenzen
- davon abhängige Elemente
- Kleine Schäden die zu größeren Schäden resultiren können  

Elemente die große Sicherheit benötigen sollten in mehrere kleine Elemente unterteilt werden.  

**Selection of Safeguards**

Modelliere den Informations-Bereich:  

Hierfür sollen die passenden Module aus dem IT-Grundschutz Katalog gewählt werden.  

Hierbei ist jeweils angemessen zu handeln. Sichrheitsmaßnahmen sollten effektiv, passend, leicht anzuwenden und effizient sein.  

**Basic Security Check**

Hier werden die benötigten Sicherheitsmaßnahmen aus der Struktur-Analyse mit den Vorhandenen verglichen. Fehlende Sicherheitsmaßnahmen werden festgehalten.  

**Risk analysis/Risk Treatment**

Siehe Risiko-Analyse  

**Implementing the Security Concept**

Sechs Schritte in BSI 100-2 Standard beschrieben:  

![](https://i.imgur.com/MqUhfQo.jpg)

**Risk Analysis**
[schon erledigt weiter oben](#Risk-Analysis-Risikoanalyse)

**Gap Analysis**
Bewerte folgende Kriterien [ISO/IEC 27002:2013](#ISOIEC-270022013) nach Impact (Wichtigkeit) und aktueller Status von 0-2 (0 = schwach/ Kontrolle nicht impelmentiert, 1 = mittel/ Kontrolle unvollständig implementiert, 2 = hoch/ ausreichende Implementierung der Kontrolle)




Software Security Analysis
==========================

Statische Analyse
-----------------

Source Code Analyse
Ziel: Aufspüren von potentiellen Bugs

Techniken:
    + Syntaktische Überprüfung
    + Type Checking
    + Weitere Analysen (zB Dataflow Analysis, Controol Flow Analysis)

Durchgeführt von Compiler, Analyse Tools

Style-Checking
    + Warnungen zu schlechter Variablenwahl und Verletzung der Coding         Conventions
    + Firmenspezifische Namenskonventionen und Code Guidelines

Weitere Checks
    + Unbenutzte Variablen, keine Initialisierung
    + Dead Code

Vorteile
:   + Testen von Source Code
    + Codeinspezierung
    + Einhaltung von Coding Conventions

Nachteile
:   + Unüberschaubar bei großer LOC (Lines of Code)
    + Sicherheitslücken schwer erkennbar
    + Unentscheidbare Probleme
    + Heap schwer zu handhaben


PREfast & SAL
-------------

PREfast 
:    + Lightweight Static Analysis Tool für C++

SAL (Standard Annotation Language)
:    + Sprache zur Annotation von C/C++ Code und Bibliotheken
        + Präzisere Prüfung als PREfast

Checks:
+ Funktionen, die deprecated sind
+ Richtige Verwendung von Funktionen
+ Code Errors
+ Syntax Errors
+ Memory Errors


Security Testing
----------------

Normal testing
:    Gewünschtes Verhalten für vernünftige Eingaben

Security testing
:    Suche nach falschen, unerwünschten Verhalten

Prüfung anhand von Testdaten, ob SUT versprochene Ergebnisse liefern
:   + Wie gut decken die Testdaten / Testumgebung den Code ab?
    + Was passiert beim Programmabsturz?

Abuse Cases
:   + Was würde der Angreifer versuchen zu tun?
    + Wo könnte in der Implementierung gepfuscht worden sein?


Fuzzing
-------

Effektiver, automatisierter Sicherheitstest
Grundidee: Automatische Generierung von Random-Inputs -> Überprüfung ob das Programm abstürzt

Fuzzing-Ideen:
:   + Blank-Strings
    + Negative Werte, Min-, Max-Werte oder Null-Objekte für Integer
    + Spezielle Werte oder Keywords
        + NULL, \n, %s, %x, %n
        + /, backslash, :, ""
        + CREATE, DROP TABLE, DELETE

Arten von Fuzzern:
:   + Mutations-based Fuzzer
    + Generation-based Fuzzer
    + Evolutionary Fuzzer
    + Whitebox approaches

Vorteile
:   + Geringerer Aufwand
        + Crasht das Programm?
    + Darstellung der Robustheit von C/C++ Code

Nachteile
:   + Findet nicht alle Bugs
        + Verwendung von Smart-Fuzzern
    + Ursache für Crash kann schwer zu finden sein





Language-Based Security
=======================

Sichere Programmiersprachen...
:   + Bieten gewisse Abstraktion
    + Setzen Disziplin und Einschränkungen an den Programmierer
        => Kleine Einschränkungen in Freiheit und Flexibilität führt zu            mehr Klarheit und Sicherheit


Sichere Programmiersprachen - Differenzierung
:   + Memory Safety
    + Type Safety
    + Arithmetic Safety
    + Thread Safety


Memory Safety
-------------

Programmiersprache garantiert Memory Safety
:   + Programm hat keinen Zugriff auf nicht zugewiesenen Speicher
    + Programm hat keinen Zugriff auf nicht initialisierten Speicher

Typische Eigenschaften von unsicheren Sprachen
:   + Keine Array-Bound-Checks
    + Pointer-Arithmetik
    + Null Pointer und deren nicht definiertes Verhalten


Type Safety & Arithmetic Safety
-------------------------------

Type-Safety
:   Daten können nur anhand der Vorgabe ihrer Typen manipuliert werden

Arithmetic Safety
:   + Wie verhält sich ein programm, wenn i += 1 überläuft?
        + Nicht definiertes Verhalten: C/C++
        + Spezifikation von Über/Unterläufen: Java/C#


Thread Safety
-------------

Thread
:    Ausführungsstrang/-reihenfolge in der Abarbeitung eines Programms, Teil eines Prozesses

Zwei oder mehrere konkurrierende Threads können sich gegenseitig korrumpieren -> Multi-Threading in Java (Behebung durch synchronized)

Performance vs. Sicherheit

Global Interpreter Lock 
:    Verhinderung, dass mehrere Threads den selben Code gleichzeitig ausführen




More Standard (Input) Security Problems
=======================================

Beispiele für Eingabemöglichkeiten
:   + URL einer Webanwendung
    + Formulare auf einer Webanwendung
    + zu öffnende Dateien, Dateiuploads

Denkbare Angriffe
:   + Buffer Overflow (lange Eingabewerte)
    + Command Injections (Shell-, SQL-, PHP-, HTML-, LDAP-Injection)
    + Path Traversal
    + Forced Browsing
    + Dokumente mit Makros
    + Archive Bomb
    + ZeroDays im Dokumentenbetrachter
    + Ausführbare Dateien

Supply Chain Attack
:   Einschleusen einer korrupten Bibliothek, die als Abhängigkeit der anzugreifenden Software gebraucht wird (zB Packages oder über Stackoverflow)

Schutzmöglichkeiten
:   + Concept of least privilege, Trust Boundaries
        + Möglichst wenig privilegierter Code
        + Mandatory Access Control (MAC) nutzen (SELinux, AppArmor)
        + Kein Vertrauen nach außen (Bsp XSS: SRI nutzen)
    + Sandboxing
        + Containerisierung, Microservices (Docker, Podman, LXC)
        + Werkzeuge zB Flatpak, Bubblewrap, gVisor
    + Input Validation (siehe unten)
    + Input Sanitisation (siehe unten), Escaping -> Achtung!

Input Validation / Sanitisation
:   + Whitelist / Blacklist
    + Feldlängebegrenzung
    + Parser auf Basis (hoffentlich nicht zu komplexer) Grammatiken
    + Hoffentlich nichts übersehen

Validation richtig machen: Choke Point for validation statt validation all over the place UND validation kurz nach input und zusätzliche validation kurz vor output

Alternativen:
:   + Encoding
    + Übertragung der Eingabe auf einen separaten Kanal



Application-level Sandboxing
============================

Compartmentalisation
--------------------

+ Hilfreich für die Isolierung von verschiedenen Trust Leveln
+ Access Control von Compartments
    + Rights/Permissions
    + Parties
    + Policies
    + Runtime Monitoring
+ Security Design von Compartments
    + Unterteilung des Systems in chunks
    + Vergabe minimaler Zugriffsrechte an jedes compartment
    + Starke Kapselung der Compartments
    + Klare/Einfache Interfaces zwischen Compartments

Verschiedene Formen der Compartmentalisation
:   + Konventionelle OS Access Control
    + Language level sandboxing in sicheren Programmiersprachen
        + zb Java sandboxing mit stackwalking
        + Java VM & OS im TCB
    + Hardware-supported enclaves (~ umschließen/Umschluss) in unsicheren Sprachen
        + zB Intel SGX enclaves
        + zugrundeliegende OS möglicherweiße nicht in TCB


OS Access Control
-----------------

Sowas wie "Google Maps would like to use your current position" bei iPhones

**Problems:**
+ Größe des TCB (Trusted Computing Base)
    + Sicherheitslücken resultierend aus der Größe
    + Beispiel: Bösartiger User bekommt root/Administrator Rechte
+ Hohe Flexibilität
    + Hohe Fehleranfälligkeit in der Entwicklung
+ Mangelnder Ausdruck / Granularität
    + Komponenten innerhalb eines Prozesses können nicht unterschieden         werden
+ Limitations:
    + Prozess bekommt vorgeschriebene Rechte (meistens die vom                 ausführenden user)
    + Ausführung mit reduziertem Berechtigungssatz


Language-level Access Control
-----------------------------

+ In sicheren Programmiersprachen kann die Zugriffskontrolle innerhalb eines Prozesses auf Sprachebene bereitgestellt werden
    + Interaktion zwischen den Komponenten wird eingeschränkt und kontrolliert
+ Ermöglicht Sicherheitsgarantien bei vertrauenswürdigen Code
+ Sand-boxing mit code-based Access Control (Java, .NET)
    + Behandelt verschiedene Teile des Programms unterschiedlich
    + Benutzerbasierte Zugriffskontrollen vom OS
    + Voraussetzung:
        + Permissions
        + Protection Domains
        + Policies


Sandboxing
----------

Language based Sandboxing ist eine Art um Access Control innerhalb einer Applikation umzusetzen: Verschiedene access rights für verschiedene Parts des Codes
:   + Reduziert TCB für manche Funktionalität
    + Kann erlauben, die Codeüberprüfung zu beschränken auf einen kleinen Teil des Codes
    + Kann erlauben, Code von jeglicher Quelle auf der gleichen VM auszuführen und nicht allen gleichermaßen zu vertrauen

Hardware-based Sandboxing kann dies auch erreichen bei unsicheren Programmiersprachen
:    + bei weitem weniger TCB: OS und VM sind nicht länger in der TCB
     + aber weniger expressiv und weniger flexibel
            + kein stackwalking oder reichhaltigen Satz an Berechtigungen



Information Flow
================

What is Information Flow?
explicit flows, implicit flows, covert channels
how can we statically control information flow, using type systems?
how can we formally define what information flow is?
non-interference, termination-sensitive or termination-insensitive

explaining if ther is unwanted information for integrity or confidentiality in example programs (slides 5, 7, 12, 15)
giving and/or motivating a typing rule for information flow typing (slides 23-25, 33), for termination- sensitive or insensitive
giving and/or explaining the definition of non-interference, for integrity or confidentiality (but not the possibilistic & probabilistic versions)






Meltdown & Spectre
==================

CPU-Techniken
-------------

+ Spekulative Ausführung
    + Ausnutzung von Wartezeiten, um andere Befehle auszuführen
    + Diese Befehle werden von CPU spekuliert, dass sie als nächstes               durchgeführt werden
+ Implizites Caching
    + Daten werden frühzeitig in den Cache gelegt
        => Performance der CPU steigt
+ Branch Prefetching
    + Spekulative Auswahl eines Ausführungspfads durch bedingten oder             indirekten Sprung
    + Daten werden in L1-Cache geladen -> schneller Zugriff
+ Branch Target Buffer
    + Verminderung von fehlerhaften Aussagen von BP
    + Verwaltung eines speziellen Cache zur Protokollierung von                   Zieladressen
+ Out-Of-Order Execution
    + Parallelverarbeitung möglich, durch vorherige Ausführung
    + Instruktion wird erst beendet, wenn vorherige fehlerfrei                     abgearbeitet wurde


### L1-Cache

Zwischenspeicher der CPU für die am häufigsten benutzten Befehle

Auslesen
:   + typischerweise Seitenkanalangriffe über Timing
    + Verschiedene Operationen brauchen aufgrund des Inhalts des L1-Cache         unterschiedlich lange
    + Zeitunterschiede minimal, aber messbar

Erste Absicherung
:   + Entfernung von Präzisionstimern aus Webbrowsern
    + Andere Laufzeitumgebungen fügen absichtlich zufällige Fehler ein


Meltdown
--------

Basiert auf Out-Of-Order-Execution

Grober Ablauf
:   + READ secret from forbidden adress ("spy liest secret")
    + Stash away secret before CPU detects wrongdoing ("spy stößt weg")
    + Retrieve Secret ("collector sammelt es auf")

Angriffsbasis
:   + Spekulative Ausführung von Befehlen
    + Keine Prüfung der Zugriffsrechte
    + Laden in den L1-Cache

Daten werden in den Betriebssystemkern geladen
Rechtekontrolle wird umgangen
Daten im L1-Cache, die nicht gelöscht werden

Betrifft so ziemlich jede CPU
:    Intel, AMD, ARM, PowerPC

### Meltdown (Rogue Data Cache Load)

Speicherbereich des Betriebssystems wird komplett in den virtuellen Speicher eines Nutzerprozesses abgebildet
=>
Nutzerprozess enthält in Seitentabelle die Speicherseiten des betriebssystems, markiert als Kernel-Pages
=>
Performance-bedingt Out-Of-Order Execution umgeht Zugriffsschutz
=>
Speicherzugriffe zunächst ohne Kontrolle
Speicherzugriff wird erst geprüft, wenn Befehl benötigt wird
=>
Ergebnisse der Spekulativen Ausführung wird verworfen
Daten gelangen unkontrolliert von Kerneladressraum in L1 Cache -> Auslesen möglich


Spectre
-------

Basiert auf Speculativ Execution

Grober Ablauf
:   + force victim to leak secret (by manipulating the branch prediction of       the CPU)
    + stash away secret (wie meltdown)
    + retrieve secret (wie meltdown)

Unterschied Meltdown & Spectre
:   + Meltdown: Die CPU **weiß** was die nächste Instruktion ist und checkt       asynchron die permissions
    + Spectre: Die CPU **schätzt** die nächste Instruktion anhand von             Heuristiken

Attacker Process
:   + Prime the branch prediction to expect a loop
    + Make sure "Loop"-Counter is not cached so the CPU is more likely to speculatively run the code
    + Find a way that victim leaks data when other (wrong code) are executed speculatively

(in anderer Variante 2 ist es kein conditional jump, sondern ein indirect jump)


### Maßnahmen

Ursache: Hardware
Software-Patches sind keine Lösung

+ Eingrenzung: Microcode-Patches & Betriebssystem-Updates
    + Leistungseinbußen
    + Einschränkung der Parallelverarbeitung

Naive Lösung:
:   + Idee: Verzicht auf spekulative Ausführung oder Out-Of-Order Execution,       Deaktivierung von SMT / Hyperthreading
    + Problem: Erhebliche Leistungseinbußen -> inakzeptabel

Meltdown-Maßnahmen:
:   + Physische Aufteilung von User- und Kernel-Speicherbereich
        + Kernel Page Table Isolation (KPTI)
    + KAISER
        + Kernel Address Isolation to have Side-channels Efficiently Removed
        + Nachfolger von KASLR
        + Strikte Trennung von Adressbereich von Kernel- und User- Space
        + Kernel-Addressbereich nicht mehr im virtuellen Speicher für                 Nutzerprozesse vorhanden
    









WEITERES
========


Malware und andere Bedrohungen
------------------------------

Virus
:   Ein Virus ist ein sich selbst verbreitendes Programm, welches sich in andere Programme einschleust und reproduziert. Ein Virus kann veränderungen an dem OS oder anderer Software vornehmen oder auch zu Schäden an der Hardware führen. Typische Verbreitung für Viren sind Emails, Websiten oder offene Ports für Filesharing in einem Netzwerk.

Wurm
:   Ein Wurm ist ebenfalls selbstreplezierend und kann Schaden an Systemen führen oder unerlaubte Dienste ausführen. Im Gegensatz zum Virus kann sich ein Wurm verbreiten ohne fremde Daten mit seinem Code zu infizieren.

Trojaner
:   Trojaner reproduzieren sich meistens nicht selbst und sind oft als nützliches Programm getarnt, welches jedoch im geheimen eine Nebenfunktion hat. Typische Nebenfunktionen von Trojanern sind Sniffer, Keylogger oder Backdoors.

### Buzzword: APT (Advanced Persistent Threat)
Ein APT bezeichnet einen Angreifer, der über mehrere Phasen hinweg versucht:
- in ein Netzwerk einzudringen
- nicht erwischt zu werden
- wertvolle Informationen zu sammeln



Information Flow
================

Unterschied zu Access Control
-----------------------------

Access Control geht NUR darum an Daten ranzukommen
Information Flow geht AUCH darum, was mit Daten passiert, nachdem auf sie zugegriffen wurden

Code Fragments Confidentiality und Integrity
--------------------------------------------

**Confidentiality (hi ist vertraulich)**

negativ
:   lo = hi;
    println(hi);
    if (hi > 0) {lo = 99;}
    if (hi > 0) {print(lo);}
    if (lo > 0) {print(hi);}
    while (hi > 99) do {...};
    a[hi] = 23; // a is high/secret
    a[hi] = 23; // a is low/public
    a[lo] = 23; // a is high/secret

unklar
:   hi = "1234";
    readln(hi);
    
**Integrity (hi ist integer)**

negativ
:   hi = lo;
    readln(hi);

ok
:   hi = "1234";
    println(hi);

**Duality Integrity und Confidentiality**
Inputs sind gefährlich für Integrität
Outputs sind gefährlich für Vertraulichkeit

**Arten von Information Flows**
1. Direkt (zB andere Variablen damit setzen oder print)
2. Indirekt (zB in if oder while frage drin)
3. Hidden Channels (zB execution time, (non)termination, exceptions, noise, power consumption, EM radiation aka TEMPEST attacks)



Soundness & Completeness
------------------------

Soundness
:    Heißt, man kann nichts beweisen, was falsch ist

Completeness
:    Heißt, man kann alles beweisen, was richtig ist




Security Policies, Standards, Procedures
========================================

## Reminder:
### Statement of Applicablity SOA
Formale Definition meiner Controls in 27002. Müssen erklärt sein.

### Risk Treatment Plan RTP
Systematische identifikation der Kontrollen die benötigt werden um jedes Risk aus dem Risk Assessment zu bearbeiten

### Action Plan AP
Was tut wer, wann und wie um die geplanten Änderungen umszusetzen?

Policies: Abstrakte Beschreibung wie etwas laufen soll
Standard Guidelines: Spezifiziert die Technologien und Methoden um Systeme sicher zu machen
Procedures: Detaillierte Schritte um spezifische sicherheitskritische Aufgaben zu lösen

## Policies
> Eine formaler abstrakter Plan der die generellen Glauebensätze einer Organisiation und deren Ziele, zu einem bestimmten Thema, beschriebt. Policies beschrieben immer die benötigten Aktionen und verweist eventuell auf Standards.
Attribute sind Folgende:
> - es muss sich daran gehalten werden
> - wenn man sich nicht daran hällt folgen Disziplinarverfahren
> - sind auf die gewünschten Resultate konzentriert, nicht auf deren Umsetzung
> - sind weiter definiert durch Standards  

Beantworten *Wer? Was? Warum?* Fragen.
Alle Personen einer Organisation werden darüber informiert:
- wie sie sich einem bestimmten Thema gegenüber Verhalten sollten
- was das Management darüber denkt
- Welchte bestimmten InfoSec-Themen die Organisation unterstützt

The information security policy must be
- written,
- short,
- unambiguous and
- easy to read
Adressing:
- Policy scope
- Responsibilities
- Management’s intention for implementing it



### InfoSec Policy
ISO27002 gibt eine nice checkliste vor.
**Allgemeinwissen besagt: braucht jede Firma!**
+ Gibt ein Framework zur Auswahl und Implementierung von Gegenmaßnahmen gegenüber Threats an
  - Organisational Policy
  - System Specific Policy
  - Issue Related Policy
+ IS0 27002 gibt eine Checklist zur Erstellung von Security Policy Documents
+ Information Security Acknowledgement form
  - User muss unterschrieben, dass er weiß was er zu tun hat
+ Network policy
  - Access control procedures
  - Administration rights
  - Email policy statements
  - Network security issues
+ Folgende policies sollten getrennt behandelt werden:
  - Email policy
  - Internet policy


## Standards
> Standards sind verpflichtenede Regeln oder Vorgehensweise um eine Policiy zu unterstützen. 
Ein Standard sollte die Policiy effektivert und aussagekräftiger machen.
Ein Standard muss ein oder mehr akzeptierte Spefikationen für Hardware, Software oder Verhalten haben.  

Ein paar Regeln und Konventionen auf die man sich geeinigt hat um einheitlich und effektiv arbeiten zu können.
Es wird ein level an Erwartungen festgesetzt das jeder ereichen muss um die Obligationen zu erfüllen.
+ Security standards ensure that individuals operate consistently to minimise risk and to make the administration of systems and networks more efficient

Factors of successful security standards
- A good standard contains consistent guidelines
- A good standard will meet enterprise security objectives
- Standards must comply with the relevant laws
- Standards should contain naming conventions on passwords and accounts
- should include information about appropriate information storage
- must include physical security implementation
- must be compliant with organisation procedures

Es gibt sau viele Organisationen die Standards machen z.B. 
- ANSI: The American National Standards Institute
- EIA: Electronic Industries Association
- ISO: International Standards Organisation
- NIST: National Institute of Standards and Technology


## Procedures
> Procedures beschreiben den Prozess - Wer tut was? Wann tut er es und unter welchen Umständen?  

Wo? Wann? Wie? Fragen
Außerdem Best practices rundum bestimmte Aktionen
+ Procedures are plans, processes and operations that address the specifics of how to go about a particular action.


Risk Analysis
=============

Reasons to Perform a Risk Analysis & Risk Management?
- Improve security awareness
- Improve the basis for decision making, for e.g. budgetary issues
- Justify expenditures for security
- Identify assets, determine threats (vulnerabilities) to the assets and to determine relevant control measures to mediate the identified risks

Security Baselines and Risk Assessments
---------------------------------------

Baselines: Einschätzung wie sicher ein System zu Anfang ist, um dann Verbesserungen messen zu können

Assessments: Mechanismus zum Kontrollieren der Fortschritte bzgl. Stärken und Schwächen eine Systems sowie controls und vulnerakölnbsabvklnties

Application Control Assessments:
- Zugangskontrolle/ Authentifizierung
- Datenbank Sicherheit
- Netzwerk Assessments
- ...

Risk Analysis (Risikoanalyse)
-----------------------------

__Baselines__ are the starting point to measure the changes in configurations & improvements to a system.

__Assessments__ are mechanisms to identify the strengths & implemented controls of a system, not only the weaknesses & vulnerabilities

Man kann u.a. folgende Level betrachten:
+ High Level Security Assessment
  + Bsp. Security Policies, Standards, Procedures
  + Security plan
+ Application Control Assessments
  - Application control is a security practice that blocks or restricts unauthorized applications from executing in ways that put data at risk.
+ Risk Assessments
  - Kosten und vorhandene gegenmaßnahmen, bzw allg. Auswirkungen mit verbundenen Kosten

__Risk Analysis__ Identification + Assessment
+ is a process to determine the vulnerabilities in systems as well as the threats (exposures) to electronic assets and the potential harm which can be done to these assets  

__Risk Management__ Monitoring + Resolution
+ Risk Management is the process to implement and manage control measures to minimize vulnerabilities as well as to reduce the identified threats  

Prozess zum Finden der Schwächen in einem System
- Welche Möglichkeiten zum Schutz gibt es?
- Wie weiß man welche Schwächen es im System gibt?
- Welche Risiken gibt es?  

__Risk__ = Thread + Vulnerability (+ Impact)  

Risk Management
---------------
Prozess zum Implmentieren und Managen von Kontrollpunkten zum Reduzieren von Schwächen
- Identifizieren der Sicherheitsrisiken
- Priorisieren der Risiken und Risikobehandlung
- Verbessern des Risikomanagements
- Sicher gehen das alle beteiligten Parteien in den Prozess der Sicherheit involviert sind und diesen verstehen
- Sicherstellen, dass Risiken und die Prozesse der Sicherheit regelmäßig überprüft werden

**27005**

![](https://i.imgur.com/VPKwc2i.png)

Ablauf
1. Identifiziere Assets
    1. Hardware
    2. Software
    3. Daten
    4. Personen
    5. Dokumentation
    6. Supplies (Bereitstellungen)
2. Finde Schwächen in den Assets zu
    - Confidentiality (Vertraulichkeit)
    - Integrity (Integrität)
    - Availability (Verfügbarkeit)
3. Wie oft treten diese Schwächen auf?
4. Berechne die Kosten bei möglichen Vorfällen
5. Schlage mögliche Sicherheitskontrollen vor (und berechne deren Kosten) um die Gefahr zu mildern oder beseitigen

Es gibt viele verschiedene Methoden für Risiko-Managment:
zB.:
OCTAVE, FIRM, A portion of ISO 27005, etc.


**Information Risk (Informationsrisiko)**
Risiko was vor eine Firma entsteht wenn folgende Punkte auftreten:
- availability: Löschen der Information bei mir
- integrity: Verändern der Information
- confidentiality: Veröffentlichen der Information

**Information Assets (Informationswertgegenstände)**
- Computer
- Netzwerk
- Router

**Threat (Gefahr)**
Angriff auf die Informationswertgegenstände
Beispiele :
- Personen mit Netzwerkzugang
- Personen mit Firmenzugang
- Systemprobleme


Risk Profile Work Sheet
-----------------------
- Kombination von FIRM und OCTAVE, Trees werden nur verwendet, um Threat impact zu bestimmen
- systematische Ansammlung der Informationen über Risiken
- Messen des Risikolevels der Informationswertgegenstände
- Ziele:
    - Wie kritisch (wichtig) ist die Informationsquelle?
    - Status der Kontrolle
    - Gefahrenlevel (Level of Threats) 
    - Untersuche die Schwächen, die zu ungewollten Aktionen führen können
    - Entwickle eine Sicherheitsstrategie zum Schutz der Organisation

Dimensions of Risk Profile:
1. Loss of confidentiality - Disclosed to the wrong people
2. Loss of integrity - Modified without authorisation or otherwise
corrupted
3. Loss of availability for defined periods of time
4. Level of threat - how many incidents have occurred that put the security status of important information at risk?
5. Technical assessment – what do vulnerability assessments show of the real vulnerabilities that exist?
6. Vulnerability - What is the status of countermeasures in each of the areas?
7. Environmental Factors – factors that can influence size or complexity of the asset
8. Threat impact profile – calculate the impact of a threat outcome






STRIDE Beispiel
===============

- Datenbank:
    - Service Records (Reparaturdokumentation) des Flugzeugs
    - Zertifikation der Service-Mitarbeiter
    - Handbücher und Checklisten
- Prozesse
    - Aktualisierung der Checklisten
    - iPad Checkout
    - iPad
    
![](https://i.imgur.com/vN04PBk.png)

    
Musterlösung zum Diagramm aber Application noch zu undetailiert.
![](https://i.imgur.com/eCdy7EX.png)






LEGENDE
=======

A-F
---

ACL		
: Access Control List

AH		
: Authentication Header Protokoll

ANSI		
: The American National Standards Institute

AP		
: Action Plan

APT		
: Advanced Persistent Threat

ASLR		
: Address Space Layout Randomisation

BP		
: Branch Prefetching

BSI		
: Bundesamt für Sicherheit in der Informationstechnik

CA		
: Certificate Authority

CBC		
: Cipher Block Chaining

CFB		
: Cipher Feedback

CIA		
: Confidentiality, Integrity, Availability

CPU	
: Central Processing Unit

CSR		
: Certification Signing Request

CRL		
: Certificate Revocation List

CTR		
: Counter

DAC
: Discretionary Access Control

DEP
: Date Execution Prevention

DFD
: Data Flow Diagram

DoS
: Denial of Service

DPI
: Deep Packet Inspection

DREAD
: Damage 
Reproducibility 
Exploitability 
Affected users 
Discoverability

DSS
: Digital Signature Standard

ECB
: Electronic Codebook

EIA
: Electronic Industries Association

ESP
: Encapsulating Security Payload

FIPS
: Federal Information Processing Standard


G-L
---

GCM
: Galois/Counter

HTML
: Hypertext Markup Language

HTTPS
: Hypertext Transfer Protocol Secure

ID
: Identifier

IDS
: Intrusion Detection System

IEC
: International Electronical Comission

IKT
: Informations- und Kommunikationstechnologie

IP
: Internetprotokoll

IPsec
: Internet Protocol Security

ISMS
: Information Security Management System

ISO
: International Standards Organisation

IT
: Informationstechnik

KASLR
: Kernel Address Space Layout Randomisation

KPTI
: Kernel Page Table Isolation

LOC
: Lines of Code

LDAP
: Lightweight Directory Protocol


M-R
---

MAC
: Mandatory Access Control

NAT	
: Network Adress Translation

NIST
: National Institute of Standards and Technology

OFB
: Output Feedback

OS
: Operating System

OSCP
: Online Certificate Status Protocol

PaX
: spezieller Unix-Befehl oder auch spezieller Linux-Patch

PCI-DSS
: Payment Card Industry Data Security Standard

PGP
: Pretty Good Privacy

PHP
: Hypertext Preprocessor

PKI
: Public Key Infrastructure

PREfast	
: spezielles Tool zur Codeanalyse so wie SAL (von Microsoft)

RSA
: River-Shamir-Adleman

RTP
: Risk Treatment Plan


S-Z
---

SAL
: Standard Annotation Language (Tool zur Codeanalyse)

SBU
: Sensitive but Unclassified (zB Information)

SHA
: Secure Hash Algorithm

SMT
: Simple Mail Transfer (Protocol)

SOA
: Statement of Applicablity

SQL
: Structured Query Language

SRI
: Subresource Integrity

SSH
: Secure Shell

SSL
: Secure Sockets Layer

STRIDE	
: Spoofing identity 
Tampering with data 
Repudiation 
Information disclosure 
DoS 
Elevation of privilege

SUT
: System Under Test

TCB
: Trusted Computing Base

TCP
: Transmission Control Protocol

TLS
: Transport Layer Security

UDP
: User Datagram Protocol

URL
: Uniform Ressource Locator

VM
: Virtual Machine

VPN
: Virtual Private Network

XSS
: Cross Site Scripting


