Links zu anderen Teilen der Studie
- (Sind sie hier)
Dieser Artikel schließt den Zyklus von Veröffentlichungen ab, die sich mit der Gewährleistung der Informationssicherheit bei bargeldlosen Bankzahlungen befassen. Hier sehen wir uns die generischen Bedrohungsmodelle an, auf die verwiesen wird :
- .
- .
- .
- .
HABR-WARNUNG!!! Liebe Chabrowiten, das ist kein unterhaltsamer Beitrag.
Es werden mehr als 40 Seiten mit Materialien benötigt, die unter dem Schnitt verborgen sind Hilfe bei der Arbeit oder beim Lernen Personen, die sich auf Bankwesen oder Informationssicherheit spezialisiert haben. Diese Materialien stellen das Endprodukt der Studie dar und sind in einem trockenen, formalen Ton verfasst. Tatsächlich handelt es sich dabei um Rohlinge für interne Dokumente zur Informationssicherheit.Nun ja, das Traditionelle „Die Verwendung der Informationen aus dem Artikel für illegale Zwecke ist strafbar“. Produktives Lesen!
Informationen für Leser, die die Studie ab dieser Veröffentlichung lesen.
Worum geht es in der Studie?
Sie lesen einen Leitfaden für einen Spezialisten, der für die Gewährleistung der Informationssicherheit von Zahlungen in einer Bank verantwortlich ist.
Präsentationslogik
Am Anfang in и die Beschreibung des Schutzgegenstandes erfolgt. Dann in Es erklärt, wie man ein Schutzsystem aufbaut, und spricht über die Notwendigkeit, ein Bedrohungsmodell zu erstellen. IN Es erklärt, was Bedrohungsmodelle sind und wie sie entstehen. IN и Es wird eine Analyse realer Angriffe gegeben. и enthalten eine Beschreibung des Bedrohungsmodells, das unter Berücksichtigung der Informationen aus allen vorherigen Teilen erstellt wurde.
TYPISCHES BEDROHUNGSMODELL. NETZWERKVERBINDUNG
Das Schutzobjekt, für das das Bedrohungsmodell angewendet wird (Umfang)
Der Schutzgegenstand sind Daten, die über eine Netzwerkverbindung übertragen werden, die in Datennetzen betrieben wird, die auf der Grundlage des TCP/IP-Stacks aufgebaut sind.
Architektur
Beschreibung der Architekturelemente:
- „Endknoten“ – Knoten, die geschützte Informationen austauschen.
- „Zwischenknoten“ - Elemente des Datenübertragungsnetzes: Router, Switches, Zugangsserver, Proxyserver und andere Geräte – über die der Netzwerkverbindungsverkehr übertragen wird. Im Allgemeinen kann eine Netzwerkverbindung ohne Zwischenknoten (direkt zwischen Endknoten) funktionieren.
Sicherheitsbedrohungen auf höchstem Niveau
Zersetzung
U1. Unbefugter Zugriff auf übermittelte Daten.
U2. Unerlaubte Veränderung der übermittelten Daten.
U3. Verletzung der Urheberschaft der übermittelten Daten.
U1. Unbefugter Zugriff auf übermittelte Daten
Zersetzung
U1.1. <...>, durchgeführt auf End- oder Zwischenknoten:
U1.1.1. <…> durch Lesen der Daten, während sie sich in den Speichergeräten des Knotens befinden:
U1.1.1.1. <…> im RAM.
Erläuterungen zu V1.1.1.1.
Zum Beispiel während der Datenverarbeitung durch den Netzwerkstapel des Knotens.
U1.1.1.2. <…> im nichtflüchtigen Speicher.
Erläuterungen zu V1.1.1.2.
Beispielsweise beim Speichern übertragener Daten im Cache, temporären Dateien oder Auslagerungsdateien.
Y1.2. <…> durchgeführt auf Datennetzknoten Dritter:
U1.2.1. <...> durch Erfassen aller Pakete, die auf die Netzwerkschnittstelle des Knotens fallen:
Erläuterungen zu V1.2.1.
Alle Pakete werden erfasst, indem die Netzwerkkarte in den Promiscuous-Modus geschaltet wird (Promiscuous-Modus für kabelgebundene Adapter oder Überwachungsmodus für Wi-Fi-Adapter).
U1.2.2. <…> durch die Durchführung von Man-in-the-Middle (MiTM)-Angriffen, jedoch ohne Veränderung der übertragenen Daten (die Dienstdaten von Netzwerkprotokollen nicht mitgerechnet).
Y1.2.2.1. Verknüpfung: .
Y1.3. <...>, durchgeführt aufgrund von Informationslecks über technische Kanäle (TCUI) von physischen Knoten oder Kommunikationsleitungen.
U1.4. <...>, durchgeführt für die Installation spezieller technischer Mittel (STS) auf den End- oder Zwischenknoten, die zur verdeckten Entfernung von Informationen bestimmt sind.
U2. Unerlaubte Veränderung der übermittelten Daten
Zersetzung
U2.1. <...>, durchgeführt auf End- oder Zwischenknoten:
Y2.1.1. <...> durch Lesen und Ändern der Daten, während sie sich in den Speichergeräten der Knoten befinden:
Y2.1.1.1. <...> im RAM:
Y2.1.1.2. <...> im nichtflüchtigen Speicher:
Y2.2. <...> durchgeführt auf Datennetzknoten Dritter:
U2.2.1. <…> durch die Durchführung von Man-in-the-Middle (MiTM)-Angriffen und die Umleitung des Datenverkehrs zum bösartigen Host:
Y2.2.1.1. Die physische Verbindung der Geräte des Angreifers, um die Netzwerkverbindung zu unterbrechen.
Y2.2.1.2. Umsetzung von Angriffen auf Netzwerkprotokolle:
Y2.2.1.2.1. <…> Verwaltung des virtuellen lokalen Netzwerks (VLAN):
Y2.2.1.2.1.1. .
Y2.2.1.2.1.2. Unbefugte Änderung der VLAN-Einstellungen an Switches oder Routern.
Y2.2.1.2.2. <…> Verkehrsführung:
Y2.2.1.2.2.1. Unbefugte Änderung der statischen Routing-Tabellen von Routern.
Y2.2.1.2.2.2. Ankündigung gefälschter Routen durch Angreifer durch dynamische Routing-Protokolle.
Y2.2.1.2.3. <…> automatische Konfiguration:
Y2.2.1.2.3.1. .
Y2.2.1.2.3.2. .
Y2.2.1.2.4. <…> Adressierung und Namensauflösung:
Y2.2.1.2.4.1. .
Y2.2.1.2.4.2. .
Y2.2.1.2.4.3. Vornehmen nicht autorisierter Änderungen an lokalen Hostnamendateien (Hosts, lmhosts usw.)
U3. Verletzung der Urheberschaft der übermittelten Daten
Zersetzung
Y3.1. Neutralisierung von Mechanismen zur Feststellung der Urheberschaft von Informationen durch Angabe falscher Angaben zum Autor oder zur Datenquelle:
Y3.1.1. Änderung der in den übermittelten Informationen enthaltenen Angaben zum Autor.
Y3.1.1.1. Neutralisierung des kryptografischen Schutzes der Integrität und Urheberschaft der übertragenen Daten:
Y3.1.1.1.1. Verknüpfung: .
Y3.1.1.2. Aufhebung des Schutzes der übermittelten Datenurheberschaft, umgesetzt durch einmalige Bestätigungscodes:
Y3.1.1.2.1. .
Y3.1.2. Änderung der Informationen über die Quelle der übermittelten Informationen:
Y3.1.2.1. .
Y3.1.2.2. .
TYPISCHES BEDROHUNGSMODELL. INFORMATIONSSYSTEM AUF BASIS DER CLIENT-SERVER-ARCHITEKTUR
Das Schutzobjekt, für das das Bedrohungsmodell angewendet wird (Umfang)
Der Schutzgegenstand ist ein Informationssystem, das auf der Grundlage der Client-Server-Architektur aufgebaut ist.
Architektur
Beschreibung der Architekturelemente:
- "Klient" - ein Gerät, auf dem der Client-Teil des Informationssystems läuft.
- "Server" - ein Gerät, auf dem der Serverteil des Informationssystems läuft.
- "Datenspeicher" - Teil der Serverinfrastruktur des Informationssystems, der zur Speicherung der vom Informationssystem verarbeiteten Daten dient.
- "Netzwerkverbindung" — ein Informationsaustauschkanal zwischen dem Client und dem Server, der über das Datenübertragungsnetzwerk verläuft. Eine detailliertere Beschreibung des Elementmodells finden Sie unter .
Einschränkungen
Bei der Modellierung eines Objekts werden folgende Einschränkungen festgelegt:
- Der Benutzer interagiert mit dem Informationssystem innerhalb begrenzter Zeiträume, sogenannter Arbeitssitzungen.
- Zu Beginn jeder Sitzung wird der Benutzer identifiziert, authentifiziert und autorisiert.
- Alle geschützten Informationen werden auf dem Serverteil des Informationssystems gespeichert.
Sicherheitsbedrohungen auf höchstem Niveau
Zersetzung
U1. Angreifer begehen nicht autorisierte Aktionen im Namen eines legitimen Benutzers.
U2. Unbefugte Änderung geschützter Informationen während ihrer Verarbeitung durch den Serverteil des Informationssystems.
U1. Angreifer begehen nicht autorisierte Aktionen im Namen eines legitimen Benutzers
Erklärung
Normalerweise erfolgt in Informationssystemen die Korrelation von Aktionen mit dem Benutzer, der sie ausgeführt hat, durch:
- Systemprotokolle (Protokolle).
- spezielle Attribute von Datenobjekten, die Informationen über den Benutzer enthalten, der sie erstellt oder geändert hat.
Bezogen auf eine Arbeitssitzung kann diese Bedrohung wie folgt zerlegt werden:
- <…> wird innerhalb der Benutzersitzung ausgeführt.
- <…> wird außerhalb der Benutzersitzung durchgeführt.
Eine Benutzersitzung kann wie folgt initiiert werden:
- Vom Benutzer selbst.
- Eindringlinge.
Zu diesem Zeitpunkt sieht die Zwischenzerlegung dieser Bedrohung wie folgt aus:
U1.1. Nicht autorisierte Aktionen, die innerhalb der Benutzersitzung ausgeführt werden:
U1.1.1. <…> vom angegriffenen Benutzer festgelegt.
U1.1.2. <…> von Angreifern installiert.
Y1.2. Außerhalb der Sitzung des Benutzers wurden nicht autorisierte Aktionen ausgeführt.
Aus der Sicht der Informationsinfrastrukturobjekte, die von Eindringlingen betroffen sein können, sieht die Aufteilung der Zwischenbedrohungen wie folgt aus:
Elemente
Bedrohungszerlegung
Y1.1.1.
Y1.1.2.
Y1.2.
Auftraggeber
Y1.1.1.1.
Y1.1.2.1.
Netzwerkverbindung
Y1.1.1.2.
Server
Y1.2.1.
Zersetzung
U1.1. Nicht autorisierte Aktionen, die innerhalb der Benutzersitzung ausgeführt werden:
U1.1.1. <…> vom angegriffenen Benutzer festgelegt:
U1.1.1.1. Angreifer agierten unabhängig vom Client aus:
У1.1.1.1.1 Die Angreifer verwendeten Standard-Tools für den Zugriff auf Informationssysteme:
Y1.1.1.1.1.1. Die Angreifer nutzten die physischen Ein-/Ausgabemittel des Clients (Tastatur, Maus, Monitor oder Touchscreen eines mobilen Geräts):
Y1.1.1.1.1.1.1. Die Angreifer agierten in Zeiträumen, in denen die Sitzung aktiv war, E/A-Einrichtungen verfügbar waren und der Benutzer abwesend war.
Y1.1.1.1.1.2. Die Angreifer nutzten Remote-Verwaltungstools (standardmäßig oder durch Schadcode bereitgestellt), um den Client zu verwalten:
Y1.1.1.1.1.2.1. Die Angreifer agierten in Zeiträumen, in denen die Sitzung aktiv war, E/A-Einrichtungen verfügbar waren und der Benutzer abwesend war.
Y1.1.1.1.1.2.2. Die Angreifer nutzten Remote-Verwaltungstools, deren Funktionsweise für den angegriffenen Benutzer unsichtbar ist.
U1.1.1.2. Die Angreifer haben die Daten in der Netzwerkverbindung zwischen dem Client und dem Server gefälscht und sie so verändert, dass sie als Handlungen eines legitimen Benutzers wahrgenommen wurden:
Y1.1.1.2.1. Verknüpfung: .
U1.1.1.3. Die Angreifer zwangen den Benutzer mithilfe von Social-Engineering-Methoden dazu, die von ihm vorgegebenen Aktionen auszuführen.
U1.1.2 <…> von Angreifern gesetzt:
Y1.1.2.1. Die Angreifer agierten vom Client aus (И):
Y1.1.2.1.1. Die Angreifer haben das Zugangskontrollsystem des Informationssystems neutralisiert:
Y1.1.2.1.1.1. Verknüpfung: .
Y1.1.2.1.2. Übeltäter nutzten reguläre Zugangswege zum Informationssystem
U1.1.2.2. Die Angreifer agierten von anderen Knoten des Datenübertragungsnetzes aus, von denen aus eine Netzwerkverbindung mit dem Server hergestellt werden kann (И):
Y1.1.2.2.1. Die Angreifer haben das Zugangskontrollsystem des Informationssystems neutralisiert:
Y1.1.2.2.1.1. Verknüpfung: .
Y1.1.2.2.2. Die Angreifer nutzten nicht standardmäßige Mittel, um auf das Informationssystem zuzugreifen.
Erläuterungen Y1.1.2.2.2.
Die Angreifer könnten einen regulären Informationssystem-Client auf einem Knoten eines Drittanbieters installieren oder nicht standardmäßige Software verwenden, die Standard-Austauschprotokolle zwischen dem Client und dem Server implementiert.
P1.2 Nicht autorisierte Aktionen, die außerhalb der Sitzung des Benutzers ausgeführt werden.
S1.2.1 Angreifer haben nicht autorisierte Aktionen durchgeführt und dann nicht autorisierte Änderungen an den Betriebsprotokollen des Informationssystems oder an speziellen Attributen von Datenobjekten vorgenommen, was darauf hindeutet, dass die von ihnen durchgeführten Aktionen von einem legitimen Benutzer ausgeführt wurden.
U2. Unbefugte Änderung geschützter Informationen während ihrer Verarbeitung durch den Serverteil des Informationssystems
Zersetzung
U2.1. Angreifer modifizieren geschützte Informationen mit Standardtools von Informationssystemen und tun dies im Auftrag eines legitimen Benutzers.
Y2.1.1. Verknüpfung: .
Y2.2. Angreifer verändern geschützte Informationen, indem sie Datenzugriffsmechanismen nutzen, die im regulären Betrieb des Informationssystems nicht vorgesehen sind.
U2.2.1. Angreifer verändern Dateien, die geschützte Informationen enthalten:
Y2.2.1.1. <…> unter Verwendung der vom Betriebssystem bereitgestellten Dateiverarbeitungsmechanismen.
Y2.2.1.2. <...> indem die Wiederherstellung von Dateien aus einem nicht autorisierten, geänderten Backup provoziert wird.
U2.2.2. Übeltäter verändern die in der Datenbank gespeicherten geschützten Informationen (И):
Y2.2.2.1. Angreifer neutralisieren das DBMS-Zugriffskontrollsystem:
Y2.2.2.1.1. Verknüpfung: .
Y2.2.2.2. Angreifer modifizieren Informationen über Standard-DBMS-Schnittstellen, um auf Daten zuzugreifen.
Y2.3. Übeltäter verändern die geschützten Informationen durch unbefugte Modifikation der Arbeitsalgorithmen der sie verarbeitenden Software.
Y2.3.1. Es werden Änderungen am Quellcode der Software vorgenommen.
Y2.3.1. Es werden Änderungen am Maschinencode der Software vorgenommen.
Y2.4. Angreifer modifizieren geschützte Informationen, indem sie Schwachstellen in der Software des Informationssystems ausnutzen.
Y2.5. Angreifer verändern die geschützten Informationen, wenn sie zwischen den Komponenten des Serverteils des Informationssystems (z. B. dem Datenbankserver und dem Anwendungsserver) übertragen werden:
Y2.5.1. Verknüpfung: .
TYPISCHES BEDROHUNGSMODELL. ZUGRIFFSKONTROLLSYSTEM
Das Schutzobjekt, für das das Bedrohungsmodell angewendet wird (Umfang)
Das Schutzobjekt, auf das dieses Bedrohungsmodell angewendet wird, entspricht dem Schutzobjekt des Bedrohungsmodells: „Typisches Bedrohungsmodell. Ein Informationssystem, das auf einer Client-Server-Architektur basiert.
Unter dem Benutzerzugriffskontrollsystem wird in diesem Bedrohungsmodell eine Informationssystemkomponente verstanden, die folgende Funktionen implementiert:
- Benutzeridentifikation.
- Benutzerauthentifizierung.
- Benutzerberechtigungen.
- Benutzeraktionen protokollieren.
Sicherheitsbedrohungen auf höchstem Niveau
Zersetzung
U1. Unbefugter Aufbau einer Sitzung im Namen eines legitimen Benutzers.
U2. Unbefugte Erweiterung von Benutzerrechten im Informationssystem.
U1. Unautorisierter Sitzungsaufbau im Namen eines legitimen Benutzers
Erklärung
Die Zerlegung dieser Bedrohung hängt im Allgemeinen von der Art der verwendeten Benutzeridentifikations- und Authentifizierungssysteme ab.
In diesem Modell wird nur das System zur Benutzeridentifizierung und -authentifizierung mittels Textanmeldung und Passwort berücksichtigt. In diesem Fall gehen wir davon aus, dass es sich bei der Benutzeranmeldung um öffentliche Informationen handelt, die den Angreifern bekannt sind.
Zersetzung
U1.1. <…> durch Kompromittierung von Anmeldeinformationen:
U1.1.1. Die Angreifer manipulierten die Anmeldeinformationen des Benutzers, während diese gespeichert wurden.
Erläuterungen Y1.1.1.
Beispielsweise könnten die Anmeldeinformationen auf einen Klebezettel geschrieben werden, der auf den Monitor geklebt wird.
U1.1.2. Der Benutzer hat versehentlich oder böswillig Zugangsdaten an Angreifer weitergegeben.
Y1.1.2.1. Der Benutzer sprach die Anmeldeinformationen beim Betreten laut aus.
U1.1.2.2. Der Benutzer hat seine Anmeldeinformationen absichtlich weitergegeben:
Y1.1.2.2.1. <…> Kollegen bei der Arbeit.
Erläuterungen Y1.1.2.2.1.
Zum Beispiel, damit sie es durch eine Krankheit ersetzen können.
Y1.1.2.2.2. <…> an die Gegenparteien des Arbeitgebers, die Arbeiten an den Objekten der Informationsinfrastruktur durchführen.
Y1.1.2.2.3. <…> an Dritte.
Erläuterungen Y1.1.2.2.3.
Eine, aber nicht die einzige Möglichkeit, diese Bedrohung umzusetzen, ist der Einsatz von Social-Engineering-Methoden durch Angreifer.
U1.1.3. Die Angreifer haben die Zugangsdaten brutal erzwungen:
Y1.1.3.1. <…> unter Verwendung regulärer Zugriffsmechanismen.
U1.1.3.2. <...> durch zuvor abgefangene Codes (z. B. Passwort-Hashes) zum Speichern von Anmeldeinformationen.
U1.1.4. Die Angreifer nutzten Schadcode, um die Anmeldeinformationen des Benutzers abzufangen.
U1.1.5. Angreifer haben Anmeldeinformationen aus einer Netzwerkverbindung zwischen dem Client und dem Server extrahiert:
Y1.1.5.1. Verknüpfung: .
U1.1.6. Angreifer entnahmen Zugangsdaten aus Aufzeichnungen von Arbeitsüberwachungssystemen:
U1.1.6.1. <…> Videoüberwachungssysteme (falls Tastenanschläge auf der Tastatur während des Betriebs aufgezeichnet wurden).
U1.1.6.2. <…> Systeme zur Überwachung der Aktionen von Mitarbeitern am Computer
Erläuterungen Y1.1.6.2.
Ein Beispiel für ein solches System ist .
U1.1.7. Die Angreifer haben die Zugangsdaten des Benutzers aufgrund von Fehlern im Übertragungsprozess kompromittiert.
Erläuterungen Y1.1.7.
Beispielsweise die Übermittlung von Passwörtern im Klartext per E-Mail.
U1.1.8. Die Angreifer erfuhren die Anmeldeinformationen, indem sie die Sitzung des Benutzers mithilfe von Remoteverwaltungssystemen überwachten.
U1.1.9. Die Angreifer haben die Zugangsdaten aufgrund ihrer Datenlecks über technische Kanäle (TCUE) entwendet:
U1.1.9.1. Die Angreifer haben ausspioniert, wie der Benutzer Anmeldeinformationen über die Tastatur eingibt:
E1.1.9.1.1 Die Angreifer befanden sich in unmittelbarer Nähe des Benutzers und sahen die Eingabe der Anmeldeinformationen mit eigenen Augen.
C1.1.9.1.1 Erläuterungen
Zu diesen Fällen zählen beispielsweise die Aktionen von Arbeitskollegen oder der Fall, dass die Tastatur des Benutzers für Besucher der Organisation sichtbar ist.
E1.1.9.1.2 Die Angreifer setzten zusätzliche technische Mittel wie Ferngläser oder ein unbemanntes Luftfahrzeug ein und sahen den Eintritt von Ausweisen durch ein Fenster.
U1.1.9.2. Die Angreifer extrahierten Zugangsdaten aus den Aufzeichnungen des Funkaustauschs zwischen der Tastatur und der Systemeinheit des Computers, wenn diese über die Funkschnittstelle (z. B. Bluetooth) verbunden waren.
U1.1.9.3. Die Angreifer fingen die Zugangsdaten ab, indem sie sie über den Kanal für unerwünschte elektromagnetische Strahlung und Tonabnehmer (PEMIN) durchsickerten.
Erläuterungen Y1.1.9.3.
Angriffsbeispiele и .
U1.1.9.4. Der Angreifer hat die Eingabe von Anmeldeinformationen über die Tastatur mithilfe spezieller technischer Mittel (STS) abgefangen, die darauf ausgelegt sind, Informationen heimlich zu entfernen.
Erläuterungen Y1.1.9.4.
Примеры .
U1.1.9.5. Die Angreifer haben die Eingabe von Zugangsdaten über die Tastatur abgefangen
Analyse des Wi-Fi-Signals, das durch den Vorgang des Tastendrucks durch den Benutzer moduliert wird.
Erläuterungen Y1.1.9.5.
Beispiel .
U1.1.9.6. Die Angreifer fingen die Eingabe von Zugangsdaten über die Tastatur ab, indem sie die Geräusche von Tastenanschlägen analysierten.
Erläuterungen Y1.1.9.6.
Beispiel .
U1.1.9.7. Die Angreifer fingen die Eingabe von Anmeldeinformationen über die Tastatur eines Mobilgeräts ab, indem sie die Messwerte des Beschleunigungsmessers analysierten.
Erläuterungen Y1.1.9.7.
Beispiel .
U1.1.10. <...> zuvor auf dem Client gespeichert.
Erläuterungen Y1.1.10.
Beispielsweise könnte ein Benutzer einen Benutzernamen und ein Passwort im Browser speichern, um auf eine bestimmte Website zuzugreifen.
U1.1.11. Die Angreifer haben die Anmeldeinformationen aufgrund von Fehlern im Widerrufsprozess des Benutzerzugriffs kompromittiert.
Erläuterungen Y1.1.11.
Beispielsweise blieben nach der Entlassung eines Nutzers dessen Konten nicht gesperrt.
Y1.2. <…> durch Ausnutzung von Schwachstellen im Zugangskontrollsystem.
U2. Unbefugte Erweiterung von Benutzerrechten im Informationssystem
Zersetzung
P2.1 <...> durch unbefugte Änderungen an Daten, die Informationen über die Berechtigungen des Benutzers enthalten.
U2.2 <…> durch Ausnutzung von Schwachstellen im Zugangskontrollsystem.
Y2.3. <…> aufgrund von Fehlern im Benutzerzugriffskontrollprozess.
Erläuterungen Y2.3.
Beispiel 1. Einem Benutzer wurde aufgrund behördlicher Anforderungen mehr Zugriff auf die Arbeit gewährt, als er benötigte.
Beispiel 2: Nach der Versetzung eines Benutzers auf eine andere Position wurden die zuvor gewährten Zugriffsrechte nicht widerrufen.
TYPISCHES BEDROHUNGSMODELL. INTEGRATIONSMODUL
Das Schutzobjekt, für das das Bedrohungsmodell angewendet wird (Umfang)
Integrationsmodul – eine Reihe von Informationsinfrastrukturobjekten, die den Informationsaustausch zwischen Informationssystemen organisieren sollen.
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 Verbindung zwischen Komponenten innerhalb eines Informationssystems betrachtet werden.
Architektur
Das verallgemeinerte Schema des Integrationsmoduls sieht folgendermaßen aus:
Beschreibung der Architekturelemente:
- „Exchange Server (CO)“ – ein Knoten/Dienst/eine Komponente eines Informationssystems, der die Funktion des Datenaustauschs mit einem anderen Informationssystem übernimmt.
- "Vermittler" - ein Knoten/Dienst, der die Interaktion zwischen Informationssystemen organisieren soll, aber kein Teil davon ist.
Beispiele „Vermittler“ Dies können E-Mail-Dienste, Enterprise Service Bus/SoA-Architektur, Dateiserver von Drittanbietern usw. sein. Im Allgemeinen darf das Integrationsmodul keine „Intermediäre“ enthalten. - „Datenverarbeitungssoftware“ - eine Reihe von Programmen, die Datenaustauschprotokolle und Formatkonvertierung implementieren.
Konvertieren Sie beispielsweise Daten vom UFEBS-Format in das ABS-Format, ändern Sie den Nachrichtenstatus während der Übertragung usw. - "Netzwerkverbindung" entspricht dem im typischen Bedrohungsmodell „Netzwerkverbindung“ beschriebenen Objekt. Einige der im obigen Diagramm dargestellten Netzwerkverbindungen sind möglicherweise nicht vorhanden.
Beispiele für Integrationsmodule
Schema 1. Integration von ABS und AWP KBR über einen Dateiserver eines Drittanbieters
Zur Ausführung von Zahlungen lädt ein autorisierter Mitarbeiter der Bank elektronische Zahlungsdokumente aus dem ABS hoch und speichert diese in einer Datei (eigenes Format, z. B. SQL-Dump) im Netzwerkordner (…SHARE) des Dateiservers. Anschließend wird diese Datei mithilfe eines Konverterskripts in eine Reihe von Dateien im UFEBS-Format konvertiert, die dann vom CBD AWP gelesen werden.
Danach verschlüsselt und signiert ein autorisierter Mitarbeiter – ein Benutzer des AWS CBD – die empfangene Datei und sendet sie an das Zahlungssystem der Bank von Russland.
Nach Erhalt von Zahlungen von der Bank von Russland entschlüsselt das AWP der CBR diese, prüft die elektronische Signatur und schreibt sie anschließend als Dateisatz im UFEBS-Format auf den Dateiserver. Vor dem Import von Zahlungsbelegen in das ABS werden diese mit einem Script-Konverter vom UFEBS-Format in das ABS-Format konvertiert.
Wir gehen davon aus, dass in diesem Schema das ABS auf einem physischen Server läuft, die CBD-Workstation auf einem dedizierten Computer und der Skriptkonverter auf einem Dateiserver.
Übereinstimmung der Objekte des betrachteten Schemas mit den Elementen des Modells des Integrationsmoduls:
„Exchange-Server von der ABS-Seite“ - ABS-Server.
„Exchange-Server von der Seite des AWP KBR“ - Computerarbeitsplatz KBR.
"Vermittler" - Dateiserver eines Drittanbieters.
„Datenverarbeitungssoftware“ - Skriptkonverter.
Schema 2. Integration von ABS und AWS KBR beim Platzieren eines freigegebenen Netzwerkordners mit Zahlungen auf AWS KBR
Alles ist ähnlich wie bei Schema 1, jedoch wird kein separater Dateiserver verwendet, sondern ein Netzwerkordner (…SHARE) mit elektronischen Zahlungsdokumenten auf einem Computer mit AWS CBD. Der Skriptkonverter funktioniert auch auf AWP CBD.
Übereinstimmung der Objekte des betrachteten Schemas mit den Elementen des Modells des Integrationsmoduls:
Ähnlich wie Schema 1, jedoch "Vermittler" Wird nicht benutzt.
Schema 3. Integration von ABS und AWS KBR-N über IBM WebSphera MQ und Signieren elektronischer Dokumente „auf der ABS-Seite“
Das ABS läuft auf einer Plattform, die nicht von CIPF SKAD Signature unterstützt wird. Ausgehende elektronische Dokumente werden auf einem speziellen elektronischen Signaturserver (ES Server) signiert. Derselbe Server überprüft die elektronische Signatur unter den von der Bank von Russland eingehenden Dokumenten.
Das ABS lädt eine Datei mit Zahlungsdokumenten in seinem eigenen Format auf den ES-Server hoch.
Der ES-Server konvertiert die Datei mithilfe eines Konverterskripts in elektronische Nachrichten im UFEBS-Format. Anschließend werden die elektronischen Nachrichten signiert und an IBM WebSphere MQ übertragen.
AWS KBR-N greift auf IBM WebSphere MQ zu und empfängt von dort signierte Zahlungsnachrichten. Anschließend verschlüsselt ein autorisierter Mitarbeiter – ein Benutzer von AWS KBR – diese und sendet sie an das Zahlungssystem der Bank von Russland.
Nach Erhalt von Zahlungen von der Bank von Russland entschlüsselt AWP KBR-N diese und überprüft die elektronische Signatur. Erfolgreich verarbeitete Zahlungen in Form von entschlüsselten und signierten elektronischen Nachrichten im UFEBS-Format werden an IBM WebSphere MQ übertragen, von wo aus sie vom ES Server empfangen werden.
Der ES-Server überprüft die elektronische Signatur der empfangenen Zahlungen und speichert sie in einer Datei im ABS-Format. Anschließend lädt ein autorisierter Mitarbeiter – der ABS-Benutzer – die resultierende Datei in der vorgeschriebenen Weise auf das ABS hoch.
Übereinstimmung der Objekte des betrachteten Schemas mit den Elementen des Modells des Integrationsmoduls:
„Exchange-Server von der ABS-Seite“ - ABS-Server.
„Exchange-Server von der Seite des AWP KBR“ - Computerarbeitsplatz KBR.
"Vermittler" – ES-Server und IBM WebSphere MQ.
„Datenverarbeitungssoftware“ – Skriptkonverter, CIPF SCAD-Signatur auf dem ES-Server.
Schema 4. Integration des RBS-Servers und des ABS über die API, die von einem dedizierten Exchange-Server bereitgestellt wird
Wir gehen davon aus, dass die Bank mehrere Remote-Banking-Systeme (RBS) nutzt:
- „Internet Client-Bank“ für Privatpersonen (ICB FL);
- „Internet Client-Bank“ für juristische Personen (ICB LE).
Um die Informationssicherheit zu gewährleisten, erfolgt die gesamte Interaktion des ABS mit RB-Systemen über einen dedizierten Austauschserver, der im Rahmen des ABS-Informationssystems betrieben wird.
Als nächstes betrachten wir den Prozess der Interaktion des RBS-Systems des ICB LE mit dem ABS.
Nachdem der RBS-Server einen ordnungsgemäß beglaubigten Zahlungsauftrag vom Kunden erhalten hat, muss er auf dieser Grundlage ein entsprechendes Dokument im ABS erstellen. Dazu übermittelt er über die API Informationen an den Exchange-Server, der wiederum Daten in das ABS eingibt.
Wenn sich der Kontostand des Kunden ändert, generiert das ABS elektronische Benachrichtigungen, die über den Exchange-Server an den RBS-Server übermittelt werden.
Übereinstimmung der Objekte des betrachteten Schemas mit den Elementen des Modells des Integrationsmoduls:
„Exchange-Server von RBS“ – RBS-Server IKB YUL.
„Exchange-Server von der ABS-Seite“ - Austausch server.
"Vermittler" - fehlen.
„Datenverarbeitungssoftware“ – RB-Serverkomponenten, die für die Verwendung der Exchange-Server-API verantwortlich sind, Exchange-Serverkomponenten, die für die Verwendung der ABS-API verantwortlich sind.
Sicherheitsbedrohungen auf höchstem Niveau
Zersetzung
U1. Die Einführung falscher Informationen durch Übeltäter über das Integrationsmodul.
U1. Die Einführung falscher Informationen durch Angreifer über das Integrationsmodul
Zersetzung
U1.1. Unbefugte Änderung legitimer Daten während der Übertragung über Netzwerkverbindungen:
U1.1.1 Link: .
Y1.2. Übermittlung falscher Daten über Kommunikationskanäle im Namen eines legitimen Börsenteilnehmers:
U1.1.2 Link: .
Y1.3. Unbefugte Änderung legitimer Daten während ihrer Verarbeitung auf den Exchange-Servern oder dem Vermittler:
Y1.3.1. Verknüpfung: .
U1.4. Erstellung gefälschter Daten auf den Exchange-Servern oder dem Vermittler im Namen eines legitimen Exchange-Teilnehmers:
Y1.4.1. Verknüpfung:
Y1.5. Unbefugte Veränderung von Daten während ihrer Verarbeitung durch Datenverarbeitungssoftware:
U1.5.1. <…> aufgrund der Einführung unbefugter Änderungen durch Eindringlinge in die Einstellungen (Konfiguration) der Datenverarbeitungssoftware.
U1.5.2. <…> weil die Eindringlinge unbefugte Änderungen an den ausführbaren Dateien der Datenverarbeitungssoftware vornehmen.
U1.5.3. <...> aufgrund der interaktiven Steuerung von Datenverarbeitungssoftware durch Angreifer.
TYPISCHES BEDROHUNGSMODELL. KRYPTOGRAPHISCHES INFORMATIONSSCHUTZSYSTEM
Das Schutzobjekt, für das das Bedrohungsmodell angewendet wird (Umfang)
Schutzgegenstand ist das kryptografische Informationsschutzsystem, das zur Gewährleistung der Sicherheit des Informationssystems eingesetzt wird.
Architektur
Die Basis eines jeden Informationssystems ist Anwendungssoftware (Software), die seine Zielfunktionalität umsetzt.
Der kryptografische Schutz wird in diesem Fall normalerweise durch den Aufruf kryptografischer Grundelemente aus der Geschäftslogik der Anwendungssoftware implementiert, die sich in speziellen Bibliotheken – Kryptokerneln – befinden.
Zu den kryptografischen Grundelementen gehören kryptografische Funktionen auf niedriger Ebene, wie zum Beispiel:
- Datenblock verschlüsseln/entschlüsseln;
- Erstellen/Überprüfen der elektronischen Signatur des Datenblocks;
- Berechnen Sie die Hash-Funktion des Datenblocks.
- Schlüsselinformationen generieren/hochladen/hochladen;
- usw.
Die Geschäftslogik der Anwendungssoftware implementiert mithilfe kryptografischer Grundelemente eine Funktionalität auf höherer Ebene:
- verschlüsseln Sie die Datei mit den Schlüsseln der ausgewählten Empfänger;
- eine sichere Netzwerkverbindung herstellen;
- über die Ergebnisse der Überprüfung der elektronischen Signatur informieren;
- usw.
Das Zusammenspiel von Geschäftslogik und Kryptokern kann wie folgt durchgeführt werden:
- direkt, indem die Geschäftslogik kryptografische Grundelemente aus den dynamischen Bibliotheken des Kryptokernels (.DLL – für Windows, .SO – für Linux) aufruft;
- direkt über kryptografische Schnittstellen – Wrapper, zum Beispiel MS Crypto API, Java Cryptography Architecture, PKCS # 11 usw. In diesem Fall verweist die Geschäftslogik auf die Kryptoschnittstelle und übersetzt den Aufruf an den entsprechenden Kryptokern, der in diesem Fall wird es Krypto-Anbieter genannt. Durch die Verwendung kryptografischer Schnittstellen kann Anwendungssoftware von bestimmten kryptografischen Algorithmen abstrahieren und flexibler sein.
Es gibt zwei typische Schemata zum Organisieren eines Kryptokerns:
Schema 1 – Monolithischer Kryptokern
Schema 2 – Geteilter Kryptokern
Die Elemente in den obigen Diagrammen können entweder separate Softwaremodule sein, die auf demselben Computer ausgeführt werden, oder Netzwerkdienste, die innerhalb eines Computernetzwerks interagieren.
Bei der Verwendung von Systemen, die nach Schema 1 aufgebaut sind, arbeiten die Anwendungssoftware und der Kryptokern innerhalb einer einzigen Umgebung für den Betrieb eines Kryptomittels (CFC), beispielsweise auf demselben Computer, auf dem dasselbe Betriebssystem ausgeführt wird. Der Benutzer des Systems kann in der Regel andere Programme innerhalb derselben Betriebsumgebung ausführen, einschließlich solcher, die Schadcode enthalten. Unter solchen Bedingungen besteht ein ernstes Risiko des Verlusts privater kryptografischer Schlüssel.
Um das Risiko zu minimieren, wird Schema 2 verwendet, bei dem der Kryptokern in zwei Teile geteilt wird:
- Der erste Teil läuft zusammen mit der Anwendungssoftware in einer nicht vertrauenswürdigen Umgebung, in der das Risiko einer Malware-Infektion besteht. Wir werden diesen Teil „Softwareteil“ nennen.
- Der zweite Teil funktioniert in einer vertrauenswürdigen Umgebung auf einem dedizierten Gerät, das einen privaten Schlüsselspeicher enthält. Wir werden diesen Teil im Folgenden als „Hardware-Teil“ bezeichnen.
Die Aufteilung des Kryptokernels in Software- und Hardwareteile ist sehr bedingt. Es gibt Systeme auf dem Markt, die nach dem Schema mit einem geteilten Kryptokern aufgebaut sind, deren „Hardware“-Teil jedoch in Form eines Abbilds einer virtuellen Maschine – virtuelles HSM ().
Das Zusammenspiel beider Teile des Kryptokerns erfolgt so, dass private kryptografische Schlüssel niemals auf den Softwareteil übertragen werden und dementsprechend nicht durch Schadcode gestohlen werden können.
Die Interaktionsschnittstelle (API) und der Satz kryptografischer Grundelemente, die der Kryptokern der Anwendungssoftware zur Verfügung stellt, sind in beiden Fällen gleich. Der Unterschied liegt in der Art und Weise ihrer Umsetzung.
Bei Verwendung eines Schemas mit geteiltem Kryptokern erfolgt die Interaktion zwischen Software und Hardware also nach folgendem Prinzip:
- Kryptografische Grundfunktionen, die keinen privaten Schlüssel erfordern (z. B. Berechnung einer Hash-Funktion, Überprüfung einer elektronischen Signatur usw.), werden von der Software ausgeführt.
- Kryptografische Grundfunktionen, die einen privaten Schlüssel verwenden (Erstellen einer elektronischen Signatur, Entschlüsseln von Daten usw.), werden von der Hardware ausgeführt.
Lassen Sie uns die Funktionsweise eines geteilten Kryptocores am Beispiel der Erstellung einer elektronischen Signatur veranschaulichen:
- Der Softwareteil berechnet die Hash-Funktion der signierten Daten und übermittelt diesen Wert über den Austauschkanal zwischen den Krypto-Cores an die Hardware.
- Der Hardwareteil generiert mithilfe des privaten Schlüssels und des Hash den Wert der elektronischen Signatur und überträgt ihn über den Austauschkanal an den Softwareteil.
- Der Softwareteil gibt den empfangenen Wert an die Anwendungssoftware zurück.
Merkmale zur Überprüfung der Richtigkeit einer elektronischen Signatur
Wenn der Empfänger mit einer elektronischen Signatur signierte Daten erhält, muss er mehrere Überprüfungsschritte durchführen. Ein positives Ergebnis der Prüfung einer elektronischen Signatur wird nur erreicht, wenn alle Prüfungsschritte erfolgreich abgeschlossen werden.
Stufe 1. Kontrolle der Datenintegrität und Datenurheberschaft.
Bühneninhalt. Die elektronische Signatur der Daten wird nach dem entsprechenden kryptografischen Algorithmus überprüft. Der erfolgreiche Abschluss dieser Phase zeigt an, dass die Daten seit der Signatur nicht geändert wurden und dass die Signatur mit einem privaten Schlüssel erstellt wurde, der dem öffentlichen Schlüssel zur Überprüfung der elektronischen Signatur entspricht.
Ort der Bühne: Kryptokernel.
Stufe 2. Kontrolle des Vertrauens in den öffentlichen Schlüssel des Unterzeichners und Kontrolle der Gültigkeitsdauer des privaten Schlüssels der elektronischen Signatur.
Bühneninhalt. Die Stufe besteht aus zwei Zwischenstufen. Die erste stellt fest, ob der öffentliche Schlüssel zur Überprüfung der elektronischen Signatur zum Zeitpunkt der Signatur der Daten vertrauenswürdig war. Die zweite Methode stellt fest, ob der private Schlüssel der elektronischen Signatur zum Zeitpunkt der Signatur der Daten gültig war. Im Allgemeinen stimmen die Gültigkeitsdauern dieser Schlüssel möglicherweise nicht überein (z. B. bei qualifizierten Zertifikaten von Schlüsseln zur Überprüfung elektronischer Signaturen). Die Methoden zum Aufbau von Vertrauen in den öffentlichen Schlüssel des Unterzeichners werden durch die Regeln der elektronischen Dokumentenverwaltung bestimmt, die von den interagierenden Parteien übernommen werden.
Ort der Bühne: Anwendungssoftware / Krypto-Kernel.
Stufe 3. Kontrolle der Autorität des Unterzeichners.
Bühneninhalt. Gemäß den etablierten Regeln des elektronischen Dokumentenmanagements wird geprüft, ob der Unterzeichner das Recht hatte, die geschützten Daten zu zertifizieren. Stellen Sie sich zum Beispiel eine Situation der Autoritätsverletzung vor. Angenommen, es gibt eine Organisation, in der alle Mitarbeiter eine elektronische Signatur haben. Das interne elektronische Dokumentenmanagementsystem erhält eine Bestellung vom Leiter, die jedoch mit der elektronischen Signatur des Lagerleiters unterzeichnet ist. Dementsprechend kann ein solches Dokument nicht als legitim angesehen werden.
Ort der Bühne: Anwendungssoftware.
Annahmen zur Beschreibung des Schutzgegenstandes
- Informationsübertragungskanäle verlaufen mit Ausnahme der Schlüsselaustauschkanäle auch über Anwendungssoftware, API und Kryptokern.
- Informationen über das Vertrauen in öffentliche Schlüssel und (oder) Zertifikate sowie Informationen über die Autorität der Eigentümer öffentlicher Schlüssel werden im öffentlichen Schlüsselspeicher abgelegt.
- Die Anwendungssoftware arbeitet mit der Speicherung des öffentlichen Schlüssels über den Krypto-Kernel.
Ein Beispiel für ein mit CIPF geschütztes Informationssystem
Um die zuvor vorgestellten Schemata zu veranschaulichen, betrachten Sie ein hypothetisches Informationssystem und wählen Sie alle Strukturelemente darauf aus.
Beschreibung des Informationssystems
Die beiden Organisationen beschlossen, gemeinsam ein rechtsverbindliches elektronisches Dokumentenmanagement (EDF) einzuführen. Dazu schlossen sie eine Vereinbarung, in der sie festlegten, dass die Dokumente per E-Mail übermittelt werden und gleichzeitig verschlüsselt und mit einer qualifizierten elektronischen Signatur signiert sein müssen. Als Mittel zum Erstellen und Bearbeiten von Dokumenten sollten Office-Programme aus dem Microsoft Office 2016-Paket und als Mittel zum kryptografischen Schutz CIPF CryptoPRO und die Verschlüsselungssoftware CryptoARM verwendet werden.
Beschreibung der Infrastruktur der Organisation 1
Organisation 1 beschloss, die Software CryptoPRO CIPF und CryptoARM auf der Workstation des Benutzers, einem physischen Computer, zu installieren. Verschlüsselungs- und elektronische Signaturschlüssel werden auf dem ruToken-Schlüsselträger gespeichert, der im abrufbaren Schlüsselmodus arbeitet. Der Nutzer erstellt lokal auf seinem Computer elektronische Dokumente, die anschließend mit einem lokal installierten Mail-Client verschlüsselt, signiert und versendet werden.
Beschreibung der Infrastruktur der Organisation 2
Organisation 2 beschloss, die Funktionen der Verschlüsselung und elektronischen Signatur auf eine dedizierte virtuelle Maschine zu verlagern. In diesem Fall werden alle kryptografischen Vorgänge automatisch ausgeführt.
Dazu werden zwei Netzwerkordner auf einer dedizierten virtuellen Maschine organisiert: „…In“, „…Out“. Von der Gegenpartei in offener Form empfangene Dateien werden automatisch im Netzwerkordner „…In“ abgelegt. Diese Dateien werden entschlüsselt und die elektronische Signatur wird darauf überprüft.
Im Ordner „…Out“ legt der Benutzer Dateien ab, die verschlüsselt, signiert und an die Gegenpartei gesendet werden müssen. Der Benutzer bereitet die Dateien selbst an seinem Arbeitsplatz vor.
Um Verschlüsselungs- und elektronische Signaturfunktionen auszuführen, werden auf der virtuellen Maschine die Software CryptoPRO CIPF, die Software CryptoARM und ein Mail-Client installiert. Die automatische Verwaltung aller Elemente der virtuellen Maschine erfolgt mithilfe von Skripten, die von Systemadministratoren entwickelt wurden. Die Arbeit von Skripten wird in Protokolldateien (Logs) protokolliert.
Die kryptografischen Schlüssel der elektronischen Signatur werden auf einem Token mit einem nicht abrufbaren JaCarta GOST-Schlüssel gespeichert, den der Benutzer mit seinem lokalen Computer verbindet.
Das Token wird mithilfe spezieller USB-over-IP-Software, die auf der Workstation des Benutzers und auf der virtuellen Maschine installiert ist, an die virtuelle Maschine weitergeleitet.
Die Systemuhr auf dem Arbeitsplatz des Benutzers in Organisation 1 wird manuell angepasst. Die Systemuhr der dedizierten virtuellen Maschine in Organisation 2 wird mit der Systemuhr des Hypervisors synchronisiert, der wiederum über das Internet mit öffentlichen Zeitservern synchronisiert wird.
Zuordnung von Strukturelementen von CIPF
Basierend auf der obigen Beschreibung der IT-Infrastruktur greifen wir die Strukturelemente des CIPF heraus und halten sie in einer Tabelle fest.
Tabelle – Übereinstimmung der Elemente des CIPF-Modells mit den Elementen von Informationssystemen
Artikelname
Organisation 1
Organisation 2
Anwendungssoftware
CryptoARM-Software
CryptoARM-Software
Der Softwareteil des Kryptokernels
CIPF CryptoPRO CSP
CIPF CryptoPRO CSP
Der Hardware-Teil des Kryptokernels
kein
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Speicherung öffentlicher Schlüssel
Benutzerarbeitsplatz:
- Festplatte;
- Standard-Windows-Zertifikatspeicher.
Hypervisor:
- Festplatte.
Virtuelle Maschine:
- Festplatte;
- Standard-Windows-Zertifikatspeicher.
Private Schlüsselspeicherung
Schlüsselträger ruToken, der im Modus eines ausziehbaren Schlüssels arbeitet
JaCarta GOST-Schlüsselträger, der im nicht abrufbaren Schlüsselmodus arbeitet
Kanal für den Austausch öffentlicher Schlüssel
Benutzerarbeitsplatz:
- Rom.
Hypervisor:
- Rom.
Virtuelle Maschine:
- Rom.
Kanal für den privaten Schlüsselaustausch
Benutzerarbeitsplatz:
- USB-Bus;
- Rom.
kein
Austauschkanal zwischen Kryptokernen
fehlt (keine Cryptocore-Hardware)
Benutzerarbeitsplatz:
- USB-Bus;
- Rom;
- USB-over-IP-Softwaremodul;
- Netzwerkschnittstelle.
Unternehmensnetzwerk der Organisation 2.
Hypervisor:
- Rom;
- Netzwerkschnittstelle.
Virtuelle Maschine:
- Netzwerkschnittstelle;
- Rom;
- USB-over-IP-Softwaremodul.
Offener Datenaustauschkanal
Benutzerarbeitsplatz:
- Eingabe-Ausgabe-Mittel;
- Rom;
- Festplatte.
Benutzerarbeitsplatz:
- Eingabe-Ausgabe-Mittel;
- Rom;
- Festplatte;
- Netzwerkschnittstelle.
Unternehmensnetzwerk der Organisation 2.
Hypervisor:
- Netzwerkschnittstelle;
- Rom;
- Festplatte.
Virtuelle Maschine:
- Netzwerkschnittstelle;
- Rom;
- Festplatte.
Sicherer Datenaustauschkanal
Internet.
Unternehmensnetzwerk der Organisation 1.
Benutzerarbeitsplatz:
- Festplatte;
- Rom;
- Netzwerkschnittstelle.
Internet.
Unternehmensnetzwerk der Organisation 2.
Hypervisor:
- Netzwerkschnittstelle;
- Rom;
- Festplatte.
Virtuelle Maschine:
- Netzwerkschnittstelle;
- Rom;
- Festplatte.
Zeitkanal
Benutzerarbeitsplatz:
- Eingabe-Ausgabe-Mittel;
- Rom;
- Systemtimer.
Internet.
Unternehmensnetzwerk der Organisation 2,
Hypervisor:
- Netzwerkschnittstelle;
- Rom;
- Systemtimer.
Virtuelle Maschine:
- Rom;
- Systemtimer.
Steuerbefehlsübertragungskanal
Benutzerarbeitsplatz:
- Eingabe-Ausgabe-Mittel;
- Rom.
(GUI der CryptoARM-Software)
Virtuelle Maschine:
- Rom;
- Festplatte.
(Automatisierungsskripte)
Kanal zum Empfang von Arbeitsergebnissen
Benutzerarbeitsplatz:
- Eingabe-Ausgabe-Mittel;
- Rom.
(GUI der CryptoARM-Software)
Virtuelle Maschine:
- Rom;
- Festplatte.
(Protokolldateien für Automatisierungsskripte)
Sicherheitsbedrohungen auf höchstem Niveau
Erklärung
Annahmen zur Zerlegung von Bedrohungen:
- Es werden starke kryptografische Algorithmen verwendet.
- Kryptografische Algorithmen werden sicher in den richtigen Betriebsmodi verwendet (z. B. gilt nicht für die Verschlüsselung großer Datenmengen, die zulässige Belastung des Schlüssels wird berücksichtigt usw.).
- Übeltäter kennen alle verwendeten Algorithmen, Protokolle und öffentlichen Schlüssel.
- Angreifer haben Zugriff auf alle verschlüsselten Daten.
- Angreifer sind in der Lage, beliebige Programmelemente im System zu reproduzieren.
Zersetzung
U1. Kompromittierung privater kryptografischer Schlüssel.
U2. Verschlüsselung gefälschter Daten im Auftrag eines legitimen Absenders.
U3. Entschlüsselung verschlüsselter Daten durch Personen, die keine rechtmäßigen Datenempfänger sind (Eindringlinge).
U4. Erstellung einer elektronischen Signatur eines rechtmäßigen Unterzeichners unter falschen Daten.
U5. Erhalten eines positiven Ergebnisses der Überprüfung der elektronischen Signatur falscher Daten.
U6. Fehlerhafte Annahme elektronischer Dokumente zur Ausführung aufgrund von Problemen bei der Organisation des elektronischen Dokumentenmanagements.
U7. Unbefugter Zugriff auf geschützte Daten während ihrer Verarbeitung durch CIPF.
U1. Kompromittierung privater kryptografischer Schlüssel
U1.1. Holen Sie sich den privaten Schlüssel aus dem privaten Schlüsselspeicher.
Y1.2. Erhalten eines privaten Schlüssels aus den Objekten der Funktionsumgebung des kryptografischen Tools, in dem er sich vorübergehend befinden kann.
Erläuterungen Y1.2.
Zu den Objekten, die einen privaten Schlüssel vorübergehend speichern können, gehören:
- Rom,
- temporäre Dateien,
- Auslagerungsdateien,
- Ruhezustandsdateien,
- Snapshot-Dateien des „heißen“ Zustands virtueller Maschinen, einschließlich Dateien des RAM-Inhalts virtueller Maschinen, die angehalten wurden.
U1.2.1. Abrufen privater Schlüssel aus dem Arbeits-RAM durch Einfrieren von RAM-Modulen, Extrahieren dieser und anschließendes Auslesen der Daten (Freeze-Angriff).
Erläuterungen Y1.2.1.
Beispiel .
Y1.3. Erhalten eines privaten Schlüssels von einem privaten Schlüsselaustauschkanal.
Erläuterungen Y1.3.
Es wird ein Beispiel für die Umsetzung dieser Bedrohung gegeben .
U1.4. Unerlaubte Veränderung des Kryptokerns, wodurch private Schlüssel Angreifern bekannt werden.
Y1.5. Kompromittierung des privaten Schlüssels durch Nutzung technischer Informationsleckkanäle (TCLE).
Erläuterungen Y1.5.
Beispiel .
U1.6. Kompromittierung des privaten Schlüssels durch den Einsatz spezieller technischer Mittel (STS), die zum geheimen Abrufen von Informationen („Bugs“) konzipiert sind.
Y1.7. Kompromittierung privater Schlüssel während ihrer Speicherung außerhalb des CIPF.
Erläuterungen Y1.7.
Beispielsweise bewahrt ein Benutzer seine wichtigsten Medien in einer Schreibtischschublade auf, aus der sie von Eindringlingen leicht entnommen werden können.
U2. Verschlüsselung gefälschter Daten im Auftrag eines legitimen Absenders
Erklärung
Diese Bedrohung wird nur für Datenverschlüsselungsschemata mit Absenderauthentifizierung berücksichtigt. Beispiele für solche Schemata sind in den Empfehlungen zur Normung aufgeführt. . Bei anderen kryptografischen Verfahren besteht diese Gefahr nicht, da die Verschlüsselung auf den öffentlichen Schlüsseln des Empfängers erfolgt und diese den Angreifern im Allgemeinen bekannt sind.
Zersetzung
U2.1. Kompromittierung des privaten Schlüssels des Absenders:
Y2.1.1. Verknüpfung: .
Y2.2. Substitution von Eingabedaten im offenen Datenaustauschkanal.
Anmerkungen U2.2.
Nachfolgend finden Sie Beispiele für die Umsetzung dieser Bedrohung. и .
U3. Entschlüsselung verschlüsselter Daten durch Personen, die keine rechtmäßigen Datenempfänger sind (Eindringlinge)
Zersetzung
Y3.1. Kompromittierung privater Schlüssel des Empfängers verschlüsselter Daten.
U3.1.1 Link: .
Y3.2. Ersetzung verschlüsselter Daten in einem sicheren Datenaustauschkanal.
U4. Erstellung einer elektronischen Signatur eines rechtmäßigen Unterzeichners unter falschen Daten
Zersetzung
Y4.1. Kompromittierung privater Schlüssel der elektronischen Signatur eines rechtmäßigen Unterzeichners.
U4.1.1 Link: .
Y4.2. Substitution signierter Daten im offenen Datenaustauschkanal.
Hinweis U4.2.
Nachfolgend finden Sie Beispiele für die Umsetzung dieser Bedrohung. и .
U5. Erhalten eines positiven Ergebnisses der Überprüfung der elektronischen Signatur falscher Daten
Zersetzung
Y5.1. Übeltäter fangen im Kanal der Übermittlung der Arbeitsergebnisse die Nachricht über das negative Ergebnis der Prüfung der elektronischen Signatur ab und ersetzen sie durch die Nachricht mit positivem Ergebnis.
Y5.2. Angreifer führen einen Angriff auf das Vertrauen in Signaturzertifikate durch (SZENARIO – alle Elemente sind erforderlich):
U5.2.1. Angreifer generieren einen öffentlichen und einen privaten Schlüssel für eine elektronische Signatur. Wenn das System elektronische Signaturschlüsselzertifikate verwendet, erzeugen sie ein elektronisches Signaturzertifikat, das dem Zertifikat des angeblichen Absenders der Daten, dessen Nachricht sie fälschen wollen, möglichst ähnlich ist.
U5.2.2. Angreifer nehmen unbefugte Änderungen am öffentlichen Schlüsselspeicher vor und verleihen dem von ihnen generierten öffentlichen Schlüssel das erforderliche Maß an Vertrauen und Autorität.
Y5.2.3. Angreifer signieren gefälschte Daten mit einem zuvor generierten elektronischen Signaturschlüssel und betten sie in einen sicheren Datenaustauschkanal ein.
Y5.3. Angreifer führen einen Angriff mit abgelaufenen elektronischen Signaturschlüsseln eines rechtmäßigen Unterzeichners durch (SZENARIO – alle Elemente sind erforderlich):
Y5.3.1. Angreifer kompromittieren die abgelaufenen (derzeit nicht gültigen) privaten Schlüssel der elektronischen Signatur des legitimen Absenders.
Y5.3.2. Angreifer ersetzen die Zeit im Zeitübertragungskanal durch die Zeit, zu der die kompromittierten Schlüssel noch gültig waren.
Y5.3.3. Angreifer signieren gefälschte Daten mit einem zuvor kompromittierten elektronischen Signaturschlüssel und betten sie in einen sicheren Datenaustauschkanal ein.
Y5.4. Angreifer führen einen Angriff mit kompromittierten elektronischen Signaturschlüsseln eines rechtmäßigen Unterzeichners durch (SZENARIO – alle Elemente sind erforderlich):
Y5.4.1. Die Angreifer erstellen eine Kopie des öffentlichen Schlüsselspeichers.
Y5.4.2. Angreifer kompromittieren die privaten Schlüssel eines der legitimen Absender. Er bemerkt die Kompromittierung, widerruft die Schlüssel, Informationen über den Widerruf des Schlüssels werden im öffentlichen Schlüsselspeicher abgelegt.
Y5.4.3. Die Angreifer ersetzen den öffentlichen Schlüsselspeicher durch den zuvor kopierten.
Y5.4.4. Angreifer signieren gefälschte Daten mit einem zuvor kompromittierten elektronischen Signaturschlüssel und betten sie in einen sicheren Datenaustauschkanal ein.
Y5.5. <...> aufgrund des Vorliegens von Fehlern bei der Umsetzung der 2. und 3. Stufe der elektronischen Signaturprüfung:
Erläuterungen Y5.5.
Es wird ein Beispiel für die Umsetzung dieser Bedrohung gegeben .
U5.5.1. Überprüfung des Vertrauens in das Zertifikat des elektronischen Signaturschlüssels nur durch das Vorhandensein von Vertrauen in das Zertifikat, mit dem er signiert wurde, ohne CRL- oder OCSP-Prüfungen.
Erläuterungen Y5.5.1.
Implementierungsbeispiel .
U5.5.2. Beim Aufbau einer Vertrauenskette für ein Zertifikat wird die Autorität der ausstellenden Zertifikate nicht analysiert
Erläuterungen Y5.5.2.
Ein Beispiel für einen Angriff gegen SSL/TLS-Zertifikate.
Die Angreifer kauften ein legitimes Zertifikat für ihre E-Mail. Anschließend erstellten sie ein gefälschtes Website-Zertifikat und signierten es mit ihrem eigenen Zertifikat. Wird die Legitimationsprüfung nicht durchgeführt, stellt sich bei der Überprüfung der Vertrauenskette heraus, dass diese korrekt ist und dementsprechend auch das gefälschte Zertifikat korrekt ist.
Y5.5.3. Beim Aufbau einer Zertifikatsvertrauenskette werden Zwischenzertifikate nicht auf Widerruf überprüft.
Y5.5.4. CRLs werden seltener aktualisiert, als die Zertifizierungsstelle sie ausgibt.
U5.5.5. Die Entscheidung, der elektronischen Signatur zu vertrauen, wird getroffen, bevor die OCSP-Antwort über den Status des Zertifikats empfangen wird, und zwar auf eine Anfrage, die später als zum Zeitpunkt der Signaturerstellung oder früher als die nächste nach Erhalt der CRL-Signatur gestellt wird.
Erläuterungen Y5.5.5.
In den Vorschriften der meisten Zertifizierungsstellen gilt als Zertifikatssperrzeitpunkt der Zeitpunkt der Ausstellung der nächstgelegenen CRL, die Informationen über die Sperrung des Zertifikats enthält.
U5.5.6. Beim Empfang signierter Daten wird die Inhaberschaft des Zertifikats beim Absender nicht überprüft.
Erläuterungen Y5.5.6.
Angriffsbeispiel. Bei SSL-Zertifikaten wird möglicherweise nicht überprüft, ob die Adresse des angerufenen Servers mit dem Wert des CN-Felds im Zertifikat übereinstimmt.
Angriffsbeispiel. Die Angreifer haben die elektronischen Signaturschlüssel eines der Teilnehmer des Zahlungssystems kompromittiert. Danach hackten sie das Netzwerk eines anderen Teilnehmers und schickten in seinem Namen mit kompromittierten Schlüsseln signierte Zahlungsdokumente an den Abrechnungsserver des Zahlungssystems. Wenn der Server nur Vertrauen analysiert und nicht auf Konformität prüft, gelten betrügerische Dokumente als legitim.
U6. Fehlerhafte Annahme elektronischer Dokumente zur Ausführung aufgrund von Problemen bei der Organisation des elektronischen Dokumentenmanagements.
Zersetzung
U6.1. Die empfangende Partei erkennt keine Duplikate der empfangenen Dokumente.
Erläuterungen Y6.1.
Angriffsbeispiel. Übeltäter können das an den Empfänger übermittelte Dokument, auch wenn es kryptografisch geschützt ist, abfangen und es dann wiederholt an den sicheren Datenübertragungskanal senden. Wenn der Empfänger keine Duplikate erkennt, werden alle empfangenen Dokumente als unterschiedliche Dokumente wahrgenommen und verarbeitet.
U7. Unbefugter Zugriff auf geschützte Daten während ihrer Verarbeitung durch CIPF
Zersetzung
U7.1. <…> aufgrund von Informationslecks über Kanäle Dritter (Seitenkanalangriff).
Erläuterungen Y7.1.
Beispiel .
U7.2. <...> aufgrund der Neutralisierung des Schutzes vor unbefugtem Zugriff auf auf CIPF verarbeitete Informationen:
Y7.2.1. Betrieb von CIPF mit Verstößen gegen die in der Dokumentation für CIPF beschriebenen Anforderungen.
Y7.2.2. <…> implementiert aufgrund des Vorhandenseins von Schwachstellen in:
Y7.2.2.1. <…> Mittel zum Schutz vor unbefugtem Zugriff.
Y7.2.2.2. <…> das CIPF selbst.
Y7.2.2.3. <...> die Umgebung für das Funktionieren des kryptografischen Tools.
Angriffsbeispiele
Die im Folgenden diskutierten Szenarien enthalten offensichtlich Fehler in der Organisation der Informationssicherheit und dienen lediglich der Veranschaulichung möglicher Angriffe.
Szenario 1. Ein Beispiel für die Implementierung der Bedrohungen U2.2 und U4.2.
Beschreibung des Objekts
Die ARM-KBR-Software und die CIPF-SCAD-Signatur werden auf einem physischen Computer installiert, der nicht mit einem Computernetzwerk verbunden ist. Der FKN vdToken wird im Betriebsmodus mit nicht abrufbarem Schlüssel als Schlüsselträger verwendet.
Die Abwicklungsordnung geht davon aus, dass der Abwicklungsspezialist von seinem Arbeitsrechner elektronische Nachrichten im Klartext (das Schema des alten KBR AWS) von einem speziellen sicheren Dateiserver herunterlädt, diese dann auf einen entfernbaren USB-Stick schreibt und an den KBR AWP überträgt , wo sie verschlüsselt und signiert werden. Anschließend überträgt der Spezialist sichere elektronische Nachrichten auf ein übertragbares Medium und schreibt sie dann über seinen Arbeitscomputer auf einen Dateiserver, von wo aus sie an UTA und dann an das Zahlungssystem der Bank von Russland gelangen.
In diesem Fall umfassen die Kanäle für den Austausch offener und sicherer Daten: einen Dateiserver, einen Arbeitscomputer eines Spezialisten und ein übertragbares Medium.
Angriff
Unbefugte Angreifer installieren ein Fernsteuerungssystem auf dem Arbeitscomputer des Spezialisten und tauschen bei der Aufzeichnung von Zahlungsaufträgen (elektronischen Nachrichten) auf dem Übertragungsmedium den Inhalt eines davon offen aus. Der Spezialist übermittelt die Zahlungsaufträge an die AWS des KBR, signiert und verschlüsselt sie, ohne die Ersetzung zu bemerken (z. B. aufgrund der großen Anzahl von Zahlungsaufträgen auf dem Flug, Müdigkeit usw.). Danach gelangt der gefälschte Zahlungsauftrag, nachdem er die technologische Kette durchlaufen hat, in das Zahlungssystem der Bank von Russland.
Szenario 2. Ein Beispiel für die Implementierung der Bedrohungen U2.2 und U4.2.
Beschreibung des Objekts
Ein Computer mit installiertem AWS KBR, SKAD-Signatur und einem angeschlossenen Schlüsselträger FKN vdToken wird in einem dafür vorgesehenen Raum ohne Zugang des Personals betrieben.
Der Abwicklungsspezialist verbindet sich im Fernzugriffsmodus über das RDP-Protokoll mit dem AWS des KBR.
Angriff
Angreifer fangen die Daten ab, mit denen sich der Abwicklungsspezialist mit dem KBR-Automatenarbeitsplatz verbindet und mit ihm arbeitet (z. B. aufgrund von Schadcode auf seinem Computer). Dann verbinden sie sich in seinem Namen und senden einen gefälschten Zahlungsauftrag an das Zahlungssystem der Bank von Russland.
Szenario 3. Ein Beispiel für die Umsetzung der Bedrohung U1.3.
Beschreibung des Objekts
Betrachten wir eine der hypothetischen Optionen zur Implementierung der ABS-KBR-Integrationsmodule für das neue Schema (ARM KBR-N), bei dem die elektronische Signatur ausgehender Dokumente auf der Seite des ABS erfolgt. Gleichzeitig gehen wir davon aus, dass das ABS auf einem Betriebssystem basiert, das nicht von der CIPF SKAD-Signatur unterstützt wird, und dementsprechend die kryptografische Funktionalität auf einer separaten virtuellen Maschine platziert wird – dem ABS-CBR-Integrationsmodul .
Als Schlüsselträger wird ein normaler USB-Token im Wechselschlüsselmodus verwendet. Als der Schlüsselträger mit dem Hypervisor verbunden wurde, stellte sich heraus, dass im System keine freien USB-Anschlüsse vorhanden waren. Daher wurde beschlossen, den USB-Token über einen Netzwerk-USB-Hub anzuschließen und einen USB-over-IP-Client darauf zu installieren virtuelle Maschine, die mit dem Hub kommuniziert.
Angriff
Die 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 einem privaten Schlüssel generierten die Angreifer einen gefälschten Zahlungsauftrag, signierten ihn mit einer elektronischen Signatur und schickten ihn zur Ausführung an den automatisierten Arbeitsplatz KBR-N.
Szenario 4. Ein Beispiel für die Umsetzung von Bedrohungen U5.5.
Beschreibung des Objekts
Betrachten Sie die gleiche Schaltung wie im vorherigen Szenario. Wir gehen davon aus, dass E-Mails, die von der KBR-N-Workstation kommen, im Ordner …SHAREIn landen und E-Mails, die an die KBR-N-Workstation und weiter an das Zahlungssystem der Bank von Russland gesendet werden, in …SHAREout landen.
Wir gehen außerdem davon aus, dass bei der Implementierung des Integrationsmoduls die Listen der widerrufenen Zertifikate nur aktualisiert werden, wenn kryptografische Schlüssel erneut ausgegeben werden, und dass im Ordner …SHAREIn empfangene elektronische Nachrichten nur auf Integritätskontrolle und Vertrauenskontrolle zum öffentlichen Schlüssel von überprüft werden die elektronische Signatur.
Angriff
Mithilfe der im vorherigen Szenario gestohlenen Schlüssel unterzeichneten die Angreifer einen gefälschten Zahlungsauftrag mit Informationen über den Geldeingang auf dem Konto eines betrügerischen Kunden und führten ihn in einen sicheren Datenaustauschkanal ein. Da es keine Überprüfung gibt, ob der Zahlungsauftrag von der Bank von Russland unterzeichnet wurde, wird er zur Ausführung angenommen.
Source: habr.com