Links til andre dele af undersøgelsen
- (Er du her)
Denne artikel fuldender cyklussen af publikationer, der er afsat til at sikre informationssikkerheden ved bankbetalinger, der ikke er kontanter. Her ser vi på de generiske trusselsmodeller, der refereres til i :
- .
- .
- .
- .
HABR-ADVARSEL!!! Kære Khabrovites, dette er ikke et underholdende indlæg.
Mere end 40 sider med materialer gemt under snittet kaldes på hjælp til arbejde eller studie personer, der har specialiseret sig i bank- eller informationssikkerhed. Disse materialer er det endelige produkt af undersøgelsen og er skrevet i en tør formel tone. Faktisk er disse tomme felter for interne dokumenter om informationssikkerhed.Nå, det traditionelle "Brugen af information fra artiklen til ulovlige formål er strafbar ved lov". Produktiv læsning!
Information til læsere, der læser undersøgelsen, der starter med denne publikation.
Hvad handler undersøgelsen om
Du læser en guide til en specialist med ansvar for at sikre informationssikkerheden ved betalinger i en bank.
Præsentationslogik
I begyndelsen i и beskrivelsen af beskyttelsesobjektet er givet. Så ind den fortæller, hvordan man bygger et beskyttelsessystem, og fortæller om behovet for at skabe en trusselsmodel. I Den fortæller om, hvad trusselsmodeller er, og hvordan de dannes. I и analyse af reelle angreb er givet. и indeholde en beskrivelse af trusselsmodellen bygget under hensyntagen til oplysningerne fra alle tidligere dele.
TYPISKE TRUSLER MODEL. NETVÆRKS FORBINDELSE
Det beskyttelsesobjekt, som trusselsmodellen anvendes på (omfang)
Formålet med beskyttelsen er data, der overføres via en netværksforbindelse, der opererer i datanetværk bygget på basis af TCP/IP-stakken.
arkitektur
Beskrivelse af arkitekturelementer:
- "slut noder" — knudepunkter, der udveksler beskyttet information.
- "Mellem noder" - elementer i datatransmissionsnetværket: routere, switches, adgangsservere, proxyservere og andet udstyr - gennem hvilket netværksforbindelsestrafik transmitteres. Generelt kan en netværksforbindelse fungere uden mellemliggende noder (direkte mellem slutnoder).
Sikkerhedstrusler på højeste niveau
Nedbrydning
U1. Uautoriseret adgang til overførte data.
U2. Uautoriseret ændring af overførte data.
U3. Krænkelse af forfatterskabet af de overførte data.
U1. Uautoriseret adgang til overførte data
Nedbrydning
U1.1. <...>, udført på afsluttende eller mellemliggende knudepunkter:
U1.1.1. <…> ved at læse dataene, mens de er i nodens lagerenheder:
U1.1.1.1. <…> i RAM.
Forklaringer til V1.1.1.1.
For eksempel under databehandling af nodens netværksstak.
U1.1.1.2. <…> i ikke-flygtig hukommelse.
Forklaringer til V1.1.1.2.
For eksempel ved lagring af overførte data i cachen, midlertidige filer eller personsøgningsfiler.
Y1.2. <…> udført på tredjeparts datanetværksknuder:
U1.2.1. <...> ved at fange alle pakker, der falder på netværksgrænsefladen for noden:
Forklaringer til V1.2.1.
Alle pakker fanges ved at skifte netværkskortet til promiskuøs tilstand (promiskuøs tilstand for kablede adaptere eller skærmtilstand for wi-fi adaptere).
U1.2.2. <…> ved at udføre man-in-the-middle (MiTM)-angreb, men uden at ændre de transmitterede data (netværksprotokollernes servicedata medregnes ikke).
Y1.2.2.1. Link: .
Y1.3. <...>, udført på grund af informationslækage gennem tekniske kanaler (TCUI) fra fysiske noder eller kommunikationslinjer.
U1.4. <...>, udført til installation af særlige tekniske midler (STS) på de sidste eller mellemliggende knudepunkter, beregnet til skjult fjernelse af information.
U2. Uautoriseret ændring af overførte data
Nedbrydning
U2.1. <...>, udført på afsluttende eller mellemliggende knudepunkter:
Y2.1.1. <...> ved at læse og ændre dataene, mens de er i nodernes lagerenheder:
Y2.1.1.1. <...> i RAM:
Y2.1.1.2. <…> i ikke-flygtig hukommelse:
Y2.2. <...> udført på tredjeparts datanetværksknuder:
U2.2.1. <…> ved at udføre Man-in-the-Middle (MiTM) angreb og omdirigere trafik til den ondsindede vært:
Y2.2.1.1. Den fysiske forbindelse af angriberens udstyr til at bryde netværksforbindelsen.
Y2.2.1.2. Implementering af angreb på netværksprotokoller:
Y2.2.1.2.1. <…> administration af virtuelt lokalnetværk (VLAN):
Y2.2.1.2.1.1. .
Y2.2.1.2.1.2. Uautoriseret ændring af VLAN-indstillinger på switche eller routere.
Y2.2.1.2.2. <…> trafikdirigering:
Y2.2.1.2.2.1. Uautoriseret ændring af de statiske routingtabeller for routere.
Y2.2.1.2.2.2. Annoncering af falske ruter af angribere gennem dynamiske routing-protokoller.
Y2.2.1.2.3. <…> automatisk konfiguration:
Y2.2.1.2.3.1. .
Y2.2.1.2.3.2. .
Y2.2.1.2.4. <…> adressering og navneopløsning:
Y2.2.1.2.4.1. .
Y2.2.1.2.4.2. .
Y2.2.1.2.4.3. Foretage uautoriserede ændringer af lokale værtsnavnefiler (værter, lmhosts osv.)
U3. Krænkelse af forfatterskabet af de overførte data
Nedbrydning
Y3.1. Neutralisering af mekanismer til at bestemme forfatterskabet af information ved at angive falsk information om forfatteren eller datakilden:
Y3.1.1. Ændring af oplysningerne om forfatteren i den overførte information.
Y3.1.1.1. Neutralisering af kryptografisk beskyttelse af integriteten og forfatterskabet af de transmitterede data:
Y3.1.1.1.1. Link: .
Y3.1.1.2. Neutralisering af beskyttelsen af det transmitterede dataforfatterskab, implementeret ved hjælp af engangsbekræftelseskoder:
Y3.1.1.2.1. .
Y3.1.2. Ændring af oplysninger om kilden til overførte oplysninger:
Y3.1.2.1. .
Y3.1.2.2. .
TYPISKE TRUSLER MODEL. INFORMATIONSSYSTEM BYGGET PÅ BASIS AF KLIENT-SERVER-ARKITEKTUR
Det beskyttelsesobjekt, som trusselsmodellen anvendes på (omfang)
Objektet for beskyttelse er et informationssystem bygget på basis af klient-server-arkitekturen.
arkitektur
Beskrivelse af arkitekturelementer:
- "Klient" - en enhed, som klientdelen af informationssystemet fungerer på.
- "Server" - en enhed, som serverdelen af informationssystemet fungerer på.
- "Datalager" - en del af informationssystemets serverinfrastruktur, designet til at lagre data, der behandles af informationssystemet.
- "Netværks forbindelse" — en informationsudvekslingskanal mellem klienten og serveren, der passerer gennem datatransmissionsnetværket. For en mere detaljeret beskrivelse af elementmodellen, se .
Begrænsninger
Når du modellerer et objekt, sættes følgende begrænsninger:
- Brugeren interagerer med informationssystemet inden for begrænsede tidsrum, kaldet arbejdssessioner.
- I begyndelsen af hver session bliver brugeren identificeret, autentificeret og autoriseret.
- Al beskyttet information gemmes på serverdelen af informationssystemet.
Sikkerhedstrusler på højeste niveau
Nedbrydning
U1. Angribere, der begår uautoriserede handlinger på vegne af en legitim bruger.
U2. Uautoriseret ændring af beskyttet information under behandlingen af serverdelen af informationssystemet.
U1. Angribere, der begår uautoriserede handlinger på vegne af en legitim bruger
Forklaringer
Normalt i informationssystemer udføres korrelationen af handlinger med den bruger, der udførte dem ved hjælp af:
- systemlogfiler (logfiler).
- særlige attributter for dataobjekter, der indeholder information om den bruger, der har oprettet eller ændret dem.
I forhold til en arbejdssession kan denne trussel dekomponeres i:
- <…> udført i brugersessionen.
- <…> udført uden for brugersessionen.
En brugersession kan startes:
- Af brugeren selv.
- Ubudne gæster.
På dette stadium vil den mellemliggende nedbrydning af denne trussel se sådan ud:
U1.1. Uautoriserede handlinger udført i brugersessionen:
U1.1.1. <…> indstillet af den angrebne bruger.
U1.1.2. <…> installeret af angribere.
Y1.2. Uautoriserede handlinger blev udført uden for brugerens session.
Fra synspunktet om informationsinfrastrukturobjekter, der kan blive påvirket af ubudne gæster, vil nedbrydningen af mellemliggende trusler se sådan ud:
elementer
Truslens nedbrydning
Y1.1.1.
Y1.1.2.
Y1.2.
Kunde
Y1.1.1.1.
Y1.1.2.1.
netværks forbindelse
Y1.1.1.2.
Server
Y1.2.1.
Nedbrydning
U1.1. Uautoriserede handlinger udført i brugersessionen:
U1.1.1. <…> indstillet af den angrebne bruger:
U1.1.1.1. Angribere handlede uafhængigt af klienten:
У1.1.1.1.1 Angriberne brugte standardværktøjer til adgang til informationssystem:
Y1.1.1.1.1.1. Angriberne brugte klientens fysiske input/output-midler (tastatur, mus, skærm eller berøringsskærm på en mobilenhed):
Y1.1.1.1.1.1.1. Angriberne handlede i perioder, hvor sessionen er aktiv, I/O-faciliteter er tilgængelige, og brugeren er væk.
Y1.1.1.1.1.2. Angriberne brugte fjernadministrationsværktøjer (standard eller leveret af ondsindet kode) til at administrere klienten:
Y1.1.1.1.1.2.1. Angriberne handlede i perioder, hvor sessionen er aktiv, I/O-faciliteter er tilgængelige, og brugeren er væk.
Y1.1.1.1.1.2.2. Angriberne brugte fjernadministrationsværktøjer, hvis funktion er usynlig for den angrebne bruger.
U1.1.1.2. Angriberne forfalskede dataene i netværksforbindelsen mellem klienten og serveren og ændrede dem på en sådan måde, at de blev opfattet som handlinger fra en legitim bruger:
Y1.1.1.2.1. Link: .
Y1.1.1.3. Angriberne tvang brugeren til at udføre de handlinger, de specificerede ved hjælp af social engineering-metoder.
U1.1.2 <…> indstillet af angribere:
Y1.1.2.1. Angriberne handlede fra klienten (И):
Y1.1.2.1.1. Angriberne neutraliserede informationssystemets adgangskontrolsystem:
Y1.1.2.1.1.1. Link: .
Y1.1.2.1.2. Forbrydere brugte regelmæssige midler til adgang til informationssystem
U1.1.2.2. Angriberne handlede fra andre noder i datatransmissionsnetværket, hvorfra det er muligt at etablere en netværksforbindelse med serveren (И):
Y1.1.2.2.1. Angriberne neutraliserede informationssystemets adgangskontrolsystem:
Y1.1.2.2.1.1. Link: .
Y1.1.2.2.2. Angriberne brugte ikke-standardiserede metoder til at få adgang til informationssystemet.
Forklaringer Y1.1.2.2.2.
Angriberne kunne installere en almindelig informationssystemklient på en tredjepartsknude eller kunne bruge ikke-standard software, der implementerer standardudvekslingsprotokoller mellem klienten og serveren.
P1.2 Uautoriserede handlinger udført uden for brugerens session.
S1.2.1 Angribere udførte uautoriserede handlinger og foretog derefter uautoriserede ændringer i logfilerne i informationssystemet eller særlige attributter for dataobjekter, hvilket indikerer, at de handlinger, de udførte, blev udført af en legitim bruger.
U2. Uautoriseret ændring af beskyttet information under behandlingen af serverdelen af informationssystemet
Nedbrydning
U2.1. Angribere ændrer beskyttet information ved hjælp af standardværktøjer til informationssystem og gør dette på vegne af en legitim bruger.
Y2.1.1. Link: .
Y2.2. Angribere ændrer beskyttet information ved at bruge dataadgangsmekanismer, som ikke er tilvejebragt af informationssystemets almindelige drift.
U2.2.1. Angribere ændrer filer, der indeholder beskyttet information:
Y2.2.1.1. <…> ved hjælp af filmanipulationsmekanismerne, som operativsystemet leverer.
Y2.2.1.2. <...> ved at fremprovokere gendannelse af filer fra en uautoriseret ændret sikkerhedskopi.
U2.2.2. Malefactors ændrer den beskyttede information, der er gemt i databasen (И):
Y2.2.2.1. Angribere neutraliserer DBMS-adgangskontrolsystemet:
Y2.2.2.1.1. Link: .
Y2.2.2.2. Angribere ændrer information ved hjælp af standard DBMS-grænseflader for at få adgang til data.
Y2.3. Malefactors ændrer den beskyttede information ved uautoriseret ændring af algoritmer for arbejdet i softwaren, der behandler dem.
Y2.3.1. Der foretages ændringer i softwarens kildekode.
Y2.3.1. Der foretages ændringer i softwarens maskinkode.
Y2.4. Angribere ændrer beskyttet information ved at udnytte sårbarheder i informationssystemsoftwaren.
Y2.5. Angribere ændrer den beskyttede information, når den overføres mellem komponenterne i serverdelen af informationssystemet (f.eks. databaseserveren og applikationsserveren):
Y2.5.1. Link: .
TYPISKE TRUSLER MODEL. ADGANGSKONTROLSYSTEM
Det beskyttelsesobjekt, som trusselsmodellen anvendes på (omfang)
Det beskyttelsesobjekt, som denne trusselsmodel anvendes på, svarer til trusselsmodellens beskyttelsesobjekt: ”Typisk trusselsmodel. Et informationssystem bygget på basis af en klient-server-arkitektur.
Brugeradgangskontrolsystemet i denne trusselsmodel forstås som en informationssystemkomponent, der implementerer følgende funktioner:
- Bruger identifikation.
- Brugergodkendelse.
- Brugerautorisationer.
- Logning af brugerhandlinger.
Sikkerhedstrusler på højeste niveau
Nedbrydning
U1. Uautoriseret etablering af en session på vegne af en legitim bruger.
U2. Uautoriseret forhøjelse af brugerrettigheder i informationssystemet.
U1. Uautoriseret sessionsetablering på vegne af en legitim bruger
Forklaringer
Nedbrydningen af denne trussel i det generelle tilfælde vil afhænge af typen af brugeridentifikation og autentificeringssystemer, der anvendes.
I denne model vil kun brugeridentifikations- og autentificeringssystemet ved hjælp af tekstlogin og adgangskode blive taget i betragtning. I dette tilfælde vil vi antage, at brugerens login er offentlig information kendt af angribere.
Nedbrydning
U1.1. <…> ved at kompromittere legitimationsoplysninger:
U1.1.1. Angriberne kompromitterede brugerens legitimationsoplysninger, mens de blev gemt.
Forklaringer Y1.1.1.
For eksempel kan legitimationsoplysninger skrives på en klæbe seddel, som er tapet til skærmen.
U1.1.2. Brugeren har ved et uheld eller ondsindet videregivet adgangsoplysninger til angribere.
Y1.1.2.1. Brugeren talte legitimationsoplysningerne højt, da de kom ind.
U1.1.2.2. Brugeren har med vilje givet deres legitimationsoplysninger:
Y1.1.2.2.1. <…> kollegaer på arbejde.
Forklaringer Y1.1.2.2.1.
For eksempel så de kan erstatte det med en sygdomsperiode.
Y1.1.2.2.2. <…> til arbejdsgiverens modparter, der udfører arbejde på informationsinfrastrukturens objekter.
Y1.1.2.2.3. <…> til tredjeparter.
Forklaringer Y1.1.2.2.3.
En, men ikke den eneste måde at implementere denne trussel på, er at bruge social engineering-metoder af angribere.
U1.1.3. Angriberne brute-forced legitimationsoplysningerne:
Y1.1.3.1. <…> ved hjælp af almindelige adgangsmekanismer.
U1.1.3.2. <...> af tidligere opsnappede koder (for eksempel kodeords-hash) til lagring af legitimationsoplysninger.
U1.1.4. Angriberne brugte ondsindet kode til at opsnappe brugerens legitimationsoplysninger.
U1.1.5. Angribere udtrak legitimationsoplysninger fra en netværksforbindelse mellem klienten og serveren:
Y1.1.5.1. Link: .
U1.1.6. Angribere udtrak legitimationsoplysninger fra registreringer af arbejdsovervågningssystemer:
U1.1.6.1. <…> videoovervågningssystemer (i tilfælde af at tastetryk på tastaturet blev optaget under drift).
U1.1.6.2. <…> systemer til overvågning af medarbejderes handlinger ved computeren
Forklaringer Y1.1.6.2.
Et eksempel på et sådant system er .
U1.1.7. Angriberne kompromitterede brugerens legitimationsoplysninger på grund af fejl i transmissionsprocessen.
Forklaringer Y1.1.7.
For eksempel transmission af adgangskoder i klartekst via e-mail.
U1.1.8. Angriberne lærte legitimationsoplysningerne ved at overvåge brugerens session ved hjælp af fjernadministrationssystemer.
U1.1.9. Angriberne udtrak legitimationsoplysningerne som et resultat af deres lækage gennem tekniske kanaler (TCUE):
U1.1.9.1. Angriberne spionerede på, hvordan brugeren indtaster legitimationsoplysninger fra tastaturet:
E1.1.9.1.1 Angriberne var placeret tæt på brugeren og så indtastningen af legitimationsoplysninger med deres egne øjne.
C1.1.9.1.1 Forklaringer
Sådanne tilfælde omfatter kollegers handlinger på arbejdet eller tilfældet, hvor brugerens tastatur er synligt for besøgende i organisationen.
E1.1.9.1.2 Angriberne brugte yderligere tekniske midler, såsom en kikkert eller et ubemandet luftfartøj, og så indtastningen af legitimationsoplysninger gennem et vindue.
U1.1.9.2. Angriberne udtrak legitimationsoplysninger fra registreringerne af radioudvekslingen mellem tastaturet og computerens systemenhed, hvis de var forbundet via radiogrænsefladen (f.eks. Bluetooth).
U1.1.9.3. Angriberne opsnappede legitimationsoplysningerne ved at lække dem gennem kanalen med falsk elektromagnetisk stråling og pickupper (PEMIN).
Forklaringer Y1.1.9.3.
Eksempler på angreb и .
U1.1.9.4. Angriberen opsnappede input af legitimationsoplysninger fra tastaturet ved brug af specielle tekniske midler (STS), designet til hemmeligt at fjerne information.
Forklaringer Y1.1.9.4.
Примеры .
U1.1.9.5. Angriberne opsnappede input af legitimationsoplysninger fra tastaturet ved hjælp af
analyse af Wi-Fi-signalet moduleret ved processen med at trykke på tasterne af brugeren.
Forklaringer Y1.1.9.5.
Eksempel .
U1.1.9.6. Angriberne opsnappede input af legitimationsoplysninger fra tastaturet ved at analysere lyden af tastetryk.
Forklaringer Y1.1.9.6.
Eksempel .
U1.1.9.7. Angriberne opsnappede input af legitimationsoplysninger fra tastaturet på en mobilenhed ved at analysere accelerometerets aflæsninger.
Forklaringer Y1.1.9.7.
Eksempel .
U1.1.10. <...> tidligere gemt på klienten.
Forklaringer Y1.1.10.
For eksempel kan en bruger gemme et brugernavn og en adgangskode i browseren for at få adgang til et bestemt websted.
U1.1.11. Angriberne kompromitterede legitimationsoplysninger på grund af fejl i processen for tilbagekaldelse af brugeradgang.
Forklaringer Y1.1.11.
For eksempel, efter afskedigelsen af en bruger, forblev hans konti ikke blokeret.
Y1.2. <…> ved at udnytte sårbarheder i adgangskontrolsystemet.
U2. Uautoriseret forhøjelse af brugerrettigheder i informationssystemet
Nedbrydning
P2.1 <...> ved at foretage uautoriserede ændringer af data, der indeholder information om brugerens privilegier.
U2.2 <…> ved at udnytte sårbarheder i adgangskontrolsystemet.
Y2.3. <…> på grund af fejl i brugeradgangskontrolprocessen.
Forklaringer Y2.3.
Eksempel 1. En bruger fik mere adgang til arbejde, end han havde brug for på grund af officielle behov.
Eksempel 2: Efter overførsel af en bruger til en anden position blev de tidligere tildelte adgangsrettigheder ikke tilbagekaldt.
TYPISKE TRUSLER MODEL. INTEGRATIONSMODUL
Det beskyttelsesobjekt, som trusselsmodellen anvendes på (omfang)
Integrationsmodul - et sæt informationsinfrastrukturobjekter designet til at organisere udvekslingen af information mellem informationssystemer.
I betragtning af, at det i virksomhedsnetværk ikke altid er muligt entydigt at adskille et informationssystem fra et andet, kan integrationsmodulet også betragtes som et bindeled mellem komponenter i et informationssystem.
arkitektur
Det generelle skema for integrationsmodulet ser således ud:
Beskrivelse af arkitekturelementer:
- "Exchange Server (CO)" – en node/tjeneste/komponent i et informationssystem, der udfører funktionen med at udveksle data med et andet informationssystem.
- "mellemmand" - en node/tjeneste designet til at organisere interaktion mellem informationssystemer, men ikke en del af dem.
Eksempler "mellemmænd" kan være e-mail-tjenester, enterprise service bus / SoA-arkitektur, tredjeparts filservere mv. I det generelle tilfælde må integrationsmodulet ikke indeholde "Formidlere". - "Databehandlingssoftware" - et sæt programmer, der implementerer dataudvekslingsprotokoller og formatkonvertering.
For eksempel konvertering af data fra UFEBS-formatet til ABS-formatet, ændring af meddelelsesstatusser under transmission, osv. - "Netværks forbindelse" svarer til objektet beskrevet i den typiske trusselmodel "Netværksforbindelse". Nogle netværksforbindelser fra dem, der er vist i diagrammet ovenfor, er muligvis ikke det.
Eksempler på integrationsmoduler
Skema 1. Integration af ABS og AWP KBR gennem en tredjeparts filserver
For at udføre betalinger uploader en autoriseret medarbejder i banken elektroniske betalingsdokumenter fra ABS og gemmer dem i en fil (i eget format, f.eks. SQL-dump) på filserverens netværksmappe (…SHARE). Derefter konverteres denne fil til et sæt filer i UFEBS-formatet ved hjælp af et konverterscript, som derefter læses af CBD AWP.
Derefter krypterer og underskriver en autoriseret medarbejder - en bruger af AWS CBD - den modtagne fil og sender dem til betalingssystemet i Bank of Russia.
Efter modtagelse af betalinger fra Bank of Russia dekrypterer CBR's AWP dem og kontrollerer den elektroniske signatur, hvorefter den skriver dem som et sæt filer i UFEBS-formatet til filserveren. Inden betalingsdokumenter importeres til ABS, konverteres de ved hjælp af en script-konverter fra UFEBS-formatet til ABS-formatet.
Vi vil antage, at i denne ordning fungerer ABS på én fysisk server, CBD-arbejdsstationen opererer på en dedikeret computer, og script-konverteren fungerer på en filserver.
Korrespondance mellem objekterne i den betragtede ordning og elementerne i modellen for integrationsmodulet:
"Udvekslingsservere fra ABS-siden" - ABS server.
"Udvekslingsservere fra siden af AWP KBR" - computer arbejdsstation KBR.
"mellemmand" - tredjeparts filserver.
"Databehandlingssoftware" - script konverter.
Skema 2. Integration af ABS og AWS KBR ved placering af en delt netværksmappe med betalinger på AWS KBR
Alt ligner skema 1, men der bruges ikke en separat filserver; i stedet er en netværksmappe (…DEL) med elektroniske betalingsdokumenter placeret på en computer med AWS CBD. Script-konverteren virker også på AWP CBD.
Korrespondance mellem objekterne i den betragtede ordning og elementerne i modellen for integrationsmodulet:
Svarende til skema 1, men "mellemmand" anvendes ikke.
Skema 3. Integration af ABS og AWS KBR-N gennem IBM WebSphera MQ og signering af elektroniske dokumenter "på ABS-siden"
ABS'en fungerer på en platform, der ikke understøttes af CIPF SKAD Signature. Udgående elektroniske dokumenter signeres på en særlig elektronisk signaturserver (ES Server). Den samme server verificerer den elektroniske signatur under dokumenter, der kommer fra Bank of Russia.
ABS'en uploader til ES-serveren en fil med betalingsdokumenter i sit eget format.
ES-serveren konverterer ved hjælp af et konverteringsscript filen til elektroniske meddelelser i UFEBS-formatet, hvorefter de elektroniske meddelelser signeres og transmitteres til IBM WebSphere MQ.
AWS KBR-N tilgår IBM WebSphere MQ og modtager signerede betalingsmeddelelser derfra, hvorefter en autoriseret medarbejder - en bruger af AWS KBR - krypterer dem og sender dem til betalingssystemet i Bank of Russia.
Efter modtagelse af betalinger fra Bank of Russia dekrypterer AWP KBR-N dem og verificerer den elektroniske signatur. Vellykket behandlede betalinger i form af dekrypterede og signerede elektroniske meddelelser i UFEBS-formatet overføres til IBM WebSphere MQ, hvorfra de modtages af ES-serveren.
ES-serveren verificerer den elektroniske signatur af modtagne betalinger og gemmer dem i en fil i ABS-format. Herefter uploader en autoriseret medarbejder - ABS-brugeren - den resulterende fil til ABS'en på den foreskrevne måde.
Korrespondance mellem objekterne i den betragtede ordning og elementerne i modellen for integrationsmodulet:
"Exchange-server fra ABS-siden" - ABS server.
"Udvekslingsserver fra siden af AWP KBR" - computer arbejdsstation KBR.
"mellemmand" – ES-server og IBM WebSphere MQ.
"Databehandlingssoftware" – script-konverter, CIPF SCAD-signatur på ES-serveren.
Skema 4. Integration af RBS-serveren og ABS via API'et leveret af en dedikeret udvekslingsserver
Vi antager, at banken bruger flere fjernbanksystemer (RBS):
- "Internet Client-Bank" for enkeltpersoner (ICB FL);
- "Internet Client-Bank" for juridiske enheder (ICB LE).
For at sikre informationssikkerheden udføres al interaktion mellem ABS og RB-systemer gennem en dedikeret udvekslingsserver, der opererer inden for rammerne af ABS informationssystemet.
Dernæst vil vi overveje processen med interaktion mellem RBS-systemet i ICB LE med ABS.
RBS-serveren skal, efter at have modtaget en behørigt certificeret betalingsordre fra klienten, oprette et passende dokument i ABS baseret på den. For at gøre dette, ved hjælp af API'en, overfører den information til udvekslingsserveren, som igen indtaster data i ABS.
Når saldierne på kundens konto ændres, genererer ABS'en elektroniske meddelelser, som sendes til RBS-serveren ved hjælp af exchange-serveren.
Korrespondance mellem objekterne i den betragtede ordning og elementerne i modellen for integrationsmodulet:
"Exchange server fra RBS" – RBS-server IKB YUL.
"Exchange-server fra ABS-siden" - udvekslingsserver.
"mellemmand" - fraværende.
"Databehandlingssoftware" – RB Server-komponenter, der er ansvarlige for brugen af Exchange Server API, Exchange Server-komponenter, der er ansvarlige for at bruge ABS API.
Sikkerhedstrusler på højeste niveau
Nedbrydning
U1. Introduktionen af falske oplysninger fra skadevoldere gennem integrationsmodulet.
U1. Angribernes introduktion af falsk information gennem integrationsmodulet
Nedbrydning
U1.1. Uautoriseret ændring af legitime data under transmissionen over netværksforbindelser:
U1.1.1 Link: .
Y1.2. Overførsel af falske data gennem kommunikationskanaler på vegne af en legitim udvekslingsdeltager:
U1.1.2 Link: .
Y1.3. Uautoriseret ændring af legitime data under deres behandling på Exchange-serverne eller mellemmanden:
Y1.3.1. Link: .
U1.4. Oprettelse på Exchange-servere eller mellemmand af falske data på vegne af en legitim udvekslingsdeltager:
Y1.4.1. Link:
Y1.5. Uautoriseret ændring af data under deres behandling ved hjælp af databehandlingssoftware:
U1.5.1. <…> på grund af indførelse af uautoriserede ændringer af ubudne gæster i indstillingerne (konfigurationen) af databehandlingssoftwaren.
U1.5.2. <…> på grund af, at ubudne gæster foretager uautoriserede ændringer i de eksekverbare filer i databehandlingssoftwaren.
U1.5.3. <...> på grund af angribernes interaktive kontrol af databehandlingssoftware.
TYPISKE TRUSLER MODEL. KRYPTOGRAFISK INFORMATIONSBESKYTTELSESSYSTEM
Det beskyttelsesobjekt, som trusselsmodellen anvendes på (omfang)
Objektet for beskyttelse er det kryptografiske informationsbeskyttelsessystem, der bruges til at sikre informationssystemets sikkerhed.
arkitektur
Grundlaget for ethvert informationssystem er applikationssoftware (software), der implementerer dets målfunktionalitet.
Kryptografisk beskyttelse i dette tilfælde implementeres normalt ved at kalde kryptografiske primitiver fra applikationssoftwarens forretningslogik, som er placeret i specialiserede biblioteker - kryptokerner.
Kryptografiske primitiver omfatter kryptografiske funktioner på lavt niveau såsom:
- kryptere/dekryptere datablok;
- oprette / verificere den elektroniske signatur af datablokken;
- beregne hash-funktionen af datablokken;
- generere / uploade / uploade nøgleoplysninger;
- etc.
Forretningslogikken i applikationssoftwaren, ved hjælp af kryptografiske primitiver, implementerer en funktionalitet på højere niveau:
- krypter filen med nøglerne til de valgte modtagere;
- etablere en sikker netværksforbindelse;
- informere om resultaterne af verifikationen af den elektroniske signatur;
- og så videre.
Samspillet mellem forretningslogik og kryptokerne kan udføres:
- direkte ved at kalde kryptografiske primitiver fra kryptokernens dynamiske biblioteker (.DLL - for Windows, .SO - for Linux) af forretningslogikken;
- direkte gennem kryptografiske grænseflader - wrappers, for eksempel MS Crypto API, Java Cryptography Architecture, PKCS # 11 osv. I dette tilfælde refererer forretningslogikken til kryptogrænsefladen, og den oversætter opkaldet til den tilsvarende kryptokerne, som i dette tilfælde kaldes kryptoudbyder. Brugen af kryptografiske grænseflader gør det muligt for applikationssoftware at abstrahere fra specifikke kryptografiske algoritmer og være mere fleksibel.
Der er to typiske ordninger til at organisere en kryptokerne:
Skema 1 - Monolitisk kryptokerne
Skema 2 - Split Crypto Core
Elementerne i ovenstående diagrammer kan enten være separate softwaremoduler, der kører på den samme computer, eller netværkstjenester, der interagerer inden for et computernetværk.
Når der bruges systemer bygget i henhold til skema 1, fungerer applikationssoftwaren og kryptokernen i et enkelt miljø til drift af et kryptomiddel (CFC), for eksempel på den samme computer, der kører det samme operativsystem. Brugeren af systemet kan som regel køre andre programmer inden for det samme driftsmiljø, inklusive dem, der indeholder skadelig kode. Under sådanne forhold er der en alvorlig risiko for lækage af private kryptografiske nøgler.
For at minimere risikoen anvendes skema 2, hvor kryptokernen er opdelt i to dele:
- Den første del, sammen med applikationssoftwaren, kører i et upålideligt miljø, hvor der er risiko for malware-infektion. Vi vil kalde denne del "softwaredel".
- Den anden del fungerer i et pålideligt miljø på en dedikeret enhed, som indeholder et privat nøglelager. Yderligere vil vi kalde denne del - "hardwaredel".
Opdelingen af kryptokernen i software- og hardwaredele er meget betinget. Der er systemer på markedet bygget efter skemaet med en delt kryptokerne, men hvoraf "hardware"-delen præsenteres i form af et virtuelt maskinbillede - virtuel HSM ().
Interaktionen mellem begge dele af kryptokernen sker på en sådan måde, at private kryptografiske nøgler aldrig overføres til softwaredelen og derfor ikke kan stjæles ved hjælp af ondsindet kode.
Interaktionsgrænsefladen (API) og sættet af kryptografiske primitiver, der leveres til applikationssoftwaren af kryptokernen, er de samme i begge tilfælde. Forskellen ligger i den måde, de implementeres på.
Så når du bruger et skema med en opdelt kryptokerne, udføres interaktionen mellem software og hardware efter følgende princip:
- Kryptografiske primitiver, der ikke kræver brug af en privat nøgle (f.eks. beregning af en hashfunktion, verifikation af en elektronisk signatur osv.) udføres af softwaren.
- Kryptografiske primitiver, der bruger en privat nøgle (oprettelse af en elektronisk signatur, dekryptering af data osv.) udføres af hardwaren.
Lad os illustrere driften af en delt kryptokerne ved at bruge eksemplet med at oprette en elektronisk signatur:
- Softwaredelen beregner hashfunktionen af de signerede data og overfører denne værdi til hardwaren via udvekslingskanalen mellem kryptokernerne.
- Hardwaredelen, ved hjælp af den private nøgle og hash, genererer værdien af den elektroniske signatur og overfører den til softwaredelen via udvekslingskanalen.
- Softwaredelen returnerer den modtagne værdi til applikationssoftwaren.
Funktioner til at kontrollere rigtigheden af en elektronisk signatur
Når den modtagende part modtager data underskrevet med en elektronisk signatur, skal den udføre flere stadier af verifikation. Et positivt resultat af verifikation af en elektronisk signatur opnås kun, hvis alle stadier af verifikation er gennemført.
Trin 1. Kontrol af dataintegritet og dataforfatterskab.
Sceneindhold. Den elektroniske signatur af dataene verificeres i henhold til den tilsvarende kryptografiske algoritme. En vellykket gennemførelse af dette trin indikerer, at dataene ikke er blevet ændret, siden de blev underskrevet, og at signaturen blev lavet med en privat nøgle svarende til den offentlige nøgle til verifikation af den elektroniske signatur.
Stedet for scenen: kryptokernel.
Trin 2. Kontrol af tillid til underskriverens offentlige nøgle og kontrol af gyldighedsperioden for den private nøgle til den elektroniske signatur.
Sceneindhold. Scenen består af to mellemliggende delfaser. Den første fastslår, om den offentlige nøgle til verifikation af den elektroniske signatur var tillid til på tidspunktet for underskrivelsen af dataene. Den anden fastslår, om den private nøgle til den elektroniske signatur var gyldig på tidspunktet for underskrivelsen af dataene. I det generelle tilfælde falder gyldighedsperioderne for disse nøgler muligvis ikke sammen (f.eks. for kvalificerede certifikater for verifikationsnøgler til elektronisk signatur). Metoder til at etablere tillid til underskriverens offentlige nøgle bestemmes af reglerne for elektronisk dokumenthåndtering vedtaget af de interagerende parter.
Stedet for scenen: applikationssoftware / kryptokerne.
Trin 3. Kontrol af underskriverens autoritet.
Sceneindhold. I overensstemmelse med de fastsatte regler for elektronisk dokumenthåndtering kontrolleres det, om underskriveren havde ret til at attestere de beskyttede data. Overvej for eksempel en situation med myndighedskrænkelse. Antag, at der er en organisation, hvor alle medarbejdere har en elektronisk signatur. Det interne elektroniske dokumenthåndteringssystem modtager en ordre fra lederen, men underskrevet af lagerchefens elektroniske signatur. Et sådant dokument kan derfor ikke anses for legitimt.
Stedet for scenen: applikations software.
Antagelser ved beskrivelse af beskyttelsesobjektet
- Informationsoverførselskanaler, med undtagelse af nøgleudvekslingskanaler, passerer også gennem applikationssoftware, API og kryptokerne.
- Oplysninger om tillid til offentlige nøgler og (eller) certifikater samt oplysninger om offentlige nøgleejeres autoritet placeres i det offentlige nøglelager.
- Applikationssoftwaren fungerer med den offentlige nøgleopbevaring gennem kryptokernen.
Et eksempel på et informationssystem beskyttet med CIPF
For at illustrere de tidligere præsenterede ordninger skal du overveje et hypotetisk informationssystem og vælge alle de strukturelle elementer på det.
Beskrivelse af informationssystemet
De to organisationer besluttede at indføre juridisk bindende elektronisk dokumenthåndtering (EDF) mellem dem. For at gøre dette indgik de en aftale, hvor de oplyste, at dokumenterne ville blive transmitteret på e-mail, og samtidig skal de være krypteret og underskrevet med en kvalificeret elektronisk signatur. Som et middel til at oprette og behandle dokumenter, bør kontorprogrammer fra Microsoft Office 2016-pakken bruges, og som middel til kryptografisk beskyttelse - CIPF CryptoPRO og krypteringssoftware CryptoARM.
Beskrivelse af organisationens infrastruktur 1
Organisation 1 besluttede, at den ville installere CryptoPRO CIPF og CryptoARM software på brugerens arbejdsstation - en fysisk computer. Kryptering og elektroniske signaturnøgler vil blive gemt på ruToken-nøgleholderen, der fungerer i genfindbar nøgletilstand. Brugeren vil udarbejde elektroniske dokumenter lokalt på sin computer, hvorefter de krypteres, signeres og sendes ved hjælp af en lokalt installeret mailklient.
Beskrivelse af organisationens infrastruktur 2
Organisation 2 besluttede at flytte funktionerne kryptering og elektronisk signatur til en dedikeret virtuel maskine. I dette tilfælde vil alle kryptografiske operationer blive udført automatisk.
For at gøre dette er to netværksmapper organiseret på en dedikeret virtuel maskine: "...In", "...Out". Filer modtaget fra modparten i åben form vil automatisk blive placeret i netværksmappen "...In". Disse filer vil blive dekrypteret, og den elektroniske signatur vil blive verificeret på dem.
I mappen "...Out" vil brugeren placere filer, der skal krypteres, signeres og sendes til modparten. Brugeren forbereder selv filerne på sin arbejdsstation.
For at udføre kryptering og elektroniske signaturfunktioner er CryptoPRO CIPF, CryptoARM-software og en mail-klient installeret på den virtuelle maskine. Automatisk styring af alle elementer i den virtuelle maskine vil blive udført ved hjælp af scripts udviklet af systemadministratorer. Arbejdet med scripts logges i logfiler (logs).
De kryptografiske nøgler til den elektroniske signatur vil blive placeret på et token med en JaCarta GOST ikke-hentbar nøgle, som brugeren vil forbinde til sin lokale computer.
Tokenet vil blive videresendt til den virtuelle maskine ved hjælp af specialiseret 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 dedikerede virtuelle maskine i organisation 2 vil blive synkroniseret med hypervisorens systemur, som igen vil blive synkroniseret over internettet med offentlige tidsservere.
Tildeling af strukturelle elementer af CIPF
På baggrund af ovenstående beskrivelse af IT-infrastrukturen udskiller vi de strukturelle elementer i CIPF og skriver dem ned i en tabel.
Tabel - Korrespondance af elementerne i CIPF-modellen med elementerne i informationssystemer
Varenavn
Organisation 1
Organisation 2
Applikations software
CryptoARM software
CryptoARM software
Softwaredelen af kryptokernelen
CIPF CryptoPRO CSP
CIPF CryptoPRO CSP
Hardwaredelen af kryptokernelen
Ingen
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Opbevaring af offentlig nøgle
Brugerarbejdsstation:
- HDD;
- standard Windows-certifikatlager.
Hypervisor:
- HDD.
Virtuel maskine:
- HDD;
- standard Windows-certifikatlager.
Privat nøgleopbevaring
Nøgleholder ruToken, der fungerer i tilstanden som en udtrækbar nøgle
JaCarta GOST nøgleholder, der fungerer i ikke-hentbar nøgletilstand
Offentlig nøgleudvekslingskanal
Brugerarbejdsstation:
- VÆDDER.
Hypervisor:
- VÆDDER.
Virtuel maskine:
- VÆDDER.
Privat nøgleudvekslingskanal
Brugerarbejdsstation:
- USB-bus;
- VÆDDER.
Ingen
Udvekslingskanal mellem kryptokerner
fraværende (ingen cryptocore hardware)
Brugerarbejdsstation:
- USB-bus;
- VÆDDER;
- USB-over-IP softwaremodul;
- netværksgrænseflade.
Organisationens virksomhedsnetværk 2.
Hypervisor:
- VÆDDER;
- netværksgrænseflade.
Virtuel maskine:
— netværksgrænseflade;
- VÆDDER;
- USB-over-IP softwaremodul.
Åbn dataudvekslingskanal
Brugerarbejdsstation:
- midler til input-output;
- VÆDDER;
- HDD.
Brugerarbejdsstation:
- midler til input-output;
- VÆDDER;
- HDD;
- netværksgrænseflade.
Organisationens virksomhedsnetværk 2.
Hypervisor:
— netværksgrænseflade;
- VÆDDER;
- HDD.
Virtuel maskine:
— netværksgrænseflade;
- VÆDDER;
- HDD.
Sikker dataudvekslingskanal
Internet.
Organisationens virksomhedsnetværk 1.
Brugerarbejdsstation:
- HDD;
- VÆDDER;
- netværksgrænseflade.
Internet.
Organisationens virksomhedsnetværk 2.
Hypervisor:
— netværksgrænseflade;
- VÆDDER;
- HDD.
Virtuel maskine:
— netværksgrænseflade;
- VÆDDER;
- HDD.
Tidskanal
Brugerarbejdsstation:
- midler til input-output;
- VÆDDER;
- system timer.
Internet.
Organisationens virksomhedsnetværk 2,
Hypervisor:
— netværksgrænseflade;
- VÆDDER;
- system timer.
Virtuel maskine:
- VÆDDER;
- system timer.
Styrekommando transmissionskanal
Brugerarbejdsstation:
- midler til input-output;
- VÆDDER.
(GUI af CryptoARM-software)
Virtuel maskine:
- VÆDDER;
- HDD.
(Automatisk scripts)
Kanal til modtagelse af arbejdsresultater
Brugerarbejdsstation:
- midler til input-output;
- VÆDDER.
(GUI af CryptoARM-software)
Virtuel maskine:
- VÆDDER;
- HDD.
(Logfiler til automatiseringsscripts)
Sikkerhedstrusler på højeste niveau
Forklaringer
Antagelser lavet i nedbrydningen af trusler:
- Der anvendes stærke kryptografiske algoritmer.
- Kryptografiske algoritmer bruges sikkert i de korrekte driftsformer (f.eks. gælder ikke for kryptering af store mængder data, der tages højde for den tilladte belastning på nøglen osv.).
- Malefactors kender alle brugte algoritmer, protokoller og offentlige nøgler.
- Angribere har adgang til alle krypterede data.
- Angribere er i stand til at gengive alle programelementer i systemet.
Nedbrydning
U1. Kompromittering af private kryptografiske nøgler.
U2. Kryptering af falske data på vegne af en legitim afsender.
U3. Dekryptering af krypterede data af personer, der ikke er legitime modtagere af data (ubudte gæster).
U4. Oprettelse af en elektronisk signatur for en legitim underskriver under falske data.
U5. At opnå et positivt resultat af kontrol af den elektroniske signatur af falske data.
U6. Fejlagtig accept af elektroniske dokumenter til udførelse på grund af problemer i organiseringen af elektronisk dokumenthåndtering.
U7. Uautoriseret adgang til beskyttede data under deres behandling af CIPF.
U1. Kompromittering af private kryptografiske nøgler
U1.1. Få den private nøgle fra den private nøglebutik.
Y1.2. Opnåelse af en privat nøgle fra objekterne i miljøet for funktion af det kryptografiske værktøj, hvori det kan være midlertidigt placeret.
Forklaringer Y1.2.
Objekter, der midlertidigt kan gemme en privat nøgle, vil omfatte:
- VÆDDER,
- midlertidige filer,
- personsøgningsfiler,
- dvale filer,
- snapshot-filer af virtuelle maskiners "varme" tilstand, herunder filer med indholdet af RAM'en på virtuelle maskiner, der er blevet sat på pause.
U1.2.1. Hentning af private nøgler fra fungerende RAM ved at fryse RAM-moduler, udpakke dem og derefter læse dataene (fryseangreb).
Forklaringer Y1.2.1.
Eksempel .
Y1.3. Indhentning af en privat nøgle fra en privat nøgleudvekslingskanal.
Forklaringer Y1.3.
Et eksempel på implementeringen af denne trussel vil blive givet .
U1.4. Uautoriseret ændring af kryptokernen, som et resultat af, at private nøgler bliver kendt for angribere.
Y1.5. Kompromittering af den private nøgle som følge af brugen af tekniske kanaler for informationslækage (TCLE).
Forklaringer Y1.5.
Eksempel .
U1.6. Kompromittering af den private nøgle som følge af brugen af specielle tekniske midler (STS) designet til hemmelig genfinding af information ("bugs").
Y1.7. Kompromittering af private nøgler under deres opbevaring uden for CIPF.
Forklaringer Y1.7.
For eksempel opbevarer en bruger deres nøglemedier i en skrivebordsskuffe, hvorfra de nemt kan hentes af ubudne gæster.
U2. Kryptering af falske data på vegne af en legitim afsender
Forklaringer
Denne trussel tages kun i betragtning for datakrypteringsordninger med afsendergodkendelse. Eksempler på sådanne ordninger er angivet i anbefalingerne for standardisering. . For andre kryptografiske skemaer eksisterer denne trussel ikke, da kryptering udføres på modtagerens offentlige nøgler, og de er generelt kendt af angribere.
Nedbrydning
U2.1. Kompromittering af afsenderens private nøgle:
Y2.1.1. Link: .
Y2.2. Substitution af inputdata i den åbne dataudvekslingskanal.
Bemærkninger U2.2.
Eksempler på implementeringen af denne trussel er givet nedenfor. и .
U3. Dekryptering af krypterede data af personer, der ikke er legitime modtagere af data (ubudte gæster)
Nedbrydning
Y3.1. Kompromittering af private nøgler for modtageren af krypterede data.
U3.1.1 Link: .
Y3.2. Substitution af krypterede data i en sikker dataudvekslingskanal.
U4. Oprettelse af en elektronisk signatur for en legitim underskriver under falske data
Nedbrydning
Y4.1. Kompromittering af private nøgler til den elektroniske signatur fra en legitim underskriver.
U4.1.1 Link: .
Y4.2. Substitution af signerede data i den åbne dataudvekslingskanal.
Bemærk U4.2.
Eksempler på implementeringen af denne trussel er givet nedenfor. и .
U5. At opnå et positivt resultat af kontrol af den elektroniske signatur af falske data
Nedbrydning
Y5.1. Forbrydere opsnapper i kanalen for transmission af arbejdsresultater beskeden på negativt resultat af kontrol af den elektroniske signatur og erstatter den med beskeden med positivt resultat.
Y5.2. Angribere udfører et angreb på tilliden til at underskrive certifikater (SCENARIO - alle elementer er påkrævet):
U5.2.1. Angribere genererer en offentlig og privat nøgle til en elektronisk signatur. Hvis systemet bruger elektroniske signaturnøglecertifikater, genererer de et elektronisk signaturcertifikat, der ligner så meget som muligt certifikatet for den påståede afsender af de data, hvis besked de ønsker at forfalske.
U5.2.2. Angribere foretager uautoriserede ændringer i det offentlige nøglelager, hvilket giver den offentlige nøgle, der er genereret af dem, det nødvendige niveau af tillid og autoritet.
Y5.2.3. Angribere signerer falske data med en tidligere genereret elektronisk signaturnøgle og indlejrer dem i en sikker dataudvekslingskanal.
Y5.3. Angribere udfører et angreb ved hjælp af udløbne elektroniske signaturnøgler fra en lovlig underskriver (SCENARIO - alle elementer er påkrævet):
Y5.3.1. Angribere kompromitterer de udløbne (ikke gyldige) private nøgler til den legitime afsenderes elektroniske signatur.
Y5.3.2. Angribere erstatter tidspunktet i tidstransmissionskanalen med det tidspunkt, hvor de kompromitterede nøgler stadig var gyldige.
Y5.3.3. Angribere signerer falske data med en tidligere kompromitteret elektronisk signaturnøgle og indlejrer den i en sikker dataudvekslingskanal.
Y5.4. Angribere udfører et angreb ved at bruge kompromitterede elektroniske signaturnøgler fra en lovlig underskriver (SCENARIO - alle elementer er påkrævet):
Y5.4.1. Angriberne laver en kopi af det offentlige nøglelager.
Y5.4.2. Angribere kompromitterer en af de legitime afsenderes private nøgler. Han bemærker kompromiset, tilbagekalder nøglerne, information om tilbagekaldelse af nøglen er placeret i det offentlige nøglelager.
Y5.4.3. Angriberne erstatter det offentlige nøglelager med det tidligere kopierede.
Y5.4.4. Angribere signerer falske data med en tidligere kompromitteret elektronisk signaturnøgle og indlejrer den i en sikker dataudvekslingskanal.
Y5.5. <...> på grund af tilstedeværelsen af fejl i implementeringen af 2. og 3. trin af elektronisk signaturverifikation:
Forklaringer Y5.5.
Et eksempel på implementeringen af denne trussel er givet .
U5.5.1. Bekræftelse af tillid til certifikatet for den elektroniske signaturnøgle kun ved tilstedeværelsen af tillid til det certifikat, som det er signeret med, uden CRL- eller OCSP-tjek.
Forklaringer Y5.5.1.
Implementeringseksempel .
Y5.5.2. Når du opbygger en tillidskæde for et certifikat, analyseres autoriteten til at udstede certifikater ikke
Forklaringer Y5.5.2.
Et eksempel på et angreb mod SSL/TLS-certifikater.
Angriberne købte et legitimt certifikat til deres e-mail. De lavede derefter et svigagtigt webstedscertifikat og underskrev det med deres eget certifikat. Hvis legitimationskontrollen ikke udføres, vil den, når du kontrollerer tillidskæden, vise sig at være korrekt, og følgelig vil det svigagtige certifikat også være korrekt.
Y5.5.3. Når du opbygger en certifikattillidskæde, kontrolleres mellemliggende certifikater ikke for tilbagekaldelse.
Y5.5.4. CRL'er opdateres sjældnere, end certifikatmyndigheden udsteder dem.
U5.5.5. Beslutningen om at stole på den elektroniske signatur træffes før OCSP-svaret om certifikatets status er modtaget, sendt på en anmodning, der er foretaget senere end signaturgenereringstidspunktet eller tidligere end den næste efter CRL-signeringen er modtaget.
Forklaringer Y5.5.5.
I reglerne for de fleste CA'er anses certifikattilbagekaldelsestiden for at være tidspunktet for udstedelse af den nærmeste CRL, der indeholder oplysninger om tilbagekaldelse af certifikatet.
U5.5.6. Ved modtagelse af underskrevne data bekræftes afsenderens ejerskab af certifikatet ikke.
Forklaringer Y5.5.6.
Eksempel på angreb. For SSL-certifikater kontrollerer den muligvis ikke, om adressen på den kaldte server matcher værdien af CN-feltet i certifikatet.
Eksempel på angreb. Angriberne kompromitterede de elektroniske signaturnøgler fra en af deltagerne i betalingssystemet. Derefter hackede de en anden deltagers netværk og sendte på hans vegne betalingsdokumenter underskrevet med kompromitterede nøgler til betalingssystemets afregningsserver. Hvis serveren kun analyserer tillid og ikke tjekker for overholdelse, vil svigagtige dokumenter blive betragtet som legitime.
U6. Fejlagtig accept af elektroniske dokumenter til udførelse på grund af problemer i organiseringen af elektronisk dokumenthåndtering.
Nedbrydning
U6.1. Den modtagende part opdager ikke duplikering af modtagne dokumenter.
Forklaringer Y6.1.
Eksempel på angreb. Forbrydere kan opsnappe det dokument, der er overført til modtageren, selvom det er kryptografisk beskyttet, og derefter gentagne gange sende det til den sikre datatransmissionskanal. Hvis modtageren ikke opdager dubletter, så vil alle modtagne dokumenter blive opfattet og behandlet som forskellige dokumenter.
U7. Uautoriseret adgang til beskyttede data under deres behandling af CIPF
Nedbrydning
U7.1. <…> på grund af informationslækage gennem tredjepartskanaler (sidekanalangreb).
Forklaringer Y7.1.
Eksempel .
U7.2. <...> på grund af neutraliseringen af beskyttelsen mod uautoriseret adgang til oplysninger behandlet på CIPF:
Y7.2.1. Drift af CIPF med overtrædelser af kravene beskrevet i dokumentationen til CIPF.
Y7.2.2. <…> implementeret på grund af tilstedeværelsen af sårbarheder i:
Y7.2.2.1. <…> midler til beskyttelse mod uautoriseret adgang.
Y7.2.2.2. <…> selve CIPF.
Y7.2.2.3. <...> miljøet for det kryptografiske værktøjs funktion.
Eksempler på angreb
De scenarier, der diskuteres nedenfor, indeholder naturligvis fejl i organisationen af informationssikkerhed og tjener kun til at illustrere mulige angreb.
Scenarie 1. Et eksempel på implementering af trusler U2.2 og U4.2.
Beskrivelse af objektet
ARM KBR-software og CIPF SCAD Signature er installeret på en fysisk computer, der ikke er forbundet til et computernetværk. FKN vdToken bruges som nøglebærer i driftstilstanden med en ikke-hentelig nøgle.
Forligsforordningen forudsætter, at afregningsspecialisten fra sin arbejdscomputer downloader elektroniske meddelelser i klartekst (skemaet fra den gamle KBR AWS) fra en særlig sikker filserver, derefter skriver dem til et flytbart USB-flashdrev og overfører dem til KBR AWP'en. , hvor de er krypteret og skilter. Derefter overfører specialisten sikre elektroniske meddelelser til et overførbart medie og skriver dem derefter gennem sin arbejdscomputer til en filserver, hvorfra de kommer til UTA og derefter til betalingssystemet i Bank of Russia.
I dette tilfælde vil kanalerne til udveksling af åbne og sikre data omfatte: en filserver, en specialists arbejdscomputer og et overførbart medie.
Angreb
Uautoriserede angribere installerer et fjernstyringssystem på specialistens arbejdscomputer og erstatter åbenlyst indholdet af en af dem på tidspunktet for registrering af betalingsordrer (elektroniske meddelelser) på det overførbare medium. Specialisten overfører betalingsordrerne til KBR's AWS, underskriver og krypterer dem uden at bemærke substitutionen (for eksempel på grund af det store antal betalingsordrer på flyvningen, træthed osv.). Derefter kommer den falske betalingsordre, der er gået gennem den teknologiske kæde, ind i betalingssystemet i Bank of Russia.
Scenarie 2. Et eksempel på implementering af trusler U2.2 og U4.2.
Beskrivelse af objektet
Computeren med den installerede AWS KBR, SKAD Signature og den tilsluttede nøgleholder til FKN vdToken fungerer i et dedikeret rum uden adgang fra personalet.
Afregningsspecialisten forbinder til AWS af KBR i fjernadgangstilstand via RDP-protokollen.
Angreb
Angribere opsnapper detaljerne, ved hjælp af hvilke afregningsspecialisten forbinder og arbejder med den automatiserede KBR-arbejdsplads (for eksempel på grund af ondsindet kode på hans computer). Derefter forbinder de på hans vegne og sender en falsk betalingsordre til betalingssystemet i Bank of Russia.
Scenarie 3. Et eksempel på implementeringen af truslen U1.3.
Beskrivelse af objektet
Lad os overveje en af de hypotetiske muligheder for implementering af ABS-KBR-integrationsmoduler til den nye ordning (ARM KBR-N), hvor den elektroniske signatur af udgående dokumenter forekommer på siden af ABS. I dette tilfælde vil vi antage, at ABS'en fungerer på basis af et operativsystem, der ikke understøttes af CIPF SKAD-signaturen, og derfor placeres den kryptografiske funktionalitet på en separat virtuel maskine - ABS-CBR-integrationsmodulet.
Et almindeligt USB-token, der fungerer i den flytbare nøgletilstand, bruges som nøgleholder. Da nøgleholderen blev tilsluttet hypervisoren, viste det sig, at der ikke var nogen ledige USB-porte i systemet, så det blev besluttet at tilslutte USB-tokenet gennem en netværks-USB-hub og installere en USB-over-IP-klient på virtuel maskine, der vil kommunikere med hubben.
Angreb
Angriberne opsnappede den private nøgle til den elektroniske signatur fra kommunikationskanalen mellem USB-hubben og hypervisoren (dataene blev transmitteret i klartekst). Med en privat nøgle genererede angriberne en falsk betalingsordre, underskrev den med en elektronisk signatur og sendte den til den automatiserede KBR-N-arbejdsplads til udførelse.
Scenarie 4. Et eksempel på implementering af trusler U5.5.
Beskrivelse af objektet
Overvej det samme kredsløb som i det foregående scenarie. Vi vil antage, at e-mails, der kommer fra KBR-N-arbejdsstationen, ender i …SHAREIn-mappen, og de, der sendes til KBR-N-arbejdsstationen og videre til Bank of Russias betalingssystem, går til …SHAREout.
Vi vil også antage, at ved implementering af integrationsmodulet, opdateres listerne over tilbagekaldte certifikater kun, når kryptografiske nøgler genudstedes, og også at elektroniske meddelelser modtaget i …SHAREIn-mappen kun kontrolleres for integritetskontrol og tillidskontrol til den offentlige nøgle af den elektroniske signatur.
Angreb
Angriberne, der brugte nøglerne stjålet i det tidligere scenarie, underskrev en falsk betalingsordre indeholdende oplysninger om modtagelsen af penge på en svigagtig klients konto og indførte den i en sikker dataudvekslingskanal. Da der ikke er nogen bekræftelse af, at betalingsordren er underskrevet af Bank of Russia, accepteres den til udførelse.
Kilde: www.habr.com