{"id":31627,"date":"2019-10-31T21:42:14","date_gmt":"2019-10-31T18:42:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/informatsionnaya-bezopasnost-bankovskih-beznalichnyh-platezhej-chast-8-tipovye-modeli-ugroz\/"},"modified":"2019-10-31T21:42:14","modified_gmt":"2019-10-31T18:42:14","slug":"informatsionnaya-bezopasnost-bankovskih-beznalichnyh-platezhej-chast-8-tipovye-modeli-ugroz","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/informatsionnaya-bezopasnost-bankovskih-beznalichnyh-platezhej-chast-8-tipovye-modeli-ugroz","title":{"rendered":"Informationssicherheit bei bankgest\u00fctzten bargeldlosen Zahlungen. Teil 8 \u2013 Typische Bedrohungsmodelle","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/\"><img decoding=\"async\" alt=\"Informationssicherheit bei bankgest\u00fctzten bargeldlosen Zahlungen. Teil 8 \u2013 Typische Bedrohungsmodelle\" src=\"\/wp-content\/uploads\/2019\/04\/acac26db4761c25a5215f37ef9e8cb5b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#ABOUT\">Wor\u00fcber die Forschung handelt<\/a><\/noindex><\/p>\n<p><b class=\"spoiler_title\">Links zu anderen Teilen der Forschung<\/b><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/344740\/\">Informationssicherheit im Bereich der bargeldlosen Bankzahlungen. Teil 1 - Wirtschaftliche Grundlagen.<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/345194\/\">Informationssicherheit im Bereich der bargeldlosen Bankzahlungen. Teil 2 - Typische IT-Infrastruktur einer Bank.<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/350852\/\">Informationssicherheit im Bereich der bargeldlosen Bankzahlungen. Teil 3 - Anforderungen an das Schutzsystem.<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/351326\/\">Informationssicherheit im Bereich der bargeldlosen Bankzahlungen. Teil 4 - \u00dcberblick \u00fcber Normen zur Bedrohungsmodellierung.<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/413703\/\">Informationssicherheit im Bereich der bargeldlosen Bankzahlungen. Teil 5 - 100+ thematische Links zu Bank\u00fcberf\u00e4llen.<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/419027\/\">Informationssicherheit im Bereich der bargeldlosen Bankzahlungen. Teil 6 - Analyse von Bankverbrechen.<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/421161\/\">Informationssicherheit im Bereich der bargeldlosen Bankzahlungen. Teil 7 - Grundmodell der Bedrohungen.<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/\">Informationssicherheit bei bankgest\u00fctzten bargeldlosen Zahlungen. Teil 8 \u2013 Typische Bedrohungsmodelle <\/a><\/noindex>(<b>Sie sind hier<\/b>)<\/li>\n<\/ul>\n<p>Dieser Artikel schlie\u00dft den Zyklus von Publikationen zur Gew\u00e4hrleistung der Informationssicherheit im Bereich der bargeldlosen Bankzahlungen ab. Hier betrachten wir die typischen Bedrohungsmodelle, auf die in der <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/421161\/\">Grundmodell<\/a><\/noindex>:<\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUNC\">Typisches Bedrohungsmodell. Netzwerkverbindung<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUIS\">Typisches Bedrohungsmodell. Informationssystem basierend auf einer Client-Server-Architektur<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSRD\">Typisches Bedrohungsmodell. Zugriffskontrollsystem<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUMI\">Typisches Bedrohungsmodell. Integrationsmodul<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZI\">Typisches Bedrohungsmodell. System zur kryptografischen Informationssicherung.<\/a><\/noindex><\/li>\n<\/ul>\n<p><\/p>\n<blockquote><p><b>HABRO-WARNING !!!<\/b> Sehr geehrte Habrowaner, dies ist kein unterhaltsamer Beitrag. <br \/>\nDie unter dem Kat verborgenen 40+ Seiten Materialien sollen <b>bei der Arbeit oder im Studium helfen<\/b> Menschen, die sich mit Bankwesen oder Informationssicherheit besch\u00e4ftigen. Diese Materialien sind das Endprodukt der Forschung und sind im sachlichen offiziellen Ton verfasst. Im Grunde genommen sind dies Vorlagen f\u00fcr interne Dokumente zur Informationssicherheit. <\/p>\n<p>Nun und traditionell - <b>\u201eDie Verwendung von Informationen aus dem Artikel zu illegalen Zwecken wird gesetzlich verfolgt\u201c<\/b>. Produktives Lesen!\n<\/p><\/blockquote>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nInformationen f\u00fcr Leser, die sich mit der Forschung vertraut machen, beginnend mit dieser Ver\u00f6ffentlichung.<br \/>\n<noindex><a rel=\"nofollow\" name=\"ABOUT\"><\/a><\/noindex><\/p>\n<blockquote>\n<h2>Wor\u00fcber die Forschung handelt<\/h2>\n<p>\nSie lesen einen Leitfaden f\u00fcr Fachkr\u00e4fte, die f\u00fcr die Informationssicherheit der Zahlungen in der Bank verantwortlich sind. <\/p>\n<p><b>Logik der Darstellung<\/b><\/p>\n<p>Zu Beginn in <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/344740\/\">Teil 1<\/a><\/noindex> und <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/345194\/\">Teil 2<\/a><\/noindex> wird der Schutzgegenstand beschrieben. Dann in <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/350852\/\">Teil 3<\/a><\/noindex> Es wird erkl\u00e4rt, wie ein Schutzsystem aufgebaut wird, und es wird auf die Notwendigkeit hingewiesen, ein Bedrohungsmodell zu entwickeln. In <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/351326\/\">Teil 4<\/a><\/noindex> wird beschrieben, welche Bedrohungsmodelle existieren und wie sie entwickelt werden. In <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/413703\/\">Teil 5<\/a><\/noindex> und <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/419027\/\">Teil 6<\/a><\/noindex> wird eine Analyse realer Angriffe bereitgestellt. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/421161\/\">Teil 7<\/a><\/noindex> und <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/\">Teil 8<\/a><\/noindex> enth\u00e4lt eine Beschreibung des Bedrohungsmodells, das auf Informationen aus allen vorhergehenden Teilen basiert.<\/p><\/blockquote>\n<p>\n<noindex><a rel=\"nofollow\" name=\"TMUNC\"><\/a><\/noindex><\/p>\n<h2>TYPISCHES BEDROHUNGS-MODELL. NETZWERKVERBINDUNG<\/h2>\n<p><\/p>\n<h3>Das Schutzobjekt, f\u00fcr das das Bedrohungsmodell angewendet wird (scope)<\/h3>\n<p>\nDas Schutzobjekt sind die Daten, die \u00fcber eine Netzwerkverbindung \u00fcbertragen werden, die in Datennetzen funktioniert, die auf dem TCP\/IP-Stack basieren.<\/p>\n<p><b>Architektur<\/b><\/p>\n<p><img decoding=\"async\" alt=\"Informationssicherheit bei bankgest\u00fctzten bargeldlosen Zahlungen. Teil 8 \u2013 Typische Bedrohungsmodelle\" src=\"\/wp-content\/uploads\/2019\/04\/7fec6dc479280db22a581595ae7fc493.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBeschreibung der Architekturelemente:<\/p>\n<ul>\n<li><i>\u201eEndknoten\u201c<\/i> \u2013 Knoten, die gesch\u00fctzte Informationen austauschen.<\/li>\n<li><i>\u201eZwischenknoten\u201c<\/i> \u2013 Elemente des Datennetzes: Router, Switches, Zugangserver, Proxy-Server und andere Ger\u00e4te, \u00fcber die der Datenverkehr der Netzwerkverbindung \u00fcbertragen wird. Im Allgemeinen kann eine Netzwerkverbindung ohne Zwischenknoten funktionieren (direkt zwischen den Endknoten).<\/li>\n<\/ul>\n<p><\/p>\n<h3>Sicherheitsbedrohungen auf oberster Ebene<\/h3>\n<p>\n<b>Dekomposition<\/b><\/p>\n<p>U1. Unbefugter Zugriff auf \u00fcbertragene Daten.<br \/>\nU2. Unbefugte Modifikation \u00fcbertragener Daten.<br \/>\nU3. Verletzung des Urheberrechts \u00fcbertragener Daten.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUNCU1\"><\/a><\/noindex><\/p>\n<h3>U1. Unbefugter Zugriff auf \u00fcbertragene Daten<\/h3>\n<p>\n<b>Dekomposition<\/b><br \/>\n1.1. &lt;&#8230;&gt; erfolgt an End- oder Zwischenknoten:<br \/>\n1.1.1. &lt;&#8230;&gt; durch das Auslesen von Daten, w\u00e4hrend sie sich in den Speichermedien des Knotens befinden:<br \/>\n1.1.1.1. &lt;&#8230;&gt; im Arbeitsspeicher.<br \/>\n<i>Erkl\u00e4rungen zu U1.1.1.1.<\/i><br \/>\nZum Beispiel w\u00e4hrend der Datenverarbeitung durch den Netzwerkstack des Knotens.<\/p>\n<p>1.1.1.2. &lt;&#8230;&gt; im nichtfl\u00fcchtigen Speicher.<br \/>\n<i>Erkl\u00e4rungen zu U1.1.1.2.<\/i><br \/>\nZum Beispiel beim Speichern \u00fcbertragener Daten im Cache, in tempor\u00e4ren Dateien oder Auslagerungsdateien.<\/p>\n<p>1.2. &lt;&#8230;&gt; erfolgt an externen Knoten im Daten\u00fcbertragungsnetz:<br \/>\n1.2.1. &lt;&#8230;&gt; mittels Packet-Capture aller an die Netzwerkschnittstelle des Knotens gelangenden Pakete:<br \/>\n<i>Erkl\u00e4rungen zu U1.2.1.<\/i><br \/>\nDie Erfassung aller Pakete erfolgt durch das Umschalten der Netzwerkkarte in den Sniffer-Modus (promiscuous mode f\u00fcr kabelgebundene Adapter oder in den Monitor-Modus f\u00fcr Wi-Fi-Adapter).<\/p>\n<p>1.2.2. &lt;&#8230;&gt; durch die Durchf\u00fchrung von Man-in-the-Middle (MiTM)-Angriffen, jedoch ohne Modifizierung der \u00fcbertragenen Daten (au\u00dfer den Protokolldaten).<br \/>\nU1.2.2.1. Link: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUNCU2\">\u201eTypisches Bedrohungsmodell. Netzwerkverbindung. U2. Unbefugte Modifikation \u00fcbertragener Daten\u201c<\/a><\/noindex>.<\/p>\n<p>1.3. &lt;&#8230;&gt; erfolgt durch das Abflie\u00dfen von Informationen \u00fcber technische Kan\u00e4le (\u0422\u041a\u0423\u0418) von physischen Knoten oder Kommunikationsleitungen.<\/p>\n<p>1.4. &lt;&#8230;&gt; erfolgt durch die Installation von speziellen technischen Mitteln (\u0421\u0422\u0421) an End- oder Zwischenknoten, die f\u00fcr die heimliche Informationsentnahme bestimmt sind.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUNCU2\"><\/a><\/noindex><\/p>\n<h3>U2. Unbefugte Modifikation \u00fcbertragener Daten<\/h3>\n<p>\n<b>Dekomposition<\/b><br \/>\n2.1. &lt;&#8230;&gt; erfolgt an End- oder Zwischenknoten:<br \/>\n2.1.1. &lt;&#8230;&gt; durch das Lesen und Ver\u00e4ndern von Daten, w\u00e4hrend sie sich in den Speichermedien der Knoten befinden:<br \/>\n2.1.1.1. &lt;&#8230;&gt; im Arbeitsspeicher:<br \/>\n2.1.1.2. &lt;&#8230;&gt; im nichtfl\u00fcchtigen Speicher:<\/p>\n<p>2.2. &lt;&#8230;&gt; erfolgt an externen Knoten im Daten\u00fcbertragungsnetz:<br \/>\n2.2.1. &lt;&#8230;&gt; durch die Durchf\u00fchrung von Man-in-the-Middle (MiTM)-Angriffen und die Umleitung des Traffics zu den Knoten der Angreifer:<br \/>\nU2.2.1.1. Physische Verbindung der Angreiferhardware in die Unterbrechung der Netzwerkverbindung.<br \/>\nU2.2.1.2. Durchf\u00fchrung von Angriffen auf Netzwerkprotokolle:<br \/>\n2.2.1.2.1. &lt;&#8230;&gt; Steuerung virtueller lokaler Netzwerke (VLAN):<br \/>\nU2.2.1.2.1.1. <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/VLAN_hopping\">VLAN-Hopping<\/a><\/noindex>.<br \/>\nU2.2.1.2.1.2. Unbefugte Modifikation der VLAN-Einstellungen an Switches oder Routern.<br \/>\n2.2.1.2.2. &lt;&#8230;&gt; VerkehrsRouting:<br \/>\nU2.2.1.2.2.1. Unbefugte Modifikation der statischen Routingtabellen von Routern.<br \/>\nU2.2.1.2.2.2. Ank\u00fcndigung von gef\u00e4lschten Routen durch Angreifer \u00fcber dynamische Routingprotokolle.<br \/>\n2.2.1.2.3. &lt;&#8230;&gt; automatische Konfiguration:<br \/>\nU2.2.1.2.3.1. <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Rogue_DHCP\">Rogue DHCP<\/a><\/noindex>.<br \/>\nU2.2.1.2.3.2. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.securitylab.ru\/analytics\/379619.php\">Rogue WPAD<\/a><\/noindex>.<br \/>\n2.2.1.2.4. &lt;&#8230;&gt; Adressierung und Namensaufl\u00f6sung:<br \/>\nU2.2.1.2.4.1. <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.wikipedia.org\/wiki\/ARP-spoofing\">ARP-Spoofing<\/a><\/noindex>.<br \/>\nU2.2.1.2.4.2. <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.wikipedia.org\/wiki\/DNS_spoofing\">DNS-Spoofing<\/a><\/noindex>.<br \/>\nU2.2.1.2.4.3. Unbefugte \u00c4nderungen an lokalen Dateien der Hostnamen (hosts, lmhosts usw.)<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUNCU3\"><\/a><\/noindex><\/p>\n<h3>U3. Verletzung des Urheberrechts \u00fcbertragener Daten<\/h3>\n<p>\n<b>Dekomposition<\/b><br \/>\nU3.1. Neutralisierung von Mechanismen zur Ermittlung der Urheberschaft von Informationen durch Angabe falscher Angaben \u00fcber den Autor oder die Quelle der Daten:<br \/>\nU3.1.1. \u00c4nderung der Angaben des Autors, die in den \u00fcbermittelten Informationen enthalten sind.<br \/>\nU3.1.1.1. Neutralisierung des kryptografischen Schutzes der Integrit\u00e4t und Urheberschaft \u00fcbertragener Daten:<br \/>\nU3.1.1.1.1. Link: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIU4\">\u201eTypisches Bedrohungsmodell. System zur kryptografischen Informationseinschutzung.<br \/>\nU4. Erstellung einer elektronischen Unterschrift eines legitimen Unterzeichners f\u00fcr gef\u00e4lschte Daten\u201c<\/a><\/noindex>.<br \/>\nU3.1.1.2. Neutralisierung des Urheberrechtsschutzes \u00fcbertragener Daten, realisiert durch Einmalbest\u00e4tigungscodes:<br \/>\nU3.1.1.2.1. <noindex>SIM-Tausch<\/noindex>.<\/p>\n<p>U3.1.2. \u00c4nderung der Angaben zur Quelle \u00fcbertragener Informationen:<br \/>\nU3.1.2.1. <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/IP_address_spoofing\">IP-Spoofing<\/a><\/noindex>.<br \/>\nU3.1.2.2. <noindex><a rel=\"nofollow\" href=\"http:\/\/xgu.ru\/wiki\/MAC-spoofing\">MAC-Spoofing<\/a><\/noindex>.<\/p>\n<p>\n<noindex><a rel=\"nofollow\" name=\"TMUIS\"><\/a><\/noindex><\/p>\n<h2>TYPISCHES BEDROHUNGSMODELL. INFORMATIONSSYSTEM, BASIEREND AUF EINER CLIENT-SERVER-ARCHITEKTUR<\/h2>\n<p><\/p>\n<h3>Das Schutzobjekt, f\u00fcr das das Bedrohungsmodell angewendet wird (scope)<\/h3>\n<p>\nDas zu sch\u00fctzende Objekt ist ein Informationssystem, das auf einer Client-Server-Architektur basiert.<\/p>\n<p><b>Architektur<\/b><br \/>\n<img decoding=\"async\" alt=\"Informationssicherheit bei bankgest\u00fctzten bargeldlosen Zahlungen. Teil 8 \u2013 Typische Bedrohungsmodelle\" src=\"\/wp-content\/uploads\/2019\/04\/f18c9c6c1e3d5372932d8c2a331284cf.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBeschreibung der Architekturelemente:<\/p>\n<ul>\n<li><i>\u201eClient\u201c<\/i> \u2013 das Ger\u00e4t, auf dem der Client-Teil des Informationssystems funktioniert.<\/li>\n<li><i>\u201eServer\u201c<\/i> \u2013 das Ger\u00e4t, auf dem der Server-Teil des Informationssystems funktioniert.<\/li>\n<li><i>\u201eDatenspeicher\u201c<\/i> \u2013 Teil der Serverinfrastruktur des Informationssystems, der f\u00fcr die Speicherung von Daten vorgesehen ist, die durch das Informationssystem verarbeitet werden.<\/li>\n<li><i>\u201eNetzwerkverbindung\u201c<\/i> \u2013 ein Kanal f\u00fcr den Austausch von Informationen zwischen Client und Server, der durch das Datennetzwerk f\u00fchrt. Eine detailliertere Beschreibung des Elementmodells finden Sie in <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUNC\">\u201eTypischem Bedrohungsmodell. Netzwerkverbindung\u201c<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\n<b>Einschr\u00e4nkungen<\/b><br \/>\nBei der Modellierung des Objekts wurden folgende Einschr\u00e4nkungen festgelegt:<\/p>\n<ol>\n<li>Der Benutzer interagiert mit dem Informationssystem innerhalb von Endzeitintervallen, die als Arbeitssitzungen bezeichnet werden.<\/li>\n<li>Zu Beginn jeder Arbeitssitzung erfolgt die Identifikation, Authentifizierung und Autorisierung des Benutzers.<\/li>\n<li>Alle sch\u00fctzenswerten Informationen werden auf dem Serverteil des Informationssystems gespeichert.<\/li>\n<\/ol>\n<p><\/p>\n<h3>Sicherheitsbedrohungen auf oberster Ebene<\/h3>\n<p>\n<b>Dekomposition<\/b><br \/>\nU1. Durchf\u00fchrung unbefugter Aktionen durch Dritte im Namen eines legitimen Benutzers.<br \/>\nU2. Unbefugte Modifikation gesch\u00fctzter Informationen w\u00e4hrend ihrer Verarbeitung durch den Serverteil des Informationssystems.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUISU1\"><\/a><\/noindex><\/p>\n<h3>U1. Durchf\u00fchrung unbefugter Aktionen durch Dritte im Namen eines legitimen Benutzers<\/h3>\n<p>\n<b>Erl\u00e4uterungen<\/b><br \/>\nIn der Regel wird in Informationssystemen die Zuordnung von Aktionen zu dem Benutzer, der sie durchgef\u00fchrt hat, durch folgende Mittel hergestellt:<\/p>\n<ol>\n<li>Systemprotokolle (logs). <\/li>\n<li>Spezielle Attribute von Datenobjekten, die Informationen \u00fcber den Ersteller oder Modifizierer enthalten.<\/li>\n<\/ol>\n<p>\nIn Bezug auf die Arbeitssitzung kann diese Bedrohung wie folgt dekonstruiert werden:<\/p>\n<ol>\n<li>&lt;&#8230;&gt; ausgef\u00fchrt im Rahmen der Sitzung des Benutzers.<\/li>\n<li>&lt;&#8230;&gt; ausgef\u00fchrt au\u00dferhalb der Sitzung des Benutzers.<\/li>\n<\/ol>\n<p>\nDie Arbeitssitzung des Benutzers kann initiiert werden durch:<\/p>\n<ol>\n<li>Den Benutzer selbst.<\/li>\n<li>Dritte.<\/li>\n<\/ol>\n<p>\nIn diesem Stadium wird die interm\u00e9diaire Dekomposition dieser Bedrohung wie folgt aussehen:<br \/>\nU1.1. Unbefugte Aktionen wurden innerhalb der Benutzersitzung ausgef\u00fchrt:<br \/>\n1.1.1. &lt;&#8230;&gt;, installiert durch den angegriffenen Benutzer.<br \/>\n1.1.2. &lt;&#8230;&gt;, installiert von den Angreifern.<br \/>\nU1.2. Unbefugte Aktionen wurden au\u00dferhalb der Benutzersitzung ausgef\u00fchrt.<\/p>\n<p>Aus Sicht der Objekte der Informationsinfrastruktur, die von Angreifern angegriffen werden k\u00f6nnen, wird die Dekomposition der interm\u00e9diaire Bedrohungen wie folgt aussehen:<\/p>\n<p>Elemente<br \/>\nDekomposition der Bedrohungen<\/p>\n<p><b>U1.1.1.<\/b><br \/>\n<b>U1.1.2.<\/b><br \/>\n<b>U1.2.<\/b><\/p>\n<p>den Kunden zur\u00fcckzuf\u00fchren sind, nicht verf\u00fcgbar ist.<br \/>\nU1.1.1.1.<br \/>\nU1.1.2.1.<\/p>\n<p>Netzwerkverbindung<br \/>\nU1.1.1.2.<\/p>\n<p>Server<\/p>\n<p>U1.2.1.<\/p>\n<p>\n<b>Dekomposition<\/b><br \/>\nU1.1. Unbefugte Aktionen wurden innerhalb der Benutzersitzung ausgef\u00fchrt:<br \/>\n1.1.1. &lt;&#8230;&gt;, installiert durch den angegriffenen Benutzer:<br \/>\nU1.1.1.1. Angreifer handelten eigenst\u00e4ndig vom Client:<br \/>\nU1.1.1.1.1 Angreifer verwendeten die regul\u00e4ren Zugangsmittel des Informationssystems:<br \/>\nU1.1.1.1.1.1. Angreifer verwendeten physische Eingabe- und Ausgabemittel des Clients (Tastatur, Maus, Monitor oder Touchscreen des mobilen Ger\u00e4ts):<br \/>\nU1.1.1.1.1.1.1. Angreifer handelten w\u00e4hrend der Zeitperioden, in denen die Sitzung aktiv war, Eingabe- und Ausgabemittel verf\u00fcgbar waren und der Benutzer abwesend war.<br \/>\nU1.1.1.1.1.2. Angreifer verwendeten Remote-Administrationstools (regul\u00e4r oder von Schadcode bereitgestellt), um den Client zu steuern:<br \/>\nU1.1.1.1.1.2.1. Angreifer handelten w\u00e4hrend der Zeitperioden, in denen die Sitzung aktiv war, Eingabe- und Ausgabemittel verf\u00fcgbar waren und der Benutzer abwesend war.<br \/>\nU1.1.1.1.1.2.2. Angreifer verwendeten Remote-Administrationstools, deren Betrieb vom angegriffenen Benutzer nicht bemerkt wird.<br \/>\nU1.1.1.2. Angreifer manipulierten die Daten in der Netzwerkverbindung zwischen dem Client und dem Server, indem sie diese so modifizierten, dass sie als Aktionen eines legitimen Benutzers erkannt wurden:<br \/>\nU1.1.1.2.1. Link: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUNCU2\">\u201eTypisches Bedrohungsmodell. Netzwerkverbindung. U2. Unbefugte Modifikation \u00fcbertragener Daten\u201c<\/a><\/noindex>.<br \/>\nU1.1.1.3. Angreifer zwangen den Benutzer, die von ihnen angegebenen Aktionen auszuf\u00fchren, indem sie soziale Ingenieurmethoden anwendeten.<\/p>\n<p>1.1.2 &lt;&#8230;&gt; installiert von den Angreifern:<br \/>\nU1.1.2.1. Angreifer handelten vom Client aus (<b>Und<\/b>):<br \/>\nU1.1.2.1.1. Angreifer neutralisierten das Zugriffskontrollsystem des Informationssystems:<br \/>\nU1.1.2.1.1.1. Link: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSRDU1\">\u00abStandardbedrohungsmodell. Zugriffskontrollsystem. U1. Unbefugtes Einrichten einer Sitzung im Namen eines legitimen Benutzers\u00bb<\/a><\/noindex>. <br \/>\nU1.1.2.1.2. Angreifer haben die regul\u00e4ren Zugangsrechte des Informationssystems verwendet<br \/>\nU1.1.2.2. Angreifer handelten von anderen Knoten im Datennetz, von denen aus eine Netzwerkverbindung mit dem Server hergestellt werden kann (<b>Und<\/b>):<br \/>\nU1.1.2.2.1. Angreifer haben das Zugriffskontrollsystem des Informationssystems neutralisiert:<br \/>\nU1.1.2.2.1.1. Link: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSRDU1\">\u00abStandardbedrohungsmodell. Zugriffskontrollsystem. U1. Unbefugtes Einrichten einer Sitzung im Namen eines legitimen Benutzers\u00bb<\/a><\/noindex>. <br \/>\nU1.1.2.2.2. Angreifer haben nicht autorisierte Zugangsmechanismen des Informationssystems verwendet.<br \/>\n<i>Erkl\u00e4rung U1.1.2.2.2.<\/i><br \/>\nAngreifer konnten den regul\u00e4ren Client des Informationssystems auf einem externen Knoten installieren oder nicht autorisierte Software verwenden, die die regul\u00e4ren Austauschprotokolle zwischen Client und Server implementiert.<\/p>\n<p>U1.2 Unbefugte Aktionen wurden au\u00dferhalb der Benutzersitzung durchgef\u00fchrt.<br \/>\nU1.2.1 Angreifer f\u00fchrten unbefugte Aktionen aus und nahmen anschlie\u00dfend nicht autorisierte \u00c4nderungen in den Protokollen des Informationssystems oder speziellen Attributen von Datenobjekten vor, um anzugeben, dass ihre Handlungen von einem legitimen Benutzer durchgef\u00fchrt wurden.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUISU2\"><\/a><\/noindex><\/p>\n<h3>U2. Unbefugte Modifikation gesch\u00fctzter Informationen w\u00e4hrend ihrer Verarbeitung durch den Server des Informationssystems<\/h3>\n<p>\n<b>Dekomposition<\/b><br \/>\nU2.1. Angreifer modifizieren gesch\u00fctzte Informationen mit Hilfe der regul\u00e4ren Mittel des Informationssystems und f\u00fchren dies im Namen eines legitimen Benutzers durch.<br \/>\nU2.1.1. Link: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUISU1\">\u00abStandardbedrohungsmodell. Informationssystem, das auf einer Client-Server-Architektur basiert. U1. Durchf\u00fchrung unbefugter Aktionen von Angreifern im Namen eines legitimen Benutzers\u00bb<\/a><\/noindex>.<\/p>\n<p>U2.2. Angreifer modifizieren gesch\u00fctzte Informationen durch die Nutzung von Mechanismen, die nicht im regul\u00e4ren Betrieb des Informationssystems vorgesehen sind.<br \/>\nU2.2.1. Angreifer modifizieren Dateien, die gesch\u00fctzte Informationen enthalten:<br \/>\n2.2.1.1. &lt;&#8230;&gt;, unter Verwendung der von dem Betriebssystem bereitgestellten Datei-Management-Mechanismen.<br \/>\n2.2.1.2. &lt;&#8230;&gt; durch die Provokation einer Wiederherstellung von Dateien aus einer unautorisiert modifizierten Sicherungskopie.<\/p>\n<p>U2.2.2. Angreifer modifizieren gesch\u00fctzte Informationen, die in der Datenbank gespeichert sind (<b>Und<\/b>):<br \/>\nU2.2.2.1. Angreifer neutralisieren das Zugriffssteuerungssystem der DBMS:<br \/>\nU2.2.2.1.1. Link: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSRDU1\">\u00abStandardbedrohungsmodell. Zugriffskontrollsystem. U1. Unbefugtes Einrichten einer Sitzung im Namen eines legitimen Benutzers\u00bb<\/a><\/noindex>.<br \/>\nU2.2.2.2. Angreifer modifizieren Informationen, indem sie die Standardinterfaces des DBMS verwenden, um auf Daten zuzugreifen.<\/p>\n<p>U2.3. Angreifer modifizieren gesch\u00fctzte Informationen durch unautorisierte Modifikation der Algorithmen der verarbeitenden Software.<br \/>\nU2.3.1. Der Quellcode der Software wird modifiziert.<br \/>\nU2.3.1. Der Maschinencode der Software wird modifiziert.<\/p>\n<p>U2.4. Angreifer modifizieren gesch\u00fctzte Informationen durch Ausnutzung von Schwachstellen in der Software des Informationssystems.<\/p>\n<p>U2.5. Angreifer modifizieren gesch\u00fctzte Informationen w\u00e4hrend ihrer \u00dcbertragung zwischen den Komponenten des Serversystems des Informationssystems (z. B. zwischen Datenbankserver und Anwendungsserver):<br \/>\nU2.5.1. Link: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUNCU2\">\u201eTypisches Bedrohungsmodell. Netzwerkverbindung. U2. Unbefugte Modifikation \u00fcbertragener Daten\u201c<\/a><\/noindex>.<\/p>\n<p>\n<noindex><a rel=\"nofollow\" name=\"TMUSRD\"><\/a><\/noindex><\/p>\n<h2>TYPISCHES MODELL DER BEDROHUNG. ZUGRIFFSKONTROLLSYSTEM<\/h2>\n<p><\/p>\n<h3>Das Schutzobjekt, f\u00fcr das das Bedrohungsmodell angewendet wird (scope)<\/h3>\n<p>\nDas Schutzobjekt, f\u00fcr das dieses Bedrohungsmodell angewendet wird, entspricht dem Schutzobjekt des Bedrohungsmodells: \u201eTypisches Bedrohungsmodell. Informationssystem, das auf Architektur des Client-Server-Frameworks basiert.\u201c<\/p>\n<p>Unter dem Zugriffskontrollsystem f\u00fcr Benutzer in diesem Bedrohungsmodell versteht man eine Komponente des Informationssystems, die folgende Funktionen implementiert:<\/p>\n<ol>\n<li>Identifizierung der Benutzer.<\/li>\n<li>Authentifizierung der Benutzer.<\/li>\n<li>Autorisierung der Benutzer.<\/li>\n<li>Protokollierung der Benutzeraktionen.<\/li>\n<\/ol>\n<p><\/p>\n<h3>Sicherheitsbedrohungen auf oberster Ebene<\/h3>\n<p>\n<b>Dekomposition<\/b><br \/>\nU1. Unautorisierte Sitzungser\u00f6ffnung im Namen eines legitimen Benutzers. <br \/>\nU2. Unautorisierte Erh\u00f6hung der Benutzerberechtigungen im Informationssystem.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSRDU1\"><\/a><\/noindex> <\/p>\n<h3>U1. Unautorisierte Sitzungser\u00f6ffnung im Namen eines legitimen Benutzers <\/h3>\n<p>\n<b>Erl\u00e4uterungen<\/b><br \/>\nDie Zerlegung dieser Bedrohung h\u00e4ngt im Allgemeinen vom verwendeten Typ der Systeme zur Identifizierung und Authentifizierung von Benutzern ab. <\/p>\n<p>In diesem Modell wird nur das System zur Identifizierung und Authentifizierung von Benutzern betrachtet, das Textanmeldungen und Passw\u00f6rter verwendet. Dabei nehmen wir an, dass der Benutzername eine \u00f6ffentlich zug\u00e4ngliche Information ist, die Angreifern bekannt ist.<\/p>\n<p><b>Dekomposition<\/b><br \/>\n1.1. &lt;&#8230;&gt; durch die Kompromittierung von Anmeldedaten:<br \/>\nU1.1.1. Angreifer haben die Anmeldedaten des Benutzers w\u00e4hrend ihrer Speicherung kompromittiert.<br \/>\n<i>Erl\u00e4uterungen zu U1.1.1.<\/i><br \/>\nZum Beispiel k\u00f6nnten die Anmeldedaten auf einem Aufkleber geschrieben worden sein, der am Monitor befestigt ist.<\/p>\n<p>U1.1.2. Der Benutzer hat versehentlich oder in b\u00f6ser Absicht die Zugangsdaten an Dritte weitergegeben.<br \/>\nU1.1.2.1. Der Benutzer hat die Anmeldedaten laut beim Eingeben ausgesprochen.<br \/>\nU1.1.2.2. Der Benutzer hat absichtlich seine Anmeldedaten weitergegeben:<br \/>\n1.1.2.2.1. &lt;&#8230;&gt; von Arbeitskollegen.<br \/>\n<i>Erl\u00e4uterungen U1.1.2.2.1.<\/i><br \/>\nZum Beispiel, damit sie ihn w\u00e4hrend seiner Krankheitszeit ersetzen k\u00f6nnen.<\/p>\n<p>U1.1.2.2.2. &lt;&#8230;&gt; f\u00fcr die Auftragnehmer des Arbeitgebers, die an Objekten der Informationsinfrastruktur arbeiten.<br \/>\nU1.1.2.2.3. &lt;&#8230;&gt; an Dritte.<br \/>\n<i>Erl\u00e4uterungen U1.1.2.2.3.<\/i><br \/>\nEine der M\u00f6glichkeiten, wie diese Bedrohung realisiert werden kann, ist, dass Angreifer Methoden der sozialen Manipulation verwenden.<\/p>\n<p>U1.1.3. Angreifer haben die Anmeldedaten durch Ausprobieren erlangt:<br \/>\nU1.1.3.1. &lt;&#8230;&gt; unter Verwendung der Standardzugangsmechanismen.<br \/>\nU1.1.3.2. &lt;&#8230;&gt; anhand zuvor aufgezeichneter Codes (z. B. Passwort-Hashes) zur Speicherung von Anmeldeinformationen.<\/p>\n<p>U1.1.4. Angreifer haben schadhafter Code verwendet, um die Anmeldedaten des Benutzers abzufangen.<\/p>\n<p>U1.1.5. Angreifer haben die Anmeldedaten aus der Netzwerkverbindung zwischen dem Client und dem Server extrahiert:<br \/>\nU1.1.5.1. Link: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUNCU1\">\u201eTypisches Bedrohungsmodell. Netzwerkverbindung. U1. Unbefugtes Lesen \u00fcbertragener Daten\u201c<\/a><\/noindex>.<\/p>\n<p>U1.1.6. Angreifer haben die Anmeldedaten aus den Aufzeichnungen von \u00dcberwachungssystemen extrahiert:<br \/>\nU1.1.6.1. &lt;&#8230;&gt; von \u00dcberwachungssystemen (wenn w\u00e4hrend der Arbeit Tasteneingaben auf der Tastatur aufgezeichnet wurden).<br \/>\nU1.1.6.2. &lt;&#8230;&gt; von Systemen zur Kontrolle der Mitarbeiteraktivit\u00e4ten am Computer. <br \/>\n<i>Erl\u00e4uterungen U1.1.6.2.<\/i><br \/>\nEin Beispiel f\u00fcr ein solches System ist \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.staffcop.ru\">StuffCop<\/a><\/noindex>.<\/p>\n<p>U1.1.7. Angreifer haben die Anmeldedaten des Benutzers aufgrund von M\u00e4ngeln im \u00dcbertragungsprozess kompromittiert.<br \/>\n<i>Erl\u00e4uterungen U1.1.7.<\/i><br \/>\nZum Beispiel die \u00dcbertragung von Passw\u00f6rtern im Klartext per E-Mail.<\/p>\n<p>U1.1.8. Angreifer haben die Anmeldedaten erhalten, indem sie die Sitzung des Benutzers mit Remote-Management-Systemen beobachtet haben.<\/p>\n<p>U1.1.9. Angreifer haben die Anmeldedaten infolge ihrer technischen Kan\u00e4le (TKUIs) abgerufen:<br \/>\nU1.1.9.1. Angreifer haben beobachtet, wie der Benutzer die Anmeldedaten von der Tastatur eingibt:<br \/>\nU1.1.9.1.1 Angreifer befanden sich in unmittelbarer N\u00e4he zum Benutzer und sahen die Eingabe der Anmeldedaten mit eigenen Augen. <br \/>\n<i>Erl\u00e4uterungen U1.1.9.1.1<\/i><br \/>\nZu solchen F\u00e4llen geh\u00f6ren die Handlungen von Kollegen am Arbeitsplatz oder der Fall, dass die Tastatur des Nutzers f\u00fcr die Besucher der Organisation sichtbar ist.<\/p>\n<p>U1.1.9.1.2 Angreifer verwendeten zus\u00e4tzliche technische Mittel wie ein Fernglas oder eine Drohne und sahen die Eingabe von Anmeldedaten durch ein Fenster. <br \/>\nU1.1.9.2. Angreifer erlangten die Anmeldedaten durch das Abfangen von Funk\u00fcbertragungen zwischen der Tastatur und dem Computer, wenn sie \u00fcber eine Funkverbindung (z. B. Bluetooth) verbunden waren.<br \/>\nU1.1.9.3. Angreifer konnten Anmeldedaten abfangen, indem sie diese durch elektromagnetische Strahlung und St\u00f6rungen (PEMIN) erfassten.<br \/>\n<i>Erl\u00e4uterungen U1.1.9.3.<\/i><br \/>\nBeispiele f\u00fcr Angriffe <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=tMSglPLIDYU\">hier<\/a><\/noindex> und <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cl.cam.ac.uk\/~mgk25\/pet2004-fpd.pdf\">hier<\/a><\/noindex>. <\/p>\n<p>U1.1.9.4. Der Angreifer konnte die Eingabe von Anmeldedaten \u00fcber die Tastatur mit speziellen technischen Mitteln (STM) abfangen, die f\u00fcr das heimliche Abgreifen von Informationen bestimmt sind.<br \/>\n<i>Erl\u00e4uterungen U1.1.9.4.<\/i><br \/>\nBeispiele <noindex>Ger\u00e4te<\/noindex>. <\/p>\n<p>U1.1.9.5. Angreifer schnappen die Eingabe von Anmeldedaten \u00fcber die Tastatur ab, indem sie <br \/>\ndas Wi-Fi-Signal analysieren, das durch den Prozess der Tasteneingabe des Benutzers moduliert wird.<br \/>\n<i>Erl\u00e4uterungen U1.1.9.5.<\/i><br \/>\nBeispiel <noindex><a rel=\"nofollow\" href=\"https:\/\/threatpost.com\/keystroke-recognition-uses-wi-fi-signals-to-snoop\/120135\/\">Angriffe<\/a><\/noindex>.<\/p>\n<p>U1.1.9.6. Angreifer schnappen die Eingabe von Anmeldedaten \u00fcber die Tastatur ab, indem sie die Ger\u00e4usche von Tasteneingaben analysieren.<br \/>\n<i>Erl\u00e4uterungen U1.1.9.6.<\/i><br \/>\nBeispiel <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/398545\/\">Angriffe<\/a><\/noindex>.<\/p>\n<p>U1.1.9.7. Angreifer schnappen die Eingabe von Anmeldedaten von mobilen Ger\u00e4ten ab, indem sie die Daten des Beschleunigungssensors analysieren.<br \/>\n<i>Erl\u00e4uterungen U1.1.9.7.<\/i><br \/>\nBeispiel <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/126806\/\">Angriffe<\/a><\/noindex>.<\/p>\n<p>U1.1.10. &lt;&#8230;&gt;, die zuvor auf dem Client gespeichert wurden.<br \/>\n<i>Erl\u00e4uterungen U1.1.10.<\/i><br \/>\nZum Beispiel k\u00f6nnte der Benutzer seinen Benutzernamen und sein Passwort f\u00fcr den Zugang zu einer bestimmten Website im Browser gespeichert haben.<\/p>\n<p>U1.1.11. Angreifer haben Anmeldedaten aufgrund von M\u00e4ngeln im Verfahren zur Widerrufung von Benutzerzug\u00e4ngen kompromittiert.<br \/>\n<i>Erl\u00e4uterungen U1.1.11.<\/i><br \/>\nZum Beispiel blieben die Konten eines Benutzers nach seiner Entlassung ungesperrt.<\/p>\n<p>U1.2. &lt;&#8230;&gt; durch die Ausnutzung von Schwachstellen im Zugriffskontrollsystem.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSRDU2\"><\/a><\/noindex> <\/p>\n<h3>U2. Unbefugte Erh\u00f6hung der Benutzerprivilegien im Informationssystem<\/h3>\n<p>\n<b>Dekomposition<\/b><br \/>\nU2.1 &lt;&#8230;&gt; durch unbefugte \u00c4nderungen der Daten, die Informationen \u00fcber die Benutzerberechtigungen enthalten.<\/p>\n<p>U2.2 &lt;&#8230;&gt; durch die Ausnutzung von Schwachstellen im Zugriffskontrollsystem.<\/p>\n<p>U2.3. &lt;&#8230;&gt; aufgrund von M\u00e4ngeln im Benutzermanagementprozess.<br \/>\n<i>Erkl\u00e4rung U2.3.<\/i><br \/>\nBeispiel 1. Dem Benutzer wurde ein gr\u00f6\u00dferer Zugang gew\u00e4hrt, als er f\u00fcr dienstliche Zwecke ben\u00f6tigte.<br \/>\nBeispiel 2. Nach der Versetzung des Benutzers in eine andere Position wurden die zuvor erteilten Zugriffsrechte nicht entzogen.<\/p>\n<p>\n<noindex><a rel=\"nofollow\" name=\"TMUMI\"><\/a><\/noindex><\/p>\n<h2>TYPISCHES BEDROHUNGSMODELL. INTEGRATIONSMODUL<\/h2>\n<p><\/p>\n<h3>Das Schutzobjekt, f\u00fcr das das Bedrohungsmodell angewendet wird (scope)<\/h3>\n<p>\nDas Integrationsmodul ist eine Reihe von Objekten der Informationsinfrastruktur, die zum Austausch von Informationen zwischen Informationssystemen gedacht sind.<\/p>\n<p>Unter Ber\u00fccksichtigung der Tatsache, dass es in Unternehmensnetzwerken nicht immer m\u00f6glich ist, ein Informationssystem eindeutig von einem anderen zu trennen, kann das Integrationsmodul auch als Verbindungsglied zwischen Komponenten innerhalb eines Informationssystems betrachtet werden.<\/p>\n<p><b>Architektur<\/b><br \/>\nDas allgemeine Schema des Integrationsmoduls sieht wie folgt aus:<\/p>\n<p><img decoding=\"async\" alt=\"Informationssicherheit bei bankgest\u00fctzten bargeldlosen Zahlungen. Teil 8 \u2013 Typische Bedrohungsmodelle\" src=\"\/wp-content\/uploads\/2019\/04\/6b91d59698b761a14aef7f1c4fbec325.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBeschreibung der Architekturelemente:<\/p>\n<ul>\n<li><i>\u201eAustauschserver (AS)\u201c<\/i> \u2013 Knoten \/ Dienst \/ Komponente des Informationssystems, die die Funktion hat, Daten mit einem anderen Informationssystem auszutauschen.<\/li>\n<li><i>\u201eVermittler\u201c<\/i> \u2013 Knoten \/ Dienst, der zur Organisation der Interaktion zwischen Informationssystemen gedacht ist, jedoch nicht Teil dieser Systeme ist. <br \/>\nBeispiele <i>\u201eVermittler\u201c<\/i> k\u00f6nnten Dienste f\u00fcr elektronische Post, Unternehmensdienstbusse (Enterprise Service Bus \/ SoA-Architektur), externe Datei-Server usw. sein. Im allgemeinen Fall kann das Integrationsmodul auch keine \u201eVermittler\u201c enthalten.<\/li>\n<li><i>\u201eDatenverarbeitungssoftware\u201c<\/i> \u2013 Gesamtheit der Programme, die Protokolle f\u00fcr den Austausch von Daten und die Formatumwandlung implementieren. <br \/>\nZum Beispiel die Umwandlung von Daten aus dem UFEBN-Format in das ABS-Format, die \u00c4nderung des Status von Nachrichten w\u00e4hrend der \u00dcbertragung usw.<\/li>\n<li><i>\u201eNetzwerkverbindung\u201c<\/i> entspricht dem Objekt, das im typischen Bedrohungsmodell \u201eNetzwerkverbindung\u201c beschrieben wird. Einige der oben dargestellten Netzwerkverbindungen k\u00f6nnten fehlen.<\/li>\n<\/ul>\n<p><b>Beispiele f\u00fcr Integrationsmodule<\/b><\/p>\n<p><i>Schema 1. Integration von ABS und ARM KBR \u00fcber einen externen Datei-Server<\/i><\/p>\n<p>Um Zahlungen auszuf\u00fchren, l\u00e4dt ein autorisierter Bankmitarbeiter elektronische Zahlungsdokumente aus dem ABS herunter und speichert sie in einer Datei (eigenes Format, z. B. SQL-Dump) auf dem Netzwerkordner (&#8230;SHARE) des Dateiservers. Diese Datei wird dann mit einem Konverter-Skript in eine Reihe von UFEBDS-Dateien umgewandelt, die anschlie\u00dfend von ARM KBR gelesen werden. <br \/>\nNachfolgend verschl\u00fcsselt und signiert der autorisierte Mitarbeiter \u2014 der Benutzer des ARM KBR \u2014 die erhaltene Datei und sendet sie an das Zahlungssystem der Bank von Russland.<\/p>\n<p>Bei Zahlungseing\u00e4ngen von der Bank von Russland entschl\u00fcsselt das ARM KBR diese und \u00fcberpr\u00fcft die elektronische Signatur, bevor sie in Form einer Reihe von Dateien im UFEBS-Format auf den Dateiserver gespeichert werden. Vor dem Import der Zahlungsdokumente in das ABS werden sie mithilfe eines Konverter-Skripts vom UFEBS-Format ins ABS-Format umgewandelt. <\/p>\n<p>Angenommen, in diesem Schema l\u00e4uft das ABS auf einem physischen Server, das ARM KBR auf einem dedizierten Computer und das Konverter-Skript l\u00e4uft auf dem Dateiserver.<\/p>\n<p><img decoding=\"async\" alt=\"Informationssicherheit bei bankgest\u00fctzten bargeldlosen Zahlungen. Teil 8 \u2013 Typische Bedrohungsmodelle\" src=\"\/wp-content\/uploads\/2019\/04\/bef53aaa1deaee5adeca620204345642.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDie Entsprechung der Objekte im betrachteten Schema zu den Elementen des Integrationsmoduls:<br \/>\n<i>\u201eAustauschserver auf der ABS-Seite\u201c<\/i> \u2013 ABS-Server.<br \/>\n<i>\u201eAustauschserver auf der ARM KBR-Seite\u201c<\/i> \u2013 Computer des ARM KBR.<br \/>\n<i>\u201eVermittler\u201c<\/i> \u2013 externer Dateiserver.<br \/>\n<i>\u201eDatenverarbeitungssoftware\u201c<\/i> \u2013 Skript-Konverter.<\/p>\n<p><i>Schema 2. Integration von ABS und ARM KBR durch Bereitstellung eines gemeinsamen Netzwerkordners mit Zahlungen auf ARM KBR<\/i><\/p>\n<p>Alles wie in Schema 1, aber ein separater Dateiserver wird nicht verwendet; stattdessen wird der Netzwerkordner (&#8230;SHARE) mit den elektronischen Zahlungsdokumenten auf dem Computer mit ARM KBR platziert. Das Konverter-Skript funktioniert ebenfalls auf ARM KBR.<\/p>\n<p><img decoding=\"async\" alt=\"Informationssicherheit bei bankgest\u00fctzten bargeldlosen Zahlungen. Teil 8 \u2013 Typische Bedrohungsmodelle\" src=\"\/wp-content\/uploads\/2019\/04\/7d3ecde6d78b2c45e1249236c7da925b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDie Entsprechung der Objekte im betrachteten Schema zu den Elementen des Integrationsmoduls:<br \/>\n\u00c4hnlich wie im Schema 1, aber <i>\u201eVermittler\u201c<\/i> wird nicht verwendet.<\/p>\n<p><i>Schema 3. Integration von ABS und ARM KBR-N \u00fcber IBM WebSphere MQ und signieren elektronischer Dokumente \u201eauf der ABS-Seite\u201c<\/i><\/p>\n<p>ABS l\u00e4uft auf einer Plattform, die von der SKZI SKAD Signature nicht unterst\u00fctzt wird. Die Signatur der ausgehenden elektronischen Dokumente erfolgt auf einem speziellen Server f\u00fcr elektronische Signaturen (EP-Server). Dieser Server \u00fcberpr\u00fcft auch die elektronische Signatur der eingehenden Dokumente von der Bank von Russland.<\/p>\n<p>ABS l\u00e4dt eine Datei mit den Zahlungsdokumenten im eigenen Format auf den EP-Server hoch.<br \/>\nDer EP-Server wandelt die Datei mithilfe eines Konverter-Skripts in elektronische Nachrichten im UFEBS-Format um, danach werden die elektronischen Nachrichten signiert und an IBM WebSphere MQ \u00fcbermittelt.<\/p>\n<p>ARM KBR-N greift auf IBM WebSphere MQ zu und erh\u00e4lt dort die signierten Zahlungsnachrichten, anschlie\u00dfend verschl\u00fcsselt der autorisierte Mitarbeiter \u2014 der Benutzer des ARM KBR \u2014 sie und sendet sie an das Zahlungssystem der Bank von Russland.<\/p>\n<p>Bei der Zahlungseing\u00e4ngen von der Bank Russland entschl\u00fcsselt APM KBR-N diese und pr\u00fcft die elektronische Signatur. Erfolgreich verarbeitete Zahlungen in Form von entschl\u00fcsselten und signierten elektronischen Nachrichten im UFEBS-Format werden an IBM WebSphere MQ weitergeleitet, von wo sie den EP-Server empfangen.<\/p>\n<p>Der EP-Server \u00fcberpr\u00fcft die elektronische Signatur der eingegangenen Zahlungen und speichert sie in einer ABS-Datei. Danach l\u00e4dt ein autorisierter Mitarbeiter \u2014 Nutzer der ABS \u2014 die entstandene Datei gem\u00e4\u00df den festgelegten Verfahren in die ABS hoch.<\/p>\n<p><img decoding=\"async\" alt=\"Informationssicherheit bei bankgest\u00fctzten bargeldlosen Zahlungen. Teil 8 \u2013 Typische Bedrohungsmodelle\" src=\"\/wp-content\/uploads\/2019\/04\/b1bd9c224b18dc84cca5f8bdc7d69713.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDie Entsprechung der Objekte im betrachteten Schema zu den Elementen des Integrationsmoduls:<br \/>\n<i>\u201eAustauschserver seitens ABS\u201c<\/i> \u2013 ABS-Server.<br \/>\n<i>\u201eAustauschserver seitens APM KBR\u201c<\/i> \u2014 Computer APM KBR.<br \/>\n<i>\u201eVermittler\u201c<\/i> \u2013 EP-Server und IBM WebSphere MQ.<br \/>\n<i>\u201eDatenverarbeitungssoftware\u201c<\/i> \u2013 Konvertierungsskript, SKZI SKAD Signatur auf dem EP-Server.<\/p>\n<p><i>Schema 4. Integration des DBO-Servers und ABS \u00fcber die API, die vom dedizierten Austauschserver bereitgestellt wird<\/i><\/p>\n<p>Wir gehen davon aus, dass in der Bank mehrere Systeme f\u00fcr das Internet-Banking (DBO) verwendet werden: <\/p>\n<ul>\n<li>\u201eInternet Client-Bank\u201c f\u00fcr Privatpersonen (IKB FL);<\/li>\n<li>\u201eInternet Client-Bank\u201c f\u00fcr juristische Personen (IKB JL). <\/li>\n<\/ul>\n<p>\nZur Gew\u00e4hrleistung der Informationssicherheit erfolgt die gesamte Interaktion der ABS mit den DBO-Systemen \u00fcber einen dedizierten Austauschserver, der im Rahmen des Informationssystems \u201eABS\u201c arbeitet.<\/p>\n<p>Betrachten wir nun den Interaktionsprozess des DBO-Systems IKB JL mit der ABS.<br \/>\nDer DBO-Server muss aufgrund des ordnungsgem\u00e4\u00df beglaubigten Zahlungsauftrags, den er vom Kunden erhalten hat, das entsprechende Dokument in der ABS erstellen. Dazu \u00fcbertr\u00e4gt er \u00fcber die API die Informationen an den Austauschserver, der die Daten wiederum in die ABS einf\u00fcgt. <\/p>\n<p>Bei \u00c4nderungen der Kontost\u00e4nde des Kunden generiert die ABS elektronische Benachrichtigungen, die \u00fcber den Austauschserver an den DBO-Server gesendet werden.<\/p>\n<p><img decoding=\"async\" alt=\"Informationssicherheit bei bankgest\u00fctzten bargeldlosen Zahlungen. Teil 8 \u2013 Typische Bedrohungsmodelle\" src=\"\/wp-content\/uploads\/2019\/04\/63f88ad151996e7ddaa883349a6d8e22.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDie Entsprechung der Objekte im betrachteten Schema zu den Elementen des Integrationsmoduls:<br \/>\n<i>\u201eAustauschserver seitens DBO\u201c<\/i> \u2013 DBO-Server IKB JL.<br \/>\n<i>\u201eAustauschserver seitens ABS\u201c<\/i> \u2013 Austauschserver.<br \/>\n<i>\u201eVermittler\u201c<\/i> \u2013 nicht vorhanden.<br \/>\n<i>\u201eDatenverarbeitungssoftware\u201c<\/i> \u2013 Komponenten des DBO-Servers, die f\u00fcr die Nutzung der API des Austauschservers verantwortlich sind, Komponenten des Austauschservers, die f\u00fcr die Nutzung der API der ABS verantwortlich sind.<\/p>\n<h3>Sicherheitsbedrohungen auf oberster Ebene<\/h3>\n<p>\n<b>Dekomposition<\/b><br \/>\nU1. Einschleusung von gef\u00e4lschten Informationen durch Angreifer \u00fcber das Integrationsmodul. <br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUMIU1\"><\/a><\/noindex><\/p>\n<h3>U1. Einschleusung von gef\u00e4lschten Informationen durch Angreifer \u00fcber das Integrationsmodul <\/h3>\n<p><b>Dekomposition<\/b><br \/>\nU1.1. Unbefugte Modifizierung legitimer Daten bei deren \u00dcbertragung \u00fcber Netzwerkverbindungen:<br \/>\nU1.1.1 Link: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUNCU2\">\u201eTypisches Bedrohungsmodell. Netzwerkverbindung. U2. Unbefugte Modifikation \u00fcbertragener Daten\u201c<\/a><\/noindex>.<\/p>\n<p>U1.2. \u00dcbertragung von gef\u00e4lschten Daten im Namen eines legitimen Teilnehmers des Austauschs:<br \/>\nU1.1.2 Link: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUNCU3\">\u201eTypisches Bedrohungsmodell. Netzwerkverbindung. U3. Verletzung des Urheberrechts \u00fcbertragener Daten\u201c<\/a><\/noindex>.<\/p>\n<p>U1.3. Unbefugte Modifikation legitimer Daten bei deren Verarbeitung auf Austausch-Servern oder durch einen Mittelsmann:<br \/>\nU1.3.1. Link: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUISU2\">\u201eTypisches Bedrohungsmodell. Informationssystem, das auf der Client-Server-Architektur basiert. U2. Unbefugte Modifikation gesch\u00fctzter Informationen w\u00e4hrend ihrer Verarbeitung durch den Serverteil des Informationssystems\u201c<\/a><\/noindex>.<\/p>\n<p>U1.4. Erstellung gef\u00e4lschter Daten auf Austausch-Servern oder durch einen Mittelsmann im Namen eines legitimen Teilnehmers des Austauschs:<br \/>\nU1.4.1. Link: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUISU1\">\u201eTypisches Bedrohungsmodell. Informationssystem, das auf der Client-Server-Architektur basiert. U1. Durchf\u00fchrung unbefugter Handlungen durch Angreifer im Namen eines legitimen Benutzers.\u201c<\/a><\/noindex><\/p>\n<p>U1.5. Unbefugte Modifikation von Daten bei deren Verarbeitung mit Hilfe von Datenverarbeitungssoftware:<br \/>\nU1.5.1. &lt;&#8230;&gt; durch nicht autorisierte \u00c4nderungen an den Einstellungen (Konfiguration) der Datenverarbeitungssoftware durch Angreifer.<br \/>\nU1.5.2. &lt;&#8230;&gt; durch nicht autorisierte \u00c4nderungen an den ausf\u00fchrbaren Dateien der Datenverarbeitungssoftware durch Angreifer.<br \/>\nU1.5.3. &lt;&#8230;&gt; durch interaktive Steuerung der Datenverarbeitungssoftware durch Angreifer.<\/p>\n<p>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZI\"><\/a><\/noindex><\/p>\n<h2>TYPISCHES BEDROHUNGSMODELL. SYSTEM ZUR KRYPTOGRAPHISCHEN SCHUTZ VON INFORMATIONEN<\/h2>\n<p><\/p>\n<h3>Das Schutzobjekt, f\u00fcr das das Bedrohungsmodell angewendet wird (scope)<\/h3>\n<p>\nDas Objekt des Schutzes ist ein System zur kryptographischen Sicherung von Informationen, das zur Gew\u00e4hrleistung der Sicherheit des Informationssystems eingesetzt wird.<\/p>\n<p><b>Architektur<\/b><br \/>\nDie Grundlage jedes Informationssystems ist die Anwendungssoftware (AS), die ihre Zielsetzung umsetzt. <\/p>\n<p>Kryptographischer Schutz wird in der Regel realisiert, indem kryptographische Primitiven zur Anwendung aus der Gesch\u00e4ftslogik der Anwendungssoftware aufgerufen werden, die in speziellen Bibliotheken \u2013 Krypto-Kernen \u2013 abgelegt sind.<\/p>\n<p>Zu den kryptographischen Primitiven geh\u00f6ren niedrigstufige kryptographische Funktionen wie:<\/p>\n<ul>\n<li>Datenbl\u00f6cke verschl\u00fcsseln \/ entschl\u00fcsseln;<\/li>\n<li>Digitale Signaturen f\u00fcr Datenbl\u00f6cke erstellen \/ \u00fcberpr\u00fcfen;<\/li>\n<li>Hash-Funktionen f\u00fcr Datenbl\u00f6cke berechnen;<\/li>\n<li>Schl\u00fcsselinformationen erzeugen \/ laden \/ entladen;<\/li>\n<li>usw.<\/li>\n<\/ul>\n<p>\nDie Gesch\u00e4ftslogik der Anwendungssoftware realisiert mit Hilfe kryptographischer Primitiven h\u00f6herstufige Funktionalit\u00e4ten:<\/p>\n<ul>\n<li>Dateien mit Schl\u00fcsseln der gew\u00e4hlten Empf\u00e4nger verschl\u00fcsseln;<\/li>\n<li>eine sichere Netzwerkverbindung herstellen;<\/li>\n<li>\u00fcber die Ergebnisse der \u00dcberpr\u00fcfung der elektronischen Signatur informieren;<\/li>\n<li>u.\u00e4.<\/li>\n<\/ul>\n<p>\nDie Interaktion der Gesch\u00e4ftslogik mit dem Kryptokern kann erfolgen:<\/p>\n<ul>\n<li>direkt, durch den Aufruf kryptografischer Primitiven aus dynamischen Bibliotheken des Kryptokerns (.DLL \u2013 f\u00fcr Windows, .SO \u2013 f\u00fcr Linux);<\/li>\n<li>indirekt, \u00fcber kryptografische Schnittstellen \u2013 Wrapper, wie z. B. MS Crypto API, Java Cryptography Architecture, PKCS#11 usw. In diesem Fall wendet sich die Gesch\u00e4ftslogik an die Kryptoschnittstelle, die den Aufruf an den entsprechenden Kryptokern weiterleitet, der in diesem Fall als Kryptoprotektor bezeichnet wird. Die Verwendung kryptografischer Schnittstellen erm\u00f6glicht es der Anwendungssoftware, sich von spezifischen kryptografischen Algorithmen zu abstrahieren und flexibler zu sein.<\/li>\n<\/ul>\n<p>\nEs lassen sich zwei typische Organisationen des Kryptokerns unterscheiden:<\/p>\n<p><i>Schema 1 \u2013 Monolithischer Kryptokern<\/i><br \/>\n<img decoding=\"async\" alt=\"Informationssicherheit bei bankgest\u00fctzten bargeldlosen Zahlungen. Teil 8 \u2013 Typische Bedrohungsmodelle\" src=\"\/wp-content\/uploads\/2019\/04\/e5186d11e4e0e9ad9361f3935228bc30.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>Schema 2 \u2013 Geteilter Kryptokern<\/i><br \/>\n<img decoding=\"async\" alt=\"Informationssicherheit bei bankgest\u00fctzten bargeldlosen Zahlungen. Teil 8 \u2013 Typische Bedrohungsmodelle\" src=\"\/wp-content\/uploads\/2019\/04\/9953d524fbee78d7e4eb917e9d56a38f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDie Elemente der dargestellten Schemata k\u00f6nnen sowohl separate Softwaremodule, die auf einem Computer arbeiten, als auch Netzservices sein, die im Rahmen eines Rechennetzwerks interagieren.<\/p>\n<p>Bei der Verwendung von Systemen, die nach Schema 1 aufgebaut sind, arbeiten Anwendungssoftware und Kryptokern innerhalb einer einheitlichen Umgebung f\u00fcr den Betrieb des Kryptomittels (SFK), z. B. auf demselben Computer, unter derselben Betriebssystemverwaltung. Der Nutzer des Systems kann in der Regel auch andere Programme in derselben Umgebung ausf\u00fchren, einschlie\u00dflich solcher mit sch\u00e4dlichem Code. Unter diesen Bedingungen besteht ein erhebliches Risiko f\u00fcr die Offenlegung geheimer kryptografischer Schl\u00fcssel.<\/p>\n<p>Um das Risiko zu minimieren, verwenden wir Schema 2, bei dem der Kryptokern in zwei Teile geteilt wird:<\/p>\n<ol>\n<li>Der erste Teil arbeitet zusammen mit der Anwendungssoftware in einer unsicheren Umgebung, in der das Risiko einer Infektion mit sch\u00e4dlichem Code besteht. Wir nennen diesen Teil \u2013 \"Softwareteil\".<\/li>\n<li>Der zweite Teil arbeitet in einer vertrauensw\u00fcrdigen Umgebung auf einem dedizierten Ger\u00e4t, das einen geheimen Schl\u00fcssel speichert. Wir nennen diesen Teil \u2013 \"Hardwareteil\".<\/li>\n<\/ol>\n<p>\nDie Trennung des Krypto-Kerns in Software- und Hardware-Komponenten ist recht willk\u00fcrlich. Auf dem Markt gibt es Systeme, die nach dem Prinzip des geteilten Krypto-Kerns aufgebaut sind, bei denen die \"Hardware\"-Komponente jedoch in Form eines Abbilds einer virtuellen Maschine - virtual HSM - pr\u00e4sentiert wird.<noindex><a rel=\"nofollow\" href=\"https:\/\/www.unboundtech.com\/product\/unbound-key-control\/\">Beispiel<\/a><\/noindex>).<\/p>\n<p>Die Interaktion beider Teile des Krypto-Kerns erfolgt so, dass geheimen kryptografischen Schl\u00fcssel niemals an den Software-Teil \u00fcbermittelt werden und folglich nicht durch sch\u00e4dlichen Code gestohlen werden k\u00f6nnen.<\/p>\n<p>Die Schnittstelle (API) zur Interaktion und die Menge der kryptografischen Primitiven, die das Krypto-Kern der Anwendungssoftware bereitstellt, sind in beiden F\u00e4llen identisch. Der Unterschied liegt in der Art und Weise ihrer Umsetzung.<\/p>\n<p>So erfolgt bei der Verwendung des geteilten Krypto-Kern-Prinzips die Interaktion zwischen Software- und Hardware-Anteil nach folgendem Prinzip:<\/p>\n<ol>\n<li>Kryptografische Primitiven, die keinen geheimen Schl\u00fcssel ben\u00f6tigen (z.B. Berechnung von Hash-Funktionen, \u00dcberpr\u00fcfung von digitalen Signaturen usw.), werden durch den Software-Anteil ausgef\u00fchrt.<\/li>\n<li>Kryptografische Primitiven, die einen geheimen Schl\u00fcssel verwenden (Erstellung digitaler Signaturen, Entschl\u00fcsselung von Daten usw.), werden durch den Hardware-Anteil ausgef\u00fchrt.<\/li>\n<\/ol>\n<p>\nWir veranschaulichen die Arbeit des geteilten Krypto-Kerns am Beispiel der Erstellung einer digitalen Signatur:<\/p>\n<ol>\n<li>Der Software-Anteil berechnet die Hash-Funktion der zu signierenden Daten und \u00fcbertr\u00e4gt diesen Wert \u00fcber den Austauschkanal zwischen den Krypto-Kernen an den Hardware-Anteil.<\/li>\n<li>Der Hardware-Anteil, unter Verwendung des geheimen Schl\u00fcssels und des Hashes, formt den Wert der digitalen Signatur und \u00fcbertr\u00e4gt ihn \u00fcber den Austauschkanal an den Software-Anteil.<\/li>\n<li>Der Software-Anteil gibt den erhaltenen Wert an die Anwendungssoftware zur\u00fcck.<\/li>\n<\/ol>\n<p>\n<b>Merkmale der \u00dcberpr\u00fcfung der G\u00fcltigkeit der digitalen Signatur.<\/b><\/p>\n<p>Wenn die empfangende Seite Daten erh\u00e4lt, die mit einer digitalen Signatur versehen sind, muss sie mehrere \u00dcberpr\u00fcfungsschritte durchf\u00fchren. Ein positives Ergebnis der \u00dcberpr\u00fcfung der digitalen Signatur wird nur durch die erfolgreiche Durchf\u00fchrung aller \u00dcberpr\u00fcfungsschritte erreicht.<\/p>\n<p><i>Schritt 1. \u00dcberpr\u00fcfung der Datenintegrit\u00e4t und Urheberschaft der Daten.<\/i><\/p>\n<p><u>Inhalt des Schrittes.<\/u> Die \u00dcberpr\u00fcfung der elektronischen Signatur der Daten erfolgt gem\u00e4\u00df dem entsprechenden kryptographischen Algorithmus. Das erfolgreiche Bestehen dieser Phase zeigt an, dass die Daten seit ihrer Unterzeichnung nicht ver\u00e4ndert wurden und dass die Signatur mit dem privaten Schl\u00fcssel erstellt wurde, der dem \u00f6ffentlichen Schl\u00fcssel zur \u00dcberpr\u00fcfung der elektronischen Signatur entspricht.<br \/>\n<u>Durchf\u00fchrungsort der Phase:<\/u> Krypto-Kern.<\/p>\n<p><i>Phase 2. Kontrolle des Vertrauens in den \u00f6ffentlichen Schl\u00fcssel des Unterzeichners und Kontrolle der G\u00fcltigkeitsdauer des privaten Schl\u00fcssels der elektronischen Signatur.<\/i><br \/>\n<u>Inhalt des Schrittes.<\/u> Die Phase besteht aus zwei Zwischenphasen. In der ersten wird festgestellt, ob der \u00f6ffentliche Schl\u00fcssel zur \u00dcberpr\u00fcfung der elektronischen Signatur zum Zeitpunkt der Datenunterzeichnung vertrauensw\u00fcrdig war. In der zweiten wird festgestellt, ob der private Schl\u00fcssel der elektronischen Signatur zum Zeitpunkt der Datenunterzeichnung g\u00fcltig war. In der Regel k\u00f6nnen die G\u00fcltigkeitsdauern dieser Schl\u00fcssel unterschiedlich sein (zum Beispiel f\u00fcr qualifizierte Zertifikate der Schl\u00fcssel zur \u00dcberpr\u00fcfung der elektronischen Signatur). Die Methoden zur Feststellung des Vertrauens in den \u00f6ffentlichen Schl\u00fcssel des Unterzeichners werden durch die im elektronischen Dokumentenaustausch festgelegten Regeln bestimmt, die von den beteiligten Parteien angenommen wurden.<br \/>\n<u>Durchf\u00fchrungsort der Phase:<\/u> Anwendungssoftware \/ Krypto-Kern.<\/p>\n<p><i>Phase 3. Kontrolle der Befugnisse des Unterzeichners.<\/i><br \/>\n<u>Inhalt des Schrittes.<\/u> Gem\u00e4\u00df den festgelegten Regeln des elektronischen Dokumentenaustauschs wird \u00fcberpr\u00fcft, ob der Unterzeichner das Recht hatte, die gesch\u00fctzten Daten zu best\u00e4tigen. Nehmen wir als Beispiel eine Situation, in der die Befugnisse verletzt wurden. Angenommen, es gibt eine Organisation, in der alle Mitarbeiter eine elektronische Signatur haben. Ein Befehl des Chefs wird im internen System des elektronischen Dokumentenaustauschs eingegeben, jedoch von der elektronischen Signatur des Lagerleiters unterzeichnet. Dementsprechend kann ein solches Dokument nicht als legitim betrachtet werden.<br \/>\n<u>Durchf\u00fchrungsort der Phase:<\/u> Anwendungssoftware.<\/p>\n<p><b>Annahmen, die bei der Beschreibung des Schutzobjekts getroffen wurden.<\/b><\/p>\n<ol>\n<li>Die Informations\u00fcbertragungswege, mit Ausnahme der Kan\u00e4le zum Austausch von Schl\u00fcsseln, verlaufen ebenfalls \u00fcber die Anwendungssoftware, API und Krypto-Kern.<\/li>\n<li>Informationen \u00fcber das Vertrauen in die \u00f6ffentlichen Schl\u00fcssel und\/oder Zertifikate sowie Informationen \u00fcber die Befugnisse der Inhaber der \u00f6ffentlichen Schl\u00fcssel werden im Schl\u00fcsselverzeichnis gespeichert.<\/li>\n<li>Die Anwendungssoftware arbeitet \u00fcber den Krypto-Kern mit dem Schl\u00fcsselverzeichnis.<\/li>\n<\/ol>\n<p><\/p>\n<h3>Beispiel eines Informationssystems, das mit Hilfe von SKZI gesch\u00fctzt ist.<\/h3>\n<p>\nUm die zuvor dargelegten Systemschemata zu veranschaulichen, betrachten wir ein hypothetisches Informationssystem und heben alle strukturellen Elemente hervor. <\/p>\n<p><b>Beschreibung des Informationssystems<\/b><\/p>\n<p><img decoding=\"async\" alt=\"Informationssicherheit bei bankgest\u00fctzten bargeldlosen Zahlungen. Teil 8 \u2013 Typische Bedrohungsmodelle\" src=\"\/wp-content\/uploads\/2019\/04\/74f3e2fd669ed97f50253fbb4b348f6f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nZwei Organisationen haben beschlossen, einen rechtlich verbindlichen elektronischen Dokumentenaustausch (EDO) einzuf\u00fchren. Zu diesem Zweck haben sie eine Vereinbarung getroffen, in der festgelegt wurde, dass Dokumente per E-Mail \u00fcbermittelt werden, wobei diese verschl\u00fcsselt und mit einer qualifizierten elektronischen Signatur versehen sein m\u00fcssen. Zur Erstellung und Bearbeitung der Dokumente sollen B\u00fcroanwendungen aus dem Paket Microsoft Office 2016 verwendet werden, und als Mittel zur kryptografischen Sicherheit sind die SKZI KryptoPRO und die Verschl\u00fcsselungssoftware KryptoARM vorgesehen.<\/p>\n<p><b>Beschreibung der Infrastruktur der Organisation 1<\/b><\/p>\n<p>Organisation 1 hat beschlossen, die SKZI KryptoPRO und die Software KryptoARM auf dem Arbeitsplatzrechner \u2013 dem physischen Computer \u2013 zu installieren. Die Schl\u00fcssel f\u00fcr die Verschl\u00fcsselung und elektronische Signatur werden auf einem Schl\u00fcsseltr\u00e4ger ruToken gespeichert, der im Modus des entnehmbaren Schl\u00fcssels arbeitet. Der Benutzer wird elektronische Dokumente lokal auf seinem Computer erstellen, diese dann verschl\u00fcsseln, signieren und \u00fcber einen lokal installierten E-Mail-Client versenden.<\/p>\n<p><b>Beschreibung der Infrastruktur der Organisation 2<\/b><\/p>\n<p>Organisation 2 hat beschlossen, die Funktionen der Verschl\u00fcsselung und elektronischen Signatur auf eine dedizierte virtuelle Maschine auszulagern. Alle kryptografischen Operationen werden dabei automatisch durchgef\u00fchrt. <\/p>\n<p>Hierzu werden auf einer dedizierten virtuellen Maschine zwei Netzwerkordner eingerichtet: &#171;&#8230;In&#187;, &#171;&#8230;Out&#187;. Im Netzwerkordner &#171;&#8230;In&#187; werden automatisch die vom Auftragnehmer erhaltenen Dateien im offenen Format abgelegt. Diese Dateien werden entschl\u00fcsselt, und ihre elektronische Signatur wird \u00fcberpr\u00fcft.<\/p>\n<p>In den Ordner &#171;&#8230;Out&#187; wird der Benutzer Dateien ablegen, die verschl\u00fcsselt, signiert und an den Vertragspartner gesendet werden m\u00fcssen. Die Dateien selbst wird der Benutzer auf seinem Arbeitsplatz vorbereiten.<br \/>\nZur Durchf\u00fchrung der Funktionen der Verschl\u00fcsselung und elektronischen Signatur sind auf der virtuellen Maschine SKZI KryptoPRO, die Software KryptoARM und ein E-Mail-Client installiert. Die automatische Verwaltung aller Elemente der virtuellen Maschine erfolgt durch Skripte, die von Systemadministratoren entwickelt wurden. Die Ausf\u00fchrung der Skripte wird in Protokolldateien (Logs) dokumentiert.<\/p>\n<p>Die kryptografischen Schl\u00fcssel der elektronischen Signatur werden auf dem tokens mit dem nicht entziehbaren JaCarta GOST-Schl\u00fcssel abgelegt, den der Benutzer mit seinem lokalen Computer verbinden wird.<\/p>\n<p>Das Token wird mit Hilfe spezialisierter Software-Tools USB-over-IP, die auf der Benutzer-ARM und auf der virtuellen Maschine installiert sind, an die virtuelle Maschine weitergeleitet.<\/p>\n<p>Die Systemuhren auf der Benutzer-ARM in Organisation 1 werden manuell eingestellt. Die Systemuhren der spezialisierten virtuellen Maschine in Organisation 2 werden mit den Systemuhren des Hypervisors synchronisiert, der wiederum \u00fcber das Internet mit \u00f6ffentlichen Zeitservern synchronisiert wird.<\/p>\n<p><b>Identifikation der strukturellen Elemente des SKZI<\/b><br \/>\nAuf der Basis der obigen Beschreibung der IT-Infrastruktur identifizieren wir die strukturellen Elemente des SKZI und tragen diese in eine Tabelle ein.<\/p>\n<p><i>Tabelle \u2013 Entsprechung der SKZI-Modell-Elemente zu den Elementen der Informationssysteme<\/i> <\/p>\n<p><b>Bezeichnung des Elements<\/b><br \/>\n<b>Organisation 1<\/b><br \/>\n<b>Organisation 2<\/b><\/p>\n<p>Anwendungssoftware<br \/>\nCryptoARM-Software<br \/>\nCryptoARM-Software<\/p>\n<p>Software-Teil des Kryptokerns<br \/>\nSKZI CryptoPro CSP<br \/>\nSKZI CryptoPro CSP<\/p>\n<p>Hardware-Teil des Kryptokerns<br \/>\nkomplett.<br \/>\nJaCarta GOST<\/p>\n<p>API<br \/>\nMS CryptoAPI<br \/>\nMS CryptoAPI<\/p>\n<p>Schl\u00fcssel-Speicher<br \/>\nBenutzer-ARM:<br \/>\n \u2014 Festplatte;<br \/>\n \u2014 Standardzertifikatsspeicher von Windows.<br \/>\nHypervisor:<br \/>\n \u2014 Festplatte.<\/p>\n<p>Virtuelle Maschine:<br \/>\n \u2014 Festplatte;<br \/>\n \u2014 Standardzertifikatsspeicher von Windows.<\/p>\n<p>Geheimspeicher<br \/>\nSchl\u00fcsselspeicher ruToken, der im entziehbaren Schl\u00fcsselmodus arbeitet<br \/>\nSchl\u00fcsselspeicher JaCarta GOST, der im nicht entziehbaren Schl\u00fcsselmodus arbeitet<\/p>\n<p>Kanal zum Austausch \u00f6ffentlicher Schl\u00fcssel<br \/>\nBenutzer-ARM:<br \/>\n \u2014 Arbeitsspeicher.<\/p>\n<p>Hypervisor:<br \/>\n \u2014 Arbeitsspeicher.<\/p>\n<p>Virtuelle Maschine:<br \/>\n \u2014 Arbeitsspeicher.<\/p>\n<p>Kanal zum Austausch geheime Schl\u00fcssel<br \/>\nBenutzer-ARM:<br \/>\n \u2014 USB-Bus;<br \/>\n \u2014 Arbeitsspeicher.<br \/>\nkomplett.<\/p>\n<p>Kanal zum Austausch zwischen Kryptokernen<br \/>\nfehlt (es gibt keinen Hardware-Teil des Kryptokerns)<br \/>\nBenutzer-ARM:<br \/>\n \u2014 USB-Bus;<br \/>\n \u2014 Arbeitsspeicher;<br \/>\n \u2014 USB-over-IP-Softwaremodul;<br \/>\n \u2014 Netzwerk-Schnittstelle.<\/p>\n<p>Unternehmensnetzwerk von Organisation 2.<\/p>\n<p>Hypervisor:<br \/>\n \u2014 Arbeitsspeicher;<br \/>\n \u2014 Netzwerk-Schnittstelle.<\/p>\n<p>Virtuelle Maschine:<br \/>\n \u2014 Netzwerk-Schnittstelle;<br \/>\n \u2014 Arbeitsspeicher;<br \/>\n \u2014 USB-over-IP-Softwaremodul.<\/p>\n<p>Kanal zum Austausch \u00f6ffentlicher Daten<br \/>\nBenutzer-ARM:<br \/>\n \u2014 Eingabe-\/Ausgabemittel;<br \/>\n \u2014 Arbeitsspeicher;<br \/>\n \u2014 Festplatte.<br \/>\nBenutzer-ARM:<br \/>\n \u2014 Eingabe-\/Ausgabemittel;<br \/>\n \u2014 Arbeitsspeicher;<br \/>\n \u2014 Festplatte;<br \/>\n \u2014 Netzwerk-Schnittstelle.<\/p>\n<p>Unternehmensnetzwerk von Organisation 2.<\/p>\n<p>Hypervisor:<br \/>\n \u2014 Netzwerk-Schnittstelle; <br \/>\n \u2014 Arbeitsspeicher;<br \/>\n \u2014 Festplatte.<\/p>\n<p>Virtuelle Maschine: <br \/>\n \u2014 Netzwerk-Schnittstelle; <br \/>\n \u2014 Arbeitsspeicher;<br \/>\n \u2014 Festplatte.<\/p>\n<p>Kanal zum Austausch gesch\u00fctzte Daten<br \/>\nInternet.<\/p>\n<p>Unternehmensnetzwerk von Organisation 1.<\/p>\n<p>Benutzer-ARM:<br \/>\n \u2014 Festplatte;<br \/>\n \u2014 Arbeitsspeicher;<br \/>\n \u2014 Netzwerk-Schnittstelle.<\/p>\n<p>Internet.<\/p>\n<p>Unternehmensnetzwerk von Organisation 2.<\/p>\n<p>Hypervisor:<br \/>\n \u2014 Netzwerk-Schnittstelle; <br \/>\n \u2014 Arbeitsspeicher;<br \/>\n \u2014 Festplatte.<\/p>\n<p>Virtuelle Maschine: <br \/>\n \u2014 Netzwerk-Schnittstelle; <br \/>\n \u2014 Arbeitsspeicher;<br \/>\n \u2014 Festplatte.<\/p>\n<p>Kanal zur \u00dcbertragung von Zeit<br \/>\nBenutzer-ARM:<br \/>\n \u2014 Eingabe-\/Ausgabemittel;<br \/>\n \u2014 Arbeitsspeicher;<br \/>\n \u2014 Systemtimer.<\/p>\n<p>Internet. <br \/>\nUnternehmensnetzwerk von Organisation 2,<\/p>\n<p>Hypervisor:<br \/>\n \u2014 Netzwerk-Schnittstelle;<br \/>\n \u2014 Arbeitsspeicher;<br \/>\n \u2014 Systemtimer.<\/p>\n<p>Virtuelle Maschine:<br \/>\n \u2014 Arbeitsspeicher;<br \/>\n \u2014 Systemtimer.<\/p>\n<p>Kanal zur \u00dcbertragung von Steuerbefehlen<br \/>\nBenutzer-ARM:<br \/>\n \u2014 Eingabe-\/Ausgabemittel;<br \/>\n \u2014 Arbeitsspeicher.<\/p>\n<p>(Grafische Benutzeroberfl\u00e4che der CryptoARM-Software)<\/p>\n<p>Virtuelle Maschine:<br \/>\n \u2014 Arbeitsspeicher;<br \/>\n \u2014 Festplatte.<\/p>\n<p>(Automatisierungsskripte)<\/p>\n<p>Kanal zum Empfang der Arbeitsergebnisse<br \/>\nBenutzer-ARM:<br \/>\n \u2014 Eingabe-\/Ausgabemittel;<br \/>\n \u2014 Arbeitsspeicher.<\/p>\n<p>(Grafische Benutzeroberfl\u00e4che der CryptoARM-Software)<\/p>\n<p>Virtuelle Maschine:<br \/>\n \u2014 Arbeitsspeicher;<br \/>\n \u2014 Festplatte.<\/p>\n<p>(Protokolldateien der Arbeitsprotokolle der Automatisierungsskripte)<\/p>\n<p><\/p>\n<h3>Sicherheitsbedrohungen auf oberster Ebene<\/h3>\n<p>\n<b>Erl\u00e4uterungen<\/b><\/p>\n<p>Annahmen, die bei der Zerlegung von Bedrohungen getroffen wurden:<\/p>\n<ol>\n<li>Es werden robuste kryptografische Algorithmen verwendet.<\/li>\n<li>Kryptografische Algorithmen werden sicher in den richtigen Betriebsmodi verwendet (zum Beispiel, <noindex><a rel=\"nofollow\" href=\"http:\/\/cryptowiki.net\/index.php?title=Electronic_Code_Book\">ECB<\/a><\/noindex> wird nicht zum Verschl\u00fcsseln gro\u00dfer Datenmengen angewendet, dabei wird die zul\u00e4ssige Belastung des Schl\u00fcssels ber\u00fccksichtigt usw.).<\/li>\n<li>Angreifern sind alle eingesetzten Algorithmen, Protokolle und \u00f6ffentlichen Schl\u00fcssel bekannt.<\/li>\n<li>Angreifern sind alle verschl\u00fcsselten Daten zug\u00e4nglich.<\/li>\n<li>Angreifer sind in der Lage, beliebige Programmelemente im System zu reproduzieren.<\/li>\n<\/ol>\n<p>\n<b>Dekomposition<\/b><\/p>\n<p>U1. Kompromittierung geheimer kryptografischer Schl\u00fcssel.<br \/>\nU2. Verschl\u00fcsselung gef\u00e4lschter Daten im Namen eines legitimen Absenders.<br \/>\nU3. Entschl\u00fcsselung von verschl\u00fcsselten Daten durch Personen, die nicht die legitimen Empf\u00e4nger der Daten sind (Angreifer).<br \/>\nU4. Erstellung einer elektronischen Unterschrift des legitimen Unterzeichners unter gef\u00e4lschten Daten.<br \/>\nU5. Erhalten eines positiven Ergebnisses der \u00dcberpr\u00fcfung der elektronischen Unterschrift unter gef\u00e4lschten Daten.<br \/>\nU6. Falsche Annahme von elektronischen Dokumenten aufgrund von Problemen in der Organisation des elektronischen Dokumentenverkehrs.<br \/>\nU7. Unbefugter Zugriff auf gesch\u00fctzte Daten w\u00e4hrend ihrer Verarbeitung durch Krypto-Schutzsysteme.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIU1\"><\/a><\/noindex><\/p>\n<h3>U1. Kompromittierung geheimer kryptografischer Schl\u00fcssel<\/h3>\n<p>\nU1.1. Erhalt des privaten Schl\u00fcssels aus dem Tresor der geheimen Schl\u00fcssel.<\/p>\n<p>U1.2. Erhalt des privaten Schl\u00fcssels aus Elementen der Betriebsumgebung des Kryptosystems, in denen er sich vor\u00fcbergehend befinden kann.<br \/>\n<i>Erl\u00e4uterungen zu U1.2.<\/i><\/p>\n<p>Zu den Elementen, in denen der private Schl\u00fcssel vor\u00fcbergehend gespeichert werden kann, geh\u00f6ren:<\/p>\n<ol>\n<li>RAM, <\/li>\n<li>tempor\u00e4re Dateien, <\/li>\n<li>Auslagerungsdateien, <\/li>\n<li>Hibernation-Dateien, <\/li>\n<li>Snapshot-Dateien des \u201ehei\u00dfen\u201c Zustands von virtuellen Maschinen, einschlie\u00dflich der Dateien des Inhalts des RAM von pausierten virtuellen Maschinen.<\/li>\n<\/ol>\n<p>\nU1.2.1. Extraktion geheimer Schl\u00fcssel aus laufendem RAM durch das Einfrieren von RAM-Modulen, deren Entnahme und anschlie\u00dfendes Auslesen der Daten (Freeze-Angriff).<br \/>\n<i>Erl\u00e4uterungen zu U1.2.1.<\/i><br \/>\nBeispiel <noindex><a rel=\"nofollow\" href=\"https:\/\/www.securitylab.ru\/analytics\/452899.php\">Angriffe<\/a><\/noindex>. <\/p>\n<p>U1.3. Erhalt des privaten Schl\u00fcssels aus dem Kanal f\u00fcr den Austausch geheimer Schl\u00fcssel.<br \/>\n<i>Erl\u00e4uterungen zu U1.3.<\/i><br \/>\nEin Beispiel f\u00fcr die Umsetzung dieser Bedrohung wird gegeben <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIA3\">unten<\/a><\/noindex>.<\/p>\n<p>U1.4. Unbefugte Modifizierung des Kryptokernels, durch die geheime Schl\u00fcssel den Angreifern bekannt werden.<\/p>\n<p>U1.5. Die Kompromittierung des privaten Schl\u00fcssels durch die Nutzung technischer Informationslecks (TKUI).<br \/>\n<i>Erl\u00e4uterungen zu U1.5.<\/i><br \/>\nBeispiel <noindex><a rel=\"nofollow\" href=\"https:\/\/www.usenix.org\/system\/files\/conference\/usenixsecurity18\/sec18-alam.pdf\">Angriffe<\/a><\/noindex>. <\/p>\n<p>U1.6. Die Kompromittierung des privaten Schl\u00fcssels durch die Verwendung spezieller technischer Mittel (STM), die f\u00fcr die heimliche Abh\u00f6rung von Informationen (\u201eAbh\u00f6rger\u00e4te\u201c) bestimmt sind.<\/p>\n<p>U1.7. Die Kompromittierung von privaten Schl\u00fcsseln w\u00e4hrend ihrer Lagerung au\u00dferhalb von SKZI.<br \/>\n<i>Erl\u00e4uterungen zu U1.7.<\/i><br \/>\nZum Beispiel verstaut der Benutzer seine Schl\u00fcsseltr\u00e4ger in einer Schreibtischschublade, aus der sie leicht von Angreifern entnommen werden k\u00f6nnen.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIU2\"><\/a><\/noindex><\/p>\n<h3>U2. Verschl\u00fcsselung gef\u00e4lschter Daten im Namen eines legitimen Absenders.<\/h3>\n<p>\n<b>Erl\u00e4uterungen<\/b><br \/>\nDiese Bedrohung wird nur f\u00fcr Verschl\u00fcsselungsschemata mit Absenderauthentifizierung betrachtet. Beispiele solcher Schemata sind in den Standardisierungsempfehlungen angegeben. <noindex><a rel=\"nofollow\" href=\"https:\/\/tc26.ru\/standarts\/rekomendatsii-po-standartizatsii\/r-1323565-1-004-2017-informatsionnaya-tekhnologiya-kriptograficheskaya-zashchita-informatsii-skhemy-vyrabotki-obshchego-klyucha-s-autentifikatsiey-na-osnove-otkrytogo-klyucha.html\">R 1323565.1.004-2017 \u201eInformationstechnologie. Kryptographischer Schutz von Informationen. Schemata zur Erzeugung eines gemeinsamen Schl\u00fcssels mit Authentifizierung auf Basis \u00f6ffentlicher Schl\u00fcssel\u201c<\/a><\/noindex>. F\u00fcr andere kryptographische Schemata besteht diese Bedrohung nicht, da die Verschl\u00fcsselung mit den \u00f6ffentlichen Schl\u00fcsseln des Empf\u00e4ngers erfolgt, die im Allgemeinen Angreifern bekannt sind.<\/p>\n<p><b>Dekomposition<\/b><br \/>\nU2.1. Die Kompromittierung des privaten Schl\u00fcssels des Absenders:<br \/>\nU2.1.1. Link: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIU1\">\u201eTypisches Bedrohungsmodell. System kryptographischer Informationsschutz. U1. Die Kompromittierung geschlossener kryptographischer Schl\u00fcssel\u201c<\/a><\/noindex>.<\/p>\n<p>U2.2. Die Manipulation von Eingangsdaten im Austauschkanal f\u00fcr \u00f6ffentliche Daten.<br \/>\n<i>Anmerkungen zu U2.2.<\/i><br \/>\nBeispiele f\u00fcr die Umsetzung dieser Bedrohung sind nachfolgend aufgef\u00fchrt. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIA1\">hier<\/a><\/noindex> und <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIA2\">hier<\/a><\/noindex>.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIU3\"><\/a><\/noindex><\/p>\n<h3>U3. Die Entschl\u00fcsselung verschl\u00fcsselter Daten durch nicht legitime Empf\u00e4nger der Daten (Angreifer).<\/h3>\n<p>\n<b>Dekomposition<\/b><br \/>\nU3.1. Die Kompromittierung von privaten Schl\u00fcsseln der Empf\u00e4nger von verschl\u00fcsselten Daten. <br \/>\nU3.1.1 Verweis: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIU1\">\u201eTypisches Bedrohungsmodell. System kryptographischer Informationsschutz. U1. Die Kompromittierung geschlossener kryptographischer Schl\u00fcssel\u201c<\/a><\/noindex>.<\/p>\n<p>U3.2. Die Manipulation von verschl\u00fcsselten Daten im Austauschkanal f\u00fcr gesch\u00fctzte Daten.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIU4\"><\/a><\/noindex><\/p>\n<h3>U4. Die Erstellung einer elektronischen Signatur eines legitimen Unterzeichners unter gef\u00e4lschten Daten.<br \/>\n<\/h3>\n<p>\n<b>Dekomposition<\/b><br \/>\nU4.1. Die Kompromittierung von privaten Schl\u00fcsseln der elektronischen Signatur eines legitimen Unterzeichners. <br \/>\nU4.1.1 Verweis: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIU1\">\u201eTypisches Bedrohungsmodell. System kryptographischer Informationsschutz. U1. Die Kompromittierung geschlossener kryptographischer Schl\u00fcssel\u201c<\/a><\/noindex>.<\/p>\n<p>U4.2. Die Manipulation der zu unterzeichnenden Daten im Austauschkanal f\u00fcr \u00f6ffentliche Daten.<br \/>\n<i>Anmerkung zu U4.2.<\/i><br \/>\nBeispiele f\u00fcr die Umsetzung dieser Bedrohung sind nachfolgend aufgef\u00fchrt. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIA1\">hier<\/a><\/noindex> und <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIA2\">hier<\/a><\/noindex>.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIU5\"><\/a><\/noindex><\/p>\n<h3>U5. Erhalt eines positiven Ergebnisses der \u00dcberpr\u00fcfung der elektronischen Signatur unter gef\u00e4lschten Daten.<\/h3>\n<p>\n<b>Dekomposition<\/b><br \/>\nU5.1. Angreifer fangen in der \u00dcbertragungsleitung der Ergebnis\u00fcbertragung eine Nachricht \u00fcber das negative Ergebnis der \u00dcberpr\u00fcfung der elektronischen Signatur ab und ersetzen sie durch eine Nachricht mit positivem Ergebnis.<\/p>\n<p>U5.2. Angreifer f\u00fchren einen Vertrauensangriff auf die Signaturzertifikate durch (<b>SZENARIO \u2014 alle Elemente sind obligatorisch<\/b>):<br \/>\nU5.2.1. Angreifer generieren ein \u00f6ffentliches und ein privates Schl\u00fcsselpaar f\u00fcr die elektronische Signatur. Falls im System Zertifikate f\u00fcr elektronische Signaturschl\u00fcssel verwendet werden, generieren sie ein elektronisches Signaturzertifikat, das dem Zertifikat des mutma\u00dflichen Absenders der Daten, dessen Nachricht sie f\u00e4lschen wollen, m\u00f6glichst \u00e4hnlich ist.<br \/>\nU5.2.2. Angreifer nehmen nicht autorisierte \u00c4nderungen im Repository der \u00f6ffentlichen Schl\u00fcssel vor, versehen den von ihnen generierten \u00f6ffentlichen Schl\u00fcssel mit dem erforderlichen Vertrauensniveau und den Befugnissen.<br \/>\nU5.2.3. Angreifer signieren gef\u00e4lschte Daten mit dem zuvor generierten elektronischen Signaturschl\u00fcssel und injizieren diese in den Kanal f\u00fcr den Austausch gesch\u00fctzter Daten.<\/p>\n<p>U5.3. Angreifer f\u00fchren einen Angriff mit abgelaufenen elektronischen Signaturschl\u00fcsseln eines legitimen Unterzeichners durch (<b>SZENARIO \u2014 alle Elemente sind obligatorisch<\/b>):<br \/>\nU5.3.1. Angreifer kompromittieren die abgelaufenen (nicht mehr g\u00fcltigen) privaten elektronischen Signaturschl\u00fcssel eines legitimen Absenders.<br \/>\nU5.3.2. Angreifer ersetzen die Zeit im \u00dcbertragungsprotokoll durch eine Zeit, zu der die kompromittierten Schl\u00fcssel noch g\u00fcltig waren.<br \/>\nU5.3.3. Angreifer signieren gef\u00e4lschte Daten mit dem zuvor kompromittierten elektronischen Signaturschl\u00fcssel und injizieren diese in den Kanal f\u00fcr den Austausch gesch\u00fctzter Daten.<\/p>\n<p>U5.4. Angreifer f\u00fchren einen Angriff mit kompromittierten elektronischen Signaturschl\u00fcsseln eines legitimen Unterzeichners durch (<b>SZENARIO \u2014 alle Elemente sind obligatorisch<\/b>):<br \/>\nU5.4.1. Angreifer erstellen eine Kopie des Repositories der \u00f6ffentlichen Schl\u00fcssel.<br \/>\nU5.4.2. Angreifer kompromittieren die privaten Schl\u00fcssel eines der legitimen Absender. Dieser entdeckt die Kompromittierung, zieht die Schl\u00fcssel zur\u00fcck, und die Informationen \u00fcber den Schl\u00fcsselr\u00fcckzug werden im Repository der \u00f6ffentlichen Schl\u00fcssel gespeichert.<br \/>\nU5.4.3. Angreifer ersetzen das Repository der \u00f6ffentlichen Schl\u00fcssel durch das zuvor kopierte.<br \/>\nU5.4.4. Angreifer signieren gef\u00e4lschte Daten mit dem zuvor kompromittierten elektronischen Signaturschl\u00fcssel und injizieren diese in den Kanal f\u00fcr den Austausch gesch\u00fctzter Daten.<\/p>\n<p>U5.5. &lt;&#8230;&gt; aufgrund von Fehlern bei der Umsetzung der 2. und 3. Stufe der Pr\u00fcfung der elektronischen Signatur:<br \/>\n<i>Erl\u00e4uterungen U5.5.<\/i><br \/>\nEin Beispiel f\u00fcr die Umsetzung dieser Bedrohung wird gegeben <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/422329\/#TMUSKZIA4\">unten<\/a><\/noindex>.<\/p>\n<p>U5.5.1. \u00dcberpr\u00fcfung des Vertrauens in das Zertifikat des elektronischen Signaturschl\u00fcssels nur aufgrund des Vorhandenseins des Vertrauens in das Zertifikat, mit dem es signiert wurde, ohne CRL- oder OCSP-\u00dcberpr\u00fcfungen.<br \/>\n<i>Erl\u00e4uterungen U5.5.1.<\/i><br \/>\nBeispielimplementation <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/332730\/\">Bedrohungen<\/a><\/noindex>. <\/p>\n<p>U5.5.2. Bei der Erstellung einer Vertrauenskette f\u00fcr das Zertifikat werden die Befugnisse der ausstellenden Zertifikate nicht analysiert<br \/>\n<i>Erl\u00e4uterungen U5.5.2.<\/i><br \/>\nBeispiel eines Angriffs auf SSL\/TLS-Zertifikate. <br \/>\nAngreifer haben ein legitimes Zertifikat f\u00fcr ihre E-Mail gekauft. Anschlie\u00dfend haben sie ein gef\u00e4lschtes Zertifikat f\u00fcr eine Website erstellt und dieses mit ihrem Zertifikat signiert. Wenn die Befugnis\u00fcberpr\u00fcfung nicht durchgef\u00fchrt wird, wird die \u00dcberpr\u00fcfung der Vertrauenskette korrekt sein, und demnach wird auch das gef\u00e4lschte Zertifikat als korrekt angesehen.<\/p>\n<p>U5.5.3. Bei der Erstellung einer Vertrauenskette f\u00fcr das Zertifikat werden die Zwischenzertifikate auf den Widerruf nicht \u00fcberpr\u00fcft.<\/p>\n<p>U5.5.4. Die Aktualisierung der CRL erfolgt seltener, als sie vom Zertifizierungsstelle ausgegeben werden.<\/p>\n<p>U5.5.5. Die Entscheidung \u00fcber das Vertrauen in die elektronische Signatur wird getroffen, bevor die OCSP-Antwort \u00fcber den Status des Zertifikats erhalten wird, die auf eine Anfrage gesendet wurde, die nach dem Zeitpunkt der Signaturerstellung gestellt wurde oder bevor die n\u00e4chste nach der Signaturerstellung CRL erhalten wird. <br \/>\n<i>Erl\u00e4uterungen U5.5.5.<\/i><br \/>\nIn den Vorschriften der meisten CA wird die Zeit des Widerrufs eines Zertifikats als die Zeit des Ausstellens der n\u00e4chstgelegenen CRL betrachtet, die Informationen \u00fcber den Widerruf des Zertifikats enth\u00e4lt.<\/p>\n<p>U5.5.6. Bei Erhalt signierter Daten wird die Zugeh\u00f6rigkeit des Zertifikats zum Absender nicht \u00fcberpr\u00fcft. <br \/>\n<i>Erl\u00e4uterungen U5.5.6.<\/i><br \/>\nBeispiel eines Angriffs. In Bezug auf SSL-Zertifikate: Die \u00dcbereinstimmung der aufgerufenen Serveradresse mit dem Wert des CN-Felds im Zertifikat wird m\u00f6glicherweise nicht \u00fcberpr\u00fcft.<br \/>\nBeispiel eines Angriffs. Angreifer haben die elektronischen Signaturschl\u00fcssel eines Teilnehmers an einem Zahlungssystem kompromittiert. Danach haben sie das Netzwerk eines anderen Teilnehmers gehackt und in dessen Namen Dokumente zur Zahlung an den Zahlungsserver gesendet, die mit den kompromittierten Schl\u00fcsseln signiert waren. Wenn der Server nur das Vertrauen analysiert und keine \u00dcbereinstimmung \u00fcberpr\u00fcft, werden die betr\u00fcgerischen Dokumente als legitim angesehen.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIU6\"><\/a><\/noindex><\/p>\n<h3>U6. Falsche Annahme von elektronischen Dokumenten aufgrund von Problemen in der Organisation des elektronischen Dokumentenverkehrs.<\/h3>\n<p>\n<b>Dekomposition<\/b><br \/>\nU6.1. Die empfangende Partei entdeckt keine Duplikate der erhaltenen Dokumente.<br \/>\n<i>Erl\u00e4uterungen U6.1.<\/i><br \/>\nBeispiel eines Angriffs. Angreifer k\u00f6nnen ein an den Empf\u00e4nger \u00fcbermitteltes Dokument, selbst wenn es kryptografisch gesichert ist, abfangen und dann mehrfach im Kanal der gesch\u00fctzten Daten\u00fcbertragung senden. Wenn der Empf\u00e4nger keine Duplikate erkennt, werden alle erhaltenen Dokumente als unterschiedliche Dokumente wahrgenommen und verarbeitet.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIU7\"><\/a><\/noindex><\/p>\n<h3>U7. Unbefugter Zugriff auf gesch\u00fctzte Daten w\u00e4hrend ihrer Verarbeitung durch SKZI. <\/h3>\n<p>\n<b>Dekomposition<\/b><\/p>\n<p>U7.1. &lt;&#8230;&gt; infolge einer Informationsleckage \u00fcber externe Kan\u00e4le (Side-Channel-Angriff).<br \/>\n<i>Erl\u00e4uterungen zu U7.1.<\/i><br \/>\nBeispiel <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cs.tau.ac.il\/~tromer\/synesthesia\/synesthesia.pdf\">Angriffe<\/a><\/noindex>. <\/p>\n<p>U7.2. &lt;&#8230;&gt; infolge der Neutralisierung des Schutzes vor unbefugtem Zugriff auf die Informationen, die auf dem SKZI verarbeitet werden:<br \/>\nU7.2.1. Betrieb von SKZI unter Missachtung der in der Dokumentation zu SKZI beschriebenen Anforderungen.<\/p>\n<p>U7.2.2. &lt;&#8230;&gt;, die aufgrund der Anf\u00e4lligkeiten in Folgendem durchgef\u00fchrt wurde:<br \/>\nU7.2.2.1. &lt;&#8230;&gt; Mitteln zum Schutz vor unbefugtem Zugriff.<br \/>\nU7.2.2.2. &lt;&#8230;&gt; dem SKZI selbst.<br \/>\nU7.2.2.3. &lt;&#8230;&gt; der Umgebung, in der das Kryptomittel arbeitet.<\/p>\n<h3>Beispiele f\u00fcr Angriffe<\/h3>\n<p>\nDie nachfolgend behandelten Szenarien enthalten absichtlich Fehler in der Organisation der Informationssicherheit und dienen nur zur Veranschaulichung m\u00f6glicher Angriffe.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIA1\"><\/a><\/noindex><\/p>\n<h4>Szenario 1. Beispiel zur Umsetzung der Bedrohungen U2.2 und U4.2.<\/h4>\n<p>\n<b>Beschreibung des Objekts<\/b><br \/>\n<img decoding=\"async\" alt=\"Informationssicherheit bei bankgest\u00fctzten bargeldlosen Zahlungen. Teil 8 \u2013 Typische Bedrohungsmodelle\" src=\"\/wp-content\/uploads\/2019\/04\/77d51167720552df4eb9c2bafbce6765.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSoftware A\u0420M KBR und SKZI SKAD sind auf einem physischen Computer installiert, der nicht mit dem Rechennetzwerk verbunden ist. Als Schl\u00fcsseltr\u00e4ger wird ein FKN vdToken im Modus mit nicht extrahierbarem Schl\u00fcssel verwendet.<\/p>\n<p>Die Vorschriften zur Durchf\u00fchrung von Berechnungen sehen vor, dass der Berechnungsprofi elektronische Nachrichten in offener Form (Schema des alten A\u0420M KBR) von einem speziellen gesch\u00fctzten Dateiserver auf seinem Arbeitscomputer herunterl\u00e4dt, diese dann auf ein tragbares USB-Laufwerk \u00fcbertr\u00e4gt und auf das A\u0420M KBR bringt, wo sie verschl\u00fcsselt und signiert werden. Danach \u00fcbertr\u00e4gt der Spezialist die gesch\u00fctzten elektronischen Nachrichten auf ein tragbares Medium und speichert sie anschlie\u00dfend \u00fcber seinen Arbeitscomputer auf dem Dateiserver, von wo sie auf das UTA und dann in das Zahlungssystem der Bank von Russland gelangen.<\/p>\n<p>In diesem Fall umfassen die Kan\u00e4le f\u00fcr den Austausch offener und gesch\u00fctzter Daten: den Dateiserver, den Arbeitscomputer des Spezialisten und das tragbare Medium.<\/p>\n<p><b>Der Angriff<\/b><br \/>\nAngreifer installieren unbefugt ein Fernwartungssystem auf dem Arbeitscomputer eines Spezialisten und ersetzen w\u00e4hrend der \u00dcbertragung von Zahlungsanweisungen (elektronischen Nachrichten) in offener Form den Inhalt einer von ihnen. Der Spezialist \u00fcbertr\u00e4gt die Zahlungsanweisungen auf den Arbeitsplatzrechner (ARM KBR), signiert sie und verschl\u00fcsselt sie, ohne die Manipulation zu bemerken (zum Beispiel aufgrund der gro\u00dfen Anzahl an Zahlungsanweisungen, Erm\u00fcdung usw.). Danach gelangt das gef\u00e4lschte Zahlungsauftrag durch die technologische Kette in das Zahlungssystem der Bank Russland.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIA2\"><\/a><\/noindex><\/p>\n<h4>Szenario 2. Beispiel f\u00fcr die Umsetzung der Bedrohungen U2.2 und U4.2.<\/h4>\n<p>\n<b>Beschreibung des Objekts<\/b><br \/>\n<img decoding=\"async\" alt=\"Informationssicherheit bei bankgest\u00fctzten bargeldlosen Zahlungen. Teil 8 \u2013 Typische Bedrohungsmodelle\" src=\"\/wp-content\/uploads\/2019\/04\/b4489290d665b359323ec6b58dde1139.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEin Computer mit installiertem ARM KBR, SKAD Signatur und angeschlossenem Schl\u00fcsseltr\u00e4ger FKN vdToken arbeitet in einem abgeschotteten Raum ohne Zugriff des Personals.<br \/>\nDer Abrechnungs-Spezialist verbindet sich im Remote-Zugriffsmodus \u00fcber das RDP-Protokoll mit ARM KBR.<\/p>\n<p><b>Der Angriff<\/b><br \/>\nAngreifer fangen die Zugangsdaten ab, mit denen der Abrechnungs-Spezialist eine Verbindung zu ARM KBR herstellt und damit arbeitet (zum Beispiel durch b\u00f6sartigen Code auf seinem Computer). Dann stellen sie eine Verbindung in seinem Namen her und schicken ein gef\u00e4lschtes Zahlungsauftrag in das Zahlungssystem der Bank Russland.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIA3\"><\/a><\/noindex><\/p>\n<h4>Szenario 3. Beispiel f\u00fcr die Umsetzung der Bedrohung U1.3. <\/h4>\n<p>\n<b>Beschreibung des Objekts<\/b><br \/>\n<img decoding=\"async\" alt=\"Informationssicherheit bei bankgest\u00fctzten bargeldlosen Zahlungen. Teil 8 \u2013 Typische Bedrohungsmodelle\" src=\"\/wp-content\/uploads\/2019\/04\/988a97dd75247780556d388566d771f0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBetrachten wir eine der hypothetischen Varianten der Umsetzung der Integrationsmodule \u201eABS-KBR\u201c f\u00fcr das neue Schema (ARM KBR-N), bei dem die elektronische Unterschrift der ausgehenden Dokumente auf der Seite der ABS erfolgt. Dabei gehen wir davon aus, dass die ABS auf einem Betriebssystem l\u00e4uft, das von der SKZI SKAD Signatur nicht unterst\u00fctzt wird, und entsprechend die kryptografischen Funktionen auf eine separate virtuelle Maschine - das Integrationsmodul \u201eABS-KBR\u201c - ausgelagert sind.<br \/>\nAls Schl\u00fcsseltr\u00e4ger wird ein gew\u00f6hnlicher USB-Token verwendet, der im Modus eines entnehmbaren Schl\u00fcssels arbeitet. Bei der Verbindung des Schl\u00fcsseltr\u00e4gers mit dem Hypervisor stellte sich heraus, dass im System keine freien USB-Ports vorhanden sind, daher wurde beschlossen, den USB-Token \u00fcber einen Netzwerk-USB-Hub anzuschlie\u00dfen, und auf der virtuellen Maschine einen USB-over-IP-Client zu installieren, der die Verbindung zum Hub herstellt.<\/p>\n<p><b>Der Angriff<\/b><br \/>\nAngreifer haben den privaten Schl\u00fcssel der elektronischen Signatur aus dem Kommunikationskanal zwischen dem USB-Hub und dem Hypervisor abgefangen (die Daten wurden im Klartext \u00fcbertragen). Mit dem privaten Schl\u00fcssel erstellten die Angreifer einen gef\u00e4lschten Zahlungsauftrag, unterzeichneten ihn mit der elektronischen Signatur und sendeten ihn zur Ausf\u00fchrung an AR\u041c K\u0411\u0420-\u041d.<br \/>\n<noindex><a rel=\"nofollow\" name=\"TMUSKZIA4\"><\/a><\/noindex><\/p>\n<h4>Szenario 4. Beispiel zur Umsetzung der Bedrohungen U5.5.<\/h4>\n<p>\n<b>Beschreibung des Objekts<\/b><br \/>\nBetrachten wir dasselbe Schema wie im vorherigen Szenario. Nehmen wir an, dass die elektronischen Nachrichten, die aus dem AR\u041c K\u0411\u0420-N kommen, in den Ordner &#8230;SHAREIn gelangen, und die, die an das AR\u041c K\u0411\u0420-N gesendet werden und weiter an das Zahlungssystem der Bank von Russland, - in &#8230;SHAREout.<br \/>\nWir nehmen auch an, dass bei der Implementierung des Integrationsmoduls die Listen der widerrufenen Zertifikate nur bei der Neuausstellung von kryptographischen Schl\u00fcsseln aktualisiert werden und dass elektronische Nachrichten, die in den Ordner &#8230;SHAREIn eintreffen, nur auf Integrit\u00e4ts- und Vertrauenspr\u00fcfungen des \u00f6ffentlichen Schl\u00fcssels der elektronischen Signatur \u00fcberpr\u00fcft werden.<\/p>\n<p><b>Der Angriff<\/b><\/p>\n<p>Die Angreifer, die die in dem vorherigen Szenario gestohlenen Schl\u00fcssel ausnutzten, unterzeichneten einen gef\u00e4lschten Zahlungsauftrag, der Informationen \u00fcber den Geldeingang auf das Konto eines betr\u00fcgerischen Kunden enthielt, und schickten ihn in den Kanal f\u00fcr den Austausch gesch\u00fctzter Daten. Da keine \u00dcberpr\u00fcfung stattfindet, ob der Zahlungsauftrag tats\u00e4chlich von der Bank von Russland unterzeichnet wurde, wird er zur Ausf\u00fchrung angenommen.<br \/>\n<br \/>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/422329\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041e \u0447\u0435\u043c \u0438\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u0435 \u0421\u0441\u044b\u043b\u043a\u0438 \u043d\u0430 \u0434\u0440\u0443\u0433\u0438\u0435 \u0447\u0430\u0441\u0442\u0438 \u0438\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u044f \u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c \u0431\u0430\u043d\u043a\u043e\u0432\u0441\u043a\u0438\u0445 \u0431\u0435\u0437\u043d\u0430\u043b\u0438\u0447\u043d\u044b\u0445 \u043f\u043b\u0430\u0442\u0435\u0436\u0435\u0439. \u0427\u0430\u0441\u0442\u044c 1 \u2014 \u042d\u043a\u043e\u043d\u043e\u043c\u0438\u0447\u0435\u0441\u043a\u0438\u0435 \u043e\u0441\u043d\u043e\u0432\u044b. \u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c \u0431\u0430\u043d\u043a\u043e\u0432\u0441\u043a\u0438\u0445 \u0431\u0435\u0437\u043d\u0430\u043b\u0438\u0447\u043d\u044b\u0445 \u043f\u043b\u0430\u0442\u0435\u0436\u0435\u0439. \u0427\u0430\u0441\u0442\u044c 2 \u2014 \u0422\u0438\u043f\u043e\u0432\u0430\u044f IT-\u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0430 \u0431\u0430\u043d\u043a\u0430. \u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c \u0431\u0430\u043d\u043a\u043e\u0432\u0441\u043a\u0438\u0445 \u0431\u0435\u0437\u043d\u0430\u043b\u0438\u0447\u043d\u044b\u0445 \u043f\u043b\u0430\u0442\u0435\u0436\u0435\u0439. \u0427\u0430\u0441\u0442\u044c 3 \u2014 \u0424\u043e\u0440\u043c\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u0439 \u043a \u0441\u0438\u0441\u0442\u0435\u043c\u0435 \u0437\u0430\u0449\u0438\u0442\u044b. \u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c \u0431\u0430\u043d\u043a\u043e\u0432\u0441\u043a\u0438\u0445 \u0431\u0435\u0437\u043d\u0430\u043b\u0438\u0447\u043d\u044b\u0445 \u043f\u043b\u0430\u0442\u0435\u0436\u0435\u0439. \u0427\u0430\u0441\u0442\u044c 4 \u2014 \u041e\u0431\u0437\u043e\u0440 \u0441\u0442\u0430\u043d\u0434\u0430\u0440\u0442\u043e\u0432 \u043c\u043e\u0434\u0435\u043b\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0443\u0433\u0440\u043e\u0437. \u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":23545,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-31627","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/informatsionnaya-bezopasnost-bankovskih-beznalichnyh-platezhej-chast-8-tipovye-modeli-ugroz\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c \u0431\u0430\u043d\u043a\u043e\u0432\u0441\u043a\u0438\u0445 \u0431\u0435\u0437\u043d\u0430\u043b\u0438\u0447\u043d\u044b\u0445 \u043f\u043b\u0430\u0442\u0435\u0436\u0435\u0439. \u0427\u0430\u0441\u0442\u044c 8 \u2014 \u0422\u0438\u043f\u043e\u0432\u044b\u0435 \u043c\u043e\u0434\u0435\u043b\u0438 \u0443\u0433\u0440\u043e\u0437 | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/informatsionnaya-bezopasnost-bankovskih-beznalichnyh-platezhej-chast-8-tipovye-modeli-ugroz\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:42:14+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:42:14+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Informationssicherheit bei bargeldlosen Zahlungen im Bankwesen. Teil 8 \u2014 Typische Bedrohungsmodelle | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/informatsionnaya-bezopasnost-bankovskih-beznalichnyh-platezhej-chast-8-tipovye-modeli-ugroz","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0418\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c \u0431\u0430\u043d\u043a\u043e\u0432\u0441\u043a\u0438\u0445 \u0431\u0435\u0437\u043d\u0430\u043b\u0438\u0447\u043d\u044b\u0445 \u043f\u043b\u0430\u0442\u0435\u0436\u0435\u0439. \u0427\u0430\u0441\u0442\u044c 8 \u2014 \u0422\u0438\u043f\u043e\u0432\u044b\u0435 \u043c\u043e\u0434\u0435\u043b\u0438 \u0443\u0433\u0440\u043e\u0437 | ProHoster","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/informatsionnaya-bezopasnost-bankovskih-beznalichnyh-platezhej-chast-8-tipovye-modeli-ugroz","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:42:14+00:00","article:modified_time":"2019-10-31T18:42:14+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"31627","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 07:04:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:13:29","updated":"2026-01-21 07:04:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/31627","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=31627"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/31627\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/23545"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=31627"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=31627"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=31627"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}