Länkar till andra delar av studien
- (Är du här)
Den här artikeln kompletterar serien av publikationer som ägnas åt att säkerställa informationssäkerhet för bankbetalningar som inte är kontanter. Här kommer vi att titta på de typiska hotmodeller som hänvisas till i :
- .
- .
- .
- .
HABRO-VARNING!!! Kära Khabrovites, detta är inget underhållande inlägg.
De 40+ sidorna med material som är gömda under snittet är avsedda att hjälp med arbete eller studier personer som är specialiserade på bank- eller informationssäkerhet. Dessa material är slutprodukten av forskningen och är skrivna i en torr, formell ton. I huvudsak är dessa tomrum för interna informationssäkerhetsdokument.Tja, traditionella - "användning av information från artikeln för olagliga ändamål är straffbart enligt lag". Produktiv läsning!
Information till läsare som blir bekanta med studien från och med denna publikation.
Vad handlar studien om?
Du läser en guide för en specialist som ansvarar för att säkerställa informationssäkerhet för betalningar i en bank.
Logik i presentationen
I början i и en beskrivning av skyddsobjektet ges. Sedan i beskriver hur man bygger ett säkerhetssystem och talar om behovet av att skapa en hotmodell. I talar om vilka hotmodeller som finns och hur de bildas. I и En analys av verkliga attacker tillhandahålls. и innehålla en beskrivning av hotmodellen, byggd med hänsyn till information från alla tidigare delar.
TYPISK HOTMODEL. NÄTVERKSANSLUTNING
Skyddsobjekt för vilket hotmodellen (scope) tillämpas
Skyddsobjektet är data som överförs via en nätverksanslutning som fungerar i datanätverk byggda på basis av TCP/IP-stacken.
Arkitektur
Beskrivning av arkitektoniska element:
- "Slutnoder" — Noder som utbyter skyddad information.
- "Mellanliggande noder" — delar av ett dataöverföringsnätverk: routrar, switchar, åtkomstservrar, proxyservrar och annan utrustning — genom vilken nätverksanslutningstrafik överförs. I allmänhet kan en nätverksanslutning fungera utan mellannoder (direkt mellan ändnoder).
Säkerhetshot på högsta nivå
Sönderfall
U1. Obehörig åtkomst till överförda data.
U2. Otillåten ändring av överförda data.
U3. Intrång i upphovsrätten till överförda data.
U1. Obehörig åtkomst till överförda data
Sönderfall
U1.1. <…>, utförs vid de sista eller mellanliggande noderna:
U1.1.1. <…> genom att läsa data medan den finns i värdlagringsenheterna:
U1.1.1.1. <…> i RAM.
Förklaringar till U1.1.1.1.
Till exempel under databehandling av värdens nätverksstack.
U1.1.1.2. <…> i icke-flyktigt minne.
Förklaringar till U1.1.1.2.
Till exempel vid lagring av överförda data i en cache, temporära filer eller swap-filer.
U1.2. <…>, utförs på tredjepartsnoder i datanätverket:
U1.2.1. <…> genom metoden att fånga alla paket som anländer till värdens nätverksgränssnitt:
Förklaringar till U1.2.1.
Infångning av alla paket utförs genom att växla nätverkskortet till promiskuöst läge (promiskuöst läge för trådbundna adaptrar eller monitorläge för wi-fi-adaptrar).
U1.2.2. <…> genom att utföra man-in-the-middle (MiTM)-attacker, men utan att modifiera de överförda data (exklusive nätverksprotokolltjänstdata).
U1.2.2.1. Länk: .
U1.3. <…>, utförs på grund av informationsläckage genom tekniska kanaler (TKUI) från fysiska noder eller kommunikationslinjer.
U1.4. <…>, utförs genom att installera speciella tekniska medel (STS) på änd- eller mellannoder, avsedda för hemlig insamling av information.
U2. Otillåten ändring av överförda data
Sönderfall
U2.1. <…>, utförs vid de sista eller mellanliggande noderna:
U2.1.1. <…> genom att läsa och göra ändringar i data medan den finns i nodernas lagringsenheter:
U2.1.1.1. <…> i RAM:
U2.1.1.2. <…> i icke-flyktigt minne:
U2.2. <…>, utförd på tredjepartsnoder i dataöverföringsnätverket:
U2.2.1. <…> genom att utföra man-in-the-middle-attacker (MiTM) och omdirigera trafik till angriparnas nod:
U2.2.1.1. Fysisk anslutning av angriparnas utrustning gör att en nätverksanslutning bryts.
U2.2.1.2. Utföra attacker på nätverksprotokoll:
U2.2.1.2.1. <…> hantering av virtuella lokala nätverk (VLAN):
U2.2.1.2.1.1. .
U2.2.1.2.1.2. Otillåten ändring av VLAN-inställningar på switchar eller routrar.
U2.2.1.2.2. <…> trafikdirigering:
U2.2.1.2.2.1. Otillåten modifiering av statiska routningstabeller för routrar.
U2.2.1.2.2.2. Meddelande om falska rutter av angripare genom dynamiska routingprotokoll.
U2.2.1.2.3. <…> automatisk konfiguration:
U2.2.1.2.3.1. .
U2.2.1.2.3.2. .
U2.2.1.2.4. <…> adressering och namnupplösning:
U2.2.1.2.4.1. .
U2.2.1.2.4.2. .
U2.2.1.2.4.3. Göra obehöriga ändringar i lokala värdnamnsfiler (värdar, lmhosts, etc.)
U3. Intrång i upphovsrätten för överförda data
Sönderfall
U3.1. Neutralisering av mekanismer för att bestämma författarskapet av information genom att ange falsk information om författaren eller datakällan:
U3.1.1. Ändra information om författaren som finns i den överförda informationen.
U3.1.1.1. Neutralisering av kryptografiskt skydd av integriteten och upphovsrätten till överförda data:
U3.1.1.1.1. Länk: .
U3.1.1.2. Neutralisering av upphovsrättsligt skydd för överförda data, implementerad med engångsbekräftelsekoder:
U3.1.1.2.1. .
U3.1.2. Ändra information om källan till överförd information:
U3.1.2.1. .
U3.1.2.2. .
TYPISK HOTMODEL. INFORMATIONSSYSTEM BYGGT PÅ BAS AV KLIENT-SERVER-ARKITEKTUR
Skyddsobjekt för vilket hotmodellen (scope) tillämpas
Skyddsobjektet är ett informationssystem byggt på en klient-server-arkitektur.
Arkitektur
Beskrivning av arkitektoniska element:
- "Klient" – en enhet på vilken klientdelen av informationssystemet fungerar.
- "Server" – en enhet på vilken serverdelen av informationssystemet fungerar.
- "Datalagring" — En del av ett informationssystems serverinfrastruktur, utformad för att lagra data som behandlas av informationssystemet.
- "Nätverksanslutning" — en kanal för informationsutbyte mellan klienten och servern som går genom datanätverket. En mer detaljerad beskrivning av elementmodellen ges i .
Begränsningar
Vid modellering av ett objekt sätts följande begränsningar:
- Användaren interagerar med informationssystemet inom begränsade tidsperioder, så kallade arbetssessioner.
- I början av varje arbetssession identifieras, autentiseras och auktoriseras användaren.
- All skyddad information lagras på serverdelen av informationssystemet.
Säkerhetshot på högsta nivå
Sönderfall
U1. Utföra obehöriga handlingar av angripare på uppdrag av en legitim användare.
U2. Otillåten ändring av skyddad information under dess bearbetning av serverdelen av informationssystemet.
U1. Utföra obehöriga handlingar av angripare på uppdrag av en legitim användare
förklaringar
Vanligtvis i informationssystem är åtgärder korrelerade med användaren som utförde dem med hjälp av:
- systemdriftsloggar (loggar).
- speciella attribut för dataobjekt som innehåller information om användaren som skapade eller modifierade dem.
I förhållande till en arbetssession kan detta hot delas upp i:
- <…> utförs under användarsessionen.
- <…> körs utanför användarsessionen.
En användarsession kan initieras:
- Av användaren själv.
- Brottslingar.
I detta skede kommer den mellanliggande nedbrytningen av detta hot att se ut så här:
U1.1. Otillåtna åtgärder utfördes under en användarsession:
U1.1.1. <…> installerat av den attackerade användaren.
U1.1.2. <…> installerat av angripare.
U1.2. Otillåtna åtgärder utfördes utanför användarsessionen.
Ur synvinkel av informationsinfrastrukturobjekt som kan påverkas av angripare, kommer nedbrytningen av mellanliggande hot att se ut så här:
element
Hotnedbrytning
U1.1.1.
U1.1.2.
U1.2.
kund
U1.1.1.1.
U1.1.2.1.
Nätverksanslutning
U1.1.1.2.
Server
U1.2.1.
Sönderfall
U1.1. Otillåtna åtgärder utfördes under en användarsession:
U1.1.1. <…> installerat av den attackerade användaren:
U1.1.1.1. Angriparna agerade oberoende av klienten:
U1.1.1.1.1 Angriparna använde standardverktyg för åtkomst till informationssystem:
U1.1.1.1.1.1. Angriparna använde klientens fysiska inmatnings-/utmatningsmedel (tangentbord, mus, bildskärm eller pekskärm på en mobil enhet):
U1.1.1.1.1.1.1. Angriparna opererade under perioder när sessionen var aktiv, I/O-faciliteter var tillgängliga och användaren inte var närvarande.
У1.1.1.1.1.2. Angriparna använde fjärradministrationsverktyg (standard eller tillhandahållna av skadlig kod) för att hantera klienten:
U1.1.1.1.1.2.1. Angriparna opererade under perioder när sessionen var aktiv, I/O-faciliteter var tillgängliga och användaren inte var närvarande.
У1.1.1.1.1.2.2. Angriparna använde fjärradministrationsverktyg, vars funktion är osynlig för den attackerade användaren.
U1.1.1.2. Angriparna ersatte data i nätverksanslutningen mellan klienten och servern och modifierade den på ett sådant sätt att den uppfattades som handlingarna av en legitim användare:
U1.1.1.2.1. Länk: .
U1.1.1.3. Angriparna tvingade användaren att utföra de åtgärder de angav med hjälp av social ingenjörskonst.
У1.1.2 <…> installerat av angripare:
U1.1.2.1. Angriparna agerade från klienten (И):
U1.1.2.1.1. Angriparna neutraliserade informationssystemets åtkomstkontrollsystem:
U1.1.2.1.1.1. Länk: .
У1.1.2.1.2. Angriparna använde standardverktyg för åtkomst till informationssystem
U1.1.2.2. Angriparna opererade från andra noder i datanätverket, från vilka en nätverksanslutning till servern kunde upprättas (И):
U1.1.2.2.1. Angriparna neutraliserade informationssystemets åtkomstkontrollsystem:
U1.1.2.2.1.1. Länk: .
U1.1.2.2.2. Angriparna använde icke-standardiserade sätt att komma åt informationssystemet.
Förklaringar U1.1.2.2.2.
Angriparna kan installera en standardklient för informationssystemet på en tredjepartsnod eller kan använda icke-standardiserad programvara som implementerar standardutbytesprotokoll mellan klienten och servern.
U1.2 Otillåtna åtgärder utfördes utanför användarsessionen.
U1.2.1 Angripare utförde obehöriga åtgärder och gjorde sedan obehöriga ändringar i informationssystemets driftloggar eller speciella attribut för dataobjekt, vilket indikerar att de åtgärder de utförde utfördes av en legitim användare.
U2. Otillåten ändring av skyddad information under dess bearbetning av serverdelen av informationssystemet
Sönderfall
U2.1. Angripare modifierar skyddad information med hjälp av standardverktyg för informationssystem och gör detta på uppdrag av en legitim användare.
U2.1.1. Länk: .
U2.2. Angripare modifierar skyddad information genom att använda dataåtkomstmekanismer som inte tillhandahålls av informationssystemets normala drift.
U2.2.1. Angripare ändrar filer som innehåller skyddad information:
U2.2.1.1. <…>, med hjälp av de filhanteringsmekanismer som tillhandahålls av operativsystemet.
U2.2.1.2. <…> genom att provocera fram återställning av filer från en obehörig modifierad säkerhetskopia.
U2.2.2. Angripare ändrar skyddad information som lagras i databasen (И):
U2.2.2.1. Angripare neutraliserar DBMS-åtkomstkontrollsystemet:
U2.2.2.1.1. Länk: .
U2.2.2.2. Angripare ändrar information med hjälp av vanliga DBMS-gränssnitt för att komma åt data.
U2.3. Angripare modifierar skyddad information genom otillåten modifiering av operativa algoritmer för programvaran som bearbetar den.
U2.3.1. Källkoden för programvaran kan ändras.
U2.3.1. Programvarans maskinkod kan ändras.
U2.4. Angripare modifierar skyddad information genom att utnyttja sårbarheter i informationssystemprogramvara.
U2.5. Angripare ändrar skyddad information när den överförs mellan komponenter i serverdelen av informationssystemet (till exempel en databasserver och en applikationsserver):
U2.5.1. Länk: .
TYPISK HOTMODEL. ÅTKOMSTKONTROLLSYSTEM
Skyddsobjekt för vilket hotmodellen (scope) tillämpas
Skyddsobjektet för vilket denna hotmodell tillämpas motsvarar hotmodellens skyddsobjekt: ”Typisk hotmodell. Ett informationssystem byggt på en klient-server-arkitektur.”
I denna hotmodell betyder ett användarkontrollsystem en komponent i ett informationssystem som implementerar följande funktioner:
- Användaridentifikation.
- Användarautentisering.
- Användarbehörigheter.
- Loggar användaråtgärder.
Säkerhetshot på högsta nivå
Sönderfall
U1. Otillåten etablering av en session på uppdrag av en legitim användare.
U2. Otillåten ökning av användarrättigheter i ett informationssystem.
U1. Otillåten etablering av en session på uppdrag av en legitim användare
förklaringar
Nedbrytningen av detta hot beror i allmänhet på vilken typ av användaridentifiering och autentiseringssystem som används.
I den här modellen kommer endast ett användaridentifikations- och autentiseringssystem som använder textinloggning och lösenord att beaktas. I det här fallet kommer vi att anta att användarinloggningen är allmänt tillgänglig information som är känd för angripare.
Sönderfall
U1.1. <…> på grund av kompromiss med referenser:
U1.1.1. Angriparna äventyrade användarens autentiseringsuppgifter när de lagrade dem.
Förklaringar U1.1.1.
Till exempel kan autentiseringsuppgifterna skrivas på en lapp som sitter fast på monitorn.
U1.1.2. Användaren skickade av misstag eller uppsåtlig åtkomstinformation till angriparna.
U1.1.2.1. Användaren sa inloggningsuppgifterna högt när de gick in.
U1.1.2.2. Användaren delade avsiktligt sina autentiseringsuppgifter:
U1.1.2.2.1. <…> till arbetskollegor.
Förklaringar U1.1.2.2.1.
Till exempel så att de kan byta ut det vid sjukdom.
U1.1.2.2.2. <…> till arbetsgivarens entreprenörer som utför arbete på informationsinfrastrukturobjekt.
U1.1.2.2.3. <…> till tredje part.
Förklaringar U1.1.2.2.3.
Ett men inte det enda alternativet för att implementera detta hot är att angripare använder sociala ingenjörsmetoder.
U1.1.3. Angriparna valde inloggningsuppgifter med hjälp av brute force-metoder:
U1.1.3.1. <…> med standardåtkomstmekanismer.
U1.1.3.2. <…> använder tidigare avlyssnade koder (till exempel lösenordshaschar) för att lagra autentiseringsuppgifter.
U1.1.4. Angriparna använde skadlig kod för att fånga upp användaruppgifter.
U1.1.5. Angriparna extraherade autentiseringsuppgifter från nätverksanslutningen mellan klienten och servern:
U1.1.5.1. Länk: .
U1.1.6. Angriparna extraherade referenser från register över arbetsövervakningssystem:
U1.1.6.1. <...> videoövervakningssystem (om tangenttryckningar på tangentbordet registrerades under drift).
U1.1.6.2. <…> system för övervakning av anställdas handlingar vid datorn
Förklaringar U1.1.6.2.
Ett exempel på ett sådant system är .
U1.1.7. Angripare har äventyrat användaruppgifter på grund av brister i överföringsprocessen.
Förklaringar U1.1.7.
Till exempel att skicka lösenord i klartext via e-post.
U1.1.8. Angripare fick inloggningsuppgifter genom att övervaka en användares session med hjälp av fjärradministrationssystem.
U1.1.9. Angriparna fick inloggningsuppgifter som ett resultat av deras läcka via tekniska kanaler (TCUI):
U1.1.9.1. Angriparna observerade hur användaren skrev in autentiseringsuppgifter från tangentbordet:
U1.1.9.1.1 Angriparna befann sig i närheten av användaren och såg inmatningen av referenser med egna ögon.
Förklaringar U1.1.9.1.1
Sådana fall inkluderar handlingar från arbetskollegor eller fallet när användarens tangentbord är synligt för besökare i organisationen.
U1.1.9.1.2 Angriparna använde ytterligare tekniska medel, såsom en kikare eller ett obemannat flygfordon, och såg inträde av legitimationsuppgifter genom ett fönster.
U1.1.9.2. Angriparna hämtade referenser från radiokommunikation mellan tangentbordet och datorsystemenheten när de var anslutna via ett radiogränssnitt (till exempel Bluetooth).
U1.1.9.3. Angriparna snappade upp referenser genom att läcka dem genom kanalen för falsk elektromagnetisk strålning och störningar (PEMIN).
Förklaringar U1.1.9.3.
Exempel på attacker и .
U1.1.9.4. Angriparen fångade inmatningen av referenser från tangentbordet med hjälp av speciella tekniska medel (STS) utformade för att i hemlighet skaffa information.
Förklaringar U1.1.9.4.
Примеры .
U1.1.9.5. Angriparna fångade inmatningen av autentiseringsuppgifter från tangentbordet med hjälp av
analys av Wi-Fi-signalen modulerad av användarens tangenttryckningsprocess.
Förklaringar U1.1.9.5.
Exempel .
U1.1.9.6. Angriparna avlyssnade inmatningen av inloggningsuppgifter från tangentbordet genom att analysera ljuden av tangenttryckningar.
Förklaringar U1.1.9.6.
Exempel .
U1.1.9.7. Angriparna fångade inmatningen av referenser från tangentbordet på en mobil enhet genom att analysera accelerometeravläsningar.
Förklaringar U1.1.9.7.
Exempel .
U1.1.10. <…>, tidigare sparad på klienten.
Förklaringar U1.1.10.
En användare kan till exempel spara inloggning och lösenord i webbläsaren för att komma åt en specifik webbplats.
U1.1.11. Angripare har äventyrat sina autentiseringsuppgifter på grund av brister i processen för att återkalla användaråtkomst.
Förklaringar U1.1.11.
Till exempel, efter att en användare avskedats, förblev hans konton oblockerade.
U1.2. <…> genom att utnyttja sårbarheter i åtkomstkontrollsystemet.
U2. Otillåten höjning av användarrättigheter i ett informationssystem
Sönderfall
U2.1 <…> genom att göra otillåtna ändringar i data som innehåller information om användarrättigheter.
U2.2 <…> genom användning av sårbarheter i passersystemet.
U2.3. <…> på grund av brister i hanteringsprocessen för användaråtkomst.
Förklaringar U2.3.
Exempel 1. En användare fick mer åtkomst för arbete än han krävde av affärsskäl.
Exempel 2: Efter att en användare flyttats till en annan position återkallades inte tidigare beviljade åtkomsträttigheter.
TYPISK HOTMODEL. INTEGRATIONSMODUL
Skyddsobjekt för vilket hotmodellen (scope) tillämpas
En integrationsmodul är en uppsättning informationsinfrastrukturobjekt utformade för att organisera utbytet av information mellan informationssystem.
Med tanke på att det i företagsnätverk inte alltid är möjligt att entydigt separera ett informationssystem från ett annat, kan integrationsmodulen också betraktas som en sammanbindande länk mellan komponenter inom ett informationssystem.
Arkitektur
Det generaliserade diagrammet för integrationsmodulen ser ut så här:
Beskrivning av arkitektoniska element:
- "Exchange Server (SO)" – en nod / tjänst / komponent i ett informationssystem som utför funktionen att utbyta data med ett annat informationssystem.
- "Medlare" – en nod/tjänst utformad för att organisera interaktion mellan informationssystem, men inte en del av dem.
Exempel "Förmedlarna" det kan finnas e-posttjänster, företagsservicebussar (företagsservicebuss/SoA-arkitektur), filservrar från tredje part, etc. I allmänhet får integrationsmodulen inte innehålla "Intermediärer". - "Databehandlingsprogram" – en uppsättning program som implementerar datautbytesprotokoll och formatkonvertering.
Till exempel att konvertera data från UFEBS-formatet till ABS-formatet, ändra meddelandestatus under överföring, etc. - "Nätverksanslutning" motsvarar objektet som beskrivs i standardmodellen för "Nätverksanslutning". Vissa av nätverksanslutningarna som visas i diagrammet ovan kanske inte existerar.
Exempel på integrationsmoduler
Schema 1. Integrering av ABS och AWS KBR via en filserver från tredje part
För att utföra betalningar laddar en auktoriserad bankanställd ned elektroniska betalningsdokument från kärnbankssystemet och sparar dem till en fil (i sitt eget format, till exempel en SQL-dump) i en nätverksmapp (...SHARE) på en filserver. Sedan konverteras den här filen med hjälp av ett omvandlingsskript till en uppsättning filer i UFEBS-formatet, som sedan läses av CBD-arbetsstationen.
Efter detta krypterar och signerar den auktoriserade medarbetaren - användaren av den automatiserade arbetsplatsen KBR - de mottagna filerna och skickar dem till Rysslands Banks betalningssystem.
När betalningar tas emot från Rysslands centralbank dekrypterar KBR:s automatiserade arbetsplats dem och kontrollerar den elektroniska signaturen, varefter den registrerar dem i form av en uppsättning filer i UFEBS-formatet på en filserver. Innan betalningsdokument importeras till ABS, konverteras de med hjälp av ett omvandlingsskript från UFEBS-formatet till ABS-formatet.
Vi kommer att anta att i detta schema arbetar ABS på en fysisk server, KBR-arbetsstationen arbetar på en dedikerad dator och omvandlingsskriptet körs på en filserver.
Överensstämmelse mellan objekten i det övervägda diagrammet och elementen i integrationsmodulmodellen:
"Exchange server från ABS-sidan" – ABS-server.
"Utbytesserver från AWS KBR-sidan" – datorarbetsstation KBR.
"Medlare" – filserver från tredje part.
"Databehandlingsprogram" – omvandlarskript.
Schema 2. Integration av ABS och AWS KBR vid placering av en delad nätverksmapp med betalningar på AWS KBR
Allt liknar Schema 1, men en separat filserver används inte, istället placeras en nätverksmapp (...DELA) med elektroniska betalningsdokument på en dator med en arbetsstation av CBD. Omvandlingsskriptet fungerar även på CBD-arbetsstationen.
Överensstämmelse mellan objekten i det övervägda diagrammet och elementen i integrationsmodulmodellen:
Liknar Schema 1, men "Medlare" inte använd.
Schema 3. Integration av ABS och automatiserad arbetsplats KBR-N via IBM WebSphera MQ och signering av elektroniska dokument "på ABS-sidan"
ABS fungerar på en plattform som inte stöds av CIPF SCAD Signature. Signering av utgående elektroniska dokument sker på en speciell elektronisk signaturserver (ES Server). Samma server kontrollerar den elektroniska signaturen på dokument som kommer in från Rysslands centralbank.
ABS laddar upp en fil med betalningsdokument i sitt eget format till ES-servern.
ES-servern, med hjälp av ett omvandlingsskript, konverterar filen till elektroniska meddelanden i UFEBS-format, varefter de elektroniska meddelandena signeras och överförs till IBM WebSphere MQ.
KBR-N-arbetsstationen får åtkomst till IBM WebSphere MQ och tar emot signerade betalningsmeddelanden därifrån, varefter en auktoriserad anställd - en användare av KBR-arbetsstationen - krypterar dem och skickar dem till Rysslands centralbanks betalningssystem.
När betalningar tas emot från Rysslands centralbank dekrypterar den automatiserade arbetsplatsen KBR-N dem och verifierar den elektroniska signaturen. Framgångsrikt behandlade betalningar i form av dekrypterade och signerade elektroniska meddelanden i UFEBS-formatet överförs till IBM WebSphere MQ, varifrån de tas emot av den elektroniska signaturservern.
Den elektroniska signaturservern verifierar den elektroniska signaturen för mottagna betalningar och sparar dem i en fil i ABS-format. Efter detta laddar den auktoriserade medarbetaren - ABS-användaren - upp den resulterande filen till ABS på föreskrivet sätt.
Överensstämmelse mellan objekten i det övervägda diagrammet och elementen i integrationsmodulmodellen:
"Exchange server från ABS-sidan" – ABS-server.
"Utbytesserver från AWS KBR-sidan" — datorarbetsstation KBR.
"Medlare" – ES-server och IBM WebSphere MQ.
"Databehandlingsprogram" – skriptomvandlare, CIPF SCAD-signatur på ES-servern.
Schema 4. Integration av RBS-servern och kärnbankssystemet via API:et som tillhandahålls av en dedikerad växlingsserver
Vi kommer att anta att banken använder flera fjärrbanksystem (RBS):
- "Internet Client-Bank" för privatpersoner (IKB FL);
- "Internet Client-Bank" för juridiska personer (IKB LE).
För att säkerställa informationssäkerheten sker all interaktion mellan ABS och fjärrbanksystem genom en dedikerad växelserver som arbetar inom ramen för ABS informationssystem.
Därefter kommer vi att överväga processen för interaktion mellan RBS-systemet för IKB LE och ABS.
RBS-servern måste, efter att ha mottagit en vederbörligen certifierad betalningsorder från klienten, skapa ett motsvarande dokument i ABS baserat på det. För att göra detta, med hjälp av API:t, överför den information till utbytesservern, som i sin tur matar in data i ABS.
När kundens kontosaldon ändras genererar ABS elektroniska meddelanden, som överförs till fjärrbankservern med hjälp av växlingsservern.
Överensstämmelse mellan objekten i det övervägda diagrammet och elementen i integrationsmodulmodellen:
"Exchange-server från RBS-sidan" – RBS-server för IKB YUL.
"Exchange server från ABS-sidan" – utbytesserver.
"Medlare" - saknas.
"Databehandlingsprogram" – RBS Server-komponenter som ansvarar för att använda Exchange Server API, Exchange Server-komponenter som ansvarar för att använda core Banking API.
Säkerhetshot på högsta nivå
Sönderfall
U1. Injektion av falsk information av angripare genom integrationsmodulen.
U1. Injektion av falsk information av angripare genom integrationsmodulen
Sönderfall
U1.1. Obehörig ändring av legitima data när de överförs via nätverksanslutningar:
U1.1.1 Länk: .
U1.2. Överföring av falsk data via kommunikationskanaler på uppdrag av en legitim utbytesdeltagare:
U1.1.2 Länk: .
U1.3. Otillåten modifiering av legitim data under dess behandling på Exchange-servrar eller mellanhanden:
U1.3.1. Länk: .
U1.4. Skapande av falsk data på Exchange-servrarna eller mellanhanden på uppdrag av en legitim utbytesdeltagare:
U1.4.1. Länk:
U1.5. Otillåten ändring av data när den behandlas med databehandlingsprogramvara:
U1.5.1. <…> på grund av att angripare gör otillåtna ändringar av inställningarna (konfigurationen) av databehandlingsprogramvaran.
U1.5.2. <…> på grund av angripare som gör otillåtna ändringar i körbara filer i databehandlingsprogram.
U1.5.3. <…> på grund av den interaktiva kontrollen av databehandlingsprogramvaran av angripare.
TYPISK HOTMODEL. KRYPTOGRAFISKT INFORMATIONSSKYDDSSYSTEM
Skyddsobjekt för vilket hotmodellen (scope) tillämpas
Skyddsobjektet är ett kryptografiskt informationsskyddssystem som används för att säkerställa informationssystemets säkerhet.
Arkitektur
Grunden för alla informationssystem är tillämpningsprogram som implementerar dess målfunktionalitet.
Kryptografiskt skydd implementeras vanligtvis genom att anropa kryptografiska primitiver från applikationsmjukvarans affärslogik, som finns i specialiserade bibliotek - kryptokärnor.
Kryptografiska primitiver inkluderar lågnivå kryptografiska funktioner, såsom:
- kryptera/dekryptera ett datablock;
- skapa/verifiera en elektronisk signatur av ett datablock;
- beräkna hashfunktionen för datablocket;
- generera / ladda / ladda upp nyckelinformation;
- etc.
Affärslogiken i applikationsmjukvaran implementerar funktionalitet på högre nivå med hjälp av kryptografiska primitiver:
- kryptera filen med hjälp av de valda mottagarnas nycklar;
- upprätta en säker nätverksanslutning;
- informera om resultatet av att kontrollera den elektroniska signaturen;
- och så vidare.
Interaktionen mellan affärslogik och kryptokärna kan utföras:
- direkt, genom affärslogik som anropar kryptografiska primitiver från dynamiska bibliotek i kryptokärnan (.DLL för Windows, .SO för Linux);
- direkt, genom kryptografiska gränssnitt - omslag, till exempel MS Crypto API, Java Cryptography Architecture, PKCS#11, etc. I det här fallet får affärslogiken åtkomst till kryptogränssnittet och den översätter anropet till motsvarande kryptokärna, som i detta fall kallas kryptoleverantör. Användningen av kryptografiska gränssnitt gör att applikationsprogramvaran kan abstrahera bort från specifika kryptografiska algoritmer och vara mer flexibel.
Det finns två typiska scheman för att organisera kryptokärnan:
Schema 1 – Monolitisk kryptokärna
Schema 2 – Delad kryptokärna
Elementen i ovanstående diagram kan antingen vara individuella programvarumoduler som körs på en dator eller nätverkstjänster som interagerar inom ett datornätverk.
När man använder system byggda enligt Schema 1, fungerar applikationsmjukvaran och kryptokärnan inom en enda operativ miljö för kryptoverktyget (SFC), till exempel på samma dator som kör samma operativsystem. Systemanvändaren kan som regel köra andra program, inklusive de som innehåller skadlig kod, inom samma operativsystem. Under sådana förhållanden finns det en allvarlig risk för läckage av privata kryptografiska nycklar.
För att minimera risken används schema 2, där kryptokärnan är uppdelad i två delar:
- Den första delen, tillsammans med applikationsmjukvaran, fungerar i en opålitlig miljö där det finns risk för infektion med skadlig kod. Vi kommer att kalla denna del för "mjukvarudelen".
- Den andra delen fungerar i en pålitlig miljö på en dedikerad enhet, som innehåller en privat nyckellagring. Från och med nu kommer vi att kalla denna del för "hårdvara".
Uppdelningen av kryptokärnan i mjukvaru- och hårdvarudelar är mycket godtycklig. Det finns system på marknaden byggda enligt ett schema med en delad kryptokärna, men vars "hårdvara" del presenteras i form av en virtuell maskinavbildning - virtuell HSM ().
Interaktionen mellan de båda delarna av kryptokärnan sker på ett sådant sätt att privata kryptografiska nycklar aldrig överförs till mjukvarudelen och följaktligen inte kan stjälas med skadlig kod.
Interaktionsgränssnittet (API) och uppsättningen av kryptografiska primitiver som tillhandahålls till applikationsmjukvaran av kryptokärnan är desamma i båda fallen. Skillnaden ligger i hur de implementeras.
Således, när du använder ett schema med en delad kryptokärna, utförs interaktionen mellan mjukvara och hårdvara enligt följande princip:
- Kryptografiska primitiver som inte kräver användning av en privat nyckel (till exempel beräkning av en hashfunktion, verifiering av en elektronisk signatur etc.) utförs av programvaran.
- Kryptografiska primitiver som använder en privat nyckel (skapa en elektronisk signatur, dekryptera data, etc.) utförs av hårdvara.
Låt oss illustrera arbetet med den delade kryptokärnan med hjälp av exemplet att skapa en elektronisk signatur:
- Mjukvarudelen beräknar hashfunktionen för den signerade datan och överför detta värde till hårdvaran via utbyteskanalen mellan kryptokärnor.
- Hårdvarudelen, med hjälp av den privata nyckeln och hashen, genererar värdet av den elektroniska signaturen och överför den till mjukvarudelen via en utbyteskanal.
- Mjukvarudelen returnerar det mottagna värdet till applikationsmjukvaran.
Funktioner för att kontrollera korrektheten av en elektronisk signatur
När den mottagande parten tar emot elektroniskt signerad data måste den utföra flera verifieringssteg. Ett positivt resultat av att kontrollera en elektronisk signatur uppnås endast om alla stadier av verifieringen är framgångsrika genomförda.
Steg 1. Kontroll av dataintegritet och dataförfattarskap.
Scenens innehåll. Den elektroniska signaturen för data verifieras med hjälp av lämplig kryptografisk algoritm. Ett framgångsrikt slutförande av detta steg indikerar att data inte har modifierats sedan det ögonblick de signerades, och även att signaturen gjordes med en privat nyckel som motsvarar den publika nyckeln för att verifiera den elektroniska signaturen.
Plats för scenen: krypto kärna.
Steg 2. Kontroll av förtroende för undertecknarens publika nyckel och kontroll av giltighetstiden för den elektroniska signaturens privata nyckel.
Scenens innehåll. Scenen består av två mellanliggande delsteg. Den första är att bestämma om den publika nyckeln för att verifiera den elektroniska signaturen var betrodd vid tidpunkten för signering av data. Den andra bestämmer om den privata nyckeln för den elektroniska signaturen var giltig vid tidpunkten för undertecknandet av datan. I allmänhet kanske giltighetsperioderna för dessa nycklar inte sammanfaller (till exempel för kvalificerade certifikat för verifieringsnycklar för elektroniska signaturer). Metoder för att etablera förtroende för undertecknarens publika nyckel bestäms av reglerna för elektronisk dokumenthantering som antagits av de interagerande parterna.
Plats för scenen: applikationsprogramvara / kryptokärna.
Steg 3. Kontroll av undertecknarens befogenhet.
Scenens innehåll. I enlighet med fastställda regler för elektronisk dokumenthantering kontrolleras om undertecknaren hade rätt att intyga de skyddade uppgifterna. Som ett exempel, låt oss ge en situation med myndighetsöverträdelse. Anta att det finns en organisation där alla anställda har en elektronisk signatur. Det interna elektroniska dokumenthanteringssystemet tar emot en beställning från chefen, men undertecknad med lagerchefens elektroniska signatur. En sådan handling kan följaktligen inte anses legitim.
Plats för scenen: programvara.
Antaganden som gjorts vid beskrivning av skyddsobjektet
- Informationsöverföringskanaler, med undantag för nyckelutbyteskanaler, passerar också genom applikationsprogramvara, API och kryptokärna.
- Information om förtroende för offentliga nycklar och (eller) certifikat, samt information om befogenheter för ägare av publika nycklar, finns i det offentliga nyckellagret.
- Applikationsmjukvaran fungerar med det allmänna nyckellagret genom kryptokärnan.
Ett exempel på ett informationssystem skyddat med CIPF
För att illustrera de tidigare presenterade diagrammen, låt oss överväga ett hypotetiskt informationssystem och markera alla strukturella element på det.
Beskrivning av informationssystemet
De två organisationerna beslutade att införa juridiskt betydelsefull elektronisk dokumenthantering (EDF) sinsemellan. För att göra detta ingick de ett avtal där de föreskrev att dokument skulle skickas med e-post och samtidigt måste de krypteras och signeras med en kvalificerad elektronisk signatur. Office-program från Microsoft Office 2016-paketet ska användas som verktyg för att skapa och bearbeta dokument, och CIPF CryptoPRO och krypteringsmjukvaran CryptoARM ska användas som medel för kryptografiskt skydd.
Beskrivning av organisationens infrastruktur 1
Organisation 1 beslutade att den skulle installera programvaran CIPF CryptoPRO och CryptoARM på användarens arbetsstation - en fysisk dator. Kryptering och elektroniska signaturnycklar kommer att lagras på ruToken-nyckelmediet, som fungerar i hämtbart nyckelläge. Användaren kommer att förbereda elektroniska dokument lokalt på sin dator, sedan kryptera, signera och skicka dem med en lokalt installerad e-postklient.
Beskrivning av organisationens infrastruktur 2
Organisation 2 beslutade att flytta krypterings- och elektroniska signaturfunktioner till en dedikerad virtuell maskin. I det här fallet kommer alla kryptografiska operationer att utföras automatiskt.
För att göra detta är två nätverksmappar organiserade på den dedikerade virtuella maskinen: "...In", "...Out". Filer som tas emot från motparten i öppen form kommer automatiskt att placeras i nätverksmappen "...In". Dessa filer kommer att dekrypteras och den elektroniska signaturen kommer att verifieras.
Användaren kommer att placera filer i mappen "...Out" som måste krypteras, signeras och skickas till motparten. Användaren förbereder filerna själv på sin arbetsstation.
För att utföra kryptering och elektroniska signaturfunktioner installeras CIPF CryptoPRO, CryptoARM programvara och en e-postklient på den virtuella maskinen. Automatisk hantering av alla delar av den virtuella maskinen kommer att utföras med hjälp av skript utvecklade av systemadministratörer. Arbetet med skript loggas i loggfiler.
Kryptografiska nycklar för den elektroniska signaturen kommer att placeras på en token med en ej återtagbar JaCarta GOST-nyckel, som användaren kommer att ansluta till sin lokala dator.
Token kommer att vidarebefordras till den virtuella maskinen med hjälp av specialiserad USB-over-IP-programvara installerad på användarens arbetsstation och på den virtuella maskinen.
Systemklockan på användarens arbetsstation i organisation 1 kommer att justeras manuellt. Systemklockan för den dedikerade virtuella maskinen i organisation 2 kommer att synkroniseras med hypervisorns systemklocka, som i sin tur kommer att synkroniseras över Internet med publika tidsservrar.
Identifiering av strukturella delar av CIPF
Baserat på ovanstående beskrivning av IT-infrastrukturen kommer vi att lyfta fram de strukturella delarna av CIPF och skriva dem i en tabell.
Tabell - Överensstämmelse mellan CIPF-modellelement och informationssystemelement
Artikelnamn
Organisation 1
Organisation 2
Programvara
CryptoARM programvara
CryptoARM programvara
Mjukvarudel av kryptokärnan
CIPF CryptoPRO CSP
CIPF CryptoPRO CSP
Krypto kärna hårdvara
ingen
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Public Key Store
Användarens arbetsstation:
- HDD;
- standard Windows-certifikatarkiv.
Hypervisor:
- Hårddisk.
Virtuell maskin:
- HDD;
- standard Windows-certifikatarkiv.
Privat nyckelförvaring
ruToken-nyckelbärare som fungerar i hämtbart nyckelläge
JaCarta GOST-nyckelhållare som fungerar i icke-borttagbart nyckelläge
Utbyteskanal för offentlig nyckel
Användarens arbetsstation:
- BAGGE.
Hypervisor:
- BAGGE.
Virtuell maskin:
- BAGGE.
Privat nyckelutbyteskanal
Användarens arbetsstation:
— USB-buss;
- BAGGE.
ingen
Utbyteskanal mellan kryptokärnor
saknas (ingen krypto kärnhårdvara)
Användarens arbetsstation:
— USB-buss;
- BAGGE;
— USB-over-IP-mjukvarumodul;
— nätverksgränssnitt.
Organisationens företagsnätverk 2.
Hypervisor:
- BAGGE;
— nätverksgränssnitt.
Virtuell maskin:
— nätverksgränssnitt.
- BAGGE;
— USB-over-IP mjukvarumodul.
Öppna datakanal
Användarens arbetsstation:
— input-output-organ.
- BAGGE;
- Hårddisk.
Användarens arbetsstation:
— input-output-organ.
- BAGGE;
- HDD;
— nätverksgränssnitt.
Organisationens företagsnätverk 2.
Hypervisor:
— nätverksgränssnitt.
- BAGGE;
- Hårddisk.
Virtuell maskin:
— nätverksgränssnitt.
- BAGGE;
- Hårddisk.
Säker kanal för datautbyte
Internet.
Organisationens företagsnätverk 1.
Användarens arbetsstation:
- HDD;
- BAGGE;
— nätverksgränssnitt.
Internet.
Organisationens företagsnätverk 2.
Hypervisor:
— nätverksgränssnitt.
- BAGGE;
- Hårddisk.
Virtuell maskin:
— nätverksgränssnitt.
- BAGGE;
- Hårddisk.
Tidskanal
Användarens arbetsstation:
— input-output-organ.
- BAGGE;
- systemtimer.
Internet.
Företagsnätverk av organisation 2,
Hypervisor:
— nätverksgränssnitt.
- BAGGE;
- systemtimer.
Virtuell maskin:
- BAGGE;
- systemtimer.
Styrkommando överföringskanal
Användarens arbetsstation:
— input-output-organ.
- BAGGE.
(Grafiskt användargränssnitt för CryptoARM-programvaran)
Virtuell maskin:
- BAGGE;
- Hårddisk.
(Automatisk skript)
Kanal för att ta emot arbetsresultat
Användarens arbetsstation:
— input-output-organ.
- BAGGE.
(Grafiskt användargränssnitt för CryptoARM-programvaran)
Virtuell maskin:
- BAGGE;
- Hårddisk.
(Loggfiler för automatiseringsskript)
Säkerhetshot på högsta nivå
förklaringar
Antaganden som görs vid nedbrytning av hot:
- Starka kryptografiska algoritmer används.
- Kryptografiska algoritmer används säkert i de korrekta driftsätten (t.ex. används inte för att kryptera stora datamängder, den tillåtna belastningen på nyckeln beaktas etc.).
- Angripare känner till alla algoritmer, protokoll och publika nycklar som används.
- Angripare kan läsa all krypterad data.
- Angripare kan reproducera alla programvaruelement i systemet.
Sönderfall
U1. Kompromiss med privata kryptografiska nycklar.
U2. Kryptera falska data på uppdrag av den legitima avsändaren.
U3. Dekryptering av krypterad data av personer som inte är legitima mottagare av uppgifterna (angripare).
U4. Skapande av en elektronisk signatur för en legitim signatär under falska uppgifter.
U5. Att få ett positivt resultat från att kontrollera den elektroniska signaturen av förfalskade data.
U6. Felaktigt godtagande av elektroniska dokument för exekvering på grund av problem med att organisera elektroniskt dokumentflöde.
U7. Obehörig åtkomst till skyddad data under deras behandling av CIPF.
U1. Kompromiss med privata kryptografiska nycklar
U1.1. Hämtar den privata nyckeln från det privata nyckellagret.
U1.2. Att erhålla en privat nyckel från objekt i kryptoverktygets driftsmiljö, där det tillfälligt kan finnas.
Förklaringar U1.2.
Objekt som tillfälligt kan lagra en privat nyckel inkluderar:
- BAGGE,
- tillfälliga filer,
- byta filer,
- viloläge filer,
- ögonblicksbildfiler av virtuella maskiners "heta" tillstånd, inklusive filer med innehållet i RAM-minnet på pausade virtuella maskiner.
U1.2.1. Extrahera privata nycklar från fungerande RAM genom att frysa RAM-moduler, ta bort dem och sedan läsa data (frysattack).
Förklaringar U1.2.1.
Exempel .
U1.3. Erhålla en privat nyckel från en privat nyckelutbyteskanal.
Förklaringar U1.3.
Ett exempel på genomförandet av detta hot kommer att ges .
U1.4. Otillåten modifiering av kryptokärnan, som ett resultat av att privata nycklar blir kända för angripare.
U1.5. Kompromiss av en privat nyckel som ett resultat av användningen av tekniska informationsläckagekanaler (TCIL).
Förklaringar U1.5.
Exempel .
U1.6. Kompromiss med en privat nyckel som ett resultat av användningen av speciella tekniska medel (STS) utformade för att i hemlighet hämta information ("buggar").
U1.7. Kompromiss med privata nycklar under deras lagring utanför CIPF.
Förklaringar U1.7.
Till exempel lagrar en användare sina nyckelmedier i en skrivbordslåda, från vilken de enkelt kan hämtas av angripare.
U2. Kryptera falska data på uppdrag av en legitim avsändare
förklaringar
Detta hot beaktas endast för datakrypteringsscheman med avsändarautentisering. Exempel på sådana system anges i standardiseringsrekommendationerna . För andra kryptografiska system existerar inte detta hot, eftersom kryptering utförs på mottagarens publika nycklar, och de är allmänt kända för angripare.
Sönderfall
U2.1. Att äventyra avsändarens privata nyckel:
U2.1.1. Länk: .
U2.2. Substitution av indata i en öppen datautbyteskanal.
Anmärkningar U2.2.
Exempel på genomförandet av detta hot ges nedan. и .
U3. Dekryptering av krypterad data av personer som inte är legitima mottagare av uppgifterna (angripare)
Sönderfall
U3.1. Kompromiss med privata nycklar för mottagaren av krypterad data.
U3.1.1 Länk: .
U3.2. Ersättning av krypterad data i en säker datautbyteskanal.
U4. Skapa en elektronisk signatur för en legitim undertecknare under falsk data
Sönderfall
U4.1. Kompromiss med de privata nycklarna för den elektroniska signaturen för en legitim undertecknare.
U4.1.1 Länk: .
U4.2. Ersättning av signerade data i en öppen datautbyteskanal.
Notera U4.2.
Exempel på genomförandet av detta hot ges nedan. и .
U5. Att få ett positivt resultat från att kontrollera den elektroniska signaturen av förfalskade data
Sönderfall
U5.1. Angripare fångar upp ett meddelande i kanalen för att överföra arbetsresultat om ett negativt resultat av att kontrollera en elektronisk signatur och ersätter det med ett meddelande med ett positivt resultat.
U5.2. Angripare attackerar förtroendet för att signera certifikat (SCRIPT - alla element krävs):
U5.2.1. Angripare genererar en offentlig och privat nyckel för en elektronisk signatur. Om systemet använder nyckelcertifikat för elektroniska signaturer, genererar de ett elektroniskt signaturcertifikat som är så likt certifikatet för den avsedda avsändaren av de uppgifter vars meddelande de vill förfalska.
U5.2.2. Angripare gör obehöriga ändringar i det offentliga nyckellagret, vilket ger den offentliga nyckeln de genererar den nödvändiga nivån av förtroende och auktoritet.
U5.2.3. Angripare signerar falsk data med en tidigare genererad elektronisk signaturnyckel och infogar den i den säkra datautbyteskanalen.
U5.3. Angripare utför en attack med utgångna elektroniska signaturnycklar från en laglig undertecknare (SCRIPT - alla element krävs):
U5.3.1. Angripare kompromissar utgångna (ej giltiga för närvarande) privata nycklar för den elektroniska signaturen för en legitim avsändare.
U5.3.2. Angripare ersätter tiden i tidsöverföringskanalen med den tid då de komprometterade nycklarna fortfarande var giltiga.
U5.3.3. Angripare signerar falsk data med en tidigare komprometterad elektronisk signaturnyckel och injicerar den i den säkra datautbyteskanalen.
U5.4. Angripare utför en attack med komprometterade elektroniska signaturnycklar från en laglig undertecknare (SCRIPT - alla element krävs):
U5.4.1. Angriparen gör en kopia av det offentliga nyckellagret.
U5.4.2. Angriparna äventyrar de privata nycklarna för en av de legitima avsändarna. Han märker kompromissen, återkallar nycklarna och information om nyckelåterkallelsen placeras i det offentliga nyckellagret.
U5.4.3. Angripare ersätter det offentliga nyckellagret med ett tidigare kopierat.
U5.4.4. Angripare signerar falsk data med en tidigare komprometterad elektronisk signaturnyckel och injicerar den i den säkra datautbyteskanalen.
U5.5. <…> på grund av förekomsten av fel i implementeringen av den andra och tredje etappen av elektronisk signaturverifiering:
Förklaringar U5.5.
Ett exempel på genomförandet av detta hot ges .
U5.5.1. Kontrollera förtroende för ett elektroniskt signaturnyckelcertifikat endast genom närvaron av förtroende i certifikatet som det är signerat med, utan CRL- eller OCSP-kontroller.
Förklaringar U5.5.1.
Implementeringsexempel .
U5.5.2. När man bygger en förtroendekedja för ett certifikat, analyseras inte myndigheterna för att utfärda certifikat
Förklaringar U5.5.2.
Ett exempel på en attack mot SSL/TLS-certifikat.
Angriparna köpte ett legitimt certifikat för sin e-post. De gjorde sedan ett bedrägligt webbplatscertifikat och undertecknade det med sitt certifikat. Om referenserna inte kontrolleras, kommer det att visa sig vara korrekt när du kontrollerar förtroendekedjan, och följaktligen kommer det bedrägliga certifikatet också att vara korrekt.
U5.5.3. När du bygger en förtroendekedja för certifikat kontrolleras inte mellanliggande certifikat för återkallelse.
U5.5.4. CRL uppdateras mer sällan än de utfärdas av certifieringsmyndigheten.
U5.5.5. Beslutet att lita på en elektronisk signatur tas innan ett OCSP-svar om certifikatets status tas emot, skickat på en begäran som görs senare än den tidpunkt då signaturen genererades eller tidigare än nästa CRL efter att signaturen genererades.
Förklaringar U5.5.5.
I regelverket för de flesta CA anses tidpunkten för certifikatåterkallelse vara tidpunkten för utfärdandet av närmaste CRL som innehåller information om certifikatåterkallelsen.
U5.5.6. Vid mottagning av signerad data, certifikatet tillhör avsändaren kontrolleras inte.
Förklaringar U5.5.6.
Exempel på attack. I förhållande till SSL-certifikat: överensstämmelsen mellan den anropade serveradressen och värdet på CN-fältet i certifikatet kanske inte kontrolleras.
Exempel på attack. Angripare äventyrade de elektroniska signaturnycklarna för en av deltagarna i betalningssystemet. Därefter hackade de sig in i en annan deltagares nätverk och skickade på hans vägnar betalningsdokument signerade med komprometterade nycklar till betalningssystemets avvecklingsserver. Om servern bara analyserar förtroende och inte kontrollerar efterlevnad, kommer bedrägliga dokument att anses vara legitima.
U6. Felaktigt godtagande av elektroniska dokument för exekvering på grund av problem med att organisera elektroniskt dokumentflöde.
Sönderfall
U6.1. Den mottagande parten upptäcker inte dubblering av mottagna dokument.
Förklaringar U6.1.
Exempel på attack. Angripare kan fånga upp ett dokument som sänds till en mottagare, även om det är kryptografiskt skyddat, och sedan upprepade gånger skicka det över en säker dataöverföringskanal. Om mottagaren inte identifierar dubbletter kommer alla mottagna dokument att uppfattas och behandlas som olika dokument.
U7. Obehörig åtkomst till skyddad data under deras behandling av CIPF
Sönderfall
U7.1. <…> på grund av informationsläckage via sidokanaler (sidokanalangrepp).
Förklaringar U7.1.
Exempel .
U7.2. <…> på grund av neutraliseringen av skyddet mot obehörig åtkomst till information som behandlas på CIPF:
U7.2.1. Drift av CIPF i strid med kraven som beskrivs i dokumentationen för CIPF.
U7.2.2. <…>, utförs på grund av närvaron av sårbarheter i:
U7.2.2.1. <…> medel för skydd mot obehörig åtkomst.
U7.2.2.2. <…> CIPF själv.
U7.2.2.3. <…> operativmiljön för kryptoverktyget.
Exempel på attacker
Scenarierna som diskuteras nedan innehåller uppenbarligen informationssäkerhetsfel och tjänar endast till att illustrera möjliga attacker.
Scenario 1. Ett exempel på implementering av hot U2.2 och U4.2.
Beskrivning av objektet
AWS KBR-programvaran och CIPF SCAD Signature är installerade på en fysisk dator som inte är ansluten till datornätverket. FKN vdToken används som nyckelbärare i läget att arbeta med en icke-borttagbar nyckel.
Avräkningsbestämmelserna förutsätter att avvecklingsspecialisten från sin arbetsdator laddar ner elektroniska meddelanden i klartext (schemat för den gamla KBR-arbetsstationen) från en speciell säker filserver, sedan skriver dem till ett överförbart USB-minne och överför dem till KBR-arbetsstationen, där de är krypterade och skyltar. Efter detta överför specialisten säkra elektroniska meddelanden till det alienerade mediet och skriver dem sedan via sin arbetsdator till en filserver, varifrån de går till UTA och sedan till Rysslands centralbanks betalningssystem.
I det här fallet kommer kanalerna för utbyte av öppna och skyddade data att inkludera: en filserver, en specialists arbetsdator och alienerade media.
Ge sig på
Obehöriga angripare installerar ett fjärrkontrollsystem på en specialists arbetsdator och, när betalningsuppdrag (elektroniska meddelanden) skrivs till ett överförbart medium, ersätter innehållet i ett av dem i klartext. Specialisten överför betalningsuppdrag till den automatiserade KBR-arbetsplatsen, signerar och krypterar dem utan att märka ersättningen (till exempel på grund av ett stort antal betalningsorder på en flygning, trötthet, etc.). Efter detta kommer den falska betalningsordern, efter att ha passerat genom den tekniska kedjan, in i Rysslands Banks betalningssystem.
Scenario 2. Ett exempel på implementering av hot U2.2 och U4.2.
Beskrivning av objektet
En dator med en installerad arbetsstation KBR, SCAD Signature och en ansluten nyckelbärare FKN vdToken fungerar i ett dedikerat rum utan åtkomst från personal.
Beräkningsspecialisten ansluter till CBD-arbetsstationen i fjärråtkomstläge via RDP-protokollet.
Ge sig på
Angripare fångar upp detaljerna, med hjälp av vilka beräkningsspecialisten ansluter och arbetar med CBD-arbetsstationen (till exempel genom skadlig kod på sin dator). Sedan ansluter de på hans vägnar och skickar en falsk betalningsorder till betalningssystemet Bank of Russia.
Scenario 3. Exempel på hotimplementering U1.3.
Beskrivning av objektet
Låt oss överväga ett av de hypotetiska alternativen för att implementera ABS-KBR-integreringsmodulerna för ett nytt schema (AWS KBR-N), där den elektroniska signaturen av utgående dokument sker på ABS-sidan. I det här fallet kommer vi att anta att ABS fungerar på basis av ett operativsystem som inte stöds av CIPF SKAD-signaturen, och följaktligen överförs den kryptografiska funktionaliteten till en separat virtuell maskin - "ABS-KBR"-integrationen modul.
En vanlig USB-token som fungerar i hämtbart nyckelläge används som nyckelbärare. Vid anslutning av nyckelmediet till hypervisorn visade det sig att det inte fanns några lediga USB-portar i systemet, så det beslöts att ansluta USB-token via en nätverks-USB-hubb och installera en USB-over-IP-klient på den virtuella maskin, som skulle kommunicera med navet.
Ge sig på
Angriparna snappade upp den privata nyckeln till den elektroniska signaturen från kommunikationskanalen mellan USB-hubben och hypervisorn (data överfördes i klartext). Med den privata nyckeln genererade angriparna en falsk betalningsorder, undertecknade den med en elektronisk signatur och skickade den till den automatiserade KBR-N-arbetsplatsen för utförande.
Scenario 4. Ett exempel på implementering av hot U5.5.
Beskrivning av objektet
Låt oss betrakta samma krets som i föregående scenario. Vi kommer att anta att elektroniska meddelanden som kommer från KBR-N-arbetsstationen hamnar i …SHAREIn-mappen, och de som skickas till KBR-N-arbetsstationen och vidare till Bank of Russias betalningssystem går till …SHAREout.
Vi kommer också att anta att vid implementering av integrationsmodulen uppdateras listor över återkallade certifikat endast när kryptografiska nycklar återutges, och även att elektroniska meddelanden som tas emot i …SHAREIn-mappen endast kontrolleras för integritetskontroll och förtroendekontroll i den publika nyckeln till elektronisk signatur.
Ge sig på
Angriparna, med hjälp av nycklarna som stulits i det tidigare scenariot, undertecknade en falsk betalningsorder innehållande information om mottagandet av pengar på kontot hos den bedrägliga klienten och introducerade den i den säkra datautbyteskanalen. Eftersom det inte finns någon verifiering av att betalningsordern undertecknades av Rysslands centralbank, accepteras den för utförande.
Källa: will.com