Links zu anderen Teilen der Studie
- (Sie sind hier)
Dieser Artikel beendet die Reihe von Veröffentlichungen zur Gewährleistung der Informationssicherheit bei bankgestützten Zahlungen. Hier besprechen wir typischen Bedrohungsmodelle, auf die verwiesen wurde in :
- .
- .
- .
- .
HABRO-WARNUNG !!! Sehr geehrte Habro-Mitglieder, dies ist kein unterhaltsamer Beitrag.
Unter dem Beitrag verstecken sich über 40 Seiten Material, die dazu gedacht sind, Menschen, die im Bankwesen oder in der Informationssicherheit tätig sind, zu unterstützen. Dieses Material ist das Endprodukt einer Untersuchung und in einem formellen Ton verfasst. Es handelt sich im Wesentlichen um Vorlagen für interne Dokumente zur Informationssicherheit.Und wie gewohnt — „Die Verwendung von Informationen aus diesem Artikel zu illegalen Zwecken wird gesetzlich verfolgt.“. Ich wünsche Ihnen eine produktive Lektüre!
Information für Leser, die sich mit der Untersuchung vertrautmachen, beginnend mit dieser Veröffentlichung.
Über die Studie
Sie lesen einen Leitfaden für die Person, die für die Sicherstellung der Informationssicherheit von Zahlungen in der Bank verantwortlich ist.
Logik der Darstellung
Zunächst wird in und eine Beschreibung des Schutzobjekts gegeben. Dann wird in Es wird erklärt, wie ein Schutzsystem aufgebaut wird, und die Notwendigkeit der Bedrohungsmodellierung wird angesprochen. In wird behandelt, welche Bedrohungsmodelle es gibt und wie sie erstellt werden. In und wird eine Analyse von realen Angriffen vorgenommen. und enthält eine Beschreibung des Bedrohungsmodells, das auf Informationen aus allen vorherigen Teilen basiert.
TYPISCHES BEDROHUNGSMODELL. NETZWERKVERBINDUNG
Schutzobjekt, für das das Bedrohungsmodell angewendet wird (scope)
Das Schutzobjekt sind die Daten, die über eine Netzwerkverbindung übertragen werden, die in Datennetzwerken betrieben werden, die auf dem TCP/IP-Stack basieren.
Architektur von
Beschreibung der Architekturelemente:
- «Endpunkte» – Knoten, die geschützte Informationen austauschen.
- «Zwischenknoten» – Elemente des Datennetzwerks: Router, Switches, Zugangserver, Proxy-Server und andere Geräte, über die der Datenverkehr der Netzwerkverbindung geleitet wird. Im Allgemeinen kann eine Netzwerkverbindung ohne Zwischenknoten funktionieren (direkt zwischen den Endpunkten).
Sicherheitsbedrohungen auf oberster Ebene
Dekomposition
U1. Unbefugter Zugriff auf übertragene Daten.
U2. Unautorisierte Modifikation der übermittelten Daten.
U3. Verletzung des Urheberrechts der übermittelten Daten.
U1. Unautorisierter Zugriff auf die übermittelten Daten.
Dekomposition
U1.1. , durchgeführt an End- oder Zwischenknoten:
U1.1.1. durch Auslesen der Daten während ihres Verbleibs in den Speichermedien des Knotens:
U1.1.1.1. im Arbeitsspeicher.
Erläuterungen zu U1.1.1.1.
Zum Beispiel während der Verarbeitung von Daten durch den Netzwerkstack des Knotens.
U1.1.1.2. im nichtflüchtigen Speicher.
Erläuterungen zu U1.1.1.2.
Zum Beispiel beim Speichern der übermittelten Daten im Cache, temporären Dateien oder Auslagerungsdateien.
U1.2. , durchgeführt an fremden Knoten im Datennetz:
U1.2.1. durch das Erfassen aller Pakete, die auf die Netzwerkschnittstelle des Knotens gelangen:
Erläuterungen zu U1.2.1.
Das Erfassen aller Pakete erfolgt durch das Umschalten des Netzwerkadapters in den Promiscuous-Modus (Promiskuitiver Modus für kabelgebundene Adapter oder Überwachungsmodus für Wi-Fi-Adapter).
U1.2.2. durch Durchführung von Man-in-the-Middle (MitM)-Angriffen, jedoch ohne Modifikation der übermittelten Daten (außer den Protokolldaten der Netzwerke).
U1.2.2.1. Link: .
U1.3. , die durch den Informationsleck über technische Kanäle (TKEI) von physischen Knoten oder Kommunikationsleitungen erfolgt.
U1.4. , die durch das Installieren spezieller technischer Mittel (STM) an End- oder Zwischenknoten für die heimliche Informationsbeschaffung erfolgt.
U2. Unbefugte Modifikation übertragener Daten
Dekomposition
U2.1. , die an End- oder Zwischenknoten durchgeführt wird:
U2.1.1. durch Auslesen und Ändern von Daten während ihrer Speicherung in den Speichergeräten der Knoten:
U2.1.1.1. im Arbeitsspeicher:
U2.1.1.2. im nicht flüchtigen Speicher:
U2.2. , die an fremden Knoten des Datenübertragungsnetzes durchgeführt wird:
U2.2.1. durch Durchführung von Man-in-the-Middle (MiTM)-Angriffen und Umleitung des Verkehrs zu einem Angreiferknoten:
U2.2.1.1. Physikalische Verbindung der Angreiferausrüstung in der Unterbrechung der Netzwerkverbindung.
U2.2.1.2. Durchführung von Angriffen auf Netzwerkprotokolle:
U2.2.1.2.1. Steuerung virtueller lokaler Netzwerke (VLAN):
U2.2.1.2.1.1. .
U2.2.1.2.1.2. Unbefugte Modifikation der VLAN-Einstellungen auf Switches oder Routern.
U2.2.1.2.2. Datenverkehrs-Routing:
U2.2.1.2.2.1. Unbefugte Modifikation der statischen Routing-Tabellen von Routern.
U2.2.1.2.2.2. Ankündigung gefälschter Routen durch Angreifer über dynamische Routing-Protokolle.
U2.2.1.2.3. automatischer Konfiguration:
U2.2.1.2.3.1. .
U2.2.1.2.3.2. .
U2.2.1.2.4. Adressierung und Namensauflösung:
U2.2.1.2.4.1. .
U2.2.1.2.4.2. .
U2.2.1.2.4.3. Unbefugte Änderungen an lokalen Hostnamen-Dateien (hosts, lmhosts usw.) vornehmen.
U3. Verletzung des Urheberrechts übertragener Daten.
Dekomposition
U3.1. Neutralisierung der Mechanismen zur Bestimmung der Urheberschaft von Informationen durch Angabe gefälschter Angaben zum Autor oder zur Quelle der Daten:
U3.1.1. Änderung der Angaben zum Autor, die in den übertragungsei Informationen enthalten sind.
U3.1.1.1. Neutralisierung der kryptografischen Schutzmaßnahmen für Integrität und Urheberschaft übertragener Daten:
U3.1.1.1.1. Verweis: .
U3.1.1.2. Neutralisierung des Urheberschutzes übertragener Daten, realisiert durch Einmalbestätigungs-Codes:
U3.1.1.2.1. .
U3.1.2. Änderung der Quelle übertragener Informationen:
U3.1.2.1. .
U3.1.2.2. .
TYPISCHES BEDROHUNGSMODELL. INFORMATIONSSYSTEM, DAS AUF DER CLIENT-SERVER-ARCHITEKTUR BASIERT
Schutzobjekt, für das das Bedrohungsmodell angewendet wird (scope)
Das Schutzobjekt ist ein Informationssystem, das auf der Client-Server-Architektur basiert.
Architektur von
Beschreibung der Architekturelemente:
- „Client“ – ein Gerät, auf dem der Client-Teil des Informationssystems funktioniert.
- „Server“ – ein Gerät, auf dem der Server-Teil des Informationssystems funktioniert.
- „Datenlager“ – ein Teil der Serverinfrastruktur des Informationssystems, der zur Speicherung von Daten dient, die vom Informationssystem verarbeitet werden.
- „Netzwerkverbindung“ – ein Kanal für den Informationsaustausch zwischen Client und Server, der durch ein Datennetzwerk verläuft. Eine detailliertere Beschreibung des Modells des Elements finden Sie in .
Einschränkungen
Bei der Modellierung des Objekts wurden folgende Einschränkungen festgelegt:
- Der Benutzer interagiert mit dem Informationssystem innerhalb zeitlich begrenzter Arbeitsintervalle, die als Sitzungen bezeichnet werden.
- Zu Beginn jeder Sitzung erfolgt die Identifizierung, Authentifizierung und Autorisierung des Benutzers.
- Alle geschützten Informationen werden auf der Serverseite des Informationssystems gespeichert.
Sicherheitsbedrohungen auf oberster Ebene
Dekomposition
U1. Durchführung unbefugter Handlungen durch Angreifer im Namen eines legitimen Benutzers.
U2. Unbefugte Modifikation geschützter Informationen während deren Verarbeitung durch die Serverseite des Informationssystems.
U1. Durchführung unbefugter Handlungen durch Angreifer im Namen eines legitimen Benutzers.
Erklärungen
In Informationssystemen wird üblicherweise die Zuordnung von Handlungen zu dem Benutzer, der sie ausgeführt hat, durch Folgendes durchgeführt:
- Systemprotokolle (Logs).
- Spezielle Attribute von Datenelementen, die Informationen über den Benutzer enthalten, der sie erstellt oder geändert hat.
In Bezug auf die Sitzung kann diese Bedrohung in folgende Teile zerlegt werden:
- ausgeführt im Rahmen der Benutzersitzung.
- außerhalb der Benutzersitzung durchgeführte Aktionen.
Die Benutzersitzung kann initiiert werden durch:
- Den Benutzer selbst.
- Durch Angreifer.
In diesem Stadium wird die Zwischendekompensation dieser Bedrohung folgendermaßen aussehen:
U1.1. Unbefugte Aktionen wurden im Rahmen der Benutzersitzung durchgeführt:
U1.1.1. , installiert vom angegriffenen Benutzer.
U1.1.2. , installiert von den Angreifern.
U1.2. Unbefugte Aktionen wurden außerhalb der Benutzersitzung durchgeführt.
Aus der Sicht der Objekte der Informationsinfrastruktur, die von Angreifern betroffen sein können, sieht die Dekompensation der Zwischenbedrohungen wie folgt aus:
Die Elemente
Dekompensation von Bedrohungen
U1.1.1.
U1.1.2.
U1.2.
Kunde
U1.1.1.1.
U1.1.2.1.
Netzwerkverbindung
U1.1.1.2.
Server
U1.2.1.
Dekomposition
U1.1. Unbefugte Aktionen wurden im Rahmen der Benutzersitzung durchgeführt:
U1.1.1. , installiert vom angegriffenen Benutzer:
U1.1.1.1. Angreifer handelten eigenständig mit dem Client:
U1.1.1.1.1 Angreifer nutzten reguläre Zugriffsmittel des Informationssystems:
U1.1.1.1.1.1. Angreifer haben die physischen Eingabemittel des Kunden (Tastatur, Maus, Monitor oder Touchscreen eines mobilen Geräts) verwendet:
U1.1.1.1.1.1.1. Angreifer agierten zu Zeiten, in denen die Sitzung aktiv war, die Eingabemittel verfügbar waren und der Benutzer nicht anwesend war.
U1.1.1.1.1.2. Angreifer nutzten Fernadministrationstools (entweder legale oder durch schädlichen Code bereitgestellte), um den Kunden zu steuern:
U1.1.1.1.1.2.1. Angreifer agierten zu Zeiten, in denen die Sitzung aktiv war, die Eingabemittel verfügbar waren und der Benutzer nicht anwesend war.
U1.1.1.1.1.2.2. Angreifer verwendeten Fernadministrationstools, deren Betrieb für den angegriffenen Benutzer nicht erkennbar war.
U1.1.1.2. Angreifer änderten die Daten in der Netzwerkverbindung zwischen dem Kunden und dem Server, so dass sie als Aktionen eines legitimen Benutzers wahrgenommen wurden:
U1.1.1.2.1. Link: .
U1.1.1.3. Angreifer zwangen den Benutzer, die von ihnen angegebenen Aktionen auszuführen, indem sie Methoden der sozialen Manipulation anwendeten.
U1.1.2 von den Angreifern eingerichtet:
U1.1.2.1. Angreifer handelten vom Client aus (Und):
U1.1.2.1.1. Angreifer neutralisierten das Zugangskontrollsystem der Informationssysteme:
U1.1.2.1.1.1. Link: .
U1.1.2.1.2. Angreifer verwendeten reguläre Zugriffsmittel des Informationssystems.
U1.1.2.2. Angreifer handelten von anderen Knoten des Datennetzwerks, von denen eine Netzwerkverbindung zum Server hergestellt werden kann (Und):
U1.1.2.2.1. Angreifer neutralisierten das Zugangskontrollsystem der Informationssysteme:
U1.1.2.2.1.1. Link: .
U1.1.2.2.2. Angreifer verwendeten nicht autorisierte Zugriffsmittel des Informationssystems.
Erläuterungen U1.1.2.2.2.
Angreifer konnten den regulären Client des Informationssystems auf einem fremden Knoten installieren oder unautorisierte Software verwenden, die reguläre Austauschprotokolle zwischen Client und Server realisiert.
U1.2 Unbefugte Handlungen wurden außerhalb der Benutzersitzung ausgeführt.
U1.2.1 Angreifer führten unautorisierte Handlungen durch und änderten dann unrechtmäßig die Protokolle des Informationssystems oder spezielle Attribute von Datenobjekten, um anzuzeigen, dass ihre Handlungen von einem legitimen Benutzer ausgeführt wurden.
U2. Unautorisierte Modifikation geschützter Informationen während ihrer Verarbeitung durch die Server-Komponente des Informationssystems.
Dekomposition
U2.1. Angreifer modifizieren geschützte Informationen mithilfe der standardmäßigen Werkzeuge des Informationssystems und agieren dabei im Namen eines legitimen Benutzers.
U2.1.1. Link: .
U2.2. Angreifer modifizieren geschützte Informationen durch die Nutzung nicht im regulären Betrieb des Informationssystems vorgesehenen Zugriffsmöglichkeiten.
U2.2.1. Angreifer modifizieren Dateien, die geschützte Informationen enthalten:
U2.2.1.1. , indem die von dem Betriebssystem bereitgestellten Dateimechanismen verwendet werden.
U2.2.1.2. durch die Provokation der Wiederherstellung von Dateien aus einer unbefugten, modifizierten Sicherungskopie.
U2.2.2. Angreifer modifizieren geschützte Informationen, die in der Datenbank gespeichert sind (Und):
U2.2.2.1. Angreifer neutralisieren das Zugriffssteuerungssystem der DBMS:
U2.2.2.1.1. Link: .
U2.2.2.2. Angreifer modifizieren Informationen, indem sie die Standard-Schnittstellen des DBMS nutzen, um auf Daten zuzugreifen.
U2.3. Angreifer modifizieren geschützte Informationen durch unbefugte Änderungen an den Algorithmen der verarbeitenden Software.
U2.3.1. Der Quellcode der Software wird modifiziert.
U2.3.1. Der Maschinencode der Software wird modifiziert.
U2.4. Angreifer modifizieren geschützte Informationen durch die Ausnutzung von Schwachstellen in der Software des Informationssystems.
U2.5. Angreifer modifizieren geschützte Informationen beim Transfer zwischen Komponenten der Server-Seite des Informationssystems (zum Beispiel zwischen Datenbankserver und Anwendungsserver):
U2.5.1. Link: .
TYPISCHES BEDROHUNGSMODELL. ZUGANGSKONTROLLSYSTEM
Schutzobjekt, für das das Bedrohungsmodell angewendet wird (scope)
Das Schutzobjekt, für das dieses Bedrohungsmodell Anwendung findet, entspricht dem Schutzobjekt des Bedrohungsmodells: „Typisches Bedrohungsmodell. Informationssystem, das auf einer Client-Server-Architektur basiert.“
Unter dem Zugangskontrollsystem in diesem Bedrohungsmodell versteht man eine Komponente des Informationssystems, die folgende Funktionen bereitstellt:
- Benutzeridentifikation.
- Benutzerauthentifizierung.
- Benutzerautorisierung.
- Protokollierung der Benutzeraktionen.
Sicherheitsbedrohungen auf oberster Ebene
Dekomposition
U1. Unbefugte Sitzungseröffnung im Namen eines legitimen Benutzers.
U2. Unbefugte Erhöhung der Benutzerrechte im Informationssystem.
U1. Unbefugte Sitzungseröffnung im Namen eines legitimen Benutzers.
Erklärungen
Die Dekompensation dieser Bedrohung wird im Allgemeinen von der Art der verwendeten Identifikations- und Authentifizierungssysteme abhängen.
In diesem Modell wird ausschließlich das System zur Identifizierung und Authentifizierung von Nutzern behandelt, das einen Textbenutzernamen und ein Passwort verwendet. Dabei gehen wir davon aus, dass der Benutzername eine öffentliche Information ist, die potenziellen Angreifern bekannt ist.
Dekomposition
U1.1. aufgrund der Kompromittierung von Anmeldedaten:
U1.1.1. Angreifer haben die Anmeldedaten des Nutzers während ihrer Speicherung kompromittiert.
Erklärungen U1.1.1.
Zum Beispiel könnten die Anmeldedaten auf einem Aufkleber notiert sein, der am Monitor befestigt ist.
U1.1.2. Der Nutzer hat versehentlich oder absichtlich seine Zugangsdaten an Angreifer weitergegeben.
U1.1.2.1. Der Nutzer hat die Anmeldedaten beim Eingeben laut ausgesprochen.
U1.1.2.2. Der Nutzer hat absichtlich seine Anmeldedaten weitergegeben:
U1.1.2.2.1. an Arbeitskollegen.
Erklärungen U1.1.2.2.1.
Zum Beispiel, damit diese ihn während seiner Krankheitszeit ersetzen können.
U1.1.2.2.2. an Geschäftspartner des Arbeitgebers, die an Objekten der Informationsinfrastruktur arbeiten.
U1.1.2.2.3. an Dritte.
Erklärungen U1.1.2.2.3.
Eine Möglichkeit, diese Bedrohung umzusetzen, besteht darin, dass Angreifer Methoden der sozialen Manipulation verwenden.
U1.1.3. Angreifer haben Zugangsdaten durch Brute-Force-Verfahren erlangt:
U1.1.3.1. unter Verwendung der vorhandenen Zugangsmechanismen.
U1.1.3.2. anhand zuvor abgefangener Codes (z. B. Passwort-Hashes) zur Speicherung von Zugangsdaten.
U1.1.4. Angreifer haben bösartigen Code verwendet, um die Zugangsdaten des Benutzers abzufangen.
U1.1.5. Angreifer haben Zugangsdaten aus der Netzwerkverbindung zwischen dem Client und dem Server extrahiert:
U1.1.5.1. Link: .
U1.1.6. Angreifer haben Zugangsdaten aus den Aufzeichnungen von Monitoring-Systemen extrahiert:
U1.1.6.1. von Videoüberwachungssystemen (falls während des Betriebs Tasteneingaben erfasst wurden).
U1.1.6.2. von Systemen zur Überwachung der Computeraktivitäten von Mitarbeitern.
Erklärung zu U1.1.6.2.
Ein Beispiel für ein solches System ist - .
U1.1.7. Angreifer haben die Zugangsdaten des Benutzers aufgrund von Mängeln im Prozess ihrer Übertragung kompromittiert.
Erklärungen U1.1.7.
Zum Beispiel die Übertragung von Passwörtern im Klartext per E-Mail.
U1.1.8. Angreifer haben Zugangsdaten durch die Überwachung einer Benutzersitzung mittels Fernwartungssystemen erlangt.
U1.1.9. Angreifer haben Zugangsdaten durch deren technische Leckage (TKUIs) extrahiert:
U1.1.9.1. Angreifer haben beobachtet, wie ein Benutzer die Zugangsdaten von der Tastatur eingegeben hat:
U1.1.9.1.1 Angreifer befanden sich in unmittelbarer Nähe des Benutzers und konnten die Eingabe der Zugangsdaten mit ihren eigenen Augen sehen.
Erklärungen U1.1.9.1.1
Zu solchen Fällen zählen die Handlungen von Arbeitskollegen oder Situationen, in denen die Tastatur des Benutzers für Besucher der Organisation sichtbar ist.
U1.1.9.1.2 Angreifer verwendeten zusätzliche technische Mittel wie ein Fernglas oder eine Drohne und beobachteten die Eingabe der Zugangsdaten durch ein Fenster.
U1.1.9.2. Angreifer haben Zugangsdaten aus dem Funkverkehr zwischen der Tastatur und dem Computergehäuse extrahiert, falls sie über eine Funkverbindung (z. B. Bluetooth) verbunden waren.
U1.1.9.3. Angreifer haben Anmeldeinformationen durch deren Abgreifen über elektromagnetische Strahlung und Störungen (PEM) erlangt.
Erläuterungen zu U1.1.9.3.
Beispiele für Angriffe und .
U1.1.9.4. Der Angreifer hat Eingaben von Anmeldeinformationen über spezielle technische Mittel (STM), die zum heimlichen Abzug von Informationen bestimmt sind, abgegriffen.
Erläuterungen zu U1.1.9.4.
Beispiele .
U1.1.9.5. Angreifer haben Eingaben von Anmeldeinformationen über
die Analyse von Wi-Fi-Signalen, die durch das Drücken von Tasten durch den Benutzer moduliert werden.
Erläuterungen zu U1.1.9.5.
Beispiel .
U1.1.9.6. Angreifer haben Eingaben von Anmeldeinformationen über die Analyse der Geräusche, die beim Drücken der Tasten entstehen, abgegriffen.
Erläuterungen zu U1.1.9.6.
Beispiel .
U1.1.9.7. Angreifer haben Eingaben von Anmeldeinformationen auf mobilen Geräten durch die Analyse der Beschleunigungsdaten abgegriffen.
Erläuterungen zu U1.1.9.7.
Beispiel .
U1.1.10. , die zuvor auf dem Client gespeichert wurden.
Erläuterungen zu U1.1.10.
Ein Beispiel könnte sein, dass der Benutzer Anmeldename und Passwort für den Zugriff auf eine bestimmte Webseite im Browser gespeichert hat.
U1.1.11. Angreifer haben Zugangsdaten aufgrund von Mängeln im Rücknahmeprozess der Benutzerzugriffe kompromittiert.
Erläuterungen zu U1.1.11.
Beispielsweise blieben nach der Kündigung eines Benutzers dessen Konten ungesperrt.
U1.2. durch die Ausnutzung von Schwachstellen im Zugriffskontrollsystem.
U2. Unbefugte Erhöhung der Benutzerprivilegien im Informationssystem
Dekomposition
U2.1 durch unbefugte Änderungen an den Daten, die Informationen über die Benutzerprivilegien enthalten.
U2.2 durch die Ausnutzung von Schwachstellen im Zugriffskontrollsystem.
U2.3. aufgrund von Mängeln im Zugriffsmanagementprozess der Benutzer.
Erläuterungen zu U2.3.
Beispiel 1. Einem Benutzer wurde ein größerer Zugang gewährt, als er für dienstliche Zwecke benötigte.
Beispiel 2. Nach der Versetzung eines Benutzers auf eine andere Position wurden die zuvor gewährten Zugriffsrechte nicht entzogen.
TYPISCHES BEDROHUNGSMODELL. INTEGRATIONS-MODUL
Schutzobjekt, für das das Bedrohungsmodell angewendet wird (scope)
Integrationsmodul – eine Sammlung von Objekten der Informationsinfrastruktur, die für den Austausch von Informationen zwischen Informationssystemen konzipiert ist.
Da es in Unternehmensnetzwerken nicht immer möglich ist, ein Informationssystem eindeutig von einem anderen zu trennen, kann das Integrationsmodul auch als Bindeglied zwischen den Komponenten innerhalb eines Informationssystems betrachtet werden.
Architektur von
Das allgemeine Schema des Integrationsmoduls sieht folgendermaßen aus:
Beschreibung der Architekturelemente:
- „Austauschserver (AS)“ – Knoten / Dienst / Komponente des Informationssystems, die die Funktion des Datenaustauschs mit einem anderen Informationssystem ausführt.
- „Vermittler“ – Knoten / Dienst, der dafür vorgesehen ist, die Interaktion zwischen Informationssystemen zu organisieren, jedoch nicht Teil von ihnen ist.
Beispiele für „Vermittler“ sind E-Mail-Dienste, Unternehmensservice-Busse (Enterprise Service Bus / SoA-Architektur), externe Dateiserver usw. Im Allgemeinen kann das Integrationsmodul auch keine „Vermittler“ enthalten. - „Datenverarbeitungssoftware“ – eine Sammlung von Programmen, die Protokolle für den Datenaustausch und die Formatumwandlung implementiert.
Beispielsweise die Umwandlung von Daten aus dem UFEBS-Format in das ABS-Format, das Ändern von Nachrichtenstatus während der Übertragung usw. - „Netzwerkverbindung“ entspricht dem Objekt, das im Bedrohungsmodell „Netzwerkverbindung“ beschrieben ist. Einige der in der obigen Abbildung dargestellten Netzwerkverbindungen können fehlen.
Beispiele für Integrationsmodule
Abbildung 1. Integration von ABS und ARM KBR über einen externen Dateiserver
Zur Durchführung von Zahlungen exportiert der autorisierte Bankmitarbeiter elektronische Zahlungsdokumente aus dem ABS und speichert sie in einer Datei (eigenes Format, z. B. SQL-Dump) im Netzwerkordner (…SHARE) des Dateiservers. Anschließend wird diese Datei mithilfe eines Konverter-Skripts in eine Gruppe von UFEBS-Formatdateien umgewandelt, die dann von ARM KBR eingelesen werden.
Daraufhin verschlüsselt und signiert der autorisierte Mitarbeiter — ein Benutzer von ARM KBR — die erhaltene Datei und sendet sie an das Zahlungssystem der Bank von Russland.
Bei Zahlungseingängen von der Bank Russland entschlüsselt das ARM KBR die Zahlungen und überprüft die elektronische Signatur, bevor diese als eine Sammlung von Dateien im UFEBS-Format auf dem Dateiserver gespeichert werden. Vor dem Import der Zahlungsdokumente in das ABS werden sie mit einem Konverter-Skript vom UFEBS-Format in das ABS-Format umgewandelt.
Nehmen wir an, dass in diesem Schema das ABS auf einem physischen Server funktioniert, das ARM KBR auf einem dedizierten Computer läuft und das Konverter-Skript auf dem Dateiserver arbeitet.
Entsprechung der Objekte des behandelten Schemas mit den Elementen des Integrationsmoduls:
„Austauschserver seitens des ABS“ – ABS-Server.
„Austauschserver seitens des ARM KBR“ – Computer ARM KBR.
„Vermittler“ – externer Dateiserver.
„Datenverarbeitungssoftware“ – Konverter-Skript.
Schema 2. Integration von ABS und ARM KBR durch Bereitstellung eines gemeinsamen Netzwerkordners für Zahlungen auf ARM KBR
Alles wie im Schema 1, aber ein separater Dateiserver wird nicht verwendet; stattdessen befindet sich der Netzwerkordner (…SHARE) mit den elektronischen Zahlungsdokumenten auf dem Computer mit ARM KBR. Das Konverter-Skript läuft ebenfalls auf ARM KBR.
Entsprechung der Objekte des behandelten Schemas mit den Elementen des Integrationsmoduls:
Ähnlich wie im Schema 1, jedoch „Vermittler“ wird nicht verwendet.
Schema 3. Integration von ABS und ARM KBR-N über IBM WebSphere MQ und die Unterzeichnung elektronischer Dokumente „seitens ABS“
ABS läuft auf einer Plattform, die von der SKZI SKAD Signature nicht unterstützt wird. Die elektronische Unterzeichnung ausgehender Dokumente erfolgt auf einem speziellen Server für elektronische Unterschriften (EP-Server). Dieser Server überprüft auch die elektronische Signatur eingehender Dokumente von der Bank von Russland.
ABS lädt eine Datei mit Zahlungsdokumenten im eigenen Format auf den EP-Server hoch.
Der EP-Server wandelt mit einem Konverter-Skript die Datei in elektronische Nachrichten im Format UFEBS um, danach werden die elektronischen Nachrichten signiert und an IBM WebSphere MQ übermittelt.
ARM KBR-N greift auf IBM WebSphere MQ zu und erhält die signierten Zahlungsnachrichten, anschließend verschlüsselt der autorisierte Mitarbeiter — der Benutzer von ARM KBR — diese und sendet sie an das Zahlungsystem der Bank von Russland.
Bei Zahlungseingängen von der Bank Russland entschlüsselt das ARM KBR-Н diese und prüft die elektronische Signatur. Erfolgreich verarbeitete Zahlungen werden in Form von entschlüsselten und signierten elektronischen Nachrichten im UFEBS-Format an IBM WebSphere MQ übergeben, von wo sie vom EP-Server empfangen werden.
Der EP-Server überprüft die elektronische Signatur der eingegangenen Zahlungen und speichert sie in einer Datei im ABS-Format. Anschließend lädt ein autorisierter Mitarbeiter – ein Benutzer des ABS – die resultierende Datei ordnungsgemäß in das ABS hoch.
Entsprechung der Objekte des behandelten Schemas mit den Elementen des Integrationsmoduls:
„Austauschserver seitens des ABS“ – ABS-Server.
„Austauschserver seitens ARM KBR“ – Computer ARM KBR.
„Vermittler“ – EP-Server und IBM WebSphere MQ.
„Datenverarbeitungssoftware“ – Konvertierungsskript, SKZI SKAD Signatur auf dem EP-Server.
Schema 4. Integration des DBO-Servers und des ABS über die API, die vom dedizierten Austauschserver bereitgestellt wird.
Angenommen, in der Bank werden mehrere Systeme für das Online-Banking (DBO) verwendet:
- „Internet Client-Bank“ für Privatkunden (IKB FL);
- „Internet Client-Bank“ für juristische Personen (IKB UL).
Um die Informationssicherheit zu gewährleisten, erfolgt die gesamte Interaktion der ABS mit den DBO-Systemen über einen dedizierten Austauschserver, der im Rahmen des Informationssystems „ABS“ arbeitet.
Im Folgenden betrachten wir den Prozess der Interaktion des DBO-Systems der ICB für juristische Personen mit der ABS.
Der DBO-Server muss auf Grundlage des ordnungsgemäß vom Kunden beglaubigten Zahlungsauftrags das entsprechende Dokument in der ABS erstellen. Dazu überträgt er mithilfe der API die Informationen an den Austauschserver, der im Gegenzug die Daten in die ABS einpflegt.
Bei Änderungen des Guthabens auf dem Kundenkonto erstellt die ABS elektronische Benachrichtigungen, die über den Austauschserver an den DBO-Server gesendet werden.
Entsprechung der Objekte des behandelten Schemas mit den Elementen des Integrationsmoduls:
„Austauschserver vonseiten des DBO“ – DBO-Server der ICB für juristische Personen.
„Austauschserver seitens des ABS“ – Austauschserver.
„Vermittler“ – nicht vorhanden.
„Datenverarbeitungssoftware“ – Komponenten des DBO-Servers, die für die Nutzung der API des Austauschservers verantwortlich sind, sowie Komponenten des Austauschservers, die für die Nutzung der API der ABS verantwortlich sind.
Sicherheitsbedrohungen auf oberster Ebene
Dekomposition
U1. Einführung von gefälschten Informationen durch Angreifer über das Integrationsmodul.
U1. Einführung von gefälschten Informationen durch Angreifer über das Integrationsmodul.
Dekomposition
U1.1. Unbefugte Modifikation legitimerter Daten während ihrer Übertragung über Netzwerkverbindungen:
U1.1.1 Link: .
U1.2. Übertragung von gefälschten Daten im Namen eines legitimen Teilnehmers am Austausch:
U1.1.2 Link: .
U1.3. Unbefugte Modifikation legitimer Daten während ihrer Verarbeitung auf Austauschservern oder durch einen Vermittler:
U1.3.1. Link: .
U1.4. Erstellung von gefälschten Daten auf Austauschservern oder durch einen Vermittler im Namen eines legitimen Teilnehmers am Austausch:
U1.4.1. Link:
U1.5. Unbefugte Modifikation von Daten während ihrer Verarbeitung mit Datenverarbeitungssoftware:
U1.5.1. durch unautorisierte Änderungen an den Einstellungen (Konfiguration) der Datenverarbeitungssoftware durch Angreifer.
U1.5.2. durch unautorisierte Änderungen an den ausführbaren Dateien der Datenverarbeitungssoftware durch Angreifer.
U1.5.3. durch interaktive Steuerung der Datenverarbeitungssoftware durch Angreifer.
TYPISCHE BEDROHUNGSMODELLE. SYSTEM ZUR KRYPTOGRAPHISCHEN SICHERHEIT VON INFORMATIONEN
Schutzobjekt, für das das Bedrohungsmodell angewendet wird (scope)
Objekt des Schutzes ist das System zur kryptographischen Sicherheit von Informationen, das zur Gewährleistung der Sicherheit des Informationssystems verwendet wird.
Architektur von
Die Grundlage jedes Informationssystems ist die Anwendungssoftware, die die spezifische Funktionalität umsetzt.
Die kryptographische Sicherheit wird normalerweise durch Aufrufe aus der Geschäftslogik der Anwendungssoftware an kryptographische Primitiven realisiert, die in speziellen Bibliotheken – Krypto-Kernen – abgelegt sind.
Zu den kryptographischen Primitiven gehören niedrigstufige kryptographische Funktionen wie:
- Datenblöcke verschlüsseln / entschlüsseln;
- Elektронische Signaturen von Datenblöcken erstellen / überprüfen;
- Berechnen Sie die Hash-Funktion eines Datenblocks;
- Schlüsselinformationen erstellen / hochladen / herunterladen;
- usw.
Die Geschäftslogik der Anwendungssoftware implementiert mit Hilfe kryptografischer Primitiven höhere Funktionalitäten:
- eine Datei mit den Schlüsseln der ausgewählten Empfänger verschlüsseln;
- eine sichere Netzwerkverbindung einrichten;
- über die Ergebnisse der Überprüfung der elektronischen Signatur informieren;
- usw.
Die Interaktion zwischen Geschäftslogik und Krypto-Kern kann erfolgen:
- direkt, indem die Geschäftslogik kryptografische Primitiven aus dynamischen Bibliotheken des Krypto-Kerns aufruft (.DLL – für Windows, .SO – für Linux);
- indirekt, über kryptografische Schnittstellen – Wrapper, wie z.B. MS Crypto API, Java Cryptography Architecture, PKCS#11 usw. In diesem Fall greift die Geschäftslogik auf die Krypto-Schnittstelle zu, die den Aufruf an den entsprechenden Krypto-Kern übersetzt, der in diesem Fall als Krypto-Provider bezeichnet wird. Die Verwendung kryptografischer Schnittstellen ermöglicht es der Anwendungssoftware, sich von spezifischen kryptografischen Algorithmen zu abstrahieren und flexibler zu sein.
Es können zwei standardmäßige Organisationsschemata des Krypto-Kerns hervorgehoben werden:
Schema 1 – Monolithisches Krypto-Kern
Schema 2 – Geteilter Krypto-Kern
Die Elemente in den dargestellten Schemata können sowohl separate Softwaremodule sein, die auf einem Computer laufen, als auch Netzservices, die im Rahmen eines Rechenzentrums interagieren.
Bei der Verwendung von Systemen, die auf Schema 1 basieren, arbeiten Anwendungssoftware und Krypto-Kern innerhalb einer einheitlichen Betriebsumgebung des Kryptomittels (KFE), beispielsweise auf demselben Computer und unter demselben Betriebssystem. Der Benutzer des Systems kann in der Regel auch andere Programme innerhalb dieser Betriebsumgebung ausführen, einschließlich solcher, die schadhafte Codes enthalten. Unter diesen Bedingungen besteht ein ernsthaftes Risiko für das Leck von vertraulichen kryptografischen Schlüsseln.
Um das Risiko zu minimieren, wird Schema 2 verwendet, bei dem der Krypto-Kern in zwei Teile aufgeteilt wird:
- Der erste Teil zusammen mit der Anwendungssoftware arbeitet in einer unzuverlässigen Umgebung, in der das Risiko einer Infektion mit schädlichem Code besteht. Wir nennen diesen Teil die "Software-Komponente".
- Der zweite Teil arbeitet in einer vertrauenswürdigen Umgebung auf einem dedizierten Gerät, das über ein Speichersystem für geheime Schlüssel verfügt. Wir werden diesen Teil als „Hardware-Komponente“ bezeichnen.
Die Trennung des Krypto-Kerns in Software- und Hardware-Komponenten ist recht willkürlich. Auf dem Markt gibt es Systeme, die nach dem Prinzip eines getrennten Krypto-Kerns aufgebaut sind, wobei die „Hardware“-Komponente jedoch als Abbild einer virtuellen Maschine dargestellt wird – virtual HSM ().
Die Interaktion beider Teile des Krypto-Kerns erfolgt so, dass geheime kryptografische Schlüssel niemals an den Software-Teil übermittelt werden und somit nicht durch schädlichen Code abgegriffen werden können.
Die Schnittstelle für die Interaktion (API) und die Reihe von kryptografischen Primitiven, die vom Krypto-Kern an die Anwendungssoftware bereitgestellt werden, sind in beiden Fällen identisch. Der Unterschied liegt in der Art und Weise ihrer Implementierung.
Bei der Verwendung des Schemas mit getrenntem Krypto-Kern erfolgt die Interaktion zwischen Software- und Hardware-Komponente nach folgendem Prinzip:
- Kryptografische Primitive, die keinen privaten Schlüssel benötigen (z. B. die Berechnung von Hash-Funktionen, die Überprüfung elektronischer Signaturen usw.), werden von der Software durchgeführt.
- Kryptografische Primitive, die einen privaten Schlüssel verwenden (z. B. die Erstellung elektronischer Signaturen, das Entschlüsseln von Daten usw.), werden von der Hardware durchgeführt.
Lassen Sie uns die Funktionsweise eines geteilten Krypto-Kerns am Beispiel der Erstellung einer elektronischen Signatur veranschaulichen:
- Die Software berechnet die Hash-Funktion der zu signierenden Daten und überträgt diesen Wert über die Interprozesskommunikation an die Hardware.
- Die Hardware verwendet den privaten Schlüssel und den Hash, um den Wert der elektronischen Signatur zu bilden, und überträgt ihn über die Interprozesskommunikation an die Software.
- Die Software gibt den erhaltenen Wert an die Anwendungssoftware zurück.
Besonderheiten der Überprüfung der Gültigkeit elektronischer Signaturen
Wenn die empfangende Partei Daten erhält, die mit einer elektronischen Signatur signiert sind, muss sie mehrere Überprüfungsschritte durchführen. Ein positives Ergebnis der Überprüfung der elektronischen Signatur wird nur erreicht, wenn alle Überprüfungsschritte erfolgreich abgeschlossen werden.
Schritt 1. Überprüfung der Datenintegrität und der Datenautorschaft.
Inhalt des Schrittes. Es wird die elektronische Signatur der Daten gemäß dem entsprechenden kryptografischen Algorithmus überprüft. Das erfolgreiche Bestehen dieses Schrittes zeigt, dass die Daten seit ihrer Signierung nicht verändert wurden und dass die Signatur mit dem privaten Schlüssel erstellt wurde, der dem öffentlichen Schlüssel zur Überprüfung der elektronischen Signatur entspricht.
Durchführungsort des Schrittes: Krypto-Kern.
Schritt 2. Überprüfung des Vertrauens in den öffentlichen Schlüssel des Unterzeichners und Überprüfung der Gültigkeitsdauer des privaten Schlüssels für die elektronische Signatur.
Inhalt des Schrittes. Der Schritt besteht aus zwei Zwischenphasen. In der ersten Phase wird festgestellt, ob der öffentliche Schlüssel zur Überprüfung der elektronischen Signatur zum Zeitpunkt der Datenunterzeichnung vertrauenswürdig war. In der zweiten Phase wird überprüft, ob der private Schlüssel zur elektronischen Signatur zum Zeitpunkt der Datenunterzeichnung gültig war. Im Allgemeinen können die Gültigkeitszeiträume dieser Schlüssel unterschiedlich sein (z.B. bei qualifizierten Zertifikaten zur Überprüfung elektronischer Signaturen). Die Methoden zur Feststellung des Vertrauens in den öffentlichen Schlüssel des Unterzeichners werden durch die Regeln des elektronischen Dokumentenverkehrs, die von den beteiligten Parteien festgelegt sind, bestimmt.
Durchführungsort des Schrittes: Anwendungssoftware / Kryptokern.
Schritt 3. Kontrolle der Berechtigungen des Unterzeichners.
Inhalt des Schrittes. Gemäß den festgelegten Regeln für den elektronischen Dokumentenaustausch wird überprüft, ob der Unterzeichner das Recht hatte, die geschützten Daten zu bestätigen. Nehmen wir als Beispiel einen Fall von Überschreitung der Befugnisse. Angenommen, es gibt eine Organisation, in der alle Mitarbeiter eine elektronische Signatur haben. Ein Befehl des Leiters wird in das interne System des elektronischen Dokumentenaustauschs eingegeben, jedoch von der elektronischen Signatur des Lagerleiters unterschrieben. Folglich kann ein solches Dokument nicht als legitim gelten.
Durchführungsort des Schrittes: Anwendungssoftware.
Annahmen, die bei der Beschreibung des Objekts des Schutzes getroffen wurden.
- Die Übertragungswege für Informationen, mit Ausnahme der Kanäle für den Schlüsselaustausch, verlaufen ebenfalls über Anwendungssoftware, API und das kryptografische Kernsystem.
- Informationen über das Vertrauen in öffentliche Schlüssel und/oder Zertifikate sowie Informationen über die Rechte der Inhaber öffentlicher Schlüssel werden im öffentlichen Schlüsselspeicher abgelegt.
- Die Anwendungssoftware arbeitet über das kryptografische Kernsystem mit dem öffentlichen Schlüsselspeicher.
Beispiel eines Informationssystems, das durch ein kryptografisches Schutzsystem gesichert ist.
Um die zuvor vorgestellten Schemen zu veranschaulichen, betrachten wir ein hypothetisches Informationssystem und heben alle strukturellen Elemente hervor.
Beschreibung des Informationssystems
Zwei Organisationen haben beschlossen, einen rechtlich verbindlichen elektronischen Dokumentenaustausch (EDE) zwischen ihnen einzuführen. Zu diesem Zweck haben sie eine Vereinbarung getroffen, in der festgelegt ist, dass die Dokumente per E-Mail übermittelt werden und dabei verschlüsselt und mit einer qualifizierten elektronischen Signatur versehen sein müssen. Als Software zur Erstellung und Verarbeitung der Dokumente kommen Büroprogramme aus dem Microsoft Office 2016-Paket zum Einsatz, während für die kryptografische Sicherheit die KryptoPro SKZI und die KryptoARM Verschlüsselungssoftware verwendet werden sollen.
Beschreibung der Infrastruktur der Organisation 1
Die Organisation 1 hat beschlossen, die SKZI KryptoPRO und die Software KryptoARM auf dem Benutzerarbeitsplatz — dem physischen Computer — zu installieren. Die Verschlüsselungs- und elektronischen Signaturschlüssel werden auf dem Schlüsselmedium ruToken gespeichert, das im abziehbaren Schlüsselmodus arbeitet. Der Benutzer wird elektronische Dokumente lokal auf seinem Computer vorbereiten und diese dann verschlüsseln, signieren und über den lokal installierten E-Mail-Client versenden.
Beschreibung der Infrastruktur der Organisation 2
Die Organisation 2 hat sich entschieden, die Funktionen der Verschlüsselung und der elektronischen Signatur auf eine dedizierte virtuelle Maschine auszulagern. Dabei werden alle kryptografischen Operationen automatisiert durchgeführt.
Auf der dedizierten virtuellen Maschine sind zwei Netzwerkordner eingerichtet: „…In“, „…Out“. In den Netzwerkordner „…In“ werden automatisch die vom Geschäftspartner empfangenen Dateien im offenen Format abgelegt. Diese Dateien werden entschlüsselt und die elektronische Signatur wird überprüft.
In den Ordner „…Out“ wird der Nutzer Dateien ablegen, die verschlüsselt, signiert und an den Vertragspartner gesendet werden müssen. Die Dateien selbst bereitet der Nutzer auf seinem Arbeitsplatzrechner vor.
Für die Ausführung der Funktionen zur Verschlüsselung und elektronischen Signatur sind auf der virtuellen Maschine die kryptographischen Softwareprodukte KryptoPRO, KryptoARM sowie ein E-Mail-Client installiert. Die automatische Verwaltung aller Elemente der virtuellen Maschine erfolgt durch Skripte, die von den Systemadministratoren entwickelt werden. Die Ausführung dieser Skripte wird in Protokolldateien (Logs) protokolliert.
Die kryptographischen Schlüssel für die elektronische Signatur werden auf einem Token mit nicht extrahierbarem Schlüssel JaCarta ГОСТ abgelegt, den der Nutzer mit seinem lokalen Computer verbindet.
Der Token wird durch spezielle Softwarelösungen USB-over-IP, die auf dem Arbeitsplatzrechner und auf der virtuellen Maschine installiert sind, an die virtuelle Maschine weitergeleitet.
Die Systemuhr am Arbeitsplatz des Nutzers in Organisation 1 wird manuell angepasst. Die Systemuhr der spezialisierten virtuellen Maschine in Organisation 2 wird mit der Systemuhr des Hypervisors synchronisiert, der wiederum über das Internet mit öffentlichen Zeitservern synchronisiert wird.
Identifikation der strukturellen Elemente der SKZI
Auf Grundlage der oben genannten Beschreibung der IT-Infrastruktur werden wir die strukturellen Elemente der SKZI identifizieren und in einer Tabelle festhalten.
Tabelle – Zuordnung der Elemente des SKZI-Modells zu den Elementen der Informationssysteme
Bezeichnung des Elements
Organisation 1
Organisation 2
Anwendungssoftware
CryptoARM-Software
CryptoARM-Software
Softwarekomponente des Kryptokerns
SKZI CryptoPro CSP
SKZI CryptoPro CSP
Hardwarekomponente des Kryptokerns
nicht vorhanden
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Schlüsselbund für öffentliche Schlüssel
Benutzerarbeitsplatz:
— Festplatte;
— Standard Windows-Zertifikatsspeicher.
Hypervisor:
— Festplatte.
Virtuelle Maschine:
— Festplatte;
— Standard Windows-Zertifikatsspeicher.
Schlüsselbund für private Schlüssel
Schlüsselträger ruToken, der im Extraktionsmodus betrieben wird
Schlüsselträger JaCarta GOST, der im nicht-extrahierbaren Modus betrieben wird
Austauschkanal für öffentliche Schlüssel
Benutzerarbeitsplatz:
— Arbeitsspeicher.
Hypervisor:
— Arbeitsspeicher.
Virtuelle Maschine:
— Arbeitsspeicher.
Kanal für den Austausch geschlossener Schlüssel
Benutzerarbeitsplatz:
— USB-Bus;
— Arbeitsspeicher.
nicht vorhanden
Kanal für den Austausch zwischen Krypto-Kernen
nicht vorhanden (keine Hardware für den Krypto-Kern)
Benutzerarbeitsplatz:
— USB-Bus;
— Arbeitsspeicher;
— Softwaremodul USB-over-IP;
— Netzwerkinterface.
Firmeninternes Netzwerk der Organisation 2.
Hypervisor:
— Arbeitsspeicher;
— Netzwerkinterface.
Virtuelle Maschine:
— Netzwerkinterface;
— Arbeitsspeicher;
— Softwaremodul USB-over-IP.
Kanal für den Austausch offener Daten
Benutzerarbeitsplatz:
— Eingabegeräte;
— Arbeitsspeicher;
— Festplatte.
Benutzerarbeitsplatz:
— Eingabegeräte;
— Arbeitsspeicher;
— Festplatte;
— Netzwerkinterface.
Firmeninternes Netzwerk der Organisation 2.
Hypervisor:
— Netzwerkinterface;
— Arbeitsspeicher;
— Festplatte.
Virtuelle Maschine:
— Netzwerkinterface;
— Arbeitsspeicher;
— Festplatte.
Kanal für den Austausch geschützte Daten
Internet.
Firmeninternes Netzwerk der Organisation 1.
Benutzerarbeitsplatz:
— Festplatte;
— Arbeitsspeicher;
— Netzwerkinterface.
Internet.
Firmeninternes Netzwerk der Organisation 2.
Hypervisor:
— Netzwerkinterface;
— Arbeitsspeicher;
— Festplatte.
Virtuelle Maschine:
— Netzwerkinterface;
— Arbeitsspeicher;
— Festplatte.
Zeitübertragungs-Kanal
Benutzerarbeitsplatz:
— Eingabegeräte;
— Arbeitsspeicher;
— Systemtimer.
Internet.
Firmeninternes Netzwerk der Organisation 2,
Hypervisor:
— Netzwerkinterface;
— Arbeitsspeicher;
— Systemtimer.
Virtuelle Maschine:
— Arbeitsspeicher;
— Systemtimer.
Kanal für die Übertragung von Steuerbefehlen
Benutzerarbeitsplatz:
— Eingabegeräte;
— Arbeitsspeicher.
(Grafische Benutzeroberfläche der Software KryptoARM)
Virtuelle Maschine:
— Arbeitsspeicher;
— Festplatte.
(Automatisierungsskripte)
Kanal für den Empfang der Arbeitsergebnisse
Benutzerarbeitsplatz:
— Eingabegeräte;
— Arbeitsspeicher.
(Grafische Benutzeroberfläche der Software KryptoARM)
Virtuelle Maschine:
— Arbeitsspeicher;
— Festplatte.
(Protokolldateien der Automatisierungsskripte)
Sicherheitsbedrohungen auf oberster Ebene
Erklärungen
Annahmen, die bei der Dekomposition von Bedrohungen gemacht wurden:
- Robuste kryptografische Algorithmen werden verwendet.
- Kryptografische Algorithmen werden sicher in den richtigen Betriebsmodi verwendet (z.B., wird nicht zur Verschlüsselung großer Datenmengen verwendet, die zulässige Schlüsselbelastung wird berücksichtigt usw.).
- Angreifer kennen alle angewandten Algorithmen, Protokolle und öffentlichen Schlüssel.
- Angreifer können alle verschlüsselten Daten lesen.
- Angreifer sind in der Lage, beliebige Softwareelemente im System zu reproduzieren.
Dekomposition
U1. Kompromittierung geheimer kryptografischer Schlüssel.
U2. Verschlüsselung gefälschter Daten im Namen eines legitimen Absenders.
U3. Entschlüsselung verschlüsselter Daten durch nicht legitime Empfänger (Angreifer).
U4. Erstellung einer elektronischen Signatur eines legitimen Unterzeichners unter gefälschten Daten.
U5. Erhalt eines positiven Ergebnisses der Überprüfung der elektronischen Signatur gefälschter Daten.
U6. Falsche Annahme elektronischer Dokumente zur Ausführung aufgrund von Problemen im elektronischen Dokumentenfluss.
U7. Unbefugter Zugriff auf geschützte Daten während ihrer Verarbeitung durch SKZI.
U1. Kompromittierung geheimer kryptografischer Schlüssel
U1.1. Erhalt des privaten Schlüssels aus dem Schlüsselverwaltungssystem.
U1.2. Erhalt des privaten Schlüssels aus Objekten der Betriebsumgebung kryptografischer Mittel, in denen er sich vorübergehend befinden kann.
Erklärungen U1.2.
Zu den Objekten, in denen der private Schlüssel vorübergehend gespeichert werden kann, zählen:
- Arbeitsspeicher,
- temporäre Dateien,
- Auslagerungsdateien,
- Hibernate-Dateien,
- Schnappschuss-Dateien des "heißen" Zustands virtueller Maschinen, einschließlich der Inhalte des Arbeitsspeichers von pausierten virtuellen Maschinen.
U1.2.1. Extraktion privater Schlüssel aus dem aktiven Arbeitsspeicher durch Einfrieren der RAM-Module, deren Extraktion und anschließendes Auslesen der Daten (Freeze-Angriff).
Erklärungen U1.2.1.
Beispiel .
U1.3. Gewinnung des privaten Schlüssels aus einem Kanal zum Austausch privater Schlüssel.
Erklärungen U1.3.
Ein Beispiel für die Umsetzung dieser Bedrohung wird präsentiert. .
U1.4. Unautorisierte Modifikation des Kryptokerns, wobei private Schlüssel den Angreifern bekannt werden.
U1.5. Kompromittierung des privaten Schlüssels durch die Nutzung technischer Informationsabflusskanäle (T1).
Erklärungen U1.5.
Beispiel .
U1.6. Kompromittierung des privaten Schlüssels durch den Einsatz spezieller technischer Mittel (STM), die für die heimliche Informationsübertragung ("Wanzen") bestimmt sind.
U1.7. Kompromittierung privater Schlüssel während ihrer Speicherung außerhalb des Sicherheitsmoduls.
Erläuterungen U1.7.
Zum Beispiel bewahrt der Benutzer seine Schlüsselmedien in der Schublade des Desktops, aus der sie leicht von Angreifern entnommen werden können.
U2. Verschlüsselung gefälschter Daten im Namen des legitimen Absenders
Erklärungen
Diese Bedrohung wird nur für Datenverschlüsselungsschemata mit Authentifizierung des Absenders betrachtet. Beispiele für solche Schemata sind in den Empfehlungen zur Standardisierung aufgeführt. . Für andere kryptografische Schemata besteht diese Bedrohung nicht, da die Verschlüsselung auf den öffentlichen Schlüsseln des Empfängers erfolgt, die in der Regel Angreifern bekannt sind.
Dekomposition
U2.1. Kompromittierung des privaten Schlüssels des Absenders:
U2.1.1. Link: .
U2.2. Manipulation der Eingabedaten im Kanal des Austauschs offener Daten.
Hinweise U2.2.
Beispiele für die Umsetzung dieser Bedrohung sind unten aufgeführt. und .
U3. Entschlüsselung von Daten durch unbefugte Dritte (Angreifer)
Dekomposition
U3.1. Kompromittierung der privaten Schlüssel des Empfängers der verschlüsselten Daten.
U3.1.1 Link: .
U3.2. Manipulation verschlüsselter Daten im Übertragungskanal geschützter Daten.
U4. Erstellung einer elektronischen Signatur eines legitimen Unterzeichners unter gefälschten Daten.
Dekomposition
U4.1. Kompromittierung der privaten Schlüssel der elektronischen Signatur des legitimen Unterzeichners.
U4.1.1 Link: .
U4.2. Manipulation der zu signierenden Daten im Übertragungskanal offener Daten.
Hinweis U4.2.
Beispiele für die Umsetzung dieser Bedrohung sind unten aufgeführt. und .
U5. Erhalt eines positiven Ergebnisses der Überprüfung der elektronischen Signatur gefälschter Daten.
Dekomposition
U5.1. Angreifer fangen im Übertragungskanal das negative Ergebnis der Überprüfung der elektronischen Signatur ab und ersetzen es durch eine Mitteilung mit positivem Ergebnis.
U5.2. Angreifer führen einen Vertrauensangriff auf die Signaturzertifikate durch (SZENARIO — alle Elemente sind obligatorisch):
U5.2.1. Angreifer generieren einen öffentlichen und einen privaten Schlüssel für digitale Signaturen. Wenn im System Zertifikate für digitale Signaturschlüssel verwendet werden, erzeugen sie ein Zertifikat, das dem des vermeintlichen Absenders von Daten, dessen Nachricht sie fälschen möchten, so ähnlich wie möglich ist.
U5.2.2. Angreifer nehmen unbefugte Änderungen im Repository der öffentlichen Schlüssel vor, indem sie dem von ihnen generierten öffentlichen Schlüssel das erforderliche Maß an Vertrauen und Befugnissen verleihen.
U5.2.3. Angreifer signieren gefälschte Daten mit dem zuvor erstellten digitalen Signaturschlüssel und schleusen diese in den Kanal für den Austausch geschützter Daten ein.
U5.3. Angreifer führen einen Angriff mit abgelaufenen digitalen Signaturschlüsseln eines legitimen Unterzeichners durch (SZENARIO — alle Elemente sind obligatorisch):
U5.3.1. Angreifer kompromittieren abgelaufene (derzeit nicht gültige) private Schlüssel für digitale Signaturen eines legitimen Absenders.
U5.3.2. Angreifer ersetzen die Zeit im Zeitübertragungs-Kanal durch einen Zeitpunkt, zu dem die kompromittierten Schlüssel noch gültig waren.
U5.3.3. Angreifer verwenden zuvor kompromittierte elektronische Signaturschlüssel, um gefälschte Daten zu signieren und diese in den Kanal für den Austausch geschützter Daten einzufügen.
U5.4. Angreifer führen einen Angriff mit kompromittierten elektronischen Signaturschlüsseln eines legitimen Unterzeichners durch (SZENARIO — alle Elemente sind obligatorisch):
U5.4.1. Angreifer erstellen eine Kopie des öffentlichen Schlüssel-Repositorys.
U5.4.2. Angreifer kompromittieren die privaten Schlüssel eines der legitimen Absender. Dieser bemerkt die Kompromittierung, zieht die Schlüssel zurück und die Informationen über den Schlüsselrückzug werden im öffentlichen Schlüssel-Repository gespeichert.
U5.4.3. Angreifer ersetzen das öffentliche Schlüssel-Repository durch das zuvor kopierte.
U5.4.4. Angreifer signieren gefälschte Daten mit dem zuvor kompromittierten elektronischen Signaturschlüssel und fügen diese in den Kanal für den Austausch geschützter Daten ein.
U5.5. aufgrund von Fehlern in der Umsetzung der 2. und 3. Phase der Überprüfung der elektronischen Signatur:
Erklärungen U5.5.
Ein Beispiel für die Umsetzung dieser Bedrohung wird angeführt .
U5.5.1. Überprüfung des Vertrauens in das Zertifikat des elektronischen Signaturschlüssels nur aufgrund des Vorhandenseins von Vertrauen in das Zertifikat, mit dem es signiert wurde, ohne Überprüfungen des CRL oder OCSP.
Erläuterungen U5.5.1.
Beispiel einer Implementierung .
U5.5.2. Bei der Erstellung einer Vertrauenskette zu einem Zertifikat werden die Berechtigungen der ausstellenden Zertifizierungsstellen nicht analysiert.
Erläuterungen U5.5.2.
Beispiel eines Angriffs auf SSL/TLS-Zertifikate.
Angreifer erwarben ein legitimes Zertifikat für ihre E-Mail. Danach erstellten sie ein gefälschtes Zertifikat für eine Website und signierten es mit ihrem Zertifikat. Wenn die Berechtigungen nicht überprüft werden, wird die Vertrauenskette bei der Überprüfung korrekt erscheinen, und folglich wird auch das gefälschte Zertifikat als gültig angezeigt.
U5.5.3. Bei der Erstellung einer Vertrauenskette zu einem Zertifikat werden die Zwischenzertifikate nicht auf Widerruf geprüft.
U5.5.4. Die Aktualisierung der CRL erfolgt seltener, als sie von der Zertifizierungsstelle ausgegeben werden.
U5.5.5. Die Entscheidung über das Vertrauen in die elektronische Signatur erfolgt früher, als die OCSP-Antwort über den Status des Zertifikats eintrifft, die auf eine später als den Zeitpunkt der Signaturbildung gestellte Anfrage gerichtet ist, oder bevor der nach der Signaturbildung nächste CRL empfangen wird.
Erläuterungen U5.5.5.
In den Richtlinien der meisten CA wird die Widerrufszeit eines Zertifikats als der Zeitpunkt angesehen, an dem das nächste CRL veröffentlicht wird, das Informationen über den Widerruf des Zertifikats enthält.
U5.5.6. Bei Erhalt der signierten Daten wird die Zugehörigkeit des Zertifikats zum Absender nicht überprüft.
Erläuterungen zu U5.5.6.
Angriffsszenario. In Bezug auf SSL-Zertifikate: Es kann sein, dass die Übereinstimmung der Adresse des aufgerufenen Servers mit dem Wert des CN-Feldes im Zertifikat nicht überprüft wird.
Angriffsszenario. Angreifer haben die Schlüssel der elektronischen Signatur eines Teilnehmers an einem Zahlungssystem kompromittiert. Danach haben sie das Netzwerk eines anderen Teilnehmers gehackt und im Namen dieses Teilnehmers Zahlungsdokumente, die mit den kompromittierten Schlüsseln signiert waren, an den Abrechnungsserver des Zahlungssystems gesendet. Wenn der Server nur das Vertrauen analysiert und keine Übereinstimmungen überprüft, werden die betrügerischen Dokumente als legitim angesehen.
U6. Falsche Annahme elektronischer Dokumente zur Ausführung aufgrund von Problemen im elektronischen Dokumentenfluss.
Dekomposition
U6.1. Die empfangende Partei stellt keine Duplizierung der erhaltenen Dokumente fest.
Erläuterungen zu U6.1.
Beispiel eines Angriffs. Angreifer können ein an den Empfänger übermitteltes Dokument abfangen, selbst wenn es kryptografisch geschützt ist, und es dann mehrfach im Kanal für den Versand geschützter Daten versenden. Wenn der Empfänger keine Duplikate erkennt, werden alle empfangenen Dokumente als unterschiedliche Dokumente betrachtet und bearbeitet.
U7. Unbefugter Zugriff auf geschützte Daten während ihrer Verarbeitung durch SKZI
Dekomposition
U7.1. aufgrund von Informationen, die über Drittkanäle geleakt werden (Side-Channel-Angriff).
Erläuterungen zu U7.1.
Beispiel .
U7.2. aufgrund der Neutralisierung des Schutzes vor unbefugtem Zugang zu Informationen, die in der SKZI verarbeitet werden:
U7.2.1. Nutzung der SKZI unter Verletzung der Anforderungen, die in der Dokumentation für die SKZI beschrieben sind.
U7.2.2. , durchgeführt aufgrund von vorhandenen Schwachstellen in:
U7.2.2.1. Mitteln zum Schutz vor unbefugtem Zugriff.
U7.2.2.2. der SKZI selbst.
U7.2.2.3. der Betriebsumgebung der kryptografischen Mittel.
Beispiele für Angriffe
Die im Folgenden behandelten Szenarien enthalten absichtlich Fehler in der Organisation der Informationssicherheit und dienen nur zur Illustration möglicher Angriffe.
Szenario 1. Beispiel für die Umsetzung der Bedrohungen U2.2 und U4.2.
Objektbeschreibung
Die Software für das ARMs KBR und die SKZI SKAD ist auf einem physikalischen Computer installiert, der nicht mit dem Rechnungsnetzwerk verbunden ist. Als Schlüsselträger wird der FKN vdToken im Modus mit nicht extrahierbarem Schlüssel verwendet.
Die Vorschriften für die Durchführung der Berechnungen sehen vor, dass der Berechnungsspezialist elektronische Nachrichten in offener Form (Schema des alten ARMs KBR) von einem speziellen geschützten Dateiserver auf seinem Arbeitscomputer herunterlädt, sie dann auf ein abtrennbares Speichermedium (USB-Stick) kopiert und auf das ARM KBR überträgt, wo sie verschlüsselt und signiert werden. Danach überträgt der Spezialist die geschützten elektronischen Nachrichten auf ein abtrennbares Speichermedium und kopiert sie über seinen Arbeitscomputer auf den Dateiserver, von wo sie in die UTA und weiter in das Zahlungssystem der Bank von Russland gelangen.
In diesem Fall umfassen die Kanäle für den Austausch von offenen und geschützten Daten: den Dateiserver, den Arbeitscomputer des Spezialisten und das abtrennbare Speichermedium.
Angriff
Angreifer installieren unbefugt ein Fernsteuerungssystem auf dem Arbeitscomputer eines Spezialisten. Während die Zahlungsanweisungen (elektronischen Nachrichten) auf ein abzugebendes Medium aufgezeichnet werden, ersetzen sie den Inhalt einer dieser Anweisungen im Klartext. Der Spezialist überträgt die Zahlungsanweisungen auf seinen KBR-Arbeitsplatz, unterschreibt und chiffriert sie, ohne die Manipulation zu bemerken (zum Beispiel aufgrund der Vielzahl von Zahlungsanweisungen während der Schicht, Müdigkeit usw.). Danach gelangt die gefälschte Zahlungsanweisung, nachdem sie durch die technologische Kette geleitet wurde, in das Zahlungssystem der Bank von Russland.
Szenario 2. Beispiel für die Umsetzung der Bedrohungen U2.2 und U4.2.
Objektbeschreibung
Der Computer mit installierten KBR-Arbeitsplatz, SCAD-Signatur und angeschlossenem Schlüsselträger FKN vdToken funktioniert in einem separaten Raum ohne Zugang für das Personal.
Der Berechnungsspezialist verbindet sich über das RDP-Protokoll in den Remote-Zugriffsmodus mit dem KBR-Arbeitsplatz.
Angriff
Angreifer fangen Kontodaten ab, mit denen ein Abrechnungsmitarbeiter eine Verbindung herstellt und mit dem ARM KBR arbeitet (zum Beispiel durch schädlichen Code auf seinem Computer). Danach stellen sie im Namen des Mitarbeiters eine Verbindung her und senden einen gefälschten Zahlungsauftrag an das Zahlungssystem der Bank von Russland.
Szenario 3. Beispiel für die Umsetzung der Bedrohung U1.3.
Objektbeschreibung
Betrachten wir eine der hypothetischen Möglichkeiten zur Implementierung der Integrationsmodule „ABS-KBR“ für das neue Schema (ARM KBR-N), bei dem die elektronische Signatur der ausgehenden Dokumente auf der Seite des ABS erfolgt. In diesem Fall nehmen wir an, dass das ABS auf einem Betriebssystem basiert, das von SKZI SKAD Signatur nicht unterstützt wird, und daher die kryptografischen Funktionen auf eine separate virtuelle Maschine – das Integrationsmodul „ABS-KBR“ – verlagert werden.
Als Hauptmedium wird ein gewöhnlicher USB-Token verwendet, der im Modus des entnehmbaren Schlüssels arbeitet. Bei der Verbindung des Schlüssels mit dem Hypervisor stellte sich heraus, dass im System keine freien USB-Ports vorhanden sind, daher wurde beschlossen, den USB-Token über einen Netzwerk-USB-Hub zu verbinden und auf der virtuellen Maschine einen USB-over-IP-Client zu installieren, der die Kommunikation mit dem Hub übernimmt.
Angriff
Angreifer haben den privaten Schlüssel der elektronischen Signatur aus dem Kommunikationskanal zwischen dem USB-Hub und dem Hypervisor abgefangen (die Daten wurden im Klartext übertragen). Mit dem privaten Schlüssel konnten die Angreifer ein gefälschtes Zahlungsdokument erstellen, es elektronisch signieren und zur Ausführung an das ARM KBR-N senden.
Szenario 4. Beispiel für die Umsetzung der Bedrohungen U5.5.
Objektbeschreibung
Betrachten wir das gleiche Schema wie im vorherigen Szenario. Wir gehen davon aus, dass die elektronischen Nachrichten, die aus dem ARM KBR-N kommen, in den Ordner …SHAREIn gelangen, während die Nachrichten, die an das ARM KBR-N und weiter an das Zahlungssystem der Bank von Russland gesendet werden, in …SHAREout gelangen.
Wir gehen auch davon aus, dass bei der Implementierung des Integrationsmoduls die Listen der widerrufenen Zertifikate nur bei der Neuerstellung kryptografischer Schlüssel aktualisiert werden. Außerdem werden elektronische Nachrichten, die im Ordner …SHAREIn eingehen, lediglich auf Integritätskontrolle und das Vertrauen in den öffentlichen Schlüssel der elektronischen Unterschrift überprüft.
Angriff
Die Angreifer nutzten die im vorherigen Szenario gestohlenen Schlüssel, um einen gefälschten Zahlungsauftrag zu signieren, der Informationen über den Geldtransfer auf das Konto des betrügerischen Kunden enthielt, und schickten ihn in den Kanal für den Austausch gesicherter Daten. Da keine Überprüfung erfolgt, ob der Zahlungsauftrag tatsächlich von der Bank Russland signiert wurde, wird er zur Ausführung angenommen.
Quelle: habr.com
