Skakels na ander dele van die studie
- (Is jy hier)
Hierdie artikel voltooi die siklus van publikasies wat gewy is aan die versekering van die inligtingsekuriteit van bankbetalings wat nie kontant is nie. Hier kyk ons na die generiese bedreigingsmodelle waarna verwys word :
- .
- .
- .
- .
HABR-WAARSKUWING!!! Beste Khabrovites, hierdie is nie 'n vermaaklike plasing nie.
Meer as 40 bladsye materiaal wat onder die snit versteek is, word aangevra help met werk of studie mense wat spesialiseer in bankwese of inligtingsekuriteit. Hierdie materiaal is die finale produk van die studie en is in 'n droë formele toon geskryf. Trouens, dit is spasies vir interne dokumente oor inligtingsekuriteit.Wel, die tradisionele "Die gebruik van inligting uit die artikel vir onwettige doeleindes is strafbaar deur die wet". Produktiewe lees!
Inligting vir lesers wat die studie vanaf hierdie publikasie lees.
Waaroor gaan die studie
Jy lees 'n gids vir 'n spesialis wat verantwoordelik is om die inligtingsekuriteit van betalings in 'n bank te verseker.
Aanbiedingslogika
Aan die begin in и die beskrywing van die beskermingsobjek word gegee. Toe in dit vertel hoe om 'n beskermingstelsel te bou, en praat oor die behoefte om 'n bedreigingsmodel te skep. IN Dit vertel oor wat bedreigingsmodelle is en hoe dit gevorm word. IN и ontleding van werklike aanvalle word gegee. и bevat 'n beskrywing van die bedreigingsmodel wat gebou is met inagneming van die inligting van alle vorige dele.
TIPIESE BEDREIGINGSMODEL. NETWERK KONNEKSIE
Die beskermingsobjek waarvoor die bedreigingsmodel toegepas word (omvang)
Die doel van beskerming is data wat oorgedra word deur 'n netwerkverbinding wat in datanetwerke werk wat op die basis van die TCP/IP-stapel gebou is.
Argitektuur
Beskrywing van argitektuurelemente:
- "eind nodes" - nodusse wat beskermde inligting uitruil.
- "Intermediêre nodusse" - elemente van die data-oordragnetwerk: routers, skakelaars, toegangsbedieners, instaanbedieners en ander toerusting - waardeur netwerkverbindingsverkeer oorgedra word. Oor die algemeen kan 'n netwerkverbinding sonder tussennodusse funksioneer (direk tussen eindnodusse).
Topvlak sekuriteitsbedreigings
Ontbinding
U1. Ongemagtigde toegang tot oorgedra data.
U2. Ongemagtigde wysiging van oorgedra data.
U3. Oortreding van die outeurskap van die oorgedra data.
U1. Ongemagtigde toegang tot oorgedra data
Ontbinding
U1.1. <...>, uitgevoer op finale of intermediêre nodusse:
U1.1.1. <…> deur die data te lees terwyl dit in die stoortoestelle van die nodus is:
U1.1.1.1. <…> in RAM.
Verduidelikings vir V1.1.1.1.
Byvoorbeeld, tydens dataverwerking deur die nodus se netwerkstapel.
U1.1.1.2. <…> in nie-vlugtige geheue.
Verduidelikings vir V1.1.1.2.
Byvoorbeeld, wanneer versende data in die kas gestoor word, tydelike lêers of blaailêers.
Y1.2. <...> uitgevoer op derdeparty-datanetwerknodusse:
U1.2.1. <...> deur alle pakkies wat op die netwerkkoppelvlak van die nodus val, vas te lê:
Verduidelikings vir V1.2.1.
Alle pakkies word vasgelê deur die netwerkkaart na promiskue modus oor te skakel (promiskue modus vir bedrade adapters of monitormodus vir wi-fi adapters).
U1.2.2. <…> deur man-in-die-middel (MiTM) aanvalle uit te voer, maar sonder om die oorgedrade data te wysig (nie die diensdata van netwerkprotokolle ingereken nie).
Y1.2.2.1. Skakel: .
Y1.3. <...>, uitgevoer as gevolg van inligtinglekkasie deur tegniese kanale (TCUI) vanaf fisiese nodusse of kommunikasielyne.
U1.4. <...>, uitgevoer vir die installering van spesiale tegniese middele (STS) op die finale of intermediêre nodusse, bedoel vir die geheime verwydering van inligting.
U2. Ongemagtigde wysiging van oorgedra data
Ontbinding
U2.1. <...>, uitgevoer op finale of intermediêre nodusse:
Y2.1.1. <...> deur die data te lees en te wysig terwyl dit in die stoortoestelle van die nodusse is:
Y2.1.1.1. <...> in RAM:
Y2.1.1.2. <…> in nie-vlugtige geheue:
Y2.2. <...> uitgevoer op derdeparty-datanetwerknodusse:
U2.2.1. <…> deur Man-in-the-Middle (MiTM) aanvalle uit te voer en verkeer na die kwaadwillige gasheer te herlei:
Y2.2.1.1. Die fisiese verbinding van die aanvallers se toerusting om die netwerkverbinding te verbreek.
Y2.2.1.2. Implementering van aanvalle op netwerkprotokolle:
Y2.2.1.2.1. <…> virtuele plaaslike area netwerk (VLAN) bestuur:
Y2.2.1.2.1.1. .
Y2.2.1.2.1.2. Ongemagtigde wysiging van VLAN-instellings op skakelaars of routers.
Y2.2.1.2.2. <…> verkeersroetes:
Y2.2.1.2.2.1. Ongemagtigde wysiging van die statiese roeteertabelle van routers.
Y2.2.1.2.2.2. Aankondiging van vals roetes deur aanvallers deur dinamiese roete-protokolle.
Y2.2.1.2.3. <…> outomatiese konfigurasie:
Y2.2.1.2.3.1. .
Y2.2.1.2.3.2. .
Y2.2.1.2.4. <…> adressering en naamresolusie:
Y2.2.1.2.4.1. .
Y2.2.1.2.4.2. .
Y2.2.1.2.4.3. Maak ongemagtigde veranderinge aan plaaslike gasheernaamlêers (gashere, lmhosts, ens.)
U3. Oortreding van die outeurskap van die oorgedra data
Ontbinding
Y3.1. Neutralisering van meganismes om die outeurskap van inligting te bepaal deur vals inligting oor die outeur of databron aan te dui:
Y3.1.1. Die verandering van die inligting oor die outeur vervat in die oorgedra inligting.
Y3.1.1.1. Neutralisering van kriptografiese beskerming van die integriteit en outeurskap van die oorgedra data:
Y3.1.1.1.1. Skakel: .
Y3.1.1.2. Neutralisering van die beskerming van die oorgedra data outeurskap, geïmplementeer met behulp van eenmalige bevestiging kodes:
Y3.1.1.2.1. .
Y3.1.2. Verandering van inligting oor die bron van oorgedra inligting:
Y3.1.2.1. .
Y3.1.2.2. .
TIPIESE BEDREIGINGSMODEL. INLIGTINGSTELSEL GEBOU OP DIE BASIS VAN KLIËNT-BEDIENER-ARGITEKTUUR
Die beskermingsobjek waarvoor die bedreigingsmodel toegepas word (omvang)
Die doel van beskerming is 'n inligtingstelsel wat gebou is op die basis van die kliënt-bediener argitektuur.
Argitektuur
Beskrywing van argitektuurelemente:
- "Kliënt" - 'n toestel waarop die kliëntdeel van die inligtingstelsel werk.
- "Bediener" - 'n toestel waarop die bedienergedeelte van die inligtingstelsel werk.
- "Data winkel" - deel van die bedienerinfrastruktuur van die inligtingstelsel, ontwerp om data wat deur die inligtingstelsel verwerk word, te stoor.
- "Netwerk konneksie" — 'n inligting-uitruilkanaal tussen die kliënt en die bediener wat deur die data-oordragnetwerk gaan. Vir 'n meer gedetailleerde beskrywing van die elementmodel, sien .
Beperkings
Wanneer 'n voorwerp gemodelleer word, word die volgende beperkings gestel:
- Die gebruiker interaksie met die inligtingstelsel binne beperkte tydperke, wat werksessies genoem word.
- Aan die begin van elke sessie word die gebruiker geïdentifiseer, geverifieer en gemagtig.
- Alle beskermde inligting word op die bedienergedeelte van die inligtingstelsel gestoor.
Topvlak sekuriteitsbedreigings
Ontbinding
U1. Aanvallers wat ongemagtigde handelinge namens 'n wettige gebruiker pleeg.
U2. Ongemagtigde wysiging van beskermde inligting tydens die verwerking daarvan deur die bedienerdeel van die inligtingstelsel.
U1. Aanvallers wat ongemagtigde handelinge namens 'n wettige gebruiker pleeg
verduidelikings
Gewoonlik in inligtingstelsels word die korrelasie van aksies met die gebruiker wat dit uitgevoer het uitgevoer met behulp van:
- stelsel logs (logs).
- spesiale eienskappe van data-objekte wat inligting bevat oor die gebruiker wat dit geskep of gewysig het.
Met betrekking tot 'n werksessie kan hierdie bedreiging ontbind word in:
- <…> uitgevoer binne die gebruikersessie.
- <...> buite die gebruikersessie uitgevoer.
'n Gebruikersessie kan geïnisieer word:
- Deur die gebruiker self.
- Indringers.
Op hierdie stadium sal die intermediêre ontbinding van hierdie bedreiging soos volg lyk:
U1.1. Ongemagtigde handelinge uitgevoer binne die gebruikersessie:
U1.1.1. <…> gestel deur die aangeval gebruiker.
U1.1.2. <…> deur aanvallers geïnstalleer.
Y1.2. Ongemagtigde handelinge is buite die gebruiker se sessie uitgevoer.
Uit die oogpunt van inligting-infrastruktuurvoorwerpe wat deur indringers geraak kan word, sal die ontbinding van intermediêre bedreigings soos volg lyk:
elemente
Bedreiging Ontbinding
Y1.1.1.
Y1.1.2.
Y1.2.
kliënt
Y1.1.1.1.
Y1.1.2.1.
netwerk konneksie
Y1.1.1.2.
Bediener
Y1.2.1.
Ontbinding
U1.1. Ongemagtigde handelinge uitgevoer binne die gebruikersessie:
U1.1.1. <…> gestel deur die aangeval gebruiker:
U1.1.1.1. Aanvallers het onafhanklik van die kliënt opgetree:
У1.1.1.1.1 Die aanvallers het standaard inligtingstelseltoegangnutsmiddels gebruik:
Y1.1.1.1.1.1. Die aanvallers het die kliënt se fisiese invoer/afvoermiddel gebruik (sleutelbord, muis, monitor of raakskerm van 'n mobiele toestel):
Y1.1.1.1.1.1.1. Die aanvallers het opgetree gedurende tydperke wanneer die sessie aktief is, I/O-fasiliteite beskikbaar is en die gebruiker weg is.
Y1.1.1.1.1.2. Die aanvallers het afstandadministrasienutsmiddels (standaard of verskaf deur kwaadwillige kode) gebruik om die kliënt te bestuur:
Y1.1.1.1.1.2.1. Die aanvallers het opgetree gedurende tydperke wanneer die sessie aktief is, I/O-fasiliteite beskikbaar is en die gebruiker weg is.
Y1.1.1.1.1.2.2. Die aanvallers het afgeleë administrasienutsmiddels gebruik, waarvan die werking onsigbaar is vir die aangevallende gebruiker.
U1.1.1.2. Die aanvallers het die data in die netwerkverbinding tussen die Kliënt en die Bediener bedrieg, en dit op so 'n manier gewysig dat dit as die optrede van 'n wettige gebruiker beskou is:
Y1.1.1.2.1. Skakel: .
Y1.1.1.3. Die aanvallers het die gebruiker gedwing om die aksies uit te voer wat hulle gespesifiseer het deur sosiale ingenieurswese-metodes te gebruik.
U1.1.2 <…> gestel deur aanvallers:
Y1.1.2.1. Die aanvallers het vanaf die kliënt opgetree (И):
Y1.1.2.1.1. Die aanvallers het die toegangsbeheerstelsel van die inligtingstelsel geneutraliseer:
Y1.1.2.1.1.1. Skakel: .
Y1.1.2.1.2. Misdadigers het gereelde toegang tot inligtingstelsels gebruik
U1.1.2.2. Die aanvallers het vanaf ander nodusse van die data-oordragnetwerk opgetree, vanwaar dit moontlik is om 'n netwerkverbinding met die Bediener (И):
Y1.1.2.2.1. Die aanvallers het die toegangsbeheerstelsel van die inligtingstelsel geneutraliseer:
Y1.1.2.2.1.1. Skakel: .
Y1.1.2.2.2. Die aanvallers het nie-standaard maniere gebruik om toegang tot die inligtingstelsel te verkry.
Verduidelikings Y1.1.2.2.2.
Die aanvallers kan 'n gereelde inligtingstelselkliënt op 'n derdeparty-nodus installeer of kan nie-standaard sagteware gebruik wat standaard uitruilprotokolle tussen die kliënt en die bediener implementeer.
P1.2 Ongemagtigde handelinge wat buite die gebruiker se sessie uitgevoer word.
S1.2.1 Aanvallers het ongemagtigde handelinge uitgevoer, en dan ongemagtigde veranderinge aan die inligtingstelsel se werkinglogboeke of spesiale eienskappe van data-objekte aangebring, wat aandui dat die aksies wat hulle gepleeg het deur 'n wettige gebruiker uitgevoer is.
U2. Ongemagtigde wysiging van beskermde inligting tydens die verwerking daarvan deur die bedienerdeel van die inligtingstelsel
Ontbinding
U2.1. Aanvallers wysig beskermde inligting deur gebruik te maak van standaard inligtingstelselnutsgoed en doen dit namens 'n wettige gebruiker.
Y2.1.1. Skakel: .
Y2.2. Aanvallers wysig beskermde inligting deur gebruik te maak van datatoegangsmeganismes waarvoor die gereelde werking van die inligtingstelsel nie voorsiening maak nie.
U2.2.1. Aanvallers wysig lêers wat beskermde inligting bevat:
Y2.2.1.1. <…> met behulp van die lêerhanteringsmeganismes wat deur die bedryfstelsel verskaf word.
Y2.2.1.2. <...> deur die herstel van lêers uit 'n ongemagtigde gewysigde rugsteun uit te lok.
U2.2.2. Misdadigers wysig die beskermde inligting wat in die databasis gestoor word (И):
Y2.2.2.1. Aanvallers neutraliseer die DBMS-toegangsbeheerstelsel:
Y2.2.2.1.1. Skakel: .
Y2.2.2.2. Aanvallers verander inligting deur gebruik te maak van standaard DBMS-koppelvlakke om toegang tot data te verkry.
Y2.3. Misdadigers verander die beskermde inligting deur ongemagtigde wysiging van algoritmes van werk van die sagteware wat dit verwerk.
Y2.3.1. Wysigings word aan die bronkode van die sagteware gemaak.
Y2.3.1. Wysigings word aan die masjienkode van die sagteware aangebring.
Y2.4. Aanvallers wysig beskermde inligting deur kwesbaarhede in die inligtingstelselsagteware te ontgin.
Y2.5. Aanvallers wysig die beskermde inligting wanneer dit oorgedra word tussen die komponente van die bedienerdeel van die inligtingstelsel (byvoorbeeld die databasisbediener en die toepassingsbediener):
Y2.5.1. Skakel: .
TIPIESE BEDREIGINGSMODEL. TOEGANGSBEHEERSTELSEL
Die beskermingsobjek waarvoor die bedreigingsmodel toegepas word (omvang)
Die beskermingsobjek waarvoor hierdie bedreigingsmodel toegepas word, stem ooreen met die beskermingsobjek van die bedreigingsmodel: “Tipiese bedreigingsmodel. 'n Inligtingstelsel gebou op die basis van 'n kliënt-bediener argitektuur.
Die gebruikertoegangsbeheerstelsel in hierdie bedreigingsmodel word verstaan as 'n inligtingstelselkomponent wat die volgende funksies implementeer:
- Gebruiker identifikasie.
- Gebruikersverifikasie.
- Gebruiker magtigings.
- Meld gebruikershandelinge aan.
Topvlak sekuriteitsbedreigings
Ontbinding
U1. Ongemagtigde vestiging van 'n sessie namens 'n wettige gebruiker.
U2. Ongemagtigde verhoging van gebruikersregte in die inligtingstelsel.
U1. Ongemagtigde sessie vestiging namens 'n wettige gebruiker
verduidelikings
Die ontbinding van hierdie bedreiging in die algemene geval sal afhang van die tipe gebruiker-identifikasie- en verifikasiestelsels wat gebruik word.
In hierdie model sal slegs die gebruiker-identifikasie en -verifikasiestelsel wat teksaanmelding en wagwoord gebruik, oorweeg word. In hierdie geval sal ons aanvaar dat die gebruiker se aanmelding publieke inligting is wat aan aanvallers bekend is.
Ontbinding
U1.1. <…> deur geloofsbriewe te kompromitteer:
U1.1.1. Die aanvallers het die gebruiker se geloofsbriewe gekompromitteer terwyl dit gestoor is.
Verduidelikings Y1.1.1.
Geloofsbriewe kan byvoorbeeld geskryf word op 'n plaknota wat op die monitor vasgemaak is.
U1.1.2. Die gebruiker het per ongeluk of opsetlik toegangsbesonderhede aan aanvallers deurgegee.
Y1.1.2.1. Die gebruiker het die geloofsbriewe hardop gepraat toe hulle ingegaan het.
U1.1.2.2. Die gebruiker het doelbewus hul eiebewyse geslaag:
Y1.1.2.2.1. <…> kollegas by die werk.
Verduidelikings Y1.1.2.2.1.
Byvoorbeeld, sodat hulle dit kan vervang met 'n tydperk van siekte.
Y1.1.2.2.2. <…> aan die teenpartye van die werkgewer wat werk verrig op die voorwerpe van die inligting-infrastruktuur.
Y1.1.2.2.3. <…> aan derde partye.
Verduidelikings Y1.1.2.2.3.
Een, maar nie die enigste manier om hierdie bedreiging te implementeer nie, is om sosiale ingenieurswese-metodes deur aanvallers te gebruik.
U1.1.3. Die aanvallers het die geloofsbriewe brute-gedwing:
Y1.1.3.1. <…> deur gereelde toegangsmeganismes te gebruik.
U1.1.3.2. <...> deur kodes wat voorheen onderskep is (byvoorbeeld wagwoord-hashes) vir die stoor van geloofsbriewe.
U1.1.4. Die aanvallers het kwaadwillige kode gebruik om die gebruiker se geloofsbriewe te onderskep.
U1.1.5. Aanvallers het geloofsbriewe uit 'n netwerkverbinding tussen die kliënt en die bediener onttrek:
Y1.1.5.1. Skakel: .
U1.1.6. Aanvallers het geloofsbriewe uit rekords van werkmoniteringstelsels onttrek:
U1.1.6.1. <…> video-toesigstelsels (in die geval dat toetsaanslagen op die sleutelbord tydens operasie opgeneem is).
U1.1.6.2. <…> stelsels vir die monitering van die optrede van werknemers by die rekenaar
Verduidelikings Y1.1.6.2.
'n Voorbeeld van so 'n stelsel is .
U1.1.7. Die aanvallers het die gebruiker se geloofsbriewe gekompromitteer weens gebreke in die oordragproses.
Verduidelikings Y1.1.7.
Byvoorbeeld, die oordrag van wagwoorde in duidelike teks per e-pos.
U1.1.8. Die aanvallers het die geloofsbriewe geleer deur die gebruiker se sessie met behulp van afstandadministrasiestelsels te monitor.
U1.1.9. Die aanvallers het die geloofsbriewe onttrek as gevolg van hul lekkasie deur tegniese kanale (TCUE):
U1.1.9.1. Die aanvallers het gespioeneer hoe die gebruiker geloofsbriewe vanaf die sleutelbord invoer:
E1.1.9.1.1 Die aanvallers was naby die gebruiker geleë en het die inskrywing van geloofsbriewe met hul eie oë gesien.
C1.1.9.1.1 Verduidelikings
Sulke gevalle sluit in die optrede van kollegas by die werk of die geval wanneer die gebruiker se sleutelbord sigbaar is vir besoekers aan die organisasie.
E1.1.9.1.2 Die aanvallers het bykomende tegniese middele, soos 'n verkyker of 'n onbemande lugvoertuig, gebruik en die inskrywing van geloofsbriewe deur 'n venster gesien.
U1.1.9.2. Die aanvallers het geloofsbriewe uit die rekords van die radio-uitruiling tussen die sleutelbord en die stelseleenheid van die rekenaar onttrek as hulle via die radio-koppelvlak (byvoorbeeld Bluetooth) gekoppel is.
U1.1.9.3. Die aanvallers het die geloofsbriewe onderskep deur dit deur die kanaal van valse elektromagnetiese straling en bakkies (PEMIN) te lek.
Verduidelikings Y1.1.9.3.
Aanval voorbeelde и .
U1.1.9.4. Die aanvaller het die invoer van geloofsbriewe vanaf die sleutelbord onderskep deur die gebruik van spesiale tegniese middele (STS) wat ontwerp is om inligting heimlik te verwyder.
Verduidelikings Y1.1.9.4.
voorbeelde .
U1.1.9.5. Die aanvallers het die invoer van geloofsbriewe vanaf die sleutelbord onderskep met behulp van
ontleding van die Wi-Fi-sein gemoduleer deur die proses om die sleutels deur die gebruiker te druk.
Verduidelikings Y1.1.9.5.
Voorbeeld .
U1.1.9.6. Die aanvallers het die invoer van geloofsbriewe vanaf die sleutelbord onderskep deur die klanke van toetsaanslagen te ontleed.
Verduidelikings Y1.1.9.6.
Voorbeeld .
U1.1.9.7. Die aanvallers het die invoer van geloofsbriewe vanaf die sleutelbord van 'n mobiele toestel onderskep deur die versnellingsmeterlesings te ontleed.
Verduidelikings Y1.1.9.7.
Voorbeeld .
U1.1.10. <...> voorheen op die kliënt gestoor.
Verduidelikings Y1.1.10.
Byvoorbeeld, 'n gebruiker kan 'n gebruikersnaam en wagwoord in die blaaier stoor om toegang tot 'n spesifieke webwerf te verkry.
U1.1.11. Die aanvallers het geloofsbriewe gekompromitteer weens gebreke in die proses vir die herroeping van gebruikerstoegang.
Verduidelikings Y1.1.11.
Byvoorbeeld, na die ontslag van 'n gebruiker, het sy rekeninge nie geblokkeer nie.
Y1.2. <…> deur kwesbaarhede in die toegangsbeheerstelsel te ontgin.
U2. Ongemagtigde verhoging van gebruikersregte in die inligtingstelsel
Ontbinding
P2.1 <...> deur ongemagtigde veranderinge aan data te maak wat inligting oor die gebruiker se voorregte bevat.
U2.2 <…> deur kwesbaarhede in die toegangsbeheerstelsel te ontgin.
Y2.3. <…> as gevolg van gebreke in die gebruikertoegangsbeheerproses.
Verduidelikings Y2.3.
Voorbeeld 1. 'n Gebruiker is meer toegang tot werk gegee as wat hy nodig gehad het as gevolg van amptelike behoeftes.
Voorbeeld 2: Nadat 'n gebruiker na 'n ander posisie oorgeplaas is, is die voorheen verleende toegangsregte nie herroep nie.
TIPIESE BEDREIGINGSMODEL. INTEGRASIE MODULE
Die beskermingsobjek waarvoor die bedreigingsmodel toegepas word (omvang)
Integrasiemodule - 'n stel inligting-infrastruktuurobjekte wat ontwerp is om die uitruil van inligting tussen inligtingstelsels te organiseer.
Gegewe die feit dat dit in korporatiewe netwerke nie altyd moontlik is om een inligtingstelsel ondubbelsinnig van 'n ander te skei nie, kan die integrasiemodule ook beskou word as 'n skakel tussen komponente binne een inligtingstelsel.
Argitektuur
Die algemene skema van die integrasiemodule lyk soos volg:
Beskrywing van argitektuurelemente:
- "Exchange Server (CO)" – 'n nodus / diens / komponent van 'n inligtingstelsel wat die funksie verrig om data met 'n ander inligtingstelsel uit te ruil.
- "Tussenganger" - 'n nodus/diens wat ontwerp is om interaksie tussen inligtingstelsels te organiseer, maar nie deel daarvan nie.
Voorbeelde "Tussengangers" kan e-posdienste, ondernemingsdiensbus / SoA-argitektuur, derdeparty-lêerbedieners, ens. In die algemene geval mag die integrasiemodule nie "Tussengangers" bevat nie. - "Dataverwerkingsagteware" - 'n stel programme wat data-uitruilprotokolle en formaatomskakeling implementeer.
Byvoorbeeld, die omskakeling van data van die UFEBS-formaat na die ABS-formaat, die verandering van boodskapstatusse tydens transmissie, ens. - "Netwerk konneksie" stem ooreen met die voorwerp wat beskryf word in die tipiese bedreigingsmodel "Netwerkverbinding". Sommige netwerkverbindings van dié wat in die diagram hierbo aangebied word, is dalk nie.
Voorbeelde van integrasiemodules
Skema 1. Integrasie van ABS en AWP KBR deur 'n derdeparty lêerbediener
Om betalings uit te voer, laai 'n gemagtigde werknemer van die bank elektroniese betalingsdokumente vanaf die ABS op en stoor dit in 'n lêer (van sy eie formaat, byvoorbeeld SQL-storting) op die netwerklêergids (...SHARE) van die lêerbediener. Dan word hierdie lêer omgeskakel na 'n stel lêers in die UFEBS-formaat met behulp van 'n omskakelingskrip, wat dan deur die CBD AWP gelees word.
Daarna enkripteer en onderteken 'n gemagtigde werknemer - 'n gebruiker van die AWS CBD - die ontvangde lêer en stuur dit na die betaalstelsel van die Bank van Rusland.
By ontvangs van betalings van die Bank van Rusland, dekripteer die AWP van die CBR dit en kontroleer die elektroniese handtekening, waarna dit dit as 'n stel lêers in die UFEBS-formaat na die lêerbediener skryf. Voordat betalingsdokumente in die ABS ingevoer word, word dit met behulp van 'n script-omskakelaar van die UFEBS-formaat na die ABS-formaat omgeskakel.
Ons sal aanvaar dat in hierdie skema die ABS op een fisiese bediener werk, die SSK werkstasie op 'n toegewyde rekenaar werk, en die script converter werk op 'n lêerbediener.
Ooreenstemming van die oogmerke van die oorweegde skema met die elemente van die model van die integrasiemodule:
"Uitruilbedieners vanaf die ABS-kant" - ABS-bediener.
"Ruil bedieners van die kant van die AWP KBR" - rekenaar werkstasie KBR.
"Tussenganger" - derdeparty lêerbediener.
"Dataverwerkingsagteware" - script converter.
Skema 2. Integrasie van ABS en AWS KBR wanneer 'n gedeelde netwerkgids met betalings op AWS KBR geplaas word
Alles is soortgelyk aan Skema 1, maar 'n aparte lêerbediener word nie gebruik nie; In plaas daarvan is 'n netwerklêergids (...SHARE) met elektroniese betalingsdokumente op 'n rekenaar met AWS CBD geleë. Die script-omskakelaar werk ook op AWP CBD.
Ooreenstemming van die oogmerke van die oorweegde skema met die elemente van die model van die integrasiemodule:
Soortgelyk aan Skema 1, maar "Tussenganger" nie gebruik nie.
Skema 3. Integrasie van ABS en AWS KBR-N deur IBM WebSphera MQ en ondertekening van elektroniese dokumente "aan die ABS-kant"
Die ABS werk op 'n platform wat nie deur CIPF SCUD Signature ondersteun word nie. Uitgaande elektroniese dokumente word op 'n spesiale elektroniese handtekeningbediener (ES Server) onderteken. Dieselfde bediener verifieer die elektroniese handtekening onder dokumente wat van die Bank van Rusland inkom.
Die ABS laai 'n lêer met betalingsdokumente in sy eie formaat op na die ES Server.
Die ES-bediener, met behulp van 'n omskakelingskrip, omskep die lêer in elektroniese boodskappe in die UFEBS-formaat, waarna die elektroniese boodskappe onderteken en na IBM WebSphere MQ oorgedra word.
AWS KBR-N kry toegang tot IBM WebSphere MQ en ontvang getekende betalingsboodskappe van daar af, waarna 'n gemagtigde werknemer - 'n gebruiker van AWS KBR - dit enkripteer en na die betaalstelsel van die Bank van Rusland stuur.
By ontvangs van betalings van die Bank van Rusland, dekripteer AWP KBR-N dit en verifieer die elektroniese handtekening. Suksesvol verwerkte betalings in die vorm van gedekripteerde en ondertekende elektroniese boodskappe in die UFEBS-formaat word na IBM WebSphere MQ oorgedra, vanwaar dit deur die ES-bediener ontvang word.
Die ES-bediener verifieer die elektroniese handtekening van ontvangde betalings en stoor dit in 'n lêer in ABS-formaat. Daarna laai 'n gemagtigde werknemer - die ABS-gebruiker - die resulterende lêer op die voorgeskrewe wyse op na die ABS.
Ooreenstemming van die oogmerke van die oorweegde skema met die elemente van die model van die integrasiemodule:
"Uitruilbediener vanaf die ABS-kant" - ABS-bediener.
"Uitruilbediener vanaf die kant van die AWP KBR" - rekenaar werkstasie KBR.
"Tussenganger" – ES-bediener en IBM WebSphere MQ.
"Dataverwerkingsagteware" – Skrip-omskakelaar, CIPF SCAD-handtekening op die ES-bediener.
Skema 4. Integrasie van die RBS-bediener en ABS deur die API wat deur 'n toegewyde uitruilbediener verskaf word
Ons neem aan dat die bank verskeie afgeleë bankstelsels (RBS) gebruik:
- "Internet Client-Bank" vir individue (ICB FL);
- "Internet Client-Bank" vir regsentiteite (ICB LE).
Ten einde inligtingsekuriteit te verseker, word alle interaksie van die ABS met RB-stelsels uitgevoer deur 'n toegewyde uitruilbediener wat binne die raamwerk van die ABS-inligtingstelsel werk.
Vervolgens sal ons die proses van interaksie van die RBS-stelsel van die ICB LE met die ABS oorweeg.
Die RBS-bediener, nadat hy 'n behoorlik gesertifiseerde betalingsbevel van die kliënt ontvang het, moet 'n toepaslike dokument in die ABS skep wat daarop gebaseer is. Om dit te doen, met behulp van die API, dra dit inligting oor na die uitruilbediener, wat op sy beurt data in die ABS invoer.
Wanneer die saldo's op die kliënt se rekening verander, genereer die ABS elektroniese kennisgewings, wat met behulp van die uitruilbediener na die RBS-bediener versend word.
Ooreenstemming van die oogmerke van die oorweegde skema met die elemente van die model van die integrasiemodule:
"Uitruilbediener vanaf RBS" – RBS-bediener IKB YUL.
"Uitruilbediener vanaf die ABS-kant" - ruil bediener.
"Tussenganger" - afwesig.
"Dataverwerkingsagteware" – RB-bedienerkomponente wat verantwoordelik is vir die gebruik van die uitruilbediener-API, uitruilbedienerkomponente wat verantwoordelik is vir die gebruik van die ABS-API.
Topvlak sekuriteitsbedreigings
Ontbinding
U1. Die bekendstelling van vals inligting deur kwaaddoeners deur die integrasiemodule.
U1. Die bekendstelling van vals inligting deur aanvallers deur die integrasiemodule
Ontbinding
U1.1. Ongemagtigde wysiging van wettige data tydens die oordrag daarvan oor netwerkverbindings:
U1.1.1 Skakel: .
Y1.2. Oordrag van vals data deur kommunikasiekanale namens 'n wettige uitruildeelnemer:
U1.1.2 Skakel: .
Y1.3. Ongemagtigde wysiging van wettige data tydens die verwerking daarvan op die Exchange Servers of die tussenganger:
Y1.3.1. Skakel: .
U1.4. Skep op die Exchange Servers of die tussenganger van vals data namens 'n wettige uitruildeelnemer:
Y1.4.1. Skakel:
Y1.5. Ongemagtigde wysiging van data tydens die verwerking daarvan met behulp van dataverwerkingsagteware:
U1.5.1. <…> as gevolg van die bekendstelling van ongemagtigde veranderinge deur indringers in die instellings (konfigurasie) van die dataverwerkingsagteware.
U1.5.2. <…> as gevolg van die indringers wat ongemagtigde veranderinge aan die uitvoerbare lêers van die dataverwerkingsagteware maak.
U1.5.3. <...> as gevolg van die interaktiewe beheer van dataverwerkingsagteware deur aanvallers.
TIPIESE BEDREIGINGSMODEL. KRYPTOGRAFIESE INLIGTING BESKERMINGSSTELSEL
Die beskermingsobjek waarvoor die bedreigingsmodel toegepas word (omvang)
Die doel van beskerming is die kriptografiese inligtingbeskermingstelsel wat gebruik word om die sekuriteit van die inligtingstelsel te verseker.
Argitektuur
Die basis van enige inligtingstelsel is toepassingsagteware (sagteware) wat sy teikenfunksionaliteit implementeer.
Kriptografiese beskerming in hierdie geval word gewoonlik geïmplementeer deur kriptografiese primitiewe te noem vanuit die besigheidslogika van die toepassingsagteware, wat in gespesialiseerde biblioteke geleë is - kripto-pitte.
Kriptografiese primitiewe sluit lae-vlak kriptografiese funksies in soos:
- enkripteer/dekripteer datablok;
- die elektroniese handtekening van die datablok te skep/verifieer;
- die hash-funksie van die datablok te bereken;
- genereer / laai / laai sleutelinligting op;
- ens.
Die besigheidslogika van die toepassingsagteware, met behulp van kriptografiese primitiewe, implementeer 'n hoër-vlak funksionaliteit:
- enkripteer die lêer met die sleutels van die geselekteerde ontvangers;
- vestig 'n veilige netwerkverbinding;
- inlig oor die resultate van verifikasie van die elektroniese handtekening;
- en so aan.
Die interaksie van besigheidslogika en kripto-kern kan uitgevoer word:
- direk, deur kriptografiese primitiewe uit die dinamiese biblioteke van die kriptokern (.DLL - vir Windows, .SO - vir Linux) deur die besigheidslogika te roep;
- direk deur kriptografiese koppelvlakke - omhulsels, byvoorbeeld, MS Crypto API, Java Cryptography Architecture, PKCS # 11, ens. In hierdie geval verwys die besigheidslogika na die kripto-koppelvlak, en dit vertaal die oproep na die ooreenstemmende kripto-kern, wat in hierdie geval word kripto-verskaffer genoem. Die gebruik van kriptografiese koppelvlakke laat toepassingsagteware toe om uit spesifieke kriptografiese algoritmes te abstraheer en meer buigsaam te wees.
Daar is twee tipiese skemas om 'n kriptokern te organiseer:
Skema 1 - Monolitiese kriptokern
Skema 2 - Verdeel Crypto Core
Die elemente in die diagramme hierbo kan óf afsonderlike sagtewaremodules wees wat op dieselfde rekenaar loop, óf netwerkdienste wat binne 'n rekenaarnetwerk interaksie het.
Wanneer stelsels gebruik word wat volgens skema 1 gebou is, werk die toepassingsagteware en die kriptokern binne 'n enkele omgewing vir die werking van 'n kripto-middel (CFC), byvoorbeeld op dieselfde rekenaar wat dieselfde bedryfstelsel bedryf. Die gebruiker van die stelsel kan as 'n reël ander programme binne dieselfde bedryfsomgewing laat loop, insluitend dié wat kwaadwillige kode bevat. In sulke toestande is daar 'n ernstige risiko van lekkasie van private kriptografiese sleutels.
Om die risiko te verminder, word skema 2 gebruik, waarin die kriptokern in twee dele verdeel word:
- Die eerste deel, saam met die toepassingsagteware, werk in 'n onbetroubare omgewing waar daar 'n risiko van infeksie met kwaadwillige kode is. Ons sal hierdie deel "sagteware deel" noem.
- Die tweede deel werk in 'n betroubare omgewing op 'n toegewyde toestel wat 'n privaat sleutelstoor bevat. Ons sal van nou af na hierdie deel as die "hardeware-deel" verwys.
Die verdeling van die kripto-kern in sagteware- en hardeware-onderdele is baie voorwaardelik. Daar is stelsels op die mark wat volgens die skema gebou is met 'n gesplete kriptokern, maar die "hardeware"-deel word aangebied in die vorm van 'n virtuele masjienbeeld - virtuele HSM ().
Die interaksie van beide dele van die kriptokern vind plaas op so 'n manier dat private kriptografiese sleutels nooit na die sagteware deel oorgedra word nie en gevolglik nie met kwaadwillige kode gesteel kan word nie.
Die interaksie-koppelvlak (API) en die stel kriptografiese primitiewe wat deur die kriptokern aan die toepassingsagteware verskaf word, is in beide gevalle dieselfde. Die verskil lê in die manier waarop hulle geïmplementeer word.
Dus, wanneer 'n skema met 'n verdeelde kriptokern gebruik word, word die interaksie tussen sagteware en hardeware volgens die volgende beginsel uitgevoer:
- Kriptografiese primitiewe wat nie die gebruik van 'n private sleutel vereis nie (byvoorbeeld berekening van 'n hash-funksie, verifikasie van 'n elektroniese handtekening, ens.) word deur die sagteware uitgevoer.
- Kriptografiese primitiewe wat 'n private sleutel gebruik (skep 'n elektroniese handtekening, dekripteer data, ens.) word deur die hardeware uitgevoer.
Kom ons illustreer die werking van 'n gesplete kriptokern deur die voorbeeld van die skep van 'n elektroniese handtekening te gebruik:
- Die sagteware-deel bereken die hash-funksie van die getekende data en stuur hierdie waarde na die hardeware oor via die uitruilkanaal tussen die kripto-kerne.
- Die hardeware-deel, met behulp van die private sleutel en hash, genereer die waarde van die elektroniese handtekening en dra dit oor na die sagteware-deel via die uitruilkanaal.
- Die sagteware-deel gee die ontvangde waarde terug na die toepassingsagteware.
Kenmerke van die kontrolering van die korrektheid van 'n elektroniese handtekening
Wanneer die ontvangende party data ontvang wat met 'n elektroniese handtekening onderteken is, moet dit verskeie stadiums van verifikasie uitvoer. 'n Positiewe resultaat van verifikasie van 'n elektroniese handtekening word slegs behaal as alle stadiums van verifikasie suksesvol voltooi is.
Fase 1. Beheer van data-integriteit en data-outeurskap.
Verhoog inhoud. Die elektroniese handtekening van die data word geverifieer volgens die ooreenstemmende kriptografiese algoritme. Suksesvolle voltooiing van hierdie stadium dui aan dat die data nie gewysig is sedert hulle onderteken is nie, en dat die handtekening gemaak is met 'n private sleutel wat ooreenstem met die publieke sleutel om die elektroniese handtekening te verifieer.
Ligging van die verhoog: kriptokern.
Fase 2. Beheer van vertroue in die publieke sleutel van die ondertekenaar en beheer van die geldigheidstydperk van die private sleutel van die elektroniese handtekening.
Verhoog inhoud. Die verhoog bestaan uit twee intermediêre sub-stadia. Die eerste een bepaal of die publieke sleutel vir die verifikasie van die elektroniese handtekening vertrou is ten tyde van die ondertekening van die data. Die tweede een bepaal of die private sleutel van die elektroniese handtekening geldig was ten tyde van die ondertekening van die data. In die algemene geval mag die geldigheidstydperke van hierdie sleutels nie saamval nie (byvoorbeeld vir gekwalifiseerde sertifikate van elektroniese handtekeningverifikasiesleutels). Metodes om vertroue in die ondertekenaar se publieke sleutel te vestig, word bepaal deur die reëls van elektroniese dokumentbestuur wat deur die interaktiewe partye aanvaar word.
Ligging van die verhoog: toepassingsagteware / kripto-kern.
Stadium 3. Beheer van die ondertekenaar se gesag.
Verhoog inhoud. In ooreenstemming met die vasgestelde reëls van elektroniese dokumentbestuur, word gekontroleer of die ondertekenaar die reg gehad het om die beskermde data te sertifiseer. Oorweeg byvoorbeeld die situasie van skending van gesag. Gestel daar is 'n organisasie waar alle werknemers 'n elektroniese handtekening het. Die interne elektroniese dokumentbestuurstelsel ontvang 'n bestelling van die hoof, maar onderteken deur die elektroniese handtekening van die pakhuisbestuurder. Gevolglik kan so 'n dokument nie as wettig beskou word nie.
Ligging van die verhoog: toepassingsprogrammatuur.
Aannames gemaak wanneer die voorwerp van beskerming beskryf word
- Inligtingsoordragkanale, met die uitsondering van sleuteluitruilkanale, gaan ook deur toepassingsagteware, API en kripto-kern.
- Inligting oor vertroue in publieke sleutels en (of) sertifikate, sowel as inligting oor die gesag van publieke sleuteleienaars, word in die publieke sleutelstoor geplaas.
- Die toepassingsagteware werk met die publieke sleutelberging deur die kripto-kern.
'n Voorbeeld van 'n inligtingstelsel wat met CIPF beskerm word
Om die voorheen aangebied skemas te illustreer, oorweeg 'n hipotetiese inligtingstelsel en kies al die strukturele elemente daarop.
Beskrywing van die inligtingstelsel
Die twee organisasies het besluit om wetlik bindende elektroniese dokumentbestuur (EDF) tussen hulle in te stel. Om dit te doen het hulle ’n ooreenkoms aangegaan waarin hulle verklaar het dat die dokumente per e-pos versend sal word, en terselfdertyd moet dit geïnkripteer en met ’n gekwalifiseerde elektroniese handtekening onderteken word. As 'n manier om dokumente te skep en te verwerk, moet kantoorprogramme van die Microsoft Office 2016-pakket gebruik word, en as middel van kriptografiese beskerming - CIPF CryptoPRO en enkripsiesagteware CryptoARM.
Beskrywing van die organisasie se infrastruktuur 1
Organisasie 1 het besluit dat dit CryptoPRO CIPF- en CryptoARM-sagteware op die gebruiker se werkstasie – ’n fisiese rekenaar – sal installeer. Enkripsie- en elektroniese handtekeningsleutels sal op die ruToken-sleuteldraer gestoor word wat in die herwinbare sleutelmodus werk. Die gebruiker sal elektroniese dokumente plaaslik op sy rekenaar voorberei, waarna dit geënkripteer, onderteken en gestuur sal word met behulp van 'n plaaslik geïnstalleerde poskliënt.
Beskrywing van die organisasie se infrastruktuur 2
Organisasie 2 het besluit om die funksies van enkripsie en elektroniese handtekening na 'n toegewyde virtuele masjien te skuif. In hierdie geval sal alle kriptografiese bewerkings outomaties uitgevoer word.
Om dit te doen, word twee netwerkvouers op 'n toegewyde virtuele masjien georganiseer: "...In", "...Out". Lêers wat in oop vorm van die teenparty ontvang word, sal outomaties in die "...In" netwerklêergids geplaas word. Hierdie lêers sal gedekripteer word en die elektroniese handtekening sal daarop geverifieer word.
In die "...Out"-lêergids sal die gebruiker lêers plaas wat geënkripteer, onderteken en aan die teenparty gestuur moet word. Die gebruiker sal self die lêers op sy werkstasie voorberei.
Om enkripsie- en elektroniese handtekeningfunksies uit te voer, word CryptoPRO CIPF, CryptoARM-sagteware en 'n poskliënt op die virtuele masjien geïnstalleer. Outomatiese bestuur van alle elemente van die virtuele masjien sal uitgevoer word met behulp van skrifte wat deur stelseladministrateurs ontwikkel is. Die werk van skrifte word in loglêers (logs) aangeteken.
Die kriptografiese sleutels van die elektroniese handtekening sal op 'n teken geplaas word met 'n JaCarta GOST nie-herhaalbare sleutel, wat die gebruiker aan sy plaaslike rekenaar sal koppel.
Die teken sal na die virtuele masjien aangestuur word deur gebruik te maak van gespesialiseerde USB-oor-IP-sagteware wat op die gebruiker se werkstasie en op die virtuele masjien geïnstalleer is.
Die stelselklok op die gebruiker se werkstasie in organisasie 1 sal met die hand aangepas word. Die stelselklok van die toegewyde virtuele masjien in organisasie 2 sal gesinchroniseer word met die stelselklok van die hipervisor, wat op sy beurt oor die internet met openbare tydbedieners gesinchroniseer sal word.
Toekenning van strukturele elemente van CIPF
Op grond van bogenoemde beskrywing van die IT-infrastruktuur, sonder ons die strukturele elemente van die CIPF uit en skryf dit in 'n tabel neer.
Tabel - Korrespondensie van die elemente van die CIPF-model met die elemente van inligtingstelsels
Element naam
Organisasie 1
Organisasie 2
Toepassingsprogrammatuur
CryptoARM sagteware
CryptoARM sagteware
Die sagteware deel van die kriptokern
CIPF CryptoPRO CSP
CIPF CryptoPRO CSP
Die hardeware deel van die kriptokern
geen
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Publieke sleutelberging
Gebruiker werkstasie:
- HDD;
- standaard Windows-sertifikaatwinkel.
Hipervisor:
-HDD.
Virtuele masjien:
- HDD;
- standaard Windows-sertifikaatwinkel.
Privaat sleutelberging
Sleuteldraer ruToken werk in die modus van onttrekbare sleutel
JaCarta GOST-sleuteldraer wat in nie-herwinbare sleutelmodus werk
Publieke sleutel-uitruilkanaal
Gebruiker werkstasie:
- RAM.
Hipervisor:
- RAM.
Virtuele masjien:
- RAM.
Privaat sleuteluitruilkanaal
Gebruiker werkstasie:
- USB-bus;
- RAM.
geen
Ruil kanaal tussen kripto-kerne
afwesig (geen cryptocore hardeware nie)
Gebruiker werkstasie:
- USB-bus;
- RAM;
- USB-oor-IP sagteware module;
- netwerk koppelvlak.
Korporatiewe netwerk van die organisasie 2.
Hipervisor:
- RAM;
- netwerk koppelvlak.
Virtuele masjien:
- netwerk koppelvlak;
- RAM;
- USB-oor-IP sagteware module.
Maak data-uitruilkanaal oop
Gebruiker werkstasie:
- middele van inset-uitset;
- RAM;
-HDD.
Gebruiker werkstasie:
- middele van inset-uitset;
- RAM;
- HDD;
- netwerk koppelvlak.
Korporatiewe netwerk van die organisasie 2.
Hipervisor:
- netwerk koppelvlak;
- RAM;
-HDD.
Virtuele masjien:
- netwerk koppelvlak;
- RAM;
-HDD.
Veilige data-uitruilkanaal
Internet.
Korporatiewe netwerk van die organisasie 1.
Gebruiker werkstasie:
- HDD;
- RAM;
- netwerk koppelvlak.
Internet.
Korporatiewe netwerk van die organisasie 2.
Hipervisor:
- netwerk koppelvlak;
- RAM;
-HDD.
Virtuele masjien:
- netwerk koppelvlak;
- RAM;
-HDD.
Tyd kanaal
Gebruiker werkstasie:
- middele van inset-uitset;
- RAM;
- stelsel timer.
Internet.
Korporatiewe netwerk van die organisasie 2,
Hipervisor:
- netwerk koppelvlak;
- RAM;
- stelsel timer.
Virtuele masjien:
- RAM;
- stelsel timer.
Beheer opdrag transmissiekanaal
Gebruiker werkstasie:
- middele van inset-uitset;
- RAM.
(GUI van CryptoARM sagteware)
Virtuele masjien:
- RAM;
-HDD.
(Outomatisering skrifte)
Kanaal vir die ontvangs van werkresultate
Gebruiker werkstasie:
- middele van inset-uitset;
- RAM.
(GUI van CryptoARM sagteware)
Virtuele masjien:
- RAM;
-HDD.
(Loglêers vir outomatiseringsskrifte)
Topvlak sekuriteitsbedreigings
verduidelikings
Aannames gemaak in die ontbinding van bedreigings:
- Sterk kriptografiese algoritmes word gebruik.
- Kriptografiese algoritmes word veilig gebruik in die korrekte werkingsmodusse (bv. is nie van toepassing op die enkripteer van groot hoeveelhede data nie, die toelaatbare las op die sleutel word in ag geneem, ens.).
- Misdadigers ken alle gebruikte algoritmes, protokolle en publieke sleutels.
- Aanvallers het toegang tot alle geënkripteerde data.
- Aanvallers is in staat om enige programelemente in die stelsel te reproduseer.
Ontbinding
U1. Kompromie van private kriptografiese sleutels.
U2. Enkripsie van vals data namens 'n wettige sender.
U3. Dekripsie van geënkripteerde data deur persone wat nie wettige ontvangers van data is nie (indringers).
U4. Skep van 'n elektroniese handtekening van 'n wettige ondertekenaar onder vals data.
U5. Verkry 'n positiewe resultaat van die kontrolering van die elektroniese handtekening van vals data.
U6. Foutiewe aanvaarding van elektroniese dokumente vir uitvoering as gevolg van probleme in die organisasie van elektroniese dokumentbestuur.
U7. Ongemagtigde toegang tot beskermde data tydens die verwerking daarvan deur CIPF.
U1. Kompromie van private kriptografiese sleutels
U1.1. Kry die private sleutel van die private sleutel winkel.
Y1.2. Die verkryging van 'n private sleutel uit die voorwerpe van die omgewing van funksionering van die kriptografiese instrument, waarin dit tydelik geleë kan wees.
Verduidelikings Y1.2.
Voorwerpe wat 'n private sleutel tydelik kan stoor, sal insluit:
- RAM,
- tydelike lêers,
- blaai lêers,
- hibernasie lêers,
- momentopname-lêers van die "warm" toestand van virtuele masjiene, insluitend lêers van die inhoud van die RAM van virtuele masjiene wat onderbreek is.
U1.2.1. Herwinning van private sleutels uit werkende RAM deur RAM-modules te vries, hulle te onttrek en dan die data te lees (vriesaanval).
Verduidelikings Y1.2.1.
Voorbeeld .
Y1.3. Verkryging van 'n private sleutel vanaf 'n privaat sleuteluitruilkanaal.
Verduidelikings Y1.3.
'n Voorbeeld van die implementering van hierdie bedreiging sal gegee word .
U1.4. Ongemagtigde wysiging van die kriptokern, as gevolg waarvan private sleutels aan aanvallers bekend word.
Y1.5. Kompromie van die private sleutel as gevolg van die gebruik van tegniese kanale van inligtinglekkasie (TCLE).
Verduidelikings Y1.5.
Voorbeeld .
U1.6. Kompromie van die private sleutel as gevolg van die gebruik van spesiale tegniese middele (STS) wat ontwerp is vir geheime herwinning van inligting ("bugs").
Y1.7. Kompromie van private sleutels tydens hul berging buite die CIPF.
Verduidelikings Y1.7.
Byvoorbeeld, 'n gebruiker hou hul sleutelmedia in 'n lessenaarlaai, waaruit dit maklik deur indringers opgespoor kan word.
U2. Enkripsie van vals data namens 'n wettige sender
verduidelikings
Hierdie bedreiging word slegs oorweeg vir data-enkripsieskemas met sender-verifikasie. Voorbeelde van sulke skemas word in die aanbevelings vir standaardisering aangedui. . Vir ander kriptografiese skemas bestaan hierdie bedreiging nie, aangesien enkripsie op die publieke sleutels van die ontvanger uitgevoer word, en dit is algemeen bekend aan aanvallers.
Ontbinding
U2.1. Kompromie van die sender se private sleutel:
Y2.1.1. Skakel: .
Y2.2. Vervanging van insetdata in die oop data-uitruilkanaal.
Notas U2.2.
Voorbeelde van die implementering van hierdie bedreiging word hieronder gegee. и .
U3. Dekripsie van geënkripteerde data deur persone wat nie wettige ontvangers van data is nie (indringers)
Ontbinding
Y3.1. Kompromie van private sleutels van die ontvanger van geënkripteerde data.
U3.1.1 Skakel: .
Y3.2. Vervanging van geënkripteerde data in 'n veilige data-uitruilkanaal.
U4. Skep van 'n elektroniese handtekening van 'n wettige ondertekenaar onder vals data
Ontbinding
Y4.1. Kompromie van private sleutels van die elektroniese handtekening van 'n wettige ondertekenaar.
U4.1.1 Skakel: .
Y4.2. Vervanging van ondertekende data in die oop data-uitruilkanaal.
Let wel U4.2.
Voorbeelde van die implementering van hierdie bedreiging word hieronder gegee. и .
U5. Verkry 'n positiewe resultaat van die kontrolering van die elektroniese handtekening van vals data
Ontbinding
Y5.1. Misdadigers onderskep in die kanaal van oordrag van resultate van werk die boodskap op negatiewe resultaat van kontrolering van die elektroniese handtekening en vervang dit met die boodskap met positiewe resultaat.
Y5.2. Aanvallers voer 'n aanval uit op vertroue in die ondertekening van sertifikate (SCENARIO - alle elemente word vereis):
Y5.2.1. Aanvallers genereer 'n publieke en private sleutel vir 'n elektroniese handtekening. As die stelsel elektroniese handtekeningsleutelsertifikate gebruik, genereer hulle 'n elektroniese handtekeningsertifikaat wat so soortgelyk as moontlik is aan die sertifikaat van die beweerde sender van die data wie se boodskap hulle wil vervals.
U5.2.2. Aanvallers maak ongemagtigde veranderinge aan die publieke sleutelstoor, en gee die publieke sleutel wat deur hulle gegenereer word met die nodige vlak van vertroue en gesag.
Y5.2.3. Aanvallers onderteken vals data met 'n voorheen gegenereerde elektroniese handtekeningsleutel en sluit dit in 'n veilige data-uitruilkanaal in.
Y5.3. Aanvallers voer 'n aanval uit deur elektroniese handtekeningsleutels van 'n wettige ondertekenaar te gebruik (SCENARIO - alle elemente word vereis):
Y5.3.1. Aanvallers kompromitteer die vervalde (nie tans geldige) private sleutels van die wettige sender se elektroniese handtekening.
Y5.3.2. Aanvallers vervang die tyd in die tydoordragkanaal met die tyd waarop die gekompromitteerde sleutels nog geldig was.
Y5.3.3. Aanvallers onderteken vals data met 'n voorheen gekompromitteerde elektroniese handtekeningsleutel en sluit dit in 'n veilige data-uitruilkanaal in.
Y5.4. Aanvallers voer 'n aanval uit met behulp van gekompromitteerde elektroniese handtekeningsleutels van 'n wettige ondertekenaar (SCENARIO - alle elemente word vereis):
Y5.4.1. Die aanvallers maak 'n kopie van die publieke sleutelstoor.
Y5.4.2. Aanvallers kompromitteer die private sleutels van een van die wettige senders. Hy merk die kompromie op, trek die sleutels terug, inligting oor die herroeping van die sleutel word in die publieke sleutelstoor geplaas.
Y5.4.3. Die aanvallers vervang die publieke sleutelstoor met die voorheen gekopieerde een.
Y5.4.4. Aanvallers onderteken vals data met 'n voorheen gekompromitteerde elektroniese handtekeningsleutel en sluit dit in 'n veilige data-uitruilkanaal in.
Y5.5. <...> as gevolg van die teenwoordigheid van foute in die implementering van die 2de en 3de stadiums van elektroniese handtekeningverifikasie:
Verduidelikings Y5.5.
'n Voorbeeld van die implementering van hierdie bedreiging word gegee .
U5.5.1. Verifikasie van vertroue in die sertifikaat van die elektroniese handtekeningsleutel slegs deur die teenwoordigheid van vertroue in die sertifikaat waarmee dit onderteken is, sonder CRL- of OCSP-kontroles.
Verduidelikings Y5.5.1.
Implementering voorbeeld .
U5.5.2. Wanneer 'n vertrouesketting vir 'n sertifikaat gebou word, word die gesag om sertifikate uit te reik nie ontleed nie
Verduidelikings Y5.5.2.
'n Voorbeeld van 'n aanval teen SSL/TLS-sertifikate.
Die aanvallers het ’n wettige sertifikaat vir hul e-pos gekoop. Hulle het toe ’n bedrieglike webwerfsertifikaat gemaak en dit met hul eie sertifikaat onderteken. As die geloofsbriewe nie uitgevoer word nie, sal dit korrek blyk te wees wanneer die vertrouesketting nagegaan word, en dienooreenkomstig sal die bedrieglike sertifikaat ook korrek wees.
Y5.5.3. Wanneer 'n sertifikaattrustketting gebou word, word intermediêre sertifikate nie vir herroeping nagegaan nie.
Y5.5.4. CRL's word minder gereeld opgedateer as wat die sertifikaatowerheid dit uitreik.
Y5.5.5. Die besluit om die elektroniese handtekening te vertrou word geneem voordat die OCSP-antwoord oor die status van die sertifikaat ontvang is, gestuur op 'n versoek wat later as die handtekeninggenereringstyd gemaak is of vroeër as die volgende een nadat die CRL-ondertekening ontvang is.
Verduidelikings Y5.5.5.
In die regulasies van die meeste GR'e word die sertifikaatherroepingstyd beskou as die tyd van uitreiking van die naaste CRL wat inligting bevat oor die herroeping van die sertifikaat.
U5.5.6. By ontvangs van getekende data word die eienaarskap van die sertifikaat deur die sender nie nagegaan nie.
Verduidelikings Y5.5.6.
Aanval voorbeeld. Vir SSL-sertifikate, sal dit dalk nie kyk of die adres van die opgeroep bediener ooreenstem met die waarde van die CN-veld in die sertifikaat nie.
Aanval voorbeeld. Die aanvallers het die elektroniese handtekeningsleutels van een van die deelnemers aan die betalingstelsel in gevaar gestel. Daarna het hulle die netwerk van 'n ander deelnemer gekap en namens hom betaaldokumente wat met gekompromitteerde sleutels onderteken is, na die vereffeningsbediener van die betaalstelsel gestuur. As die bediener slegs vertroue ontleed en nie nagaan vir voldoening nie, sal bedrieglike dokumente as wettig beskou word.
U6. Foutiewe aanvaarding van elektroniese dokumente vir uitvoering as gevolg van probleme in die organisasie van elektroniese dokumentbestuur.
Ontbinding
U6.1. Die ontvangende party bespeur nie duplisering van ontvangde dokumente nie.
Verduidelikings Y6.1.
Aanval voorbeeld. Misdadigers kan die dokument wat na die ontvanger oorgedra is, onderskep, selfs al is dit kriptografies beskerm, en dit dan herhaaldelik na die veilige data-oordragkanaal stuur. As die ontvanger nie duplikate opspoor nie, sal alle ontvangde dokumente as verskillende dokumente waargeneem en verwerk word.
U7. Ongemagtigde toegang tot beskermde data tydens die verwerking daarvan deur CIPF
Ontbinding
U7.1. <…> as gevolg van inligtinglekkasie deur derdeparty-kanale (sykanaalaanval).
Verduidelikings Y7.1.
Voorbeeld .
U7.2. <...> as gevolg van die neutralisering van beskerming teen ongemagtigde toegang tot inligting wat op CIPF verwerk word:
Y7.2.1. Werking van CIPF met oortredings van die vereistes beskryf in die dokumentasie vir CIPF.
Y7.2.2. <…> geïmplementeer as gevolg van die teenwoordigheid van kwesbaarhede in:
Y7.2.2.1. <…> middel van beskerming teen ongemagtigde toegang.
Y7.2.2.2. <…> die CIPF self.
Y7.2.2.3. <...> die omgewing vir die funksionering van die kriptografiese hulpmiddel.
Aanval voorbeelde
Die scenario's wat hieronder bespreek word, bevat uiteraard foute in die organisasie van inligtingsekuriteit en dien slegs om moontlike aanvalle te illustreer.
Scenario 1. 'n Voorbeeld van die implementering van bedreigings U2.2 en U4.2.
Beskrywing van die voorwerp
ARM KBR-sagteware en CIPF SCAD Signature is geïnstalleer op 'n fisiese rekenaar wat nie aan 'n rekenaarnetwerk gekoppel is nie. Die FKN vdToken word gebruik as 'n sleuteldraer in die werkingsmodus met 'n nie-herwinbare sleutel.
Die skikkingsregulasie veronderstel dat die skikkingspesialis vanaf sy werkrekenaar elektroniese boodskappe in duidelike teks (die skema van die ou KBR AWS) vanaf 'n spesiale veilige lêerbediener aflaai, dit dan na 'n verwyderbare USB-flitsskyf skryf en dit na die KBR AWP oordra. , waar hulle geïnkripteer is en tekens. Daarna dra die spesialis veilige elektroniese boodskappe oor na 'n oordraagbare medium, en skryf dit dan deur sy werkrekenaar na 'n lêerbediener, van waar hulle by UTA kom en dan na die betaalstelsel van die Bank van Rusland.
In hierdie geval sal die kanale vir die uitruil van oop en veilige data die volgende insluit: 'n lêerbediener, 'n spesialis se werkrekenaar en 'n oordraagbare media.
aanval
Ongemagtigde aanvallers installeer 'n afstandbeheerstelsel op die spesialis se werkrekenaar en vervang, ten tyde van die opneem van betalingsopdragte (elektroniese boodskappe) op die oordraagbare medium, openlik die inhoud van een daarvan. Die spesialis dra die betalingsopdragte oor na die AWS van die KBR, teken en enkripteer dit sonder om die vervanging op te let (byvoorbeeld weens die groot aantal betalingsopdragte op die vlug, moegheid, ens.). Daarna gaan die vals betalingsbevel, wat deur die tegnologiese ketting gegaan het, die betalingsstelsel van die Bank van Rusland binne.
Scenario 2. 'n Voorbeeld van die implementering van bedreigings U2.2 en U4.2.
Beskrywing van die voorwerp
Die rekenaar met die geïnstalleerde AWS KBR, SKAD Handtekening en die gekoppelde sleuteldraer van die FKN vdToken werk in 'n toegewyde kamer sonder toegang van die personeel.
Die nedersettingspesialis koppel aan die AWS van die KBR in die afstandtoegangsmodus via die HOP-protokol.
aanval
Aanvallers onderskep die besonderhede, met behulp waarvan die skikkingspesialis verbind en met die KBR-geoutomatiseerde werkplek werk (byvoorbeeld as gevolg van kwaadwillige kode op sy rekenaar). Dan verbind hulle namens hom en stuur 'n vals betalingsbevel na die betaalstelsel van die Bank van Rusland.
Scenario 3. 'n Voorbeeld van die implementering van die bedreiging U1.3.
Beskrywing van die voorwerp
Kom ons kyk na een van die hipotetiese opsies vir die implementering van ABS-KBR-integrasiemodules vir die nuwe skema (ARM KBR-N), waarin die elektroniese handtekening van uitgaande dokumente aan die kant van die ABS voorkom. Terselfdertyd sal ons aanvaar dat die ABS werk op die basis van 'n bedryfstelsel wat nie deur die CIPF SKAD Signature ondersteun word nie, en dienooreenkomstig word die kriptografiese funksionaliteit op 'n aparte virtuele masjien geplaas - die ABS-CBR-integrasiemodule .
'n Gereelde USB-token wat in die verwyderbare sleutelmodus werk, word as 'n sleuteldraer gebruik. Toe die sleuteldraer aan die hipervisor gekoppel is, het dit geblyk dat daar geen vrye USB-poorte in die stelsel was nie, daarom is besluit om die USB-token deur 'n netwerk-USB-hub te koppel, en 'n USB-oor-IP-kliënt op die virtuele masjien wat met die spilpunt sal kommunikeer.
aanval
Die aanvallers het die private sleutel van die elektroniese handtekening onderskep vanaf die kommunikasiekanaal tussen die USB-hub en die hipervisor (die data is in duidelike teks versend). Met 'n private sleutel het die aanvallers 'n vals betalingsbevel gegenereer, dit met 'n elektroniese handtekening onderteken en dit na die KBR-N outomatiese werkplek gestuur vir uitvoering.
Scenario 4. 'n Voorbeeld van die implementering van bedreigings U5.5.
Beskrywing van die voorwerp
Oorweeg dieselfde stroombaan as in die vorige scenario. Ons sal aanvaar dat e-posse wat vanaf die KBR-N-werkstasie kom, in die …SHAREIn-lêergids beland, en dié wat na die KBR-N-werkstasie en verder na die Bank of Russia-betalingstelsel gestuur word, gaan na …SHAREout.
Ons sal ook aanvaar dat wanneer die integrasiemodule geïmplementeer word, die lyste van herroepe sertifikate slegs bygewerk word wanneer kriptografiese sleutels heruitgereik word, en ook dat elektroniese boodskappe wat in die …SHAREIn-lêergids ontvang word, slegs nagegaan word vir integriteitsbeheer en vertrouebeheer na die publieke sleutel van die elektroniese handtekening.
aanval
Die aanvallers, met behulp van die sleutels wat in die vorige scenario gesteel is, het 'n vals betalingsbevel onderteken wat inligting bevat oor die ontvangs van geld op die rekening van 'n bedrieglike kliënt en dit in 'n veilige data-uitruilkanaal ingebring. Aangesien daar geen verifikasie is dat die betalingsbevel deur die Bank van Rusland onderteken is nie, word dit vir uitvoering aanvaar.
Bron: will.com