Links zu anderen Teilen der Forschung
- (Sie sind hier)
Dieser Artikel schließt den Zyklus von Publikationen zur Gewährleistung der Informationssicherheit im Bereich der bargeldlosen Bankzahlungen ab. Hier betrachten wir die typischen Bedrohungsmodelle, auf die in der :
- .
- .
- .
- .
HABRO-WARNING !!! Sehr geehrte Habrowaner, dies ist kein unterhaltsamer Beitrag.
Die unter dem Kat verborgenen 40+ Seiten Materialien sollen bei der Arbeit oder im Studium helfen Menschen, die sich mit Bankwesen oder Informationssicherheit beschäftigen. Diese Materialien sind das Endprodukt der Forschung und sind im sachlichen offiziellen Ton verfasst. Im Grunde genommen sind dies Vorlagen für interne Dokumente zur Informationssicherheit.Nun und traditionell - „Die Verwendung von Informationen aus dem Artikel zu illegalen Zwecken wird gesetzlich verfolgt“. Produktives Lesen!
Informationen für Leser, die sich mit der Forschung vertraut machen, beginnend mit dieser Veröffentlichung.
Worüber die Forschung handelt
Sie lesen einen Leitfaden für Fachkräfte, die für die Informationssicherheit der Zahlungen in der Bank verantwortlich sind.
Logik der Darstellung
Zu Beginn in und wird der Schutzgegenstand beschrieben. Dann in Es wird erklärt, wie ein Schutzsystem aufgebaut wird, und es wird auf die Notwendigkeit hingewiesen, ein Bedrohungsmodell zu entwickeln. In wird beschrieben, welche Bedrohungsmodelle existieren und wie sie entwickelt werden. In und wird eine Analyse realer Angriffe bereitgestellt. und enthält eine Beschreibung des Bedrohungsmodells, das auf Informationen aus allen vorhergehenden Teilen basiert.
TYPISCHES BEDROHUNGS-MODELL. NETZWERKVERBINDUNG
Das Schutzobjekt, für das das Bedrohungsmodell angewendet wird (scope)
Das Schutzobjekt sind die Daten, die über eine Netzwerkverbindung übertragen werden, die in Datennetzen funktioniert, die auf dem TCP/IP-Stack basieren.
Architektur
Beschreibung der Architekturelemente:
- „Endknoten“ – Knoten, die geschützte Informationen austauschen.
- „Zwischenknoten“ – Elemente des Datennetzes: Router, Switches, Zugangserver, Proxy-Server und andere Geräte, über die der Datenverkehr der Netzwerkverbindung übertragen wird. Im Allgemeinen kann eine Netzwerkverbindung ohne Zwischenknoten funktionieren (direkt zwischen den Endknoten).
Sicherheitsbedrohungen auf oberster Ebene
Dekomposition
U1. Unbefugter Zugriff auf übertragene Daten.
U2. Unbefugte Modifikation übertragener Daten.
U3. Verletzung des Urheberrechts übertragener Daten.
U1. Unbefugter Zugriff auf übertragene Daten
Dekomposition
U1.1. <…>, die an End- oder Zwischenknoten durchgeführt wird:
U1.1.1. <…> durch das Auslesen von Daten, während sie sich im Speicher des Knotens befinden:
U1.1.1.1. <…> im Arbeitsspeicher.
Erklärungen zu U1.1.1.1.
Zum Beispiel während der Datenverarbeitung durch den Netzwerkstack des Knotens.
U1.1.1.2. <…> im nichtflüchtigen Speicher.
Erklärungen zu U1.1.1.2.
Zum Beispiel beim Speichern übertragener Daten im Cache, in temporären Dateien oder Auslagerungsdateien.
U1.2. <…>, die an fremden Knoten im Datennetz durchgeführt wird:
U1.2.1. <…> mittels Erfassung aller Pakete, die auf das Netzwerkinterface des Knotens gelangen:
Erklärungen zu U1.2.1.
Die Erfassung aller Pakete erfolgt durch das Umschalten der Netzwerkkarte in den Sniffer-Modus (promiscuous mode für kabelgebundene Adapter oder in den Monitor-Modus für Wi-Fi-Adapter).
U1.2.2. <…> durch Durchführung von Man-in-the-Middle-Angriffen (MiTM), jedoch ohne Modifikation der übertragenden Daten (außer Verwaltungsdaten der Netzwerkprotokolle).
U1.2.2.1. Link: .
U1.3. , die durch das Auslaufen von Informationen über technische Kanäle (TKUI) von physischen Knoten oder Kommunikationslinien erfolgt.
U1.4. , durchgeführt durch die Installation spezieller technischer Mittel (STM) an End- oder Zwischenknoten, die zur geheimen Informationsabnahme bestimmt sind.
U2. Unbefugte Modifikation übertragener Daten
Dekomposition
U2.1. , die an End- oder Zwischenknoten durchgeführt wird:
U2.1.1. durch Lesen und Ändern von Daten während deren Aufenthalt in den Speichereinheiten der Knoten:
U2.1.1.1. im Arbeitsspeicher:
U2.1.1.2. im nichtflüchtigen Speicher:
U2.2. , die an fremden Knoten des Datenübertragungsnetzes durchgeführt wird:
U2.2.1. durch Ausführung von Man-in-the-Middle (MiTM)-Angriffen und Umleitung des Traffics zu einem Angreiferknoten:
U2.2.1.1. Physische Verbindung der Angreiferhardware in die Unterbrechung der Netzwerkverbindung.
U2.2.1.2. Durchführung von Angriffen auf Netzwerkprotokolle:
U2.2.1.2.1. Steuerung von virtuellen lokalen Netzwerken (VLAN):
U2.2.1.2.1.1. .
U2.2.1.2.1.2. Unbefugte Modifikation der VLAN-Einstellungen an Switches oder Routern.
U2.2.1.2.2. Routenrouting:
U2.2.1.2.2.1. Unbefugte Modifikation der statischen Routingtabellen von Routern.
U2.2.1.2.2.2. Ankündigung von gefälschten Routen durch Angreifer über dynamische Routingprotokolle.
U2.2.1.2.3. Automatische 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 Dateien der Hostnamen (hosts, lmhosts usw.)
U3. Verletzung des Urheberrechts übertragener Daten
Dekomposition
U3.1. Neutralisierung von Mechanismen zur Ermittlung der Urheberschaft von Informationen durch Angabe falscher Angaben über den Autor oder die Quelle der Daten:
U3.1.1. Änderung der Angaben des Autors, die in den übermittelten Informationen enthalten sind.
U3.1.1.1. Neutralisierung des kryptografischen Schutzes der Integrität und Urheberschaft übertragener Daten:
U3.1.1.1.1. Link: .
U3.1.1.2. Neutralisierung des Urheberrechtsschutzes übertragener Daten, realisiert durch Einmalbestätigungscodes:
U3.1.1.2.1. .
U3.1.2. Änderung der Angaben zur Quelle übertragener Informationen:
U3.1.2.1. .
U3.1.2.2. .
TYPISCHES BEDROHUNGSMODELL. INFORMATIONSSYSTEM, BASIEREND AUF EINER CLIENT-SERVER-ARCHITEKTUR
Das Schutzobjekt, für das das Bedrohungsmodell angewendet wird (scope)
Das zu schützende Objekt ist ein Informationssystem, das auf einer Client-Server-Architektur basiert.
Architektur
Beschreibung der Architekturelemente:
- „Client“ – das Gerät, auf dem der Client-Teil des Informationssystems funktioniert.
- „Server“ – das Gerät, auf dem der Server-Teil des Informationssystems funktioniert.
- „Datenspeicher“ – Teil der Serverinfrastruktur des Informationssystems, der für die Speicherung von Daten vorgesehen ist, die durch das Informationssystem verarbeitet werden.
- „Netzwerkverbindung“ – ein Kanal für den Austausch von Informationen zwischen Client und Server, der durch das Datennetzwerk führt. Eine detailliertere Beschreibung des Elementmodells finden Sie in .
Einschränkungen
Bei der Modellierung des Objekts wurden folgende Einschränkungen festgelegt:
- Der Benutzer interagiert mit dem Informationssystem innerhalb von Endzeitintervallen, die als Arbeitssitzungen bezeichnet werden.
- Zu Beginn jeder Arbeitssitzung erfolgt die Identifikation, Authentifizierung und Autorisierung des Benutzers.
- Alle schützenswerten Informationen werden auf dem Serverteil des Informationssystems gespeichert.
Sicherheitsbedrohungen auf oberster Ebene
Dekomposition
U1. Durchführung unbefugter Aktionen durch Dritte im Namen eines legitimen Benutzers.
U2. Unbefugte Modifikation geschützter Informationen während ihrer Verarbeitung durch den Serverteil des Informationssystems.
U1. Durchführung unbefugter Aktionen durch Dritte im Namen eines legitimen Benutzers
Erläuterungen
In der Regel wird in Informationssystemen die Zuordnung von Aktionen zu dem Benutzer, der sie durchgeführt hat, durch folgende Mittel hergestellt:
- Systemprotokolle (logs).
- Spezielle Attribute von Datenobjekten, die Informationen über den Ersteller oder Modifizierer enthalten.
In Bezug auf die Arbeitssitzung kann diese Bedrohung wie folgt dekonstruiert werden:
- durchgeführt innerhalb der Arbeitssitzung des Benutzers.
- durchgeführt außerhalb der Arbeitssitzung des Benutzers.
Die Arbeitssitzung des Benutzers kann initiiert werden durch:
- Den Benutzer selbst.
- Dritte.
In diesem Stadium wird die intermédiaire Dekomposition dieser Bedrohung wie folgt aussehen:
U1.1. Unbefugte Aktionen wurden innerhalb der Benutzersitzung ausgeführt:
U1.1.1. installiert durch den angegriffenen Benutzer.
U1.1.2. installiert von Angreifern.
U1.2. Unbefugte Aktionen wurden außerhalb der Benutzersitzung ausgeführt.
Aus Sicht der Objekte der Informationsinfrastruktur, die von Angreifern angegriffen werden können, wird die Dekomposition der intermédiaire Bedrohungen wie folgt aussehen:
Elemente
Dekomposition der Bedrohungen
U1.1.1.
U1.1.2.
U1.2.
den Kunden zurückzuführen sind, nicht verfügbar ist.
U1.1.1.1.
U1.1.2.1.
Netzwerkverbindung
U1.1.1.2.
Server
U1.2.1.
Dekomposition
U1.1. Unbefugte Aktionen wurden innerhalb der Benutzersitzung ausgeführt:
U1.1.1. installiert durch den angegriffenen Benutzer:
U1.1.1.1. Angreifer handelten eigenständig vom Client:
U1.1.1.1.1 Angreifer verwendeten die regulären Zugangsmittel des Informationssystems:
U1.1.1.1.1.1. Angreifer verwendeten physische Eingabe- und Ausgabemittel des Clients (Tastatur, Maus, Monitor oder Touchscreen des mobilen Geräts):
U1.1.1.1.1.1.1. Angreifer handelten während der Zeitperioden, in denen die Sitzung aktiv war, Eingabe- und Ausgabemittel verfügbar waren und der Benutzer abwesend war.
U1.1.1.1.1.2. Angreifer verwendeten Remote-Administrationstools (regulär oder von Schadcode bereitgestellt), um den Client zu steuern:
U1.1.1.1.1.2.1. Angreifer handelten während der Zeitperioden, in denen die Sitzung aktiv war, Eingabe- und Ausgabemittel verfügbar waren und der Benutzer abwesend war.
U1.1.1.1.1.2.2. Angreifer verwendeten Remote-Administrationstools, deren Betrieb vom angegriffenen Benutzer nicht bemerkt wird.
U1.1.1.2. Angreifer manipulierten die Daten in der Netzwerkverbindung zwischen dem Client und dem Server, indem sie diese so modifizierten, dass sie als Aktionen eines legitimen Benutzers erkannt wurden:
U1.1.1.2.1. Link: .
U1.1.1.3. Angreifer zwangen den Benutzer, die von ihnen angegebenen Aktionen auszuführen, indem sie soziale Ingenieurmethoden anwendeten.
U1.1.2 installiert von Angreifern:
U1.1.2.1. Angreifer handelten vom Client aus (Und):
U1.1.2.1.1. Angreifer neutralisierten das Zugriffskontrollsystem des Informationssystems:
U1.1.2.1.1.1. Link: .
U1.1.2.1.2. Angreifer haben die regulären Zugangsrechte des Informationssystems verwendet
U1.1.2.2. Angreifer handelten von anderen Knoten im Datennetz, von denen aus eine Netzwerkverbindung mit dem Server hergestellt werden kann (Und):
U1.1.2.2.1. Angreifer haben das Zugriffskontrollsystem des Informationssystems neutralisiert:
U1.1.2.2.1.1. Link: .
U1.1.2.2.2. Angreifer haben nicht autorisierte Zugangsmechanismen des Informationssystems verwendet.
Erklärung U1.1.2.2.2.
Angreifer konnten den regulären Client des Informationssystems auf einem externen Knoten installieren oder nicht autorisierte Software verwenden, die die regulären Austauschprotokolle zwischen Client und Server implementiert.
U1.2 Unbefugte Aktionen wurden außerhalb der Benutzersitzung durchgeführt.
U1.2.1 Angreifer führten unbefugte Aktionen aus und nahmen anschließend nicht autorisierte Änderungen in den Protokollen des Informationssystems oder speziellen Attributen von Datenobjekten vor, um anzugeben, dass ihre Handlungen von einem legitimen Benutzer durchgeführt wurden.
U2. Unbefugte Modifikation geschützter Informationen während ihrer Verarbeitung durch den Server des Informationssystems
Dekomposition
U2.1. Angreifer modifizieren geschützte Informationen mit Hilfe der regulären Mittel des Informationssystems und führen dies im Namen eines legitimen Benutzers durch.
U2.1.1. Link: .
U2.2. Angreifer modifizieren geschützte Informationen durch die Nutzung von Mechanismen, die nicht im regulären Betrieb des Informationssystems vorgesehen sind.
U2.2.1. Angreifer modifizieren Dateien, die geschützte Informationen enthalten:
U2.2.1.1. , unter Verwendung der von dem Betriebssystem bereitgestellten Dateioperationen.
U2.2.1.2. durch die Provokation der Wiederherstellung von Dateien aus einer unbefugt 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 Standardinterfaces des DBMS verwenden, um auf Daten zuzugreifen.
U2.3. Angreifer modifizieren geschützte Informationen durch unautorisierte Modifikation der 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 Ausnutzung von Schwachstellen in der Software des Informationssystems.
U2.5. Angreifer modifizieren geschützte Informationen während ihrer Übertragung zwischen den Komponenten des Serversystems des Informationssystems (z. B. zwischen Datenbankserver und Anwendungsserver):
U2.5.1. Link: .
TYPISCHES MODELL DER BEDROHUNG. ZUGRIFFSKONTROLLSYSTEM
Das Schutzobjekt, für das das Bedrohungsmodell angewendet wird (scope)
Das Schutzobjekt, für das dieses Bedrohungsmodell angewendet wird, entspricht dem Schutzobjekt des Bedrohungsmodells: „Typisches Bedrohungsmodell. Informationssystem, das auf Architektur des Client-Server-Frameworks basiert.“
Unter dem Zugriffskontrollsystem für Benutzer in diesem Bedrohungsmodell versteht man eine Komponente des Informationssystems, die folgende Funktionen implementiert:
- Identifizierung der Benutzer.
- Authentifizierung der Benutzer.
- Autorisierung der Benutzer.
- Protokollierung der Benutzeraktionen.
Sicherheitsbedrohungen auf oberster Ebene
Dekomposition
U1. Unautorisierte Sitzungseröffnung im Namen eines legitimen Benutzers.
U2. Unautorisierte Erhöhung der Benutzerberechtigungen im Informationssystem.
U1. Unautorisierte Sitzungseröffnung im Namen eines legitimen Benutzers
Erläuterungen
Die Zerlegung dieser Bedrohung hängt im Allgemeinen vom verwendeten Typ der Systeme zur Identifizierung und Authentifizierung von Benutzern ab.
In diesem Modell wird nur das System zur Identifizierung und Authentifizierung von Benutzern betrachtet, das Textanmeldungen und Passwörter verwendet. Dabei nehmen wir an, dass der Benutzername eine öffentlich zugängliche Information ist, die Angreifern bekannt ist.
Dekomposition
U1.1. durch Kompromittierung der Anmeldedaten:
U1.1.1. Angreifer haben die Anmeldedaten des Benutzers während ihrer Speicherung kompromittiert.
Erläuterungen zu U1.1.1.
Zum Beispiel könnten die Anmeldedaten auf einem Aufkleber geschrieben worden sein, der am Monitor befestigt ist.
U1.1.2. Der Benutzer hat versehentlich oder in böser Absicht die Zugangsdaten an Dritte weitergegeben.
U1.1.2.1. Der Benutzer hat die Anmeldedaten laut beim Eingeben ausgesprochen.
U1.1.2.2. Der Benutzer hat absichtlich seine Anmeldedaten weitergegeben:
U1.1.2.2.1. an Kollegen.
Erläuterungen U1.1.2.2.1.
Zum Beispiel, damit sie ihn während seiner Krankheitszeit ersetzen können.
U1.1.2.2.2. an Geschäftspartner des Arbeitgebers, die an der Informationsinfrastruktur arbeiten.
U1.1.2.2.3. an Dritte.
Erläuterungen U1.1.2.2.3.
Eine der Möglichkeiten, wie diese Bedrohung realisiert werden kann, ist, dass Angreifer Methoden der sozialen Manipulation verwenden.
U1.1.3. Angreifer haben die Anmeldedaten durch Ausprobieren erlangt:
U1.1.3.1. unter Verwendung der vorhandenen Zugangsmethoden.
U1.1.3.2. basierend auf zuvor abgefangenen Codes (z. B. Passwort-Hashes) zur Speicherung der Anmeldedaten.
U1.1.4. Angreifer haben schadhafter Code verwendet, um die Anmeldedaten des Benutzers abzufangen.
U1.1.5. Angreifer haben die Anmeldedaten aus der Netzwerkverbindung zwischen dem Client und dem Server extrahiert:
U1.1.5.1. Link: .
U1.1.6. Angreifer haben die Anmeldedaten aus den Aufzeichnungen von Überwachungssystemen extrahiert:
U1.1.6.1. von Videosystemen (falls bei der Arbeit die Tastenanschläge aufgezeichnet wurden).
U1.1.6.2. von Systemen, die das Verhalten der Mitarbeiter am Computer überwachen.
Erläuterungen U1.1.6.2.
Ein Beispiel für ein solches System ist — .
U1.1.7. Angreifer haben die Anmeldedaten des Benutzers aufgrund von Mängeln im Übertragungsprozess kompromittiert.
Erläuterungen U1.1.7.
Zum Beispiel die Übertragung von Passwörtern im Klartext per E-Mail.
U1.1.8. Angreifer haben die Anmeldedaten erhalten, indem sie die Sitzung des Benutzers mit Remote-Management-Systemen beobachtet haben.
U1.1.9. Angreifer haben die Anmeldedaten infolge ihrer technischen Kanäle (TKUIs) abgerufen:
U1.1.9.1. Angreifer haben beobachtet, wie der Benutzer die Anmeldedaten von der Tastatur eingibt:
U1.1.9.1.1 Angreifer befanden sich in unmittelbarer Nähe zum Benutzer und sahen die Eingabe der Anmeldedaten mit eigenen Augen.
Erläuterungen U1.1.9.1.1
Zu solchen Fällen gehören die Handlungen von Kollegen am Arbeitsplatz oder der Fall, dass die Tastatur des Nutzers für die Besucher der Organisation sichtbar ist.
U1.1.9.1.2 Angreifer verwendeten zusätzliche technische Mittel wie ein Fernglas oder eine Drohne und sahen die Eingabe von Anmeldedaten durch ein Fenster.
U1.1.9.2. Angreifer erlangten die Anmeldedaten durch das Abfangen von Funkübertragungen zwischen der Tastatur und dem Computer, wenn sie über eine Funkverbindung (z. B. Bluetooth) verbunden waren.
U1.1.9.3. Angreifer konnten Anmeldedaten abfangen, indem sie diese durch elektromagnetische Strahlung und Störungen (PEMIN) erfassten.
Erläuterungen U1.1.9.3.
Beispiele für Angriffe und .
U1.1.9.4. Der Angreifer konnte die Eingabe von Anmeldedaten über die Tastatur mit speziellen technischen Mitteln (STM) abfangen, die für das heimliche Abgreifen von Informationen bestimmt sind.
Erläuterungen U1.1.9.4.
Beispiele .
U1.1.9.5. Angreifer schnappen die Eingabe von Anmeldedaten über die Tastatur ab, indem sie
das Wi-Fi-Signal analysieren, das durch den Prozess der Tasteneingabe des Benutzers moduliert wird.
Erläuterungen U1.1.9.5.
Beispiel .
U1.1.9.6. Angreifer schnappen die Eingabe von Anmeldedaten über die Tastatur ab, indem sie die Geräusche von Tasteneingaben analysieren.
Erläuterungen U1.1.9.6.
Beispiel .
U1.1.9.7. Angreifer schnappen die Eingabe von Anmeldedaten von mobilen Geräten ab, indem sie die Daten des Beschleunigungssensors analysieren.
Erläuterungen U1.1.9.7.
Beispiel .
U1.1.10. , zuvor auf dem Client gespeichert.
Erläuterungen U1.1.10.
Zum Beispiel könnte der Benutzer seinen Benutzernamen und sein Passwort für den Zugang zu einer bestimmten Website im Browser gespeichert haben.
U1.1.11. Angreifer haben Anmeldedaten aufgrund von Mängeln im Verfahren zur Widerrufung von Benutzerzugängen kompromittiert.
Erläuterungen U1.1.11.
Zum Beispiel blieben die Konten eines Benutzers nach seiner Entlassung ungesperrt.
U1.2. aufgrund der Nutzung von Schwachstellen im Zugangskontrollsystem.
U2. Unbefugte Erhöhung der Benutzerprivilegien im Informationssystem
Dekomposition
U2.1 durch nicht autorisierte Änderungen an den Daten, die Informationen über die Benutzerprivilegien enthalten.
U2.2 durch die Nutzung von Schwachstellen im Zugangskontrollsystem.
U2.3. aufgrund von Mängeln im Verfahren zur Zugriffsverwaltung der Benutzer.
Erklärung U2.3.
Beispiel 1. Dem Benutzer wurde ein größerer Zugang gewährt, als er für dienstliche Zwecke benötigte.
Beispiel 2. Nach der Versetzung des Benutzers in eine andere Position wurden die zuvor erteilten Zugriffsrechte nicht entzogen.
TYPISCHES BEDROHUNGSMODELL. INTEGRATIONSMODUL
Das Schutzobjekt, für das das Bedrohungsmodell angewendet wird (scope)
Das Integrationsmodul ist eine Reihe von Objekten der Informationsinfrastruktur, die zum Austausch von Informationen zwischen Informationssystemen gedacht sind.
Unter Berücksichtigung der Tatsache, dass es in Unternehmensnetzwerken nicht immer möglich ist, ein Informationssystem eindeutig von einem anderen zu trennen, kann das Integrationsmodul auch als Verbindungsglied zwischen Komponenten innerhalb eines Informationssystems betrachtet werden.
Architektur
Das allgemeine Schema des Integrationsmoduls sieht wie folgt aus:
Beschreibung der Architekturelemente:
- „Austauschserver (AS)“ – Knoten / Dienst / Komponente des Informationssystems, die die Funktion hat, Daten mit einem anderen Informationssystem auszutauschen.
- „Vermittler“ – Knoten / Dienst, der zur Organisation der Interaktion zwischen Informationssystemen gedacht ist, jedoch nicht Teil dieser Systeme ist.
Beispiele „Vermittler“ könnten Dienste für elektronische Post, Unternehmensdienstbusse (Enterprise Service Bus / SoA-Architektur), externe Datei-Server usw. sein. Im allgemeinen Fall kann das Integrationsmodul auch keine „Vermittler“ enthalten. - „Datenverarbeitungssoftware“ – Gesamtheit der Programme, die Protokolle für den Austausch von Daten und die Formatumwandlung implementieren.
Zum Beispiel die Umwandlung von Daten aus dem UFEBN-Format in das ABS-Format, die Änderung des Status von Nachrichten während der Übertragung usw. - „Netzwerkverbindung“ entspricht dem Objekt, das im typischen Bedrohungsmodell „Netzwerkverbindung“ beschrieben wird. Einige der oben dargestellten Netzwerkverbindungen könnten fehlen.
Beispiele für Integrationsmodule
Schema 1. Integration von ABS und ARM KBR über einen externen Datei-Server
Für die Ausführung von Zahlungen lädt ein autorisierter Mitarbeiter der Bank elektronische Zahlungsdokumente aus dem ABS herunter und speichert sie in einer Datei (in einem eigenen Format, z. B. SQL-Dump) auf dem Netzwerkordner (…SHARE) des Datei-Servers. Diese Datei wird dann mit Hilfe eines Konvertierungsskripts in eine Reihe von Dateien im UFEBN-Format umgewandelt, die anschließend von ARM KBR gelesen werden.
Nachfolgend verschlüsselt und signiert der autorisierte Mitarbeiter — der Benutzer des ARM KBR — die erhaltene Datei und sendet sie an das Zahlungssystem der Bank von Russland.
Bei Zahlungseingängen von der Bank von Russland entschlüsselt das ARM KBR diese und überprüft die elektronische Signatur, bevor sie in Form einer Reihe von Dateien im UFEBS-Format auf den Dateiserver gespeichert werden. Vor dem Import der Zahlungsdokumente in das ABS werden sie mithilfe eines Konverter-Skripts vom UFEBS-Format ins ABS-Format umgewandelt.
Angenommen, in diesem Schema läuft das ABS auf einem physischen Server, das ARM KBR auf einem dedizierten Computer und das Konverter-Skript läuft auf dem Dateiserver.
Die Entsprechung der Objekte im betrachteten Schema zu den Elementen des Integrationsmoduls:
„Austauschserver auf der ABS-Seite“ – ABS-Server.
„Austauschserver auf der ARM KBR-Seite“ – Computer des ARM KBR.
„Vermittler“ – externer Dateiserver.
„Datenverarbeitungssoftware“ – Skript-Konverter.
Schema 2. Integration von ABS und ARM KBR durch Bereitstellung eines gemeinsamen Netzwerkordners mit Zahlungen auf ARM KBR
Alles ähnlich wie im Schema 1, aber ein separater Dateiserver wird nicht verwendet, stattdessen wird der Netzwerkordner (…SHARE) mit elektronischen Zahlungsdokumenten auf dem Computer des ARM KBR bereitgestellt. Das Skript-Konverter arbeitet ebenfalls auf dem ARM KBR.
Die Entsprechung der Objekte im betrachteten Schema zu den Elementen des Integrationsmoduls:
Ähnlich wie im Schema 1, aber „Vermittler“ wird nicht verwendet.
Schema 3. Integration von ABS und ARM KBR-N über IBM WebSphere MQ und signieren elektronischer Dokumente „auf der ABS-Seite“
ABS läuft auf einer Plattform, die von der SKZI SKAD Signature nicht unterstützt wird. Die Signatur der ausgehenden elektronischen Dokumente erfolgt auf einem speziellen Server für elektronische Signaturen (EP-Server). Dieser Server überprüft auch die elektronische Signatur der eingehenden Dokumente von der Bank von Russland.
ABS lädt eine Datei mit den Zahlungsdokumenten im eigenen Format auf den EP-Server hoch.
Der EP-Server wandelt die Datei mithilfe eines Konverter-Skripts in elektronische Nachrichten im UFEBS-Format 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 dort die signierten Zahlungsnachrichten, anschließend verschlüsselt der autorisierte Mitarbeiter — der Benutzer des ARM KBR — sie und sendet sie an das Zahlungssystem der Bank von Russland.
Bei der Zahlungseingängen von der Bank Russland entschlüsselt APM KBR-N diese und prüft die elektronische Signatur. Erfolgreich verarbeitete Zahlungen in Form von entschlüsselten und signierten elektronischen Nachrichten im UFEBS-Format werden an IBM WebSphere MQ weitergeleitet, von wo sie den EP-Server empfangen.
Der EP-Server überprüft die elektronische Signatur der eingegangenen Zahlungen und speichert sie in einer ABS-Datei. Danach lädt ein autorisierter Mitarbeiter — Nutzer der ABS — die entstandene Datei gemäß den festgelegten Verfahren in die ABS hoch.
Die Entsprechung der Objekte im betrachteten Schema zu den Elementen des Integrationsmoduls:
„Austauschserver seitens ABS“ – ABS-Server.
„Austauschserver seitens APM KBR“ — Computer APM KBR.
„Vermittler“ – EP-Server und IBM WebSphere MQ.
„Datenverarbeitungssoftware“ – Konvertierungsskript, SKZI SKAD Signatur auf dem EP-Server.
Schema 4. Integration des DBO-Servers und ABS über die API, die vom dedizierten Austauschserver bereitgestellt wird
Wir gehen davon aus, dass in der Bank mehrere Systeme für das Internet-Banking (DBO) verwendet werden:
- „Internet Client-Bank“ für Privatpersonen (IKB FL);
- „Internet Client-Bank“ für juristische Personen (IKB JL).
Zur Gewährleistung der Informationssicherheit erfolgt die gesamte Interaktion der ABS mit den DBO-Systemen über einen dedizierten Austauschserver, der im Rahmen des Informationssystems „ABS“ arbeitet.
Betrachten wir nun den Interaktionsprozess des DBO-Systems IKB JL mit der ABS.
Der DBO-Server muss aufgrund des ordnungsgemäß beglaubigten Zahlungsauftrags, den er vom Kunden erhalten hat, das entsprechende Dokument in der ABS erstellen. Dazu überträgt er über die API die Informationen an den Austauschserver, der die Daten wiederum in die ABS einfügt.
Bei Änderungen der Kontostände des Kunden generiert die ABS elektronische Benachrichtigungen, die über den Austauschserver an den DBO-Server gesendet werden.
Die Entsprechung der Objekte im betrachteten Schema zu den Elementen des Integrationsmoduls:
„Austauschserver seitens DBO“ – DBO-Server IKB JL.
„Austauschserver seitens ABS“ – Austauschserver.
„Vermittler“ – nicht vorhanden.
„Datenverarbeitungssoftware“ – Komponenten des DBO-Servers, die für die Nutzung der API des Austauschservers verantwortlich sind, Komponenten des Austauschservers, die für die Nutzung der API der ABS verantwortlich sind.
Sicherheitsbedrohungen auf oberster Ebene
Dekomposition
U1. Einschleusung von gefälschten Informationen durch Angreifer über das Integrationsmodul.
U1. Einschleusung von gefälschten Informationen durch Angreifer über das Integrationsmodul
Dekomposition
U1.1. Unbefugte Modifizierung legitimer Daten bei deren Übertragung über Netzwerkverbindungen:
U1.1.1 Link: .
U1.2. Übertragung von gefälschten Daten im Namen eines legitimen Teilnehmers des Austauschs:
U1.1.2 Link: .
U1.3. Unbefugte Modifikation legitimer Daten bei deren Verarbeitung auf Austausch-Servern oder durch einen Mittelsmann:
U1.3.1. Link: .
U1.4. Erstellung gefälschter Daten auf Austausch-Servern oder durch einen Mittelsmann im Namen eines legitimen Teilnehmers des Austauschs:
U1.4.1. Link:
U1.5. Unbefugte Modifikation von Daten bei deren Verarbeitung mit Hilfe von Datenverarbeitungssoftware:
U1.5.1. durch unbefugte Änderungen der Einstellungen (Konfiguration) der Datenverarbeitungssoftware durch Angreifer.
U1.5.2. durch unbefugte Änderungen der ausführbaren Dateien der Datenverarbeitungssoftware durch Angreifer.
U1.5.3. durch interaktive Steuerung der Arbeitsweise der Datenverarbeitungssoftware durch Angreifer.
TYPISCHES BEDROHUNGSMODELL. SYSTEM ZUR KRYPTOGRAPHISCHEN SCHUTZ VON INFORMATIONEN
Das Schutzobjekt, für das das Bedrohungsmodell angewendet wird (scope)
Das Objekt des Schutzes ist ein System zur kryptographischen Sicherung von Informationen, das zur Gewährleistung der Sicherheit des Informationssystems eingesetzt wird.
Architektur
Die Grundlage jedes Informationssystems ist die Anwendungssoftware (AS), die ihre Zielsetzung umsetzt.
Kryptographischer Schutz wird in der Regel realisiert, indem kryptographische Primitiven zur Anwendung aus der Geschäftslogik der Anwendungssoftware aufgerufen werden, die in speziellen Bibliotheken – Krypto-Kernen – abgelegt sind.
Zu den kryptographischen Primitiven gehören niedrigstufige kryptographische Funktionen wie:
- Datenblöcke verschlüsseln / entschlüsseln;
- Digitale Signaturen für Datenblöcke erstellen / überprüfen;
- Hash-Funktionen für Datenblöcke berechnen;
- Schlüsselinformationen erzeugen / laden / entladen;
- usw.
Die Geschäftslogik der Anwendungssoftware realisiert mit Hilfe kryptographischer Primitiven höherstufige Funktionalitäten:
- Dateien mit Schlüsseln der gewählten Empfänger verschlüsseln;
- eine sichere Netzwerkverbindung herstellen;
- über die Ergebnisse der Überprüfung der elektronischen Signatur informieren;
- u.ä.
Die Interaktion der Geschäftslogik mit dem Kryptokern kann erfolgen:
- direkt, durch den Aufruf kryptografischer Primitiven aus dynamischen Bibliotheken des Kryptokerns (.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 wendet sich die Geschäftslogik an die Kryptoschnittstelle, die den Aufruf an den entsprechenden Kryptokern weiterleitet, der in diesem Fall als Kryptoprotektor bezeichnet wird. Die Verwendung kryptografischer Schnittstellen ermöglicht es der Anwendungssoftware, sich von spezifischen kryptografischen Algorithmen zu abstrahieren und flexibler zu sein.
Es lassen sich zwei typische Organisationen des Kryptokerns unterscheiden:
Schema 1 – Monolithischer Kryptokern
Schema 2 – Geteilter Kryptokern
Die Elemente der dargestellten Schemata können sowohl separate Softwaremodule, die auf einem Computer arbeiten, als auch Netzservices sein, die im Rahmen eines Rechennetzwerks interagieren.
Bei der Verwendung von Systemen, die nach Schema 1 aufgebaut sind, arbeiten Anwendungssoftware und Kryptokern innerhalb einer einheitlichen Umgebung für den Betrieb des Kryptomittels (SFK), z. B. auf demselben Computer, unter derselben Betriebssystemverwaltung. Der Nutzer des Systems kann in der Regel auch andere Programme in derselben Umgebung ausführen, einschließlich solcher mit schädlichem Code. Unter diesen Bedingungen besteht ein erhebliches Risiko für die Offenlegung geheimer kryptografischer Schlüssel.
Um das Risiko zu minimieren, verwenden wir Schema 2, bei dem der Kryptokern in zwei Teile geteilt wird:
- Der erste Teil arbeitet zusammen mit der Anwendungssoftware in einer unsicheren Umgebung, in der das Risiko einer Infektion mit schädlichem Code besteht. Wir nennen diesen Teil – "Softwareteil".
- Der zweite Teil arbeitet in einer vertrauenswürdigen Umgebung auf einem dedizierten Gerät, das einen geheimen Schlüssel speichert. Wir nennen diesen Teil – "Hardwareteil".
Die Trennung des Krypto-Kerns in Software- und Hardware-Komponenten ist recht willkürlich. Auf dem Markt gibt es Systeme, die nach dem Prinzip des geteilten Krypto-Kerns aufgebaut sind, bei denen die "Hardware"-Komponente jedoch in Form eines Abbilds einer virtuellen Maschine - virtual HSM - präsentiert wird.).
Die Interaktion beider Teile des Krypto-Kerns erfolgt so, dass geheimen kryptografischen Schlüssel niemals an den Software-Teil übermittelt werden und folglich nicht durch schädlichen Code gestohlen werden können.
Die Schnittstelle (API) zur Interaktion und die Menge der kryptografischen Primitiven, die das Krypto-Kern der Anwendungssoftware bereitstellt, sind in beiden Fällen identisch. Der Unterschied liegt in der Art und Weise ihrer Umsetzung.
So erfolgt bei der Verwendung des geteilten Krypto-Kern-Prinzips die Interaktion zwischen Software- und Hardware-Anteil nach folgendem Prinzip:
- Kryptografische Primitiven, die keinen geheimen Schlüssel benötigen (z.B. Berechnung von Hash-Funktionen, Überprüfung von digitalen Signaturen usw.), werden durch den Software-Anteil ausgeführt.
- Kryptografische Primitiven, die einen geheimen Schlüssel verwenden (Erstellung digitaler Signaturen, Entschlüsselung von Daten usw.), werden durch den Hardware-Anteil ausgeführt.
Wir veranschaulichen die Arbeit des geteilten Krypto-Kerns am Beispiel der Erstellung einer digitalen Signatur:
- Der Software-Anteil berechnet die Hash-Funktion der zu signierenden Daten und überträgt diesen Wert über den Austauschkanal zwischen den Krypto-Kernen an den Hardware-Anteil.
- Der Hardware-Anteil, unter Verwendung des geheimen Schlüssels und des Hashes, formt den Wert der digitalen Signatur und überträgt ihn über den Austauschkanal an den Software-Anteil.
- Der Software-Anteil gibt den erhaltenen Wert an die Anwendungssoftware zurück.
Merkmale der Überprüfung der Gültigkeit der digitalen Signatur.
Wenn die empfangende Seite Daten erhält, die mit einer digitalen Signatur versehen sind, muss sie mehrere Überprüfungsschritte durchführen. Ein positives Ergebnis der Überprüfung der digitalen Signatur wird nur durch die erfolgreiche Durchführung aller Überprüfungsschritte erreicht.
Schritt 1. Überprüfung der Datenintegrität und Urheberschaft der Daten.
Inhalt des Schrittes. Die Überprüfung der elektronischen Signatur der Daten erfolgt gemäß dem entsprechenden kryptographischen Algorithmus. Das erfolgreiche Bestehen dieser Phase zeigt an, dass die Daten seit ihrer Unterzeichnung 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 der Phase: Krypto-Kern.
Phase 2. Kontrolle des Vertrauens in den öffentlichen Schlüssel des Unterzeichners und Kontrolle der Gültigkeitsdauer des privaten Schlüssels der elektronischen Signatur.
Inhalt des Schrittes. Die Phase besteht aus zwei Zwischenphasen. In der ersten wird festgestellt, ob der öffentliche Schlüssel zur Überprüfung der elektronischen Signatur zum Zeitpunkt der Datenunterzeichnung vertrauenswürdig war. In der zweiten wird festgestellt, ob der private Schlüssel der elektronischen Signatur zum Zeitpunkt der Datenunterzeichnung gültig war. In der Regel können die Gültigkeitsdauern dieser Schlüssel unterschiedlich sein (zum Beispiel für qualifizierte Zertifikate der Schlüssel zur Überprüfung der elektronischen Signatur). Die Methoden zur Feststellung des Vertrauens in den öffentlichen Schlüssel des Unterzeichners werden durch die im elektronischen Dokumentenaustausch festgelegten Regeln bestimmt, die von den beteiligten Parteien angenommen wurden.
Durchführungsort der Phase: Anwendungssoftware / Krypto-Kern.
Phase 3. Kontrolle der Befugnisse des Unterzeichners.
Inhalt des Schrittes. Gemäß den festgelegten Regeln des elektronischen Dokumentenaustauschs wird überprüft, ob der Unterzeichner das Recht hatte, die geschützten Daten zu bestätigen. Nehmen wir als Beispiel eine Situation, in der die Befugnisse verletzt wurden. Angenommen, es gibt eine Organisation, in der alle Mitarbeiter eine elektronische Signatur haben. Ein Befehl des Chefs wird im internen System des elektronischen Dokumentenaustauschs eingegeben, jedoch von der elektronischen Signatur des Lagerleiters unterzeichnet. Dementsprechend kann ein solches Dokument nicht als legitim betrachtet werden.
Durchführungsort der Phase: Anwendungssoftware.
Annahmen, die bei der Beschreibung des Schutzobjekts getroffen wurden.
- Die Informationsübertragungswege, mit Ausnahme der Kanäle zum Austausch von Schlüsseln, verlaufen ebenfalls über die Anwendungssoftware, API und Krypto-Kern.
- Informationen über das Vertrauen in die öffentlichen Schlüssel und/oder Zertifikate sowie Informationen über die Befugnisse der Inhaber der öffentlichen Schlüssel werden im Schlüsselverzeichnis gespeichert.
- Die Anwendungssoftware arbeitet über den Krypto-Kern mit dem Schlüsselverzeichnis.
Beispiel eines Informationssystems, das mit Hilfe von SKZI geschützt ist.
Um die zuvor dargelegten Systemschemata 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 (EDO) einzuführen. Zu diesem Zweck haben sie eine Vereinbarung getroffen, in der festgelegt wurde, dass Dokumente per E-Mail übermittelt werden, wobei diese verschlüsselt und mit einer qualifizierten elektronischen Signatur versehen sein müssen. Zur Erstellung und Bearbeitung der Dokumente sollen Büroanwendungen aus dem Paket Microsoft Office 2016 verwendet werden, und als Mittel zur kryptografischen Sicherheit sind die SKZI KryptoPRO und die Verschlüsselungssoftware KryptoARM vorgesehen.
Beschreibung der Infrastruktur der Organisation 1
Organisation 1 hat beschlossen, die SKZI KryptoPRO und die Software KryptoARM auf dem Arbeitsplatzrechner – dem physischen Computer – zu installieren. Die Schlüssel für die Verschlüsselung und elektronische Signatur werden auf einem Schlüsselträger ruToken gespeichert, der im Modus des entnehmbaren Schlüssels arbeitet. Der Benutzer wird elektronische Dokumente lokal auf seinem Computer erstellen, diese dann verschlüsseln, signieren und über einen lokal installierten E-Mail-Client versenden.
Beschreibung der Infrastruktur der Organisation 2
Organisation 2 hat beschlossen, die Funktionen der Verschlüsselung und elektronischen Signatur auf eine dedizierte virtuelle Maschine auszulagern. Alle kryptografischen Operationen werden dabei automatisch durchgeführt.
Dazu wurden auf der dedizierten virtuellen Maschine zwei Netzwerkmappen eingerichtet: „…In“, „…Out“. In die Netzwerkmappen „…In“ werden automatisch die empfangenen Dateien vom Geschäftspartner im offenen Format gelegt. Diese Dateien werden entschlüsselt und auf die elektronische Signatur überprüft.
In den Ordner „…Out“ wird der Benutzer Dateien ablegen, die verschlüsselt, signiert und an den Geschäftspartner gesendet werden müssen. Die Dateien wird der Benutzer auf seinem Arbeitsplatzrechner vorbereiten.
Zur Durchführung der Funktionen der Verschlüsselung und elektronischen Signatur sind auf der virtuellen Maschine SKZI KryptoPRO, die Software KryptoARM und ein E-Mail-Client installiert. Die automatische Verwaltung aller Elemente der virtuellen Maschine erfolgt durch Skripte, die von Systemadministratoren entwickelt wurden. Die Ausführung der Skripte wird in Protokolldateien (Logs) dokumentiert.
Die kryptografischen Schlüssel der elektronischen Signatur werden auf dem tokens mit dem nicht entziehbaren JaCarta GOST-Schlüssel abgelegt, den der Benutzer mit seinem lokalen Computer verbinden wird.
Das Token wird mit Hilfe spezialisierter Software-Tools USB-over-IP, die auf der Benutzer-ARM und auf der virtuellen Maschine installiert sind, an die virtuelle Maschine weitergeleitet.
Die Systemuhren auf der Benutzer-ARM in Organisation 1 werden manuell eingestellt. Die Systemuhren der spezialisierten virtuellen Maschine in Organisation 2 werden mit den Systemuhren des Hypervisors synchronisiert, der wiederum über das Internet mit öffentlichen Zeitservern synchronisiert wird.
Identifikation der strukturellen Elemente des SKZI
Auf der Basis der obigen Beschreibung der IT-Infrastruktur identifizieren wir die strukturellen Elemente des SKZI und tragen diese in eine Tabelle ein.
Tabelle – Entsprechung der SKZI-Modell-Elemente zu den Elementen der Informationssysteme
Bezeichnung des Elements
Organisation 1
Organisation 2
Anwendungssoftware
CryptoARM-Software
CryptoARM-Software
Software-Teil des Kryptokerns
SKZI CryptoPro CSP
SKZI CryptoPro CSP
Hardware-Teil des Kryptokerns
komplett.
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Schlüssel-Speicher
Benutzer-ARM:
— Festplatte;
— Standardzertifikatsspeicher von Windows.
Hypervisor:
— Festplatte.
Virtuelle Maschine:
— Festplatte;
— Standardzertifikatsspeicher von Windows.
Geheimspeicher
Schlüsselspeicher ruToken, der im entziehbaren Schlüsselmodus arbeitet
Schlüsselspeicher JaCarta GOST, der im nicht entziehbaren Schlüsselmodus arbeitet
Kanal zum Austausch öffentlicher Schlüssel
Benutzer-ARM:
— Arbeitsspeicher.
Hypervisor:
— Arbeitsspeicher.
Virtuelle Maschine:
— Arbeitsspeicher.
Kanal zum Austausch geheime Schlüssel
Benutzer-ARM:
— USB-Bus;
— Arbeitsspeicher.
komplett.
Kanal zum Austausch zwischen Kryptokernen
fehlt (es gibt keinen Hardware-Teil des Kryptokerns)
Benutzer-ARM:
— USB-Bus;
— Arbeitsspeicher;
— USB-over-IP-Softwaremodul;
— Netzwerk-Schnittstelle.
Unternehmensnetzwerk von Organisation 2.
Hypervisor:
— Arbeitsspeicher;
— Netzwerk-Schnittstelle.
Virtuelle Maschine:
— Netzwerk-Schnittstelle;
— Arbeitsspeicher;
— USB-over-IP-Softwaremodul.
Kanal zum Austausch öffentlicher Daten
Benutzer-ARM:
— Eingabe-/Ausgabemittel;
— Arbeitsspeicher;
— Festplatte.
Benutzer-ARM:
— Eingabe-/Ausgabemittel;
— Arbeitsspeicher;
— Festplatte;
— Netzwerk-Schnittstelle.
Unternehmensnetzwerk von Organisation 2.
Hypervisor:
— Netzwerk-Schnittstelle;
— Arbeitsspeicher;
— Festplatte.
Virtuelle Maschine:
— Netzwerk-Schnittstelle;
— Arbeitsspeicher;
— Festplatte.
Kanal zum Austausch geschützte Daten
Internet.
Unternehmensnetzwerk von Organisation 1.
Benutzer-ARM:
— Festplatte;
— Arbeitsspeicher;
— Netzwerk-Schnittstelle.
Internet.
Unternehmensnetzwerk von Organisation 2.
Hypervisor:
— Netzwerk-Schnittstelle;
— Arbeitsspeicher;
— Festplatte.
Virtuelle Maschine:
— Netzwerk-Schnittstelle;
— Arbeitsspeicher;
— Festplatte.
Kanal zur Übertragung von Zeit
Benutzer-ARM:
— Eingabe-/Ausgabemittel;
— Arbeitsspeicher;
— Systemtimer.
Internet.
Unternehmensnetzwerk von Organisation 2,
Hypervisor:
— Netzwerk-Schnittstelle;
— Arbeitsspeicher;
— Systemtimer.
Virtuelle Maschine:
— Arbeitsspeicher;
— Systemtimer.
Kanal zur Übertragung von Steuerbefehlen
Benutzer-ARM:
— Eingabe-/Ausgabemittel;
— Arbeitsspeicher.
(Grafische Benutzeroberfläche der CryptoARM-Software)
Virtuelle Maschine:
— Arbeitsspeicher;
— Festplatte.
(Automatisierungsskripte)
Kanal zum Empfang der Arbeitsergebnisse
Benutzer-ARM:
— Eingabe-/Ausgabemittel;
— Arbeitsspeicher.
(Grafische Benutzeroberfläche der CryptoARM-Software)
Virtuelle Maschine:
— Arbeitsspeicher;
— Festplatte.
(Protokolldateien der Arbeitsprotokolle der Automatisierungsskripte)
Sicherheitsbedrohungen auf oberster Ebene
Erläuterungen
Annahmen, die bei der Zerlegung von Bedrohungen getroffen wurden:
- Es werden robuste kryptografische Algorithmen verwendet.
- Kryptografische Algorithmen werden sicher in den richtigen Betriebsmodi verwendet (zum Beispiel, wird nicht zum Verschlüsseln großer Datenmengen angewendet, dabei wird die zulässige Belastung des Schlüssels berücksichtigt usw.).
- Angreifern sind alle eingesetzten Algorithmen, Protokolle und öffentlichen Schlüssel bekannt.
- Angreifern sind alle verschlüsselten Daten zugänglich.
- Angreifer sind in der Lage, beliebige Programmelemente 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 von verschlüsselten Daten durch Personen, die nicht die legitimen Empfänger der Daten sind (Angreifer).
U4. Erstellung einer elektronischen Unterschrift des legitimen Unterzeichners unter gefälschten Daten.
U5. Erhalten eines positiven Ergebnisses der Überprüfung der elektronischen Unterschrift unter gefälschten Daten.
U6. Falsche Annahme von elektronischen Dokumenten aufgrund von Problemen in der Organisation des elektronischen Dokumentenverkehrs.
U7. Unbefugter Zugriff auf geschützte Daten während ihrer Verarbeitung durch Krypto-Schutzsysteme.
U1. Kompromittierung geheimer kryptografischer Schlüssel
U1.1. Erhalt des privaten Schlüssels aus dem Tresor der geheimen Schlüssel.
U1.2. Erhalt des privaten Schlüssels aus Elementen der Betriebsumgebung des Kryptosystems, in denen er sich vorübergehend befinden kann.
Erläuterungen zu U1.2.
Zu den Elementen, in denen der private Schlüssel vorübergehend gespeichert werden kann, gehören:
- RAM,
- temporäre Dateien,
- Auslagerungsdateien,
- Hibernation-Dateien,
- Snapshot-Dateien des „heißen“ Zustands von virtuellen Maschinen, einschließlich der Dateien des Inhalts des RAM von pausierten virtuellen Maschinen.
U1.2.1. Extraktion geheimer Schlüssel aus laufendem RAM durch das Einfrieren von RAM-Modulen, deren Entnahme und anschließendes Auslesen der Daten (Freeze-Angriff).
Erläuterungen zu U1.2.1.
Beispiel .
U1.3. Erhalt des privaten Schlüssels aus dem Kanal für den Austausch geheimer Schlüssel.
Erläuterungen zu U1.3.
Ein Beispiel für die Umsetzung dieser Bedrohung wird gegeben .
U1.4. Unbefugte Modifizierung des Kryptokernels, durch die geheime Schlüssel den Angreifern bekannt werden.
U1.5. Die Kompromittierung des privaten Schlüssels durch die Nutzung technischer Informationslecks (TKUI).
Erläuterungen zu U1.5.
Beispiel .
U1.6. Die Kompromittierung des privaten Schlüssels durch die Verwendung spezieller technischer Mittel (STM), die für die heimliche Abhörung von Informationen („Abhörgeräte“) bestimmt sind.
U1.7. Die Kompromittierung von privaten Schlüsseln während ihrer Lagerung außerhalb von SKZI.
Erläuterungen zu U1.7.
Zum Beispiel verstaut der Benutzer seine Schlüsselträger in einer Schreibtischschublade, aus der sie leicht von Angreifern entnommen werden können.
U2. Verschlüsselung gefälschter Daten im Namen eines legitimen Absenders.
Erläuterungen
Diese Bedrohung wird nur für Verschlüsselungsschemata mit Absenderauthentifizierung betrachtet. Beispiele solcher Schemata sind in den Standardisierungsempfehlungen angegeben. . Für andere kryptographische Schemata besteht diese Bedrohung nicht, da die Verschlüsselung mit den öffentlichen Schlüsseln des Empfängers erfolgt, die im Allgemeinen Angreifern bekannt sind.
Dekomposition
U2.1. Die Kompromittierung des privaten Schlüssels des Absenders:
U2.1.1. Link: .
U2.2. Die Manipulation von Eingangsdaten im Austauschkanal für öffentliche Daten.
Anmerkungen zu U2.2.
Beispiele für die Umsetzung dieser Bedrohung sind nachfolgend aufgeführt. und .
U3. Die Entschlüsselung verschlüsselter Daten durch nicht legitime Empfänger der Daten (Angreifer).
Dekomposition
U3.1. Die Kompromittierung von privaten Schlüsseln der Empfänger von verschlüsselten Daten.
U3.1.1 Verweis: .
U3.2. Die Manipulation von verschlüsselten Daten im Austauschkanal für geschützte Daten.
U4. Die Erstellung einer elektronischen Signatur eines legitimen Unterzeichners unter gefälschten Daten.
Dekomposition
U4.1. Die Kompromittierung von privaten Schlüsseln der elektronischen Signatur eines legitimen Unterzeichners.
U4.1.1 Verweis: .
U4.2. Die Manipulation der zu unterzeichnenden Daten im Austauschkanal für öffentliche Daten.
Anmerkung zu U4.2.
Beispiele für die Umsetzung dieser Bedrohung sind nachfolgend aufgeführt. und .
U5. Erhalt eines positiven Ergebnisses der Überprüfung der elektronischen Signatur unter gefälschten Daten.
Dekomposition
U5.1. Angreifer fangen in der Übertragungsleitung der Ergebnisübertragung eine Nachricht über das negative Ergebnis der Überprüfung der elektronischen Signatur ab und ersetzen sie durch eine Nachricht mit positivem Ergebnis.
U5.2. Angreifer führen einen Vertrauensangriff auf die Signaturzertifikate durch (SZENARIO — alle Elemente sind obligatorisch):
U5.2.1. Angreifer generieren ein öffentliches und ein privates Schlüsselpaar für die elektronische Signatur. Falls im System Zertifikate für elektronische Signaturschlüssel verwendet werden, generieren sie ein elektronisches Signaturzertifikat, das dem Zertifikat des mutmaßlichen Absenders der Daten, dessen Nachricht sie fälschen wollen, möglichst ähnlich ist.
U5.2.2. Angreifer nehmen nicht autorisierte Änderungen im Repository der öffentlichen Schlüssel vor, versehen den von ihnen generierten öffentlichen Schlüssel mit dem erforderlichen Vertrauensniveau und den Befugnissen.
U5.2.3. Angreifer signieren gefälschte Daten mit dem zuvor generierten elektronischen Signaturschlüssel und injizieren diese in den Kanal für den Austausch geschützter Daten.
U5.3. Angreifer führen einen Angriff mit abgelaufenen elektronischen Signaturschlüsseln eines legitimen Unterzeichners durch (SZENARIO — alle Elemente sind obligatorisch):
U5.3.1. Angreifer kompromittieren die abgelaufenen (nicht mehr gültigen) privaten elektronischen Signaturschlüssel eines legitimen Absenders.
U5.3.2. Angreifer ersetzen die Zeit im Übertragungsprotokoll durch eine Zeit, zu der die kompromittierten Schlüssel noch gültig waren.
U5.3.3. Angreifer signieren gefälschte Daten mit dem zuvor kompromittierten elektronischen Signaturschlüssel und injizieren diese in den Kanal für den Austausch geschützter Daten.
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 Repositories der öffentlichen Schlüssel.
U5.4.2. Angreifer kompromittieren die privaten Schlüssel eines der legitimen Absender. Dieser entdeckt die Kompromittierung, zieht die Schlüssel zurück, und die Informationen über den Schlüsselrückzug werden im Repository der öffentlichen Schlüssel gespeichert.
U5.4.3. Angreifer ersetzen das Repository der öffentlichen Schlüssel durch das zuvor kopierte.
U5.4.4. Angreifer signieren gefälschte Daten mit dem zuvor kompromittierten elektronischen Signaturschlüssel und injizieren diese in den Kanal für den Austausch geschützter Daten.
U5.5. aufgrund von Fehlern in der Implementierung der 2. und 3. Phase der Überprüfung der elektronischen Signatur:
Erläuterungen U5.5.
Ein Beispiel für die Umsetzung dieser Bedrohung wird gegeben .
U5.5.1. Überprüfung des Vertrauens in das Zertifikat des elektronischen Signaturschlüssels nur aufgrund des Vorhandenseins des Vertrauens in das Zertifikat, mit dem es signiert wurde, ohne CRL- oder OCSP-Überprüfungen.
Erläuterungen U5.5.1.
Beispielimplementation .
U5.5.2. Bei der Erstellung einer Vertrauenskette für das Zertifikat werden die Befugnisse der ausstellenden Zertifikate nicht analysiert
Erläuterungen U5.5.2.
Beispiel eines Angriffs auf SSL/TLS-Zertifikate.
Angreifer haben ein legitimes Zertifikat für ihre E-Mail gekauft. Anschließend haben sie ein gefälschtes Zertifikat für eine Website erstellt und dieses mit ihrem Zertifikat signiert. Wenn die Befugnisüberprüfung nicht durchgeführt wird, wird die Überprüfung der Vertrauenskette korrekt sein, und demnach wird auch das gefälschte Zertifikat als korrekt angesehen.
U5.5.3. Bei der Erstellung einer Vertrauenskette für das Zertifikat werden die Zwischenzertifikate auf den Widerruf nicht überprüft.
U5.5.4. Die Aktualisierung der CRL erfolgt seltener, als sie vom Zertifizierungsstelle ausgegeben werden.
U5.5.5. Die Entscheidung über das Vertrauen in die elektronische Signatur wird getroffen, bevor die OCSP-Antwort über den Status des Zertifikats erhalten wird, die auf eine Anfrage gesendet wurde, die nach dem Zeitpunkt der Signaturerstellung gestellt wurde oder bevor die nächste nach der Signaturerstellung CRL erhalten wird.
Erläuterungen U5.5.5.
In den Vorschriften der meisten CA wird die Zeit des Widerrufs eines Zertifikats als die Zeit des Ausstellens der nächstgelegenen CRL betrachtet, die Informationen über den Widerruf des Zertifikats enthält.
U5.5.6. Bei Erhalt signierter Daten wird die Zugehörigkeit des Zertifikats zum Absender nicht überprüft.
Erläuterungen U5.5.6.
Beispiel eines Angriffs. In Bezug auf SSL-Zertifikate: Die Übereinstimmung der aufgerufenen Serveradresse mit dem Wert des CN-Felds im Zertifikat wird möglicherweise nicht überprüft.
Beispiel eines Angriffs. Angreifer haben die elektronischen Signaturschlüssel eines Teilnehmers an einem Zahlungssystem kompromittiert. Danach haben sie das Netzwerk eines anderen Teilnehmers gehackt und in dessen Namen Dokumente zur Zahlung an den Zahlungsserver gesendet, die mit den kompromittierten Schlüsseln signiert waren. Wenn der Server nur das Vertrauen analysiert und keine Übereinstimmung überprüft, werden die betrügerischen Dokumente als legitim angesehen.
U6. Falsche Annahme von elektronischen Dokumenten aufgrund von Problemen in der Organisation des elektronischen Dokumentenverkehrs.
Dekomposition
U6.1. Die empfangende Partei entdeckt keine Duplikate der erhaltenen Dokumente.
Erläuterungen U6.1.
Beispiel eines Angriffs. Angreifer können ein an den Empfänger übermitteltes Dokument, selbst wenn es kryptografisch gesichert ist, abfangen und dann mehrfach im Kanal der geschützten Datenübertragung senden. Wenn der Empfänger keine Duplikate erkennt, werden alle erhaltenen Dokumente als unterschiedliche Dokumente wahrgenommen und verarbeitet.
U7. Unbefugter Zugriff auf geschützte Daten während ihrer Verarbeitung durch SKZI.
Dekomposition
U7.1. aufgrund der Informationsleckagen über externe Kanäle (Seitenkanalangriff).
Erläuterungen zu U7.1.
Beispiel .
U7.2. aufgrund der Neutralisierung des Schutzes gegen unbefugten Zugriff auf Informationen, die in SKZI verarbeitet werden:
U7.2.1. Betrieb von SKZI unter Missachtung der in der Dokumentation zu SKZI beschriebenen Anforderungen.
U7.2.2. , die aufgrund von Schwachstellen in:
U7.2.2.1. Schutzmaßnahmen gegen unbefugten Zugriff.
U7.2.2.2. SKZI selbst.
U7.2.2.3. Umgebung, in der das kryptographische Mittel funktioniert.
Beispiele für Angriffe
Die nachfolgend behandelten Szenarien enthalten absichtlich Fehler in der Organisation der Informationssicherheit und dienen nur zur Veranschaulichung möglicher Angriffe.
Szenario 1. Beispiel zur Umsetzung der Bedrohungen U2.2 und U4.2.
Beschreibung des Objekts
Software AРM KBR und SKZI SKAD sind auf einem physischen Computer installiert, der nicht mit dem Rechennetzwerk verbunden ist. Als Schlüsselträger wird ein FKN vdToken im Modus mit nicht extrahierbarem Schlüssel verwendet.
Die Vorschriften zur Durchführung von Berechnungen sehen vor, dass der Berechnungsprofi elektronische Nachrichten in offener Form (Schema des alten AРM KBR) von einem speziellen geschützten Dateiserver auf seinem Arbeitscomputer herunterlädt, diese dann auf ein tragbares USB-Laufwerk überträgt und auf das AРM KBR bringt, wo sie verschlüsselt und signiert werden. Danach überträgt der Spezialist die geschützten elektronischen Nachrichten auf ein tragbares Medium und speichert sie anschließend über seinen Arbeitscomputer auf dem Dateiserver, von wo sie auf das UTA und dann in das Zahlungssystem der Bank von Russland gelangen.
In diesem Fall umfassen die Kanäle für den Austausch offener und geschützter Daten: den Dateiserver, den Arbeitscomputer des Spezialisten und das tragbare Medium.
Der Angriff
Angreifer installieren unbefugt ein Fernwartungssystem auf dem Arbeitscomputer eines Spezialisten und ersetzen während der Übertragung von Zahlungsanweisungen (elektronischen Nachrichten) in offener Form den Inhalt einer von ihnen. Der Spezialist überträgt die Zahlungsanweisungen auf den Arbeitsplatzrechner (ARM KBR), signiert sie und verschlüsselt sie, ohne die Manipulation zu bemerken (zum Beispiel aufgrund der großen Anzahl an Zahlungsanweisungen, Ermüdung usw.). Danach gelangt das gefälschte Zahlungsauftrag durch die technologische Kette in das Zahlungssystem der Bank Russland.
Szenario 2. Beispiel für die Umsetzung der Bedrohungen U2.2 und U4.2.
Beschreibung des Objekts
Ein Computer mit installiertem ARM KBR, SKAD Signatur und angeschlossenem Schlüsselträger FKN vdToken arbeitet in einem abgeschotteten Raum ohne Zugriff des Personals.
Der Abrechnungs-Spezialist verbindet sich im Remote-Zugriffsmodus über das RDP-Protokoll mit ARM KBR.
Der Angriff
Angreifer fangen die Zugangsdaten ab, mit denen der Abrechnungs-Spezialist eine Verbindung zu ARM KBR herstellt und damit arbeitet (zum Beispiel durch bösartigen Code auf seinem Computer). Dann stellen sie eine Verbindung in seinem Namen her und schicken ein gefälschtes Zahlungsauftrag in das Zahlungssystem der Bank Russland.
Szenario 3. Beispiel für die Umsetzung der Bedrohung U1.3.
Beschreibung des Objekts
Betrachten wir eine der hypothetischen Varianten der Umsetzung der Integrationsmodule „ABS-KBR“ für das neue Schema (ARM KBR-N), bei dem die elektronische Unterschrift der ausgehenden Dokumente auf der Seite der ABS erfolgt. Dabei gehen wir davon aus, dass die ABS auf einem Betriebssystem läuft, das von der SKZI SKAD Signatur nicht unterstützt wird, und entsprechend die kryptografischen Funktionen auf eine separate virtuelle Maschine - das Integrationsmodul „ABS-KBR“ - ausgelagert sind.
Als Schlüsselträger wird ein gewöhnlicher USB-Token verwendet, der im Modus eines entnehmbaren Schlüssels arbeitet. Bei der Verbindung des Schlüsselträgers 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 anzuschließen, und auf der virtuellen Maschine einen USB-over-IP-Client zu installieren, der die Verbindung zum Hub herstellt.
Der 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 erstellten die Angreifer einen gefälschten Zahlungsauftrag, unterzeichneten ihn mit der elektronischen Signatur und sendeten ihn zur Ausführung an ARМ KБР-Н.
Szenario 4. Beispiel zur Umsetzung der Bedrohungen U5.5.
Beschreibung des Objekts
Betrachten wir dasselbe Schema wie im vorherigen Szenario. Wir gehen davon aus, dass die elektronischen Nachrichten, die von ARМ KБР-Н eingehen, in den Ordner …SHAREIn gelangen, während die Nachrichten, die an ARМ KБР-Н 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 zurückgezogenen Zertifikate nur bei der Neuausstellung der kryptografischen Schlüssel aktualisiert werden und dass die elektronischen Nachrichten, die im Ordner …SHAREIn eingehen, nur auf die Integrität und das Vertrauen in den öffentlichen Schlüssel der elektronischen Signatur überprüft werden.
Der Angriff
Die Angreifer, die die in dem vorherigen Szenario gestohlenen Schlüssel ausnutzten, unterzeichneten einen gefälschten Zahlungsauftrag, der Informationen über den Geldeingang auf das Konto eines betrügerischen Kunden enthielt, und schickten ihn in den Kanal für den Austausch geschützter Daten. Da keine Überprüfung stattfindet, ob der Zahlungsauftrag tatsächlich von der Bank von Russland unterzeichnet wurde, wird er zur Ausführung angenommen.
Quelle: habr.com
