IT-Forensik Wiki - Benutzerbeiträge [de]

Penetrationstest

2019-07-21T11:41:08Z

St181103:

Ein '''Penetrationstest''' oder kurz Pentest (abgeleitet vom Begriff Penetrieren = Eindringen / Durchdringen), beschreibt die Überprüfung eines Systems auf Sicherheitslücken bzw. Schwachstellen. Der Pentester versucht dabei gewaltsam in ein System einzudringen und die identifizierten Schwachstellen auszunutzen.

== Sinn eines Pentests ==
Der Sinn eines Pentests besteht in der speziellen Vorgehensweise. Der Pentester versucht sich in die Lage eines Hackers zu versetzen und dessen Vorgehensweise zu imitieren, um ein realitätsnahes Szenario herzustellen. Dieses Vorgehen kommt einem echten Angriff am nächsten.

Ziel eines Pentests ist es allerdings nicht, einen tatsächlichen Schaden am System zu verursachen (außer dies wurde im Voraus abgeklärt), sondern Schwachstellen aufzuzeigen. So können diese im Nachgang behoben werden, bevor ein realer Angreifer sie ausnutzen kann.

== Ansätze ==
'''Whitebox-Ansatz:''' Der Pentester hat Kenntnis über die innere Funktionsweise des zu testenden Systems. Dies schließt zum Beispiel Quellcode, Entwicklungsumgebung und Dokumentation ein.

'''Blackbox-Ansatz:''' Der Pentester hat keine Kenntnis über das zu testende System und kann seine Informationen nur aus öffentlichen Quellen und seiner eigenen Erfahrung beziehen. Der Blackbox-Ansatz kommt einem realen Angriff daher am nächsten.

== Legalität ==
Die Durchführung eines Pentests muss von der Institution beauftragt werden, deren System getestet werden soll. Dabei wird dem Pentester eine “Permission to Attack” erteilt; also eine Genehmigung, die beauftragende Institution zu testen. Sind Cloud-Komponenten Bestandteil des Tests, muss zusätzlich die Genehmigung des Cloud-Anbieters eingeholt werden.

Viele Unternehmen verfügen über Intrusion Detection / Intrusion Prevention Systeme, welche einen Penetrationstest als Angriff erkennen. Um an dieser Stelle keinen unnötigen Computer Security Incident zu erzeugen, sollte ein Pentest also zuvor genehmigt und auf einen definierten Zeitraum festgelegt werden. Liegt keine Genehmigung zur Durchführung vor, muss der Pentester mit juristischen Konsequenzen rechnen, sollte er den Test dennoch durchführen.

== Weblinks ==
* https://de.wikipedia.org/wiki/Penetrationstest_(Informatik)
* https://www.der-wirtschaftsingenieur.de/index.php/testverfahren-white-box-vs-black-box/
* https://www.security-insider.de/was-ist-ein-penetrationstest-a-667683/
* https://www.itexperst.at/it-penetrationstests-ein-praktischer-leitfaden-des-bsi

Hauptseite

2019-07-21T11:37:53Z

St181103: /* D */

Willkommen beim IT-Forensik-Wiki der Hochschule Wismar. Hier werden wesentliche Begriffe zum Thema „Digitale Forensik“ erläutert.

== Literatur ==

[[Abschlussarbeiten im Bachelor Studiengang "IT-Forensik"]]

[[Abschlussarbeiten im Master Studiengang "IT-Sicherheit und Forensik"]]

[[Projektarbeiten]]

[[Forensik in DB]]

== Stichworte IT-Forensik ==
=== A ===
[[Anti-Forensik]]

=== B ===
[[BSI-Vorgehensmodell]]

[[Betriebssystem]]

=== C ===
[[Cache]]

[[CERT-Taxonomie]]

[[Chip-Off]]

[[Cross Site Scripting (XSS)]]

=== D ===
[[Darknet]]

[[Datenanalyse]]

[[Datenbankforensik]]

[[Datenvernichtung]]

[[Datensammlung]]

[[DDL & DML]]

[[Digitale Forensik]]

[[Dokumentation]]

[[Dual Use Software]]

=== E ===
[[Ermittlungsprozess]] 

[[Exploit]]

=== F ===
[[File Carving]]

[[Flüchtige Daten]]

[[Fragmentierung]]

=== G ===
[[Geotag]]

[[Gerichtsfestigkeit]]

=== H ===
[[Hilfstatort]]

[[Hardware-Sicherheitsmodul]]

[[Hashcat]]

[[Honeypot]]

=== I ===
[[Incident-Response-Team]]

[[IT-Forensik]]

=== J ===
[[Jailbreak]]

=== K ===
[[Kausalität in der Forensik]]

[[Korrelation]]

=== L ===
[[Live-Forensik]]

[[Log-File]]

=== M ===
[[Metadaten]]

[[Mobiltelefon-Forensik]]

=== N ===
[[Netflow]]

[[Never-Touch-Original]]

=== O ===
[[Online-Forensik]]

[[Offline-Forensik]]

[[OS Fingerprinting]]

=== P ===
[[Partition]]

[[P2P (Peer-to-Peer) Software / Netzwerke]]

[[Post-Mortem-Analyse]]

[[Prozess der Mobiltelefon Forensik]]

[[Prüfsumme]]

[[PCMCIA]]

[[Penetrationstest]]

=== R ===
[[Rainbow Table]]

[[Remote Access Trojaner (RAT)]]

[[Reverse Engineering]]

=== S ===
[[SAP-Modell]]

[[Sandbox]]

[[Security Information and Event Management (SIEM)]]

[[Skimming]]

[[Sniffing]]

[[SQL Injection]]

[[Sealbag]]

[[SpiderFoot]]

=== T ===
[[Tatort]]

[[Timeline]]

=== U ===
[[Unallocated Data (Nicht zugeordnete Daten)]]

=== V ===
[[Video-Forensik]]

=== W ===
[[W-Fragen]]

[[Wiping]]

[[Write Blocker]]

=== Z ===
[[Zeit]]

== Interessante Links ==

Tsurugi Forensik-Linux https://tsurugi-linux.org

== Fernstudiengänge an der Hochschule Wismar (berufsbegleitend) ==

[https://fiw.hs-wismar.de/bereiche/eui/studiengaenge/it-forensik-bachelor-fernstudium-beng/ IT-Forensik, Bachelor]

[https://fiw.hs-wismar.de/bereiche/eui/studiengaenge/it-sicherheit-und-forensik-master-fernstudium-meng/ IT-Sicherheit und Forensik, Master]

== Starthilfen ==

* Hilfe zur Benutzung und Konfiguration der Wiki-Software finden Sie im [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents Benutzerhandbuch]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Liste der Konfigurationsvariablen]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki-FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce Mailingliste neuer MediaWiki-Versionen]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Übersetze MediaWiki für deine Sprache]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Erfahre, wie du Spam auf deinem Wiki bekämpfen kannst]

Datenbankforensik

2019-07-21T11:36:50Z

St181103: Die Seite wurde neu angelegt: „'''Datenbankforensik''' ist ein Teilgebiet der IT-Forensik. Es beschäftigt sich mit der Sammlung und Analyse von forensischen Artefakten aus Datenbanken. Im D…“

'''Datenbankforensik''' ist ein Teilgebiet der IT-Forensik. Es beschäftigt sich mit der Sammlung und Analyse von forensischen Artefakten aus Datenbanken. Im Datenbankumfeld ist eine klassische Dateisystem-Analyse nicht ausreichend, sodass eine gezielte forensische Analyse von Datenbankartefakten notwendig ist.
==Forensisch relevante Datenbankartefakte==
Folgende Datenbankartefakte sind bei der Analyse bspw. zu berücksichtigen:
* Data Cache: Gibt Auskunft über die durch den Angreifer verwendeten Daten
* Plan Cache: Gibt Auskunft über zuletzt ausgeführte SQL-Statements
* Server State: Enthält Aussagen über aktive Datenbanksitzungen, -verbindungen und die letzten SQL-Statements.
* Active Virtual Log Files: Geben Auskunft über die zuletzt ausgeführten Statements und können basierend auf Zeitstempel, DB-Login oder DB-Objekt ausgewertet werden.
* Data Files: Enthalten auch gelöschte Datensätze und unterstützen die Analyse der Tätigkeiten eines Angreifers
* Database Management System Logs: Geben je nach Logging-Konfiguration Auskunft über die erfolgreichen und fehlerhaften Logins, Buffer-Overflows, fehlerhafte StatementAusführungen und andere Fehler im DBMS
Je nach Datenbanksystem (MySQL, Oracle, MSSQL, IBM DB2, PostgreSQL, etc.) sind die o.g. Artefakte an unterschiedlichen „Orten“ zu finden.
==Strategische Vorbereitung==
Im Auslieferungszustand eines Datenbanksystems werden nicht in jedem Fall alle Artefakte im notwendigen Umfang protokolliert. Die vorzunehmenden Einstellungen sind je nach Schutzbedarf der Datenbank während der Strategischen Vorbereitung durchzuführen, damit während der Datensammlung alle notwendigen Daten vorliegen.
==Online- und Offline-Forensik==
Auch bei der Datenbankforensik können Analysen in Online- und Offline-Forensik unterteilt werden. Bei der Online-Forensik einer Datenbank sollten vorab alle Caches und weitere flüchtige Daten gesichert und gesichtet werden, ohne diese zu verändern. Bei unbedachten Logins oder Ausführungen von Statements werden Caches, Buffer und Logfiles evtl. verfälscht, indem analyserelevante Artefakte überschrieben werden. Während der Online-Forensik sollte das System für den Nutzer nicht zur Verfügung stehen, um die Analyse nicht zu verfälschen. Im Gegensatz dazu, wird bei der Offline-Forensik einer Datenbank das System vollständig, bestenfalls „hart“, heruntergefahren. Dabei gehen alle flüchtigen Daten verloren. Danach wird ein vollständiges Systemabbild gezogen, auf dem die Analyse durchgeführt wird. Anschließend kann das System wieder hochgefahren werden und steht dem Nutzer wieder zur Verfügung.

==Quellen==
* Bundesamt für Sicherheit in der Informationstechnik (BSI): Leitfaden „IT-Forensik“, Version 1.0.1 (2011)
* Kevvie Fowler: SQL Server Forensic Analysis (2008)
* Mulazzani, Martin & Weippl, Edgar: Aktuelle Herausforderungen in der Datenbankforensik (2019)

Hardware-Sicherheitsmodul

2019-07-18T16:41:40Z

St181103:

Ein '''Hardware-Sicherheitsmodul''' (HSM, engl.: Hardware Security Module) ist eine Hardware zur geschützten (Integrität, Vertraulichkeit und Verfügbarkeit) Verwaltung von Schlüsselmaterial und Ausführung kryptografischer Funktionen. Sie werden gelegentlich als "Vertrauensanker" [6] für den Aufbau von Sicherheitsarchitekturen bezeichnet und kommen sowohl in lokalen Rechenzentren ("on-premise") als auch in Cloud-Infrastrukturen zum Einsatz.

Je nach Modell stellen HSMs
* symmetrische und asymmetrische Verschlüsselungsalgorithmen
* Hashfunktionen
* Funktionen zur Erzeugung von Zufallszahlen[3]
* Funktionen zur Erzeugung von Schlüsseln
* Funktionen zur Verwaltung (Zugriffsrechte, Lebenszyklus) von Schlüsseln sowie
* Funktionen zur Verwaltung einer HSM-Infrastruktur (Backup, Verteilung, Spiegelung)
zur Verfügung[1]. Sie enthalten hierfür zum Teil spezialisierte Hardware-Bausteine, z.B. zur Erzeugung von Zufallszahlen oder zur effizienten Ausführung von Ver- und Entschlüsselungsoperationen.

HSMs werden sowohl als Teilkomponente für Rechner (z.B. PCI-Karte oder PCMCIA-Steckmodul) oder als eigenständiges Gerät (z.B. als Modul für 19-Zoll-Serverschränke) angeboten.

==Anwendungsbereiche==
HSMs kommen heute vornehmlich in Bereichen mit hohen Sicherheitsanforderungen wie
* Finanzdienstleistungen/Zahlungsverkehr
* Herstellung von Ausweisen und Kreditkarten
* Maut- und Ticketsysteme
* Zertifikats- und Signaturdienste
* Verschlüsselte Archivierung
zum Einsatz[1], finden aber mit der wachsenden Bedeutung organisationsübergreifender IT-Infrastrukturen (Stichwort: Cloud) auch darüber hinaus zunehmend Verbreitung.

==Einsatz von HSMs in IT-Sicherheitsarchitekturen==
Ausgangspunkt einer umfassenden IT-Sicherheitsarchitektur ist die sichere Verwaltung von Schlüsseln. Dies ist die zentrale Aufgabe von HSMs, wobei die Schlüssel entweder innerhalb der HSMs durch geprüfte und manipulationsgeschützte Algorithmen generiert oder extern erzeugt und auf einem sicheren Kanal auf das HSM gebracht werden (-> "Bring Your Own Key", kurz BYOK[8]).

Mit Blick auf Angriffe auf den Hauptspeicher der Nutzersysteme sollten die Schlüssel die sichere Umgebung der HSM niemals verlassen, d.h. auf Basis dieser Schlüssel durchzuführende Ver- und Entschlüsselungsoperationen erfolgen i.d.R. ebenfalls innerhalb des HSMs.

Je nach Einsatzszenario werden auch anwendungsspezifische Schlüssel oder Verbindungs¬zeichenketten (engl.: Connection Strings), die innerhalb der Anwendung verschlüsselt gespeichert werden, mithilfe eines in der HSM gespeicherten Master-Keys ver- bzw. entschlüsselt und nur zur Laufzeit der Anwendung im Klartext im Hauptspeicher gehalten (Beispiel: MS Azure SQL TDE mit Azure KeyVault -> "TDE-Protector" = MasterKey, "Database Encryption Key" (DEK) = anwendungsspezifischer Schlüssel[8]). Dieses Vorgehen ist mitunter aus Gründen des Durchsatzes oder der Anwendungsarchitektur (z.B. Datenbanken) erforderlich; in diesem Fall sind jedoch die Anwendungsdaten und der anwendungsspezifische Schlüssel während zur Laufzeit der Anwendung im Hauptspeicher angreifbar.

Ein weiteres Einsatzszenario ist die sichere Erzeugung temporärer Sitzungsschlüssel (engl. Session Keys) durch ein HSM.

==Zertifizierungen für HSMs==
Für HSMs existieren verschiedene Sicherheitsstandards, nach denen diese Geräte zertifiziert werden können. Der geläufigste in diesem Kontext ist FIPS (Federal Information Processing Standards) 140-2. Die Nachfolgeversion FIPS 140-3 stellt keinen eigenständigen Standard mehr dar, sondern referenziert ihrerseits den internationalen Standard ISO/IEC 19790:2012[7] bzw. ISO/IEC 24759:2017.

FIPS 140-2 unterscheidet vier aufeinander aufbauende Sicherheitsstufen (engl.: Levels)[2]
* '''Level 1''' - Verwendung freigegebener Algorithmen; keine spez. Sicherheitsanforderungen an die Hardware
* '''Level 2''' - Hardware muss physisch so aufgebaut sein, dass Manipulationen bzw. Manipulationsversuche erkannt werden können (engl.: "tamper-evident")
* '''Level 3''' - Hardware muss physisch so aufgebaut sein, dass "einfache" Manipulationen bzw. Manipulationsversuche erkannt und (z.B. durch sichere Löschung der Daten) verhindert werden (engl: "tamper-proof").
* '''Level 4''' - Ähnlich wie Level 3, jedoch muss der Schutz hier "mit sehr hoher Wahrscheinlichkeit" gegen alle denkbaren Angriffe wirksam sein. Geräte dieses Levels sollen insbesondere für den Einsatz in ungeschützten Umgebungen geeignet sein.

:
{| class="wikitable"
!colspan="5"|Zusammenfassung der Anforderungen pro Sicherheitsstufe nach FIPS 140-2[4]
|-
|
|Sicherheitsstufe 1
|Sicherheitsstufe 2
|Sicherheitsstufe 3
|Sicherheitsstufe 4
|-
|Spezifikation des kryptografischen Moduls
|colspan="4"|Spezifikation des kryptografischen Moduls, der kryptografischen Abgrenzung, der freigegebenen Algorithmen und der freigegebenen Betriebsmodi. Beschreibung des kryptografischen Moduls, einschließlich aller Hardware-, Software- und Firmware-Komponenten. Erklärung der Sicherheitsrichtlinie des Moduls.
|-
|Anschlüsse und Schnittstellen des kryptografischen Moduls
|colspan="2"|Notwendige und optionale Schnittstellen. Spezifikation aller Schnittstellen und aller Eingangs- und Ausgangsdatenpfade.
|colspan="2"|Datenanschlüsse für ungesicherte kritische Sicherheitsparameter (engl.: Critical Security Parameter, CSP) logisch oder physisch getrennt von anderen Anschlüssen.
|-
|Rollen, Dienste und Authentifizierung
|Logische Trennung von notwendigen und optionalen Rollen und Diensten.
|Rollen- oder Identitäts-basierte Bediener-Authentifizierung
|colspan="2"|Identitäts-basierte Bediener-Authentifizierung
|-
|Endlicher Zustandsautomat
|colspan="4"|Spezifikation eines endlichen Zustandsautomaten. Notwendige und optionale Zustände. Zustands-Übergangs-Diagramm und Spezifikation der Zustandsübergänge.
|-
|Betriebsumfeld
|Einzelner Bediener. Ausführbarer Code. Freigegebener Integritätssicherungs-Mechanismus
|Gemäß EAL2 festgelegte Schutzprofile (engl.: Protection Profile, PP) mit spezifizierten Benutzerbestimmbaren Zugriffskontrollmechnismen und Auditierung
|Gemäß EAL3 festgelegte Schutzprofile mit Sicherheitsrichtlinien-Modellierung.
|Gemäß EAL4 festgelegte Schutzprofile mit vertrauenswürdigem Pfad (engl.: Trusted Path).
|-
|rowspan="2"|Kryptografisches Schlüsselmanagement
|colspan="4"|Schlüsselmanagement-Mechanismen: Zufallszahlen- und Schlüsselgenerierung, Schlüsseleinrichtung, Schlüsselverteilung, Schlüsselein-/-ausgabe, Schlüsselspeicherung und Schlüssel-Nullsetzung (engl.: Zeroization).
|-
|colspan="2"|Geheime und private Schlüssel, die manuell eingerichtet wurden, können in Klartextform ein- oder ausgegeben werden.
|colspan="2"|Geheime und private Schlüssel, die manuell eingerichtet wurden, sollen verschlüsselt oder mit Split-Knowledge-Verfahren ein- oder ausgegeben werden.
|-
|EM-Interferenz / EM-Kompatibilität
|colspan="2"|47 CFR FCC Part 15. Subpart B, Class A (gewerbliche Nutzung). Anwendbare FCC-Anforderungen (für Funk).
|colspan="2"|47 CFR FCC Part 15. Subpart B, Class B (private Nutzung).
|-
|Selbsttest
|colspan="4"|Einschalttests: Tests der kryptografischen Algorithmen, Software-/Firmware-Integritätstests, Tests kritischer Funktionen. Bedingte Tests.
|-
|Entwurfsabsicherung
|Konfigurations-management (KM). Sichere Installation und Generierung. Übereinstimmung von Entwurf und Richtlinie Leitlinien-Dokumente
|KM-System. Sichere Verteilung. Funktionale Spezifikation.
|Implementierung in Hochsprache
|Formale Modellierung. Detaillierte Erläuterungen (informelle Beweise). Vor- und Nachbedingungen
|-
|Mitigation anderer Angriffe
|colspan="4"|Spezifikation der Mitigation von Angriffen, für die derzeit keine testbaren Anforderungen verfügbar sind.
|}

Das NIST stellt ein Online-Verzeichnis von gem. FIPS 140-2 zertifizierten Geräten zur Verfügung[5].

==Aspekte der Sicherheitsorganisation==
HSMs dienen ggü. rein software-gestützten "Schlüsseltresoren" hauptsächlich dem Schutz vor Angriffen von Tätern innerhalb der Anwenderorganisation (lokale Server) bzw. in Cloud-Umgebungen gegen die Angriffsszenarien "Cloud-Anbieter gegen Cloud-Nutzer" und "Cloud-Nachbar gegen Cloud-Nutzer".

Im Hinblick auf die Gestaltung einer Sicherheitsorganisation unterstützen HSMs auf verschiedene Weise:
Erweiterte Funktionstrennung: Mit der Verwendung von HSMs kann neben den geläufigen Administrationsbereichen (Betriebssysteme, Anwendungen, Datenbanken und Netzwerke) ein eigenständiger Administrationsbereich für Schlüsselverwaltung und Kryptofunktionen geschaffen werden.
Mehr-Augen-Prinzip: HSMs bieten in der Regel Funktionen, die den Zugriff auf Schlüsselmaterial oder die Konfiguration von Kryptofunktionen nach einem "erweiterten 4-Augen-Prinzip" schützen, d.h. es können Richtlinien festgelegt werden, dass solche Änderungen nur mit der Freigaben von mehreren Personen aus dem Pool der Administrationsberechtigten möglich sind ("k-aus-n").
Zentralisierung der Schlüsselmanagements: HSMs bieten in der Regel Unterstützung für ihre sichere, zentrale Administration, Verteilung, Sicherung und Überwachung.

==HSMs aus Sicht der IT-Forensik==
Aus IT-forensischer Sicht sollte die Frage, ob in einer lokalen Client-Server-Architektur oder einer Cloud-Architektur HSMs zum Einsatz kommen, Teil der Operationalen Vorbereitung sein, da dies wesentlichen Einfluss auf das weitere Vorgehen haben sollte.

In einer IT-Sicherheitsarchitektur unter Einsatz von HSMs ist davon auszugehen, dass insbesondere sicherheitskritische Datenbereiche im Transport (Data in Transit) und in der persistenten Speicherung (Data at Rest) sicher verschlüsselt und damit der Auswertung nicht zugänglich sein werden. Damit kommt einerseits der Live-Akquise (Data in Use) eine höhere Bedeutung zu (ggf. Auslesen von anwendungsspezifischen Schlüsseln, s.o.). Andererseits kommt der Frage, ob von einer Kooperation der Krypto-Administration ausgegangen werden kann, eine besondere Bedeutung zu.

==Weblinks==
[1] https://de.wikipedia.org/wiki/Hardware-Sicherheitsmodul

[2] https://en.wikipedia.org/wiki/FIPS_140-2

[3] http://hsm.utimaco.com/de/loesungen/anwendungen/zufallszahlengenerator/

[4] http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf

[5] https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search

{6] https://safenet.gemalto.de/data-encryption/hardware-security-modules-hsms/

[7] https://www.iso.org/standard/52906.html

[8] https://docs.microsoft.com/en-us/azure/sql-database/transparent-data-encryption-byok-azure-sql

Hauptseite

2019-07-18T06:08:29Z

St181103: /* H */

Willkommen beim IT-Forensik-Wiki der Hochschule Wismar. Hier werden wesentliche Begriffe zum Thema „Digitale Forensik“ erläutert.

== Literatur ==

[[Abschlussarbeiten im Bachelor Studiengang "IT-Forensik"]]

[[Abschlussarbeiten im Master Studiengang "IT-Sicherheit und Forensik"]]

[[Projektarbeiten]]

[[Forensik in DB]]

== Stichworte IT-Forensik ==
=== A ===
[[Anti-Forensik]]

=== B ===
[[BSI-Vorgehensmodell]]

[[Betriebssystem]]

=== C ===
[[Cache]]

[[CERT-Taxonomie]]

[[Chip-Off]]

[[Cross Site Scripting (XSS)]]

=== D ===
[[Darknet]]

[[Datenanalyse]]

[[Datenvernichtung]]

[[Datensammlung]]

[[DDL & DML]]

[[Digitale Forensik]]

[[Dokumentation]]

[[Dual Use Software]]

=== E ===
[[Ermittlungsprozess]] 

[[Exploit]]

=== F ===
[[File Carving]]

[[Flüchtige Daten]]

[[Fragmentierung]]

=== G ===
[[Geotag]]

[[Gerichtsfestigkeit]]

=== H ===
[[Hilfstatort]]

[[Hardware-Sicherheitsmodul]]

[[Hashcat]]

[[Honeypot]]

=== I ===
[[Incident-Response-Team]]

[[IT-Forensik]]

=== J ===
[[Jailbreak]]

=== K ===
[[Kausalität in der Forensik]]

[[Korrelation]]

=== L ===
[[Live-Forensik]]

[[Log-File]]

=== M ===
[[Metadaten]]

[[Mobiltelefon-Forensik]]

=== N ===
[[Netflow]]

[[Never-Touch-Original]]

=== O ===
[[Online-Forensik]]

[[Offline-Forensik]]

[[OS Fingerprinting]]

=== P ===
[[Partition]]

[[P2P (Peer-to-Peer) Software / Netzwerke]]

[[Post-Mortem-Analyse]]

[[Prozess der Mobiltelefon Forensik]]

[[Prüfsumme]]

[[PCMCIA]]

[[Penetrationstest]]

=== R ===
[[Rainbow Table]]

[[Remote Access Trojaner (RAT)]]

[[Reverse Engineering]]

=== S ===
[[SAP-Modell]]

[[Sandbox]]

[[Security Information and Event Management (SIEM)]]

[[Skimming]]

[[Sniffing]]

[[SQL Injection]]

[[Sealbag]]

[[SpiderFoot]]

=== T ===
[[Tatort]]

[[Timeline]]

=== U ===
[[Unallocated Data (Nicht zugeordnete Daten)]]

=== V ===
[[Video-Forensik]]

=== W ===
[[W-Fragen]]

[[Wiping]]

[[Write Blocker]]

=== Z ===
[[Zeit]]

== Interessante Links ==

Tsurugi Forensik-Linux https://tsurugi-linux.org

== Fernstudiengänge an der Hochschule Wismar (berufsbegleitend) ==

[https://fiw.hs-wismar.de/bereiche/eui/studiengaenge/it-forensik-bachelor-fernstudium-beng/ IT-Forensik, Bachelor]

[https://fiw.hs-wismar.de/bereiche/eui/studiengaenge/it-sicherheit-und-forensik-master-fernstudium-meng/ IT-Sicherheit und Forensik, Master]

== Starthilfen ==

* Hilfe zur Benutzung und Konfiguration der Wiki-Software finden Sie im [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents Benutzerhandbuch]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Liste der Konfigurationsvariablen]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki-FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce Mailingliste neuer MediaWiki-Versionen]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Übersetze MediaWiki für deine Sprache]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Erfahre, wie du Spam auf deinem Wiki bekämpfen kannst]

Hardware Security Module

2019-07-18T06:07:48Z

St181103: St181103 verschob die Seite Hardware Security Module nach Hardware-Sicherheitsmodul: Übersetzung

#WEITERLEITUNG [[Hardware-Sicherheitsmodul]]

Hardware-Sicherheitsmodul

2019-07-18T06:07:48Z

St181103: St181103 verschob die Seite Hardware Security Module nach Hardware-Sicherheitsmodul: Übersetzung

Ein '''Hardware-Sicherheitsmodul''' (HSM, engl.: Hardware Security Module) ist eine Hardware zur geschützten (Integrität, Vertraulichkeit und Verfügbarkeit) Verwaltung von Schlüsselmaterial und Ausführung kryptografischer Funktionen. Sie werden gelegentlich als "Vertrauensanker" [6] für den Aufbau von Sicherheitsarchitekturen bezeichnet und kommen sowohl in lokalen Rechenzentren ("on-premise") als auch in Cloud-Infrastrukturen zum Einsatz.

Je nach Modell stellen HSMs
* symmetrische und asymmetrische Verschlüsselungsalgorithmen
* Hashfunktionen
* Funktionen zur Erzeugung von Zufallszahlen[3]
* Funktionen zur Erzeugung von Schlüsseln
* Funktionen zur Verwaltung (Zugriffsrechte, Lebenszyklus) von Schlüsseln sowie
* Funktionen zur Verwaltung einer HSM-Infrastruktur (Backup, Verteilung, Spiegelung)
zur Verfügung[1]. Sie enthalten hierfür zum Teil spezialisierte Hardware-Bausteine, z.B. zur Erzeugung von Zufallszahlen oder zur effizienten Ausführung von Ver- und Entschlüsselungsoperationen.

HSMs werden sowohl als Teilkomponente für Rechner (z.B. PCI-Karte oder PCMCIA-Steckmodul) oder als eigenständiges Gerät (z.B. als Modul für 19-Zoll-Serverschränke) angeboten.

==Anwendungsbereiche==
HSMs kommen heute vornehmlich in Bereichen mit hohen Sicherheitsanforderungen wie
* Finanzdienstleistungen/Zahlungsverkehr
* Herstellung von Ausweisen und Kreditkarten
* Maut- und Ticketsysteme
* Zertifikats- und Signaturdienste
* Verschlüsselte Archivierung
zum Einsatz[1], finden aber mit der wachsenden Bedeutung organisationsübergreifender IT-Infrastrukturen (Stichwort: Cloud) auch darüber hinaus zunehmend Verbreitung.

==Einsatz von HSMs in IT-Sicherheitsarchitekturen==
Ausgangspunkt einer umfassenden IT-Sicherheitsarchitektur ist die sichere Verwaltung von Schlüsseln. Dies ist die zentrale Aufgabe von HSMs, wobei die Schlüssel entweder innerhalb der HSMs durch geprüfte und manipulationsgeschützte Algorithmen generiert oder extern erzeugt und auf einem sicheren Kanal auf das HSM gebracht werden (-> "Bring Your Own Key", kurz BYOK[8]).

Mit Blick auf Angriffe auf den Hauptspeicher der Nutzersysteme sollten die Schlüssel die sichere Umgebung der HSM niemals verlassen, d.h. auf Basis dieser Schlüssel durchzuführende Ver- und Entschlüsselungsoperationen erfolgen i.d.R. ebenfalls innerhalb des HSMs.

Je nach Einsatzszenario werden auch anwendungsspezifische Schlüssel oder Verbindungs¬zeichenketten (engl.: Connection Strings), die innerhalb der Anwendung verschlüsselt gespeichert werden, mithilfe eines in der HSM gespeicherten Master-Keys ver- bzw. entschlüsselt und nur zur Laufzeit der Anwendung im Klartext im Hauptspeicher gehalten (Beispiel: MS Azure SQL TDE mit Azure KeyVault -> "TDE-Protector" = MasterKey, "Database Encryption Key" (DEK) = anwendungsspezifischer Schlüssel[8]). Dieses Vorgehen ist mitunter aus Gründen des Durchsatzes oder der Anwendungsarchitektur (z.B. Datenbanken) erforderlich; in diesem Fall sind jedoch die Anwendungsdaten und der anwendungsspezifische Schlüssel während zur Laufzeit der Anwendung im Hauptspeicher angreifbar.

Ein weiteres Einsatzszenario ist die sichere Erzeugung temporärer Sitzungsschlüssel (engl. Session Keys) durch ein HSM.

==Zertifizierungen für HSMs==
Für HSMs existieren verschiedene Sicherheitsstandards, nach denen diese Geräte zertifiziert werden können. Der geläufigste in diesem Kontext ist FIPS (Federal Information Processing Standards) 140-2. Die Nachfolgeversion FIPS 140-3 stellt keinen eigenständigen Standard mehr dar, sondern referenziert ihrerseits den internationalen Standard ISO/IEC 19790:2012[7] bzw. ISO/IEC 24759:2017.

FIPS 140-2 unterscheidet vier aufeinander aufbauende Sicherheitsstufen (engl.: Levels)[2]
* '''Level 1''' - Verwendung freigegebener Algorithmen; keine spez. Sicherheitsanforderungen an die Hardware
* '''Level 2''' - Hardware muss physisch so aufgebaut sein, dass Manipulationen bzw. Manipulationsversuche erkannt werden können (engl.: "tamper-evident")
* '''Level 3''' - Hardware muss physisch so aufgebaut sein, dass "einfache" Manipulationen bzw. Manipulationsversuche erkannt und (z.B. durch sichere Löschung der Daten) verhindert werden (engl: "tamper-proof").
* '''Level 4''' - Ähnlich wie Level 3, jedoch muss der Schutz hier "mit sehr hoher Wahrscheinlichkeit" gegen alle denkbaren Angriffe wirksam sein. Geräte dieses Levels sollen insbesondere für den Einsatz in ungeschützten Umgebungen geeignet sein.

:
{| class="wikitable"
!colspan="5"|Zusammenfassung der Anforderungen pro Sicherheitsstufe nach FIPS 140-2[4]
|-
|
|Stufe 1
|Stufe 2
|Stufe 3
|Stufe 4
|-
|Cryptographic Module Specification
|colspan="4"|Specification of cryptographic module, cryptographic boundary, Approved algorithms, and Approved modes of operation. Description of cryptographic module, including all hardware, software, and firmware components. Statement of module security policy.
|-
|Cryptographic Module Ports and Interfaces
|colspan="2"|Required and optional interfaces. Specification of all interfaces and of all input and output data paths.
|colspan="2"|Data ports for unprotected critical security parameters logically or physically separated from other data ports.
|-
|Roles, Services, and Authentication
|Logical separation of required and optional roles and services.
|Role-based or identity-based operator authentication.
|colspan="2"|Identity-based operator authentication.
|-
|Finite State Model
|colspan="4"|Specification of finite state model. Required states and optional states. State transition diagram and specification of state transitions.
|-
|Operational Environment
|Single operator. Executable code. Approved integrity technique
|Referenced PPs evaluated at EAL2 with specified discretionary access control mechanisms and auditing.
|Referenced PPs plus trusted path evaluated at EAL3 plus security policy modeling.
|Referenced PPs plus trusted path evaluated at EAL4.
|-
|rowspan="2"|Cryptographic Key Management
|colspan="4"|Key management mechanisms: random number and key generation, key establishment, key distribution, key entry/output, key storage, and key zeroization.
|-
|colspan="2"|Secret and private keys established using manual methods may be entered or output in plaintext form.
|colspan="2"|Secret and private keys established using manual methods shall be entered or output encrypted or with split knowledge procedures.
|-
|EMI/EMC
|colspan="2"|47 CFR FCC Part 15. Subpart B, Class A (Business use). Applicable FCC requirements (for radio).
|colspan="2"|47 CFR FCC Part 15. Subpart B, Class B (Home use).
|-
|Self-Tests
|colspan="4"|Power-up tests: cryptographic algorithm tests, software/firmware integrity tests, critical functions tests. Conditional tests.
|-
|Design Assurance
|Configuration management (CM). Secure installation and generation. Design and policy correspondence. Guidance documents.
|CM system. Secure distribution. Functional specification.
|High-level language implementation.
|Formal model. Detailed explanations (informal proofs). Preconditions and postcondition
|-
|Mitigation of Other Attack
|colspan="4"|Specification of mitigation of attacks for which no testable requirements are currently available.
|}

Das NIST stellt ein Online-Verzeichnis von gem. FIPS 140-2 zertifizierten Geräten zur Verfügung[5].

==Aspekte der Sicherheitsorganisation==
HSMs dienen ggü. rein software-gestützten "Schlüsseltresoren" hauptsächlich dem Schutz vor Angriffen von Tätern innerhalb der Anwenderorganisation (lokale Server) bzw. in Cloud-Umgebungen gegen die Angriffsszenarien "Cloud-Anbieter gegen Cloud-Nutzer" und "Cloud-Nachbar gegen Cloud-Nutzer".

Im Hinblick auf die Gestaltung einer Sicherheitsorganisation unterstützen HSMs auf verschiedene Weise:
Erweiterte Funktionstrennung: Mit der Verwendung von HSMs kann neben den geläufigen Administrationsbereichen (Betriebssysteme, Anwendungen, Datenbanken und Netzwerke) ein eigenständiger Administrationsbereich für Schlüsselverwaltung und Kryptofunktionen geschaffen werden.
Mehr-Augen-Prinzip: HSMs bieten in der Regel Funktionen, die den Zugriff auf Schlüsselmaterial oder die Konfiguration von Kryptofunktionen nach einem "erweiterten 4-Augen-Prinzip" schützen, d.h. es können Richtlinien festgelegt werden, dass solche Änderungen nur mit der Freigaben von mehreren Personen aus dem Pool der Administrationsberechtigten möglich sind ("k-aus-n").
Zentralisierung der Schlüsselmanagements: HSMs bieten in der Regel Unterstützung für ihre sichere, zentrale Administration, Verteilung, Sicherung und Überwachung.

==HSMs aus Sicht der IT-Forensik==
Aus IT-forensischer Sicht sollte die Frage, ob in einer lokalen Client-Server-Architektur oder einer Cloud-Architektur HSMs zum Einsatz kommen, Teil der Operationalen Vorbereitung sein, da dies wesentlichen Einfluss auf das weitere Vorgehen haben sollte.

In einer IT-Sicherheitsarchitektur unter Einsatz von HSMs ist davon auszugehen, dass insbesondere sicherheitskritische Datenbereiche im Transport (Data in Transit) und in der persistenten Speicherung (Data at Rest) sicher verschlüsselt und damit der Auswertung nicht zugänglich sein werden. Damit kommt einerseits der Live-Akquise (Data in Use) eine höhere Bedeutung zu (ggf. Auslesen von anwendungsspezifischen Schlüsseln, s.o.). Andererseits kommt der Frage, ob von einer Kooperation der Krypto-Administration ausgegangen werden kann, eine besondere Bedeutung zu.

==Weblinks==
[1] https://de.wikipedia.org/wiki/Hardware-Sicherheitsmodul

[2] https://en.wikipedia.org/wiki/FIPS_140-2

[3] http://hsm.utimaco.com/de/loesungen/anwendungen/zufallszahlengenerator/

[4] http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf

[5] https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search

{6] https://safenet.gemalto.de/data-encryption/hardware-security-modules-hsms/

[7] https://www.iso.org/standard/52906.html

[8] https://docs.microsoft.com/en-us/azure/sql-database/transparent-data-encryption-byok-azure-sql

Hauptseite

2019-07-17T20:05:55Z

St181103: /* H */

Willkommen beim IT-Forensik-Wiki der Hochschule Wismar. Hier werden wesentliche Begriffe zum Thema „Digitale Forensik“ erläutert.

== Literatur ==

[[Abschlussarbeiten im Bachelor Studiengang "IT-Forensik"]]

[[Abschlussarbeiten im Master Studiengang "IT-Sicherheit und Forensik"]]

[[Projektarbeiten]]

[[Forensik in DB]]

== Stichworte IT-Forensik ==
=== A ===
[[Anti-Forensik]]

=== B ===
[[BSI-Vorgehensmodell]]

[[Betriebssystem]]

=== C ===
[[Cache]]

[[CERT-Taxonomie]]

[[Chip-Off]]

[[Cross Site Scripting (XSS)]]

=== D ===
[[Darknet]]

[[Datenanalyse]]

[[Datenvernichtung]]

[[Datensammlung]]

[[DDL & DML]]

[[Digitale Forensik]]

[[Dokumentation]]

[[Dual Use Software]]

=== E ===
[[Ermittlungsprozess]] 

[[Exploit]]

=== F ===
[[File Carving]]

[[Flüchtige Daten]]

[[Fragmentierung]]

=== G ===
[[Geotag]]

[[Gerichtsfestigkeit]]

=== H ===
[[Hilfstatort]]

[[Hardware Security Module]]

[[Hashcat]]

[[Honeypot]]

=== I ===
[[Incident-Response-Team]]

[[IT-Forensik]]

=== J ===
[[Jailbreak]]

=== K ===
[[Kausalität in der Forensik]]

[[Korrelation]]

=== L ===
[[Live-Forensik]]

[[Log-File]]

=== M ===
[[Metadaten]]

[[Mobiltelefon-Forensik]]

=== N ===
[[Netflow]]

[[Never-Touch-Original]]

=== O ===
[[Online-Forensik]]

[[Offline-Forensik]]

[[OS Fingerprinting]]

=== P ===
[[Partition]]

[[P2P (Peer-to-Peer) Software / Netzwerke]]

[[Post-Mortem-Analyse]]

[[Prozess der Mobiltelefon Forensik]]

[[Prüfsumme]]

[[PCMCIA]]

[[Penetrationstest]]

=== R ===
[[Rainbow Table]]

[[Remote Access Trojaner (RAT)]]

[[Reverse Engineering]]

=== S ===
[[SAP-Modell]]

[[Sandbox]]

[[Security Information and Event Management (SIEM)]]

[[Skimming]]

[[Sniffing]]

[[SQL Injection]]

[[Sealbag]]

[[SpiderFoot]]

=== T ===
[[Tatort]]

[[Timeline]]

=== U ===
[[Unallocated Data (Nicht zugeordnete Daten)]]

=== V ===
[[Video-Forensik]]

=== W ===
[[W-Fragen]]

[[Wiping]]

[[Write Blocker]]

=== Z ===
[[Zeit]]

== Interessante Links ==

Tsurugi Forensik-Linux https://tsurugi-linux.org

== Fernstudiengänge an der Hochschule Wismar (berufsbegleitend) ==

[https://fiw.hs-wismar.de/bereiche/eui/studiengaenge/it-forensik-bachelor-fernstudium-beng/ IT-Forensik, Bachelor]

[https://fiw.hs-wismar.de/bereiche/eui/studiengaenge/it-sicherheit-und-forensik-master-fernstudium-meng/ IT-Sicherheit und Forensik, Master]

== Starthilfen ==

* Hilfe zur Benutzung und Konfiguration der Wiki-Software finden Sie im [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents Benutzerhandbuch]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Liste der Konfigurationsvariablen]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki-FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce Mailingliste neuer MediaWiki-Versionen]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Übersetze MediaWiki für deine Sprache]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Erfahre, wie du Spam auf deinem Wiki bekämpfen kannst]

Hardware-Sicherheitsmodul

2019-07-17T20:00:32Z

St181103:

Ein '''Hardware-Sicherheitsmodul''' (HSM, engl.: Hardware Security Module) ist eine Hardware zur geschützten (Integrität, Vertraulichkeit und Verfügbarkeit) Verwaltung von Schlüsselmaterial und Ausführung kryptografischer Funktionen. Sie werden gelegentlich als "Vertrauensanker" [6] für den Aufbau von Sicherheitsarchitekturen bezeichnet und kommen sowohl in lokalen Rechenzentren ("on-premise") als auch in Cloud-Infrastrukturen zum Einsatz.

Je nach Modell stellen HSMs
* symmetrische und asymmetrische Verschlüsselungsalgorithmen
* Hashfunktionen
* Funktionen zur Erzeugung von Zufallszahlen[3]
* Funktionen zur Erzeugung von Schlüsseln
* Funktionen zur Verwaltung (Zugriffsrechte, Lebenszyklus) von Schlüsseln sowie
* Funktionen zur Verwaltung einer HSM-Infrastruktur (Backup, Verteilung, Spiegelung)
zur Verfügung[1]. Sie enthalten hierfür zum Teil spezialisierte Hardware-Bausteine, z.B. zur Erzeugung von Zufallszahlen oder zur effizienten Ausführung von Ver- und Entschlüsselungsoperationen.

HSMs werden sowohl als Teilkomponente für Rechner (z.B. PCI-Karte oder PCMCIA-Steckmodul) oder als eigenständiges Gerät (z.B. als Modul für 19-Zoll-Serverschränke) angeboten.

==Anwendungsbereiche==
HSMs kommen heute vornehmlich in Bereichen mit hohen Sicherheitsanforderungen wie
* Finanzdienstleistungen/Zahlungsverkehr
* Herstellung von Ausweisen und Kreditkarten
* Maut- und Ticketsysteme
* Zertifikats- und Signaturdienste
* Verschlüsselte Archivierung
zum Einsatz[1], finden aber mit der wachsenden Bedeutung organisationsübergreifender IT-Infrastrukturen (Stichwort: Cloud) auch darüber hinaus zunehmend Verbreitung.

==Einsatz von HSMs in IT-Sicherheitsarchitekturen==
Ausgangspunkt einer umfassenden IT-Sicherheitsarchitektur ist die sichere Verwaltung von Schlüsseln. Dies ist die zentrale Aufgabe von HSMs, wobei die Schlüssel entweder innerhalb der HSMs durch geprüfte und manipulationsgeschützte Algorithmen generiert oder extern erzeugt und auf einem sicheren Kanal auf das HSM gebracht werden (-> "Bring Your Own Key", kurz BYOK[8]).

Mit Blick auf Angriffe auf den Hauptspeicher der Nutzersysteme sollten die Schlüssel die sichere Umgebung der HSM niemals verlassen, d.h. auf Basis dieser Schlüssel durchzuführende Ver- und Entschlüsselungsoperationen erfolgen i.d.R. ebenfalls innerhalb des HSMs.

Je nach Einsatzszenario werden auch anwendungsspezifische Schlüssel oder Verbindungs¬zeichenketten (engl.: Connection Strings), die innerhalb der Anwendung verschlüsselt gespeichert werden, mithilfe eines in der HSM gespeicherten Master-Keys ver- bzw. entschlüsselt und nur zur Laufzeit der Anwendung im Klartext im Hauptspeicher gehalten (Beispiel: MS Azure SQL TDE mit Azure KeyVault -> "TDE-Protector" = MasterKey, "Database Encryption Key" (DEK) = anwendungsspezifischer Schlüssel[8]). Dieses Vorgehen ist mitunter aus Gründen des Durchsatzes oder der Anwendungsarchitektur (z.B. Datenbanken) erforderlich; in diesem Fall sind jedoch die Anwendungsdaten und der anwendungsspezifische Schlüssel während zur Laufzeit der Anwendung im Hauptspeicher angreifbar.

Ein weiteres Einsatzszenario ist die sichere Erzeugung temporärer Sitzungsschlüssel (engl. Session Keys) durch ein HSM.

==Zertifizierungen für HSMs==
Für HSMs existieren verschiedene Sicherheitsstandards, nach denen diese Geräte zertifiziert werden können. Der geläufigste in diesem Kontext ist FIPS (Federal Information Processing Standards) 140-2. Die Nachfolgeversion FIPS 140-3 stellt keinen eigenständigen Standard mehr dar, sondern referenziert ihrerseits den internationalen Standard ISO/IEC 19790:2012[7] bzw. ISO/IEC 24759:2017.

FIPS 140-2 unterscheidet vier aufeinander aufbauende Sicherheitsstufen (engl.: Levels)[2]
* '''Level 1''' - Verwendung freigegebener Algorithmen; keine spez. Sicherheitsanforderungen an die Hardware
* '''Level 2''' - Hardware muss physisch so aufgebaut sein, dass Manipulationen bzw. Manipulationsversuche erkannt werden können (engl.: "tamper-evident")
* '''Level 3''' - Hardware muss physisch so aufgebaut sein, dass "einfache" Manipulationen bzw. Manipulationsversuche erkannt und (z.B. durch sichere Löschung der Daten) verhindert werden (engl: "tamper-proof").
* '''Level 4''' - Ähnlich wie Level 3, jedoch muss der Schutz hier "mit sehr hoher Wahrscheinlichkeit" gegen alle denkbaren Angriffe wirksam sein. Geräte dieses Levels sollen insbesondere für den Einsatz in ungeschützten Umgebungen geeignet sein.

:
{| class="wikitable"
!colspan="5"|Zusammenfassung der Anforderungen pro Sicherheitsstufe nach FIPS 140-2[4]
|-
|
|Stufe 1
|Stufe 2
|Stufe 3
|Stufe 4
|-
|Cryptographic Module Specification
|colspan="4"|Specification of cryptographic module, cryptographic boundary, Approved algorithms, and Approved modes of operation. Description of cryptographic module, including all hardware, software, and firmware components. Statement of module security policy.
|-
|Cryptographic Module Ports and Interfaces
|colspan="2"|Required and optional interfaces. Specification of all interfaces and of all input and output data paths.
|colspan="2"|Data ports for unprotected critical security parameters logically or physically separated from other data ports.
|-
|Roles, Services, and Authentication
|Logical separation of required and optional roles and services.
|Role-based or identity-based operator authentication.
|colspan="2"|Identity-based operator authentication.
|-
|Finite State Model
|colspan="4"|Specification of finite state model. Required states and optional states. State transition diagram and specification of state transitions.
|-
|Operational Environment
|Single operator. Executable code. Approved integrity technique
|Referenced PPs evaluated at EAL2 with specified discretionary access control mechanisms and auditing.
|Referenced PPs plus trusted path evaluated at EAL3 plus security policy modeling.
|Referenced PPs plus trusted path evaluated at EAL4.
|-
|rowspan="2"|Cryptographic Key Management
|colspan="4"|Key management mechanisms: random number and key generation, key establishment, key distribution, key entry/output, key storage, and key zeroization.
|-
|colspan="2"|Secret and private keys established using manual methods may be entered or output in plaintext form.
|colspan="2"|Secret and private keys established using manual methods shall be entered or output encrypted or with split knowledge procedures.
|-
|EMI/EMC
|colspan="2"|47 CFR FCC Part 15. Subpart B, Class A (Business use). Applicable FCC requirements (for radio).
|colspan="2"|47 CFR FCC Part 15. Subpart B, Class B (Home use).
|-
|Self-Tests
|colspan="4"|Power-up tests: cryptographic algorithm tests, software/firmware integrity tests, critical functions tests. Conditional tests.
|-
|Design Assurance
|Configuration management (CM). Secure installation and generation. Design and policy correspondence. Guidance documents.
|CM system. Secure distribution. Functional specification.
|High-level language implementation.
|Formal model. Detailed explanations (informal proofs). Preconditions and postcondition
|-
|Mitigation of Other Attack
|colspan="4"|Specification of mitigation of attacks for which no testable requirements are currently available.
|}

Das NIST stellt ein Online-Verzeichnis von gem. FIPS 140-2 zertifizierten Geräten zur Verfügung[5].

==Aspekte der Sicherheitsorganisation==
HSMs dienen ggü. rein software-gestützten "Schlüsseltresoren" hauptsächlich dem Schutz vor Angriffen von Tätern innerhalb der Anwenderorganisation (lokale Server) bzw. in Cloud-Umgebungen gegen die Angriffsszenarien "Cloud-Anbieter gegen Cloud-Nutzer" und "Cloud-Nachbar gegen Cloud-Nutzer".

Im Hinblick auf die Gestaltung einer Sicherheitsorganisation unterstützen HSMs auf verschiedene Weise:
Erweiterte Funktionstrennung: Mit der Verwendung von HSMs kann neben den geläufigen Administrationsbereichen (Betriebssysteme, Anwendungen, Datenbanken und Netzwerke) ein eigenständiger Administrationsbereich für Schlüsselverwaltung und Kryptofunktionen geschaffen werden.
Mehr-Augen-Prinzip: HSMs bieten in der Regel Funktionen, die den Zugriff auf Schlüsselmaterial oder die Konfiguration von Kryptofunktionen nach einem "erweiterten 4-Augen-Prinzip" schützen, d.h. es können Richtlinien festgelegt werden, dass solche Änderungen nur mit der Freigaben von mehreren Personen aus dem Pool der Administrationsberechtigten möglich sind ("k-aus-n").
Zentralisierung der Schlüsselmanagements: HSMs bieten in der Regel Unterstützung für ihre sichere, zentrale Administration, Verteilung, Sicherung und Überwachung.

==HSMs aus Sicht der IT-Forensik==
Aus IT-forensischer Sicht sollte die Frage, ob in einer lokalen Client-Server-Architektur oder einer Cloud-Architektur HSMs zum Einsatz kommen, Teil der Operationalen Vorbereitung sein, da dies wesentlichen Einfluss auf das weitere Vorgehen haben sollte.

In einer IT-Sicherheitsarchitektur unter Einsatz von HSMs ist davon auszugehen, dass insbesondere sicherheitskritische Datenbereiche im Transport (Data in Transit) und in der persistenten Speicherung (Data at Rest) sicher verschlüsselt und damit der Auswertung nicht zugänglich sein werden. Damit kommt einerseits der Live-Akquise (Data in Use) eine höhere Bedeutung zu (ggf. Auslesen von anwendungsspezifischen Schlüsseln, s.o.). Andererseits kommt der Frage, ob von einer Kooperation der Krypto-Administration ausgegangen werden kann, eine besondere Bedeutung zu.

==Weblinks==
[1] https://de.wikipedia.org/wiki/Hardware-Sicherheitsmodul

[2] https://en.wikipedia.org/wiki/FIPS_140-2

[3] http://hsm.utimaco.com/de/loesungen/anwendungen/zufallszahlengenerator/

[4] http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf

[5] https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search

{6] https://safenet.gemalto.de/data-encryption/hardware-security-modules-hsms/

[7] https://www.iso.org/standard/52906.html

[8] https://docs.microsoft.com/en-us/azure/sql-database/transparent-data-encryption-byok-azure-sql

Hardware-Sicherheitsmodul

2019-07-17T19:57:32Z

St181103: Die Seite wurde neu angelegt: „Ein '''Hardware-Sicherheitsmodul''' (HSM, engl.: Hardware Security Module) ist eine Hardware zur geschützten (Integrität, Vertraulichkeit und Verfügbarkeit)…“

Ein '''Hardware-Sicherheitsmodul''' (HSM, engl.: Hardware Security Module) ist eine Hardware zur geschützten (Integrität, Vertraulichkeit und Verfügbarkeit) Verwaltung von Schlüsselmaterial und Ausführung kryptografischer Funktionen. Sie werden gelegentlich als "Vertrauensanker" [6] für den Aufbau von Sicherheitsarchitekturen bezeichnet und kommen sowohl in lokalen Rechenzentren ("on-premise") als auch in Cloud-Infrastrukturen zum Einsatz.

Je nach Modell stellen HSMs
* symmetrische und asymmetrische Verschlüsselungsalgorithmen
* Hashfunktionen
* Funktionen zur Erzeugung von Zufallszahlen[3]
* Funktionen zur Erzeugung von Schlüsseln
* Funktionen zur Verwaltung (Zugriffsrechte, Lebenszyklus) von Schlüsseln sowie
* Funktionen zur Verwaltung einer HSM-Infrastruktur (Backup, Verteilung, Spiegelung)
zur Verfügung[1]. Sie enthalten hierfür zum Teil spezialisierte Hardware-Bausteine, z.B. zur Erzeugung von Zufallszahlen oder zur effizienten Ausführung von Ver- und Entschlüsselungsoperationen.

HSMs werden sowohl als Teilkomponente für Rechner (z.B. PCI-Karte oder PCMCIA-Steckmodul) oder als eigenständiges Gerät (z.B. als Modul für 19-Zoll-Serverschränke) angeboten.

==Anwendungsbereiche==
HSMs kommen heute vornehmlich in Bereichen mit hohen Sicherheitsanforderungen wie
* Finanzdienstleistungen/Zahlungsverkehr
* Herstellung von Ausweisen und Kreditkarten
* Maut- und Ticketsysteme
* Zertifikats- und Signaturdienste
* Verschlüsselte Archivierung
zum Einsatz[1], finden aber mit der wachsenden Bedeutung organisationsübergreifender IT-Infrastrukturen (Stichwort: Cloud) auch darüber hinaus zunehmend Verbreitung.

==Einsatz von HSMs in IT-Sicherheitsarchitekturen==
Ausgangspunkt einer umfassenden IT-Sicherheitsarchitektur ist die sichere Verwaltung von Schlüsseln. Dies ist die zentrale Aufgabe von HSMs, wobei die Schlüssel entweder innerhalb der HSMs durch geprüfte und manipulationsgeschützte Algorithmen generiert oder extern erzeugt und auf einem sicheren Kanal auf das HSM gebracht werden (-> "Bring Your Own Key", kurz BYOK[8]).

Mit Blick auf Angriffe auf den Hauptspeicher der Nutzersysteme sollten die Schlüssel die sichere Umgebung der HSM niemals verlassen, d.h. auf Basis dieser Schlüssel durchzuführende Ver- und Entschlüsselungsoperationen erfolgen i.d.R. ebenfalls innerhalb des HSMs.

Je nach Einsatzszenario werden auch anwendungsspezifische Schlüssel oder Verbindungs¬zeichenketten (engl.: Connection Strings), die innerhalb der Anwendung verschlüsselt gespeichert werden, mithilfe eines in der HSM gespeicherten Master-Keys ver- bzw. entschlüsselt und nur zur Laufzeit der Anwendung im Klartext im Hauptspeicher gehalten (Beispiel: MS Azure SQL TDE mit Azure KeyVault -> "TDE-Protector" = MasterKey, "Database Encryption Key" (DEK) = anwendungsspezifischer Schlüssel[8]). Dieses Vorgehen ist mitunter aus Gründen des Durchsatzes oder der Anwendungsarchitektur (z.B. Datenbanken) erforderlich; in diesem Fall sind jedoch die Anwendungsdaten und der anwendungsspezifische Schlüssel während zur Laufzeit der Anwendung im Hauptspeicher angreifbar.

Ein weiteres Einsatzszenario ist die sichere Erzeugung temporärer Sitzungsschlüssel (engl. Session Keys) durch ein HSM.

==Zertifizierungen für HSMs==
Für HSMs existieren verschiedene Sicherheitsstandards, nach denen diese Geräte zertifiziert werden können. Der geläufigste in diesem Kontext ist FIPS (Federal Information Processing Standards) 140-2. Die Nachfolgeversion FIPS 140-3 stellt keinen eigenständigen Standard mehr dar, sondern referenziert ihrerseits den internationalen Standard ISO/IEC 19790:2012[7] bzw. ISO/IEC 24759:2017.

FIPS 140-2 unterscheidet vier aufeinander aufbauende Sicherheitsstufen (engl.: Levels)[2]
* '''Level 1''' - Verwendung freigegebener Algorithmen; keine spez. Sicherheitsanforderungen an die Hardware
* '''Level 2''' - Hardware muss physisch so aufgebaut sein, dass Manipulationen bzw. Manipulationsversuche erkannt werden können (engl.: "tamper-evident")
* '''Level 3''' - Hardware muss physisch so aufgebaut sein, dass "einfache" Manipulationen bzw. Manipulationsversuche erkannt und (z.B. durch sichere Löschung der Daten) verhindert werden (engl: "tamper-proof").
* '''Level 4''' - Ähnlich wie Level 3, jedoch muss der Schutz hier "mit sehr hoher Wahrscheinlichkeit" gegen alle denkbaren Angriffe wirksam sein. Geräte dieses Levels sollen insbesondere für den Einsatz in ungeschützten Umgebungen geeignet sein.

:
{| class="wikitable"
!colspan="5"|Zusammenfassung der Anforderungen pro Sicherheitsstufe nach FIPS 140-2[4]
|-
|
|Stufe 1
|Stufe 2
|Stufe 3
|Stufe 4
|-
|Cryptographic Module Specification
|colspan="4"|Specification of cryptographic module, cryptographic boundary, Approved algorithms, and Approved modes of operation. Description of cryptographic module, including all hardware, software, and firmware components. Statement of module security policy.
|-
|Cryptographic Module Ports and Interfaces
|colspan="2"|Required and optional interfaces. Specification of all interfaces and of all input and output data paths.
|colspan="2"|Data ports for unprotected critical security parameters logically or physically separated from other data ports.
|-
|Roles, Services, and Authentication
|Logical separation of required and optional roles and services.
|Role-based or identity-based operator authentication.
|colspan="2"|Identity-based operator authentication.
|-
|Finite State Model
|colspan="4"|Specification of finite state model. Required states and optional states. State transition diagram and specification of state transitions.
|-
|Operational Environment
|Single operator. Executable code. Approved integrity technique
|Referenced PPs evaluated at EAL2 with specified discretionary access control mechanisms and auditing.
|Referenced PPs plus trusted path evaluated at EAL3 plus security policy modeling.
|Referenced PPs plus trusted path evaluated at EAL4.
|-
|rowspan="2"|Cryptographic Key Management
|colspan="4"|Key management mechanisms: random number and key generation, key establishment, key distribution, key entry/output, key storage, and key zeroization.
|-
|colspan="2"|Secret and private keys established using manual methods may be entered or output in plaintext form.
|colspan="2"|Secret and private keys established using manual methods shall be entered or output encrypted or with split knowledge procedures.
|-
|EMI/EMC
|colspan="2"|47 CFR FCC Part 15. Subpart B, Class A (Business use). Applicable FCC requirements (for radio).
|colspan="2"|47 CFR FCC Part 15. Subpart B, Class B (Home use).
|-
|Self-Tests
|colspan="4"|Power-up tests: cryptographic algorithm tests, software/firmware integrity tests, critical functions tests. Conditional tests.
|-
|Design Assurance
|Configuration management (CM). Secure installation and generation. Design and policy correspondence. Guidance documents.
|CM system. Secure distribution. Functional specification.
|High-level language implementation.
|Formal model. Detailed explanations (informal proofs). Preconditions and postcondition
|-
|Mitigation of Other Attack
|colspan="4"|Specification of mitigation of attacks for which no testable requirements are currently available.
|}

Das NIST stellt ein Online-Verzeichnis von gem. FIPS 140-2 zertifizierten Geräten zur Verfügung[5].

==Aspekte der Sicherheitsorganisation==
HSMs dienen ggü. rein software-gestützten "Schlüsseltresoren" hauptsächlich dem Schutz vor Angriffen von Tätern innerhalb der Anwenderorganisation (lokale Server) bzw. in Cloud-Umgebungen gegen die Angriffsszenarien "Cloud-Anbieter gegen Cloud-Nutzer" und "Cloud-Nachbar gegen Cloud-Nutzer".

Im Hinblick auf die Gestaltung einer Sicherheitsorganisation unterstützen HSMs auf verschiedene Weise:
Erweiterte Funktionstrennung: Mit der Verwendung von HSMs kann neben den geläufigen Administrationsbereichen (Betriebssysteme, Anwendungen, Datenbanken und Netzwerke) ein eigenständiger Administrationsbereich für Schlüsselverwaltung und Kryptofunktionen geschaffen werden.
Mehr-Augen-Prinzip: HSMs bieten in der Regel Funktionen, die den Zugriff auf Schlüsselmaterial oder die Konfiguration von Kryptofunktionen nach einem "erweiterten 4-Augen-Prinzip" schützen, d.h. es können Richtlinien festgelegt werden, dass solche Änderungen nur mit der Freigaben von mehreren Personen aus dem Pool der Administrationsberechtigten möglich sind ("k-aus-n").
Zentralisierung der Schlüsselmanagements: HSMs bieten in der Regel Unterstützung für ihre sichere, zentrale Administration, Verteilung, Sicherung und Überwachung.

==HSMs aus Sicht der IT-Forensik==
Aus IT-forensischer Sicht sollte die Frage, ob in einer lokalen Client-Server-Architektur oder einer Cloud-Architektur HSMs zum Einsatz kommen, Teil der operativen Vorbereitung sein, da dies wesentlichen Einfluss auf das weitere Vorgehen haben sollte.

In einer IT-Sicherheitsarchitektur unter Einsatz von HSMs ist davon auszugehen, dass insbesondere sicherheitskritische Datenbereiche im Transport (Data in Transit) und in der persistenten Speicherung (Data at Rest) sicher verschlüsselt und damit der Auswertung nicht zugänglich sein werden. Damit kommt einerseits der Live-Akquise (Data in Use) eine höhere Bedeutung zu (ggf. Auslesen von anwendungsspezifischen Schlüsseln, s.o.). Andererseits kommt der Frage, ob von einer Kooperation der Krypto-Administration ausgegangen werden kann, eine besondere Bedeutung zu.

==Weblinks==
[1] https://de.wikipedia.org/wiki/Hardware-Sicherheitsmodul

[2] https://en.wikipedia.org/wiki/FIPS_140-2

[3] http://hsm.utimaco.com/de/loesungen/anwendungen/zufallszahlengenerator/

[4] http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf

[5] https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search

{6] https://safenet.gemalto.de/data-encryption/hardware-security-modules-hsms/

[7] https://www.iso.org/standard/52906.html

[8] https://docs.microsoft.com/en-us/azure/sql-database/transparent-data-encryption-byok-azure-sql