Lenker til andre deler av studiet
- (Er du her)
Denne artikkelen fullfører serien med publikasjoner som er viet til å sikre informasjonssikkerhet for bankbetalinger som ikke er kontanter. Her skal vi se på de typiske trusselmodellene det refereres til i :
- .
- .
- .
- .
HABRO-ADVARSEL!!! Kjære Khabrovites, dette er ikke et underholdende innlegg.
De 40+ sidene med materialer som er skjult under kuttet er ment å hjelpe til med jobb eller studier personer som spesialiserer seg på bank eller informasjonssikkerhet. Disse materialene er sluttproduktet av forskningen og er skrevet i en tørr, formell tone. I hovedsak er disse tomme for interne informasjonssikkerhetsdokumenter.Vel, tradisjonell - "bruk av informasjon fra artikkelen til ulovlige formål er straffbart ved lov". Produktiv lesning!
Informasjon til lesere som blir kjent med studien fra og med denne publikasjonen.
Hva handler studien om?
Du leser en veiledning for en spesialist med ansvar for å sikre informasjonssikkerhet ved betalinger i en bank.
Presentasjonens logikk
I begynnelsen i и det gis en beskrivelse av verneobjektet. Så inn beskriver hvordan man bygger et sikkerhetssystem og snakker om behovet for å lage en trusselmodell. I snakker om hvilke trusselmodeller som finnes og hvordan de dannes. I и En analyse av reelle angrep er gitt. и inneholde en beskrivelse av trusselmodellen, bygget med hensyn til informasjon fra alle tidligere deler.
TYPISK TRUSSMODELL. NETTVERKSTILGANG
Beskyttelsesobjekt som trusselmodellen (omfanget) brukes for
Objektet for beskyttelse er data som overføres gjennom en nettverksforbindelse som opererer i datanettverk bygget på TCP/IP-stakken.
arkitektur
Beskrivelse av arkitektoniske elementer:
- "End noder" — noder som utveksler beskyttet informasjon.
- "Mellomnoder" — elementer i et dataoverføringsnettverk: rutere, svitsjer, tilgangsservere, proxy-servere og annet utstyr — som nettverksforbindelsestrafikk overføres gjennom. Generelt kan en nettverksforbindelse fungere uten mellomnoder (direkte mellom endenoder).
Sikkerhetstrusler på toppnivå
Dekomponering
U1. Uautorisert tilgang til overførte data.
U2. Uautorisert endring av overførte data.
U3. Krenkelse av forfatterskapet til overførte data.
U1. Uautorisert tilgang til overførte data
Dekomponering
U1.1. , utført ved de siste eller mellomliggende nodene:
U1.1.1. ved å lese data mens de er i vertslagringsenhetene:
U1.1.1.1. i RAM.
Forklaringer til U1.1.1.1.
For eksempel under databehandling av vertens nettverksstabel.
U1.1.1.2. i ikke-flyktig minne.
Forklaringer til U1.1.1.2.
For eksempel når du lagrer overførte data i en cache, midlertidige filer eller swap-filer.
U1.2. , utført på tredjeparts noder i datanettverket:
U1.2.1. ved metoden for å fange opp alle pakker som kommer til vertens nettverksgrensesnitt:
Forklaringer til U1.2.1.
Innhenting av alle pakker utføres ved å bytte nettverkskortet til promiskuøs modus (promiskuøs modus for kablede adaptere eller monitormodus for wi-fi adaptere).
U1.2.2. ved å utføre man-in-the-middle (MiTM) angrep, men uten å endre de overførte dataene (ikke medregnet nettverksprotokolltjenestedata).
U1.2.2.1. Link: .
U1.3. , utført på grunn av informasjonslekkasje gjennom tekniske kanaler (TKUI) fra fysiske noder eller kommunikasjonslinjer.
U1.4. , utført ved å installere spesielle tekniske midler (STS) på enden eller mellomnodene, beregnet for hemmelig innsamling av informasjon.
U2. Uautorisert endring av overførte data
Dekomponering
U2.1. , utført ved de siste eller mellomliggende nodene:
U2.1.1. ved å lese og gjøre endringer i dataene mens de er i lagringsenhetene til nodene:
U2.1.1.1. i RAM:
U2.1.1.2. i ikke-flyktig minne:
U2.2. , utført på tredjeparts noder i dataoverføringsnettverket:
U2.2.1. ved å utføre man-in-the-middle (MiTM)-angrep og omdirigere trafikk til angripernes node:
U2.2.1.1. Fysisk tilkobling av angripernes utstyr fører til at en nettverksforbindelse brytes.
U2.2.1.2. Utføre angrep på nettverksprotokoller:
U2.2.1.2.1. administrasjon av virtuelle lokale nettverk (VLAN):
U2.2.1.2.1.1. .
U2.2.1.2.1.2. Uautorisert endring av VLAN-innstillinger på brytere eller rutere.
U2.2.1.2.2. trafikkruting:
U2.2.1.2.2.1. Uautorisert modifikasjon av statiske rutingtabeller for rutere.
U2.2.1.2.2.2. Kunngjøring av falske ruter av angripere gjennom dynamiske rutingprotokoller.
U2.2.1.2.3. automatisk konfigurasjon:
U2.2.1.2.3.1. .
U2.2.1.2.3.2. .
U2.2.1.2.4. adressering og navneoppløsning:
U2.2.1.2.4.1. .
U2.2.1.2.4.2. .
U2.2.1.2.4.3. Gjøre uautoriserte endringer i lokale vertsnavnfiler (verter, lmhosts, etc.)
U3. Krenkelse av opphavsretten til overførte data
Dekomponering
U3.1. Nøytralisering av mekanismer for å bestemme forfatterskapet til informasjon ved å indikere falsk informasjon om forfatteren eller datakilden:
U3.1.1. Endring av informasjon om forfatteren i den overførte informasjonen.
U3.1.1.1. Nøytralisering av kryptografisk beskyttelse av integriteten og forfatterskapet til overførte data:
U3.1.1.1.1. Link: .
U3.1.1.2. Nøytralisering av opphavsrettslig beskyttelse av overførte data, implementert ved å bruke engangsbekreftelseskoder:
U3.1.1.2.1. .
U3.1.2. Endre informasjon om kilden til overført informasjon:
U3.1.2.1. .
U3.1.2.2. .
TYPISK TRUSSMODELL. INFORMASJONSSYSTEM BYGGET PÅ BASEN AV KLIENT-SERVER-ARKITEKTUR
Beskyttelsesobjekt som trusselmodellen (omfanget) brukes for
Objektet for beskyttelse er et informasjonssystem bygget på grunnlag av en klient-server-arkitektur.
arkitektur
Beskrivelse av arkitektoniske elementer:
- "Klient" – en enhet som klientdelen av informasjonssystemet opererer på.
- "Server" – en enhet som serverdelen av informasjonssystemet opererer på.
- "Datalager" – del av serverinfrastrukturen til et informasjonssystem, utformet for å lagre data som behandles av informasjonssystemet.
- "Nettverkstilgang" — en informasjonsutvekslingskanal mellom klienten og serveren som går gjennom datanettverket. En mer detaljert beskrivelse av elementmodellen er gitt i .
Restriksjoner
Når du modellerer et objekt, settes følgende begrensninger:
- Brukeren samhandler med informasjonssystemet innen begrensede tidsperioder, kalt arbeidsøkter.
- Ved begynnelsen av hver arbeidsøkt blir brukeren identifisert, autentisert og autorisert.
- All beskyttet informasjon lagres på serverdelen av informasjonssystemet.
Sikkerhetstrusler på toppnivå
Dekomponering
U1. Utføre uautoriserte handlinger av angripere på vegne av en legitim bruker.
U2. Uautorisert endring av beskyttet informasjon under behandlingen av serverdelen av informasjonssystemet.
U1. Utføre uautoriserte handlinger av angripere på vegne av en legitim bruker
forklaringer
Vanligvis i informasjonssystemer er handlinger korrelert med brukeren som utførte dem ved å bruke:
- systemdriftslogger (logger).
- spesielle attributter til dataobjekter som inneholder informasjon om brukeren som opprettet eller modifiserte dem.
I forhold til en arbeidsøkt kan denne trusselen dekomponeres i:
- utført i brukerøkten.
- utført utenfor brukerøkten.
En brukerøkt kan startes:
- Av brukeren selv.
- Misbrukere.
På dette stadiet vil den mellomliggende dekomponeringen av denne trusselen se slik ut:
U1.1. Uautoriserte handlinger ble utført i en brukerøkt:
U1.1.1. installert av den angrepne brukeren.
U1.1.2. installert av angripere.
U1.2. Uautoriserte handlinger ble utført utenfor brukerøkten.
Fra synspunktet til informasjonsinfrastrukturobjekter som kan bli påvirket av angripere, vil dekomponeringen av mellomliggende trusler se slik ut:
elementer
Trussel nedbrytning
U1.1.1.
U1.1.2.
U1.2.
kunde
U1.1.1.1.
U1.1.2.1.
Nettverkstilgang
U1.1.1.2.
Сервер
U1.2.1.
Dekomponering
U1.1. Uautoriserte handlinger ble utført i en brukerøkt:
U1.1.1. installert av den angrepne brukeren:
U1.1.1.1. Angriperne handlet uavhengig av klienten:
U1.1.1.1.1 Angriperne brukte standard informasjonssystemtilgangsverktøy:
У1.1.1.1.1.1. Angriperne brukte klientens fysiske input/output-midler (tastatur, mus, skjerm eller berøringsskjerm på en mobilenhet):
U1.1.1.1.1.1.1. Angriperne opererte i perioder hvor økten var aktiv, I/O-fasiliteter var tilgjengelig og brukeren ikke var til stede.
У1.1.1.1.1.2. Angriperne brukte fjernadministrasjonsverktøy (standard eller levert av ondsinnet kode) for å administrere klienten:
U1.1.1.1.1.2.1. Angriperne opererte i perioder hvor økten var aktiv, I/O-fasiliteter var tilgjengelig og brukeren ikke var til stede.
У1.1.1.1.1.2.2. Angriperne brukte fjernadministrasjonsverktøy, hvis drift er usynlig for den angrepne brukeren.
U1.1.1.2. Angriperne erstattet dataene i nettverksforbindelsen mellom klienten og serveren, og modifiserte dem på en slik måte at de ble oppfattet som handlingene til en legitim bruker:
U1.1.1.2.1. Link: .
U1.1.1.3. Angriperne tvang brukeren til å utføre handlingene de spesifiserte ved hjelp av sosiale ingeniørmetoder.
У1.1.2 installert av angripere:
U1.1.2.1. Angriperne handlet fra klienten (И):
U1.1.2.1.1. Angriperne nøytraliserte tilgangskontrollsystemet til informasjonssystemet:
U1.1.2.1.1.1. Link: .
У1.1.2.1.2. Angriperne brukte standard verktøy for tilgang til informasjonssystem
U1.1.2.2. Angriperne opererte fra andre noder i datanettverket, hvorfra en nettverksforbindelse til serveren kunne opprettes (И):
U1.1.2.2.1. Angriperne nøytraliserte tilgangskontrollsystemet til informasjonssystemet:
U1.1.2.2.1.1. Link: .
U1.1.2.2.2. Angriperne brukte ikke-standardiserte metoder for å få tilgang til informasjonssystemet.
Forklaringer U1.1.2.2.2.
Angriperne kan installere en standard klient av informasjonssystemet på en tredjeparts node eller kan bruke ikke-standard programvare som implementerer standard utvekslingsprotokoller mellom klienten og serveren.
U1.2 Uautoriserte handlinger ble utført utenfor brukersesjonen.
U1.2.1 Angripere utførte uautoriserte handlinger og gjorde deretter uautoriserte endringer i informasjonssystemets operasjonslogger eller spesielle attributter til dataobjekter, noe som indikerer at handlingene de utførte ble utført av en legitim bruker.
U2. Uautorisert endring av beskyttet informasjon under behandlingen av serverdelen av informasjonssystemet
Dekomponering
U2.1. Angripere endrer beskyttet informasjon ved å bruke standard informasjonssystemverktøy og gjør dette på vegne av en legitim bruker.
U2.1.1. Link: .
U2.2. Angripere endrer beskyttet informasjon ved å bruke datatilgangsmekanismer som ikke er gitt av normal drift av informasjonssystemet.
U2.2.1. Angripere endrer filer som inneholder beskyttet informasjon:
U2.2.1.1. , ved å bruke filhåndteringsmekanismene levert av operativsystemet.
U2.2.1.2. ved å provosere gjenoppretting av filer fra en uautorisert modifisert sikkerhetskopi.
U2.2.2. Angripere endrer beskyttet informasjon som er lagret i databasen (И):
U2.2.2.1. Angripere nøytraliserer DBMS-tilgangskontrollsystemet:
U2.2.2.1.1. Link: .
U2.2.2.2. Angripere endrer informasjon ved å bruke standard DBMS-grensesnitt for å få tilgang til data.
U2.3. Angripere endrer beskyttet informasjon ved uautorisert modifikasjon av driftsalgoritmene til programvaren som behandler den.
U2.3.1. Kildekoden til programvaren kan endres.
U2.3.1. Maskinkoden til programvaren kan endres.
U2.4. Angripere endrer beskyttet informasjon ved å utnytte sårbarheter i informasjonssystemprogramvare.
U2.5. Angripere endrer beskyttet informasjon når den overføres mellom komponenter i serverdelen av informasjonssystemet (for eksempel en databaseserver og en applikasjonsserver):
U2.5.1. Link: .
TYPISK TRUSSMODELL. TILGANGSKONTROLLSYSTEM
Beskyttelsesobjekt som trusselmodellen (omfanget) brukes for
Beskyttelsesobjektet som denne trusselmodellen brukes for, tilsvarer beskyttelsesobjektet til trusselmodellen: «Typisk trusselmodell. Et informasjonssystem bygget på en klient-server-arkitektur."
I denne trusselmodellen betyr et brukertilgangskontrollsystem en komponent i et informasjonssystem som implementerer følgende funksjoner:
- Brukeridentifikasjon.
- Bruker autentisering.
- Brukerautorisasjoner.
- Logging av brukerhandlinger.
Sikkerhetstrusler på toppnivå
Dekomponering
U1. Uautorisert etablering av en økt på vegne av en legitim bruker.
U2. Uautorisert økning av brukerrettigheter i et informasjonssystem.
U1. Uautorisert etablering av en økt på vegne av en legitim bruker
forklaringer
Dekomponeringen av denne trusselen vil generelt avhenge av typen brukeridentifikasjon og autentiseringssystemer som brukes.
I denne modellen vil kun et brukeridentifikasjons- og autentiseringssystem som bruker tekstpålogging og passord bli vurdert. I dette tilfellet vil vi anta at brukerpåloggingen er offentlig tilgjengelig informasjon kjent for angripere.
Dekomponering
U1.1. på grunn av kompromittering av legitimasjon:
U1.1.1. Angriperne kompromitterte brukerens legitimasjon mens de lagret dem.
Forklaringer U1.1.1.
For eksempel kan legitimasjonen skrives på en lapp som sitter fast på skjermen.
U1.1.2. Brukeren ga ved et uhell eller ondsinnet tilgangsinformasjon til angriperne.
U1.1.2.1. Brukeren fortalte legitimasjonen høyt da de kom inn.
U1.1.2.2. Brukeren delte med hensikt sin legitimasjon:
U1.1.2.2.1. til arbeidskolleger.
Forklaringer U1.1.2.2.1.
For eksempel slik at de kan erstatte det under sykdom.
U1.1.2.2.2. til arbeidsgivers entreprenører som utfører arbeid på informasjonsinfrastrukturobjekter.
U1.1.2.2.3. til tredjeparter.
Forklaringer U1.1.2.2.3.
Ett, men ikke det eneste alternativet for å implementere denne trusselen, er bruken av sosiale ingeniørmetoder av angripere.
U1.1.3. Angriperne valgte legitimasjon ved å bruke brute force-metoder:
U1.1.3.1. ved å bruke standard tilgangsmekanismer.
U1.1.3.2. ved å bruke tidligere avlyttede koder (for eksempel passordhash) for lagring av legitimasjon.
U1.1.4. Angriperne brukte ondsinnet kode for å avskjære brukerlegitimasjon.
U1.1.5. Angriperne hentet ut legitimasjon fra nettverksforbindelsen mellom klienten og serveren:
U1.1.5.1. Link: .
U1.1.6. Angriperne hentet ut legitimasjon fra registreringer av arbeidsovervåkingssystemer:
U1.1.6.1. videoovervåkingssystemer (hvis tastetrykk på tastaturet ble registrert under drift).
U1.1.6.2. systemer for overvåking av ansattes handlinger ved datamaskinen
Forklaringer U1.1.6.2.
Et eksempel på et slikt system er .
U1.1.7. Angripere kompromitterte brukerlegitimasjonen på grunn av feil i overføringsprosessen.
Forklaringer U1.1.7.
For eksempel å sende passord i klartekst via e-post.
U1.1.8. Angripere skaffet seg legitimasjon ved å overvåke en brukers økt ved hjelp av eksterne administrasjonssystemer.
U1.1.9. Angriperne fikk legitimasjon som et resultat av lekkasjen gjennom tekniske kanaler (TCUI):
U1.1.9.1. Angriperne observerte hvordan brukeren skrev inn legitimasjon fra tastaturet:
U1.1.9.1.1 Angriperne var lokalisert i umiddelbar nærhet av brukeren og så inntastingen av legitimasjon med egne øyne.
Forklaringer U1.1.9.1.1
Slike tilfeller inkluderer handlingene til arbeidskolleger eller tilfellet når brukerens tastatur er synlig for besøkende til organisasjonen.
U1.1.9.1.2 Angriperne brukte ytterligere tekniske midler, for eksempel en kikkert eller et ubemannet luftfartøy, og så innføringen av legitimasjon gjennom et vindu.
U1.1.9.2. Angriperne hentet ut legitimasjon fra radiokommunikasjon mellom tastaturet og datasystemenheten da de var koblet til via et radiogrensesnitt (for eksempel Bluetooth).
U1.1.9.3. Angriperne fanget opp legitimasjon ved å lekke dem gjennom kanalen for falsk elektromagnetisk stråling og interferens (PEMIN).
Forklaringer U1.1.9.3.
Eksempler på angrep и .
U1.1.9.4. Angriperen avskjærte innføringen av legitimasjon fra tastaturet ved bruk av spesielle tekniske midler (STS) designet for å skaffe informasjon i hemmelighet.
Forklaringer U1.1.9.4.
Примеры .
U1.1.9.5. Angriperne fanget opp påloggingsinformasjonen fra tastaturet ved hjelp av
analyse av Wi-Fi-signalet modulert av brukerens tastetrykkprosess.
Forklaringer U1.1.9.5.
Eksempel .
U1.1.9.6. Angriperne fanget opp påloggingsinformasjonen fra tastaturet ved å analysere lydene av tastetrykk.
Forklaringer U1.1.9.6.
Eksempel .
U1.1.9.7. Angriperne fanget opp påloggingsinformasjonen fra tastaturet til en mobilenhet ved å analysere akselerometeravlesninger.
Forklaringer U1.1.9.7.
Eksempel .
U1.1.10. , tidligere lagret på klienten.
Forklaringer U1.1.10.
For eksempel kan en bruker lagre en pålogging og passord i nettleseren for å få tilgang til et bestemt nettsted.
U1.1.11. Angripere kompromitterte legitimasjon på grunn av feil i prosessen for å tilbakekalle brukertilgang.
Forklaringer U1.1.11.
For eksempel, etter at en bruker ble sparket, forble kontoen hans ublokkert.
U1.2. ved å utnytte sårbarheter i tilgangskontrollsystemet.
U2. Uautorisert heving av brukerrettigheter i et informasjonssystem
Dekomponering
U2.1 ved å gjøre uautoriserte endringer i data som inneholder informasjon om brukerrettigheter.
U2.2 gjennom bruk av sårbarheter i tilgangskontrollsystemet.
U2.3. på grunn av mangler i administrasjonsprosessen for brukertilgang.
Forklaringer U2.3.
Eksempel 1. En bruker fikk mer tilgang til arbeid enn han krevde av forretningsmessige årsaker.
Eksempel 2: Etter at en bruker ble overført til en annen stilling, ble ikke tidligere gitte tilgangsrettigheter tilbakekalt.
TYPISK TRUSSMODELL. INTEGRASJONSMODUL
Beskyttelsesobjekt som trusselmodellen (omfanget) brukes for
En integrasjonsmodul er et sett med informasjonsinfrastrukturobjekter designet for å organisere utveksling av informasjon mellom informasjonssystemer.
Tatt i betraktning at det i bedriftsnettverk ikke alltid er mulig å entydig skille ett informasjonssystem fra et annet, kan integrasjonsmodulen også betraktes som en forbindelse mellom komponenter i ett informasjonssystem.
arkitektur
Det generaliserte diagrammet for integrasjonsmodulen ser slik ut:
Beskrivelse av arkitektoniske elementer:
- "Exchange Server (SO)" – en node / tjeneste / komponent i et informasjonssystem som utfører funksjonen å utveksle data med et annet informasjonssystem.
- "Megler" – en node/tjeneste designet for å organisere samhandling mellom informasjonssystemer, men ikke en del av dem.
Eksempler "Mellommenn" det kan være e-posttjenester, bedriftstjenestebusser (bedriftstjenestebuss / SoA-arkitektur), tredjeparts filservere, etc. Generelt kan det hende at integrasjonsmodulen ikke inneholder "mellomledd". - "Databehandlingsprogramvare" – et sett med programmer som implementerer datautvekslingsprotokoller og formatkonvertering.
For eksempel, konvertering av data fra UFEBS-formatet til ABS-formatet, endring av meldingsstatuser under overføring, etc. - "Nettverkstilgang" tilsvarer objektet beskrevet i standard trusselmodellen "Nettverkstilkobling". Noen av nettverkstilkoblingene vist i diagrammet ovenfor eksisterer kanskje ikke.
Eksempler på integrasjonsmoduler
Opplegg 1. Integrasjon av ABS og AWS KBR via en tredjeparts filserver
For å utføre betalinger laster en autorisert bankmedarbeider ned elektroniske betalingsdokumenter fra kjernebanksystemet og lagrer dem til en fil (i eget format, for eksempel en SQL-dump) på en nettverksmappe (...DEL) på en filserver. Deretter konverteres denne filen ved hjelp av et konverteringsskript til et sett med filer i UFEBS-formatet, som deretter leses av CBD-arbeidsstasjonen.
Etter dette krypterer og signerer den autoriserte ansatte - brukeren av den automatiserte arbeidsplassen KBR - de mottatte filene og sender dem til betalingssystemet til Bank of Russia.
Når betalinger mottas fra Bank of Russia, dekrypterer den automatiserte arbeidsplassen til KBR dem og sjekker den elektroniske signaturen, hvoretter den registrerer dem i form av et sett med filer i UFEBS-formatet på en filserver. Før du importerer betalingsdokumenter til ABS, konverteres de ved hjelp av et konverteringsskript fra UFEBS-formatet til ABS-formatet.
Vi vil anta at i dette opplegget opererer ABS på én fysisk server, KBR-arbeidsstasjonen opererer på en dedikert datamaskin, og konverteringsskriptet kjører på en filserver.
Korrespondanse av objektene i det betraktede diagrammet til elementene i integrasjonsmodulmodellen:
"Utvekslingsserver fra ABS-siden" – ABS-server.
"Utvekslingsserver fra AWS KBR-siden" – datamaskin arbeidsstasjon KBR.
"Megler" – tredjeparts filserver.
"Databehandlingsprogramvare" – konverteringsskript.
Skjema 2. Integrasjon av ABS og AWS KBR ved plassering av en delt nettverksmappe med betalinger på AWS KBR
Alt ligner på skjema 1, men en egen filserver brukes ikke, i stedet plasseres en nettverksmappe (...DEL) med elektroniske betalingsdokumenter på en datamaskin med en arbeidsstasjon for CBD. Konverteringsskriptet fungerer også på CBD-arbeidsstasjonen.
Korrespondanse av objektene i det betraktede diagrammet til elementene i integrasjonsmodulmodellen:
Ligner på skjema 1, men "Megler" ikke brukt.
Opplegg 3. Integrasjon av ABS og automatisert arbeidsplass KBR-N via IBM WebSphera MQ og signering av elektroniske dokumenter «på ABS-siden»
ABS opererer på en plattform som ikke støttes av CIPF SCAD Signature. Signering av utgående elektroniske dokumenter utføres på en spesiell elektronisk signaturserver (ES Server). Den samme serveren sjekker den elektroniske signaturen på dokumenter som kommer inn fra Bank of Russia.
ABS laster opp en fil med betalingsdokumenter i sitt eget format til ES Server.
ES-serveren, ved hjelp av et konverteringsskript, konverterer filen til elektroniske meldinger i UFEBS-format, hvoretter de elektroniske meldingene signeres og overføres til IBM WebSphere MQ.
KBR-N-arbeidsstasjonen får tilgang til IBM WebSphere MQ og mottar signerte betalingsmeldinger derfra, hvoretter en autorisert ansatt - en bruker av KBR-arbeidsstasjonen - krypterer dem og sender dem til betalingssystemet til Bank of Russia.
Når betalinger mottas fra Bank of Russia, dekrypterer den automatiserte arbeidsplassen KBR-N dem og verifiserer den elektroniske signaturen. Vellykket behandlede betalinger i form av dekrypterte og signerte elektroniske meldinger i UFEBS-formatet overføres til IBM WebSphere MQ, hvorfra de mottas av den elektroniske signaturserveren.
Den elektroniske signaturserveren verifiserer den elektroniske signaturen til mottatte betalinger og lagrer dem i en fil i ABS-format. Etter dette laster den autoriserte medarbeideren - ABS-brukeren - opp den resulterende filen til ABS på foreskrevet måte.
Korrespondanse av objektene i det betraktede diagrammet til elementene i integrasjonsmodulmodellen:
"Utvekslingsserver fra ABS-siden" – ABS-server.
"Utvekslingsserver fra AWS KBR-siden" — datamaskin arbeidsstasjon KBR.
"Megler" – ES-server og IBM WebSphere MQ.
"Databehandlingsprogramvare" – skriptkonverterer, CIPF SCAD-signatur på ES-serveren.
Skjema 4. Integrasjon av RBS-serveren og kjernebanksystemet via API-en levert av en dedikert utvekslingsserver
Vi vil anta at banken bruker flere eksterne banksystemer (RBS):
- "Internet Client-Bank" for enkeltpersoner (IKB FL);
- "Internet Client-Bank" for juridiske personer (IKB LE).
For å sikre informasjonssikkerhet utføres all interaksjon mellom ABS og eksterne banksystemer gjennom en dedikert utvekslingsserver som opererer innenfor rammen av ABS informasjonssystemet.
Deretter vil vi vurdere prosessen med interaksjon mellom RBS-systemet til IKB LE og ABS.
RBS-serveren, etter å ha mottatt en behørig sertifisert betalingsordre fra klienten, må opprette et tilsvarende dokument i ABS basert på det. For å gjøre dette, ved hjelp av API, overfører den informasjon til utvekslingsserveren, som igjen legger inn dataene i ABS.
Når klientens kontosaldo endres, genererer ABS elektroniske varsler, som overføres til den eksterne bankserveren ved hjelp av utvekslingsserveren.
Korrespondanse av objektene i det betraktede diagrammet til elementene i integrasjonsmodulmodellen:
“Utvekslingsserver fra RBS-siden” – RBS-server til IKB YUL.
"Utvekslingsserver fra ABS-siden" – utvekslingsserver.
"Megler" - fraværende.
"Databehandlingsprogramvare" – RBS Server-komponenter som er ansvarlige for bruk av Exchange Server API, Exchange Server-komponenter som er ansvarlige for bruk av kjernebank API.
Sikkerhetstrusler på toppnivå
Dekomponering
U1. Injeksjon av falsk informasjon fra angripere gjennom integrasjonsmodulen.
U1. Injeksjon av falsk informasjon fra angripere gjennom integrasjonsmodulen
Dekomponering
U1.1. Uautorisert endring av legitime data når de overføres over nettverkstilkoblinger:
U1.1.1 Link: .
U1.2. Overføring av falske data via kommunikasjonskanaler på vegne av en legitim utvekslingsdeltaker:
U1.1.2 Link: .
U1.3. Uautorisert endring av legitime data under behandlingen på Exchange-servere eller mellomledd:
U1.3.1. Link: .
U1.4. Opprettelse av falske data på Exchange-servere eller mellomledd på vegne av en legitim utvekslingsdeltaker:
U1.4.1. Link:
U1.5. Uautorisert endring av data når de behandles med databehandlingsprogramvare:
U1.5.1. på grunn av at angripere gjør uautoriserte endringer i innstillingene (konfigurasjonen) av databehandlingsprogramvare.
U1.5.2. på grunn av angripere som gjør uautoriserte endringer i kjørbare filer av databehandlingsprogramvare.
U1.5.3. på grunn av den interaktive kontrollen av databehandlingsprogramvaren fra angripere.
TYPISK TRUSSMODELL. KRYPTOGRAFISK INFORMASJONSBESKYTTELSESSYSTEM
Beskyttelsesobjekt som trusselmodellen (omfanget) brukes for
Objektet for beskyttelse er et kryptografisk informasjonsbeskyttelsessystem som brukes for å sikre sikkerheten til informasjonssystemet.
arkitektur
Grunnlaget for ethvert informasjonssystem er applikasjonsprogramvare som implementerer målfunksjonaliteten.
Kryptografisk beskyttelse implementeres vanligvis ved å kalle kryptografiske primitiver fra forretningslogikken til applikasjonsprogramvaren, som er plassert i spesialiserte biblioteker - kryptokjerner.
Kryptografiske primitiver inkluderer kryptografiske funksjoner på lavt nivå, for eksempel:
- kryptere/dekryptere en blokk med data;
- opprette/verifisere en elektronisk signatur av en datablokk;
- beregne hash-funksjonen til datablokken;
- generere / laste / laste opp nøkkelinformasjon;
- etc.
Forretningslogikken til applikasjonsprogramvaren implementerer funksjonalitet på høyere nivå ved bruk av kryptografiske primitiver:
- krypter filen ved å bruke nøklene til de valgte mottakerne;
- etablere en sikker nettverkstilkobling;
- informere om resultatene av å sjekke den elektroniske signaturen;
- og så videre.
Samspillet mellom forretningslogikk og kryptokjerne kan utføres:
- direkte, ved forretningslogikk som kaller kryptografiske primitiver fra dynamiske biblioteker til kryptokjernen (.DLL for Windows, .SO for Linux);
- direkte, gjennom kryptografiske grensesnitt - wrappers, for eksempel MS Crypto API, Java Cryptography Architecture, PKCS#11, etc. I dette tilfellet får forretningslogikken tilgang til kryptogrensesnittet, og den oversetter kallet til den tilsvarende kryptokjernen, som i denne saken kalles kryptoleverandør. Bruken av kryptografiske grensesnitt lar applikasjonsprogramvare abstrahere bort fra spesifikke kryptografiske algoritmer og være mer fleksibel.
Det er to typiske ordninger for å organisere kryptokjernen:
Skjema 1 - Monolittisk kryptokjerne
Skjema 2 – Delt kryptokjerne
Elementene i diagrammene ovenfor kan enten være individuelle programvaremoduler som kjører på én datamaskin eller nettverkstjenester som samhandler i et datanettverk.
Når du bruker systemer bygget i henhold til skjema 1, opererer applikasjonsprogramvaren og kryptokjernen innenfor et enkelt driftsmiljø for kryptoverktøyet (SFC), for eksempel på samme datamaskin som kjører det samme operativsystemet. Systembrukeren kan som regel kjøre andre programmer, inkludert de som inneholder skadelig kode, innenfor samme driftsmiljø. Under slike forhold er det en alvorlig risiko for lekkasje av private kryptografiske nøkler.
For å minimere risikoen brukes skjema 2, der kryptokjernen er delt inn i to deler:
- Den første delen, sammen med applikasjonsprogramvaren, opererer i et upålitelig miljø hvor det er fare for infeksjon med ondsinnet kode. Vi vil kalle denne delen "programvaredelen".
- Den andre delen fungerer i et pålitelig miljø på en dedikert enhet, som inneholder en privat nøkkellagring. Fra nå av vil vi kalle denne delen "maskinvare".
Inndelingen av kryptokjernen i programvare- og maskinvaredeler er veldig vilkårlig. Det er systemer på markedet bygget i henhold til et skjema med en delt kryptokjerne, men "maskinvaredelen" presenteres i form av et virtuell maskinbilde - virtuell HSM ().
Samspillet mellom begge deler av kryptokjernen skjer på en slik måte at private kryptografiske nøkler aldri overføres til programvaredelen og følgelig ikke kan stjeles ved hjelp av ondsinnet kode.
Interaksjonsgrensesnittet (API) og settet med kryptografiske primitiver gitt til applikasjonsprogramvaren av kryptokjernen er det samme i begge tilfeller. Forskjellen ligger i måten de implementeres på.
Således, når du bruker et opplegg med en delt kryptokjerne, utføres samspillet mellom programvare og maskinvare i henhold til følgende prinsipp:
- Kryptografiske primitiver som ikke krever bruk av en privat nøkkel (for eksempel beregning av en hash-funksjon, verifisering av elektronisk signatur osv.) utføres av programvaren.
- Kryptografiske primitiver som bruker en privat nøkkel (oppretter en elektronisk signatur, dekrypterer data osv.) utføres av maskinvare.
La oss illustrere arbeidet til den delte kryptokjernen ved å bruke eksemplet med å lage en elektronisk signatur:
- Programvaredelen beregner hash-funksjonen til de signerte dataene og overfører denne verdien til maskinvaren via utvekslingskanalen mellom kryptokjerner.
- Maskinvaredelen, ved hjelp av den private nøkkelen og hashen, genererer verdien av den elektroniske signaturen og overfører den til programvaredelen via en utvekslingskanal.
- Programvaredelen returnerer den mottatte verdien til applikasjonsprogramvaren.
Funksjoner for å kontrollere riktigheten av en elektronisk signatur
Når mottaker mottar elektronisk signert data, må den gjennomføre flere verifikasjonstrinn. Et positivt resultat av å sjekke en elektronisk signatur oppnås bare hvis alle stadier av bekreftelse er fullført.
Trinn 1. Kontroll av dataintegritet og dataforfatterskap.
Scenens innhold. Den elektroniske signaturen til dataene verifiseres ved hjelp av riktig kryptografisk algoritme. Vellykket gjennomføring av dette stadiet indikerer at dataene ikke har blitt endret siden det ble signert, og også at signaturen ble laget med en privat nøkkel som tilsvarer den offentlige nøkkelen for å verifisere den elektroniske signaturen.
Plassering av scenen: kryptokjerne.
Trinn 2. Kontroll av tillit til underskriverens offentlige nøkkel og kontroll av gyldighetsperioden til den private nøkkelen til den elektroniske signaturen.
Scenens innhold. Scenen består av to mellomliggende deltrinn. Den første er å bestemme om den offentlige nøkkelen for å bekrefte den elektroniske signaturen var klarert på tidspunktet for signering av dataene. Den andre avgjør om den private nøkkelen til den elektroniske signaturen var gyldig på tidspunktet for signering av dataene. Generelt kan det hende at gyldighetsperiodene til disse nøklene ikke faller sammen (for eksempel for kvalifiserte sertifikater for bekreftelsesnøkler for elektronisk signatur). Metoder for å etablere tillit til underskriverens offentlige nøkkel bestemmes av reglene for elektronisk dokumenthåndtering vedtatt av de samhandlende partene.
Plassering av scenen: applikasjonsprogramvare / kryptokjerne.
Trinn 3. Kontroll av underskriverens fullmakt.
Scenens innhold. I henhold til fastsatte regler for elektronisk dokumenthåndtering kontrolleres det om underskriver hadde rett til å attestere de beskyttede dataene. La oss som et eksempel gi en situasjon med myndighetsbrudd. Anta at det er en organisasjon der alle ansatte har en elektronisk signatur. Det interne elektroniske dokumenthåndteringssystemet mottar en bestilling fra leder, men signert med elektronisk signatur fra lagersjef. Følgelig kan et slikt dokument ikke anses som legitimt.
Plassering av scenen: applikasjonsprogramvare.
Forutsetninger gjort ved beskrivelse av verneobjektet
- Informasjonsoverføringskanaler, med unntak av nøkkelutvekslingskanaler, går også gjennom applikasjonsprogramvare, API og kryptokjerne.
- Informasjon om tillit til offentlige nøkler og (eller) sertifikater, samt informasjon om kreftene til eiere av offentlige nøkkel, finnes i det offentlige nøkkellageret.
- Programvaren fungerer med det offentlige nøkkellageret gjennom kryptokjernen.
Et eksempel på et informasjonssystem beskyttet ved hjelp av CIPF
For å illustrere de tidligere presenterte diagrammene, la oss vurdere et hypotetisk informasjonssystem og fremheve alle strukturelle elementer på det.
Beskrivelse av informasjonssystemet
De to organisasjonene bestemte seg for å innføre juridisk viktig elektronisk dokumenthåndtering (EDF) seg imellom. For å gjøre dette inngikk de en avtale der de satte fast at dokumenter skulle overføres på e-post, og samtidig skal de være kryptert og signert med en kvalifisert elektronisk signatur. Office-programmer fra Microsoft Office 2016-pakken bør brukes som verktøy for å lage og behandle dokumenter, og CIPF CryptoPRO og krypteringsprogramvare CryptoARM bør brukes som middel for kryptografisk beskyttelse.
Beskrivelse av organisasjonens infrastruktur 1
Organisasjon 1 bestemte seg for å installere CIPF CryptoPRO og CryptoARM programvare på brukerens arbeidsstasjon - en fysisk datamaskin. Kryptering og elektroniske signaturnøkler vil bli lagret på ruToken-nøkkelmediet, som opererer i gjenfinnbar nøkkelmodus. Brukeren vil forberede elektroniske dokumenter lokalt på datamaskinen, deretter kryptere, signere og sende dem ved hjelp av en lokalt installert e-postklient.
Beskrivelse av organisasjonens infrastruktur 2
Organisasjon 2 bestemte seg for å flytte krypterings- og elektroniske signaturfunksjonene til en dedikert virtuell maskin. I dette tilfellet vil alle kryptografiske operasjoner utføres automatisk.
For å gjøre dette er to nettverksmapper organisert på den dedikerte virtuelle maskinen: "...In", "...Out". Filer mottatt fra motparten i åpen form vil automatisk bli plassert i nettverksmappen "...In". Disse filene vil bli dekryptert og den elektroniske signaturen vil bli verifisert.
Brukeren vil plassere filer i mappen "...Out" som må krypteres, signeres og sendes til motparten. Brukeren vil klargjøre filene selv på arbeidsstasjonen sin.
For å utføre kryptering og elektroniske signaturfunksjoner er CIPF CryptoPRO, CryptoARM-programvare og en e-postklient installert på den virtuelle maskinen. Automatisk administrasjon av alle elementer i den virtuelle maskinen vil bli utført ved hjelp av skript utviklet av systemadministratorer. Arbeidet med skript logges i loggfiler.
Kryptografiske nøkler for den elektroniske signaturen vil bli plassert på et token med en ikke-hentbar JaCarta GOST-nøkkel, som brukeren vil koble til sin lokale datamaskin.
Tokenet vil bli videresendt til den virtuelle maskinen ved hjelp av spesialisert USB-over-IP-programvare installert på brukerens arbeidsstasjon og på den virtuelle maskinen.
Systemklokken på brukerens arbeidsstasjon i organisasjon 1 vil bli justert manuelt. Systemklokken til den dedikerte virtuelle maskinen i Organisasjon 2 vil bli synkronisert med hypervisor-systemklokken, som igjen vil bli synkronisert over Internett med offentlige tidsservere.
Identifikasjon av strukturelle elementer av CIPF
Basert på ovenstående beskrivelse av IT-infrastrukturen, vil vi fremheve de strukturelle elementene til CIPF og skrive dem i en tabell.
Tabell - Korrespondanse av CIPF-modellelementer til informasjonssystemelementer
Gjenstandsnavn
Organisasjon 1
Organisasjon 2
Applikasjonsprogramvare
CryptoARM programvare
CryptoARM programvare
Programvare del av kryptokjernen
CIPF CryptoPRO CSP
CIPF CryptoPRO CSP
Krypto kjerne maskinvare
ikke
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Offentlig nøkkelbutikk
Brukerens arbeidsstasjon:
- HDD;
- standard Windows-sertifikatlager.
Hypervisor:
- HDD.
Virtuell maskin:
- HDD;
- standard Windows-sertifikatlager.
Privat nøkkellagring
ruToken nøkkelbærer som opererer i gjenfinnbar nøkkelmodus
JaCarta GOST nøkkelholder som opererer i ikke-flyttbar nøkkelmodus
Offentlig nøkkelutvekslingskanal
Brukerens arbeidsstasjon:
- RAM.
Hypervisor:
- RAM.
Virtuell maskin:
- RAM.
Privat nøkkelutvekslingskanal
Brukerens arbeidsstasjon:
— USB-buss;
- RAM.
ikke
Utvekslingskanal mellom kryptokjerner
mangler (ingen kryptokjernemaskinvare)
Brukerens arbeidsstasjon:
— USB-buss;
- RAM;
— USB-over-IP programvaremodul;
- nettverksgrensesnitt.
Organisasjonens bedriftsnettverk 2.
Hypervisor:
- RAM;
- nettverksgrensesnitt.
Virtuell maskin:
— nettverksgrensesnitt;
- RAM;
— USB-over-IP programvaremodul.
Åpne datakanal
Brukerens arbeidsstasjon:
— input-output midler;
- RAM;
- HDD.
Brukerens arbeidsstasjon:
— input-output midler;
- RAM;
- HDD;
- nettverksgrensesnitt.
Organisasjonens bedriftsnettverk 2.
Hypervisor:
— nettverksgrensesnitt;
- RAM;
- HDD.
Virtuell maskin:
— nettverksgrensesnitt;
- RAM;
- HDD.
Sikker kanal for datautveksling
Internett.
Organisasjonens bedriftsnettverk 1.
Brukerens arbeidsstasjon:
- HDD;
- RAM;
- nettverksgrensesnitt.
Internett.
Organisasjonens bedriftsnettverk 2.
Hypervisor:
— nettverksgrensesnitt;
- RAM;
- HDD.
Virtuell maskin:
— nettverksgrensesnitt;
- RAM;
- HDD.
Tidskanal
Brukerens arbeidsstasjon:
— input-output midler;
- RAM;
- systemtimer.
Internett.
Bedriftsnettverk av organisasjon 2,
Hypervisor:
— nettverksgrensesnitt;
- RAM;
- systemtimer.
Virtuell maskin:
- RAM;
- systemtimer.
Kontrollkommando overføringskanal
Brukerens arbeidsstasjon:
— input-output midler;
- RAM.
(Grafisk brukergrensesnitt for CryptoARM-programvare)
Virtuell maskin:
- RAM;
- HDD.
(Automasjonsskript)
Kanal for mottak av arbeidsresultater
Brukerens arbeidsstasjon:
— input-output midler;
- RAM.
(Grafisk brukergrensesnitt for CryptoARM-programvare)
Virtuell maskin:
- RAM;
- HDD.
(Loggfiler av automatiseringsskript)
Sikkerhetstrusler på toppnivå
forklaringer
Forutsetninger som er gjort ved dekomponering av trusler:
- Sterke kryptografiske algoritmer brukes.
- Kryptografiske algoritmer brukes sikkert i de riktige driftsmodusene (f. brukes ikke til å kryptere store datamengder, det tas hensyn til tillatt belastning på nøkkelen osv.).
- Angripere kjenner alle algoritmer, protokoller og offentlige nøkler som brukes.
- Angripere kan lese alle krypterte data.
- Angripere er i stand til å reprodusere alle programvareelementer i systemet.
Dekomponering
U1. Kompromittering av private kryptografiske nøkler.
U2. Kryptering av falske data på vegne av den legitime avsenderen.
U3. Dekryptering av krypterte data av personer som ikke er legitime mottakere av dataene (angripere).
U4. Oppretting av en elektronisk signatur av en legitim underskriver under falske data.
U5. Oppnå et positivt resultat ved å sjekke den elektroniske signaturen til forfalskede data.
U6. Feilaktig aksept av elektroniske dokumenter for utførelse på grunn av problemer med organisering av elektronisk dokumenthåndtering.
U7. Uautorisert tilgang til beskyttede data under behandlingen av dem av CIPF.
U1. Kompromittering av private kryptografiske nøkler
U1.1. Henter den private nøkkelen fra det private nøkkellageret.
U1.2. Innhenting av en privat nøkkel fra objekter i kryptoverktøyets driftsmiljø, der det midlertidig kan ligge.
Forklaringer U1.2.
Objekter som midlertidig kan lagre en privat nøkkel vil omfatte:
- RAM,
- midlertidige filer,
- bytte filer,
- dvalefiler,
- øyeblikksbildefiler av den "varme" tilstanden til virtuelle maskiner, inkludert filer med innholdet i RAM-en til midlertidige virtuelle maskiner.
U1.2.1. Trekke ut private nøkler fra fungerende RAM ved å fryse RAM-moduler, fjerne dem og deretter lese dataene (fryseangrep).
Forklaringer U1.2.1.
Eksempel .
U1.3. Innhenting av en privat nøkkel fra en privat nøkkelutvekslingskanal.
Forklaringer U1.3.
Et eksempel på implementeringen av denne trusselen vil bli gitt .
U1.4. Uautorisert modifikasjon av kryptokjernen, som et resultat av at private nøkler blir kjent for angripere.
U1.5. Kompromittering av en privat nøkkel som følge av bruk av tekniske informasjonslekkasjekanaler (TCIL).
Forklaringer U1.5.
Eksempel .
U1.6. Kompromittering av en privat nøkkel som et resultat av bruk av spesielle tekniske midler (STS) designet for hemmelig henting av informasjon ("bugs").
U1.7. Kompromittering av private nøkler under lagring utenfor CIPF.
Forklaringer U1.7.
For eksempel lagrer en bruker nøkkelmediene sine i en skrivebordsskuff, hvorfra de enkelt kan hentes av angripere.
U2. Kryptering av falske data på vegne av en legitim avsender
forklaringer
Denne trusselen vurderes kun for datakrypteringssystemer med avsenderautentisering. Eksempler på slike ordninger er angitt i standardiseringsanbefalingene . For andre kryptografiske ordninger eksisterer ikke denne trusselen, siden kryptering utføres på mottakerens offentlige nøkler, og de er generelt kjent for angripere.
Dekomponering
U2.1. Kompromittere avsenderens private nøkkel:
U2.1.1. Link: .
U2.2. Substitusjon av inngangsdata i en åpen datautvekslingskanal.
Merknader U2.2.
Eksempler på implementeringen av denne trusselen er gitt nedenfor. и .
U3. Dekryptering av krypterte data av personer som ikke er legitime mottakere av dataene (angripere)
Dekomponering
U3.1. Kompromittering av de private nøklene til mottakeren av krypterte data.
U3.1.1 Link: .
U3.2. Substitusjon av krypterte data i en sikker datautvekslingskanal.
U4. Opprette en elektronisk signatur for en legitim underskriver under falske data
Dekomponering
U4.1. Kompromittering av de private nøklene til den elektroniske signaturen til en legitim underskriver.
U4.1.1 Link: .
U4.2. Substitusjon av signerte data i en åpen datautvekslingskanal.
Merk U4.2.
Eksempler på implementeringen av denne trusselen er gitt nedenfor. и .
U5. Oppnå et positivt resultat ved å sjekke den elektroniske signaturen til forfalskede data
Dekomponering
U5.1. Angripere fanger opp en melding i kanalen for overføring av arbeidsresultater om et negativt resultat av å sjekke en elektronisk signatur og erstatter den med en melding med et positivt resultat.
U5.2. Angripere angriper tilliten til å signere sertifikater (SCRIPT - alle elementer er påkrevd):
U5.2.1. Angripere genererer en offentlig og privat nøkkel for en elektronisk signatur. Hvis systemet bruker elektroniske signaturnøkkelsertifikater, genererer de et elektronisk signatursertifikat som er mest mulig lik sertifikatet til den tiltenkte avsenderen av dataene hvis melding de ønsker å forfalske.
U5.2.2. Angripere gjør uautoriserte endringer i det offentlige nøkkellageret, og gir den offentlige nøkkelen de genererer det nødvendige nivået av tillit og autoritet.
U5.2.3. Angripere signerer falske data med en tidligere generert elektronisk signaturnøkkel og setter den inn i den sikre datautvekslingskanalen.
U5.3. Angripere utfører et angrep ved å bruke utløpte elektroniske signaturnøkler fra en lovlig underskriver (SCRIPT - alle elementer er påkrevd):
U5.3.1. Angripere kompromitterer utløpte (ikke gyldige) private nøkler til den elektroniske signaturen til en legitim avsender.
U5.3.2. Angripere erstatter tiden i tidsoverføringskanalen med tiden da de kompromitterte nøklene fortsatt var gyldige.
U5.3.3. Angripere signerer falske data med en tidligere kompromittert elektronisk signaturnøkkel og injiserer den i den sikre datautvekslingskanalen.
U5.4. Angripere utfører et angrep ved å bruke kompromitterte elektroniske signaturnøkler fra en lovlig underskriver (SCRIPT - alle elementer er påkrevd):
U5.4.1. Angriperen lager en kopi av det offentlige nøkkellageret.
U5.4.2. Angriperne kompromitterer de private nøklene til en av de legitime avsenderne. Han legger merke til kompromisset, trekker tilbake nøklene, og informasjon om tilbakekallingen av nøkkelen blir plassert i det offentlige nøkkellageret.
U5.4.3. Angripere erstatter det offentlige nøkkellageret med et tidligere kopiert.
U5.4.4. Angripere signerer falske data med en tidligere kompromittert elektronisk signaturnøkkel og injiserer den i den sikre datautvekslingskanalen.
U5.5. på grunn av tilstedeværelsen av feil i implementeringen av 2. og 3. trinn av elektronisk signaturverifisering:
Forklaringer U5.5.
Et eksempel på implementeringen av denne trusselen er gitt .
U5.5.1. Kontrollerer tillit til et elektronisk signaturnøkkelsertifikat bare ved tilstedeværelse av tillit i sertifikatet det er signert med, uten CRL- eller OCSP-kontroller.
Forklaringer U5.5.1.
Implementeringseksempel .
U5.5.2. Når du bygger en tillitskjede for et sertifikat, blir ikke myndighetene for utstedelse av sertifikater analysert
Forklaringer U5.5.2.
Et eksempel på et angrep mot SSL/TLS-sertifikater.
Angriperne kjøpte et legitimt sertifikat for e-posten deres. De laget deretter et falsk nettstedsertifikat og signerte det med sertifikatet sitt. Hvis legitimasjonen ikke kontrolleres, vil den vise seg å være korrekt når du sjekker tillitskjeden, og følgelig vil det falske sertifikatet også være riktig.
U5.5.3. Når du bygger en sertifikattillitskjede, blir ikke mellomliggende sertifikater sjekket for tilbakekall.
U5.5.4. CRL-er oppdateres sjeldnere enn de utstedes av sertifiseringsmyndigheten.
U5.5.5. Beslutningen om å stole på en elektronisk signatur tas før et OCSP-svar om statusen til sertifikatet er mottatt, sendt på en forespørsel gjort senere enn tidspunktet signaturen ble generert eller tidligere enn neste CRL etter at signaturen ble generert.
Forklaringer U5.5.5.
I regelverket til de fleste CAer anses tidspunktet for tilbakekall av sertifikat å være tidspunktet for utstedelse av nærmeste CRL som inneholder informasjon om tilbakekall av sertifikat.
U5.5.6. Når du mottar signert data, er sertifikatet som tilhører avsenderen ikke sjekket.
Forklaringer U5.5.6.
Eksempel på angrep. I forhold til SSL-sertifikater: korrespondansen til den oppringte serveradressen med verdien av CN-feltet i sertifikatet kan ikke kontrolleres.
Eksempel på angrep. Angripere kompromitterte de elektroniske signaturnøklene til en av betalingssystemets deltakere. Etter det hacket de seg inn i nettverket til en annen deltaker og sendte på hans vegne betalingsdokumenter signert med kompromitterte nøkler til oppgjørsserveren til betalingssystemet. Hvis serveren kun analyserer tillit og ikke sjekker for samsvar, vil falske dokumenter anses som legitime.
U6. Feilaktig aksept av elektroniske dokumenter for utførelse på grunn av problemer med organisering av elektronisk dokumenthåndtering.
Dekomponering
U6.1. Den mottakende parten oppdager ikke duplisering av mottatte dokumenter.
Forklaringer U6.1.
Eksempel på angrep. Angripere kan avskjære et dokument som sendes til en mottaker, selv om det er kryptografisk beskyttet, og deretter gjentatte ganger sende det over en sikker dataoverføringskanal. Hvis mottakeren ikke identifiserer duplikater, vil alle mottatte dokumenter bli oppfattet og behandlet som ulike dokumenter.
U7. Uautorisert tilgang til beskyttede data under behandlingen av dem av CIPF
Dekomponering
U7.1. på grunn av informasjonslekkasje via sidekanaler (sidekanalangrep).
Forklaringer U7.1.
Eksempel .
U7.2. på grunn av nøytralisering av beskyttelse mot uautorisert tilgang til informasjon behandlet på CIPF:
U7.2.1. Drift av CIPF i strid med kravene beskrevet i dokumentasjonen for CIPF.
U7.2.2. , utført på grunn av tilstedeværelsen av sårbarheter i:
U7.2.2.1. beskyttelsesmiddel mot uautorisert tilgang.
U7.2.2.2. CIPF selv.
U7.2.2.3. operasjonsmiljøet til kryptoverktøyet.
Eksempler på angrep
Scenariene som er diskutert nedenfor inneholder åpenbart informasjonssikkerhetsfeil og tjener kun til å illustrere mulige angrep.
Scenario 1. Et eksempel på implementering av trusler U2.2 og U4.2.
Beskrivelse av objektet
AWS KBR-programvaren og CIPF SCAD Signature er installert på en fysisk datamaskin som ikke er koblet til datanettverket. FKN vdToken brukes som nøkkelbærer i modusen for arbeid med en ikke-flyttbar nøkkel.
Oppgjørsforskriften forutsetter at oppgjørsspesialisten fra sin arbeidsdatamaskin laster ned elektroniske meldinger i klartekst (skjemaet til den gamle KBR-arbeidsstasjonen) fra en spesiell sikker filserver, for så å skrive dem inn på en overførbar USB-flash-stasjon og overføre dem til KBR-arbeidsstasjonen, hvor de er kryptert og skilter. Etter dette overfører spesialisten sikre elektroniske meldinger til det fremmedgjorte mediet, og skriver dem deretter gjennom arbeidsdatamaskinen til en filserver, hvorfra de går til UTA og deretter til betalingssystemet til Bank of Russia.
I dette tilfellet vil kanalene for utveksling av åpne og beskyttede data inkludere: en filserver, en spesialists arbeidsdatamaskin og fremmedgjorte medier.
angrep
Uautoriserte angripere installerer et fjernkontrollsystem på en spesialists arbeidsdatamaskin og, når betalingsoppdrag (elektroniske meldinger) skrives til et overførbart medium, erstatter innholdet i en av dem i klartekst. Spesialisten overfører betalingsoppdrag til den automatiserte KBR-arbeidsplassen, signerer og krypterer dem uten å legge merke til erstatningen (for eksempel på grunn av et stort antall betalingsordrer på en flytur, tretthet, etc.). Etter dette kommer den falske betalingsordren, etter å ha gått gjennom den teknologiske kjeden, inn i betalingssystemet til Bank of Russia.
Scenario 2. Et eksempel på implementering av trusler U2.2 og U4.2.
Beskrivelse av objektet
En datamaskin med installert arbeidsstasjon KBR, SCAD Signature og en tilkoblet nøkkelbærer FKN vdToken opererer i et dedikert rom uten tilgang fra personell.
Beregningsspesialisten kobler til CBD-arbeidsstasjonen i fjerntilgangsmodus via RDP-protokollen.
angrep
Angripere avskjærer detaljene, ved hjelp av hvilke beregningsspesialisten kobler til og jobber med CBD-arbeidsstasjonen (for eksempel gjennom ondsinnet kode på datamaskinen hans). Deretter kobler de seg på hans vegne og sender en falsk betalingsordre til Bank of Russias betalingssystem.
Scenario 3. Eksempel på trusselimplementering U1.3.
Beskrivelse av objektet
La oss vurdere et av de hypotetiske alternativene for å implementere ABS-KBR-integrasjonsmodulene for en ny ordning (AWS KBR-N), der den elektroniske signaturen til utgående dokumenter forekommer på ABS-siden. I dette tilfellet vil vi anta at ABS-en opererer på grunnlag av et operativsystem som ikke støttes av CIPF SKAD-signaturen, og følgelig overføres den kryptografiske funksjonaliteten til en separat virtuell maskin - "ABS-KBR"-integrasjonen modul.
Et vanlig USB-token som opererer i gjenfinnbar nøkkelmodus brukes som nøkkelbærer. Når du koblet nøkkelmediet til hypervisoren, viste det seg at det ikke var noen ledige USB-porter i systemet, så det ble besluttet å koble til USB-tokenet via en nettverks-USB-hub, og installere en USB-over-IP-klient på den virtuelle maskin, som vil kommunisere med huben.
angrep
Angriperne fanget opp den private nøkkelen til den elektroniske signaturen fra kommunikasjonskanalen mellom USB-huben og hypervisoren (data ble overført i klartekst). Ved å ha den private nøkkelen genererte angriperne en falsk betalingsordre, signerte den med en elektronisk signatur og sendte den til KBR-Ns automatiserte arbeidsplass for utførelse.
Scenario 4. Et eksempel på implementering av trusler U5.5.
Beskrivelse av objektet
La oss vurdere den samme kretsen som i forrige scenario. Vi vil anta at elektroniske meldinger som kommer fra KBR-N-arbeidsstasjonen havner i …SHAREIn-mappen, og de som sendes til KBR-N-arbeidsstasjonen og videre til betalingssystemet til Bank of Russia går til …SHAREout.
Vi vil også anta at når integrasjonsmodulen implementeres, oppdateres lister over tilbakekalte sertifikater bare når kryptografiske nøkler utstedes på nytt, og også at elektroniske meldinger mottatt i …SHAREIn-mappen kun sjekkes for integritetskontroll og tillitskontroll i den offentlige nøkkelen til elektronisk signatur.
angrep
Angriperne, ved å bruke nøklene som ble stjålet i det forrige scenariet, signerte en falsk betalingsordre som inneholdt informasjon om mottak av penger på kontoen til den uredelige klienten og introduserte den i den sikre datautvekslingskanalen. Siden det ikke er noen bekreftelse på at betalingsordren ble signert av Bank of Russia, er den akseptert for utførelse.
Kilde: www.habr.com