Informationssicherheit von Bankguthaben. Teil 8 - Typische Bedrohungsmodelle

  • Tutorial

Welche Forschung

Links zu anderen Teilen der Studie


Dieser Artikel vervollständigt den Publikationszyklus, der die Informationssicherheit von bargeldlosen Bankzahlungen gewährleistet. Hier betrachten wir typische Bedrohungsmodelle, die im Basismodell referenziert wurden :


HABRO-WARNUNG !!! Lieber Habrovchane, das ist kein Unterhaltungsposten.
Versteckt unter den über 40 Seiten mit Materialien, die die Arbeit oder die Schule von Personen erleichtern, die auf Bank- oder Informationssicherheit spezialisiert sind. Diese Materialien sind das Endprodukt der Studie und sind in einem trockenen offiziellen Ton geschrieben. Im Wesentlichen handelt es sich dabei um Leerzeichen für interne Sicherheitsdokumente.

Nun, das Traditionelle - "Die Verwendung von Informationen aus dem Artikel für illegale Zwecke ist strafbar . " Produktives Lesen!

Informationen für Leser, die mit der Studie vertraut sind, beginnend mit dieser Veröffentlichung.

Welche Forschung


Sie lesen den Leitfaden des Spezialisten, der für die Informationssicherheit der Zahlungen in der Bank verantwortlich ist.

Die Logik der Präsentation

Am Anfang von Teil 1 und Teil 2 wird der Schutzgegenstand beschrieben. In Teil 3 wird beschrieben, wie ein Schutzsystem erstellt wird, und es wird erläutert, dass ein Bedrohungsmodell erstellt werden muss. In Teil 4 wird beschrieben , welche Modelle sind die Gefahren und wie sie gebildet werden. In Teil 5 und Teil 6 bietet eine Analyse der tatsächlichen Angriffe. Teil 7 und Teil 8 enthalten eine Beschreibung des Bedrohungsmodells, die auf den Informationen aller vorherigen Teile basiert.


TYPISCHES MODELL DER GEFAHR. NETZWERKVERBINDUNG


Schutzobjekt, auf das das Bedrohungsmodell angewendet wird (Geltungsbereich)


Das Schutzobjekt sind Daten, die über eine Netzwerkverbindung übertragen werden, die in Datennetzwerken betrieben wird, die auf Basis des TCP / IP-Stacks aufgebaut sind.

Architektur



Beschreibung der architektonischen Elemente:

  • "Endknoten" sind Knoten, die geschützte Informationen austauschen.
  • "Intermediate Nodes" - Elemente eines Datenübertragungsnetzes: Router, Switches, Zugriffsserver, Proxyserver und andere Geräte, über die der Verkehr einer Netzwerkverbindung übertragen wird. Im Allgemeinen kann eine Netzwerkverbindung ohne Zwischenknoten (direkt zwischen den Endknoten) funktionieren.

Sicherheitsbedrohungen der obersten Ebene


Zerlegung

U1. Unerlaubtes Kennenlernen der übertragenen Daten.
Y2. Unerlaubte Änderung der übermittelten Daten.
Y3 Verletzung der Urheberschaft der übermittelten Daten.

U1. Unerlaubtes Kennenlernen der übertragenen Daten


Zersetzung am
1.1. <...> an Terminal- oder Zwischenknoten durchgeführt:
1.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 1.1.1.1.
Zum Beispiel während der Verarbeitung des Netzwerkstapelknotens.

D1.1.1.2. <...> im nichtflüchtigen Speicher.
Erläuterungen zu 1.1.1.2.
Zum Beispiel, wenn übertragene Daten im Cache, in temporären Dateien oder Paging-Dateien gespeichert werden.

D1.2. <...> auf Knoten von Drittanbieter-Datenübertragungsnetzen durchgeführt:
D1.2.1. <...> Methode zum Erfassen aller Pakete, die auf die Netzwerkschnittstelle des Knotens fallen:
Erläuterungen zu D1.2.1.
Alle Pakete werden erfasst, indem die Netzwerkkarte in den Promiscuous-Modus versetzt wird (Promiscuous-Modus für Kabeladapter oder Überwachungsmodus für WLAN-Adapter).

D1.2.2. <...> durch Man-in-the-Middle-Angriffe (MiTM), ohne jedoch die übertragenen Daten zu verändern (ohne den Overhead der Netzwerkprotokolle zu berücksichtigen).
D1.2.2.1. Referenz: „Typisches Bedrohungsmodell. Netzwerkverbindung Y2. Nicht autorisierte Änderung der übertragenen Daten . "

H1.3. <...>, ausgeführt aufgrund von Informationsverlust auf technischen Kanälen (TKUI) von physischen Knoten oder Kommunikationsleitungen.

D1.4. <...>, zur Installation an den Endknoten oder Zwischenknoten spezieller technischer Mittel (ITS), die für die Abfrage verdeckter Informationen bestimmt sind.

Y2. Unerlaubte Änderung der übermittelten Daten


Zersetzung
U2.1. <...> an Terminal- oder Zwischenknoten durchgeführt:
D2.1.1. <...> durch Lesen und Ändern der Daten, während sich diese in den Speichereinheiten der Knoten befinden:
У 2.1.1.1. <...> im Speicher:
У2.1.1.2. <...> im nichtflüchtigen Speicher:

U2.2. <...>, die auf Knoten von Datenübertragungsnetzwerken von
Drittanbietern ausgeführt werden: У2.2.1. <...> durch
Starten von Man-in-the-Middle-Angriffen (MiTM) und Umleiten des Verkehrs an den Knoten des Angreifers: У2.2.1.1. Physikalische Verbindung von Eindringlingen in der Netzwerkverbindungslücke.
U2.2.1.2. Die Implementierung von Angriffen auf Netzwerkprotokolle:
U2.2.1.2.1. <...> VLAN-
Management : V2.2.1.2.1.1.VLAN-Sprung .
U2.2.1.2.1.2. Nicht autorisierte Änderung der VLAN-Einstellungen an Switches oder Routern.
U2.2.1.2.2. <...> Verkehrslenkung:
D2.2.1.2.2.1. Nicht autorisierte Änderung der statischen Routingtabellen von Routern.
U2.2.1.2.2.2. Die Angreifer kündigten betrügerische Routen über dynamische Routing-Protokolle an.
U2.2.1.2.3. <...> automatische Konfiguration:
U2.2.1.2.3.1. Rogue DHCP .
U2.2.1.2.3.2. Schurke WPAD .
U2.2.1.2.4. <...> Adressierung und Namensauflösung:
U2.2.1.2.4.1. ARP-Spoofing .
U2.2.1.2.4.2. Spoofing das DNS .
U2.2.1.2.4.3. Nicht autorisierte Änderungen an lokalen Host-Namensdateien (Hosts, lmhosts usw.) vornehmen

Y3 Verletzung der Datenübertragung


Zersetzung
Q3.1. Neutralisierung von Mechanismen zur Bestimmung der Urheberschaft von Informationen durch Angabe falscher Informationen über den Urheber oder die Datenquelle:
D3.1.1. Ändern Sie die Informationen zum Autor, die in den übermittelten Informationen enthalten sind.
V3.1.1.1. Neutralisierung des kryptografischen Schutzes der Integrität und Urheberschaft der übermittelten Daten:
U3.1.1.1.1. Referenz: "Typisches Bedrohungsmodell". Das System des kryptographischen Schutzes von Informationen.
E4 Erstellung einer elektronischen Unterschrift eines rechtmäßigen Unterzeichners unter falschen Angaben “
.
V3.1.1.2. Neutralisierung des Schutzes der Urheberschaft der übermittelten Daten, implementiert mit einmaligen Bestätigungscodes:
D3.1.1.2.1. Die Swap - SIM .

Q3.1.2. Informationen zur übermittelten Informationsquelle ändern:
Q3.1.2.1. IP-Spoofing .
Q3.1.2.2. MAC-Spoofing .



TYPISCHES MODELL DER GEFAHR. INFORMATIONSSYSTEM AUFGRUND DES ARCHITEKTUR-CLIENT-SERVERS


Schutzobjekt, auf das das Bedrohungsmodell angewendet wird (Geltungsbereich)


Das Schutzobjekt ist ein Informationssystem, das auf Basis der Client-Server-Architektur aufgebaut ist.

Architektur


Beschreibung der architektonischen Elemente:

  • "Client" ist das Gerät, auf dem der Client Teil des Informationssystems ist.
  • "Server" ist das Gerät, auf dem der Serverteil des Informationssystems arbeitet.
  • "Data Warehouse" ist ein Teil der Serverinfrastruktur des Informationssystems, die zum Speichern von Daten bestimmt ist, die vom Informationssystem verarbeitet werden.
  • "Netzwerkverbindung" - ein Kanal für den Informationsaustausch zwischen Client und Server, der ein Datennetz durchläuft. Eine detailliertere Beschreibung des Elementmodells finden Sie im Abschnitt „Typisches Bedrohungsmodell. Die Netzwerkverbindung " .

Einschränkungen
Beim Modellieren eines Objekts werden die folgenden Einschränkungen festgelegt:

  1. Der Benutzer interagiert mit dem Informationssystem in endlichen Zeitintervallen, so genannten Arbeitssitzungen.
  2. Zu Beginn jeder Sitzung wird der Benutzer identifiziert, authentifiziert und autorisiert.
  3. Alle geschützten Informationen werden auf der Serverseite des Informationssystems gespeichert.

Sicherheitsbedrohungen der obersten Ebene


Zerlegung
U1. Täter unberechtigter Handlungen im Namen eines rechtmäßigen Benutzers.
Y2. Nicht autorisierte Änderung der geschützten Informationen während der Verarbeitung durch den Serverteil des Informationssystems.

U1. Täter unberechtigter Handlungen im Namen eines rechtmäßigen Benutzers


Erläuterungen In der
Regel korrelieren Informationssysteme mit dem Benutzer, der sie ausgeführt hat, mit:

  1. Systemprotokolle (Protokolle).
  2. Spezielle Attribute von Datenobjekten, die Informationen über den Benutzer enthalten, der sie erstellt oder geändert hat.

In Bezug auf die Sitzung kann diese Bedrohung in Folgendes zerlegt werden:

  1. <...> wird als Teil einer Benutzersitzung durchgeführt.
  2. <...> wird außerhalb der Benutzersitzung ausgeführt.

Benutzersitzung kann initiiert werden von:

  1. Vom Benutzer
  2. Eindringlinge

Zu diesem Zeitpunkt sieht die folgende Zersetzung dieser Bedrohung folgendermaßen aus:
1.1. Nicht autorisierte Aktionen wurden im Rahmen der Benutzersitzung ausgeführt:
1.1.1. <...> vom angegriffenen Benutzer festgelegt.
D1.1.2. <...> von Eindringlingen installiert.
D1.2. Nicht autorisierte Aktionen, die außerhalb der Benutzersitzung ausgeführt werden.

Unter dem Gesichtspunkt von Informationsinfrastruktureinrichtungen, die von Eindringlingen betroffen sein können, sieht die Zerlegung von Zwischenbedrohungen folgendermaßen aus:
Artikel Bedrohung Zersetzung
D1.1.1. D1.1.2. D1.2.
Kunde D1.1.1.1. D1.1.2.1.
Netzwerkverbindung D1.1.1.2.
Server D1.2.1.

Zersetzung am
1.1. Nicht autorisierte Aktionen wurden im Rahmen der Benutzersitzung ausgeführt:
1.1.1. <...> vom angegriffenen Benutzer eingestellt:
W1.1.1.1. Die Eindringlinge handelten unabhängig vom Kunden:
A1.1.1.1.1 Die Eindringlinge verwendeten die üblichen
Zugangsmittel zum Informationssystem: A1.1.1.1.1.1. Die Angreifer nutzten die physische E / A des Clients (Tastatur, Maus, Monitor oder Touchscreen eines mobilen Geräts):
1.1.1.1.1.1.1. Die Angreifer handelten während der Zeiträume, in denen die Sitzung aktiv ist, E / A-Funktionen zur Verfügung stehen und der Benutzer nicht eingerichtet ist.
1.1.1.1.1.2. Die Angreifer verwendeten Remote-Verwaltungstools (regelmäßig oder durch schädlichen Code bereitgestellt), um den Client zu steuern:
1.1.1.1.1.2.1. Die Angreifer handelten während der Zeiträume, in denen die Sitzung aktiv ist, E / A-Funktionen zur Verfügung stehen und der Benutzer nicht eingerichtet ist.
U1.1.1.1.1.2.2. Die Angreifer verwendeten Remoteverwaltungstools, deren Arbeit für den angegriffenen Benutzer nicht sichtbar ist.
D1.1.1.2. Die Angreifer ersetzten Daten in der Netzwerkverbindung zwischen dem Client und dem Server und modifizierten sie so, dass sie von einem legitimen Benutzer als Aktionen wahrgenommen wurden:
U1.1.1.2.1. Referenz: "Typisches Bedrohungsmodell". Netzwerkverbindung Y2. Nicht autorisierte Änderung der übertragenen Daten . "
D1.1.1.3. Übeltäter zwangen den Benutzer, die von ihm angegebenen Aktionen mit Methoden des Social Engineering auszuführen.

D1.1.2 <...> von Hackern installiert:
D1.1.2.1. Die Eindringlinge handelten vom Kunden ( I ) aus:
D1.1.2.1.1. Die Angreifer neutralisierten das Zugangskontrollsystem des Informationssystems:
1.1.2.1.1.1. Referenz: „Typisches Bedrohungsmodell. Zugangskontrollsystem. U1. Nicht autorisierte Einrichtung einer Sitzung für einen legitimen Benutzer . "
D1.1.2.1.2. Übeltäter benutzten regelmäßig Zugangswege des Informationssystems
D1.1.2.2. Die Angreifer handelten von anderen Knoten des Datenübertragungsnetzes aus, von denen aus eine Netzwerkverbindung mit dem Server ( I ) hergestellt werden kann:
D1.1.2.2.1. Die Angreifer neutralisierten das Zugangskontrollsystem des Informationssystems:
D1.1.2.2.1.1. Referenz:„Typisches Bedrohungsmodell. Zugangskontrollsystem. U1. Nicht autorisierte Einrichtung einer Sitzung für einen legitimen Benutzer . "
D1.1.2.2.2. Die Angreifer verwendeten nicht standardisierte Zugangsinformationssysteme.
Klarstellungen D1.1.2.2.2.
Die Angreifer könnten einen regulären Client des Informationssystems auf einem Host eines Drittanbieters installieren oder eine nicht standardisierte Software verwenden, die regelmäßige Kommunikationsprotokolle zwischen dem Client und dem Server implementiert.

U1.2 Nicht autorisierte Aktionen, die außerhalb der Sitzung des Benutzers ausgeführt werden.
U1.2.1 Die Angreifer führten nicht autorisierte Aktionen aus und nahmen dann unbefugte Änderungen an den Betriebsprotokollen des Informationssystems oder an speziellen Attributen von Datenobjekten vor, um anzuzeigen, dass die von ihnen ausgeführten Aktionen von einem rechtmäßigen Benutzer ausgeführt wurden.

Y2. Nicht autorisierte Änderung der geschützten Informationen während der Verarbeitung durch den Serverteil des Informationssystems


Zersetzung
U2.1. Die Angreifer modifizieren die geschützten Informationen mit den Standardmitteln des Informationssystems und führen sie im Auftrag des rechtmäßigen Benutzers durch.
B2.1.1. Referenz: „Typisches Bedrohungsmodell. Informationssystem auf Basis der Client-Server-Architektur. U1. Täter von nicht autorisierten Handlungen im Namen eines rechtmäßigen Benutzers .

Y2.2. Die Angreifer modifizieren die geschützten Informationen, indem sie Datenzugriffsmechanismen verwenden, die nicht im Standardbetriebsmodus des Informationssystems vorgesehen sind.
U2.2.1. Übeltäter modifizieren die Dateien, die die geschützten Informationen enthalten:
У2.2.1.1. <...> mit den vom Betriebssystem bereitgestellten Dateibehandlungsmechanismen.
U2.2.1.2. <...> durch die Wiederherstellung von Dateien aus einer nicht autorisierten, modifizierten Sicherung.

Y2.2.2. Kriminelle modifizieren die in der Datenbank gespeicherten geschützten Informationen ( I ):
У2.2.2.1. Die Angreifer neutralisieren das Zugangskontrollsystem DBMS:
U2.2.2.1.1. Referenz: "Typisches Bedrohungsmodell". Zugangskontrollsystem. U1. Nicht autorisierte Einrichtung einer Sitzung für einen legitimen Benutzer . "
U2.2.2.2. Überträger modifizieren die Informationen und verwenden reguläre Schnittstellen eines DBMS für den Datenzugriff.

Y2.3. Die Angreifer modifizieren die geschützten Informationen durch unbefugte Modifikation der Algorithmen der sie verarbeitenden Software.
U2.3.1. Der Quellcode der Software wird geändert.
U2.3.1. Modifizierter Softwarecode ist verfügbar.

Y2.4. Übeltäter modifizieren die geschützten Informationen unter Verwendung von Schwachstellen in der Software des Informationssystems.

Y2.5. Überträger modifizieren die geschützten Informationen während der Übertragung zwischen den Komponenten des Serverteils des Informationssystems (z. B. Datenbankserver und Anwendungsserver):
У2.5.1. Referenz: "Typisches Bedrohungsmodell". Netzwerkverbindung Y2. Nicht autorisierte Änderung der übertragenen Daten . "



TYPISCHES MODELL DER GEFAHR. ZUGRIFFSBEGRENZUNGSSYSTEM


Schutzobjekt, auf das das Bedrohungsmodell angewendet wird (Geltungsbereich)


Das Schutzobjekt, für das dieses Bedrohungsmodell angewendet wird, entspricht dem Schutzobjekt für das Bedrohungsmodell: „Typisches Bedrohungsmodell. Informationssystem auf Basis der Client-Server-Architektur. “

Das System der Abgrenzung des Benutzerzugriffs in diesem Bedrohungsmodell bedeutet eine Komponente eines Informationssystems, das die Funktionen implementiert:

  1. Benutzeridentifikation
  2. Benutzerauthentifizierung
  3. Benutzerberechtigung
  4. Benutzeraktionen protokollieren

Sicherheitsbedrohungen der obersten Ebene


Zerlegung
U1. Nicht autorisierte Einrichtung einer Sitzung für einen legalen Benutzer.
Y2. Unerlaubte Erhöhung von Benutzerrechten im Informationssystem.

U1. Nicht autorisierte Einrichtung einer Sitzung für einen legalen Benutzer


Erläuterungen Die
Zerlegung dieser Bedrohung hängt im Allgemeinen von der Art der verwendeten Benutzeridentifizierungs- und Authentifizierungssysteme ab.

In diesem Modell wird nur das Benutzeridentifizierungs- und Authentifizierungssystem mit Textanmeldung und Kennwort berücksichtigt. In diesem Fall gehen wir davon aus, dass es sich bei dem Benutzernamen um öffentlich zugängliche Informationen handelt, die Angreifern bekannt sind.

Zersetzung am
1.1. <...> aufgrund von
angegriffenen Anmeldeinformationen: D1.1.1. Angreifer haben während der Speicherung die Anmeldeinformationen der Benutzer beeinträchtigt.
Erläuterungen D1.1.1.
Beispielsweise könnten Anmeldeinformationen auf einen Aufkleber geschrieben werden, der auf einem Monitor eingefügt wird.

D1.1.2. Der Benutzer hat Angreifern versehentlich oder in böswilliger Absicht Zugangsdaten gegeben.
D1.1.2.1. Der Benutzer hat die Berechtigungsnachweise beim Tippen laut vorgetragen.
D1.1.2.2. Der Benutzer hat seine Anmeldeinformationen absichtlich übermittelt:
D1.1.2.2.1. <...> an Kollegen.
Klarstellungen D1.1.2.2.1.
Zum Beispiel, damit sie es für die Dauer der Krankheit ersetzen können.

D1.1.2.2.2. <...> an die Geschäftspartner des Arbeitgebers, die an Objekten der Informationsinfrastruktur arbeiten.
D1.1.2.2.3. <...> an Dritte weitergeben.
Klarstellungen D1.1.2.2.3.
Eine, aber nicht die einzige Möglichkeit, diese Bedrohung zu implementieren, ist der Einsatz von Social-Engineering-Methoden durch Hacker.

D1.1.3. Die Angreifer haben die Anmeldeinformationen
mithilfe einer Suchmethode ausgewählt: D1.1.3.1. <...> mit Standardzugriffsmechanismen.
D1.1.3.2. <...> von zuvor abgefangenen Codes (zum Beispiel Passwort-Hashes) zum Speichern von Anmeldeinformationen.

D1.1.4. Angreifer verwendeten bösartigen Code, um Benutzerdaten abzufangen.

H1.1.5. Die Angreifer haben die Anmeldeinformationen aus der Netzwerkverbindung zwischen dem Client und dem Server entfernt:
1.1.5.1. Referenz: „Typisches Bedrohungsmodell. Netzwerkverbindung U1. Unerlaubtes Kennenlernen der übertragenen Daten . "

D1.1.6. Die Angreifer haben die Berechtigungsnachweise aus den Datensätzen der
Arbeitsüberwachungssysteme entfernt : D1.1.6.1. <...> Videoüberwachungssysteme (falls während des Betriebs Tastenanschläge auf der Tastatur aufgetreten sind).
D1.1.6.2. <...> Systeme zur Überwachung von Mitarbeiteraktionen hinter einem Computer
Erklärungen D1.1.6.2.
Ein Beispiel für ein solches System ist StuffCop .

D1.1.7. Angreifer haben die Anmeldeinformationen der Benutzer aufgrund der Mängel des Übertragungsprozesses beeinträchtigt.
Erläuterungen D1.1.7.
Zum Beispiel die Übermittlung von Passwörtern in übersichtlicher Form per E-Mail.

D1.1.8. Die Angreifer lernten die Anmeldeinformationen, indem sie die Sitzung des Benutzers mit Remote-Verwaltungssystemen überwachten.

1.1.9. Die Angreifer konnten ihre Berechtigungsnachweise aufgrund ihres
Durchsuchens durch technische Kanäle (TCIS) wiederherstellen : 1.1.9.1. Die Angreifer haben gesehen, wie der Benutzer die Anmeldeinformationen über die Tastatur
eingibt : 1.1.9.1.1 Die Angreifer befanden sich in unmittelbarer Nähe des Benutzers und sahen die eingegebenen Anmeldeinformationen mit eigenen Augen.
Klarstellungen W1.1.9.1.1
Solche Fälle können die Aktionen von Arbeitskollegen oder den Fall umfassen, wenn die Tastatur des Benutzers für Besucher der Organisation sichtbar ist.

D1.1.9.1.2 Die Angreifer verwendeten zusätzliche technische Hilfsmittel wie Ferngläser oder unbemannte Luftfahrzeuge und sahen die Eingabe von Ausweisen durch ein Fenster.
D1.1.9.2. Die Angreifer haben die Berechtigungsnachweise aus den Aufzeichnungen des Funkgeräts zwischen der Tastatur und der Systemeinheit des Computers entfernt, wenn sie über die Funkschnittstelle verbunden werden (z. B. Bluetooth).
D1.1.9.3. Die Angreifer führten das Abfangen von Berechtigungsnachweisen durch, da sie durch den Kanal unerwünschte elektromagnetische Strahlung und Interferenz (PEMIN) ableiteten.
Erläuterungen D.1.1.3.3.
Beispiele für Angriffe hier und hier .

1.1.9.4. Der Angreifer hat die Eingabe von Anmeldeinformationen über die Tastatur mithilfe spezieller technischer Mittel (ITS) abgefangen, die für das Abrufen verdeckter Informationen ausgelegt sind.
Erläuterungen D.1.1.4.4.
Beispiele für Geräte .

1.1.9.5. Die Angreifer haben die Eingabe von Anmeldeinformationen über die Tastatur abgefangen, indem
sie das Wi-Fi-Signal analysiert haben, das vom Benutzer durch den Tastenanschlag moduliert wird.
Erläuterungen D.1.1.5.
Ein Beispiel für einen Angriff .

D1.1.9.6. Die Angreifer haben die Eingabe von Anmeldeinformationen über die Tastatur abgefangen, indem sie die Geräusche von Tastatureingaben analysieren.
Klarstellungen W1.1.9.6.
Ein Beispiel für einen Angriff .

W1.1.9.7. Die Angreifer haben die Eingabe von Anmeldeinformationen über die Tastatur des mobilen Geräts abgefangen, indem sie die Messwerte des Beschleunigungsmessers analysiert haben.
Klarstellungen W1.1.9.7.
Ein Beispiel für einen Angriff .

D1.1.10. <...> zuvor auf dem Client gespeichert.
Erläuterungen D.1.1.10.
Beispielsweise könnte ein Benutzer im Browser Login und Passwort speichern, um auf eine bestimmte Site zuzugreifen.

D1.1.11. Angreifer haben Anmeldeinformationen aufgrund von Fehlern beim Sperren des Benutzerzugriffs beeinträchtigt.
Erklärung D1.1.11.
Nach der Kündigung des Benutzers wurden seine Benutzerkonten beispielsweise nicht gesperrt.

D1.2. <...> durch Ausnutzen von Schwachstellen im Zugangskontrollsystem.

Y2. Unerlaubte Erhöhung von Benutzerrechten im Informationssystem


Zerlegung von
U2.1 <...> durch unbefugte Änderungen an Daten, die Informationen zu den Berechtigungen des Benutzers enthalten.

U2.2 <...> aufgrund der Verwendung von Schwachstellen im Zugangskontrollsystem.

Y2.3. <...> aufgrund der Mängel des Benutzerzugriffssteuerungsprozesses.
Erläuterungen D2.3.
Beispiel 1. Dem Benutzer für die Arbeit wurde ein größerer Zugriff gewährt, als er für geschäftliche Anforderungen benötigt.
Beispiel 2. Nachdem ein Benutzer an eine andere Stelle übertragen wurde, wurden die zuvor gewährten Zugriffsrechte nicht widerrufen.



TYPISCHES MODELL DER GEFAHR. INTEGRATIONSMODUL


Schutzobjekt, auf das das Bedrohungsmodell angewendet wird (Geltungsbereich)


Das Integrationsmodul ist eine Gruppe von Informationsinfrastrukturobjekten, die den Informationsaustausch zwischen Informationssystemen organisieren sollen.

Da es in Unternehmensnetzwerken nicht immer möglich ist, ein Informationssystem eindeutig von einem anderen zu trennen, kann das Integrationsmodul auch als Verbindung zwischen den Komponenten innerhalb eines Informationssystems betrachtet werden.

Architektur Das
allgemeine Schema des Integrationsmoduls sieht wie folgt aus:



Beschreibung der architektonischen Elemente:

  • "Exchange Server (CO)" ist ein Knoten / Dienst / eine Komponente eines Informationssystems, das die Funktion des Datenaustauschs mit einem anderen Informationssystem ausführt.
  • „Vermittler“ ist ein Knoten / Dienst, der zur Organisation der Interaktion zwischen Informationssystemen vorgesehen ist, jedoch nicht in deren Zusammensetzung enthalten ist.
    Beispiele für "Intermediaries" sind E-Mail-Dienste, Enterprise Service-Busse (Enterprise Service Bus / SoA-Architektur), Dateiserver von Drittanbietern usw. Im Allgemeinen enthält das Integrationsmodul möglicherweise keine "Intermediaries".
  • "Datenverarbeitungssoftware" ist ein Satz von Programmen, der Datenaustauschprotokolle und Formatkonvertierungen implementiert.
    Zum Beispiel die Konvertierung von Daten aus dem UBBS-Format in das ABS-Format, die Änderung des Nachrichtenstatus während der Übertragung usw.
  • Die "Netzwerkverbindung" entspricht dem Objekt, das im typischen Bedrohungsmodell für Netzwerkverbindungen beschrieben wird. Einige der Netzwerkverbindungen von den im obigen Diagramm gezeigten sind möglicherweise nicht.


Beispiele für Integrationsmodule

Schema 1. Die Integration des ABS und des automatisierten Arbeitsplatzes der CBD über einen Dateiserver eines Drittanbieters

Um Zahlungen auszuführen, entlädt ein autorisierter Bankangestellter elektronische Zahlungsbelege aus dem ABS und speichert sie in einer Datei (in einem eigenen Format, z. B. SQL-Dump) im Netzwerkordner (\\ ... \ SHARE \) Dateiserver. Diese Datei wird dann mithilfe eines Konverter-Skripts in eine Reihe von Dateien im UBEBS-Format konvertiert, die dann von der AWS der CBD gelesen werden.
Danach verschlüsselt und signiert ein autorisierter Mitarbeiter - der Benutzer des ARM CBR - die empfangene Datei und sendet sie an das Zahlungssystem der Bank of Russia.

Wenn Zahlungen von der Bank of Russia eingehen, führt der ARM CBR die Entschlüsselung und Überprüfung der elektronischen Signatur durch und schreibt sie als Satz von Dateien im UBEBS-Format auf einen Dateiserver. Vor dem Import von Zahlungsbelegen in ABS werden sie mit Hilfe eines Konverter-Skripts vom EBWE-Format in das ABS-Format konvertiert.

Wir gehen davon aus, dass in diesem Schema das ABS auf einem physischen Server arbeitet, die AWS des CBD auf einem dedizierten Computer und der Skriptkonverter auf einem Dateiserver ausgeführt wird.



Die Entsprechung der Objekte des betrachteten Schemas mit den Elementen des Integrationsmodulmodells:
"Exchange- Server durch das ABS" ist der ABS-Server.
"Exchange Server von der ARM CBD" - Computer ARM CBD.
"Mediator" - ein Dateiserver eines Drittanbieters.
"Datenverarbeitungssoftware"- Skriptkonverter.

Schema 2. Integration von ABS und AWS der CBD beim Platzieren eines freigegebenen Netzwerkordners mit Zahlungen in der AWS der CBD

Alles ist dasselbe wie in Abbildung 1, es wird jedoch kein separater Dateiserver verwendet, sondern der Netzwerkordner (\\ ... \ SHARE \) mit elektronischen Zahlungsdokumenten Computer mit ARM CBD. Der Skriptkonverter funktioniert auch auf der AWS CBD.



Übereinstimmung der Objekte des betrachteten Schemas mit den Elementen des Integrationsmodulmodells:
Ähnlich wie in Schema 1, aber der "Mediator" wird nicht verwendet.

Scheme 3. Integration von ABS und AWS CBD-N über IBM WebSphera MQ und Implementierung der Signatur elektronischer Dokumente "auf der Seite des ABS"

ABS arbeitet auf einer Plattform, die nicht von SCZD Signature unterstützt wird. Die Signatur ausgehender elektronischer Dokumente erfolgt auf einem speziellen elektronischen Signaturserver (ES-Server). Auf demselben Server wird die elektronische Signatur anhand von Dokumenten der Bank of Russia überprüft.

Das ABS lädt eine Datei mit Zahlungsbelegen in einem eigenen Format auf den ES-Server hoch.
Der ES-Server konvertiert die Datei mit Hilfe eines Konverter-Skripts in elektronische Nachrichten des Formats UBEBS. Danach werden die elektronischen Nachrichten signiert und an IBM WebSphere MQ übermittelt.

Die AWS CBD-N nimmt mit IBM WebSphere MQ Kontakt auf und empfängt von dort signierte Zahlungsnachrichten, woraufhin ein autorisierter Mitarbeiter - der AWC-Benutzer AWD - diese verschlüsselt und an das Zahlungssystem der Bank of Russia schickt.

Wenn Zahlungen von der Bank of Russia eingehen, entschlüsselt die AWS KBR-N diese und überprüft die elektronische Signatur. Erfolgreich verarbeitete Zahlungen in Form entschlüsselter und signierter elektronischer Nachrichten des UBEBS-Formats werden an IBM WebSphere MQ übermittelt, von wo sie vom ES-Server empfangen werden.

Der ES-Server überprüft die elektronische Signatur eingehender Zahlungen und speichert sie in der Datei des ABS-Formats. Danach lädt ein autorisierter Mitarbeiter - ein ABS-Benutzer - die resultierende Datei in der vorgeschriebenen Weise in das ABS.



Die Entsprechung der Objekte des betrachteten Schemas mit den Elementen des Integrationsmodulmodells:
"Exchange-Server durch das ABS" ist der ABS-Server.
"Exchange Server von der ARM CBD" - Computer ARM CBD.
"Intermediary" - ES Server und IBM WebSphere MQ.
"Datenverarbeitungssoftware"- Skriptkonverter, SKZI SCAD-Signatur auf dem VC-Server.

Scheme 4. Integration des RB- und ABS-Servers über die von einem dedizierten Exchange-Server bereitgestellte API.

Wir gehen davon aus, dass die Bank mehrere Remote-Banking-Service-Systeme (DBOs) verwendet:

  • "Internet Client-Bank" für Einzelpersonen (ICB FL);
  • "Internet Client-Bank" für juristische Personen (ICB LE).

Um die Informationssicherheit zu gewährleisten, erfolgt die gesamte Interaktion des ABS mit den RBS-Systemen über einen dedizierten Exchange-Server, der innerhalb des ABS-Informationssystems arbeitet.

Als Nächstes betrachten wir den Prozess der Interaktion zwischen der DBO IKB LE und dem ABS-System.
Nachdem der RBS-Server einen ordnungsgemäß bestätigten Zahlungsauftrag vom Kunden erhalten hat, sollte er auf seiner Grundlage ein entsprechendes Dokument im ABS erstellen. Dazu überträgt er die API mit Informationen an den Exchange-Server und dieser gibt die Daten in das ABS ein.

Wenn sich die Salden auf dem Kundenkonto ändern, generiert das ABS elektronische Benachrichtigungen, die über den Exchange-Server an den RBS-Server übermittelt werden.



Die Entsprechung der Objekte des betrachteten Schemas mit den Elementen des Integrationsmodulmodells:
"Exchange Server by RB" ist der RB der IKB-UL.
" Serveraustausch durch das ABS" - Serveraustausch.
"Mediator" fehlt.
"Datenverarbeitungssoftware" sind die RBS-Serverkomponenten, die für die Verwendung der Exchange-Server-API verantwortlich sind, die Exchange-Serverkomponenten, die für die Verwendung der ABS-API verantwortlich sind.

Sicherheitsbedrohungen der obersten Ebene


Zerlegung
U1. Die Einführung gefälschter Informationen durch Eindringlinge durch das Integrationsmodul.

U1. Die Einführung falscher Informationen durch die Angreifer über das Integrationsmodul

Zersetzung am
1.1. Nicht autorisierte Änderung legitimer Daten während der Übertragung über Netzwerkverbindungen:
A1.1.1 Referenz: „Typisches Bedrohungsmodell. Netzwerkverbindung Y2. Nicht autorisierte Änderung der übertragenen Daten . "

D1.2. Übertragen falscher Daten über Kommunikationskanäle im Auftrag eines berechtigten Teilnehmers am Austausch:
D1.1.2 Referenz: „Typisches Bedrohungsmodell. Netzwerkverbindung Y3 Verletzung der Urheberschaft der übermittelten Daten .

H1.3. Nicht autorisierte Änderung legitimer Daten, wenn diese auf den Exchange-Servern oder dem Vermittler verarbeitet werden:
D1.3.1. Referenz:„Typisches Bedrohungsmodell. Informationssystem auf Basis der Client-Server-Architektur. Y2. "Nicht autorisierte Änderung der geschützten Informationen während ihrer Verarbeitung durch den Serverteil des Informationssystems" .

D1.4. Erstellen von gefälschten Daten auf den Exchange-Servern oder dem Vermittler im Auftrag des rechtmäßigen Teilnehmers am Austausch:
D1.4.1. Referenz: „Typisches Bedrohungsmodell. Informationssystem auf Basis der Client-Server-Architektur. U1. Täter von nicht autorisierten Handlungen im Namen eines rechtmäßigen Benutzers. “

V1.5. Eigenmächtige Veränderung von Daten während der Verarbeitung mit Datenverarbeitungssoftware:
11.5.1. <...> durch unbefugte Änderungen der Einstellungen (Konfiguration) der Datenverarbeitungssoftware durch die Angreifer.
D1.5.2. <...> durch nicht autorisierte Änderungen von Hackern in die ausführbaren Dateien der Datenverarbeitungssoftware.
D1.5.3. <...> aufgrund der interaktiven Verwaltung von Datenverarbeitungssoftware durch böswillige Benutzer.



TYPISCHES MODELL DER GEFAHR. System des kryptografischen Informationsschutzes


Schutzobjekt, auf das das Bedrohungsmodell angewendet wird (Geltungsbereich)


Der Schutzgegenstand ist ein kryptographischer Schutz von Informationen, die zur Gewährleistung der Sicherheit eines Informationssystems verwendet werden.

Architektur
Die Basis jedes Informationssystems ist die Anwendungssoftware (Software), die ihre Zielfunktionalität implementiert.

Gleichzeitig wird der kryptografische Schutz normalerweise durch Aufrufen von kryptografischen Grundelementen aus der Geschäftslogik der Anwendungssoftware implementiert, die sich in spezialisierten Bibliotheken - Kryptokernen - befinden.

Zu den kryptographischen Grundelementen gehören kryptografische Funktionen auf niedriger Ebene, z.

  • den Datenblock verschlüsseln / entschlüsseln;
  • Erstellen / Prüfen der elektronischen Signatur des Datenblocks;
  • Berechne die Hash-Funktion des Datenblocks;
  • Schlüsselinformationen generieren / hochladen / hochladen;
  • usw.

Die Geschäftslogik der Anwendungssoftware, die kryptografische Grundelemente verwendet, implementiert eine übergeordnete Funktionalität:

  • verschlüsseln Sie die Datei mit den Schlüsseln der ausgewählten Empfänger;
  • Stellen Sie eine sichere Netzwerkverbindung her.
  • über die Ergebnisse der Überprüfung der elektronischen Signatur informieren;
  • usw.

Das Zusammenspiel von Geschäftslogik und Kryptokern kann erfolgen:

  • direkt durch Aufrufen der Geschäftslogik kryptografischer Grundelemente aus den dynamischen Bibliotheken des Kryptokerns (.DLL - für Windows, .SO - für Linux);
  • indirekt über kryptografische Schnittstellen - Wrapper, beispielsweise MS Crypto API, Java Cryptography Architecture, PKCS # 11 usw. In diesem Fall bezieht sich die Geschäftslogik auf die Crypto-Schnittstelle und übersetzt den Aufruf in den entsprechenden Crypto-Core, der in diesem Fall aufgerufen wird Krypto-Anbieter. Durch die Verwendung kryptografischer Schnittstellen kann die Anwendungssoftware von bestimmten kryptographischen Algorithmen abstrahlen und flexibler sein.

Zwei typische Schemata für die Organisation eines Kryptokerns können unterschieden werden:

Schema 1 - Monolithischer Kryptokern


Schema 2 - Getrennter Kryptokern


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 gemäß Schema 1 erstellt wurden, arbeiten die Anwendungssoftware und der Kryptokern im Rahmen einer einheitlichen Umgebung für das Funktionieren von Krypto-Tools (SFC), beispielsweise auf demselben Computer, auf dem dasselbe Betriebssystem ausgeführt wird. Der Benutzer des Systems kann in der Regel andere Programme im Rahmen derselben Betriebsumgebung ausführen, einschließlich solcher, die schädlichen Code enthalten. Unter diesen Bedingungen besteht ein ernstes Risiko, dass geschlossene kryptographische Schlüssel auslaufen.

Um das Risiko zu minimieren, wenden Sie das Schema 2 an, in dem der Cryptokernel in zwei Teile unterteilt ist:

  1. Der erste Teil zusammen mit der Anwendungssoftware arbeitet in einer nicht vertrauenswürdigen Umgebung, in der die Gefahr einer Infektion durch schädlichen Code besteht. Wir nennen diesen Teil "den Softwareteil".
  2. Der zweite Teil arbeitet in einer vertrauenswürdigen Umgebung auf einem dedizierten Gerät, das einen privaten Schlüsselspeicher enthält. Weiter nennen wir diesen Teil "Hardware".

Die Aufteilung eines Kryptokerns in Software und Hardware ist sehr bedingt. Es gibt Systeme auf dem Markt, die nach einem Schema mit einem unterteilten Kryptokernel aufgebaut sind, dessen "Hardware" -Teil jedoch als Image einer virtuellen Maschine dargestellt wird - virtuelles HSM ( Beispiel ).

Das Zusammenspiel beider Teile des Krypto-Kernels erfolgt so, dass die privaten kryptographischen Schlüssel niemals an den Softwareteil übertragen werden und dementsprechend nicht mit Hilfe von Schadcode gestohlen werden können.

Die Interaktionsschnittstelle (API) und der Satz von kryptographischen Grundelementen, die von der Anwendungssoftware für den Kryptokern bereitgestellt werden, sind in beiden Fällen gleich. Der Unterschied liegt in der Art und Weise, wie sie implementiert werden.

Wenn Sie also ein Schema mit einem unterteilten Kryptokernel verwenden, erfolgt das Zusammenspiel von Software und Hardware nach folgendem Prinzip:

  1. Kryptografische Grundelemente, die nicht die Verwendung eines privaten Schlüssels erfordern (z. B. Berechnen einer Hash-Funktion, Prüfen elektronischer Signaturen usw.), werden vom Softwareteil ausgeführt.
  2. Kryptografische Grundelemente, die den privaten Schlüssel verwenden (Erstellen einer elektronischen Signatur, Entschlüsseln von Daten usw.), werden von der Hardware ausgeführt.

Wir veranschaulichen die Arbeit eines unterteilten Kryptokernels am Beispiel der Erstellung einer elektronischen Signatur:

  1. Der Softwareteil berechnet die Hash-Funktion der zu signierenden Daten und gibt diesen Wert über einen Austauschkanal zwischen Kryptokernen an die Hardware weiter.
  2. Die Hardware generiert mit dem privaten Schlüssel und dem Hash den Wert der elektronischen Signatur und überträgt diesen über den Austauschkanal an den Programmteil.
  3. Der Softwareteil gibt den resultierenden Wert an die Anwendungssoftware zurück.

Merkmale der Überprüfung der elektronischen Signatur

Wenn der Empfänger die durch die elektronische Signatur unterzeichneten Daten erhält, muss er mehrere Überprüfungsschritte durchführen. Ein positives Ergebnis der Verifizierung einer elektronischen Signatur wird nur mit dem erfolgreichen Abschluss aller Verifikationsschritte erreicht.

Schritt 1. Kontrollieren Sie die Datenintegrität und die Urheberschaft.

Der Inhalt der Bühne. Eine elektronische Signatur der Daten wird mit dem entsprechenden kryptographischen Algorithmus überprüft. Ein erfolgreicher Abschluss dieser Phase zeigt an, dass die Daten seit ihrer Unterzeichnung nicht geändert wurden, und die Tatsache, dass die Signatur mit einem privaten Schlüssel vorgenommen wurde, der dem öffentlichen Schlüssel der elektronischen Signaturüberprüfung entspricht.
Erfüllungsort: kryptoyadro.

Schritt 2. Kontrollieren Sie das Vertrauen in den öffentlichen Schlüssel des Unterzeichners und die Gültigkeit des privaten Schlüssels der elektronischen Signatur.
Der Inhalt der Bühne. Die Stufe besteht aus zwei Zwischenschritten. Die erste legt fest, ob der öffentliche Schlüssel der Überprüfung der elektronischen Signatur zum Zeitpunkt des Signierens der Daten als vertrauenswürdig eingestuft wurde. Die zweite legt fest, ob der private Schlüssel der elektronischen Signatur zum Zeitpunkt des Signierens der Daten gültig war. Im Allgemeinen können die Gültigkeitszeiträume dieser Schlüssel nicht übereinstimmen (z. B. für qualifizierte Zertifikate für elektronische Signaturprüfschlüssel). Die Art des Vertrauens in den öffentlichen Schlüssel des Unterzeichners wird durch die von den interagierenden Parteien festgelegten Regeln für das elektronische Dokumentenmanagement bestimmt.
Erfüllungsort: Anwendungssoftware / Cryptokernel.

Stufe 3. Kontrolle der Vollmacht des Unterzeichners.
Der Inhalt der Bühne. Gemäß den Regeln des elektronischen Dokumentenmanagements wird geprüft, ob der Unterzeichner das Recht hatte, die geschützten Daten zu zertifizieren. Zum Beispiel geben wir eine Situation der Verletzung der Autorität an. Angenommen, es gibt eine Organisation, in der alle Mitarbeiter eine elektronische Signatur haben. Die Bestellung des Leiters, jedoch mit der elektronischen Unterschrift des Lagerverwalters unterschrieben, geht in das interne elektronische Dokumentenverwaltungssystem ein. Dementsprechend kann ein solches Dokument nicht als legitim angesehen werden.
Erfüllungsort: Anwendungssoftware.

Annahmen, die in der Beschreibung des Schutzobjekts übernommen wurden

  1. Informationskanäle mit Ausnahme der Schlüsselaustauschkanäle, einschließlich der Anwendungssoftware, der API und des Kryptokerns.
  2. Informationen über das Vertrauen in öffentliche Schlüssel und / oder Zertifikate sowie Informationen über die Befugnisse der Besitzer öffentlicher Schlüssel werden im öffentlichen Schlüsselspeicher abgelegt.
  3. Anwendungssoftware arbeitet mit einem öffentlichen Schlüsselspeicher über einen Kryptokern.

Ein Beispiel für ein Informationssystem, das durch das SKZI geschützt wird


Um die zuvor dargestellten Schemata zu veranschaulichen, betrachten wir ein hypothetisches Informationssystem und wählen alle Strukturelemente darauf aus.

Beschreibung des Informationssystems Die



beiden Organisationen beschlossen, ein rechtlich bedeutsames elektronisches Dokumentenmanagement (EDM) untereinander einzuführen. Dazu haben sie eine Vereinbarung getroffen, in der sie erklärt haben, dass die Dokumente per E-Mail übermittelt werden. Gleichzeitig müssen sie verschlüsselt und mit einer qualifizierten elektronischen Signatur signiert sein. Office-Software aus dem Microsoft Office 2016-Paket sollte als Tools zum Erstellen und Verarbeiten von Dokumenten verwendet werden, und CryptoPRO- und CryptoARM-Verschlüsselungssoftware werden als kryptografische Schutztools verwendet.

Beschreibung der Infrastruktur der Organisation 1

Organisation 1 entschied, die CryptoPRO CIPS- und CryptoARM-Software auf dem AWP des Benutzers - einem physischen Computer - zu installieren. Verschlüsselungsschlüssel und elektronische Signaturen werden auf dem Schlüsselträger ruToken gespeichert und arbeiten in einem Modus mit extrahierbarem Schlüssel. Der Benutzer bereitet elektronische Dokumente lokal auf seinem Computer vor, wonach sie verschlüsselt, signiert und mit einem lokal installierten E-Mail-Client gesendet werden.

Beschreibung der Infrastruktur der Organisation 2

Organisation 2 entschied sich für die Verschlüsselung und elektronische Signatur der dedizierten virtuellen Maschine. Gleichzeitig werden alle kryptographischen Vorgänge automatisch ausgeführt.

Dazu werden auf der dedizierten virtuellen Maschine zwei Netzwerkordner organisiert: "\\ ... \ In \", "\\ ... \ Out \". Im Netzwerkordner wird "\\ ... \ In \" automatisch von den Gegenpartei-Dateien in geöffneter Form empfangen. Diese Dateien werden entschlüsselt und ihre elektronische Signatur wird überprüft.

Im Ordner "\\ ... \ Out \" legt der Benutzer die Dateien ab, die verschlüsselt, signiert und an die Gegenpartei gesendet werden müssen. Der Benutzer bereitet die Dateien auf seiner Workstation vor.
Um die Funktionen der Verschlüsselung und der elektronischen Signatur auf einer virtuellen Maschine auszuführen, werden das kryptografische Schutzsystem für kryptografische Informationen, die CryptoARM-Software und der Mail-Client installiert. Die automatische Steuerung aller Elemente der virtuellen Maschine wird mithilfe von von Systemadministratoren entwickelten Skripts ausgeführt.

Die kryptographischen Schlüssel der elektronischen Signatur werden mit dem nicht wiederherstellbaren JaCarta GOST-Schlüssel auf dem Token abgelegt, den der Benutzer mit seinem lokalen Computer verbindet.

Das Token wird mithilfe der auf der Workstation des Benutzers und auf der virtuellen Maschine installierten speziellen USB-over-IP-Software an die virtuelle Maschine weitergeleitet.

Die Systemuhr der AWP des Benutzers in Organisation 1 wird manuell angepasst. Die Systemuhr einer spezialisierten virtuellen Maschine in Organisation 2 wird mit der Systemuhr des Hypervisors synchronisiert, und diese wiederum wird über das Internet mit öffentlichen Zeitservern synchronisiert.

Auswahl der Strukturelemente SKZI
Basierend auf der obigen Beschreibung der IT-Infrastruktur werden wir die strukturellen Elemente des SKPI auswählen und in eine Tabelle schreiben.

Tabelle - Übereinstimmung der Elemente des SKZI-Modells mit Elementen von Informationssystemen
Artikelname Organisation 1 Organisation 2
Anwendungssoftware ON CryptoARM ON CryptoARM
Der Softwareteil des Kryptokerns SKZI CryptoPRO CSP SKZI CryptoPRO CSP
Hardware-Teil des Kryptokerns fehlt JaCarta GOST
API MS CryptoAPI MS CryptoAPI
Öffentlicher Schlüsselspeicher AWP-Benutzer:
- Festplatte;
- Standard Zertifikatsspeicher Windows.
Hypervisor:
- Festplatte.

Virtuelle Maschine:
- Festplatte;
- Standard Zertifikatsspeicher Windows.
Privater Schlüsselspeicher Schlüsselträger ruToken im abrufbaren Schlüsselmodus JaCarta GOST-Schlüsselträger, der im nicht wiederherstellbaren Schlüsselmodus arbeitet
Kanal für den öffentlichen Schlüsselaustausch AWP-Benutzer:
- RAM.
Hypervisor:
- RAM.

Virtuelle Maschine:
- RAM.
Privater Schlüsselaustauschkanal AWP-Benutzer:
- USB-Bus;
- Rom.
fehlt
Kanalaustausch zwischen Kryptokernen fehlt (keine Hardware des Kryptokerns) AWP-Benutzer:
- USB-Bus;
- Rom;
- Softwaremodul USB-over-IP;
- Netzwerkschnittstelle.

Unternehmensnetzwerk der Organisation 2.

Hypervisor:
- Betriebsspeicher;
- Netzwerkschnittstelle.

Virtuelle Maschine:
- Netzwerkschnittstelle;
- Rom;
- Softwaremodul USB-over-IP.
Datenkanal öffnen AWP-Benutzer:
- E / A;
- Rom;
- Festplatte.
AWP-Benutzer:
- E / A;
- Rom;
- Festplatte;
- Netzwerkschnittstelle.

Unternehmensnetzwerk der Organisation 2.

Hypervisor:
- Netzwerkschnittstelle;
- Rom;
- Festplatte.

Virtuelle Maschine:
- Netzwerkschnittstelle;
- Rom;
- Festplatte.
Sicherer Datenkanal Internet

Unternehmensnetzwerk der Organisation 1.

Automatisierter Arbeitsplatz des Benutzers:
- Festplatte;
- Rom;
- Netzwerkschnittstelle.
Internet

Unternehmensnetzwerk der Organisation 2.

Hypervisor:
- Netzwerkschnittstelle;
- Rom;
- Festplatte.

Virtuelle Maschine:
- Netzwerkschnittstelle;
- Rom;
- Festplatte.
Zeitkanal AWP-Benutzer:
- E / A;
- Rom;
- Systemzeitgeber.
Internet
Unternehmensnetzwerk der Organisation 2,

Hypervisor:
- Netzwerkschnittstelle;
- Rom;
- Systemzeitgeber.

Virtuelle Maschine:
- RAM;
- Systemzeitgeber.
Übertragungskanal für Steuerbefehle AWP-Benutzer:
- E / A;
- Rom.

(CryptoARM-Grafikbenutzeroberfläche)
Virtuelle Maschine:
- RAM;
- Festplatte.

(Automatisierungsskripte)
Kanal empfangen Ergebnisse AWP-Benutzer:
- E / A;
- Rom.

(CryptoARM-Grafikbenutzeroberfläche)
Virtuelle Maschine:
- RAM;
- Festplatte.

(Protokolldateien von Automatisierungsskripten)

Sicherheitsbedrohungen der obersten Ebene


Erläuterungen

Annahmen beim Zerlegen von Bedrohungen:

  1. Es werden starke kryptographische Algorithmen verwendet.
  2. Kryptografische Algorithmen werden sicher in den korrekten Betriebsmodi verwendet (z. B. wird die EZB nicht verwendet, um große Datenmengen zu verschlüsseln, eine zulässige Belastung des Schlüssels usw.).
  3. Die Angreifer kennen alle verwendeten Algorithmen, Protokolle und öffentlichen Schlüssel.
  4. Eindringlinge können alle verschlüsselten Daten lesen.
  5. Übeltäter können beliebige Programmelemente im System reproduzieren.

Zerlegung

U1. Kompromiss privater kryptografischer Schlüssel.
Y2. Verschlüsseln Sie gefälschte Daten im Auftrag eines legitimen Absenders.
Y3 Entschlüsselung verschlüsselter Daten durch nicht legitime Empfänger von Daten (Eindringlinge).
E4 Erstellen einer elektronischen Signatur eines berechtigten Unterzeichners unter falschen Daten.
V5 Ein positives Ergebnis der Überprüfung der elektronischen Signatur falscher Daten erhalten.
Y6 Die fehlerhafte Annahme elektronischer Dokumente zur Ausführung aufgrund von Problemen bei der Organisation elektronischer Dokumente.
E7. Unbefugtes Kennenlernen der geschützten Daten während ihrer Verarbeitung.

U1. Kompromiss privater kryptografischer Schlüssel


V1.1. Abrufen des privaten Schlüssels aus der Speicherung privater Schlüssel.

D1.2. Erhalten des privaten Schlüssels aus den Objekten der Umgebung der Funktionsweise der kryptographischen Mittel, in denen er sich vorübergehend befindet.
Erläuterungen D1.2.

Zu den Objekten, in denen der private Schlüssel vorübergehend gespeichert werden kann, gehören:

  1. Rom,
  2. temporäre Dateien
  3. Auslagerungsdateien
  4. Ruhezustandsdateien
  5. Momentaufnahme-Dateien von virtuellen Maschinen im „aktuellen“ Zustand, einschließlich der angehaltenen Speicherdateien von virtuellen Maschinen.

D1.2.1. Entfernen privater Schlüssel aus dem Arbeits-RAM, indem RAM-Module eingefroren, abgerufen und anschließend Daten gelesen werden (Freeze-Angriff).
Erläuterungen D1.2.1.
Ein Beispiel für einen Angriff .

H1.3. Abrufen des privaten Schlüssels vom Kanal für den privaten Schlüsselaustausch.
Erläuterungen D1.3.
Ein Beispiel für die Implementierung dieser Bedrohung wird unten gegeben .

D1.4. Nicht autorisierte Änderung eines Cryptokernel, wodurch private Schlüssel den Angreifern bekannt werden.

V1.5. Kompromiss des privaten Schlüssels infolge der Verwendung von technischen Informationsverlustkanälen (TKUI).
Erläuterungen D1.5.
Ein Beispiel für einen Angriff .

D1.6. Beeinträchtigung des privaten Schlüssels durch Verwendung spezieller technischer Mittel (ITS), die zur geheimen Sammlung von Informationen ("Bugs") bestimmt sind.

U1.7. Kompromiss zwischen privaten Schlüsseln bei der Speicherung außerhalb von SKZI.
Erläuterungen D1.7.
Zum Beispiel speichert ein Benutzer seine Schlüsselträger in einer Desktop-Schublade, aus der sie leicht von Eindringlingen entnommen werden können.

Y2. Verschlüsselung von gefälschten Daten im Auftrag eines legitimen Absenders


Erläuterungen
Diese Bedrohung wird nur für Datenverschlüsselungsschemata mit Senderauthentifizierung berücksichtigt. Beispiele für solche Schemata sind in den Empfehlungen zur Standardisierung aufgeführt. R 1323565.1.004-2017 „Informationstechnologie. Kryptografischer Schutz von Informationen. Shared-Key-Generierungsschemata mit Public-Key-Authentifizierung . Für die übrigen kryptografischen Schemata gibt es diese Bedrohung nicht, da die Verschlüsselung der öffentlichen Schlüssel des Empfängers erfolgt und diese den Angreifern im Allgemeinen bekannt sind.

Zersetzung
U2.1. Kompromiss des privaten Schlüssels des Absenders:
U2.1.1. Referenz: „Typisches Bedrohungsmodell. Das System des kryptografischen Schutzes von Informationen U1. Kompromiss zwischen privaten kryptographischen Schlüsseln " .

Y2.2. Ersetzung von Eingangsdaten im Kanal für den Austausch offener Daten.
Anmerkungen U2.2.
Beispiele für die Implementierung dieser Bedrohung finden Sie hier und hier .

Y3 Entschlüsselung verschlüsselter Daten durch Personen, die keine legitimen Empfänger von Daten sind (Eindringlinge)


Zersetzung
Q3.1. Kompromiss der privaten Schlüssel des Empfängers der verschlüsselten Daten.
V3.1.1 Referenz: „Typisches Bedrohungsmodell. Das System des kryptographischen Schutzes von Informationen. U1. Kompromiss zwischen privaten kryptographischen Schlüsseln " .

D3.2. Ersetzung verschlüsselter Daten beim Austausch geschützter Daten.

E4 Erstellen einer elektronischen Signatur eines berechtigten Unterzeichners unter falschen Daten


Zersetzung
D4.1. Kompromiss zwischen privaten Schlüsseln einer elektronischen Signatur eines berechtigten Unterzeichners.
D4.1.1 Referenz: „Typisches Bedrohungsmodell. Das System des kryptographischen Schutzes von Informationen. U1. Kompromiss zwischen privaten kryptographischen Schlüsseln " .

Y4.2. Ersetzung von signierten Daten im offenen Datenaustauschkanal.
Anmerkung Y4.2.
Beispiele für die Implementierung dieser Bedrohung finden Sie hier und hier .

V5 Ein positives Ergebnis der Überprüfung der elektronischen Signatur falscher Daten erhalten


Zersetzung
У5.1. Die Angreifer fangen die Nachricht über das negative Ergebnis der Überprüfung der elektronischen Signatur im Übertragungskanal der Arbeitsergebnisse ab und ersetzen sie durch eine Nachricht mit einem positiven Ergebnis.

E5.2. Übeltäter führen einen Vertrauensangriff auf Zertifikate der Signatur ( SCENARIO - alle Elemente sind obligatorisch ) aus:
У5.2.1. Angreifer generieren elektronische Signatur für öffentliche und private Schlüssel. Wenn das System Zertifikate für elektronische Signaturschlüssel verwendet, generiert es ein elektronisches Signaturzertifikat, das dem Zertifikat des beabsichtigten Absenders der Daten möglichst nahe kommt, deren Nachricht sie fälschen möchten.
U5.2.2. Angreifer nehmen nicht autorisierte Änderungen am öffentlichen Schlüsselspeicher vor und geben dem von ihnen generierten öffentlichen Schlüssel das erforderliche Maß an Vertrauen und Autorität.
D5.2.3. Angreifer signieren gefälschte Daten mit einem zuvor generierten elektronischen Signaturschlüssel und binden sie in den sicheren Datenaustauschkanal ein.

H5.3. Die Angreifer greifen mit den überfälligen Schlüsseln der elektronischen Unterschrift des gesetzlichen Vertreters ( SCENARIO - alle Elemente sind erforderlich ) an:
У5.3.1. Die Angreifer gefährden die abgelaufenen (derzeit nicht gültigen) privaten Schlüssel der elektronischen Signatur des berechtigten Absenders.
Y5.3.2. Die Angreifer ersetzen die Zeit im Zeitübertragungskanal durch die Zeit, zu der die gefährdeten Tasten noch betätigt wurden.
H5.3.3. Die Angreifer signieren gefälschte Daten mit einem zuvor gefährdeten elektronischen Signaturschlüssel und geben sie in den sicheren Datenaustauschkanal ein.

E5.4. Die Angreifer führen einen Angriff mit den angegriffenen elektronischen Signaturschlüsseln des gesetzlichen Unterzeichners ( SCENARIO - alle Elemente sind erforderlich ) aus:
У5.4.1. Schädliche Benutzer erstellen eine Kopie des öffentlichen Schlüsselspeichers.
D5.4.2. Die Angreifer gefährden die privaten Schlüssel eines der legalen Absender. Er merkt den Kompromiss, widerruft die Schlüssel, Informationen über den Widerruf des Schlüssels werden im öffentlichen Schlüsselspeicher abgelegt.
D5.4.3. Übeltäter ersetzen die Speicherung öffentlicher Schlüssel durch zuvor kopierte.
L5.4.4. Die Angreifer signieren gefälschte Daten mit einem zuvor gefährdeten elektronischen Signaturschlüssel und geben sie in den sicheren Datenaustauschkanal ein.

E5.5. <...> aufgrund von Fehlern bei der Implementierung der zweiten und dritten Stufe der Überprüfung der elektronischen Signatur:
Erläuterungen У5.5.
Ein Beispiel für die Implementierung dieser Bedrohung finden Sie unten .

W5.5.1. Überprüfung des Vertrauens zum Zertifikat des Schlüssels der elektronischen Signatur nur durch Vorhandensein des Vertrauens zum Zertifikat, mit dessen Hilfe das Zertifikat signiert wird, ohne die CRL oder OCSP zu überprüfen.
Klarstellung W5.5.1.
Ein Beispiel für eine Bedrohung .

Y5.5.2. Beim Aufbau einer Vertrauenskette für ein Zertifikat werden die Befugnisse zur Ausstellung von Zertifikaten nicht analysiert
. Erläuterungen У5.5.2.
Ein Beispiel für einen Angriff gegen SSL / TLS-Zertifikate.
Die Angreifer haben ein legitimes Zertifikat für ihre E-Mail erworben. Dann machten sie ein betrügerisches Site-Zertifikat und unterzeichneten es mit ihrem Zertifikat. Wenn die Berechtigungsprüfung nicht durchgeführt wird, dann ist die Prüfung der Vertrauenskette korrekt und dementsprechend auch das betrügerische Zertifikat.

Y5.5.3. Beim Aufbau einer Vertrauenskette zu einem Zertifikat werden Zwischenzertifikate nicht auf Sperrung geprüft.

W5.5.4. CRL-Aktualisierungen werden seltener ausgeführt, als von der Zertifizierungsstelle freigegeben.

Y5.5.5. Die Entscheidung über das Vertrauen in die elektronische Signatur wird getroffen, bevor die OCSP-Antwort bezüglich des Status des Zertifikats empfangen wird, und zwar auf Anforderung, die später als die Signaturerstellungszeit oder früher als die nächste nach der Signaturerfassung empfangene CRL gesendet wird.
Erläuterungen D5.5.5.
In den Vorschriften der meisten Zertifizierungsstellen wird der Zeitpunkt des Widerrufs eines Zertifikats als der Zeitpunkt der Ausstellung der nächstgelegenen CRL mit Informationen zum Widerruf des Zertifikats angesehen.

Y5.5.6. Nach Erhalt der signierten Daten überprüft das Zertifikat nicht, ob der Absender angehört.
Erläuterungen D5.5.6.
Ein Beispiel für einen Angriff. Für SSL-Zertifikate: Die Adresse des aufgerufenen Servers kann möglicherweise nicht auf den Wert des CN-Felds im Zertifikat überprüft werden.
Ein Beispiel für einen Angriff. Übeltäter haben Schlüssel einer elektronischen Unterschrift eines Teilnehmers eines Zahlungssystems kompromittiert. Danach brachen sie in das Netzwerk eines anderen Teilnehmers ein und schickten in seinem Namen Zahlungsdokumente, die mit einem Sicherheitsschlüssel signiert waren, an den Abrechnungsserver des Zahlungssystems. Wenn der Server nur das Vertrauen analysiert und die Konformität nicht überprüft, werden betrügerische Dokumente als legitim betrachtet.

Y6 Die fehlerhafte Annahme elektronischer Dokumente zur Ausführung aufgrund von Problemen bei der Organisation elektronischer Dokumente.


Zerlegung
V6.1. Die empfangende Partei erkennt keine Verdoppelung der empfangenen Dokumente.
Erklärung Q6.1.
Ein Beispiel für einen Angriff. Angreifer können ein an den Empfänger übertragenes Dokument abfangen, selbst wenn es kryptographisch geschützt ist, und es dann wiederholt an den geschützten Datenübertragungskanal senden. Wenn der Empfänger keine Duplikate entdeckt, werden alle empfangenen Dokumente als unterschiedliche Dokumente wahrgenommen und verarbeitet.

E7 Unerlaubtes Kennenlernen der geschützten Daten während der Verarbeitung von SKZI


Zersetzung

D7.1. <...> aufgrund des Verlusts von Informationen durch Kanäle Dritter (Side Channel Attack).
Erklärung Q7.1.
Ein Beispiel für einen Angriff .

D7.2. <...> aufgrund der Neutralisierung des Schutzes vor unbefugtem Zugriff auf die im
MISP verarbeiteten Informationen: D7.2.1. Betrieb von SKZI bei Verstößen gegen die in der Dokumentation zu SKZI beschriebenen Anforderungen.

D7.2.2. <...>, implementiert auf Kosten von Schwachstellen in:
D7.2.2.1. <...> Schutz vor unbefugtem Zugriff.
D7.2.2.2. <...> selbst SKZI.
D7.2.2.3. <...> kryptografisch funktionierende Umgebung.

Angriffsbeispiele


Die nachfolgend betrachteten Szenarien enthalten offensichtlich Fehler der Informationssicherheitsorganisation und dienen nur zur Veranschaulichung möglicher Angriffe.

Szenario 1. Beispiel für die Implementierung der Bedrohungen Y2.2 und Y4.2.


Objekt Beschreibung


Software ARM CBD und SKZI SCUD Signatur, die auf einem physischen Computer installiert ist, der nicht mit dem Computernetzwerk verbunden ist. PCF vdToken wird als Schlüsselträger beim Betrieb des nicht wiederherstellbaren Schlüssels verwendet.

Beim Abrechnungsverfahren wird davon ausgegangen, dass der Abwicklungsbeauftragte elektronische Nachrichten in offenem Format (das alte AWS-KBR-Schema) von einem speziell geschützten Dateiserver herunterlädt, diese dann auf ein USB-Flash-Laufwerk mit Wechselmedien schreibt und sie an die KBR-AWS übermittelt, wo sie verschlüsselt werden Zeichen Danach überträgt der Spezialist die geschützten elektronischen Nachrichten auf das entfernbare Medium und schreibt sie dann über seinen Arbeitscomputer an den Dateiserver, von wo sie zur UTA gelangen, und dann an das Zahlungssystem der Bank of Russia.

In diesem Fall umfassen die Kanäle für den Austausch offener und geschützter Daten: einen Dateiserver, einen Arbeitscomputer eines Spezialisten und entfernbare Medien.

Angriff
Unbefugte Angreifer installieren ein Fernsteuerungssystem auf einem Arbeitscomputer eines Spezialisten und ersetzen bei der Aufzeichnung auf einem nicht verwertbaren Spediteur von Zahlungsaufträgen (elektronische Nachrichten) in offener Form den Inhalt eines davon. Der Spezialist übergibt die Zahlungsaufträge an die AWS der CBD, signiert und verschlüsselt sie, ohne die Substitution zu bemerken (z. B. aufgrund der großen Anzahl von Zahlungsaufträgen auf dem Flug, Ermüdung usw.). Danach tritt ein gefälschter Zahlungsauftrag, der die technologische Kette durchläuft, in das Zahlungssystem der Bank of Russia ein.

Szenario 2. Beispiel für die Implementierung der Bedrohungen Y2.2 und Y4.2.


Beschreibung des Objekts


Computer mit installierter AWS der CBD, SCAD-Signatur und dem mit den PCF-vdToken-Funktionen verbundenen Schlüsselfunktionen in einem dedizierten Raum ohne Zugriff durch Personal.
Der Abrechnungsspezialist ist im Fernzugriffsmodus über das RDP-Protokoll mit der ARM CBD verbunden.

Angriff Die
Angreifer fangen die Details ab, über die der Abrechnungsspezialist die Verbindung zu KBR AWS herstellt und mit ihm arbeitet (z. B. durch bösartigen Code auf seinem Computer). Dann stellen sie in seinem Namen eine Verbindung her und senden einen gefälschten Zahlungsauftrag an das Zahlungssystem der Bank of Russia.

Szenario 3. Ein Beispiel für die Umsetzung der Bedrohung von 1.1.


Objektbeschreibung


Betrachten Sie eine der hypothetischen Optionen für die Implementierung der ABS-KBR-Integrationsmodule für das neue Schema (AWS KBR-N), bei dem die elektronische Signatur von ausgehenden Dokumenten auf der ABS-Seite erfolgt. Gleichzeitig gehen wir davon aus, dass das ABS auf einem Betriebssystem basiert, das nicht von SCZI SCAD Signature unterstützt wird. Dementsprechend wurde die kryptografische Funktionalität in eine separate virtuelle Maschine verschoben - das ABS-KBR-Integrationsmodul.
Als Schlüsselträger wird ein normaler USB-Token verwendet, der in einem entfernbaren Schlüsselmodus arbeitet. Beim Anschließen des Tastenträgers an den Hypervisor stellte sich heraus, dass sich im System keine freien USB-Anschlüsse befinden. Daher wurde entschieden, das USB-Token über einen Netzwerk-USB-Hub anzuschließen und einen USB-over-IP-Client an der virtuellen Maschine zu installieren, die mit dem Hub kommuniziert.

Angriff Die
Angreifer haben den privaten Schlüssel der elektronischen Signatur vom Kommunikationskanal zwischen dem USB-Hub und dem Hypervisor abgefangen (die Daten wurden in Klartext übertragen). Mit dem privaten Schlüssel bildeten die Angreifer einen gefälschten Zahlungsauftrag, unterzeichneten ihn mit einer elektronischen Signatur und schickten ihn zur Ausführung an das AWP KBR-N.

Szenario 4. Beispiel für die Implementierung von Bedrohungen V5.5.


Beschreibung des Objekts
Beachten Sie das gleiche Schema wie im vorherigen Szenario. Wir gehen davon aus, dass die E-Mails von der AWS KBR-N in den Ordner \\ ... \ SHARE \ In fallen und die an die AWS KBR-N und weiter in das Zahlungssystem der Bank of Russia - \\. .. \ TEILEN \ raus.
Wir gehen außerdem davon aus, dass beim Implementieren des Integrationsmoduls die Listen der widerrufenen Zertifikate nur dann aktualisiert werden, wenn die kryptographischen Schlüssel erneut ausgegeben werden, und dass die E-Mails, die im Ordner \\ ... \ SHARE \ In empfangen werden, nur auf Integritätskontrolle und Vertrauenskontrolle für das Öffnen geprüft werden Schlüsselunterschrift

Angriff

Die Angreifer unterzeichneten mit den im vorherigen Szenario gestohlenen Schlüsseln einen gefälschten Zahlungsauftrag, der Informationen über den Geldeingang auf dem Konto des betrügerischen Kunden enthielt, und fügten ihn in den sicheren Datenaustauschkanal ein. Da nicht die Bank von Russland prüft, dass der Zahlungsauftrag von der Bank von Russland unterzeichnet wurde, wird sie zur Ausführung angenommen.

Jetzt auch beliebt: