# 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)
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.
### 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
---
Encryption: C = M^e^ mod (n)
Decryption: C^d^ mod (n) = M^ed^ mod (n) = M^kφ(n)+1^ mod (n) = M
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.
Sicherheitsinfrastruktur, die Services für den sicheren Austausch von Daten zwischen Kommunikationspartnern bereitstellt
Ziele:
- Zertifikate prüfen
- Zugehörigkeit von öffentlichen Schlüsseln prüfen
Bestandteile einer PKI:
- Root CA (RCA)
- Certificate authority
- stellt Zertifikate für AAs und EAs aus
- Verwaltung der "Certificate Revocation List" und "Trust-service Status List"
- Certificate Revocation List: beinhaltet widerrufene CAs
- Trust-service Status List: vertrauenswürdige CAs
- Root CA gilt als Vertrauensanker des Systems
- wird von Regierungen oder Fahrzeugherstellern betrieben
- eine zentrale Root CA vereinfacht die Registriegrung neuer EAs und AAs
- RA:
- Resigration Authority
- überprüft die Identität von Entitäten, die eine Speicherung ihrer digitalen Zertifikate bei der CA beantragen
- überprüft die Richtigkeit des Zertifizierungsantrags
- VA:
- Validation authority
- ermöglicht die Überprüfung von Zertifikaten in Echtzeit wie OCSP oder SCVP
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
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
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
- PKI zum Erstellen von digitalen Zertifikaten
- 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 widerrufenen 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)
- Ermöglicht Clients den Stautus von X.509 Zertifikaten bei einem Validierungsdienst (VA) abzufragen
- 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.
### Kerberos
- Authentifizierungsdienst für offene und unsichere Computernetze
- Authentifizierung duch vertrauenswürdige dritte Partei (Trusted third Party: Kerberos Server)
- 3 beiteildigte Parteien:
- Client
- Server, auf den der Client zugreifen möchte
- Kerberos-Server (Authentifizierungsserver)
Das Protokoll Kerberos läuft so ab, dass sich der Client an den Authentication Server richtet, dort ein TGT (Ticket Granting Ticket) erstellt wird, sich der Client darauf mit diesem ein Ticket erstellt und letztlich Zugang zum Service gewährt wird.
Web-of-Trust
------------
Eine Alternative zur hierarchischen PKI Struktur bildet das Web of Trust.
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
--------
- Sicherungssystem: schütz Rechnernetz oder einzelne Computer vor unerwünschten Netzwerkzugriffen
- Firewall-Software:
- Ziel: Netzwerkzugriff beschränken
- überwacht den durch die Firewall laufenden Datenverkehr
- entscheidet ob Netzwerkpakete durchgelassen werden oder nicht
> 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.
Paketfilter:
- Netzwerkpakete anhand ihrer Netzwerkadresse sprerren oder zulassen
- wertet Header-Informationen der Netzwerkpakete aus
zustandsloser Paketfilter
: - Filterung der Datenpakete nach vorgegebenen Kriterien (statische Regeln)
-jedes Paket wird einzeln Betrachtet (keine Beziehungen zu vorherigen Paketen)
- Weiterleitung basiert auf Quell- und Ziel- IP, TCP / UDP-Quell- und Zielportnummern (Regeln in ACL)
zustandsbehafteter Paketfilter
: Erfasst Beziehungen von vorherigen Pakten
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.}
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.)
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.
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
Prozessorientierter Blickwinkel des Security Engineering (Elemente der Security werden in folgenden Abschnitten behandelt).
Secure Development Cycle
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
---------------------
### Identity and access management
**Identity:** Repräsentation einer Entität, welche über Attribute beschrieben wird
**Identity management:** Sammlung von Funktionen, um Identität zu verwalten (z.b. anlegen, löschen, kommunizieren,...)
**Access management:** Administration von Rollen und Rechten für einen sicheren Zugriff auf elektronische Daten
**Identität eines Nutzers prüfen:**
- Besitz: Token, Keycard,...
- Wissen: Passwort, Pin,...
- Biologisch: Fingerabdruck, ...
### 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
Zugriff auf Systemressourcen wird vom Betriebssystem gesteuert.
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
Zugriff auf eigene Daten kontrollieren
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.
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 (Identität vortäuschen)- Angreifer gibt sich als jemand anderes aus
$T$ampering with data (Manipulation von Daten)- Angreifer verändert Daten bei der Übetragung
$R$epudiation (Abstreitbarkeit)- Angreifer behauptet er war es nicht
$I$nformation disclosure (Offenlegung von Informationen)- Kann Angreifer Daten sehen die er nicht sehen darf?
$D$oS (Denial of Service - Serviceverweigerung)- Angreifer kann Zugriff auf die Applikation für Nutzer unterbinden
$E$levation of privilege (Erhöhung von Privilegien/Rechten)- 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.
:::info
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.
:::
#### 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
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.
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...
ISO/IEC 27005 Information security risk management
--------------------------------------------------
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
### 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
**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:
**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
Black-Box Test (es ist nicht klar wo die Ursache liegt)
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 -> White-Box Test
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
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**
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
Musterlösung zum Diagramm aber Application noch zu undetailiert.
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
Sign in with Wallet
Connect another wallet