Links naar andere delen van het onderzoek
- (U bent hier)
Dit artikel sluit de reeks publicaties af die zijn gewijd aan de waarborging van de informatiebeveiliging van bankbetalingen zonder contant geld. Hier zullen we de typische bedreigingsmodellen bespreken, waarnaar verwezen is in :
- .
- .
- .
- .
HABRO-WAARSCHUWING!!! Geachte deelnemers, dit is geen vermaakspost.
Verborgen onder de knip zijn er 40+ pagina's materiaal bedoeld om te helpen in werk of studie voor mensen die gespecialiseerd zijn in bankieren of informatiebeveiliging. Deze materialen zijn het eindproduct van het onderzoek en zijn geschreven in een zakelijke, officiële toon. Het zijn in wezen sjablonen voor interne documenten over informatiebeveiliging.En traditioneel — «het gebruik van informatie uit het artikel voor onwettige doeleinden wordt door de wet vervolgd». Productief lezen!
Informatie voor lezers die het onderzoek beginnen met deze publicatie.
Over het onderzoek
U leest een gids voor de specialist die verantwoordelijk is voor de waarborging van de informatiebeveiliging van betalingen in de bank.
Logica van de presentatie
Aan het begin wordt en een beschrijving van het te beschermen object gegeven. Vervolgens in Het beschrijft hoe een beveiligingssysteem te bouwen en benadrukt de noodzaak om een bedreigingsmodel op te stellen. In wordt besproken welke bedreigingsmodellen er zijn en hoe deze worden gevormd. In en wordt een analyse van echte aanvallen gepresenteerd. en bevat een beschrijving van het bedreigingsmodel, opgebouwd met informatie uit alle voorgaande delen.
TYPE BEDREIGINGSMODEL. NETWERKVERBINDING
Het beschermde object waarvoor het bedreigingsmodel wordt toegepast (scope)
Het beschermde object zijn de gegevens die via een netwerkverbinding worden verzonden, werkend in datanetwerken gebaseerd op de TCP/IP-stack.
Architectuur
Beschrijving van de architectuurelementen:
- ‘Eindpunten’ — knooppunten die beschermde informatie uitwisselen.
- ‘Tussenknopen’ — elementen van het datanetwerk: routers, switches, toegangservers, proxyservers en andere apparatuur, waardoor het verkeer van de netwerkverbinding wordt verzonden. In het algemeen kan een netwerkverbinding functioneren zonder tussenknopen (rechtstreeks tussen eindpunten).
Beveiligingsbedreigingen op hoog niveau
Decompositie
U1. Ongeauthoriseerde toegang tot verzonden gegevens.
U2. Ongeauthoriseerde wijziging van verzonden gegevens.
U3. Overtreding van auteursrechten van verzonden gegevens.
U1. Ongeauthoriseerde toegang tot verzonden gegevens
Decompositie
U1.1. , uitgevoerd op eind- of tussenknopen:
U1.1.1. door gegevens te lezen terwijl ze zich bevinden in de opslagmedia van het knooppunt:
U1.1.1.1. in het werkgeheugen.
Toelichtingen op U1.1.1.1.
Bijvoorbeeld, tijdens de verwerking van gegevens door de netwerkstack van het knooppunt.
U1.1.1.2. in niet-vluchtig geheugen.
Toelichtingen op U1.1.1.2.
Bijvoorbeeld, wanneer verzonden gegevens worden opgeslagen in de cache, tijdelijke bestanden of swap-bestanden.
U1.2. , uitgevoerd op externe knopen in het datanetwerk:
U1.2.1. door alle pakketten die op de netwerkinterface van het knooppunt binnenkomen te vangen:
Toelichtingen op U1.2.1.
Het vangen van alle pakketten gebeurt door de netwerkadapter in promiscuous mode te zetten (promiscuous mode voor bekabelde adapters of in monitor mode voor Wi-Fi-adapters).
U1.2.2. door aanvallen van het type ‘man-in-the-middle (MiTM)’ uit te voeren, maar zonder de verzonden gegevens aan te passen (behalve voor de headers van de netwerkprotocollen).
U1.2.2.1. Link: .
U1.3. , uitgevoerd door middel van informatielekken via technische kanalen (TKUI) van fysieke knooppunten of communicatieverbindingen.
U1.4. , uitgevoerd door het plaatsen van speciale technische middelen (STM) op eind- of tussenknooppunten, bedoeld voor het heimelijk opnemen van informatie.
U2. Ongeautoriseerde modificatie van verzonden gegevens
Decompositie
U2.1. , uitgevoerd op eind- of tussenknooppunten:
U2.1.1. door het lezen en aanpassen van gegevens terwijl deze in de opslagmedia van de knooppunten zijn:
U2.1.1.1. in het werkgeheugen:
U2.1.1.2. in de niet-vluchtige opslag:
U2.2. , uitgevoerd op externe knooppunten van het datatransmissienetwerk:
U2.2.1. door het uitvoeren van Man-in-the-Middle (MiTM) aanvallen en het omleiden van verkeer naar het knooppunt van de aanvaller:
U2.2.1.1. Fysieke verbinding van de apparatuur van de aanvaller in de netwerkverbinding.
U2.2.1.2. Uitvoering van aanvallen op netwerkprotocollen:
U2.2.1.2.1. beheer van virtuele LAN's (VLAN):
U2.2.1.2.1.1. .
U2.2.1.2.1.2. Ongeautoriseerde modificatie van VLAN-instellingen op switches of routers.
U2.2.1.2.2. routering van verkeer:
U2.2.1.2.2.1. Ongeautoriseerde modificatie van statische routeringstabellen van routers.
U2.2.1.2.2.2. Aankondiging van valse routes door aanvallers via dynamische routeringsprotocollen.
U2.2.1.2.3. automatische configuratie:
U2.2.1.2.3.1. .
U2.2.1.2.3.2. .
U2.2.1.2.4. adressering en naamresolutie:
U2.2.1.2.4.1. .
U2.2.1.2.4.2. .
U2.2.1.2.4.3. Ongeautoriseerde wijzigingen aanbrengen in lokale hostbestanden (hosts, lmhosts, enz.)
U3. Inbreuk op auteursrecht van verzonden gegevens
Decompositie
U3.1. Neutralisatie van mechanismen voor het bepalen van de auteurschap van informatie door valse informatie over de auteur of gegevensbron op te geven:
U3.1.1. Wijziging van de auteur-informatie die in de verzonden gegevens is opgenomen.
U3.1.1.1. Neutralisatie van cryptografische waarborgen voor integriteit en auteurschap van verzonden gegevens:
U3.1.1.1.1. Verwijzing: .
U3.1.1.2. Neutralisatie van de auteursrechtenbescherming van verzonden gegevens, gerealiseerd met behulp van eenmalige bevestigingscodes:
U3.1.1.2.1. .
U3.1.2. Wijziging van gegevens over de bron van verzonden informatie:
U3.1.2.1. .
U3.1.2.2. .
TYPEMODEL VAN BEDREIGING. INFORMATIESYSTEEM GEBASEERD OP CLIENT-SERVER ARCHITECTUUR
Het beschermde object waarvoor het bedreigingsmodel wordt toegepast (scope)
Het doel van de bescherming is een informatiesysteem dat is gebaseerd op client-serverarchitectuur.
Architectuur
Beschrijving van de architectuurelementen:
- ‘Client’ – een apparaat waarop de clientzijde van het informatiesysteem functioneert.
- ‘Server’ – een apparaat waarop de serverzijde van het informatiesysteem functioneert.
- ‘Gegevensopslag’ – deel van de serverinfrastructuur van het informatiesysteem, bestemd voor de opslag van gegevens die door het informatiesysteem worden verwerkt.
- ‘Netwerkverbinding’ – het communicatiekanaal tussen de Client en de Server, dat door een datanetwerk loopt. Een gedetailleerde beschrijving van het model van het element is opgenomen in .
Beperkingen
Bij het modelleren van het object zijn de volgende beperkingen vastgesteld:
- De gebruiker interacteert met het informatiesysteem binnen eindige tijdsintervallen, die sessies van activiteit worden genoemd.
- Aan het begin van elke sessie vindt identificatie, authenticatie en autorisatie van de gebruiker plaats.
- Alle beschermde informatie wordt opgeslagen op de serverzijde van het informatiesysteem.
Beveiligingsbedreigingen op hoog niveau
Decompositie
U1. Het uitvoeren van niet-autorisatie handelingen door kwaadwillenden namens een legitieme gebruiker.
U2. Niet-geautoriseerde wijziging van beschermde informatie tijdens de verwerking door de serverzijde van het informatiesysteem.
U1. Het uitvoeren van niet-autorisatie handelingen door kwaadwillenden namens een legitieme gebruiker.
Uitleg
Gewoonlijk wordt in informatiesystemen de correlatie van handelingen met de uitvoerende gebruiker uitgevoerd met behulp van:
- systeemlogboeken (logs).
- speciale attributen van gegevenselementen die informatie bevatten over de gebruiker die ze heeft gemaakt of gewijzigd.
Met betrekking tot de sessie kan deze bedreiging worden gedemonteerd in:
- uitgevoerd binnen de sessie van de gebruiker.
- uitgevoerd buiten de sessie van de gebruiker.
De sessie van de gebruiker kan worden geïnitieerd door:
- De gebruiker zelf.
- Kwaadwillenden.
Op dit moment ziet de tussentijdse decompositie van deze bedreiging er als volgt uit:
U1.1. Ongeoorloofde acties zijn uitgevoerd binnen de sessie van de gebruiker:
U1.1.1. , ingesteld door de aangevallen gebruiker.
U1.1.2. , ingesteld door kwaadwillenden.
U1.2. Ongeoorloofde acties zijn uitgevoerd buiten de gebruiksessie.
Vanuit het perspectief van de objecten van de informatie-infrastructuur die door kwaadwillenden kunnen worden beïnvloed, zal de decompositie van tussentijdse bedreigingen als volgt zijn:
Elementen
Decompositie van bedreigingen
U1.1.1.
U1.1.2.
U1.2.
Klant
U1.1.1.1.
U1.1.2.1.
Netwerkverbinding
U1.1.1.2.
Server
U1.2.1.
Decompositie
U1.1. Ongeoorloofde acties zijn uitgevoerd binnen de sessie van de gebruiker:
U1.1.1. , ingesteld door de aangevallen gebruiker:
U1.1.1.1. Kwaadwillenden handelen zelfstandig vanaf de Client:
U1.1.1.1.1 Kwaadwillenden gebruikten standaard toegangsmethoden van het informatiesysteem:
U1.1.1.1.1.1. Kwaadwillenden gebruikten fysieke invoer- en uitvoerapparaten van de Client (toetsenbord, muis, monitor of touchscreen van het mobiele apparaat):
U1.1.1.1.1.1.1. Kwaadwillenden handelden tijdens periodes wanneer de sessie actief is, invoer- en uitvoerapparaten beschikbaar zijn en de gebruiker niet aanwezig is.
U1.1.1.1.1.2. Kwaadwillenden gebruikten middelen voor externe administratie (standaard of geleverd door kwaadaardige code) om de Client te beheren:
U1.1.1.1.1.2.1. Kwaadwillenden handelden tijdens periodes wanneer de sessie actief is, invoer- en uitvoerapparaten beschikbaar zijn en de gebruiker niet aanwezig is.
U1.1.1.1.1.2.2. Kwaadwillenden gebruikten middelen voor externe administratie die onopgemerkt blijven door de aangevallen gebruiker.
U1.1.1.2. Kwaadwillenden vervingen gegevens in de netwerkverbinding tussen de Client en de Server, door deze zodanig te wijzigen dat ze werden waargenomen als acties van een legitieme gebruiker:
U1.1.1.2.1. Link: .
U1.1.1.3. Kwaadwillenden dwongen de gebruiker om de opgelegde acties uit te voeren, met behulp van sociale-engineering technieken.
U1.1.2 ingesteld door kwaadwillenden:
U1.1.2.1. Kwaadwillenden handelden vanaf de Client (En):
U1.1.2.1.1. Kwaadwillenden neutraliseerden het toegangssysteem van het informatiesysteem:
U1.1.2.1.1.1. Link: .
U1.1.2.1.2. Aanvallers gebruikten standaard toegangsmechanismen van het informatiesysteem.
U1.1.2.2. Aanvallers opereerden vanaf andere knooppunten van het datanetwerk, van waaruit een netwerkverbinding met de Server kon worden opgezet (En):
U1.1.2.2.1. Aanvallers neutraliseerden het toegangscontrolesysteem van het informatiesysteem:
U1.1.2.2.1.1. Link: .
U1.1.2.2.2. Aanvallers gebruikten niet-standaard toegangsmechanismen van het informatiesysteem.
Toelichtingen U1.1.2.2.2.
Aanvallers konden de standaardclient van het informatiesysteem op een extern knooppunt installeren of niet-standaard software gebruiken die de standaardprotocollen voor communicatie tussen de Client en de Server implementeert.
U1.2 Ongeoorloofde acties uitgevoerd buiten de werksessie van de gebruiker.
U1.2.1 Aanvallers voerden ongeoorloofde acties uit en brachten vervolgens ongeoorloofde wijzigingen aan in de logboeken van het informatiesysteem of speciale attributen van data-objecten, waarbij ze aangaven dat hun acties door een legitieme gebruiker waren uitgevoerd.
U2. Ongeoorloofde wijziging van beschermde informatie tijdens de verwerking door de server van het informatiesysteem.
Decompositie
U2.1. Aanvallers wijzigen beschermde informatie met behulp van standaardmiddelen van het informatiesysteem en doen dit onder de naam van een legitieme gebruiker.
U2.1.1. Link: .
U2.2. Aanvallers wijzigen beschermde informatie door gebruik te maken van mechanismen voor gegevensbenadering die niet zijn voorzien door de standaardwerkwijze van het informatiesysteem.
U2.2.1. Aanvallers wijzigen bestanden die beschermde informatie bevatten:
U2.2.1.1. , door gebruik te maken van de bestandsmechanismen die door het besturingssysteem worden aangeboden.
U2.2.1.2. door de provocatie van het herstellen van bestanden vanuit een ongeoorloofd gewijzigde back-up.
U2.2.2. Aanvallers wijzigen beschermde informatie die in de database is opgeslagen (En):
U2.2.2.1. Aanvallers neutraliseren het toegangscontrolesysteem van de database:
U2.2.2.1.1. Link: .
U2.2.2.2. Aanvallers wijzigen informatie met behulp van de standaardinterfaces van de database om toegang te krijgen tot gegevens.
U2.3. Aanvallers wijzigen beschermde informatie door ongeautoriseerde aanpassing van de algoritmen van de software die deze verwerkt.
U2.3.1. De broncode van de software wordt aangepast.
U2.3.1. De machinecode van de software wordt aangepast.
U2.4. Aanvallers wijzigen beschermde informatie door gebruik te maken van kwetsbaarheden in de software van het informatiesysteem.
U2.5. Aanvallers wijzigen beschermde informatie tijdens de overdracht tussen de componenten van de serverzijde van het informatiesysteem (bijvoorbeeld tussen de database server en de applicatieserver):
U2.5.1. Link: .
TYPISCH BEDREIGINGSMODEL. TOEGANGSBEHEERSYSTEEM
Het beschermde object waarvoor het bedreigingsmodel wordt toegepast (scope)
Het object dat wordt beschermd in dit bedreigingmodel komt overeen met het object van bescherming in het bedreigingmodel: "Typisch bedreigingmodel. Informatie systeem, gebouwd op basis van client-serverarchitectuur."
Onder het toegangsbeheersysteem voor gebruikers in dit bedreigingmodel verstaan we een component van het informatiesysteem die de functies uitvoert:
- Identificatie van gebruikers.
- Authenticatie van gebruikers.
- Autorisatie van gebruikers.
- Protocollering van gebruikersacties.
Beveiligingsbedreigingen op hoog niveau
Decompositie
U1. Ongeautoriseerde sessie-instelling namens een legitieme gebruiker.
U2. Ongeautoriseerde privilegeverhoging van een gebruiker in het informatiesysteem.
U1. Ongeautoriseerde sessie-instelling namens een legitieme gebruiker
Uitleg
De decompositie van deze bedreiging is in het algemeen afhankelijk van het type systemen voor identificatie en authenticatie van gebruikers dat wordt toegepast.
In dit model wordt alleen het systeem voor identificatie en authenticatie van gebruikers behandeld dat gebruikmaakt van tekstinvoer van gebruikersnaam en wachtwoord. We gaan ervan uit dat de gebruikersnaam openbare informatie is die bekend is bij aanvallers.
Decompositie
U1.1. door compromittering van inloggegevens:
U1.1.1. Aanvallers hebben de inloggegevens van de gebruiker gecompromitteerd tijdens hun opslag.
Toelichting U1.1.1.
Bijvoorbeeld, de inloggegevens kunnen op een sticker zijn geschreven die op de monitor is geplakt.
U1.1.2. De gebruiker heeft per ongeluk of met kwade opzet zijn toegangsgegevens aan kwaadwillenden doorgegeven.
U1.1.2.1. De gebruiker heeft zijn inloggegevens hardop uitgesproken tijdens het invoeren.
U1.1.2.2. De gebruiker heeft opzettelijk zijn inloggegevens doorgegeven:
U1.1.2.2.1. aan collega's.
Toelichtingen U1.1.2.2.1.
Bijvoorbeeld, zodat zij hem kunnen vervangen tijdens ziekte.
U1.1.2.2.2. aan de zakenpartners van de werkgever die werkzaamheden uitvoeren aan objecten van de informatiestructuur.
U1.1.2.2.3. aan derden.
Toelichtingen U1.1.2.2.3.
Een, maar niet de enige manier waarop deze bedreiging kan worden gerealiseerd, is het gebruik van sociale-engineeringmethoden door kwaadwillenden.
U1.1.3. Kwaadwillenden hebben inloggegevens verkregen door middel van brute-force-aanvallen:
U1.1.3.1. met gebruik van de standaard toegangsmethoden.
U1.1.3.2. op basis van eerder onderschepte codes (bijvoorbeeld, hashen van wachtwoorden) voor het opslaan van inloggegevens.
U1.1.4. Kwaadwillenden hebben kwaadaardige code gebruikt om de inloggegevens van de gebruiker te onderscheppen.
U1.1.5. Kwaadwillenden hebben inloggegevens verkregen uit de netwerkverbinding tussen de Klant en de Server:
U1.1.5.1. Link: .
U1.1.6. Kwaadwillenden hebben inloggegevens verkregen uit registraties van monitoring systemen:
U1.1.6.1. van bewakingscamera's (indien tijdens het werk de toetsaanslagen op het toetsenbord werden geregistreerd).
U1.1.6.2. van systemen die de acties van werknemers op de computer controleren.
Toelichtingen U1.1.6.2.
Een voorbeeld van een dergelijk systeem is — .
U1.1.7. Kwaadwillenden hebben de inloggegevens van de gebruiker gecompromitteerd vanwege tekortkomingen in het proces van overdracht.
Toelichtingen U1.1.7.
Bijvoorbeeld, het versturen van wachtwoorden in ongecodeerde vorm via e-mail.
U1.1.8. Kwaadwillenden hebben de inloggegevens verkregen door observatie tijdens de werksessie van de gebruiker via remote management systemen.
U1.1.9. Kwaadwillenden hebben inloggegevens verkregen door uitlekkende technische kanalen (TGU):
U1.1.9.1. Kwaadwillenden hebben gezien hoe de gebruiker inloggegevens op het toetsenbord invoert:
U1.1.9.1.1. Kwaadwillenden bevonden zich in direct zicht van de gebruiker en zagen de invoer van inloggegevens met eigen ogen.
Toelichtingen U1.1.9.1.1.
Dergelijke gevallen omvatten acties van collega's op het werk of een situatie waarbij het toetsenbord van de gebruiker zichtbaar is voor bezoekers van de organisatie.
U1.1.9.1.2 Aanvallers gebruikten aanvullende technische middelen, zoals een verrekijker of een drone, en zagen inloggegevens via een raam.
U1.1.9.2. Aanvallers haalden inloggegevens uit radioverkeersregistraties tussen het toetsenbord en de computer, als deze via een radiokoppeling (bijvoorbeeld Bluetooth) waren verbonden.
U1.1.9.3. Aanvallers onderschepten inloggegevens door ze te laten lekken via zij-elektromagnetische straling en inducties (PEM).
Toelichtingen U1.1.9.3.
Voorbeelden van aanvallen en .
U1.1.9.4. De aanvaller heeft inloggegevens van het toetsenbord onderschept door gebruik te maken van speciale technische middelen (STM) die bedoeld zijn voor het heimelijk vastleggen van informatie.
Toelichtingen U1.1.9.4.
Voorbeelden .
U1.1.9.5. Aanvallers onderschepten inloggegevens van het toetsenbord door
de Wi-Fi-signaalanalyse, gemoduleerd door het proces van toetsaanslagen door de gebruiker.
Toelichtingen U1.1.9.5.
Voorbeeld .
U1.1.9.6. Aanvallers onderschepten inloggegevens van het toetsenbord door geluiden van toetsaanslagen te analyseren.
Toelichtingen U1.1.9.6.
Voorbeeld .
U1.1.9.7. Aanvallers onderschepten inloggegevens van het toetsenbord van een mobiel apparaat door de gegevens van de accelerometer te analyseren.
Toelichtingen U1.1.9.7.
Voorbeeld .
U1.1.10. , vooraf opgeslagen op de Klant.
Toelichtingen U1.1.10.
Bijvoorbeeld, de gebruiker kan zijn inlognaam en wachtwoord voor toegang tot een bepaalde website in de browser hebben opgeslagen.
U1.1.11. Aanvallers hebben inloggegevens gecompromitteerd vanwege tekortkomingen in het proces voor het intrekken van gebruikersrechten.
Toelichtingen U1.1.11.
Bijvoorbeeld, na het ontslag van een gebruiker bleven zijn accounts ontgrendeld.
U1.2. door gebruik te maken van kwetsbaarheden in het toegangscontrole systeem.
U2. Ongerechtvaardigde privilegeverhoging van de gebruiker in het informatiesysteem.
Decompositie
U2.1 door ongeautoriseerde wijzigingen aan te brengen in gegevens die informatie over de privileges van de gebruiker bevatten.
U2.2 door gebruik te maken van kwetsbaarheden in het toegangscontrole systeem.
U2.3. door tekortkomingen in het proces van het beheer van gebruikersrechten.
Toelichting U2.3.
Voorbeeld 1. De gebruiker kreeg toegang die groter was dan wat hij nodig had voor zijn dienst.
Voorbeeld 2. Na de overplaatsing van de gebruiker naar een andere functie werden de eerder verleende toegangsrechten niet ingetrokken.
TYPEMODEL VAN BEDREIGING. INTEGRATIEMODULE
Het beschermde object waarvoor het bedreigingsmodel wordt toegepast (scope)
Het integratiemodule is een set van objecten binnen de informatie-infrastructuur die bedoeld zijn voor het organiseren van informatie-uitwisseling tussen informatiesystemen.
Gelet op het feit dat het in corporate netwerken niet altijd mogelijk is om het ene informatiesysteem duidelijk van het andere te scheiden, kan het integratiemodule worden gezien als een verbindingsschakel tussen componenten binnen één informatiesysteem.
Architectuur
Een algemene schematische weergave van het integratiemodule ziet er als volgt uit:
Beschrijving van de architectuurelementen:
- «Uitwisselingsserver (ÚS)» – knooppunt / dienst / component van het informatiesysteem die de functie vervult van gegevensuitwisseling met een ander informatiesysteem.
- «Tussenpersoon» – knooppunt / dienst die is bedoeld om de interactie tussen informatiesystemen te organiseren, maar zelf niet tot hun samenstelling behoort.
Voorbeelden «Tussenpersonen» kunnen e-mailservices, bedrijfsservicebussen (enterprise service bus / SoA-architectuur), externe bestandsservers, enz. zijn. In het algemeen kan het integratiemodule ook geen «Tussenpersonen» bevatten. - «Software voor gegevensverwerking» – een verzameling programma's die de protocollen voor gegevensuitwisseling en de conversie van formaten realizeert.
Bijvoorbeeld, het converteren van gegevens van het UFEBS formaat naar het ABS formaat, het wijzigen van de status van berichten tijdens verzending, enz. - ‘Netwerkverbinding’ komt overeen met het object dat in het typemodel van bedreigingen «Netwerkverbinding» wordt beschreven. Sommige netwerkverbindingen van diegene die op de bovenstaande schematische weergave zijn weergegeven, kunnen er ook niet zijn.
Voorbeelden van integratiemodules
Schema 1. Integratie van ABS en ARM KBR via een externe bestandsserver
Voor de uitvoering van betalingen laadt de gemachtigde bankmedewerker elektronische betalingsdocumenten uit ABS en slaat deze op in een bestand (in eigen formaat, bijvoorbeeld een SQL-dump) op de netwerklocatie (…SHARE) van de bestandsserver. Vervolgens wordt dit bestand met behulp van een converter-scripts omgevormd tot een set van bestanden in het UFEBS-formaat, die vervolgens door de ARM KBR worden gelezen.
Daarna versleutelt de bevoegde medewerker — gebruiker van het ARM KBR — het ontvangen bestand en ondertekent het, waarna het naar het betalingssysteem van de Centrale Bank van Rusland wordt verzonden.
Bij ontvangst van betalingen van de Centrale Bank van Rusland decodeert het ARM KBR deze en controleert de elektronische handtekening, waarna ze worden opgeslagen in de vorm van een set bestanden in het UFEBS-formaat op de bestandserver. Voordat de betalingsdocumenten in de ABS worden geïmporteerd, worden ze met behulp van een converter-script omgezet van het UFEBS-formaat naar het ABS-formaat.
Laten we aannemen dat in dit schema de ABS draait op één fysieke server, het ARM KBR draait op een toegewezen computer, en het converter-script werkt op de bestandserver.
De overeenkomst van de objecten in het besproken schema met de elementen van het integratiemodule-model:
‘Uitwisselingsservers van de ABS’ – server van de ABS.
‘Uitwisselingsservers van het ARM KBR’ – computer van het ARM KBR.
«Tussenpersoon» – externe bestandserver.
«Software voor gegevensverwerking» – converter-script.
Schema 2. Integratie van de ABS en ARM KBR bij het plaatsen van een gedeelde netwerkmap met betalingen op de ARM KBR
Alles is vergelijkbaar met Schema 1, maar er wordt geen aparte bestandserver gebruikt; in plaats daarvan wordt een netwerkmap (…SHARE) met elektronische betalingsdocumenten op de computer van het ARM KBR geplaatst. Het converter-script werkt ook op de ARM KBR.
De overeenkomst van de objecten in het besproken schema met de elementen van het integratiemodule-model:
Vergelijkbaar met Schema 1, maar «Tussenpersoon» wordt niet gebruikt.
Schema 3. Integratie van de ABS en ARM KBR-N via IBM WebSphere MQ en het uitvoeren van de handtekening van elektronische documenten ‘aan de kant van de ABS’
De ABS werkt op een platform dat niet wordt ondersteund door de SKZI SKAD Signature. De handtekening van de uitgaande elektronische documenten wordt uitgevoerd op een speciale elektronische handtekeningserver (Server EP). Deze server controleert ook de elektronische handtekening van de binnenkomende documenten uit de Centrale Bank van Rusland.
De ABS uploadt naar de Server EP een bestand met betalingsdocumenten in zijn eigen formaat.
De Server EP converteert het bestand met behulp van een converter-script naar elektronische berichten in het UFEBS-formaat, waarna de elektronische berichten worden ondertekend en naar IBM WebSphere MQ worden verzonden.
De ARM KBR-N roept IBM WebSphere MQ aan en ontvangt daar de ondertekende betalingsberichten, waarna de bevoegde medewerker — gebruiker van het ARM KBR — deze versleutelt en naar het betalingssysteem van de Centrale Bank van Rusland stuurt.
Bij het ontvangen van betalingen van de Bank van Rusland decodeert het KBR-N-systeem deze en controleert het de elektronische handtekening. Succesvol verwerkte betalingen in de vorm van gedecodeerde en ondertekende elektronische berichten in het UFEBS-formaat worden doorgestuurd naar IBM WebSphere MQ, vanwaar ze door de EP-server worden ontvangen.
De EP-server controleert de elektronische handtekening van de ontvangen betalingen en slaat deze op in een ABS-bestand. Vervolgens laadt een bevoegde medewerker — de ABS-gebruiker — het verkregen bestand volgens de vastgestelde procedure in de ABS.
De overeenkomst van de objecten in het besproken schema met de elementen van het integratiemodule-model:
‘Exchange server aan de ABS-zijde’ – server van de ABS.
‘Exchange server aan de KBR-N-zijde’ — computer van KBR-N.
«Tussenpersoon» – EP-server en IBM WebSphere MQ.
«Software voor gegevensverwerking» – conversiescript, SKZI SKAD-handtekening op de EP-server.
Schema 4. Integratie van de DBO-server en ABS via de API die wordt geleverd door de speciale exchange server
Laten we aannemen dat de bank verschillende systemen voor internetbankieren (DBO) gebruikt:
- ‘Internet Client-Bank’ voor particulieren (IKB FL);
- ‘Internet Client-Bank’ voor rechtspersonen (IKB YL).
Ter waarborging van de informatiebeveiliging vindt alle interactie van de ABS met de DBO-systemen plaats via een speciale exchange server die werkzaam is binnen het informatiesysteem ‘ABS’.
Laten we nu het proces van interactie tussen het DBO-systeem IKB YL en ABS bekijken.
De DBO-server, die van de klant een correct ondertekend betalingsopdracht heeft ontvangen, moet op basis daarvan het bijbehorende document in ABS aanmaken. Hiervoor verzendt hij via de API informatie naar de exchange server, die op zijn beurt de gegevens in ABS invoert.
Bij wijziging van de saldi op de rekening van de klant genereert de ABS elektronische meldingen, die via de exchange server naar de DBO-server worden verzonden.
De overeenkomst van de objecten in het besproken schema met de elementen van het integratiemodule-model:
‘Exchange server aan de DBO-zijde’ – DBO-server IKB YL.
‘Exchange server aan de ABS-zijde’ – exchange server.
«Tussenpersoon» – ontbreekt.
«Software voor gegevensverwerking» – componenten van de DBO-server die verantwoordelijk zijn voor het gebruik van de exchange server API, componenten van de exchange server die verantwoordelijk zijn voor het gebruik van de ABS API.
Beveiligingsbedreigingen op hoog niveau
Decompositie
U1. Invoering van valse informatie door kwaadwillenden via de integratiemodule.
U1. Invoering van valse informatie door kwaadwillenden via de integratiemodule
Decompositie
U1.1. Onbevoegde wijziging van legitieme gegevens tijdens hun overdracht via netwerkverbindingen:
U1.1.1 Link: .
U1.2. Overdracht van valse gegevens via communicatiemiddelen namens een legitieme deelnemer aan de uitwisseling:
U1.1.2 Link: .
U1.3. Niet-autorisering modificatie van legitieme gegevens tijdens verwerking op de uitwisselingsservers of de tussenpersoon:
U1.3.1. Link: .
U1.4. Creatie van vervalste gegevens op de uitwisselingsservers of de tussenpersoon namens een legitieme deelnemer aan de uitwisseling:
U1.4.1. Link:
U1.5. Niet-autorisering modificatie van gegevens tijdens verwerking met behulp van gegevensverwerkingssoftware:
U1.5.1. door niet-autorisering wijzigingen aangebracht door kwaadwillenden in de instellingen (configuratie) van de gegevensverwerkingssoftware.
U1.5.2. door niet-autorisering wijzigingen aangebracht door kwaadwillenden in de uitvoerbare bestanden van de gegevensverwerkingssoftware.
U1.5.3. door interactieve controle door kwaadwillenden van de werking van de gegevensverwerkingssoftware.
TYPERENDE BEDREIGINGSMODEL. SYSTEEM VOOR CRYPTOGRAFISCHE BEVEILIGING VAN INFORMATIE
Het beschermde object waarvoor het bedreigingsmodel wordt toegepast (scope)
Het object van bescherming is een systeem voor cryptografische beveiliging van informatie, gebruikt om de veiligheid van het informatie systeem te waarborgen.
Architectuur
De basis van elk informatie systeem is de applicatiesoftware (AS), die de doelfunctionaliteit implementeert.
Cryptografische beveiliging wordt meestal gerealiseerd door aanroep uit de businesslogica van de applicatiesoftware van cryptografische primitieven, die in gespecialiseerde bibliotheken - crypto-kernen - worden geplaatst.
Cryptografische primitieven omvatten laag-niveau cryptografische functies, zoals:
- gegevens blokken versleutelen / ontsleutelen;
- een digitale handtekening voor een gegevensblok aanmaken / controleren;
- de hash-functie van een gegevensblok berekenen;
- sleutelinformatie formatteren / laden / uitslepen;
- enzovoorts.
De businesslogica van applicatiesoftware implementeert met behulp van cryptografische primitieven een hoger niveau functionaliteit:
- een bestand versleutelen met de sleutels van gekozen ontvangers;
- een beveiligde netwerkverbinding tot stand brengen;
- informatie geven over de resultaten van de controle van de elektronische handtekening;
- enz.
De interactie tussen de bedrijfslogica en de cryptokern kan plaatsvinden:
- direct, door middel van aanroep van cryptografische primitieve uit dynamische bibliotheken van de cryptokern (.DLL – voor Windows, .SO – voor Linux);
- indirect, via cryptografische interfaces – wrappers, zoals MS Crypto API, Java Cryptography Architecture, PKCS#11, enz. In dit geval roept de bedrijfslogica de crypto-interface aan, die de aanroep doorstuurt naar de bijbehorende cryptokern, die in dit geval een cryptoprovider wordt genoemd. Het gebruik van cryptografische interfaces stelt applicaties in staat om zich te abstraheren van specifieke cryptografische algoritmen en flexibeler te zijn.
Er kunnen twee standaard schema's voor de organisatie van de cryptokern worden onderscheiden:
Schema 1 – Monolithische cryptokern
Schema 2 – Verdeelde cryptokern
De elementen in de bovenstaande schema's kunnen zowel afzonderlijke softwaremodules zijn die op dezelfde computer draaien als netdiensten die met elkaar communiceren binnen een computernetwerk.
Bij het gebruik van systemen die zijn opgebouwd volgens schema 1, werken de toepassingssoftware en de cryptokern binnen een gezamenlijke functionele omgeving van het cryptosysteem (SFK), bijvoorbeeld op dezelfde computer, onder dezelfde besturingssysteem. De gebruiker van het systeem kan over het algemeen ook andere programma's binnen dezezelfde functionele omgeving uitvoeren, waaronder die met kwaadaardige code. Onder dergelijke omstandigheden bestaat er een aanzienlijk risico op het uitlekken van gesloten cryptografische sleutels.
Om het risico te minimaliseren, wordt schema 2 toegepast, waarbij de cryptokern in twee delen wordt gesplitst:
- Het eerste deel werkt samen met de toepassingssoftware in een niet-vertrouwde omgeving, waar het risico op infectie met kwaadaardige code bestaat. We zullen dit deel de "softwarekant" noemen.
- Het tweede deel werkt in een vertrouwde omgeving op een speciaal apparaat, dat een opslagplaats voor gesloten sleutels bevat. We zullen dit deel de "hardwarekant" noemen.
De scheiding van de cryptokern in software- en hardwarecomponenten is vrij arbitrair. Op de markt zijn er systemen die zijn opgebouwd volgens het schema met een gescheiden cryptokern, maar waarvan de 'hardware' is gepresenteerd in de vorm van een afbeelding van een virtuele machine - virtual HSM ().
De interactie tussen beide delen van de cryptokern vindt op zo'n manier plaats dat de privésleutels nooit naar het softwaregedeelte worden gestuurd en dus niet door kwaadwillige code kunnen worden gestolen.
De interface voor interactie (API) en de set cryptografische primitieve die door de cryptokern aan toepassingssoftware worden geboden, zijn in beide gevallen hetzelfde. Het verschil ligt in de manier van implementatie.
Bij gebruik van het schema met een gescheiden cryptokern verloopt de interactie tussen het software- en hardwaregedeelte volgens het volgende principe:
- Cryptografische primitieve die geen gebruik maken van de privésleutel (zoals het berekenen van een hashfunctie, het controleren van een digitale handtekening, enz.) worden uitgevoerd door het softwaregedeelte.
- Cryptografische primitieve die de privésleutel gebruiken (zoals het maken van een digitale handtekening, het ontsleutelen van gegevens, enz.) worden uitgevoerd door het hardwaregedeelte.
We illustreren de werking van de gescheiden cryptokern aan de hand van een voorbeeld van het maken van een digitale handtekening:
- Het softwaregedeelte berekent de hashfunctie van de te ondertekenen gegevens en stuurt deze waarde via een communicatiekanaal tussen de cryptokernen naar het hardwaregedeelte.
- Het hardwaregedeelte genereert de waarde van de digitale handtekening met behulp van de privésleutel en de hash, en stuurt deze via het communicatiekanaal terug naar het softwaregedeelte.
- Het softwaregedeelte retourneert de verkregen waarde naar de toepassingssoftware.
Kenmerken van de controle op de correctheid van de digitale handtekening.
Wanneer de ontvangende partij gegevens ontvangt die zijn ondertekend met een digitale handtekening, moet ze verschillende controlefasen doorlopen. Een positieve uitkomst van de controle op de digitale handtekening wordt alleen bereikt als alle controlefasen succesvol zijn doorlopen.
Fase 1. Controle van de integriteit van de gegevens en het auteurschap van de gegevens.
Inhoud van de fase. Een controle van de elektronische handtekening van de gegevens wordt uitgevoerd volgens het overeenkomstige cryptografische algoritme. Een succesvolle afronding van deze stap geeft aan dat de gegevens sinds hun ondertekening niet zijn gewijzigd en dat de handtekening werd gemaakt met de private sleutel die overeenkomt met de publieke sleutel voor de elektronische handtekening.
Plaats van uitvoering van de stap: crypto-kern.
Stap 2. Controle van het vertrouwen in de publieke sleutel van de ondertekenaar en controle van de geldigheidsduur van de private sleutel van de elektronische handtekening.
Inhoud van de fase. De stap bestaat uit twee tussentijdse sub-stappen. In de eerste wordt vastgesteld of de publieke sleutel voor de elektronische handtekening vertrouwd was op het moment van ondertekening van de gegevens. In de tweede wordt vastgesteld of de private sleutel voor de elektronische handtekening geldig was op het moment van ondertekening van de gegevens. In algemene zin kunnen de geldigheidsduren van deze sleutels niet samenvallen (bijvoorbeeld voor gekwalificeerde certificaten van de publieke sleutels voor de elektronische handtekening). De manieren om vertrouwen te vestigen in de publieke sleutel van de ondertekenaar worden bepaald door de regels voor elektronische documentverwerking die zijn vastgesteld door de betrokken partijen.
Plaats van uitvoering van de stap: applicatie-software / crypto-kern.
Stap 3. Controle van de bevoegdheden van de ondertekenaar.
Inhoud van de fase. In overeenstemming met de vastgestelde regels voor elektronische documentverwerking wordt gecontroleerd of de ondertekenaar het recht had om de beschermde gegevens te ondertekenen. Ter illustratie een situatie van bevoegdheidsovertreding. Stel je voor dat er een organisatie is waar alle medewerkers een elektronische handtekening hebben. Er komt een bevel van de leidinggevende binnen in het interne systeem voor elektronische documentverwerking, maar het is ondertekend met de elektronische handtekening van de magazijnchef. Dergelijk document kan dus niet als legitiem worden beschouwd.
Plaats van uitvoering van de stap: applicatie-software.
Aannames die zijn gedaan bij de beschrijving van het beschermde object.
- Informatietransmissiekanalen, behalve voor sleuteldistributiekanalen, gaan ook via applicatiesoftware, API en crypto-kern.
- Informatie over het vertrouwen in publieke sleutels en (of) certificaten, evenals informatie over de bevoegdheden van de eigenaren van publieke sleutels, wordt opgeslagen in de opslag voor publieke sleutels.
- Applicatiesoftware werkt met de opslag voor publieke sleutels via de crypto-kern.
Voorbeeld van een informatiesysteem dat wordt beschermd met behulp van cryptografische beschermingsmiddelen.
Ter illustratie van de eerder genoemde schema's bekijken we een hypothetisch informatiesysteem en identificeren we alle structurele elementen ervan.
Beschrijving van het informatiesysteem
Twee organisaties hebben besloten om een juridisch significante elektronische documentverwerking (EDO) tussen hen in te voeren. Hiervoor hebben ze een overeenkomst gesloten waarin is vastgelegd dat documenten via e-mail zullen worden verzonden, en deze moeten worden versleuteld en ondertekend met een gekwalificeerde elektronische handtekening. Voor het aanmaken en verwerken van documenten moeten de kantoorprogramma's uit het Microsoft Office 2016-pakket worden gebruikt, en voor cryptografische bescherming — de cryptografische beveiligingsmiddelen KryptoPRO en de encryptiesoftware KryptoARM.
Beschrijving van de infrastructuur van organisatie 1
Organisatie 1 heeft besloten om KryptoPRO en KryptoARM te installeren op de werkplek van de gebruiker — een fysieke computer. De encryptie- en elektronische handtekening sleutels zullen worden opgeslagen op de sleuteldrager ruToken, die werkt in de modus van verwijderbare sleutel. De gebruiker zal elektronische documenten lokaal op zijn computer voorbereiden, waarna hij deze zal versleutelen, ondertekenen en verzenden met behulp van een lokaal geïnstalleerde e-mailclient.
Beschrijving van de infrastructuur van organisatie 2
Organisatie 2 heeft besloten om de functies van versleuteling en elektronische handtekening naar een eigen virtuele machine te verplaatsen. Alle cryptografische operaties zullen automatisch worden uitgevoerd.
Daartoe zijn er op de eigen virtuele machine twee netwerk mappen ingericht: '…In', '…Out'. In de netwerkmap '…In' worden automatisch de van de tegenpartij ontvangen bestanden in onversleutelde vorm geplaatst. Deze bestanden worden gedecodeerd en er wordt gecontroleerd op de elektronische handtekening.
In de map '…Out' zal de gebruiker bestanden plaatsen die moeten worden versleuteld, ondertekend en naar de tegenpartij verzonden. De bestanden zelf zal de gebruiker voorbereiden op zijn werkplek.
Voor het uitvoeren van de functies van versleuteling en elektronische handtekening zijn KryptoPRO, KryptoARM en een e-mailclient op de virtuele machine geïnstalleerd. Het automatische beheer van alle elementen van de virtuele machine zal worden uitgevoerd met behulp van scripts, ontwikkeld door systeembeheerders. De werking van de scripts wordt gelogd in logbestanden.
Cryptografische sleutels voor elektronische handtekeningen worden opgeslagen op de token met een niet-uitvoerbare sleutel JaCarta GOST, die de gebruiker op zijn lokale computer zal aansluiten.
De token zal naar de virtuele machine worden doorgestuurd met behulp van gespecialiseerde USB-over-IP-software, geïnstalleerd op de werkplek van de gebruiker en op de virtuele machine.
De systeemtijd op de werkplek van de gebruiker in organisatie 1 zal handmatig worden aangepast. De systeemtijd van de gespecialiseerde virtuele machine in organisatie 2 zal worden gesynchroniseerd met de systeemtijd van de hypervisor, die op zijn beurt via internet synchroneert met publieke tijdservers.
Identificatie van structurele elementen van SKZI
Op basis van de bovenstaande beschrijving van de IT-infrastructuur identificeren we de structurele elementen van SKZI en noteren deze in een tabel.
Tabel - Overeenstemming van de elementen van het SKZI-model met de elementen van informatiesystemen
Naam van het element
Organisatie 1
Organisatie 2
Toepasselijke software
CryptoARM-software
CryptoARM-software
Programmaonderdeel van de cryptokern
SKZI CryptoPRO CSP
SKZI CryptoPRO CSP
Hardwareonderdeel van de cryptokern
ontbreekt
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Opslag van openbare sleutels
Werkplek van de gebruiker:
— harde schijf;
— standaard opslag voor Windows-certificaten.
Hypervisor:
— harde schijf.
Virtuele machine:
— harde schijf;
— standaard opslag voor Windows-certificaten.
Opslag van privésleutels
Sleuteldrager ruToken, werkend in de modus van uitvoerbare sleutel
Sleuteldrager JaCarta GOST, werkend in de modus van niet-uitvoerbare sleutel
Kanaal voor de uitwisseling van openbare sleutels
Werkplek van de gebruiker:
— RAM.
Hypervisor:
— RAM.
Virtuele machine:
— RAM.
Kanaal voor de uitwisseling van privésleutels
Werkplek van de gebruiker:
— USB-bus;
— RAM.
ontbreekt
Kanaal voor de uitwisseling tussen cryptokernen
afwezig (geen hardwareonderdeel van de cryptokern)
Werkplek van de gebruiker:
— USB-bus;
— RAM;
— softwaremodule USB-over-IP;
— netwerkinterface.
Bedrijfsnetwerk van organisatie 2.
Hypervisor:
— RAM;
— netwerkinterface.
Virtuele machine:
— netwerkinterface;
— RAM;
— softwaremodule USB-over-IP.
Kanaal voor de uitwisseling van openbare data
Werkplek van de gebruiker:
— invoer-/uitvoerapparaten;
— RAM;
— harde schijf.
Werkplek van de gebruiker:
— invoer-/uitvoerapparaten;
— RAM;
— harde schijf;
— netwerkinterface.
Bedrijfsnetwerk van organisatie 2.
Hypervisor:
— netwerkinterface;
— RAM;
— harde schijf.
Virtuele machine:
— netwerkinterface;
— RAM;
— harde schijf.
Kanaal voor de uitwisseling van beschermde gegevens
Internet.
Bedrijfsnetwerk van organisatie 1.
Werkplek van de gebruiker:
— harde schijf;
— RAM;
— netwerkinterface.
Internet.
Bedrijfsnetwerk van organisatie 2.
Hypervisor:
— netwerkinterface;
— RAM;
— harde schijf.
Virtuele machine:
— netwerkinterface;
— RAM;
— harde schijf.
Kanaal voor de overdracht van tijd
Werkplek van de gebruiker:
— invoer-/uitvoerapparaten;
— RAM;
— systeemtimer.
Internet.
Bedrijfsnetwerk van organisatie 2,
Hypervisor:
— netwerkinterface;
— RAM;
— systeemtimer.
Virtuele machine:
— RAM;
— systeemtimer.
Kanaal voor de overdracht van stuurcommando's
Werkplek van de gebruiker:
— invoer-/uitvoerapparaten;
— RAM.
(Grafische gebruikersinterface van CryptoARM-software)
Virtuele machine:
— RAM;
— harde schijf.
(Automatiseringsscripts)
Kanaal voor het ontvangen van werkresultaten
Werkplek van de gebruiker:
— invoer-/uitvoerapparaten;
— RAM.
(Grafische gebruikersinterface van CryptoARM-software)
Virtuele machine:
— RAM;
— harde schijf.
(Logbestanden van de automatiseringsscripts)
Beveiligingsbedreigingen op hoog niveau
Uitleg
Aannames gemaakt bij het decomponeren van bedreigingen:
- Er worden robuuste cryptografische algoritmen gebruikt.
- Cryptografische algoritmen worden op een veilige manier gebruikt in de juiste operationele modi (bijvoorbeeld, wordt niet gebruikt voor het versleutelen van grote hoeveelheden gegevens, rekening houdend met de toelaatbare belasting op de sleutel, enz.).
- Kwaadwillenden kennen alle gebruikte algoritmen, protocollen en openbare sleutels.
- Alle versleutelde gegevens zijn leesbaar voor kwaadwillenden.
- Kwaadwillenden zijn in staat om alle software-elementen in het systeem te reproduceren.
Decompositie
U1. Compromittering van gesloten cryptografische sleutels.
U2. Versleuteling van vervalste gegevens namens een legitieme afzender.
U3. Ontsleuteling van versleutelde gegevens door personen die geen legitieme ontvangers van de gegevens zijn (kwaadwillenden).
U4. Het creëren van een elektronische handtekening van een legitieme ondertekenaar onder vervalste gegevens.
U5. Ontvangen van een positieve uitkomst van de controle van de elektronische handtekening onder vervalste gegevens.
U6. Foutieve aanvaarding van elektronische documenten voor uitvoering wegens problemen in de organisatie van de elektronische documentstroom.
U7. Ongeautoriseerde toegang tot beschermde gegevens tijdens hun verwerking door de sterk beveiligde cryptografische infrastructuur.
U1. Compromittering van gesloten cryptografische sleutels.
U1.1. Verkrijgen van de gesloten sleutel uit de opslag van gesloten sleutels.
U1.2. Verkrijgen van de gesloten sleutel uit objecten in de operationele omgeving van het cryptografiemiddel, waarin deze tijdelijk kan zijn.
Toelichtingen U1.2.
De objecten waarin de gesloten sleutel tijdelijk kan worden opgeslagen, omvatten:
- ramen,
- tijdelijke bestanden,
- swapbestanden,
- hybernatiebestanden,
- snapshotbestanden van de 'hot' status van virtuele machines, inclusief bestanden met de inhoud van het werkgeheugen van gepauzeerde virtuele machines.
U1.2.1. Het extraheren van gesloten sleutels uit actief werkgeheugen door het bevriezen van RAM-modules, deze te extraheren en vervolgens gegevens uit te lezen (freeze attack).
Toelichtingen U1.2.1.
Voorbeeld .
U1.3. Verkrijgen van de gesloten sleutel uit de uitwisselingskanaal voor gesloten sleutels.
Toelichtingen U1.3.
Een voorbeeld van de implementatie van deze bedreiging zal worden gegeven. .
U1.4. Ongeautoriseerde wijziging van de cryptokern, waardoor gesloten sleutels bekend worden bij kwaadwillenden.
U1.5. Compromittering van de private sleutel door gebruik van technische kanalen voor informatielekken (TCKUI).
Uitleg U1.5.
Voorbeeld .
U1.6. Compromittering van de private sleutel door gebruik van speciale technische middelen (STM) voor het heimelijk afnemen van informatie (“luisterapparaten”).
U1.7. Compromittering van private sleutels gedurende hun opslag buiten de CKZI.
Uitleg U1.7.
Bijvoorbeeld, een gebruiker bewaart zijn sleuteldragers in een bureaulade, waaruit ze gemakkelijk door kwaadwillenden kunnen worden gehaald.
U2. Versleuteling van valse gegevens namens een legitieme afzender.
Uitleg
Deze bedreiging wordt alleen beschouwd voor versleutelingsschema's met authenticatie van de afzender. Voorbeelden van dergelijke schema's zijn opgenomen in de normalisatie-aanbevelingen. . Voor andere cryptografische schema's bestaat deze bedreiging niet, omdat versleuteling plaatsvindt op de openbare sleutels van de ontvanger, en deze zijn in het algemeen bekend bij kwaadwillenden.
Decompositie
U2.1. Compromittering van de private sleutel van de afzender:
U2.1.1. Link: .
U2.2. Vervalsing van invoergegevens in de uitwisselingskanalen voor openbare gegevens.
Opmerkingen U2.2.
Voorbeelden van de uitvoering van deze bedreiging worden hieronder gepresenteerd. en .
U3. Ontsleuteling van versleutelde gegevens door personen die geen legitieme ontvangers van de gegevens zijn (kwaadwillenden).
Decompositie
U3.1. Compromittering van de private sleutels van de ontvanger van de versleutelde gegevens.
U3.1.1 Link: .
U3.2. Vervalsing van versleutelde gegevens in de uitwisselingskanalen voor beschermde gegevens.
U4. Aanmaak van een elektronische handtekening van een legitieme ondertekenaar onder valse gegevens.
Decompositie
U4.1. Compromittering van de private sleutels van de legitieme ondertekenaar.
U4.1.1 Link: .
U4.2. Vervalsing van de te ondertekenen gegevens in de uitwisselingskanalen voor openbare gegevens.
Opmerking U4.2.
Voorbeelden van de uitvoering van deze bedreiging worden hieronder gepresenteerd. en .
U5. Verkrijgen van een positief resultaat van de controle van de elektronische handtekening onder valse gegevens.
Decompositie
U5.1. Kwaadwillenden onderscheppen in de transmissiekanaal van de resultaten een bericht over een negatieve uitkomst van de verificatie van de elektronische handtekening en vervangen dit door een bericht met een positieve uitkomst.
U5.2. Kwaadwillenden voeren een aanval uit op het vertrouwen in de handtekeningcertificaten (SCENARIO — alle elementen zijn verplicht):
U5.2.1. Kwaadwillenden genereren een openbare en privésleutel voor de elektronische handtekening. Als het systeem gebruik maakt van certificaten voor elektronische handtekeningen, genereren ze een elektronische handtekening die zo veel mogelijk lijkt op het certificaat van de veronderstelde afzender van de gegevens, wiens bericht ze willen vervalsen.
U5.2.2. Kwaadwillenden brengen ongeautoriseerde wijzigingen aan in de opslag van openbare sleutels, waardoor ze de door hen gegenereerde openbare sleutel de vereiste vertrouwensniveaus en bevoegdheden geven.
U5.2.3. Kwaadwillenden ondertekenen valse gegevens met de eerder gevormde elektronische handtekening en injecteren deze in de kanaal voor de uitwisseling van beveiligde gegevens.
U5.3. Kwaadwillenden voeren een aanval uit met behulp van verlopen elektronische handtekeningen van een legitieme ondertekenaar (SCENARIO — alle elementen zijn verplicht):
U5.3.1. Kwaadwillenden compromitteren verlopen (op dit moment niet werkende) privésleutels van een legitieme afzender.
U5.3.2. Kwaadwillenden vervangen de tijd in het tijdtransportkanaal door de tijd waarop de gecompromitteerde sleutels nog geldig waren.
U5.3.3. Kwaadwillenden ondertekenen valse gegevens met de eerder gecompromitteerde elektronische handtekening en injecteren deze in de kanaal voor de uitwisseling van beveiligde gegevens.
U5.4. Kwaadwillenden voeren een aanval uit met behulp van gecompromitteerde elektronische handtekeningen van een legitieme ondertekenaar (SCENARIO — alle elementen zijn verplicht):
U5.4.1. Kwaadwillenden maken een kopie van de opslag van openbare sleutels.
U5.4.2. Kwaadwillenden compromitteren de privésleutels van een van de legitieme afzenders. Deze merkt de compromise op, int de sleutels, en informatie over het intrekken van de sleutel wordt in de opslag van openbare sleutels geplaatst.
U5.4.3. Kwaadwillenden vervangen de opslag van openbare sleutels door de eerder gemaakte kopie.
U5.4.4. Kwaadwillenden ondertekenen valse gegevens met de eerder gecompromitteerde elektronische handtekening en injecteren deze in de kanaal voor de uitwisseling van beveiligde gegevens.
U5.5. door de aanwezigheid van fouten in de uitvoering van de 2e en 3e fase van de controle van de elektronische handtekening:
Uitleg U5.5.
Een voorbeeld van deze bedreiging is gegeven .
U5.5.1. Controle van het vertrouwen in het certificaat voor de elektronische handtekening enkel op basis van het vertrouwen in het certificaat waarmee het is ondertekend, zonder controles van CRL of OCSP.
Uitleg U5.5.1.
Laten we zeggen dat we op de router twee netwerken hebben — main(1) en guest(2), voor elk van hen is er een OpenVPN-server voor verbinding van buitenaf. .
U5.5.2. Bij het opbouwen van de keten van vertrouwen voor het certificaat worden de bevoegdheden van de uitgevende certificaten niet geanalyseerd.
Uitleg U5.5.2.
Een voorbeeld van een aanval op SSL/TLS-certificaten.
Aanvallers kochten een legitiem certificaat voor hun e-mail. Vervolgens maakten ze een frauduleus certificaat van de website en ondertekenden dit met hun certificaat. Als er geen controle van bevoegdheden plaatsvindt, zal de controle van de keten van vertrouwen correct blijken te zijn, en zal dus ook het frauduleuze certificaat als geldig worden beschouwd.
U5.5.3. Bij het opbouwen van de keten van vertrouwen voor het certificaat worden tussenliggende certificaten op terugroepbaarheid niet gecontroleerd.
U5.5.4. De actualisatie van de CRL vindt minder vaak plaats dan deze door de certificaatautoriteit wordt uitgegeven.
U5.5.5. De beslissing over het vertrouwen in de elektronische handtekening wordt genomen voordat het OCSP-reactie over de status van het certificaat, dat op verzoek is verzonden, wordt ontvangen, dat is gedaan na het tijdstip van ondertekening of voordat de volgende CRL na de ondertekening is ontvangen.
Uitleg U5.5.5.
In de voorschriften van de meeste CA's wordt de tijd van terugroeping van het certificaat beschouwd als de tijd van uitgifte van de meest recente CRL die informatie over de terugroeping van het certificaat bevat.
U5.5.6. Bij het ontvangen van ondertekende gegevens wordt de toebehoren van het certificaat aan de zender niet gecontroleerd.
Uitleg U5.5.6.
Een voorbeeld van een aanval. Met betrekking tot SSL-certificaten: de overeenstemming van het adres van de aangeroepen server met de waarde van het CN-veld in het certificaat kan niet worden gecontroleerd.
Een voorbeeld van een aanval. Aanvallers compromitteerden de sleutels voor elektronische handtekeningen van een van de deelnemers aan het betalingssysteem. Vervolgens hackten ze het netwerk van een andere deelnemer en stuurden namens hem betalingsdocumenten naar de afrek сервер van het betalingssysteem, ondertekend met de gecompromitteerde sleutels. Als de server alleen het vertrouwen analyseert en geen overeenstemming controleert, zullen de frauduleuze documenten als legitiem worden beschouwd.
U6. Foutieve aanvaarding van elektronische documenten voor uitvoering wegens problemen in de organisatie van de elektronische documentstroom.
Decompositie
U6.1. De ontvangende partij detecteert geen duplicatie van de ontvangen documenten.
Uitleg U6.1.
Voorbeeld van een aanval. Vijandige actoren kunnen een document dat naar de ontvanger wordt verzonden, zelfs als het cryptografisch beveiligd is, onderscheppen en het vervolgens meerdere keren terugsturen via het kanaal voor veilige gegevensoverdracht. Als de ontvanger geen duplicaten ontdekt, zullen alle ontvangen documenten worden beschouwd en verwerkt als verschillende documenten.
U7. Niet-geautoriseerde toegang tot beschermde gegevens tijdens hun verwerking door de SKZI.
Decompositie
U7.1. als gevolg van informatielekken via externe kanalen (side channel attack).
Toelichting U7.1.
Voorbeeld .
U7.2. als gevolg van het neutraliseren van de bescherming tegen niet-geautoriseerde toegang tot informatie die door de SKZI wordt verwerkt:
U7.2.1. Exploitatie van de SKZI met inachtneming van de vereisten zoals beschreven in de documentatie van de SKZI.
U7.2.2. , uitgevoerd door kwetsbaarheden in:
U7.2.2.1. middelen voor bescherming tegen niet-geautoriseerde toegang.
U7.2.2.2. de SKZI zelf.
U7.2.2.3. de omgeving waarin de cryptografische middelen functioneren.
Voorbeelden van aanvallen
De onderstaande scenario's bevatten opzettelijk fouten in de organisatie van informatiebeveiliging en dienen alleen ter illustratie van mogelijke aanvallen.
Scenario 1. Voorbeeld van de implementatie van bedreigingen U2.2 en U4.2.
Beschrijving van het object
De software APM KBR en SKZI SKAD zijn geïnstalleerd op een fysiek apparaat, dat niet is verbonden met het computernetwerk. Een FKN vdToken wordt gebruikt als sleuteldrager in een modus met een niet-uitvoerbare sleutel.
De procedure voor het uitvoeren van berekeningen veronderstelt dat de berekeningstechnicus elektronische berichten in open tekst (volgens het oude APM KBR-schema) downloadt van een speciale beveiligde bestandsserver op zijn werkcomputer, ze vervolgens opslaat op een verwijderbare USB-stick en deze naar de APM KBR overdraagt, waar ze worden versleuteld en ondertekend. Daarna verplaatst de specialist beveiligde elektronische berichten naar de verwijderbare opslagmedia en schrijft ze vervolgens via zijn werkcomputer terug naar de bestandsserver, van waaruit ze in de UTA en verder in het betalingssysteem van de Bank van Rusland komen.
In dit geval zullen de kanalen voor de uitwisseling van open en beveiligde gegevens bestaan uit: bestandsserver, werkcomputer van de specialist en verwijderbare opslagmedia.
Aanval
Kwaadwillenden installeren ongeautoriseerd een systeem voor externe bediening op de werkcomputer van de specialist en vervalsen op het moment van registratie van de te verplaatsen betalingsopdrachten (elektronische berichten) openlijk de inhoud van een van hen. De specialist verplaatst de betalingsopdrachten naar het ARM KBR, ondertekent en versleutelt deze, zonder de vervalsing op te merken (bijvoorbeeld door het hoge aantal betalingsopdrachten in behandeling, vermoeidheid, etc.). Daarna bereikt de vervalste betalingsopdracht via de technologische keten het betalingssysteem van de Bank van Rusland.
Scenario 2. Voorbeeld van de implementatie van bedreigingen U2.2 en U4.2.
Beschrijving van het object
Een computer met geïnstalleerde ARM KBR, SCAD Handtekening en aangesloten sleutelmedium FKN vdToken werkt in een aparte ruimte zonder toegang van personeel.
De specialist in betalingen maakt verbinding met de ARM KBR in de modus voor externe toegang via het RDP-protocol.
Aanval
Kwaadwillenden onderscheppen de gegevens waarmee de specialist in betalingen verbinding maakt en werkt met de ARM KBR (bijvoorbeeld door middel van malware op zijn computer). Vervolgens maken ze verbinding namens hem en zenden een vervalste betalingsopdracht naar het betalingssysteem van de Bank van Rusland.
Scenario 3. Voorbeeld van de implementatie van bedreiging U1.3.
Beschrijving van het object
Laten we een van de hypothetische opties voor de implementatie van integratiemodules ‘ABS-KBR’ voor het nieuwe schema (ARM KBR-N) bekijken, waarbij de elektronische handtekening voor uitgaande documenten aan de kant van de ABS plaatsvindt. We gaan ervan uit dat de ABS draait op een besturingssysteem dat niet wordt ondersteund door SCZI SCAD Handtekening, en dat de cryptografische functionaliteit is overgedragen naar een aparte virtuele machine — het integratiemodule ‘ABS-KBR’.
Als sleutelmedium wordt een gewone USB-token gebruikt die werkt in de modus van een verwijderbare sleutel. Bij aansluiting van het sleutelmedium op de hypervisor bleek dat er geen vrije USB-poorten in het systeem beschikbaar waren, daarom werd besloten de USB-token via een netwerk USB-hub aan te sluiten en de client USB-over-IP op de virtuele machine te installeren die de verbinding met de hub zal verzorgen.
Aanval
Aanvallers hebben de privésleutel van de elektronische handtekening onderschept via de communicatielijn tussen de USB-hub en de hypervisor (gegevens werden ongecodeerd verzonden). Met de privésleutel hebben de aanvallers een valse betalingsopdracht gegenereerd, deze ondertekend met de elektronische handtekening en verzonden naar APM KBR-N voor uitvoering.
Scenario 4. Voorbeeld van de implementatie van bedreigingen U5.5.
Beschrijving van het object
Laten we hetzelfde schema bekijken als in het vorige scenario. We gaan ervan uit dat elektronische berichten die uit APM KBR-N komen, in de map …SHAREIn terechtkomen, en die welke naar APM KBR-N worden verzonden en verder naar het betalingsysteem van de Bank van Rusland, in …SHAREout.
We gaan er ook van uit dat bij de implementatie van de integratiemodule de lijsten van ingetrokken certificaten alleen worden bijgewerkt bij heruitgifte van cryptografische sleutels, en dat elektronische berichten die in de map …SHAREIn zijn ontvangen, alleen worden gecontroleerd op integriteitscontrole en op vertrouwen in de openbare sleutel van de elektronische handtekening.
Aanval
Aanvallers hebben, gebruikmakend van de in het vorige scenario gestolen sleutels, een valse betalingsopdracht ondertekend die informatie bevatte over de ontvangst van geld op de rekening van de oplichter, en deze in de beveiligde gegevensuitwisselingskanalen ingevoegd. Aangezien er geen controle plaatsvindt om te verifiëren of de betalingsopdracht daadwerkelijk door de Bank van Rusland is ondertekend, wordt deze geaccepteerd voor uitvoering.
Bron: habr.com
