Informationssäkerhet för elektroniska bankbetalningar. Del 8 — Typiska hotmodeller

Vad handlar studien om

Länkar till andra delar av undersökningen

• Informationssäkerhet för bankernas kontantlösa betalningar. Del 1 — Ekonomiska grunder.
• Informationssäkerhet för bankernas kontantlösa betalningar. Del 2 — Typisk IT-infrastruktur för en bank.
• Informationssäkerhet för bankernas kontantlösa betalningar. Del 3 — Utformning av krav på skyddssystemet.
• Informationssäkerhet för bankernas kontantlösa betalningar. Del 4 — Översikt av standarder för hotmodellering.
• Informationssäkerhet för bankernas kontantlösa betalningar. Del 5 — 100+ tematiska länkar om bankbrott.
• Informationssäkerhet för bankernas kontantlösa betalningar. Del 6 — Analys av bankbrott.
• Informationssäkerhet för bankernas kontantlösa betalningar. Del 7 — Grundläggande hotmodell.
• Informationssäkerhet för elektroniska bankbetalningar. Del 8 — Typiska hotmodeller (Du är här)

Denna artikel avslutar en serie publikationer om att säkerställa informationssäkerheten för bankernas kontantlösa betalningar. Här kommer vi att titta på typiska hotmodeller som nämndes i den grundläggande modellen:

• Typisk hotmodell. Nätverksanslutning.
• Typisk hotmodell. Informationssystem baserat på klient-server-arkitektur.
• Typisk hotmodell. Åtkomstkontrollsystem.
• Typisk hotmodell. Integrationsmodul.
• Typisk hotmodell. System för kryptografiskt skydd av information.

HABRO-WARNING !!! Kära habrovchane, detta är inte ett underhållande inlägg.
Döljda under kat ger 40+ sidor material som syftar till att hjälpa i arbete eller studier för personer som specialiserar sig inom bankverksamhet eller informationssäkerhet. Dessa material är slutprodukten av studien och skrivs i en torr officiell ton. I grunden är de skisser för interna dokument om IS.

Och det traditionella — «användning av uppgifter från artikeln i kriminella syften bestraffas enligt lag». Trevlig läsning!

Information till läsare som bekantar sig med studien, börja med denna publikation.

Vad handlar studien om

Du läser en guide för specialisten ansvarig för att säkerställa informationssäkerheten för betalningar i banken.

Logik för framställningen

I början i del 1 och del 2 ges en beskrivning av skyddsobjektet. Sedan i del 3 Det berättas hur man bygger ett skyddssystem och vikten av att skapa en hotmodell. I del 4 Det berättas om vilka typer av hot som finns och hur de formas. I del 5 och del 6 en analys av verkliga attacker presenteras. Del 7 och del 8 innehåller beskrivning av en hotmodell byggd med hänsyn till uppgifter från alla tidigare delar.

TYPISK HOTMODELL. NÄTVERKSANSLOPP

Skyddsobjektet för vilket hotmodellen tillämpas (scope)

Skyddsobjektet är de uppgifter som överförs via en nätverksanslutning som fungerar i datanät baserade på TCP/IP-protokollet.

Arkitektur

Beskrivning av arkitekturens element:

• «Slutpunkter» — enheter som utbyter skyddad information.
• «Mellanliggande noder» — element i datanätverket: routrar, switchar, åtkomstservrar, proxy-servrar och annan utrustning genom vilken trafiken för nätverksanslutningen passerar. Generellt kan nätverksanslutningen fungera utan mellanliggande noder (direkt mellan slutpunkterna).

Överordnade säkerhetshot

Dekomposition

H1. Obehörig åtkomst till överförda uppgifter.
H2. Obehörig modifiering av överförda uppgifter.
H3. Kränkning av upphovsrätten till överförda uppgifter.

H1. Obehörig åtkomst till överförda uppgifter

Dekomposition
H1.1. , utförd på slutliga eller mellanliggande noder:
H1.1.1. genom att läsa data när de finns i lagringsenheter på noden:
H1.1.1.1. i RAM.
Förklaringar till H1.1.1.1.
Till exempel under bearbetningen av data av nodens nätverksstack.

H1.1.1.2. i icke-flyktigt minne.
Förklaringar till H1.1.1.2.
Till exempel när överförda uppgifter lagras i cache, temporära filer eller växlingsfiler.

H1.2. , utförd på externa noder i datanätverket:
H1.2.1. genom att fånga alla paket som kommer till nodens nätverksinterface:
Förklaringar till H1.2.1.
Fångsten av alla paket sker genom att sätta nätverkskortet i promiscuous läge (promiscuous mode för trådade adaptrar eller monitorläge för wi-fi adaptrar).

H1.2.2. genom att utföra attacker av typen "man-in-the-middle (MiTM)", utan att modifiera de överförda uppgifterna (förutom protokollets kontrolldata).
H1.2.2.1. Länk: «Typmodell av hot. Nätverksanslutning. U2. Obefogad modifiering av överförda data».

U1.3. , genom att information läcker via tekniska kanaler (TKUI) från fysiska noder eller kommunikationslinjer.

U1.4. , genom att installera speciella tekniska medel (STS) på slut- eller mellanliggande noder, avsedda för tyst insamling av information.

U2. Obefogad modifiering av överförda data

Dekomposition
U2.1. , genomförd på slut- eller mellanliggande noder:
U2.1.1. genom att läsa och ändra data medan de befinner sig i nodernas minnesenheter:
U2.1.1.1. i RAM-minnet:
U2.1.1.2. i icke-flyktigt minne:

U2.2. , genomförd på externa noder i datanätverket:
U2.2.1. genom att utföra man-in-the-middle (MiTM) attacker och omdirigera trafik till angriparens nod:
U2.2.1.1. Fysisk anslutning av angriparens utrustning i brist på nätverksanslutning.
U2.2.1.2. Genomförande av attacker på nätverksprotokoll:
U2.2.1.2.1. styrning av virtuella lokala nätverk (VLAN):
U2.2.1.2.1.1. VLAN hopping.
U2.2.1.2.1.2. Obefogad modifiering av VLAN-inställningar på switchar eller routrar.
U2.2.1.2.2. routning av trafik:
U2.2.1.2.2.1. Obefogad modifiering av routernas statiska routningstabeller.
U2.2.1.2.2.2. Angripare annonserar falska rutter via protokoll för dynamisk routning.
U2.2.1.2.3. automatisk konfiguration:
U2.2.1.2.3.1. Rogue DHCP.
U2.2.1.2.3.2. Rogue WPAD.
U2.2.1.2.4. adressering och namnupplösning:
U2.2.1.2.4.1. ARP spoofing.
U2.2.1.2.4.2. DNS spoofing.
U2.2.1.2.4.3. Införande av obefogade ändringar i lokala namnfilen (hosts, lmhosts m.fl.)

U3. Överträdelse av upphovsrätt på överförda data

Dekomposition
U3.1. Neutralisering av mekanismer för att fastställa upphov till information genom att ange falska uppgifter om författaren eller källan till data:
U3.1.1. Ändring av uppgifter om författaren som ingår i den överförda informationen.
U3.1.1.1. Neutralisering av kryptografisk skydd av integritet och upphov till överförda data:
U3.1.1.1.1. Länk: «Typmodell av hot. System för kryptografiskt skydd av information.
U4. Skapande av en elektronisk signatur av en legitimerad signatär för falska data».
U3.1.1.2. Neutralisering av upphovsrättsskydd för överförda data, implementerat med hjälp av engångskoder:
U3.1.1.2.1. SIM-bytte.

U3.1.2. Ändring av källinformation för överförda uppgifter:
U3.1.2.1. IP-spoofing.
U3.1.2.2. MAC-spoofing.

TYPISK HOTMODELL. INFORMATIONSSYSTEM BYGGD PÅ KLIENT-SERVER ARCHITEKTUR

Skyddsobjektet för vilket hotmodellen tillämpas (scope)

Objektet för skydd är ett informationssystem byggt på klient-serverarkitektur.

Arkitektur


Beskrivning av arkitekturens element:

• «Klient» – en enhet på vilken klientdelen av informationssystemet fungerar.
• «Server» – en enhet på vilken serverdelen av informationssystemet fungerar.
• «Databas» — en del av serverinfrastrukturen för informationssystemet avsedd för lagring av data som behandlas av informationssystemet.
• «Nätverksanslutning» — en kanal för informationsutbyte mellan Klienten och Servern, som passerar genom datanätverket. En mer detaljerad beskrivning av elementmodellen ges i «Typisk hotmodell. Nätverksanslutning».

Begränsningar
Vid modellering av objektet har följande begränsningar fastställts:

1. Användaren interagerar med informationssystemet inom ramarna för tidsintervall som kallas arbetssessioner.
2. I början av varje arbetssession genomförs identifiering, autentisering och auktorisation av användaren.
3. All skyddad information lagras i serverdelen av informationssystemet.

Överordnade säkerhetshot

Dekomposition
U1. Utnyttjande av obehöriga åtgärder av angripare i namnet av en legitim användare.
U2. Obefogad modifiering av skyddad information under bearbetning av serverdelen av informationssystemet.

U1. Utnyttjande av obehöriga åtgärder av angripare i namnet av en legitim användare

Förklaringar
I informationssystem används vanligtvis följande metoder för att koppla åtgärder till den användare som utfört dem:

1. systemloggar (logs).
2. specifika attribut för dataobjekt som innehåller information om den som skapade eller ändrade dem.

I förhållande till arbetssessionen kan detta hot brytas ner i:

1. utförda inom ramen för användarens arbetssession.
2. utförda utanför användarens arbetssession.

En användarsession kan initieras av:

1. Själva användaren.
2. Angripare.

I detta skede kommer den mellanliggande nedbrytningen av denna hot att se ut på följande sätt:
U1.1. Obefogade åtgärder utförs inom användarsessionen:
U1.1.1. <…>, installerad av den attackerade användaren.
U1.1.2. <…>, installerad av angriparna.
U1.2. Obefogade åtgärder utförs utanför användarsessionen.

Utifrån de objekt inom informationsinfrastrukturen som angripare kan påverka, kommer den mellanliggande nedbrytningen av hot att se ut så här:

Element
Nedbrytning av hot

U1.1.1.
U1.1.2.
U1.2.

Klient
U1.1.1.1.
U1.1.2.1.

Nätverksanslutning
U1.1.1.2.

Servern

U1.2.1.

Dekomposition
U1.1. Obefogade åtgärder utförs inom användarsessionen:
U1.1.1. <…>, installerad av den attackerade användaren:
U1.1.1.1. Angriparna agerade självständigt från Klienten:
U1.1.1.1.1 Angriparna använde standardverktyg för att få tillgång till informationssystemet:
U1.1.1.1.1.1. Angriparna använde Klientens fysiska in- och utmatningsmedel (tangentbord, mus, skärm eller pekskärm på en mobil enhet):
U1.1.1.1.1.1.1. Angriparna agerade under perioder när sessionen är aktiv, in- och utmatningsmedel är tillgängliga och användaren inte är på plats.
U1.1.1.1.1.2. Angriparna använde fjärradministrationsverktyg (standard eller tillhandahållna av skadlig kod) för att kontrollera Klienten:
U1.1.1.1.1.2.1. Angriparna agerade under perioder när sessionen är aktiv, in- och utmatningsmedel är tillgängliga och användaren inte är på plats.
U1.1.1.1.1.2.2. Angriparna använde fjärradministrationsverktyg vars funktioner är osynliga för den attackerade användaren.
U1.1.1.2. Angriparna modifierade data i nätverksanslutningen mellan Klienten och Servern, så att de tolkades som handlingar av en legitim användare:
U1.1.1.2.1. Länk: «Typmodell av hot. Nätverksanslutning. U2. Obefogad modifiering av överförda data».
U1.1.1.3. Angriparna tvingade användaren att utföra de åtgärder som de angav, med hjälp av social ingenjörskonst.

U1.1.2 <…> installerad av angriparna:
U1.1.2.1. Angriparna agerade från Klienten (Och):
U1.1.2.1.1. Angriparna neutraliserade systemet för åtkomstkontroll av informationssystemet:
U1.1.2.1.1.1. Länk: Typmodell för hot. Åtkomstkontrollsystem. U1. Obehörig etablering av en arbetssession i namn av en legitim användare.
U1.1.2.1.2. Angripare använde systemets standardåtkomstmedel
U1.1.2.2. Angripare agerade från andra noder i datanätverket som kan upprätta en nätverksanslutning till servern (Och):
U1.1.2.2.1. Angripare neutraliserade åtkomstkontrollsystemet för informationssystemet:
U1.1.2.2.1.1. Länk: Typmodell för hot. Åtkomstkontrollsystem. U1. Obehörig etablering av en arbetssession i namn av en legitim användare.
U1.1.2.2.2. Angripare använde icke-standard åtkomstmedel för informationssystemet.
Förklaring U1.1.2.2.2.
Angripare kunde installera standardklienten för informationssystemet på en extern nod eller använda oauktoriserad programvara som implementerar standardprotokoll för utbyte mellan klienten och servern.

U1.2 Obehöriga åtgärder utfördes utanför användarsessionen.
U1.2.1 Angripare utförde obehöriga åtgärder och gjorde sedan obehöriga ändringar i loggarna för informationssystemets arbete eller speciella attribut för dataobjekt och angav att deras åtgärder utfördes av en legitim användare.

U2. Obehörig modifiering av skyddad information under dess behandling av serverdelen av informationssystemet

Dekomposition
U2.1. Angripare modifierar skyddad information med hjälp av systemets standardmedel och gör detta i namn av en legitim användare.
U2.1.1. Länk: Typmodell för hot. Informationssystem baserat på klient-server arkitektur. U1. Angripare utför obehöriga åtgärder i namn av en legitim användare.

U2.2. Angripare modifierar skyddad information genom att använda mekanismer för åtkomst till data som inte tillhandahålls av systemets standarddrift.
U2.2.1. Angripare modifierar filer som innehåller skyddad information:
U2.2.1.1. , med hjälp av filer som hanteras av operativsystemet.
U2.2.1.2. genom att provocera fram återställning av filer från en obehörigt modifierad backup.

U2.2.2. Angripare modifierar skyddad information som lagras i databasen (Och):
U2.2.2.1. Angripare neutraliserar åtkomstkontrollsystemet för databashanteraren:
U2.2.2.1.1. Länk: Typmodell för hot. Åtkomstkontrollsystem. U1. Obehörig etablering av en arbetssession i namn av en legitim användare.
U2.2.2.2. Angripare modifierar informationen genom att använda standardgränssnitt för databashanteraren för att få åtkomst till data.

U2.3. Angripare modifierar skyddad information genom obehörig ändring av algoritmerna för den bearbetande programvaran.
U2.3.1. Programvarans källkod modifieras.
U2.3.1. Maskinkoden för programvaran modifieras.

U2.4. Angripare modifierar skyddad information genom att utnyttja sårbarheter i programvaran i informationssystemet.

U2.5. Angripare modifierar skyddad information under överföringen mellan komponenterna i serverdelen av informationssystemet (till exempel mellan databasservrar och applikationsservrar):
U2.5.1. Länk: «Typmodell av hot. Nätverksanslutning. U2. Obefogad modifiering av överförda data».

TYPISK HOTMODELL. ÅTKOMSTKONTROLLSYSTEM

Skyddsobjektet för vilket hotmodellen tillämpas (scope)

Skyddsobjektet för vilket denna hotmodell tillämpas överensstämmer med skyddsobjektet i hotmodellen: "Typisk hotmodell. Informationssystem som bygger på klient-server-arkitektur."

Med användarbehörighetssystemet i denna hotmodell avses en komponent i informationssystemet som utför funktioner:

1. Identifiering av användare.
2. Autentisering av användare.
3. Auktorisering av användare.
4. Protokollföring av användaråtgärder.

Överordnade säkerhetshot

Dekomposition
U1. Obefogad upprättande av arbetsSESSION under namnet för en legitim användare.
U2. Obefogad höjning av användarens behörigheter i informationssystemet.

U1. Obefogad upprättande av arbetsSESSION under namnet för en legitim användare

Förklaringar
Nedbrytningen av denna hotmodell kommer generellt att bero på vilken typ av identifierings- och autentiseringssystem för användare som tillämpas.

I denna modell kommer vi att fokusera på ett identifierings- och autentiseringssystem för användare som använder textbaserade inloggningar och lösenord. Vi kommer att anta att användarnamnet är offentlig information som är känd för angriparna.

Dekomposition
U1.1. genom kompromettering av autentiseringsuppgifter:
U1.1.1. Angripare har komprometterat användarens autentiseringsuppgifter under deras lagring.
Förklaringar till U1.1.1.
Till exempel kan autentiseringsuppgifterna ha skrivits på en lapp som klistrades på monitorn.

U1.1.2. Användaren överförde av misstag eller med avsikt sina inloggningsuppgifter till illvilliga aktörer.
U1.1.2.1. Användaren uttalade sina inloggningsuppgifter högt medan de angav dem.
U1.1.2.2. Användaren avsiktligt delade sina inloggningsuppgifter:
U1.1.2.2.1. med kollegor på arbetet.
Förklaringar U1.1.2.2.1.
Till exempel så att de kan ersätta dem vid sjukdom.

U1.1.2.2.2. med kontraktsinnehavare till arbetsgivaren som arbetar med objekt inom informationsinfrastruktur.
U1.1.2.2.3. med tredje part.
Förklaringar U1.1.2.2.3.
Ett av, men inte det enda, sätten som denna hotbild kan realiseras är genom att illvilliga aktörer använder social ingenjörskonst.

U1.1.3. Illvilliga aktörer gissade inloggningsuppgifterna genom brute force-metoder:
U1.1.3.1. med hjälp av standardåtkomstmekanismer.
U1.1.3.2. genom tidigare avlyssnade koder (till exempel hash av lösenord) för lagring av inloggningsuppgifter.

U1.1.4. Illvilliga aktörer använde skadlig kod för att fånga inloggningsuppgifterna från användaren.

U1.1.5. Illvilliga aktörer extraherade inloggningsuppgifterna från nätverkskopplingen mellan klienten och servern:
U1.1.5.1. Länk: «Typmodell av hot. Nätverkskoppling. U1. Obemyndigad åtkomst till överförda data».

U1.1.6. Illvilliga aktörer extraherade inloggningsuppgifterna från övervakningssystem:
U1.1.6.1. övervakningssystem (om tangenttryckningar registrerades under arbetets gång).
U1.1.6.2. system som övervakar anställda vid datorn.
Förklaringar U1.1.6.2.
Ett exempel på ett sådant system är — StuffCop.

U1.1.7. Illvilliga aktörer komprometterade användarens inloggningsuppgifter på grund av brister i överföringsprocessen.
Förklaringar U1.1.7.
Till exempel, överföring av lösenord i klartext via e-post.

U1.1.8. Illvilliga aktörer fick veta inloggningsuppgifterna genom att övervaka användarens arbetssession med hjälp av fjärradministrationssystem.

U1.1.9. Illvilliga aktörer extraherade inloggningsuppgifterna som följd av läckor genom tekniska kanaler (tkui):
U1.1.9.1. Illvilliga aktörer såg hur användaren angav inloggningsuppgifterna med tangentbordet:
U1.1.9.1.1. Illvilliga aktörer befann sig i omedelbar närhet av användaren och såg inmatningen av inloggningsuppgifterna med sina egna ögon.
Förklaringar U1.1.9.1.1
Sådana fall kan inkludera kollegors handlingar eller situationer där användarens tangentbord är synligt för besökare i organisationen.

U1.1.9.1.2 Intrångsförövare använde ytterligare tekniska medel, såsom kikare eller obemannade flygfarkoster, och såg inmatning av autentiseringsuppgifter genom ett fönster.
U1.1.9.2. Intrångsförövare extraherade autentiseringsuppgifter från radiocommunikationsregister mellan tangentbordet och datorns systemenhet vid en anslutning via radiogränssnitt (till exempel Bluetooth).
U1.1.9.3. Intrångsförövare genomförde avlyssning av autentiseringsuppgifter på grund av läckage genom kanalen för sidopåverkande elektromagnetiska strålning och induktion (PEEM).
Förklaringar U1.1.9.3.
Exempel på attacker ). Ett typiskt exempel på användning: och ). Ett typiskt exempel på användning:.

U1.1.9.4. Intrångsförövaren genomförde avlyssning av inmatning av autentiseringsuppgifter från tangentbordet genom användning av specialtekniska medel (STM) avsedda för hemlig informationstjuv.
Förklaringar U1.1.9.4.
Exempel enheter.

U1.1.9.5. Intrångsförövare genomförde avlyssning av inmatning av autentiseringsuppgifter från tangentbordet genom
analys av Wi-Fi-signalen, som modulerades av användarens tangenttryckningar.
Förklaringar U1.1.9.5.
Exempel attacker.

U1.1.9.6. Intrångsförövare genomförde avlyssning av inmatning av autentiseringsuppgifter från tangentbordet genom att analysera ljudet av tangenttryckningar.
Förklaringar U1.1.9.6.
Exempel attacker.

U1.1.9.7. Intrångsförövare genomförde avlyssning av inmatning av autentiseringsuppgifter från en mobil enhet genom att analysera accelerometerdata.
Förklaringar U1.1.9.7.
Exempel attacker.

U1.1.10. , som tidigare sparats på Klienten.
Förklaringar U1.1.10.
Till exempel kunde användaren ha sparat inloggning och lösenord i webbläsaren för att få tillgång till en viss webbplats.

U1.1.11. Intrångsförövare kom över autentiseringsuppgifter på grund av brister i processen att återkalla användartillgångar.
Förklaringar U1.1.11.
Till exempel, efter att en användare sagts upp, förblev deras konton olåsta.

U1.2. genom att utnyttja sårbarheter i åtkomstkontrollsystemet.

U2. Obetald befordran av användarprivilegier i informationssystemet.

Dekomposition
U2.1 genom att göra obehöriga ändringar i data som innehåller uppgifter om användarprivilegier.

U2.2 genom att utnyttja sårbarheter i åtkomstkontrollsystemet.

U2.3. på grund av brister i processen för användartillgångshantering.
Förklaringar U2.3.
Exempel 1. En användare tilldelades mer åtkomst än vad som var nödvändigt för tjänsten.
Exempel 2. Efter att användaren flyttades till en annan position drogs inte tidigare tilldelade åtkomsträttigheter tillbaka.

TYPISK MODELL FÖR HOT. INTEGRATIONSMODUL

Skyddsobjektet för vilket hotmodellen tillämpas (scope)

Integrationsmodul – en uppsättning objekt i informationsinfrastrukturen som syftar till att organisera informationsutbyte mellan informationssystem.

Med tanke på att det i företagsnätverk inte alltid är möjligt att entydigt separera ett informationssystem från ett annat, kan integrationsmodulen även ses som en länk mellan komponenter inom ett enda informationssystem.

Arkitektur
Den generaliserade schemat för integrationsmodulen ser ut som följer:

Beskrivning av arkitekturens element:

• «Utbytesserver (US)» – nod / tjänst / komponent av informationssystemet som utför funktionen att utbyta data med ett annat informationssystem.
• «Mäklare» – nod / tjänst som syftar till att organisera interaktion mellan informationssystemen men inte är en del av dem.
  Exempel på «Mäklare» kan vara e-posttjänster, företagsservicebussar (enterprise service bus / SoA-arkitektur), tredjeparts filservrar, osv. Generellt kan integrationsmodulen också sakna «Mäklare».
• «Databehandlingsprogram» – en uppsättning program som implementerar protokoll för datautbyte och formatkonvertering.
  Till exempel, konvertera data från formatet UFEBS till formatet ABS, ändra statusar för meddelanden under överföringen, osv.
• «Nätverksanslutning» översätts till objektet som beskrivs i den typiska hotmodellen «Nätverksanslutning». Vissa nätverksanslutningar av de som presenteras i schemat ovan kan saknas.

Exempel på integrationsmoduler

Schema 1. Integration av ABS och ARM KBR via en tredjeparts filserver

För att utföra betalningar laddar en behörig bankanställd ner elektroniska betalningsdokument från ABS och sparar dem i en fil (i ett eget format, exempelvis SQL-dump) på den nätverksmapp (…SHARE) filservern. Sedan konverteras denna fil med hjälp av ett konverteringsskript till en uppsättning filer i UFEBS-format som sedan läses av ARM KBR.
Efter detta krypterar och signerar den auktoriserade medarbetaren — användaren av ARM KBR — den mottagna filen och skickar den till betalningssystemet för Rysslands centralbank.

Vid mottagande av betalningar från Rysslands centralbank dekrypterar ARM KBR dem och kontrollerar den elektroniska signaturen, varefter de sparas som en uppsättning filer i UFEBS-format på filservern. Innan betalningsdokument importeras till ABS konverteras de med hjälp av ett konverteringsskript från UFEBS-format till ABS-format.

Låt oss anta att ABS i detta schema fungerar på en fysisk server, ARM KBR fungerar på en dedikerad dator, och konverteringsskriptet körs på filservern.

Överensstämmelse mellan objekten i det presenterade schemat och elementen i integrationsmodellen:
»Utbytesservrar från ABS-sidan« – servern för ABS.
»Utbytesservrar från ARM KBR-sidan« – datorn för ARM KBR.
«Mäklare» – extern filserver.
«Databehandlingsprogram» – konverteringsskriptet.

Schema 2. Integration mellan ABS och ARM KBR när en gemensam nätverksmapp med betalningar placeras på ARM KBR

Allt likadant som i Schema 1, men en separat filserver används inte, istället placeras en nätverksmapp (…SHARE) med elektroniska betalningsdokument på datorn med ARM KBR. Konverteringsskriptet körs också på ARM KBR.

Överensstämmelse mellan objekten i det presenterade schemat och elementen i integrationsmodellen:
På samma sätt som i Schema 1, men «Mäklare» används inte.

Schema 3. Integration mellan ABS och ARM KBR-N via IBM WebSphere MQ och signering av elektroniska dokument "på ABS-sidan"

ABS fungerar på en plattform som inte stöds av kryptografiska skyddsanordningar SKAD Signatur. Signeringen av utgående elektroniska dokument utförs på en speciell elektronisk signeringsserver (Signeringsservern). Denna server kontrollerar också den elektroniska signaturen på de dokument som kommer från Rysslands centralbank.

ABS laddar upp en fil med betalningsdokument till Signeringsservern i sitt eget format.
Signeringsservern konverterar filen till elektroniska meddelanden i UFEBS-format med hjälp av konverteringsskriptet, varefter de elektroniska meddelandena signeras och skickas till IBM WebSphere MQ.

ARM KBR-N kontaktar IBM WebSphere MQ och får signerade betalningsmeddelanden därifrån, varefter den auktoriserade medarbetaren — användaren av ARM KBR — krypterar dem och skickar dem till betalningssystemet för Rysslands centralbank.

Vid mottagandet av betalningar från Centralbanker i Ryssland avkodar ARMs KBR-N dem och verifierar den elektroniska signaturen. Framgångsrikt bearbetade betalningar i form av avkodade och signerade elektroniska meddelanden i formatet UFEBS överförs till IBM WebSphere MQ, där de tas emot av EP-servern.

EP-servern kontrollerar den elektroniska signaturen av de mottagna betalningarna och sparar dem i en ABS-fil. Därefter laddar en behörig medarbetare – användaren av ABS – den resulterande filen i ABS enligt fastställda rutiner.

Överensstämmelse mellan objekten i det presenterade schemat och elementen i integrationsmodellen:
«Utbytesserver från ABS-sidan» – servern för ABS.
«Utbytesserver från ARM KBR-sidan» — ARM KBR-datorn.
«Mäklare» – EP-servern och IBM WebSphere MQ.
«Databehandlingsprogram» – konverteringsscript, SKZI SKAD Signature på EP-servern.

Schema 4. Integration av DBO-servern och ABS via API, tillhandahållet av dedikerad utbytesserver

Låt oss anta att banken använder flera system för distansbanktjänster (DBO):

• «Internet Klient-Bank» för fysiska personer (IKB FL);
• «Internet Klient-Bank» för juridiska personer (IKB JL).

För att säkerställa informationssäkerhet sker all interaktion mellan ABS och DBO-system via en dedikerad utbytesserver som fungerar inom ramen för informationssystemet «ABS».

Vidare ska vi granska interaktionen mellan DBO-systemet IKB JL och ABS.
DBO-servern, efter att ha fått ett korrekt undertecknat betalningsuppdrag från kunden, måste skapa det motsvarande dokumentet i ABS. För detta ändamål överför den information via API till utbytesservern, som i sin tur uppdaterar data i ABS.

Vid förändringar i kundens kontobalans genererar ABS elektroniska meddelanden som via utbytesservern överförs till DBO-servern.

Överensstämmelse mellan objekten i det presenterade schemat och elementen i integrationsmodellen:
«Utbytesserver från DBO-sidan» – DBO-servern IKB JL.
«Utbytesserver från ABS-sidan» – utbytesservern.
«Mäklare» – saknas.
«Databehandlingsprogram» – komponenter av DBO-servern som ansvarar för användning av utbytesserverns API, komponenter av utbytesservern som ansvarar för användning av ABS API.

Överordnade säkerhetshot

Dekomposition
U1. Infiltrering av falsk information av illvilliga aktörer via integrationsmodulen.

U1. Infiltrering av falsk information av illvilliga aktörer via integrationsmodulen

Dekomposition
U1.1. Obemyndigad modifiering av legitima data vid överföring via nätverksanslutningar:
U1.1.1 Länk: «Typmodell av hot. Nätverksanslutning. U2. Obefogad modifiering av överförda data».

U1.2. Överföring av falska data genom kommunikationskanaler å legitima deltagare i utbytet:
U1.1.2 Länk: «Typmodell för hot. Nätverksanslutning. U3. Överträdelser av upphovsrätt för överförda data».

U1.3. Obefogad modifiering av legitima data vid deras behandling på utbytestjänster eller medlare:
U1.3.1. Länk: «Typmodell för hot. Informationssystem baserat på klient-serverarkitektur. U2. Obefogad modifiering av skyddad information under dess behandling av serverdelen av informationssystemet».

U1.4. Skapande av falska data på utbytestjänster eller medlare i namnet av en legitimerad deltagare i utbytet:
U1.4.1. Länk: «Typmodell för hot. Informationssystem baserat på klient-serverarkitektur. U1. Genomförande av obehöriga åtgärder från illasinnade aktörer i namn av en legitimerad användare».

U1.5. Obefogad modifiering av data vid deras behandling med hjälp av programvara för databehandling:
U1.5.1. genom illasinnade aktörers obehöriga ändringar av inställningar (konfiguration) av databehandlingsprogramvara.
U1.5.2. genom illasinnade aktörers obehöriga ändringar av exekverbara filer i databehandlingsprogramvara.
U1.5.3. genom interaktiv kontroll av illasinnade aktörer över databehandlingsprogramvarans verksamhet.

TYPMODELL FÖR HOT. SYSTEM FÖR KRYPTografisk SKYDD AV INFORMATION

Skyddsobjektet för vilket hotmodellen tillämpas (scope)

Skyddsmålet är ett system för kryptografisk skydd av information, som används för att säkerställa säkerheten för informationssystemet.

Arkitektur
Grunden för varje informationssystem är applikationsprogramvara (program), som implementerar dess specifika funktionalitet.

Kryptografiskt skydd realiseras vanligtvis genom anrop från affärslogiken i applikationsprogrammet till kryptografiska primitiva funktioner, som placeras i specialiserade bibliotek – kryptokärnor.

Kryptografiska primitiva funktioner inkluderar lågnivå kryptografiska funktioner, såsom:

• kryptera / avkoda en datablänk;
• skapa / verifiera en digital signatur för en datablänk;
• beräkna hash-funktionen för en datablänk;
• skapa / ladda / ladda ner nyckelinformation;
• och så vidare.

Affärslogik i applikationsprogramvara implementerar med hjälp av kryptografiska primitiva funktioner högre nivå funktionalitet:

• kryptera en fil med nycklar från valda mottagare;
• installera en säker nätverksanslutning;
• informera om resultaten av verifieringen av den elektroniska signaturen;
• mm.

Interaktionen mellan affärslogik och kryptokärna kan ske:

• direkt, genom att affärslogiken anropar kryptografiska primitiva från kryptokärnans dynamiska bibliotek (.DLL – för Windows, .SO – för Linux);
• indirekt, via kryptografiska gränssnitt – wrappers, som t.ex. MS Crypto API, Java Cryptography Architecture, PKCS#11 m.fl. I detta fall adresserar affärslogiken kryptointerfacet, som översätter anropet till den motsvarande kryptokärnan, vilken i det här fallet kallas kryptoleverantör. Användningen av kryptografiska gränssnitt gör det möjligt för applikationsprogramvaran att abstrahera från specifika kryptografiska algoritmer och vara mer flexibel.

Två typiska scheman för organisering av kryptokärnan kan särskiljas:

Schema 1 – Monolitisk kryptokärna


Schema 2 – Delad kryptokärna


Elementen i de angivna scheman kan vara antingen separata programmoduler som körs på samma dator eller nätverkstjänster som interagerar inom ramen för datanätverket.

Vid användning av system som bygger på schema 1 arbetar applikationsprogramvaran och kryptokärnan inom ramen för en enhetlig driftsmiljö för kryptomedel (SFK), till exempel på samma dator, under samma operativsystem. Systemanvändaren kan i regel också köra andra program inom samma driftsmiljö, inklusive sådana som innehåller skadlig kod. Under sådana förhållanden finns det en allvarlig risk för läckage av privata kryptografiska nycklar.

För att minimera risken används schema 2, där kryptokärnan delas upp i två delar:

1. Den första delen arbetar tillsammans med applikationsprogramvaran i en icke-förtroendefull miljö, där det finns en risk för infektion av skadlig kod. Vi kallar denna del – "programvarudelen".
2. Den andra delen arbetar i en förtroendefull miljö på en dedikerad enhet som innehåller ett lagringsutrymme för privata nycklar. Vi benämner denna del – "hårdvarudelen".

Indelningen av kryptokärnan i mjukvara och hårdvara är ganska villkorlig. Det finns system på marknaden som bygger på en uppdelad kryptokärna, men där "hårdvarudelen" representeras av en virtuell maskinavbild - virtual HSM (exempel).

Interaktionen mellan båda delarna av kryptokärnan sker på ett sådant sätt att de privata kryptografiska nycklarna aldrig överförs till mjukvarudelen och kan därför inte stjälas av skadlig kod.

Gränssnittet för interaktion (API) och uppsättningen av kryptografiska primitiva, som kryptokärnan tillhandahåller för programvaran, är identiskt i båda fallen. Skillnaden ligger i sättet de implementeras på.

Så när man använder en uppdelad kryptokärna, sker interaktionen mellan mjukvaru- och hårdvarudelar enligt följande princip:

1. Kryptografiska primitiva som inte kräver användning av den privata nyckeln (t.ex. beräkning av hash-funktion, verifiering av digitalt signatur etc.) utförs av mjukvarudelen.
2. Kryptografiska primitiva som använder den privata nyckeln (skapande av digital signatur, avkodning av data etc.) utförs av hårdvarudelen.

Låt oss illustrera arbetet med den uppdelade kryptokärnan med ett exempel på skapandet av en digital signatur:

1. Mjukvarudelen beräknar hash-funktionen för signerade data och överför detta värde till hårdvarudelen via kommunikationskanalen mellan kryptokärnorna.
2. Hårdvarudelen, som använder den privata nyckeln och hash, skapar värdet av den digitala signaturen och överför det till mjukvarudelen via kommunikationskanalen.
3. Mjukvarudelen returnerar det mottagna värdet till programvaran.

Specifika aspekter av verifieringen av korrektheten hos den digitala signaturen

När mottagande part får data som är signerade med en digital signatur, måste den genomföra flera kontrollsteg. Ett positivt resultat av verifieringen av den digitala signaturen uppnås endast efter att alla kontrollsteg har genomförts framgångsrikt.

Steg 1. Kontroll av dataintegritet och dataskapande.

Innehållet i steget. En kontroll av den elektroniska signaturens data utförs enligt den aktuella kryptografiska algoritmen. Ett framgångsrikt genomförande av detta steg indikerar att datan inte har modifierats sedan den signerades, samt att signaturen gjordes med en privat nyckel som motsvarar den offentliga nyckeln för kontroll av den elektroniska signaturen.
Platsen för genomförandet av steget: kryptokärna.

Steg 2. Kontroll av tillit till den offentliga nyckeln hos signaturen och kontroll av giltighetstiden för den privata nyckeln till den elektroniska signaturen.
Innehållet i steget. Steget består av två delmoment. I det första fastställs huruvida den offentliga nyckeln för kontroll av den elektroniska signaturen var betrodd vid tidpunkten för signeringen av datan. I det andra fastställs huruvida den privata nyckeln till den elektroniska signaturen var giltig vid tidpunkten för signeringen av datan. Generellt kan giltighetstiderna för dessa nycklar skifta (till exempel för kvalificerade certifikat för offentliga nycklar av den elektroniska signaturen). Sätten att fastställa tillit till den offentliga nyckeln hos signaturen bestäms av reglerna för elektronisk dokumenthantering som antas av de interagerande parterna.
Platsen för genomförandet av steget: applikationsprogramvara / kryptokärna.

Steg 3. Kontroll av signatarens befogenheter.
Innehållet i steget. I enlighet med de fastställda reglerna för elektronisk dokumenthantering kontrolleras det om signatären hade rätt att intyga de skyddade uppgifterna. Som exempel kan vi nämna en situation där befogenheterna åsidosätts. Anta att det finns en organisation där alla anställda har en elektronisk signatur. En interna beställning från ledningen kommer in i det elektroniska dokumenthanteringssystemet, men det är signerad med den elektroniska signaturen från lagerchefen. Följaktligen kan ett sådant dokument inte anses vara legitimt.
Platsen för genomförandet av steget: applikationsprogramvara.

Antaganden som gjorts vid beskrivningen av skyddsobjektet.

1. Informationsöverföringskanaler, förutom kanaler för nyckelutbyte, passerar också genom applikationsprogramvara, API och kryptokärna.
2. Information om tillit till offentliga nycklar och/eller certifikat samt information om befogenheterna hos innehavarna av offentliga nycklar lagras i en nyckelförvaringssystem.
3. Applikationsprogramvaran arbetar med nyckelförvaringssystemet genom kryptokärnan.

Exempel på ett informationssystem som skyddas med hjälp av SKEI.

För att illustrera de tidigare presenterade schemana kommer vi att överväga ett hypotetiskt informationssystem och identifiera alla dess strukturella element.

Beskrivning av informationssystemet

Två organisationer har beslutat att införa en juridiskt betydelsefull elektronisk dokumenthantering (EDO) mellan sig. För detta ändamål har de ingått ett avtal som anger att dokumenten ska överföras via e-post, och att de ska vara krypterade och signerade med en kvalificerad elektronisk signatur. Som verktyg för att skapa och bearbeta dokument ska program från Microsoft Office 2016 användas, och för kryptografisk skydd ska KryptoPRO och programvaran KryptoARM användas.

Beskrivning av organisation 1:s infrastruktur

Organisation 1 har beslutat att installera KryptoPRO och KryptoARM på användarens arbetsstation – den fysiska datorn. Krypterings- och signeringsnycklarna kommer att lagras på en nyckelmaskin ruToken som fungerar i läget för avtagbar nyckel. Användaren kommer att förbereda elektroniska dokument lokalt på sin dator, efter vilket de kommer att krypteras, signeras och skickas med den lokalt installerade e-postklienten.

Beskrivning av organisation 2:s infrastruktur

Organisation 2 har beslutat att flytta funktionerna för kryptering och elektronisk signatur till en dedikerad virtuell maskin. Alla kryptografiska operationer kommer att utföras automatiskt.

För detta ändamål har två nätverksmappar organiserats på den dedikerade virtuella maskinen: «…In», «…Out». I nätverksmappen «…In» kommer mottagna filer från motparten automatiskt att placeras i okrypterad form. Dessa filer kommer att dekrypteras och deras elektroniska signatur kommer att kontrolleras.

I mappen «…Out» kommer användaren att placera de filer som behöver krypteras, signeras och skickas till motparten. Själva filerna kommer användaren att förbereda på sin arbetsstation.
För att utföra funktioner för kryptering och elektronisk signatur har KryptoPRO, KryptoARM och en e-postklient installerats på den virtuella maskinen. Automatisk hantering av alla element på den virtuella maskinen kommer att ske genom skript utvecklade av systemadministratörer. Skripts arbeten protokollförs i loggfiler.

De kryptografiska nycklarna för den elektroniska signaturen kommer att lagras på en JaCarta ГОСТ-token med en icke-extraherbar nyckel, som användaren kommer att ansluta till sin lokala dator.

Token kommer att passera till den virtuella maskinen med hjälp av specialiserade programvaror USB-over-IP, installerade på användarens arbetsplats och på den virtuella maskinen.

Systemklockorna på användarens arbetsplats i organisation 1 kommer att justeras manuellt. Systemklockorna för den specialiserade virtuella maskinen i organisation 2 kommer att synkroniseras med systemklockorna hos hypervisorn, som i sin tur kommer att synkroniseras via internet med offentliga tidsservrar.

Utdelning av strukturelement för SKZI
Baserat på den ovan angivna IT-infrastrukturen kommer vi att identifiera strukturelementen för SKZI och dokumentera dem i en tabell.

Tabell — Överensstämmelse mellan elementen i SKZI-modellen och elementen i informationssystemen

Elementnamn
Organisation 1
Organisation 2

Applikationsprogramvara
KryptoARM-programvara
KryptoARM-programvara

Programdelen av kryptokärnan
SKZI KryptoPRO CSP
SKZI KryptoPRO CSP

Hårdvarudelen av kryptokärnan
inte
JaCarta ГОСТ

API
MS CryptoAPI
MS CryptoAPI

Nyckelhanteringslager
Användarens arbetsstation:
— hårddisk;
— standard Windows certifikatslager.
Hypervisor:
— hårddisk.

Virtuell maskin:
— hårddisk;
— standard Windows certifikatslager.

Lagring av privata nycklar
Nyckelbäraren ruToken, som arbetar i extraherbar nyckelläge
Nyckelbäraren JaCarta ГОСТ, som arbetar i icke-extraherbar nyckelläge

Kanal för utbyte av offentliga nycklar
Användarens arbetsstation:
— RAM.

Hypervisor:
— RAM.

Virtuell maskin:
— RAM.

Kanal för utbyte av privata nycklar
Användarens arbetsstation:
— USB-buss;
— RAM.
inte

Kanal för utbyte mellan kryptokärnor
saknas (ingen hårdvarudel av kryptokärnan)
Användarens arbetsstation:
— USB-buss;
— RAM;
— programmodul USB-over-IP;
— nätverksgränssnitt.

Företagsnätverket i organisation 2.

Hypervisor:
— RAM;
— nätverksgränssnitt.

Virtuell maskin:
— nätverksgränssnitt;
— RAM;
— programmodul USB-over-IP.

Kanal för utbyte av öppna data
Användarens arbetsstation:
— in- och utmatningsmedel;
— RAM;
— hårddisk.
Användarens arbetsstation:
— in- och utmatningsmedel;
— RAM;
— hårddisk;
— nätverksgränssnitt.

Företagsnätverket i organisation 2.

Hypervisor:
— nätverksgränssnitt;
— RAM;
— hårddisk.

Virtuell maskin:
— nätverksgränssnitt;
— RAM;
— hårddisk.

Kanal för utbyte av skyddade data
Internet.

Företagsnätverket i organisation 1.

Användarens arbetsstation:
— hårddisk;
— RAM;
— nätverksgränssnitt.

Internet.

Företagsnätverket i organisation 2.

Hypervisor:
— nätverksgränssnitt;
— RAM;
— hårddisk.

Virtuell maskin:
— nätverksgränssnitt;
— RAM;
— hårddisk.

Tidöverföringskanal
Användarens arbetsstation:
— in- och utmatningsmedel;
— RAM;
— systemtimer.

Internet.
Företagsnätverket i organisation 2,

Hypervisor:
— nätverksgränssnitt;
— RAM;
— systemtimer.

Virtuell maskin:
— RAM;
— systemtimer.

Kanal för överföring av kontrollkommandon
Användarens arbetsstation:
— in- och utmatningsmedel;
— RAM.

(Grafiskt användargränssnitt för KryptoARM-programvaran)

Virtuell maskin:
— RAM;
— hårddisk.

(Automatiseringsskripter)

Kanal för mottagning av resultat från arbetet
Användarens arbetsstation:
— in- och utmatningsmedel;
— RAM.

(Grafiskt användargränssnitt för KryptoARM-programvaran)

Virtuell maskin:
— RAM;
— hårddisk.

(Loggfiler från automatiseringsskriptens arbete)

Överordnade säkerhetshot

Förklaringar

Antaganden som gjordes vid nedbrytning av hot:

1. Säkra kryptografiska algoritmer används.
2. Kryptografiska algoritmer används på ett säkert sätt i rätt funktionslägen (till exempel, ECB används inte för att kryptera stora datamängder, med hänsyn till den tillåtna nyckbelastningen etc.).
3. Angripare känner till alla använda algoritmer, protokoll och öppna nycklar.
4. Angripare har tillgång till all krypterad data.
5. Angripare kan återskapa alla programkomponenter i systemet.

Dekomposition

U1. Kompromettering av hemliga kryptografiska nycklar.
U2. Kryptering av falska data i namnet av en legitim avsändare.
U3. Avkodning av krypterade data av personer som inte är legitima mottagare (angripare).
U4. Skapande av en elektronisk signatur från en legitim undertecknare under falska data.
U5. Få ett positivt resultat på kontrollen av den elektroniska signaturen på falska data.
U6. Felaktig acceptans av elektroniska dokument för utförande på grund av problem i arrangemanget av elektronisk dokumenthantering.
U7. Obehörig insyn till skyddade data under bearbetningen av kryptografiska medel.

U1. Kompromettering av hemliga kryptografiska nycklar

U1.1. Återvinning av hemlig nyckel från nyckellagringssystem.

U1.2. Återvinning av hemlig nyckel från objekt i kryptografiska medels funktionsmiljö, där den kan finnas temporärt.
Förklaringar till U1.2.

Objekt där hemliga nycklar kan lagras temporärt inkluderar:

1. RAM-minne,
2. temporära filer,
3. växlingsfiler,
4. hibernate-filer,
5. snapshot-filer med "varmt" tillstånd av virtuella maskiner, inklusive filer med innehåll i RAM-minnet av pausade virtuella maskiner.

U1.2.1. Extraktion av hemliga nycklar från aktivt RAM-minne genom att frysa RAM-moduler, extrahera dem och efterföljande läsning av data (freeze attack).
Förklaringar till U1.2.1.
Exempel attacker.

U1.3. Återvinning av hemlig nyckel från kanalen för utbyte av hemliga nycklar.
Förklaringar till U1.3.
Ett exempel på hur denna hot kan realiseras kommer att ges nedan.

U1.4. Obehörig modifiering av kryptografikärnan, vilket leder till att hemliga nycklar blir kända för angripare.

U1.5. Kompromiss av den privata nyckeln som ett resultat av användning av tekniska informationsläckkanaler (TIK).
Förklaringar till U1.5.
Exempel attacker.

U1.6. Kompromiss av den privata nyckeln som ett resultat av användning av speciella tekniska medel (STM) avsedda för hemlig uppsamling av information ("lyssnare").

U1.7. Kompromiss av privata nycklar under lagring utanför SSKZI.
Förklaringar till U1.7.
Till exempel, en användare lagrar sina nyckelmedier i skrivbordslådan, från vilken de lätt kan hämtas av illvilliga aktörer.

U2. Kryptering av falska data på uppdrag av en legitim avsändare.

Förklaringar
Denna hotisk kan endast beaktas för datakrypteringsscheman med avsändarautentisering. Exempel på sådana scheman anges i standardiseringsrekommendationerna. R 1323565.1.004-2017 "Informations teknologi. Krypto skydd av information. Scheman för generering av allmänna nycklar med autentisering baserad på offentlig nyckel".. För andra kryptografiska scheman finns det inget sådant hot, eftersom kryptering utförs med mottagarens offentliga nycklar, som i allmänhet är kända för illvilliga aktörer.

Dekomposition
U2.1. Kompromiss av den privata nyckeln hos avsändaren:
U2.1.1. Länk: "Typmodell av hot. System för kryptografiskt skydd av information. U1. Kompromiss av privata kryptografiska nycklar"..

U2.2. Ändring av indata i kanalen för utbyte av offentliga data.
Anmärkningar till U2.2.
Exempel på genomförande av denna hotisk anges nedan. ). Ett typiskt exempel på användning: och ). Ett typiskt exempel på användning:.

U3. Avkodning av krypterade data av personer som inte är legitima mottagare av data (illvilliga aktörer).

Dekomposition
U3.1. Kompromiss av mottagarens privata nycklar för krypterade data.
U3.1.1 Länk: "Typmodell av hot. System för kryptografiskt skydd av information. U1. Kompromiss av privata kryptografiska nycklar"..

U3.2. Ändring av krypterade data i kanalen för utbyte av skyddade data.

U4. Skapande av en elektronisk signatur från en legitim undertecknare på falska data.

Dekomposition
U4.1. Kompromiss av den privata nyckeln hos den legitima undertecknaren.
U4.1.1 Länk: "Typmodell av hot. System för kryptografiskt skydd av information. U1. Kompromiss av privata kryptografiska nycklar"..

U4.2. Ändring av de signerade data i kanalen för utbyte av offentliga data.
Anmärkning till U4.2.
Exempel på genomförande av denna hotisk anges nedan. ). Ett typiskt exempel på användning: och ). Ett typiskt exempel på användning:.

U5. Att få ett positivt resultat vid kontroll av den elektroniska signaturen på falska data.

Dekomposition
U5.1. Angripare fångar i överföringskanalen resultatet av kontrollen av den elektroniska signaturen och ersätter det med ett meddelande med ett positivt resultat.

U5.2. Angripare genomför en attack mot förtroendet för signeringscertifikat (SCENARIO — alla element är obligatoriska):
U5.2.1. Angripare genererar en offentlig och privat nyckel för den elektroniska signaturen. Om systemet använder certifikat för elektroniska signaturnycklar, genererar de ett signeringscertifikat som är så likt som möjligt certifikatet för den tilltänkta avsändaren av data vars meddelande de vill förfalska.
U5.2.2. Angripare gör obehöriga ändringar i lagret med offentliga nycklar och ger den genererade offentliga nyckeln nödvändiga nivåer av förtroende och behörigheter.
U5.2.3. Angripare signerar falska data med den elektroniska signaturen som skapades tidigare och injicerar dem i kanalen för att utbyta skyddade data.

U5.3. Angripare genomför en attack med hjälp av utgångna elektroniska signaturnycklar från den legitima undertecknaren (SCENARIO — alla element är obligatoriska):
U5.3.1. Angripare komprometterar utgångna (inte längre giltiga) privata nycklar för den elektroniska signaturen från den legitima avsändaren.
U5.3.2. Angripare ersätter tidsstämpeln i överföringskanalen med en tid då de komprometterade nycklarna fortfarande var giltiga.
U5.3.3. Angripare signerar falska data med den tidigare komprometterade elektroniska signaturen och injicerar dem i kanalen för att utbyta skyddade data.

U5.4. Angripare genomför en attack med hjälp av komprometterade elektroniska signaturnycklar från den legitima undertecknaren (SCENARIO — alla element är obligatoriska):
U5.4.1. Angripare gör en kopia av lagret med offentliga nycklar.
U5.4.2. Angripare komprometterar de privata nycklarna från en av de legitima avsändarna. Denna upptäcker komprometteringen, återkallar sina nycklar och information om nyckelåterkallelsen placeras i lagret med offentliga nycklar.
U5.4.3. Angripare ersätter lagret med offentliga nycklar med den tidigare kopierade.
U5.4.4. Angripare signerar falska data med den tidigare komprometterade elektroniska signaturen och injicerar dem i kanalen för att utbyta skyddade data.

U5.5. på grund av fel i implementeringen av steg 2 och 3 för verifiering av elektronisk signatur:
Förklaringar U5.5.
Exempel på implementering av denna risk ges nedan.

U5.5.1. Verifiering av förtroende för certifikatet för den elektroniska signaturen sker endast utifrån förtroendet för certifikatet som signerat det, utan kontroller av CRL eller OCSP.
Förklaringar U5.5.1.
Exempel på genomförande risk.

U5.5.2. Vid upprättande av en certifikatkedja analyseras inte behörigheterna hos utfärdande certifikat.
Förklaringar U5.5.2.
Exempel på attack mot SSL/TLS-certifikat.
Angripare köpte ett legitimt certifikat för sin e-post. Sedan skapade de ett falskt certifikat för webbplatsen och signerade det med sitt certifikat. Om inte behörigheter kontrolleras kommer verifieringen av certifikatkedjan att vara korrekt, och därmed även det falska certifikatet.

U5.5.3. Vid upprättande av en certifikatkedja kontrolleras inte mellanliggande certifikat för återkallelse.

U5.5.4. Uppdatering av CRL sker mindre frekvent än vad utfärdande certifikatmyndighet publicerar.

U5.5.5. Beslut om förtroende för den elektroniska signaturen fattas innan OCSP-svaret om certifikatets status, skickat på en begäran som görs efter underskrifts tid, mottagits eller innan nästa CRL efter skapandet av signaturen mottagits.
Förklaringar U5.5.5.
I föreskrifterna för de flesta certifikatmyndigheter anses tidpunkten för återkallande av certifikatet vara tidpunkten för utfärdande av närmaste CRL som innehåller information om återkallelsen av certifikatet.

U5.5.6. Vid mottagande av signerade data kontrolleras inte certifikatets tillhörighet till avsändaren.
Förklaringar U5.5.6.
Exempel på attack. När det gäller SSL-certifikat: kan det hända att överensstämmelsen mellan anropad servers adress och fältet CN i certifikatet inte kontrolleras.
Exempel på attack. Angripare har komprometterat de elektroniska signaturnycklarna hos en av parterna i betalningssystemet. Därefter hackade de nätverket hos en annan part och skickade i hans namn betalningsdokument till betalningssystemets räknerserver, signerade med de komprometterade nycklarna. Om servern endast analyserar förtroende och inte verifierar överensstämmelse, kommer falska dokument att betraktas som legitima.

U6. Felaktig acceptans av elektroniska dokument för utförande på grund av problem i arrangemanget av elektronisk dokumenthantering.

Dekomposition
U6.1. Mottagande part upptäcker inte dupliceringen av de mottagna dokumenten.
Förklaringar U6.1.
Exempel på attack. Brottslingar kan avlyssna dokument som skickas till mottagaren, även om de är kryptografiskt skyddade, och sedan sända dem flera gånger genom den säkra datakanalen. Om mottagaren inte upptäcker dubbletter, kommer alla mottagna dokument att behandlas och bemötas som olika dokument.

U7. Otillåten åtkomst till skyddade data under deras behandling av SKZI.

Dekomposition

U7.1. till följd av informationsläckage genom externa kanaler (side channel attack).
Förklaringar U7.1.
Exempel attacker.

U7.2. till följd av neutralisering av skyddet mot otillåten åtkomst till information som behandlas av SKZI:
U7.2.1. Utnyttjande av SKZI med överträdelser av kraven som beskrivs i dokumentationen för SKZI.

U7.2.2. genomfört på grund av förekomsten av sårbarheter i:
U7.2.2.1. skyddsmekanismer mot otillåten åtkomst.
U7.2.2.2. själva SKZI.
U7.2.2.3. miljön där kryptografiska medel fungerar.

Exempel på attacker

De scenarier som beskrivs nedan innehåller medvetet fel i organisationen av informationssäkerhet och tjänar endast som illustration av möjliga attacker.

Scenario 1. Exempel på genomförande av hot U2.2 och U4.2.

Objektbeskrivning


Programvaran för ARM KBR och SKZI SKAD Sigant har installerats på en fysisk dator som inte är ansluten till datanätverket. Den viktigaste lagringsmediet som används är FKN vdToken i driftläge med en oåtkomlig nyckel.

Reglerna för att utföra transaktioner föreskriver att transaktionsspecialisten laddar ned elektroniska meddelanden i klartext (schemat för den gamla ARM KBR) från en speciell skyddad filserver, sedan skriver de på en avlägsnad enhet USB-minne och överför dem till ARM KBR, där de krypteras och signeras. Därefter överför specialisten de skyddade elektroniska meddelandena till den avlägsnade enheten, och sedan skriver han dem via sin arbetsdator till filservern, där de går vidare till UTA och sedan till betalningssystemet för Rysslands Bank.

I detta fall kommer kanalerna för utbyte av öppna och skyddade data att omfatta: filservern, specialistens arbetsdator och den avlägsnade enheten.

Attack
Angripare installerar obehörigt ett fjärrstyrningssystem på en anställds arbetsdator och vid överföring av betalningsorder (e-meddelanden) i klartext ändrar innehållet i en av dem. Den anställde överför betalningsordern till KBR:s arbetsstation, undertecknar och krypterar den utan att märka bytet (till exempel på grund av ett stort antal betalningsordrar under resan, trötthet osv.). Efter detta passerar den falska betalningsordern genom den teknologiska kedjan och hamnar i Rysslands banks betalningssystem.

Scenario 2. Exempel på implementering av hoten U2.2 och U4.2.

Objektbeskrivning


Datorn med installerade KBR:s arbetsstation, SCAD Signatur och ansluten nyckelportfölj FKN vdToken fungerar i ett avskilt rum utan tillgång från personal.
Den anställde kopplar upp sig mot KBR:s arbetsstation i fjärråtkomstläge via RDP-protokollet.

Attack
Angripare avlyssnar uppgifter som den anställde använder för att ansluta och arbeta med KBR:s arbetsstation (till exempel genom skadlig kod på hans dator). De genomför en anslutning i hans namn och skickar en falsk betalningsorder till Rysslands banks betalningssystem.

Scenario 3. Exempel på implementering av hotet U1.3.

Objektbeskrivning


Låt oss överväga ett av de hypotetiska alternativen för integrationen av "ABS-KBR" för det nya systemet (KBR-N), där den elektroniska signaturen för utgående dokument sker på sidan av ABS. Vi antar att ABS fungerar på en plattform av ett operativsystem som inte stöds av SCAD Signatur, och därför har den kryptografiska funktionen flyttats till en separat virtuell maskin — integrationsmodulen "ABS-KBR".
Som nyckelportfölj används en vanlig USB-token som fungerar i avtagbar nyckelmodus. När nyckelportföljen kopplades till hypervisorn visade det sig att det inte fanns några lediga USB-portar, så det beslutades att ansluta USB-token via en nätverks-USB-hub, och på den virtuella maskinen installera klienten USB-over-IP som skulle kommunicera med huben.

Attack
Angripare fångade den privata nyckeln för den elektroniska signaturen från kommunikationskanalen mellan USB-hubben och hypervisorn (data överfördes i klartext). Med den privata nyckeln skapade angriparna en falsk betalningsorder, signerade den med den elektroniska signaturen och skickade den till ARM KBR-N för utförande.

Scenario 4. Exempel på genomförande av hot U5.5.

Objektbeskrivning
Låt oss betrakta samma schema som i det föregående scenariot. Vi antar att elektroniska meddelanden som kommer från ARM KBR-N hamnar i mappen …SHAREIn, medan de som skickas till ARM KBR-N och vidare till betalningssystemet i Bank of Russia hamnar i …SHAREout.
Vi antar också att när integrationsmodulen genomförs så uppdateras listorna över återkallade certifikat endast vid omutfärdande av kryptografiska nycklar, samt att elektroniska meddelanden som kommer till mappen …SHAREIn endast kontrolleras för integritetskontroll och kontroll av tillit till den offentliga nyckeln för den elektroniska signaturen.

Attack

Angripare, som utnyttjade de stulna nycklarna från det föregående scenariot, signerade en falsk betalningsorder som innehöll information om att pengar skulle sättas in på kontot för en bedragarkund och införde den i kanalen för utbyte av skyddade data. Eftersom det inte görs någon kontroll av att betalningsordern verkligen är signerad av Bank of Russia, accepteras den för utförande.

Källa: habr.com