Links til andre dele af undersøgelsen
- (Du er her)
Denne artikel afslutter cyklussen af publikationer, der omhandler informationssikkerhed ved bankens kontante betalinger. Her vil vi se på standard trusselsmodeller, som der henvises til i :
- .
- .
- .
- .
HABRO-WARNING !!! Kære Habrowere, dette er ikke et underholdningsindlæg.
Skjult under kat er 40+ sider materiale beregnet til at hjælpe i arbejdet eller undervisningen mennesker, der specialiserer sig i bankvæsen eller informationssikkerhed. Disse materialer er det endelige produkt af undersøgelsen og skrevet i en tør officiel tone. I realiteten er dette skabeloner til interne dokumenter om IS.Og det traditionelle - «anvendelse af oplysningerne i artiklen til ulovlige formål straffes i henhold til loven». God læsning!
Information til læsere, der starter med denne publikation for at lære om undersøgelsen.
Hvad handler undersøgelsen om
Du læser en guide for specialisten ansvarlig for at sikre informationssikkerheden ved betalinger i banken.
Logikken i beskrivelsen
I begyndelsen i og en beskrivelse af beskyttelsesobjektet gives. Derefter i beskrives, hvordan man bygger et beskyttelsessystem, og der tales om nødvendigheden af at danne en trusselsmodel. I beskrives, hvilke trusselsmodeller der findes, og hvordan de dannes. I og gives en analyse af reelle angreb. og indeholder en beskrivelse af trusselsmodellen, bygget med information fra alle de foregående dele.
TYPISK TRUSSEL MODEL. NETVÆRKSFORBINDELSE
Beskyttelsesobjektet, som trusselsmodellen anvendes til (scope)
Beskyttelsesobjektet er data, der overføres gennem en netværksforbindelse, der fungerer i datatransmission netværk bygget på TCP/IP-stakken.
Arkitektur
Beskrivelse af arkitekturens elementer:
- «Endepunkter» — noder, der udveksler beskyttet information.
- «Mellemliggende noder» — elementer i datatransmissionsnetværket: routere, switcher, adgangsservere, proxy-servere og andet udstyr, gennem hvilket trafikken fra netværksforbindelsen sendes. Generelt kan en netværksforbindelse fungere uden mellemliggende noder (direkte mellem endepunkterne).
Trusler for sikkerheden på højeste niveau
Dekomposition
U1. Uautoriseret adgang til de overførte data.
U2. Uautoriseret ændring af de overførte data.
U3. Overtrædelse af ophavsret vedrørende de overførte data.
U1. Uautoriseret adgang til de overførte data
Dekomposition
U1.1. , udført på endepunkterne eller de mellemliggende noder:
U1.1.1. ved at læse data, mens de er i nodeopbevaringssystemerne:
U1.1.1.1. i RAM.
Forklaringer til U1.1.1.1.
For eksempel under behandling af data af nodeens netværksstak.
U1.1.1.2. i ikke-flygtig hukommelse.
Forklaringer til U1.1.1.2.
For eksempel når de overførte data opbevares i cache, midlertidige filer eller swaps.
U1.2. , udført på tredjeparts noder i datatransmissionsnetværket:
U1.2.1. ved at fange alle pakker, der rammer nodeens netværksinterface:
Forklaringer til U1.2.1.
Indfangning af alle pakker sker ved at skifte netværkskortet til en uklar tilstand (promiscuous mode for kablede adaptere eller monitor mode for Wi-Fi adaptere).
U1.2.2. ved at udføre såkaldte "man-in-the-middle (MiTM)" angreb, men uden at ændre de overførte data (bortset fra de tekniske data fra netværksprotokoller).
U1.2.2.1. Link: .
U1.3. , udført ved hjælp af informationslækager gennem tekniske kanaler (TKUI) fra fysiske noder eller kommunikationslinjer.
U1.4. , udført ved at installere særlige tekniske midler (STM) på slut- eller mellemnoder designet til hemmelig dataindsamling.
U2. Uautoriseret modifikation af de overførte data.
Dekomposition
U2.1. , udført på slut- eller mellemnoder:
U2.1.1. ved at læse og ændre data mens de er i nodeenhedens hukommelse:
U2.1.1.1. i RAM:
U2.1.1.2. i ikke-flygtig hukommelse:
U2.2. , udført på eksterne noder i datatransmissionsnetværk:
U2.2.1. ved at udføre såkaldte "man-in-the-middle (MiTM)" angreb og omdirigere trafikken til en angribers enhed:
U2.2.1.1. Fysisk tilslutning af angriberens udstyr i bruddet af netværksforbindelsen.
U2.2.1.2. Udførelse af angreb på netværksprotokoller:
U2.2.1.2.1. styring af virtuelle lokale netværk (VLAN):
U2.2.1.2.1.1. .
U2.2.1.2.1.2. Uautoriseret modifikation af VLAN-indstillinger på switcher eller routere.
U2.2.1.2.2. trafikrouting:
U2.2.1.2.2.1. Uautoriseret modifikation af statiske routingtabeller på routere.
U2.2.1.2.2.2. Annoncering af falske ruter af angribere gennem dynamiske routingprotokoller.
U2.2.1.2.3. automatisk konfiguration:
U2.2.1.2.3.1. .
U2.2.1.2.3.2. .
U2.2.1.2.4. adressering og navneopløsning:
U2.2.1.2.4.1. .
U2.2.1.2.4.2. .
U2.2.1.2.4.3. Uautoriseret ændring af lokale navnefilers indhold (hosts, lmhosts osv.)
U3. Overtrædelse af ophavsret på de overførte data.
Dekomposition
U3.1. Neutralisering af mekanismer til bestemmelse af informationens ophav ved at angive falske oplysninger om forfatteren eller datakilden:
U3.1.1. Ændring af oplysninger om forfatteren, der findes i de overførte oplysninger.
U3.1.1.1. Neutralisering af kryptografisk beskyttelse af integritet og ophavsret for overførte data:
U3.1.1.1.1. Link: .
U3.1.1.2. Neutralisering af ophavsretbeskyttelse af overførte data, implementeret med engangskoder til bekræftelse:
U3.1.1.2.1. .
U3.1.2. Ændring af oplysninger om kilden til de overførte informationer:
U3.1.2.1. .
U3.1.2.2. .
STANDARD TRUSSELSMODEL. INFORMATIONSYSTEM BYGGET PÅ CLIENT-SERVER ARKITEKTUR
Beskyttelsesobjektet, som trusselsmodellen anvendes til (scope)
Objektet for beskyttelse er et informationssystem bygget på client-server arkitektur.
Arkitektur
Beskrivelse af arkitekturens elementer:
- «Client» – enhed, hvorpå klientdelen af informationssystemet fungerer.
- «Server» – enhed, hvorpå serverdelen af informationssystemet fungerer.
- «Datasøgning» — en del af serverinfrastrukturen i informationssystemet, der er beregnet til at gemme data, som informationssystemet behandler.
- «Netværksforbindelse» — informationsudvekslingskanal mellem Client og Server, som går gennem datatransmissionsnetværket. En mere detaljeret beskrivelse af elementmodellen er givet i .
Begrænsninger
Ved modellering af objektet er følgende begrænsninger fastsat:
- Brugeren interagerer med informationssystemet inden for bestemte tidsrum, kaldet arbejdssessioner.
- I begyndelsen af hver arbejdssession sker identifikation, autentikation og autorisation af brugeren.
- Alle beskyttede oplysninger opbevares på serverdelen af informationssystemet.
Trusler for sikkerheden på højeste niveau
Dekomposition
U1. Udførelse af uautoriserede handlinger af ondsindede aktører på vegne af en legitim bruger.
U2. Uautoriseret ændring af beskyttede oplysninger under deres behandling af serverdelen af informationssystemet.
U1. Udførelse af uautoriserede handlinger af ondsindede aktører på vegne af en legitim bruger
Forklaringer
Normalt i informationssystemer relateres handlinger med den bruger, der udførte dem, ved hjælp af:
- systemlogfiler (logs).
- specielle attributter af dataobjekter, der indeholder oplysninger om den bruger, der har oprettet eller ændret dem.
I forhold til arbejdsprocessen kan denne trussel nedbrydes til:
- udført inden for arbejdsprocessen for brugeren.
- udført uden for arbejdsprocessen for brugeren.
Brugerens arbejdsførelse kan være initieret af:
- Brugeren selv.
- Kriminelle.
På dette stadium vil den mellemliggende nedbrydning af denne trussel se således ud:
U1.1. Uautoriserede handlinger udført inden for arbejdsprocessen for brugeren:
U1.1.1. , installeret af den angrebne bruger.
U1.1.2. , installeret af kriminelle.
U1.2. Uautoriserede handlinger udført uden for arbejdsprocessen for brugeren.
Set fra perspektivet af informationsinfrastrukturens objekter, som kriminelle kan påvirke, vil nedbrydningen af de mellemliggende trusler se således ud:
Elementer
Nedbrydning af trusler
U1.1.1.
U1.1.2.
U1.2.
Kunde
U1.1.1.1.
U1.1.2.1.
Netværksforbindelse
U1.1.1.2.
Server
U1.2.1.
Dekomposition
U1.1. Uautoriserede handlinger udført inden for arbejdsprocessen for brugeren:
U1.1.1. , installeret af den angrebne bruger:
U1.1.1.1. Kriminelle handlede selvstændigt fra Kunden:
U1.1.1.1.1 Kriminelle brugte standard adgangsmidler fra informationssystemet:
U1.1.1.1.1.1. Kriminelle brugte fysiske input-output midler fra Kunden (tastatur, mus, skærm eller touchskærm på mobilenhed):
U1.1.1.1.1.1.1. Kriminelle handlede i perioder, hvor sessionen er aktiv, input-output midler er tilgængelige, og brugeren ikke var til stede.
U1.1.1.1.1.2. Kriminelle brugte fjernadministrationsmidler (standard eller givet af ondsindet kode) til at styre Kunden:
U1.1.1.1.1.2.1. Kriminelle handlede i perioder, hvor sessionen er aktiv, input-output midler er tilgængelige, og brugeren ikke var til stede.
U1.1.1.1.1.2.2. Kriminelle brugte fjernadministrationsmidler, hvis funktioner er usynlige for den angrebne bruger.
U1.1.1.2. Kriminelle ændrede data i netværksforbindelsen mellem Kunden og Serveren, så de blev opfattet som handlinger fra en legitim bruger:
U1.1.1.2.1. Link: .
U1.1.1.3. Ondsindere tvang brugeren til at udføre de angivne handlinger ved at anvende metoder inden for social engineering.
U1.1.2 <…> fastsat af ondsindede:
U1.1.2.1. Ondsindede handlede fra Klienten (Og):
U1.1.2.1.1. Ondsindede neutraliserede adskillelsessystemet i informationssystemet:
U1.1.2.1.1.1. Link: .
U1.1.2.1.2. Ondsindede brugte standardadgangsmetoderne til informationssystemet
U1.1.2.2. Ondsindede handlede fra andre knudepunkter i datatransmissionsnetværket, fra hvilke der kan oprettes en netværksforbindelse til Serveren (Og):
U1.1.2.2.1. Ondsindede neutraliserede adskillelsessystemet i informationssystemet:
U1.1.2.2.1.1. Link: .
U1.1.2.2.2. Ondsindede brugte ikke-standard adgangsmetoder til informationssystemet.
Forklaringer U1.1.2.2.2.
Ondsindede kunne installere den standardklient i informationssystemet på en ekstern node eller kunne bruge ikke-standard software, der implementerer standardprotokoller til dataudveksling mellem Klienten og Serveren.
U1.2 Uautoriserede handlinger blev udført uden for brugerens arbejdssession.
U1.2.1 Ondsindede udførte uautoriserede handlinger og derefter foretog uautoriserede ændringer i logfilerne for informationssystemet eller i særlige attributter for datagener, og angav, at de handlinger, de foretog, blev udført af en legitim bruger.
U2. Uautoriseret modificering af beskyttede oplysninger under behandlingen af dem af serverdelen af informationssystemet.
Dekomposition
U2.1. Ondsindede modificerer beskyttede oplysninger ved hjælp af standardmetoder fra informationssystemet og udfører dette på vegne af en legitim bruger.
U2.1.1. Link: .
U2.2. Ondsindede ændrer beskyttede oplysninger ved at bruge mekanismer til dataadgang, der ikke er forudset i de standardfunktioner, der kræves af informationssystemet.
U2.2.1. Ondsindede ændrer filer, der indeholder beskyttede oplysninger:
U2.2.1.1. , ved at bruge filhåndteringsmekanismerne, der leveres af operativsystemet.
U2.2.1.2. ved at fremkalde gendannelse af filer fra en uautoriseret modificeret backup.
U2.2.2. Angribere modificerer den beskyttede information, der opbevares i databasen (Og):
U2.2.2.1. Angribere neutraliserer adgangskontrolsystemet i databasesystemet:
U2.2.2.1.1. Link: .
U2.2.2.2. Angribere modificerer informationen ved at bruge standardgrænsefladerne i databasesystemet for at få adgang til dataene.
U2.3. Angribere modificerer den beskyttede information ved uautoriseret ændring af algoritmerne, der behandler den.
U2.3.1. Der foretages ændringer i kildekoden til softwaren.
U2.3.1. Der foretages ændringer i maskinkoden til softwaren.
U2.4. Angribere modificerer den beskyttede information ved at udnytte sårbarheder i softwaren i informationssystemet.
U2.5. Angribere modificerer den beskyttede information under transmission mellem komponenterne i serverdelen af informationssystemet (for eksempel mellem databaser og applikationsservere):
U2.5.1. Link: .
TYPISK TRUSSEL MODEL. ADGANGSKONTROL SYSTEM
Beskyttelsesobjektet, som trusselsmodellen anvendes til (scope)
Beskyttelsesobjektet, som denne trusselsmodel anvendes på, svarer til beskyttelsesobjektet i trusselsmodellen: "Typisk trusselsmodel. Informationssystem baseret på klient-server-arkitektur."
Med adgangskontrolsystemet for brugere i denne trusselsmodel henvises der til en komponent i informationssystemet, der udfører funktioner:
- Identifikation af brugere.
- Godkendelse af brugere.
- Autorisation af brugere.
- Protokollering af brugerhandlinger.
Trusler for sikkerheden på højeste niveau
Dekomposition
U1. Uautoriseret etablering af en session i navnet på en legitim bruger.
U2. Uautoriseret opgradering af brugerens privilegier i informationssystemet.
U1. Uautoriseret etablering af en session i navnet på en legitim bruger.
Forklaringer
Decomposition of this threat will generally depend on the type of user identification and authentication systems being used.
Denne model vil kun se på systemet til identifikation og godkendelse af brugere, der bruger tekstlogin og kodeord. Vi antager, at brugerens login er offentligt tilgængelig information, som er kendt af angribere.
Dekomposition
U1.1. gennem kompromittering af legitimationsoplysninger:
U1.1.1. Angribere har kompromitteret brugerens legitimationsoplysninger under opbevaringen.
Forklaringer U1.1.1.
For eksempel kunne legitimationsoplysninger være skrevet på en sticky note og klistret på skærmen.
U1.1.2. Brugeren har utilsigtet eller med vilje givet adgangsoplysninger til angribere.
U1.1.2.1. Brugeren sagde sine legitimationsoplysninger højt, mens de blev indtastet.
U1.1.2.2. Brugeren overleverede bevidst sine legitimationsoplysninger:
U1.1.2.2.1. til kolleger.
Forklaringer U1.1.2.2.1.
For eksempel, så de kunne erstatte ham under sygdom.
U1.1.2.2.2. til virksomhedens kontrahenter, der arbejder med objekter i informationsinfrastrukturen.
U1.1.2.2.3. til tredjeparter.
Forklaringer U1.1.2.2.3.
En af, men ikke den eneste mulighed for at realisere denne trussel er anvendelsen af social engineering metoder af angribere.
U1.1.3. Angribere har gættet legitimationsoplysninger ved at bruge brute force:
U1.1.3.1. ved at bruge standardsikkerhedsmekanismer.
U1.1.3.2. ved at bruge tidligere opsnappede koder (f.eks. hashes af kodeord) til opbevaring af legitimationsoplysninger.
U1.1.4. Angribere har brugt ondsindet kode til at opsnappe brugerens legitimationsoplysninger.
U1.1.5. Angribere har udvundet legitimationsoplysninger fra netværksforbindelsen mellem klienten og serveren:
U1.1.5.1. Link: .
U1.1.6. Angribere har udvundet legitimationsoplysninger fra optagelser af overvågningssystemer:
U1.1.6.1. overvågningssystemer (hvis der under arbejdet blev registreret tastetryk).
U1.1.6.2. systemer til kontrol af medarbejdernes handlinger ved computeren.
Forklaringer U1.1.6.2.
Et eksempel på et sådant system er - .
U1.1.7. Angribere har kompromitteret brugerens legitimationsoplysninger på grund af mangler i processen for deres overførsel.
Forklaringer U1.1.7.
For eksempel, overførsel af adgangskoder i klar tekst via e-mail.
U1.1.8. Angrebsvinnere opnåede legitimationsoplysninger ved at overvåge brugerens session ved hjælp af fjernadministrationssystemer.
U1.1.9. Angrebsvinnere udvandt legitimationsoplysninger som følge af lækager gennem tekniske kanaler (TKUI):
U1.1.9.1. Angrebsvinnere så, hvordan brugeren indtaster legitimationsoplysninger via tastaturet:
U1.1.9.1.1 Angrebsvinnere var placeret i umiddelbar nærhed af brugeren og så indtastningen af legitimationsoplysningerne med egne øjne.
Forklaringer U1.1.9.1.1
Sådanne tilfælde kan omfatte kollegers handlinger eller situationer, hvor brugerens tastatur kunne ses af besøgende i organisationen.
U1.1.9.1.2 Angrebsvinnere brugte yderligere tekniske midler, såsom en kikkert eller en drone, og så indtastningen af legitimationsoplysningerne gennem et vindue.
U1.1.9.2. Angrebsvinnere udvandt legitimationsoplysninger fra radioudvekslinger mellem tastaturet og computerens systemenhed i tilfælde af, at de blev tilsluttet via radiointerface (f.eks. Bluetooth).
U1.1.9.3. Angrebsvinnere havde til hensigt at opsnappe legitimationsoplysninger gennem lækage via kanalen for sekundære elektromagnetiske emissioner og interferens (PÉMI).
Forklaringer U1.1.9.3.
Eksempler på angreb og .
U1.1.9.4. Angrebsvinderen opsnappede indtastningen af legitimationsoplysninger fra tastaturet ved hjælp af specielle tekniske midler (STM), der er beregnet til hemmelig indsamling af information.
Forklaringer U1.1.9.4.
Eksempler .
U1.1.9.5. Angrebsvinnere opsnappede indtastningen af legitimationsoplysninger fra tastaturet ved at
analysere Wi-Fi-signalet, der var moduleret ved brugerens tastetryk.
Forklaringer U1.1.9.5.
Eksempel .
U1.1.9.6. Angrebsvinnere opsnappede indtastningen af legitimationsoplysninger fra tastaturet ved at analysere lydene fra tastetryk.
Forklaringer U1.1.9.6.
Eksempel .
U1.1.9.7. Angrebsvinnere opsnappede indtastningen af legitimationsoplysninger fra en mobil enhed ved at analysere accelerometerdataene.
Forklaringer U1.1.9.7.
Eksempel .
U1.1.10. , forud for gemt på Klienten.
Forklaringer U1.1.10.
For eksempel kunne brugeren have gemt brugernavn og adgangskode i browseren til adgang til en bestemt hjemmeside.
U1.1.11. Angrebsvinnere kompromitterede legitimationsoplysningerne som følge af svagheder i tilbagekaldesprocessen for brugertilgange.
Forklaringer U1.1.11.
For eksempel, efter en brugers opsigelse forblev hans kontoer ikke låst.
U1.2. <…> ved at udnytte sårbarheder i adskillelsessystemet.
U2. Uautoriseret forhøjelse af en brugers privilegier i informationssystemet
Dekomposition
U2.1 <…> ved at foretage uautoriserede ændringer i data, der indeholder oplysninger om brugerens privilegier.
U2.2 <…> ved at udnytte sårbarheder i adskillelsessystemet.
U2.3. <…> på grund af mangler i brugeradgangsstyringsprocessen.
Forklaringer U2.3.
Eksempel 1. Brugeren fik adgang, der var større, end hvad der var nødvendigt for hans arbejdsopgave.
Eksempel 2. Efter overflytning af brugeren til en anden stilling blev de tidligere tildelte adgangsrettigheder ikke tilbagekaldt.
TYPISK TRUSSEL MODEL. INTEGRATIONS MODUL
Beskyttelsesobjektet, som trusselsmodellen anvendes til (scope)
Integrationsmodulet er en samling af objekter i informationsinfrastrukturen, der er designet til at organisere informationsudveksling mellem informationssystemer.
I betragtning af, at det i virksomhedsnetsværk ikke altid er muligt entydigt at adskille ét informationssystem fra et andet, kan integrationsmodulet også betragtes som et bindeled mellem komponenterne inden for ét informationssystem.
Arkitektur
Den generelle skema for integrationsmodulet ser således ud:
Beskrivelse af arkitekturens elementer:
- «Databytte server (DBS)» – en node / service / komponent i informationssystemet, der udfører funktionen at udveksle data med et andet informationssystem.
- «Mægler» – en node / service, der er designet til at organisere interaktionen mellem informationssystemer, men ikke indgår i deres opbygning.
Eksempler «Mæglere» kan være e-mailtjenester, virksomhedsservicebusser (enterprise service bus / SoA-arkitektur), eksterne filservere osv. Generelt kan integrationsmodulet også være uden «Mæglere». - «Databehandlingssoftware» – en samling programmer, der implementerer dataudvekslingsprotokoller og formatomdannelse.
For eksempel omdannelse af data fra UFEBS-format til ABS-format, ændring af status for beskeder under overførsel osv. - «Netværksforbindelse» svarer til det objekt, der er beskrevet i den typiske trusselmodel «Netværksforbindelse». Nogle netværksforbindelser af dem, der er præsenteret i det ovenstående diagram, kan muligvis ikke være til stede.
Eksempler på integrationsmoduler
Skema 1. Integration af ABS og ARM KBR via en ekstern filserver
For at udføre betalinger eksporterer den bemyndigede bankmedarbejder elektroniske betalingsdokumenter fra ABS og gemmer dem i en fil (i et eget format, f.eks. SQL-dump) på en netværksmappe (…SHARE) på filserveren. Derefter konverteres denne fil ved hjælp af et konverteringsscript til et sæt filer i UFEABS-format, som derefter læses af ARM KBR.
Herefter krypterer og underskriver den bemyndigede medarbejder – brugeren af ARM KBR – den modtagne fil og sender den til betalingssystemet i den russiske bank.
Når der modtages betalinger fra den russiske bank, dekrypterer ARM KBR dem og kontrollerer den elektroniske underskrift, hvorefter de gemmes som et sæt filer i UFEABS-format på filserveren. Før betalingsdokumenterne importeres til ABS, konverteres de ved hjælp af et konverteringsscript fra UFEABS-format til ABS-format.
Lad os antage, at i dette skema fungerer ABS på en fysisk server, ARM KBR fungerer på en dedikeret computer, og konverteringsscriptet kører på filserveren.
Overensstemmelse mellem objekterne i det beskrevne skema og elementerne i integrationsmodulmodellen:
«Udvekslingsservere fra ABS-siden» – ABS-server.
«Udvekslingsservere fra ARM KBR-siden» – ARM KBR-computer.
«Mægler» – ekstern filserver.
«Databehandlingssoftware» – konverteringsscript.
Skema 2. Integration af ABS og ARM KBR ved placering af en fælles netværksmappe med betalinger på ARM KBR
Alt er det samme som i Skema 1, men en separat filserver bruges ikke; i stedet placeres netværksmappen (…SHARE) med elektroniske betalingsdokumenter på computeren med ARM KBR. Konverteringsscriptet kører også på ARM KBR.
Overensstemmelse mellem objekterne i det beskrevne skema og elementerne i integrationsmodulmodellen:
Svarende til Skema 1, men «Mægler» bruges ikke.
Skema 3. Integration af ABS og ARM KBR-N gennem IBM WebSphere MQ og underskrivning af elektroniske dokumenter «på ABS-siden»
ABS kører på en platform, der ikke understøttes af SKZI SKAD Signatur. Underskrivningen af de udgående elektroniske dokumenter udføres på en særlig server for elektronisk signatur (EP-server). Denne server kontrollerer også den elektroniske underskrift af de indgående dokumenter fra den russiske bank.
ABS eksporterer til EP-serveren en fil med betalingsdokumenterne i sit eget format.
EP-serveren bruger et konverteringsscript til at omdanne filen til elektroniske meddelelser i UFEBS-format, hvorefter de elektroniske meddelelser underskrives og sendes til IBM WebSphere MQ.
ARM KBR-N henter de signerede betalingsmeddelelser fra IBM WebSphere MQ, hvorefter den autoriserede medarbejder – brugeren af ARM KBR – krypterer dem og sender dem til betalingssystemet i Rusland.
Når betalinger modtages fra Rusland, dekrypterer ARM KBR-N dem og kontrollerer den elektroniske signatur. Behandlede betalinger afleveres som dekrypterede og signerede elektroniske meddelelser i UFEBS-format til IBM WebSphere MQ, hvorfra de modtages af EP-serveren.
EP-serveren kontrollerer den elektroniske signatur på de modtagne betalinger og gemmer dem i en ABS-format fil. Herefter uploader den autoriserede medarbejder – brugeren af ABS – den resulterende fil til ABS som foreskrevet.
Overensstemmelse mellem objekterne i det beskrevne skema og elementerne i integrationsmodulmodellen:
«Udvekslingsserver fra ABS» – ABS-server.
«Udvekslingsserver fra ARM KBR» – ARM KBR-computer.
«Mægler» – EP-server og IBM WebSphere MQ.
«Databehandlingssoftware» – konverteringsscript, SKZI SKAD Signatur på EP-serveren.
Diagram 4. Integration af DBO-server og ABS via API, leveret af den dedikerede udvekslingsserver
Lad os antage, at banken bruger flere systemer til fjernbanktjenester (DBO):
- «Internet Client-Bank» for private (IKB FL);
- «Internet Client-Bank» for juridiske personer (IKB JL).
For at sikre informationssikkerheden sker al interaktion mellem ABS og DBO-systemer gennem en dedikeret udvekslingsserver, der fungerer inden for informationssystemet «ABS».
Lad os nu se på interaktionsprocessen mellem DBO-systemet IKB JL og ABS.
DBO-serveren, efter at have modtaget en korrekt attestet betalingsordre fra klienten, skal på dens grundlag oprette et tilsvarende dokument i ABS. Til dette sender den via API oplysningerne til udvekslingsserveren, som igen indtaster dataene i ABS.
Når saldoen på klientens konto ændres, genererer ABS elektroniske meddelelser, som gennem udvekslingsserveren sendes til DBO-serveren.
Overensstemmelse mellem objekterne i det beskrevne skema og elementerne i integrationsmodulmodellen:
«Udvekslingsserver fra DBO» – DBO-server for IKB JL.
«Udvekslingsserver fra ABS» – udvekslingsserver.
«Mægler» – ikke tilgængelig.
«Databehandlingssoftware» – komponenter af DBO-serveren, som er ansvarlige for brugen af API'en på udvekslingsserveren, komponenter af udvekslingsserveren, som er ansvarlige for brugen af API'en på ABS.
Trusler for sikkerheden på højeste niveau
Dekomposition
1. Indsættelse af falske oplysninger af angribere via integrationsmodulet.
1. Indsættelse af falske oplysninger af angribere via integrationsmodulet.
Dekomposition
1.1. Uautoriseret ændring af legitime data under transmission over netværksforbindelser:
1.1.1. Link: .
1.2. Transmission af falske data på vegne af en legitim deltager i udvekslingen:
1.1.2. Link: .
1.3. Uautoriseret ændring af legitime data under behandling på udvekslingsservere eller mellemmænd:
1.3.1. Link: .
1.4. Oprettelse af falske data på udvekslingsservere eller mellemmænd på vegne af en legitim deltager i udvekslingen:
1.4.1. Link:
1.5. Uautoriseret ændring af data under behandling med databehandlingssoftware:
1.5.1. ved at angribere foretager uautoriserede ændringer i indstillingerne (konfiguration) af databehandlingssoftwaren.
1.5.2. ved at angribere foretager uautoriserede ændringer i de udførelsesfiler, der tilhører databehandlingssoftwaren.
1.5.3. ved interaktivt at styre databehandlingssoftwarens arbejde af angribere.
STANDARD TRUSSELSMODEL. KRYPTOGRAFISK BESKYTTELSE AF OPLYSNINGER
Beskyttelsesobjektet, som trusselsmodellen anvendes til (scope)
Beskyttelsesobjektet er et system til kryptografisk beskyttelse af oplysninger, der anvendes til at sikre informationssystemets sikkerhed.
Arkitektur
Grundlaget for ethvert informationssystem er den applikationssoftware (AS), der realiserer dets funktionelle mål.
Kryptografisk beskyttelse implementeres normalt ved at kalde kryptografiske primitiv fra forretningslogikken i applikationssoftwaren, som er placeret i specialiserede biblioteker - kryptokerneller.
Kryptografiske primitiv omfatter lavniveau kryptografiske funktioner, såsom:
- krypter / dekrypter en blok af data;
- oprette / verificere den elektroniske underskrift af en blok data;
- beregne hash-funktionen for en blok data;
- danne / uploade / downloade nøgleinformation;
- osv.
Forretningslogikken i applikationen implementerer mere avanceret funktionalitet ved hjælp af kryptografiske primitive funktioner:
- krypter en fil med nøglerne fra de valgte modtagere;
- etablere en sikker netværksforbindelse;
- informere om resultaterne af kontrol af den elektroniske underskrift;
- osv.
Interaktion mellem forretningslogik og kryptokernen kan finde sted:
- direkte, ved at forretningslogikken kalder kryptografiske primitive fra kryptokernens dynamiske biblioteker (.DLL – for Windows, .SO – for Linux);
- indirekte, gennem kryptografiske grænseflader – wrappers, såsom MS Crypto API, Java Cryptography Architecture, PKCS#11 osv. I dette tilfælde henvender forretningslogikken sig til kryptogrænsefladen, som oversætter kaldet til den relevante kryptokerne, der i sådanne tilfælde kaldes kryptoleverandøren. Anvendelsen af kryptografiske grænseflader gør det muligt for applikationen at abstrahere fra specifikke kryptografiske algoritmer og være mere fleksibel.
Man kan skelne mellem to typiske ordninger til organisering af kryptokernen:
Ordning 1 – Monolitisk kryptokernel
Ordning 2 – Adskilt kryptokernel
Elementer i de nævnte ordninger kan være både separate softwaremoduler, der arbejder på samme computer, samt netværkstjenester, der interagerer inden for et beregningsnetværk.
Ved anvendelse af systemer bygget efter ordning 1 arbejder applikationen og kryptokernen inden for et fælles driftsmiljø for kryptosystemet (SFK), for eksempel på den samme computer, under den samme operativsystem. Systembrugeren kan typisk køre andre programmer inden for dette driftsmiljø, herunder de, der indeholder skadelig kode. Under sådanne forhold er der en betydelig risiko for lækage af fortrolige kryptografiske nøgler.
For at minimere risikoen anvendes ordning 2, hvor kryptokernen opdeles i to dele:
- Den første del arbejder sammen med applikationen i et usikkert miljø, hvor der er risiko for infektion med skadelig kode. Vi kalder denne del 'softwaredelen'.
- Den anden del fungerer i et betroet miljø på en dedikeret enhed, som rummer et lager af hemmelige nøgler. Vi kalder denne del – "hardwaredelen".
Opdelingen af kryptokernen i software- og hardwaredele er temmelig betinget. På markedet findes der systemer, der er bygget efter en ordning med delt kryptokern, men hvor "hardware"-delen er repræsenteret som et billede af en virtuel maskine — virtual HSM ().
Interaktionen mellem begge dele af kryptokernen sker på en sådan måde, at de hemmelige kryptografiske nøgler aldrig overføres til softwaredelen og derfor ikke kan blive stjålet ved hjælp af skadelig kode.
Grænsefladen for interaktion (API) og sættet af kryptografiske primitive, der leveres til applikationssoftware af kryptokernen, er i begge tilfælde den samme. Forskellen ligger i måden, de implementeres på.
Så ved brug af en ordning med delt kryptokern, udføres interaktionen mellem software- og hardwaredelen efter følgende princip:
- Kryptografiske primitive, der ikke kræver brug af den hemmelige nøgle (f.eks. beregning af hash-funktion, verifikation af digital signatur mv.), udføres af softwaredelen.
- Kryptografiske primitive, der anvender den hemmelige nøgle (oprettelse af digital signatur, dekryptering af data mv.), udføres af hardwaredelen.
Lad os illustrere arbejdet med den delte kryptokern med et eksempel på oprettelse af en digital signatur:
- Softwaredelen beregner hash-funktionen af de data, der skal signeres, og sender denne værdi til hardwaredelen via kanalen for udveksling mellem kryptokernerne.
- Hardwaredelen danner en værdi for den digitale signatur ved hjælp af den hemmelige nøgle og hash og sender den over udvekslingskanalen tilbage til softwaredelen.
- Softwaredelen returnerer den modtagne værdi til applikationssoftwaren.
Særlige forhold ved verifikation af korrektheden af den digitale signatur
Når modtageren får data, der er signeret med en digital signatur, skal den gennemgå flere faser af kontrol. Et positivt resultat af verifikationen af den digitale signatur opnås kun, hvis alle kontrolfaser gennemføres med succes.
Fase 1. Kontrol af integritet og dataværdighed.
Indholdet af fasen. Der elektroniske signaturkontrol for data udføres ved hjælp af den relevante kryptografiske algoritme. En vellykket gennemgang af dette skridt indikerer, at data ikke er blevet modificeret siden deres signering, samt at signaturen blev lavet med den private nøgle, der svarer til den offentlige nøgle til kontrol af den elektroniske signatur.
Sted for udførelsen af skridtet: krypto-kerne.
Skridt 2. Kontrol af tillid til signatarens offentlige nøgle og kontrol af gyldighedsperioden for den elektroniske signaturs private nøgle.
Indholdet af fasen. Skridtet består af to mellemliggende deltrin. Det første sikrer, om den offentlige nøgle til kontrol af den elektroniske signatur var betroet på tidspunktet for dataanvendelse. Det andet sikrer, om den private nøgle til den elektroniske signatur var aktiv på tidspunktet for dataanvendelsen. Generelt set kan gyldighedsperioderne for disse nøgler være forskellige (for eksempel for kvalificerede certifikater for kontrol af den elektroniske signatur). Metoder til at fastslå tilliden til signatarens offentlige nøgle bestemmes af de regler for elektronisk dokumenthåndtering, der er vedtaget af de involverede parter.
Sted for udførelsen af skridtet: applikationssoftware / krypto-kerne.
Skridt 3. Kontrol af signatarens beføjelser.
Indholdet af fasen. I henhold til de fastsatte regler for elektronisk dokumenthåndtering undersøges det, om signatar havde ret til at bekræfte de beskyttede data. For eksempel kan vi tage en situation med beføjelsesovertrædelse. Antag, at der er en organisation, hvor alle medarbejdere har en elektronisk signatur. En ordre fra lederen kommer ind i det interne system for elektronisk dokumenthåndtering, men er underskrevet med den elektroniske signatur fra lagerchefen. Tilsvarende kan et sådant dokument ikke betragtes som legitimt.
Sted for udførelsen af skridtet: applikationssoftware.
Antagelser, der er gjort ved beskrivelsen af beskyttelsesobjektet
- Informationsoverførselskanaler, med undtagelse af kanalerne til nøgleudveksling, går også gennem applikationssoftware, API og krypto-kerne.
- Oplysninger om tillid til offentlige nøgler og (eller) certifikater samt information om beføjelserne for ejerne af de offentlige nøgler opbevares i et opbevaringssted for offentlige nøgler.
- Applikationssoftwaren arbejder med opbevaringsstedet for offentlige nøgler gennem krypto-kernen.
Eksempel på et informationssystem beskyttet af en SKZI
For illustration of the previously presented schemes, let's consider a hypothetical information system and highlight all its structural elements.
Description of the information system
Two organizations decided to implement a legally significant electronic document management (EDM) system between themselves. For this purpose, they signed an agreement stating that documents would be transmitted via email and must be encrypted and signed with a qualified electronic signature. Office programs from the Microsoft Office 2016 suite will be used as tools for creating and processing documents, while the cryptographic protection will be provided by CryptoPro and CryptoARM encryption software.
Description of the infrastructure of organization 1
Organization 1 decided to install CryptoPro and CryptoARM on the user's workplace — a physical computer. The encryption and electronic signature keys will be stored on the ruToken key carrier, operating in removable key mode. The user will prepare electronic documents locally on their computer, after which they will encrypt, sign, and send them using the locally installed mail client.
Description of the infrastructure of organization 2
Organization 2 decided to transfer the functions of encryption and electronic signature to a dedicated virtual machine. All cryptographic operations will be performed in automatic mode.
To do this, two network folders have been created on the dedicated virtual machine: '…In' and '…Out'. The '…In' folder will automatically receive files from the counterparty in an unencrypted form. These files will be decrypted, and the electronic signature will be verified.
In the '…Out' folder, the user will place files that need to be encrypted, signed, and sent to the counterparty. The user will prepare these files on their workplace.
To perform the functions of encryption and electronic signature, CryptoPro, CryptoARM, and a mail client are installed on the virtual machine. Automatic management of all elements of the virtual machine will be carried out using scripts developed by system administrators. The work of the scripts is logged in log files.
Kryptografiske nøgler til elektronisk underskrift vil blive placeret på en JaCarta GOST-token med en uextractable nøgle, som brugeren vil tilslutte til sin lokale computer.
Tokenet vil blive dirigeret til den virtuelle maskine ved hjælp af specialiserede USB-over-IP software, installeret på brugerens arbejdsstation og på den virtuelle maskine.
Systemuret på brugerens arbejdsstation i organisation 1 vil blive justeret manuelt. Systemuret på den specialiserede virtuelle maskine i organisation 2 vil blive synkroniseret med systemuret fra hypervisoren, som igen vil synkronisere sig over internettet med offentlige tidsservere.
Identifikation af strukturelle elementer i SKZI
Baseret på ovenstående beskrivelse af IT-infrastrukturen vil vi identificere strukturelle elementer i SKZI og notere dem i en tabel.
Tabel — Overensstemmelse mellem elementerne i SKZI-modellen og elementerne i informationssystemer
Navn på element
Organisation 1
Organisation 2
Anvendelsessoftware
KryptoARM-software
KryptoARM-software
Softwaredelen af kryptokernen
SKZI KryptoPRO CSP
SKZI KryptoPRO CSP
Hardwaredelen af kryptokernen
manglende
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Lager til offentlige nøgler
Brugerarbejdsstation:
— harddisk;
— standard Windows certifikatlagring.
Hypervisor:
— harddisk.
Virtuel maskine:
— harddisk;
— standard Windows certifikatlagring.
Lager til private nøgler
Nøglebærer ruToken, der fungerer i mode med udtrækbar nøgle
Nøglebærer JaCarta GOST, der fungerer i mode med uextractable nøgle
Kanal til udveksling af åbne nøgler
Brugerarbejdsstation:
— RAM.
Hypervisor:
— RAM.
Virtuel maskine:
— RAM.
Kanal til udveksling af private nøgler
Brugerarbejdsstation:
— USB-bus;
— RAM.
manglende
Kanal til udveksling mellem kryptokernene
mangler (ingen hardwaredel af kryptokernen)
Brugerarbejdsstation:
— USB-bus;
— RAM;
— softwaremodul USB-over-IP;
— netværksinterface.
Virksomhedsnetværk i organisation 2.
Hypervisor:
— RAM;
— netværksinterface.
Virtuel maskine:
— netværksinterface;
— RAM;
— softwaremodul USB-over-IP.
Kanal til udveksling af åbne data
Brugerarbejdsstation:
— input/output enheder;
— RAM;
— harddisk.
Brugerarbejdsstation:
— input/output enheder;
— RAM;
— harddisk;
— netværksinterface.
Virksomhedsnetværk i organisation 2.
Hypervisor:
— netværksinterface;
— RAM;
— harddisk.
Virtuel maskine:
— netværksinterface;
— RAM;
— harddisk.
Kanal til udveksling af beskyttede data
Internettet.
Virksomhedsnetværk i organisation 1.
Brugerarbejdsstation:
— harddisk;
— RAM;
— netværksinterface.
Internettet.
Virksomhedsnetværk i organisation 2.
Hypervisor:
— netværksinterface;
— RAM;
— harddisk.
Virtuel maskine:
— netværksinterface;
— RAM;
— harddisk.
Kanal til tidsoverførsel
Brugerarbejdsstation:
— input/output enheder;
— RAM;
— systemtimer.
Internettet.
Virksomhedsnetværk i organisation 2,
Hypervisor:
— netværksinterface;
— RAM;
— systemtimer.
Virtuel maskine:
— RAM;
— systemtimer.
Kanal til overførsel af styresignaler
Brugerarbejdsstation:
— input/output enheder;
— RAM.
(Grafisk brugergrænseflade til KryptoARM-software)
Virtuel maskine:
— RAM;
— harddisk.
(Automatiseringsscripts)
Kanal til modtagelse af arbejdsresultater
Brugerarbejdsstation:
— input/output enheder;
— RAM.
(Grafisk brugergrænseflade til KryptoARM-software)
Virtuel maskine:
— RAM;
— harddisk.
(Logfiler fra automatiseringsscript arbejde)
Trusler for sikkerheden på højeste niveau
Forklaringer
Antagelser vedrørende trussel dekonstruktion:
- Der anvendes robuste kryptografiske algoritmer.
- Kryptografiske algoritmer anvendes på en sikker måde i de korrekte driftsmåder (f.eks. anvendes ikke til kryptering af store datamængder, og der tages højde for den tilladte belastning på nøglen osv.).
- Angriberne kender alle de anvendte algoritmer, protokoller og offentlige nøgler.
- Angriberne har adgang til at læse alle krypterede data.
- Angriberne er i stand til at genskabe enhver softwarekomponent i systemet.
Dekomposition
U1. Kompromittering af hemmelige kryptografiske nøgler.
U2. Kryptering af falske data i navnet på en legitim afsender.
U3. Dekryptering af krypterede data af personer, der ikke er legitime modtagere af dataene (angriberne).
U4. Oprettelse af en elektronisk signatur fra en legitim underskriver på falske data.
U5. Opnåelse af et positivt resultat ved validering af den elektroniske signatur på falske data.
U6. Fejlagtig accept af elektroniske dokumenter til udførelse på grund af problemer i organiseringen af den elektroniske dokumentation.
U7. Uautoriseret adgang til beskyttede data under deres behandling af kryptografiske midler.
U1. Kompromittering af hemmelige kryptografiske nøgler
U1.1. Hentning af den hemmelige nøgle fra opbevaringsstedet for hemmelige nøgler.
U1.2. Hentning af den hemmelige nøgle fra objekter i det funktionelle miljø for kryptografiske midler, hvor den midlertidigt kan befinde sig.
Forklaringer U1.2.
Objekter, hvor den hemmelige nøgle midlertidigt kan opbevares, vil inkludere:
- RAM,
- midlertidige filer,
- swap-filer,
- hibernationsfiler,
- snapshot-filer af den 'varme' tilstand af virtuelle maskiner, inklusive filer med indholdet af RAM fra virtuelle maskiner, der er sat på pause.
U1.2.1. Uddragning af hemmelige nøgler fra aktiv RAM ved at fryse RAM-modulerne, udvinde dem og derefter læse data (freeze attack).
Forklaringer U1.2.1.
Eksempel .
U1.3. Hentning af den hemmelige nøgle fra kanalen til udveksling af hemmelige nøgler.
Forklaringer U1.3.
Et eksempel på implementeringen af denne trussel vil blive givet .
U1.4. Uautoriseret modificering af kryptokernen, hvilket gør det muligt for angribere at få kendskab til de hemmelige nøgler.
U1.5. Kompromittering af den lukkede nøgle som følge af brug af tekniske kanaler til lækage af information (TKUI).
Forklaringer U1.5.
Eksempel .
U1.6. Kompromittering af den lukkede nøgle som følge af brug af specialtechniske midler (STS), der er beregnet til hemmelig overvågning af information ("bugs").
U1.7. Kompromittering af lukkede nøgler i løbet af opbevaringen uden for SKZI.
Forklaringer U1.7.
For eksempel opbevarer brugeren sine nøglemedier i skrivebordsskuffen, hvor de let kan blive udtaget af ondsindede personer.
U2. Kryptering af falske data på vegne af en legitim afsender.
Forklaringer
Denne trussel overvejes kun for datakrypteringsordninger med autentificering af afsenderen. Eksempler på sådanne ordninger er angivet i standardiseringsretningslinjerne. . For andre kryptografiske ordninger findes denne trussel ikke, fordi kryptering udføres på modtagerens offentlige nøgler, og disse er generelt kendt af ondsindede.
Dekomposition
U2.1. Kompromittering af afsenderens lukkede nøgle:
U2.1.1. Link: .
U2.2. Ændring af inputdata i kanalen til udveksling af offentlige data.
Bemærkninger U2.2.
Eksempler på realisering af denne trussel er anført nedenfor. og .
U3. Dekryptering af krypterede data af personer, der ikke er legitime modtagere af dataene (ondsindede).
Dekomposition
U3.1. Kompromittering af modtagerens lukkede nøgler af krypterede data.
U3.1.1 Henvisning: .
U3.2. Ændring af krypterede data i kanalen til udveksling af beskyttede data.
U4. Oprettelse af en digital signatur af en legitim underskriver på falske data.
Dekomposition
U4.1. Kompromittering af de lukkede nøgler for den legitime underskriver.
U4.1.1 Henvisning: .
U4.2. Ændring af de underskrevne data i kanalen til udveksling af offentlige data.
Bemærkning U4.2.
Eksempler på realisering af denne trussel er anført nedenfor. og .
U5. Opnåelse af et positivt resultat ved verifikation af den digitale signatur på falske data.
Dekomposition
U5.1. Angribere opsnapper i kanalen til transmission af resultatet arbejdet med meddelelsen om det negative resultat af verificeringen af den elektroniske signatur og erstatter den med en meddelelse med et positivt resultat.
U5.2. Angribere udfører et angreb på tilliden til signaturcertifikater (SCENARIE — alle elementer er obligatoriske):
U5.2.1. Angribere genererer en offentlig og privat nøgle til den elektroniske signatur. Hvis der anvendes certifikater for nøgler til den elektroniske signatur i systemet, genererer de et certifikat til den elektroniske signatur, der ligner mest muligt certifikatet for den formodede afsender af dataene, hvis meddelelse de ønsker at forfalske.
U5.2.2. Angribere foretager uautoriserede ændringer i lageret for offentlige nøgler, hvilket tillader den genererede offentlige nøgle den nødvendige grad af tillid og beføjelser.
U5.2.3. Angribere signerer falske data med den tidligere dannede nøgle til den elektroniske signatur og injicerer dem i kanalen for udveksling af beskyttede data.
U5.3. Angribere udfører et angreb ved hjælp af udløbne nøgler til den elektroniske signatur fra en legitim signatar (SCENARIE — alle elementer er obligatoriske):
U5.3.1. Angribere kompromitterer udløbne (i øjeblikket ikke aktive) private nøgler til den elektroniske signatur fra en legitim afsender.
U5.3.2. Angribere erstatter tiden i transmissionskanalen med et tidspunkt, hvor de kompromitterede nøgler stadig var aktive.
U5.3.3. Angribere signerer falske data med den tidligere kompromitterede nøgle til den elektroniske signatur og injicerer dem i kanalen for udveksling af beskyttede data.
U5.4. Angribere udfører et angreb ved hjælp af kompromitterede nøgler til den elektroniske signatur fra en legitim signatar (SCENARIE — alle elementer er obligatoriske):
U5.4.1. Angribere laver en kopi af lageret for offentlige nøgler.
U5.4.2. Angribere kompromitterer de private nøgler fra en af de lovlige afsendere. Denne opdager kompromitteringen, tilbagekalder nøglerne, og oplysningerne om tilbagekaldelsen placeres i lageret for offentlige nøgler.
U5.4.3. Angribere erstatter lageret for offentlige nøgler med det tidligere kopierede.
U5.4.4. Angribere signerer falske data med den tidligere kompromitterede nøgle til den elektroniske signatur og injicerer dem i kanalen for udveksling af beskyttede data.
U5.5. på grund af fejl i implementeringen af den 2. og 3. etape af kontrollen af den elektroniske signatur:
Forklaringer U5.5.
Et eksempel på implementeringen af denne trussel er givet .
U5.5.1. Kontrol af tillid til certifikatet for den elektroniske signaturs nøgle kun baseret på tillid til certifikatet, som det er underskrevet med, uden kontroller af CRL eller OCSP.
Forklaringer U5.5.1.
Eksempel på implementering .
U5.5.2. Ved opbygning af tillidskæden for certifikatet analyseres ikke bemyndigelsen af de udstedende certifikater
Forklaringer U5.5.2.
Eksempel på angreb i forhold til SSL/TLS certifikater.
Angribere købte et legitimt certifikat til deres e-mail. Derefter lavede de et falsk certifikat til en hjemmeside og underskrev det med deres certifikat. Hvis bemyndigheden ikke bliver kontrolleret, vil tillidskæden blive anset for korrekt, og dermed vil det falske certifikat også være korrekt.
U5.5.3. Ved opbygning af tillidskæden for certifikatet kontrolleres de mellemliggende certifikater ikke for tilbagekaldelse.
U5.5.4. Opdatering af CRL sker sjældnere, end de udstedes af certifikatmyndigheden.
U5.5.5. Beslutningen om tillid til den elektroniske signatur træffes før OCSP-svaret om status på certifikatet er modtaget, som blev anmodet om efter tidspunktet for dannelsen af signaturen, eller før den næste CRL efter dannelsen af signaturen er modtaget.
Forklaringer U5.5.5.
I forskrifterne for de fleste CA'er betragtes tidspunktet for tilbagekaldelse af certifikatet som tidspunktet for frigivelsen af den nærmeste CRL, der indeholder oplysninger om tilbagekaldelse af certifikatet.
U5.5.6. Ved modtagelse af underskrevne data kontrolleres det ikke, om certifikatet tilhører afsenderen.
Forklaringer U5.5.6.
Eksempel på angreb. I forhold til SSL-certifikater: der kan være manglende kontrol af, om adressen på den kaldte server svarer til værdien af feltet CN i certifikatet.
Eksempel på angreb. Angribere kompromitterede de elektroniske signatur nøgler hos en deltager i betalingssystemet. Derefter brød de ind i netværket hos en anden deltager og sendte i hans navn til betalingssystemets regnskabsserver betalingsdokumenter underskrevet med de kompromitterede nøgler. Hvis serveren kun analyserer tillid og ikke kontrollerer overensstemmelse, vil de falske dokumenter blive betragtet som legitime.
U6. Fejlagtig accept af elektroniske dokumenter til udførelse på grund af problemer i organiseringen af den elektroniske dokumentation.
Dekomposition
U6.1. Den modtagende part opdager ikke, at de modtagne dokumenter er duplikerede.
Forklaringer U6.1.
Eksempel på angreb. Kriminelle kan opsnappe de dokumenter, der sendes til modtageren, selvom de er kryptografisk beskyttede, og derefter sende dem flere gange i kanalen for beskyttede data. Hvis modtageren ikke opdager dubletter, vil alle modtagne dokumenter blive opfattet og behandlet som forskellige dokumenter.
U7. Uautoriseret adgang til beskyttede data under deres behandling af Krypteret Informationssystem (SKZI)
Dekomposition
U7.1. som følge af informationslækager gennem alternative kanaler (side channel attack).
Forklaringer til U7.1.
Eksempel .
U7.2. som følge af neutralisering af beskyttelsen mod uautoriseret adgang til information, der behandles af SKZI:
U7.2.1. Udnyttelse af SKZI under overtrædelser af kravene beskrevet i SKZI's dokumentation.
U7.2.2. , der er udført på grund af tilstedeværelsen af sårbarheder i:
U7.2.2.1. midler til beskyttelse mod uautoriseret adgang.
U7.2.2.2. selve SKZI.
U7.2.2.3. miljøet for fungering af kryptografiske midler.
Eksempler på angreb
De scenarier, der er beskrevet nedenfor, indeholder bevidst fejl i organiseringen af informationssikkerhed og tjener kun som illustration af mulige angreb.
Scenarie 1. Eksempel på realiseringen af truslerne U2.2 og U4.2.
Beskrivelse af objektet
Software til ARM KBR og SKZI SKAD Signaturen er installeret på en fysisk computer, der ikke er tilsluttet det beregningsmæssige netværk. Den centrale lagringsenhed er en FKN vdToken, der arbejder med en uavtrækbar nøgle.
Reglerne for udførelse af beregninger forudsætter, at specialisten for beregninger downloader elektroniske beskeder i åben form (plan for den gamle ARM KBR) fra en særlig beskyttet filserver til sin arbejdscomputer, derefter gemmer dem på en transportabel USB-nøgle og overfører dem til ARM KBR, hvor de krypteres og signeres. Derefter overfører specialisten de beskyttede elektroniske beskeder til en transportabel lagringsenhed og sender dem derefter via sin arbejdscomputer til filserveren, hvor de kommer til UTA og videre til betalingssystemet i Den Russiske Centralbank.
I dette tilfælde vil kanalerne for udveksling af åbne og beskyttede data inkludere: filserveren, specialistens arbejdscomputer og den transportable lagringsenhed.
Angreb
Angribere installerer en uautoriseret fjernstyringssoftware på specialistens arbejdscomputer, og i det øjeblik hvor betalingsorms (elektroniske meddelelser) optages på det bortrejsende medie, ændres indholdet af én af dem i klar tekst. Specialisten overfører betalingsorms til ARМ KBR, underskriver og krypterer dem, uden at bemærke ændringen (for eksempel på grund af det store antal betalingsorms i rejsen, træthed osv.). Efter dette passerer det falske betalingsorm gennem den teknologiske kæde og ender i betalingssystemet i Den Russiske Bank.
Scenarie 2. Eksempel på implementering af trusler U2.2 og U4.2.
Beskrivelse af objektet
Computeren med installerede ARМ KBR, SKAD Signatur og tilsluttet nøglemedie FKN vdToken fungerer i et særskilt lokale uden adgang fra personalet.
Specialisten for beregningerne opretter forbindelse til ARМ KBR i fjernadgangstilstand via RDP-protokollen.
Angreb
Angribere opfanger legitimationsoplysninger, som specialisten for beregningerne bruger til at oprette forbindelse og arbejde med ARМ KBR (for eksempel gennem skadelig kode på hans computer). Derefter opretter de forbindelse i hans navn og sender et falskt betalingsorm til betalingssystemet i Den Russiske Bank.
Scenarie 3. Eksempel på implementering af truslen U1.3.
Beskrivelse af objektet
Lad os overveje én af de hypotetiske muligheder for implementering af integrationsmodulerne "ABS-KBR" til det nye skema (ARМ KBR-N), hvor den elektroniske underskrift af udgående dokumenter sker på siden af ABS. Vi antager, at ABS fungerer på en operativsystem, der ikke understøttes af den kryptografiske beskyttelse SKAD Signatur, og dermed er den kryptografiske funktionalitet flyttet til en separat virtuel maskine — integrationsmodulet "ABS-KBR."
Som nøglemedie bruges en almindelig USB-token, der fungerer i tilstand som en flytbar nøgle. Da nøglemediet blev tilsluttet hypervisoren, viste det sig, at der ikke var ledige USB-porte i systemet, så det blev besluttet at tilslutte USB-token gennem en netværks-USB-hub, og på den virtuelle maskine installere klienten USB-over-IP, som vil sikre forbindelsen til huben.
Angreb
Angribere har opfanget den private nøgle til den digitale signatur fra kommunikationskanalen mellem USB-hubben og hypervisoren (dataene blev overført i ukrypteret format). Med den private nøgle skabte angriberne en falsk betalingsanmodning, signeret med den digitale signatur, og sendte den til ARM KBR-N til udførelse.
Scenarie 4. Eksempel på implementering af trusler U5.5.
Beskrivelse af objektet
Lad os overveje den samme skema som i det tidligere scenarie. Vi antager, at e-mails, der kommer fra ARM KBR-N, havner i mappen …SHAREIn, mens de, der sendes til ARM KBR-N og videre til betalingssystemet i Den Russiske Føderation, går til …SHAREout.
Vi antager også, at ved implementeringen af integrationsmodulet opdateres listerne over tilbagekaldte certifikater kun ved genudstedelse af kryptografiske nøgler, og at e-mails, der modtages i mappen …SHAREIn, kun kontrolleres for integritetskontrol og tillid til den offentlige nøgle i den digitale signatur.
Angreb
Angribere, ved at bruge de nøgler, der blev stjålet i det foregående scenarie, signerede en falsk betalingsanmodning indeholdende oplysninger om indbetaling af penge til en bedrager-kundekonto og indførte den i kanalen for udveksling af sikre data. Da der ikke foretages nogen kontrol af, om betalingsanmodningen rent faktisk er underskrevet af Den Russiske Føderation, accepteres den til udførelse.
Kilde: habr.com
