Links naar andere delen van het onderzoek
- (Ben je hier)
Dit artikel completeert de reeks publicaties die zich richt op het waarborgen van de informatiebeveiliging van girale betalingen per bank. Hier zullen we kijken naar de typische dreigingsmodellen waarnaar in wordt verwezen :
- .
- .
- .
- .
HABRO-WAARSCHUWING!!! Beste Khabrovieten, dit is geen vermakelijke post.
De meer dan 40 pagina's met materiaal verborgen onder de snit zijn bedoeld om hulp bij werk of studie mensen die gespecialiseerd zijn in bankieren of informatiebeveiliging. Deze materialen zijn het eindproduct van het onderzoek en zijn op een droge, formele toon geschreven. In wezen zijn dit blanco's voor interne informatiebeveiligingsdocumenten.Nou ja, traditioneel... “het gebruik van informatie uit het artikel voor illegale doeleinden is strafbaar”. Productief lezen!
Informatie voor lezers die vanaf deze publicatie vertrouwd raken met het onderzoek.
Waar gaat de studie over?
U leest een handleiding voor een specialist die verantwoordelijk is voor het waarborgen van de informatiebeveiliging van betalingen bij een bank.
Logica van presentatie
In het begin binnen и er wordt een beschrijving van het beschermde object gegeven. Dan in beschrijft hoe je een beveiligingssysteem bouwt en vertelt over de noodzaak om een dreigingsmodel te creëren. IN vertelt over welke dreigingsmodellen er bestaan en hoe deze worden gevormd. IN и Er wordt een analyse van echte aanvallen gegeven. и bevatten een beschrijving van het dreigingsmodel, waarbij rekening wordt gehouden met informatie uit alle voorgaande delen.
TYPISCH BEDREIGINGSMODEL. NETWERKVERBINDING
Beveiligingsobject waarvoor het dreigingsmodel (scope) wordt toegepast
Het voorwerp van bescherming zijn gegevens die worden verzonden via een netwerkverbinding die werkt in datanetwerken die zijn gebouwd op basis van de TCP/IP-stack.
Architectuur
Beschrijving van architectonische elementen:
- "Eindknooppunten" — knooppunten die beschermde informatie uitwisselen.
- "Tussenknooppunten" — elementen van een datatransmissienetwerk: routers, switches, toegangsservers, proxyservers en andere apparatuur — waardoor netwerkverbindingsverkeer wordt verzonden. Over het algemeen kan een netwerkverbinding functioneren zonder tussenliggende knooppunten (direct tussen eindknooppunten).
Beveiligingsbedreigingen op het hoogste niveau
Ontleding
U1. Ongeautoriseerde toegang tot verzonden gegevens.
U2. Ongeautoriseerde wijziging van verzonden gegevens.
U3. Schending van het auteurschap van verzonden gegevens.
U1. Ongeautoriseerde toegang tot verzonden gegevens
Ontleding
U1.1. <…>, uitgevoerd op de laatste of tussenliggende knooppunten:
U1.1.1. <…> door gegevens te lezen terwijl deze zich op de hostopslagapparaten bevinden:
U1.1.1.1. <…> in RAM.
Uitleg voor U1.1.1.1.
Bijvoorbeeld tijdens gegevensverwerking door de netwerkstack van de host.
U1.1.1.2. <…> in niet-vluchtig geheugen.
Uitleg voor U1.1.1.2.
Bijvoorbeeld bij het opslaan van verzonden gegevens in een cache, tijdelijke bestanden of wisselbestanden.
U1.2. <…>, uitgevoerd op externe knooppunten van het datanetwerk:
U1.2.1. <...> door de methode van het vastleggen van alle pakketten die aankomen op de netwerkinterface van de host:
Uitleg voor U1.2.1.
Het vastleggen van alle pakketten wordt uitgevoerd door de netwerkkaart in de promiscue modus te zetten (promiscue modus voor bekabelde adapters of monitormodus voor wifi-adapters).
U1.2.2. <…> door man-in-the-middle-aanvallen (MiTM) uit te voeren, maar zonder de verzonden gegevens te wijzigen (de netwerkprotocolservicegegevens niet meegerekend).
U1.2.2.1. Koppeling: .
U1.3. <…>, uitgevoerd als gevolg van informatielekken via technische kanalen (TKUI) van fysieke knooppunten of communicatielijnen.
U1.4. <…>, uitgevoerd door speciale technische middelen (STS) te installeren op de eind- of tussenknooppunten, bedoeld voor het geheim verzamelen van informatie.
U2. Ongeautoriseerde wijziging van verzonden gegevens
Ontleding
U2.1. <…>, uitgevoerd op de laatste of tussenliggende knooppunten:
U2.1.1. <…> door de gegevens te lezen en er wijzigingen in aan te brengen terwijl deze zich op de opslagapparaten van de knooppunten bevinden:
U2.1.1.1. <…> in RAM:
U2.1.1.2. <…> in niet-vluchtig geheugen:
U2.2. <…>, uitgevoerd op externe knooppunten van het datatransmissienetwerk:
U2.2.1. <…> door man-in-the-middle-aanvallen (MiTM) uit te voeren en verkeer om te leiden naar het knooppunt van de aanvaller:
U2.2.1.1. De fysieke verbinding van de apparatuur van aanvallers zorgt ervoor dat een netwerkverbinding wordt verbroken.
U2.2.1.2. Aanvallen uitvoeren op netwerkprotocollen:
U2.2.1.2.1. <…> beheer van virtuele lokale netwerken (VLAN):
U2.2.1.2.1.1. .
U2.2.1.2.1.2. Ongeautoriseerde wijziging van VLAN-instellingen op switches of routers.
U2.2.1.2.2. <…> verkeersroutering:
U2.2.1.2.2.1. Ongeoorloofde wijziging 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 naamomzetting:
U2.2.1.2.4.1. .
U2.2.1.2.4.2. .
U2.2.1.2.4.3. Ongeautoriseerde wijzigingen aanbrengen in lokale hostnaambestanden (hosts, lmhosts, enz.)
U3. Schending van het auteursrecht op verzonden gegevens
Ontleding
U3.1. Neutralisatie van mechanismen voor het bepalen van het auteurschap van informatie door valse informatie over de auteur of gegevensbron aan te geven:
U3.1.1. Veranderende informatie over de auteur in de verzonden informatie.
U3.1.1.1. Neutralisatie van cryptografische bescherming van de integriteit en het auteurschap van verzonden gegevens:
U3.1.1.1.1. Koppeling: .
U3.1.1.2. Neutralisatie van auteursrechtelijke bescherming van verzonden gegevens, geïmplementeerd met behulp van eenmalige bevestigingscodes:
U3.1.1.2.1. .
U3.1.2. Informatie over de bron van verzonden informatie wijzigen:
U3.1.2.1. .
U3.1.2.2. .
TYPISCH BEDREIGINGSMODEL. INFORMATIESYSTEEM GEBOUWD OP BASIS VAN CLIENT-SERVER ARCHITECTUUR
Beveiligingsobject waarvoor het dreigingsmodel (scope) wordt toegepast
Het object van bescherming is een informatiesysteem dat is gebouwd op basis van een client-server-architectuur.
Architectuur
Beschrijving van architectonische elementen:
- "Cliënt" – een apparaat waarop het clientgedeelte van het informatiesysteem werkt.
- "Server" – een apparaat waarop het servergedeelte van het informatiesysteem werkt.
- "Gegevensopslag" — onderdeel van de serverinfrastructuur van een informatiesysteem, ontworpen om gegevens op te slaan die door het informatiesysteem worden verwerkt.
- "Netwerkverbinding" — een informatie-uitwisselingskanaal tussen de klant en de server dat via het datanetwerk loopt. Een meer gedetailleerde beschrijving van het elementenmodel wordt gegeven in .
Beperkingen
Bij het modelleren van een object worden de volgende beperkingen ingesteld:
- De gebruiker heeft binnen een beperkte tijdsperiode interactie met het informatiesysteem, de zogenaamde werksessies.
- Aan het begin van elke werksessie wordt de gebruiker geïdentificeerd, geauthenticeerd en geautoriseerd.
- Alle beschermde informatie wordt opgeslagen op het servergedeelte van het informatiesysteem.
Beveiligingsbedreigingen op het hoogste niveau
Ontleding
U1. Het uitvoeren van ongeautoriseerde acties door aanvallers namens een legitieme gebruiker.
U2. Ongeoorloofde wijziging van beschermde informatie tijdens de verwerking ervan door het servergedeelte van het informatiesysteem.
U1. Het uitvoeren van ongeautoriseerde acties door aanvallers namens een legitieme gebruiker
Uitleg
In informatiesystemen worden acties doorgaans gecorreleerd met de gebruiker die ze heeft uitgevoerd met behulp van:
- systeembewerkingslogboeken (logboeken).
- speciale attributen van data-objecten die informatie bevatten over de gebruiker die deze heeft gemaakt of gewijzigd.
Met betrekking tot een werksessie kan deze dreiging worden opgesplitst in:
- <…> uitgevoerd binnen de gebruikerssessie.
- <…> uitgevoerd buiten de gebruikerssessie.
Een gebruikerssessie kan worden gestart:
- Door de gebruiker zelf.
- Misdadigers.
In dit stadium zal de tussentijdse ontbinding van deze dreiging er als volgt uitzien:
U1.1. Er zijn ongeautoriseerde acties uitgevoerd binnen een gebruikerssessie:
U1.1.1. <…> geïnstalleerd door de aangevallen gebruiker.
U1.1.2. <…> geïnstalleerd door aanvallers.
U1.2. Er zijn ongeautoriseerde acties uitgevoerd buiten de gebruikerssessie.
Vanuit het oogpunt van informatie-infrastructuurobjecten die door aanvallers kunnen worden beïnvloed, zal de decompositie van intermediaire bedreigingen er als volgt uitzien:
elementen
Bedreiging ontbinding
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.
Ontleding
U1.1. Er zijn ongeautoriseerde acties uitgevoerd binnen een gebruikerssessie:
U1.1.1. <…> geïnstalleerd door de aangevallen gebruiker:
U1.1.1.1. De aanvallers handelden onafhankelijk van de Klant:
U1.1.1.1.1 De aanvallers gebruikten standaardtoegangstools voor informatiesystemen:
У1.1.1.1.1.1. De aanvallers maakten gebruik van de fysieke invoer-/uitvoermiddelen van Klant (toetsenbord, muis, monitor of touchscreen van een mobiel apparaat):
U1.1.1.1.1.1.1. De aanvallers opereerden gedurende perioden waarin de sessie actief was, I/O-faciliteiten beschikbaar waren en de gebruiker niet aanwezig was.
У1.1.1.1.1.2. De aanvallers gebruikten tools voor extern beheer (standaard of geleverd door kwaadaardige code) om de Klant te controleren:
U1.1.1.1.1.2.1. De aanvallers opereerden gedurende perioden waarin de sessie actief was, I/O-faciliteiten beschikbaar waren en de gebruiker niet aanwezig was.
U1.1.1.1.1.2.2. De aanvallers gebruikten tools voor beheer op afstand, waarvan de werking onzichtbaar is voor de aangevallen gebruiker.
U1.1.1.2. De aanvallers hebben de gegevens in de netwerkverbinding tussen de Client en de Server vervangen en deze zodanig aangepast dat deze werden waargenomen als de acties van een legitieme gebruiker:
U1.1.1.2.1. Koppeling: .
U1.1.1.3. De aanvallers dwongen de gebruiker om de door hen opgegeven acties uit te voeren met behulp van social engineering-methoden.
У1.1.2 <…> geïnstalleerd door aanvallers:
U1.1.2.1. De aanvallers handelden vanuit de client (И):
U1.1.2.1.1. De aanvallers neutraliseerden het toegangscontrolesysteem van het informatiesysteem:
U1.1.2.1.1.1. Koppeling: .
У1.1.2.1.2. De aanvallers gebruikten standaardtoegangstools voor informatiesystemen
U1.1.2.2. De aanvallers opereerden vanuit andere knooppunten van het datanetwerk, van waaruit een netwerkverbinding met de Server tot stand kon worden gebracht (И):
U1.1.2.2.1. De aanvallers neutraliseerden het toegangscontrolesysteem van het informatiesysteem:
U1.1.2.2.1.1. Koppeling: .
U1.1.2.2.2. De aanvallers gebruikten niet-standaard middelen om toegang te krijgen tot het informatiesysteem.
Toelichting U1.1.2.2.2.
De aanvallers kunnen een standaardclient van het informatiesysteem op een knooppunt van een derde partij installeren of kunnen niet-standaardsoftware gebruiken die standaard uitwisselingsprotocollen tussen de client en de server implementeert.
U1.2 Er zijn ongeautoriseerde acties uitgevoerd buiten de gebruikerssessie.
U1.2.1 Aanvallers voerden ongeautoriseerde acties uit en brachten vervolgens ongeautoriseerde wijzigingen aan in de werkingslogboeken van het informatiesysteem of speciale kenmerken van dataobjecten, wat aangeeft dat de acties die ze uitvoerden werden uitgevoerd door een legitieme gebruiker.
U2. Ongeoorloofde wijziging van beschermde informatie tijdens de verwerking ervan door het servergedeelte van het informatiesysteem
Ontleding
U2.1. Aanvallers wijzigen beschermde informatie met behulp van standaardinformatiesysteemtools en doen dit namens een legitieme gebruiker.
U2.1.1. Koppeling: .
U2.2. Aanvallers wijzigen beschermde informatie door gebruik te maken van mechanismen voor gegevenstoegang waarin de normale werking van het informatiesysteem niet voorziet.
U2.2.1. Aanvallers wijzigen bestanden die beveiligde informatie bevatten:
U2.2.1.1. <…>, met behulp van de bestandsverwerkingsmechanismen van het besturingssysteem.
U2.2.1.2. <…> door het herstel van bestanden uit een ongeautoriseerd gewijzigde back-upkopie uit te lokken.
U2.2.2. Aanvallers wijzigen beschermde informatie die is opgeslagen in de database (И):
U2.2.2.1. Aanvallers neutraliseren het DBMS-toegangscontrolesysteem:
U2.2.2.1.1. Koppeling: .
U2.2.2.2. Aanvallers wijzigen informatie met behulp van standaard DBMS-interfaces om toegang te krijgen tot gegevens.
U2.3. Aanvallers wijzigen beschermde informatie door ongeoorloofde wijziging van de besturingsalgoritmen van de software die deze verwerkt.
U2.3.1. De broncode van de software is onderhevig aan wijzigingen.
U2.3.1. De machinecode van de software is onderhevig aan wijzigingen.
U2.4. Aanvallers wijzigen beschermde informatie door misbruik te maken van kwetsbaarheden in informatiesysteemsoftware.
U2.5. Aanvallers wijzigen beschermde informatie wanneer deze wordt overgedragen tussen componenten van het servergedeelte van het informatiesysteem (bijvoorbeeld een databaseserver en een applicatieserver):
U2.5.1. Koppeling: .
TYPISCH BEDREIGINGSMODEL. TOEGANGSCONTROLESYSTEEM
Beveiligingsobject waarvoor het dreigingsmodel (scope) wordt toegepast
Het beschermingsobject waarvoor dit dreigingsmodel wordt toegepast komt overeen met het beschermingsobject van het dreigingsmodel: “Typisch dreigingsmodel. Een informatiesysteem gebouwd op een client-server-architectuur.”
In dit dreigingsmodel betekent een gebruikerstoegangscontrolesysteem een onderdeel van een informatiesysteem dat de volgende functies implementeert:
- Gebruikersidentificatie.
- Gebruikersverificatie.
- Autorisaties van gebruikers.
- Registreren van gebruikersacties.
Beveiligingsbedreigingen op het hoogste niveau
Ontleding
U1. Ongeautoriseerde oprichting van een sessie namens een legitieme gebruiker.
U2. Ongeoorloofde verhoging van gebruikersrechten in een informatiesysteem.
U1. Ongeautoriseerde oprichting van een sessie namens een legitieme gebruiker
Uitleg
De ontleding van deze dreiging zal in het algemeen afhangen van het type gebruikersidentificatie- en authenticatiesystemen dat wordt gebruikt.
In dit model wordt alleen rekening gehouden met een gebruikersidentificatie- en authenticatiesysteem dat gebruikmaakt van tekstaanmelding en wachtwoord. In dit geval gaan we ervan uit dat de login van de gebruiker openbaar beschikbare informatie is die bekend is bij aanvallers.
Ontleding
U1.1. <…> vanwege compromittering van inloggegevens:
U1.1.1. De aanvallers hebben de inloggegevens van de gebruiker gecompromitteerd terwijl ze deze opsloegen.
Toelichting U1.1.1.
De inloggegevens kunnen bijvoorbeeld op een notitie worden geschreven die op de monitor wordt geplakt.
U1.1.2. De gebruiker heeft de toegangsgegevens per ongeluk of kwaadwillig aan de aanvallers doorgegeven.
U1.1.2.1. De gebruiker sprak de inloggegevens hardop uit toen hij binnenkwam.
U1.1.2.2. De gebruiker heeft opzettelijk zijn inloggegevens gedeeld:
U1.1.2.2.1. <…> voor collega's.
Toelichting U1.1.2.2.1.
Bijvoorbeeld zodat ze deze kunnen vervangen tijdens ziekte.
U1.1.2.2.2. <…> aan opdrachtnemers van de werkgever die werkzaamheden uitvoeren aan informatie-infrastructuurobjecten.
U1.1.2.2.3. <…> aan derden.
Toelichting U1.1.2.2.3.
Eén, maar niet de enige optie om deze dreiging te implementeren, is het gebruik van social engineering-methoden door aanvallers.
U1.1.3. De aanvallers selecteerden inloggegevens met behulp van brute force-methoden:
U1.1.3.1. <…> met behulp van standaardtoegangsmechanismen.
U1.1.3.2. <…> eerder onderschepte codes gebruiken (bijvoorbeeld wachtwoord-hashes) voor het opslaan van inloggegevens.
U1.1.4. De aanvallers gebruikten kwaadaardige code om de inloggegevens van gebruikers te onderscheppen.
U1.1.5. De aanvallers haalden inloggegevens uit de netwerkverbinding tussen de client en de server:
U1.1.5.1. Koppeling: .
U1.1.6. De aanvallers haalden inloggegevens uit records van werkbewakingssystemen:
U1.1.6.1. <…> videobewakingssystemen (als toetsaanslagen op het toetsenbord tijdens bedrijf werden opgenomen).
U1.1.6.2. <…> systemen voor het monitoren van de acties van medewerkers op de computer
Toelichting U1.1.6.2.
Een voorbeeld van een dergelijk systeem is .
U1.1.7. Aanvallers hebben gebruikersreferenties gecompromitteerd vanwege fouten in het overdrachtsproces.
Toelichting U1.1.7.
Bijvoorbeeld het versturen van wachtwoorden in leesbare tekst via e-mail.
U1.1.8. Aanvallers verkregen inloggegevens door de sessie van een gebruiker te monitoren met behulp van externe beheersystemen.
U1.1.9. De aanvallers hebben inloggegevens verkregen als gevolg van hun lek via technische kanalen (TCUI):
U1.1.9.1. De aanvallers observeerden hoe de gebruiker inloggegevens via het toetsenbord invoerde:
U1.1.9.1.1 De aanvallers bevonden zich in de nabijheid van de gebruiker en zagen met eigen ogen de invoer van inloggegevens.
Toelichting U1.1.9.1.1
Dergelijke gevallen omvatten de acties van collega's of het geval waarin het toetsenbord van de gebruiker zichtbaar is voor bezoekers van de organisatie.
U1.1.9.1.2 De aanvallers gebruikten aanvullende technische middelen, zoals een verrekijker of een onbemand luchtvaartuig, en zagen via een raam de inloggegevens binnenkomen.
U1.1.9.2. De aanvallers haalden inloggegevens uit de radiocommunicatie tussen het toetsenbord en de computersysteemeenheid wanneer deze waren verbonden via een radio-interface (bijvoorbeeld Bluetooth).
U1.1.9.3. De aanvallers onderschepten inloggegevens door deze te lekken via het kanaal van valse elektromagnetische straling en interferentie (PEMIN).
Toelichting U1.1.9.3.
Voorbeelden van aanvallen и .
U1.1.9.4. De aanvaller onderschepte de invoer van inloggegevens vanaf het toetsenbord met behulp van speciale technische middelen (STS) die waren ontworpen om in het geheim informatie te verkrijgen.
Toelichting U1.1.9.4.
Примеры .
U1.1.9.5. De aanvallers onderschepten de invoer van inloggegevens via het toetsenbord
analyse van het Wi-Fi-signaal gemoduleerd door het toetsaanslagproces van de gebruiker.
Toelichting U1.1.9.5.
Voorbeeld .
U1.1.9.6. De aanvallers onderschepten de invoer van inloggegevens vanaf het toetsenbord door de geluiden van toetsaanslagen te analyseren.
Toelichting U1.1.9.6.
Voorbeeld .
U1.1.9.7. De aanvallers onderschepten de invoer van inloggegevens vanaf het toetsenbord van een mobiel apparaat door de metingen van de versnellingsmeter te analyseren.
Toelichting U1.1.9.7.
Voorbeeld .
U1.1.10. <…>, eerder opgeslagen op de Client.
Toelichting U1.1.10.
Een gebruiker kan bijvoorbeeld een gebruikersnaam en wachtwoord in de browser opslaan om toegang te krijgen tot een specifieke site.
U1.1.11. Aanvallers hebben de inloggegevens gecompromitteerd vanwege fouten in het proces voor het intrekken van gebruikerstoegang.
Toelichting U1.1.11.
Nadat een gebruiker bijvoorbeeld was ontslagen, bleven zijn accounts gedeblokkeerd.
U1.2. <…> door kwetsbaarheden in het toegangscontrolesysteem te misbruiken.
U2. Ongeautoriseerde uitbreiding van gebruikersrechten in een informatiesysteem
Ontleding
U2.1 <…> door ongeoorloofde wijzigingen aan te brengen in gegevens die informatie bevatten over gebruikersrechten.
U2.2 <…> door gebruik van kwetsbaarheden in het toegangscontrolesysteem.
U2.3. <…> vanwege tekortkomingen in het gebruikerstoegangsbeheerproces.
Toelichting U2.3.
Voorbeeld 1. Een gebruiker heeft voor zijn werk meer toegang gekregen dan hij om zakelijke redenen nodig had.
Voorbeeld 2: Nadat een gebruiker naar een andere functie was overgeplaatst, werden eerder verleende toegangsrechten niet ingetrokken.
TYPISCH BEDREIGINGSMODEL. INTEGRATIEMODULE
Beveiligingsobject waarvoor het dreigingsmodel (scope) wordt toegepast
Een integratiemodule is een set informatie-infrastructuurobjecten die zijn ontworpen om de uitwisseling van informatie tussen informatiesystemen te organiseren.
Gezien het feit dat het in bedrijfsnetwerken niet altijd mogelijk is om het ene informatiesysteem eenduidig van het andere te scheiden, kan de integratiemodule ook worden beschouwd als verbindende schakel tussen componenten binnen één informatiesysteem.
Architectuur
Het algemene diagram van de integratiemodule ziet er als volgt uit:
Beschrijving van architectonische elementen:
- "Exchange-server (SO)" – een knooppunt/dienst/component van een informatiesysteem dat de functie vervult van het uitwisselen van gegevens met een ander informatiesysteem.
- "Bemiddelaar" – een knooppunt/dienst die is ontworpen om de interactie tussen informatiesystemen te organiseren, maar daar geen deel van uitmaakt.
Voorbeelden "Bemiddelaars" er kunnen e-maildiensten, bedrijfsservicebussen (enterprise servicebus / SoA-architectuur), bestandsservers van derden, enz. zijn. Over het algemeen mag de integratiemodule geen “Tussenpersonen” bevatten. - "Gegevensverwerkingssoftware" – een reeks programma's die protocollen voor gegevensuitwisseling en formaatconversie implementeren.
Bijvoorbeeld het converteren van gegevens van het UFEBS-formaat naar het ABS-formaat, het wijzigen van de berichtstatus tijdens de verzending, enz. - "Netwerkverbinding" komt overeen met het object dat wordt beschreven in het standaardbedreigingsmodel “Netwerkverbinding”. Sommige van de netwerkverbindingen die in het bovenstaande diagram worden weergegeven, bestaan mogelijk niet.
Voorbeelden van integratiemodules
Schema 1. Integratie van ABS en AWS KBR via een bestandsserver van derden
Om betalingen uit te voeren downloadt een geautoriseerde bankmedewerker elektronische betalingsdocumenten van het kernbanksysteem en slaat deze op in een bestand (in een eigen formaat, bijvoorbeeld een SQL-dump) in een netwerkmap (...SHARE) op een bestandsserver. Vervolgens wordt dit bestand met behulp van een converterscript omgezet in een set bestanden in het UFEBS-formaat, die vervolgens door het CBD-werkstation worden gelezen.
Hierna codeert en ondertekent de geautoriseerde medewerker - de gebruiker van de geautomatiseerde werkplek KBR - de ontvangen bestanden en stuurt deze naar het betalingssysteem van de Bank of Russia.
Wanneer betalingen worden ontvangen van de Bank of Russia, decodeert de geautomatiseerde werkplek van de KBR deze en controleert de elektronische handtekening, waarna deze in de vorm van een reeks bestanden in het UFEBS-formaat op een bestandsserver wordt vastgelegd. Voordat betalingsdocumenten in het ABS worden geïmporteerd, worden ze met behulp van een conversiescript van het UFEBS-formaat naar het ABS-formaat geconverteerd.
We gaan ervan uit dat in dit schema het ABS op één fysieke server werkt, het KBR-werkstation op een speciale computer en het conversiescript op een bestandsserver.
Overeenstemming van de objecten van het beschouwde diagram met de elementen van het integratiemodulemodel:
“Exchange-server vanaf de ABS-kant” – ABS-server.
“Exchange-server vanaf de AWS KBR-kant” – computerwerkstation KBR.
"Bemiddelaar" – bestandsserver van derden.
"Gegevensverwerkingssoftware" – conversiescript.
Schema 2. Integratie van ABS en AWS KBR bij het plaatsen van een gedeelde netwerkmap met betalingen op de AWS KBR
Alles is vergelijkbaar met Schema 1, maar er wordt geen aparte bestandsserver gebruikt; in plaats daarvan wordt een netwerkmap (...SHARE) met elektronische betaaldocumenten op een computer met een werkstation van CBD geplaatst. Het converterscript werkt ook op het CBD-werkstation.
Overeenstemming van de objecten van het beschouwde diagram met de elementen van het integratiemodulemodel:
Vergelijkbaar met Schema 1, maar "Bemiddelaar" niet gebruikt.
Schema 3. Integratie van ABS en geautomatiseerde werkplek KBR-N via IBM WebSphera MQ en ondertekening van elektronische documenten “aan de ABS-kant”
ABS werkt op een platform dat niet wordt ondersteund door de CIPF SCAD Signature. Het ondertekenen van uitgaande elektronische documenten gebeurt op een speciale server voor elektronische handtekeningen (ES Server). Dezelfde server controleert de elektronische handtekening op documenten die binnenkomen van de Bank of Russia.
ABS uploadt een bestand met betaaldocumenten in een eigen formaat naar de ES Server.
De ES-server converteert het bestand met behulp van een conversiescript naar elektronische berichten in het UFEBS-formaat, waarna de elektronische berichten worden ondertekend en verzonden naar IBM WebSphere MQ.
Het KBR-N-werkstation heeft toegang tot IBM WebSphere MQ en ontvangt van daaruit ondertekende betalingsberichten, waarna een geautoriseerde medewerker - een gebruiker van het KBR-werkstation - deze versleutelt en naar het betalingssysteem van de Bank of Russia stuurt.
Wanneer betalingen worden ontvangen van de Bank of Russia, decodeert de geautomatiseerde werkplek KBR-N deze en verifieert de elektronische handtekening. Succesvol verwerkte betalingen in de vorm van gedecodeerde en ondertekende elektronische berichten in het UFEBS-formaat worden overgebracht naar IBM WebSphere MQ, vanwaar ze worden ontvangen door de Electronic Signature Server.
De elektronische handtekeningserver verifieert de elektronische handtekening van ontvangen betalingen en slaat deze op in een bestand in ABS-formaat. Hierna uploadt de geautoriseerde medewerker – de ABS-gebruiker – het resulterende bestand op de voorgeschreven wijze naar het ABS.
Overeenstemming van de objecten van het beschouwde diagram met de elementen van het integratiemodulemodel:
“Exchange-server vanaf de ABS-kant” – ABS-server.
“Exchange-server vanaf de AWS KBR-kant” — computerwerkstation KBR.
"Bemiddelaar" – ES-server en IBM WebSphere MQ.
"Gegevensverwerkingssoftware" – scriptconverter, CIPF SCAD-handtekening op de ES-server.
Schema 4. Integratie van de RBS-server en het kernbanksysteem via de API van een speciale uitwisselingsserver
We gaan ervan uit dat de bank verschillende systemen voor extern bankieren (RBS) gebruikt:
- "Internet Client-Bank" voor particulieren (IKB FL);
- "Internet Client-Bank" voor rechtspersonen (IKB LE).
Om de informatieveiligheid te garanderen, wordt alle interactie tussen het ABS en de systemen voor bankieren op afstand uitgevoerd via een speciale uitwisselingsserver die functioneert binnen het raamwerk van het ABS-informatiesysteem.
Vervolgens zullen we het interactieproces tussen het RBS-systeem van IKB LE en het ABS bekijken.
Nadat de RBS-server een naar behoren gecertificeerde betalingsopdracht van de klant heeft ontvangen, moet op basis daarvan een overeenkomstig document in het ABS worden aangemaakt. Om dit te doen, verzendt het met behulp van de API informatie naar de uitwisselingsserver, die op zijn beurt de gegevens in het ABS invoert.
Wanneer het rekeningsaldo van de klant verandert, genereert het ABS elektronische meldingen, die via de uitwisselingsserver naar de server voor extern bankieren worden verzonden.
Overeenstemming van de objecten van het beschouwde diagram met de elementen van het integratiemodulemodel:
“Exchange-server vanaf de RBS-kant” – RBS-server van IKB YUL.
“Exchange-server vanaf de ABS-kant” – uitwisselingsserver.
"Bemiddelaar" - missend.
"Gegevensverwerkingssoftware" – RBS Server-componenten die verantwoordelijk zijn voor het gebruik van de uitwisselingsserver-API, uitwisselingsservercomponenten die verantwoordelijk zijn voor het gebruik van de core banking-API.
Beveiligingsbedreigingen op het hoogste niveau
Ontleding
U1. Injectie van valse informatie door aanvallers via de integratiemodule.
U1. Injectie van valse informatie door aanvallers via de integratiemodule
Ontleding
U1.1. Ongeautoriseerde wijziging van legitieme gegevens wanneer deze via netwerkverbindingen worden verzonden:
U1.1.1 Koppeling: .
U1.2. Verzending van valse gegevens via communicatiekanalen namens een legitieme uitwisselingsdeelnemer:
U1.1.2 Koppeling: .
U1.3. Ongeautoriseerde wijziging van legitieme gegevens tijdens de verwerking ervan op Exchange-servers of de tussenpersoon:
U1.3.1. Koppeling: .
U1.4. Aanmaak van valse gegevens op de Exchange-servers of tussenpersoon namens een legitieme uitwisselingsdeelnemer:
U1.4.1. Koppeling:
U1.5. Ongeautoriseerde wijziging van gegevens bij verwerking met behulp van gegevensverwerkingssoftware:
U1.5.1. <…> doordat aanvallers ongeoorloofde wijzigingen aanbrengen in de instellingen (configuratie) van gegevensverwerkingssoftware.
U1.5.2. <…> doordat aanvallers ongeoorloofde wijzigingen aanbrengen in uitvoerbare bestanden van gegevensverwerkingssoftware.
U1.5.3. <…> vanwege de interactieve controle van de gegevensverwerkingssoftware door aanvallers.
TYPISCH BEDREIGINGSMODEL. CRYPTOGRAFISCHE INFORMATIEBESCHERMINGSSYSTEEM
Beveiligingsobject waarvoor het dreigingsmodel (scope) wordt toegepast
Het object van bescherming is een cryptografisch informatiebeschermingssysteem dat wordt gebruikt om de veiligheid van het informatiesysteem te waarborgen.
Architectuur
De basis van elk informatiesysteem is applicatiesoftware die de doelfunctionaliteit implementeert.
Cryptografische bescherming wordt meestal geïmplementeerd door cryptografische primitieven op te roepen vanuit de bedrijfslogica van de applicatiesoftware, die zich in gespecialiseerde bibliotheken bevinden: cryptokernen.
Cryptografische primitieven omvatten cryptografische functies op laag niveau, zoals:
- een gegevensblok coderen/decoderen;
- een elektronische handtekening van een datablok aanmaken/verifiëren;
- bereken de hashfunctie van het datablok;
- sleutelinformatie genereren/laden/uploaden;
- etc.
De bedrijfslogica van de applicatiesoftware implementeert functionaliteit op een hoger niveau met behulp van cryptografische primitieven:
- versleutel het bestand met de sleutels van de geselecteerde ontvangers;
- een beveiligde netwerkverbinding tot stand brengen;
- informeren over de resultaten van het controleren van de elektronische handtekening;
- en zo verder.
De interactie tussen bedrijfslogica en cryptokern kan worden uitgevoerd:
- rechtstreeks, door bedrijfslogica die cryptografische primitieven aanroept uit dynamische bibliotheken van de cryptokernel (.DLL voor Windows, .SO voor Linux);
- direct, via cryptografische interfaces - wrappers, bijvoorbeeld MS Crypto API, Java Cryptography Architecture, PKCS#11, enz. In dit geval heeft de bedrijfslogica toegang tot de crypto-interface en vertaalt de oproep naar de overeenkomstige crypto-kern, die in dit geval wordt cryptoprovider genoemd. Het gebruik van cryptografische interfaces zorgt ervoor dat applicatiesoftware kan abstraheren van specifieke cryptografische algoritmen en flexibeler kan zijn.
Er zijn twee typische schema’s voor het organiseren van de cryptokern:
Schema 1 – Monolithische cryptokern
Schema 2 – Gesplitste cryptokern
De elementen in de bovenstaande diagrammen kunnen individuele softwaremodules zijn die op één computer draaien, of netwerkservices die samenwerken binnen een computernetwerk.
Bij gebruik van systemen die zijn gebouwd volgens Schema 1, werken de applicatiesoftware en de crypto-kern binnen één enkele besturingsomgeving voor de cryptotool (SFC), bijvoorbeeld op dezelfde computer met hetzelfde besturingssysteem. De systeemgebruiker kan in de regel andere programma's uitvoeren, inclusief programma's die kwaadaardige code bevatten, binnen dezelfde besturingsomgeving. Onder dergelijke omstandigheden bestaat er een ernstig risico op het lekken van private cryptografische sleutels.
Om het risico te minimaliseren wordt gebruik gemaakt van schema 2, waarbij de cryptokern in twee delen wordt verdeeld:
- Het eerste deel werkt samen met de applicatiesoftware in een niet-vertrouwde omgeving waar het risico bestaat op infectie met kwaadaardige code. We zullen dit onderdeel het “softwaregedeelte” noemen.
- Het tweede deel werkt in een vertrouwde omgeving op een speciaal apparaat, dat een privésleutelopslag bevat. Vanaf nu zullen we dit onderdeel “hardware” noemen.
De verdeling van de cryptokern in software- en hardwareonderdelen is zeer willekeurig. Er zijn systemen op de markt die zijn gebouwd volgens een schema met een verdeelde crypto-kern, maar waarvan het 'hardware'-gedeelte wordt gepresenteerd in de vorm van een afbeelding van een virtuele machine - virtuele HSM ().
De interactie tussen beide delen van de cryptokern vindt plaats op een zodanige manier dat private cryptografische sleutels nooit worden overgedragen aan het softwaredeel en dus niet kunnen worden gestolen met behulp van kwaadaardige code.
De interactie-interface (API) en de set cryptografische primitieven die door de cryptokern aan de applicatiesoftware worden geleverd, zijn in beide gevallen hetzelfde. Het verschil ligt in de manier waarop ze worden geïmplementeerd.
Bij gebruik van een schema met een verdeelde cryptokern wordt de interactie tussen software en hardware dus uitgevoerd volgens het volgende principe:
- Cryptografische primitieven waarvoor geen privésleutel nodig is (bijvoorbeeld het berekenen van een hashfunctie, het verifiëren van een elektronische handtekening, enz.) worden door de software uitgevoerd.
- Cryptografische primitieven die een privésleutel gebruiken (het creëren van een elektronische handtekening, het decoderen van gegevens, enz.) worden uitgevoerd door hardware.
Laten we het werk van de verdeelde cryptokern illustreren met behulp van het voorbeeld van het maken van een elektronische handtekening:
- Het softwaregedeelte berekent de hashfunctie van de ondertekende gegevens en verzendt deze waarde via het uitwisselingskanaal tussen cryptokernen naar de hardware.
- Het hardwaregedeelte genereert, met behulp van de privésleutel en hash, de waarde van de elektronische handtekening en verzendt deze via een uitwisselingskanaal naar het softwaregedeelte.
- Het softwaregedeelte stuurt de ontvangen waarde terug naar de applicatiesoftware.
Kenmerken van het controleren van de juistheid van een elektronische handtekening
Wanneer de ontvangende partij elektronisch ondertekende gegevens ontvangt, moet deze verschillende verificatiestappen uitvoeren. Een positief resultaat van het controleren van een elektronische handtekening wordt alleen bereikt als alle verificatiefasen met succes zijn voltooid.
Fase 1. Controle van de data-integriteit en het auteurschap van de data.
Inhoud van het podium. De elektronische handtekening van de gegevens wordt geverifieerd met behulp van het juiste cryptografische algoritme. Succesvolle voltooiing van deze fase geeft aan dat de gegevens niet zijn gewijzigd sinds het moment van ondertekening, en ook dat de handtekening is gemaakt met een privésleutel die overeenkomt met de publieke sleutel voor het verifiëren van de elektronische handtekening.
Locatie van het podium: crypto-kern.
Fase 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 het podium. De fase bestaat uit twee tussenliggende subfasen. De eerste is om te bepalen of de publieke sleutel voor het verifiëren van de elektronische handtekening vertrouwd was op het moment dat de gegevens werden ondertekend. De tweede bepaalt of de privésleutel van de elektronische handtekening geldig was op het moment dat de gegevens werden ondertekend. Over het algemeen vallen de geldigheidsperioden van deze sleutels mogelijk niet samen (bijvoorbeeld voor gekwalificeerde certificaten van sleutels voor de verificatie van elektronische handtekeningen). Methoden voor het vestigen van vertrouwen in de publieke sleutel van de ondertekenaar worden bepaald door de regels voor elektronisch documentbeheer die door de samenwerkende partijen zijn aangenomen.
Locatie van het podium: applicatiesoftware / cryptokern.
Fase 3. Controle van de autoriteit van de ondertekenaar.
Inhoud van het podium. In overeenstemming met de vastgestelde regels voor elektronisch documentbeheer wordt gecontroleerd of de ondertekenaar het recht had om de beschermde gegevens te certificeren. Laten we als voorbeeld een situatie geven waarin autoriteit wordt geschonden. Stel dat er een organisatie is waar alle medewerkers een elektronische handtekening hebben. Het interne elektronische documentbeheersysteem ontvangt een opdracht van de manager, maar ondertekend met de elektronische handtekening van de magazijnbeheerder. Bijgevolg kan een dergelijk document niet als legitiem worden beschouwd.
Locatie van het podium: applicatiesoftware.
Aannames gemaakt bij de beschrijving van het beschermingsobject
- Kanalen voor informatieoverdracht, met uitzondering van kanalen voor sleuteluitwisseling, lopen ook via applicatiesoftware, API en crypto-core.
- Informatie over het vertrouwen in publieke sleutels en (of) certificaten, evenals informatie over de bevoegdheden van eigenaren van publieke sleutels, wordt in het publieke sleutelarchief geplaatst.
- De applicatiesoftware werkt met de openbare sleutelopslag via de cryptokernel.
Een voorbeeld van een informatiesysteem dat is beveiligd met CIPF
Laten we, om de eerder gepresenteerde diagrammen te illustreren, een hypothetisch informatiesysteem bekijken en alle structurele elementen erop benadrukken.
Beschrijving van het informatiesysteem
De twee organisaties besloten onderling juridisch significant elektronisch documentbeheer (EDF) te introduceren. Om dit te doen, sloten ze een overeenkomst waarin ze bepaalden dat documenten per e-mail zouden worden verzonden en dat ze tegelijkertijd moesten worden gecodeerd en ondertekend met een gekwalificeerde elektronische handtekening. Office-programma's uit het Microsoft Office 2016-pakket moeten worden gebruikt als hulpmiddelen voor het maken en verwerken van documenten, en CIPF CryptoPRO en coderingssoftware CryptoARM moeten worden gebruikt als middel voor cryptografische bescherming.
Beschrijving van de infrastructuur van de organisatie 1
Organisatie 1 besloot dat het CIPF CryptoPRO- en CryptoARM-software op het werkstation van de gebruiker, een fysieke computer, zou installeren. Encryptie- en elektronische handtekeningsleutels worden opgeslagen op de ruToken-sleutelmedia, die werken in de modus voor ophaalbare sleutels. De gebruiker bereidt elektronische documenten lokaal op zijn computer voor en codeert, ondertekent en verzendt ze vervolgens met behulp van een lokaal geïnstalleerde e-mailclient.
Beschrijving van de infrastructuur van de organisatie 2
Organisatie 2 besloot de functies voor versleuteling en elektronische handtekeningen naar een speciale virtuele machine te verplaatsen. In dit geval worden alle cryptografische bewerkingen automatisch uitgevoerd.
Om dit te doen, zijn er twee netwerkmappen georganiseerd op de speciale virtuele machine: “...In”, “...Out”. Bestanden die in open vorm van de wederpartij worden ontvangen, worden automatisch in de netwerkmap “…In” geplaatst. Deze bestanden worden gedecodeerd en de elektronische handtekening wordt geverifieerd.
De gebruiker plaatst bestanden in de map “…Out” die gecodeerd, ondertekend en naar de tegenpartij moeten worden verzonden. De gebruiker bereidt de bestanden zelf voor op zijn werkstation.
Om coderings- en elektronische handtekeningfuncties uit te voeren, zijn CIPF CryptoPRO, CryptoARM-software en een e-mailclient op de virtuele machine geïnstalleerd. Automatisch beheer van alle elementen van de virtuele machine zal worden uitgevoerd met behulp van scripts die zijn ontwikkeld door systeembeheerders. Het werk van scripts wordt vastgelegd in logbestanden.
Cryptografische sleutels voor de elektronische handtekening worden op een token geplaatst met een niet-ophaalbare JaCarta GOST-sleutel, die de gebruiker verbindt met zijn lokale computer.
Het token wordt doorgestuurd naar de virtuele machine met behulp van gespecialiseerde USB-over-IP-software die op het werkstation van de gebruiker en op de virtuele machine is geïnstalleerd.
De systeemklok op de werkplek van de gebruiker in organisatie 1 wordt handmatig aangepast. De systeemklok van de speciale virtuele machine in Organisatie 2 wordt gesynchroniseerd met de hypervisorsysteemklok, die op zijn beurt via internet wordt gesynchroniseerd met openbare tijdservers.
Identificatie van structurele elementen van CIPF
Op basis van de bovenstaande beschrijving van de IT-infrastructuur zullen we de structurele elementen van CIPF benadrukken en deze in een tabel schrijven.
Tabel - Correspondentie van CIPF-modelelementen met informatiesysteemelementen
Naam van het item
Organisatie 1
Organisatie 2
Applicatiesoftware
CryptoARM-software
CryptoARM-software
Softwareonderdeel van de cryptokern
CIPF CryptoPRO CSP
CIPF CryptoPRO CSP
Crypto-kernhardware
Geen
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Openbare sleutelopslag
Werkstation van de gebruiker:
- HDD;
- standaard Windows-certificaatarchief.
Hypervisor:
- HDD.
Virtuele machine:
- HDD;
- standaard Windows-certificaatarchief.
Opslag van privésleutels
ruToken-sleuteldrager werkt in ophaalbare sleutelmodus
JaCarta GOST-sleuteldrager werkt in niet-verwijderbare sleutelmodus
Kanaal voor openbare sleuteluitwisseling
Werkstation van de gebruiker:
- RAM.
Hypervisor:
- RAM.
Virtuele machine:
- RAM.
Kanaal voor privésleuteluitwisseling
Werkstation van de gebruiker:
— USB-bus;
- RAM.
Geen
Uitwisselingskanaal tussen cryptokernen
ontbreekt (geen crypto core hardware)
Werkstation van de gebruiker:
— USB-bus;
- RAM;
— USB-over-IP-softwaremodule;
- netwerkinterface.
Bedrijfsnetwerk van de organisatie 2.
Hypervisor:
- RAM;
- netwerkinterface.
Virtuele machine:
- netwerkinterface;
- RAM;
— USB-over-IP-softwaremodule.
Open datakanaal
Werkstation van de gebruiker:
— input-outputmiddelen;
- RAM;
- HDD.
Werkstation van de gebruiker:
— input-outputmiddelen;
- RAM;
- HDD;
- netwerkinterface.
Bedrijfsnetwerk van de organisatie 2.
Hypervisor:
- netwerkinterface;
- RAM;
- HDD.
Virtuele machine:
- netwerkinterface;
- RAM;
- HDD.
Beveiligd gegevensuitwisselingskanaal
Internet.
Bedrijfsnetwerk van de organisatie 1.
Werkstation van de gebruiker:
- HDD;
- RAM;
- netwerkinterface.
Internet.
Bedrijfsnetwerk van de organisatie 2.
Hypervisor:
- netwerkinterface;
- RAM;
- HDD.
Virtuele machine:
- netwerkinterface;
- RAM;
- HDD.
Tijd kanaal
Werkstation van de gebruiker:
— input-outputmiddelen;
- RAM;
- systeemtimer.
Internet.
Bedrijfsnetwerk van organisatie 2,
Hypervisor:
- netwerkinterface;
- RAM;
- systeemtimer.
Virtuele machine:
- RAM;
- systeemtimer.
Transmissiekanaal voor stuurcommando's
Werkstation van de gebruiker:
— input-outputmiddelen;
- RAM.
(Grafische gebruikersinterface van CryptoARM-software)
Virtuele machine:
- RAM;
- HDD.
(Automatiseringsscripts)
Kanaal voor het ontvangen van werkresultaten
Werkstation van de gebruiker:
— input-outputmiddelen;
- RAM.
(Grafische gebruikersinterface van CryptoARM-software)
Virtuele machine:
- RAM;
- HDD.
(Logbestanden van automatiseringsscripts)
Beveiligingsbedreigingen op het hoogste niveau
Uitleg
Aannames bij het ontleden van bedreigingen:
- Er wordt gebruik gemaakt van sterke cryptografische algoritmen.
- Cryptografische algoritmen worden veilig gebruikt in de juiste werkingsmodi (bijv. wordt niet gebruikt voor het versleutelen van grote hoeveelheden gegevens, er wordt rekening gehouden met de toegestane belasting van de sleutel, enz.).
- Aanvallers kennen alle gebruikte algoritmen, protocollen en publieke sleutels.
- Aanvallers kunnen alle gecodeerde gegevens lezen.
- Aanvallers kunnen alle software-elementen in het systeem reproduceren.
Ontleding
U1. Compromis van private cryptografische sleutels.
U2. Het versleutelen van valse gegevens namens de legitieme afzender.
U3. Decodering van gecodeerde gegevens door personen die geen legitieme ontvangers van de gegevens zijn (aanvallers).
U4. Creatie van een elektronische handtekening van een legitieme ondertekenaar onder valse gegevens.
U5. Een positief resultaat verkrijgen door de elektronische handtekening van vervalste gegevens te controleren.
U6. Foutieve aanvaarding van elektronische documenten voor uitvoering als gevolg van problemen bij het organiseren van de elektronische documentenstroom.
U7. Ongeoorloofde toegang tot beschermde gegevens tijdens de verwerking ervan door CIPF.
U1. Compromis van private cryptografische sleutels
U1.1. De privésleutel ophalen uit het privésleutelarchief.
U1.2. Het verkrijgen van een privésleutel van objecten in de besturingsomgeving van de cryptotool, waarin deze zich tijdelijk kan bevinden.
Toelichting U1.2.
Objecten die tijdelijk een privésleutel kunnen opslaan, zijn onder meer:
- RAM,
- tijdelijke bestanden,
- bestanden uitwisselen,
- slaapstandbestanden,
- momentopnamebestanden van de ‘hot’-status van virtuele machines, inclusief bestanden met de inhoud van het RAM-geheugen van gepauzeerde virtuele machines.
U1.2.1. Het extraheren van privésleutels uit het werkende RAM door RAM-modules te bevriezen, ze te verwijderen en vervolgens de gegevens te lezen (bevriezingsaanval).
Toelichting U1.2.1.
Voorbeeld .
U1.3. Het verkrijgen van een privésleutel via een privésleuteluitwisselingskanaal.
Toelichting U1.3.
Er zal een voorbeeld worden gegeven van de implementatie van deze dreiging .
U1.4. Ongeautoriseerde wijziging van de cryptokern, waardoor private sleutels bekend worden bij aanvallers.
U1.5. Compromis van een privésleutel als gevolg van het gebruik van technische informatielekkanalen (TCIL).
Toelichting U1.5.
Voorbeeld .
U1.6. Compromis van een privésleutel als gevolg van het gebruik van speciale technische middelen (STS) die zijn ontworpen voor het in het geheim ophalen van informatie (“bugs”).
U1.7. Compromis van privésleutels tijdens opslag buiten het CIPF.
Toelichting U1.7.
Een gebruiker bewaart zijn sleutelmedia bijvoorbeeld in een lade op het bureaublad, waaruit deze gemakkelijk door aanvallers kunnen worden opgehaald.
U2. Het versleutelen van valse gegevens namens een legitieme afzender
Uitleg
Deze bedreiging wordt alleen in aanmerking genomen voor gegevensversleutelingsschema's met afzenderauthenticatie. Voorbeelden van dergelijke schema's worden aangegeven in de standaardisatieaanbevelingen . Bij andere cryptografische systemen bestaat deze dreiging niet, omdat de encryptie wordt uitgevoerd op de publieke sleutels van de ontvanger, en deze zijn algemeen bekend bij aanvallers.
Ontleding
U2.1. Het compromitteren van de privésleutel van de afzender:
U2.1.1. Koppeling: .
U2.2. Vervanging van invoergegevens in een open gegevensuitwisselingskanaal.
Opmerkingen U2.2.
Voorbeelden van de implementatie van deze dreiging worden hieronder gegeven. и .
U3. Decodering van gecodeerde gegevens door personen die geen legitieme ontvangers van de gegevens zijn (aanvallers)
Ontleding
U3.1. Compromis van de privésleutels van de ontvanger van gecodeerde gegevens.
U3.1.1 Koppeling: .
U3.2. Vervanging van gecodeerde gegevens in een beveiligd gegevensuitwisselingskanaal.
U4. Het creëren van een elektronische handtekening van een legitieme ondertekenaar onder valse gegevens
Ontleding
U4.1. Compromis van de privésleutels van de elektronische handtekening van een legitieme ondertekenaar.
U4.1.1 Koppeling: .
U4.2. Vervanging van ondertekende gegevens in een open gegevensuitwisselingskanaal.
Opmerking U4.2.
Voorbeelden van de implementatie van deze dreiging worden hieronder gegeven. и .
U5. Een positief resultaat verkrijgen door de elektronische handtekening van vervalste gegevens te controleren
Ontleding
U5.1. Aanvallers onderscheppen in het kanaal voor het verzenden van werkresultaten een bericht over een negatief resultaat van het controleren van een elektronische handtekening en vervangen dit door een bericht met een positief resultaat.
U5.2. Aanvallers vallen het vertrouwen in het ondertekenen van certificaten aan (SCRIPT - alle elementen zijn vereist):
U5.2.1. Aanvallers genereren een publieke en private sleutel voor een elektronische handtekening. Als het systeem sleutelcertificaten voor elektronische handtekeningen gebruikt, genereren ze een elektronisch handtekeningcertificaat dat zoveel mogelijk lijkt op het certificaat van de beoogde afzender van de gegevens wiens bericht ze willen vervalsen.
U5.2.2. Aanvallers brengen ongeoorloofde wijzigingen aan in de openbare sleutelopslag, waardoor ze met de openbare sleutel het noodzakelijke niveau van vertrouwen en autoriteit genereren.
U5.2.3. Aanvallers ondertekenen valse gegevens met een eerder gegenereerde elektronische handtekeningsleutel en voegen deze in het beveiligde gegevensuitwisselingskanaal.
U5.3. Aanvallers voeren een aanval uit met behulp van verlopen elektronische handtekeningsleutels van een wettelijke ondertekenaar (SCRIPT - alle elementen zijn vereist):
U5.3.1. Aanvallers compromitteren verlopen (momenteel niet geldige) privésleutels van de elektronische handtekening van een legitieme afzender.
U5.3.2. Aanvallers vervangen de tijd in het tijdtransmissiekanaal door de tijd waarop de gecompromitteerde sleutels nog geldig waren.
U5.3.3. Aanvallers ondertekenen valse gegevens met een eerder gecompromitteerde elektronische handtekeningsleutel en injecteren deze in het beveiligde gegevensuitwisselingskanaal.
U5.4. Aanvallers voeren een aanval uit met behulp van gecompromitteerde elektronische handtekeningsleutels van een wettelijke ondertekenaar (SCRIPT - alle elementen zijn vereist):
U5.4.1. De aanvaller maakt een kopie van de openbare sleutelopslag.
U5.4.2. De aanvallers compromitteren de privésleutels van een van de legitieme afzenders. Hij merkt het compromis op, trekt de sleutels in en informatie over de sleutelintrekking wordt in de openbare sleutelopslag geplaatst.
U5.4.3. Aanvallers vervangen de openbare sleutelopslag door een eerder gekopieerd exemplaar.
U5.4.4. Aanvallers ondertekenen valse gegevens met een eerder gecompromitteerde elektronische handtekeningsleutel en injecteren deze in het beveiligde gegevensuitwisselingskanaal.
U5.5. <…> vanwege de aanwezigheid van fouten bij de implementatie van de tweede en derde fase van de verificatie van elektronische handtekeningen:
Toelichting U5.5.
Er wordt een voorbeeld gegeven van de implementatie van deze dreiging .
U5.5.1. Het vertrouwen in een sleutelcertificaat voor elektronische handtekeningen alleen controleren op basis van de aanwezigheid van vertrouwen in het certificaat waarmee het is ondertekend, zonder CRL- of OCSP-controles.
Toelichting U5.5.1.
Implementatie voorbeeld .
U5.5.2. Bij het opbouwen van een vertrouwensketen voor een certificaat worden de autoriteiten van de uitgifte van certificaten niet geanalyseerd
Toelichting U5.5.2.
Een voorbeeld van een aanval op SSL/TLS-certificaten.
De aanvallers kochten een legitiem certificaat voor hun e-mail. Vervolgens maakten ze een frauduleus sitecertificaat en ondertekenden dit met hun certificaat. Als de inloggegevens niet worden gecontroleerd, zal het bij het controleren van de vertrouwensketen correct blijken te zijn, en dienovereenkomstig zal het frauduleuze certificaat ook correct zijn.
U5.5.3. Bij het opbouwen van een certificaatvertrouwensketen worden tussenliggende certificaten niet gecontroleerd op intrekking.
U5.5.4. CRL's worden minder vaak bijgewerkt dan ze door de certificeringsinstantie worden uitgegeven.
U5.5.5. De beslissing om een elektronische handtekening te vertrouwen wordt genomen voordat een OCSP-antwoord over de status van het certificaat is ontvangen, verzonden op een verzoek dat later is gedaan dan het moment waarop de handtekening is gegenereerd of eerder dan de volgende CRL nadat de handtekening is gegenereerd.
Toelichting U5.5.5.
In de regelgeving van de meeste CA's wordt als tijdstip van certificaatintrekking beschouwd het tijdstip van uitgifte van de dichtstbijzijnde CRL die informatie bevat over de certificaatintrekking.
U5.5.6. Bij het ontvangen van ondertekende gegevens wordt het certificaat van de afzender niet gecontroleerd.
Toelichting U5.5.6.
Voorbeeld van een aanval. Met betrekking tot SSL-certificaten: de overeenkomst van het opgeroepen serveradres met de waarde van het CN-veld in het certificaat mag niet worden gecontroleerd.
Voorbeeld van een aanval. Aanvallers hebben de elektronische handtekeningsleutels van een van de deelnemers aan het betalingssysteem gecompromitteerd. Daarna hackten ze het netwerk van een andere deelnemer en stuurden namens hem betalingsdocumenten, ondertekend met gecompromitteerde sleutels, naar de verrekeningsserver van het betalingssysteem. Als de server alleen het vertrouwen analyseert en niet controleert op naleving, worden frauduleuze documenten als legitiem beschouwd.
U6. Foutieve aanvaarding van elektronische documenten voor uitvoering als gevolg van problemen bij het organiseren van de elektronische documentenstroom.
Ontleding
U6.1. De ontvangende partij detecteert geen duplicatie van ontvangen documenten.
Toelichting U6.1.
Voorbeeld van een aanval. Aanvallers kunnen een document onderscheppen dat naar een ontvanger wordt verzonden, zelfs als het cryptografisch is beveiligd, en dit vervolgens herhaaldelijk via een beveiligd gegevensoverdrachtkanaal verzenden. Als de ontvanger geen duplicaten identificeert, worden alle ontvangen documenten als verschillende documenten beschouwd en verwerkt.
U7. Ongeoorloofde toegang tot beschermde gegevens tijdens de verwerking ervan door CIPF
Ontleding
U7.1. <…> door informatielekkage via zijkanalen (zijkanaalaanval).
Toelichting U7.1.
Voorbeeld .
U7.2. <…> vanwege de neutralisatie van de bescherming tegen ongeoorloofde toegang tot informatie verwerkt op CIPF:
U7.2.1. Exploitatie van CIPF in strijd met de vereisten beschreven in de documentatie voor CIPF.
U7.2.2. <…>, uitgevoerd vanwege de aanwezigheid van kwetsbaarheden in:
U7.2.2.1. <…> middelen ter bescherming tegen ongeoorloofde toegang.
U7.2.2.2. <…> CIPF zelf.
U7.2.2.3. <…> de besturingsomgeving van de cryptotool.
Voorbeelden van aanvallen
De hieronder besproken scenario's bevatten uiteraard informatiebeveiligingsfouten en dienen alleen ter illustratie van mogelijke aanvallen.
Scenario 1. Een voorbeeld van de implementatie van dreigingen U2.2 en U4.2.
Beschrijving van het object
De AWS KBR-software en CIPF SCAD Signature worden geïnstalleerd op een fysieke computer die niet is aangesloten op het computernetwerk. FKN vdToken wordt gebruikt als sleuteldrager bij het werken met een niet-verwijderbare sleutel.
Het schikkingsreglement gaat ervan uit dat de afwikkelingsspecialist vanaf zijn werkcomputer elektronische berichten in duidelijke tekst (schema van het oude KBR-werkstation) downloadt van een speciaal beveiligde bestandsserver, deze vervolgens op een overdraagbare USB-stick schrijft en naar het KBR-werkstation overbrengt, waar ze zijn gecodeerd en ondertekend. Hierna brengt de specialist beveiligde elektronische berichten over naar het vervreemde medium en schrijft ze vervolgens via zijn werkcomputer naar een bestandsserver, vanwaar ze naar UTA gaan en vervolgens naar het betalingssysteem van de Bank of Russia.
In dit geval omvatten de kanalen voor het uitwisselen van open en beschermde gegevens: een bestandsserver, de werkcomputer van een specialist en vervreemde media.
Aanval
Ongeautoriseerde aanvallers installeren een afstandsbedieningssysteem op de werkcomputer van een specialist en vervangen, op het moment dat betalingsopdrachten (elektronische berichten) naar een overdraagbaar medium worden geschreven, de inhoud van een ervan in duidelijke tekst. De specialist geeft betaalopdrachten door aan de geautomatiseerde werkplek van KBR, ondertekent en versleutelt deze zonder de vervanging op te merken (bijvoorbeeld door een groot aantal betaalopdrachten op een vlucht, vermoeidheid etc.). Hierna komt de valse betalingsopdracht, nadat hij de technologische keten heeft doorlopen, het betalingssysteem van de Bank of Russia binnen.
Scenario 2. Een voorbeeld van de implementatie van dreigingen U2.2 en U4.2.
Beschrijving van het object
Een computer met daarop een geïnstalleerde werkplek KBR, SCAD Signature en een aangesloten sleuteldrager FKN vdToken draait in een daarvoor bestemde ruimte zonder toegang van personeel.
De rekenspecialist maakt via het RDP-protocol verbinding met het CBD-werkstation in de modus voor externe toegang.
Aanval
Aanvallers onderscheppen de gegevens, waarmee de rekenspecialist verbinding maakt en met het CBD-werkstation werkt (bijvoorbeeld via kwaadaardige code op zijn computer). Vervolgens maken ze namens hem verbinding en sturen een valse betalingsopdracht naar het betalingssysteem van de Bank of Russia.
Scenario 3. Voorbeeld van implementatie van bedreigingen U1.3.
Beschrijving van het object
Laten we een van de hypothetische opties bekijken voor het implementeren van de ABS-KBR-integratiemodules voor een nieuw schema (AWS KBR-N), waarin de elektronische handtekening van uitgaande documenten aan de ABS-kant plaatsvindt. In dit geval gaan we ervan uit dat het ABS werkt op basis van een besturingssysteem dat niet wordt ondersteund door de CIPF SKAD-handtekening, en dienovereenkomstig wordt de cryptografische functionaliteit overgebracht naar een afzonderlijke virtuele machine - de “ABS-KBR”-integratie module.
Als sleuteldrager wordt een regulier USB-token gebruikt dat in de ophaalbare sleutelmodus werkt. Bij het aansluiten van de sleutelmedia op de hypervisor bleek dat er geen vrije USB-poorten in het systeem waren, dus werd besloten om het USB-token via een netwerk-USB-hub aan te sluiten en een USB-over-IP-client op de virtuele te installeren. machine, die zou communiceren met de hub.
Aanval
De aanvallers onderschepten de privésleutel van de elektronische handtekening van het communicatiekanaal tussen de USB-hub en de hypervisor (gegevens werden in duidelijke tekst verzonden). Met de privésleutel genereerden de aanvallers een valse betalingsopdracht, ondertekenden deze met een elektronische handtekening en stuurden deze ter uitvoering naar de geautomatiseerde KBR-N-werkplaats.
Scenario 4. Een voorbeeld van de implementatie van dreigingen U5.5.
Beschrijving van het object
Laten we hetzelfde circuit beschouwen als in het vorige scenario. We gaan ervan uit dat elektronische berichten afkomstig van het KBR-N-werkstation in de map …SHAREIn terechtkomen, en dat de berichten die naar het KBR-N-werkstation en verder naar het betalingssysteem van de Bank of Russia worden verzonden, naar …SHAREout gaan.
We gaan er ook van uit dat bij het implementeren van de integratiemodule lijsten met ingetrokken certificaten alleen worden bijgewerkt wanneer cryptografische sleutels opnieuw worden uitgegeven, en ook dat elektronische berichten die worden ontvangen in de map …SHAREIn alleen worden gecontroleerd op integriteitscontrole en vertrouwenscontrole in de openbare sleutel van de elektronische handtekening.
Aanval
De aanvallers gebruikten de sleutels die in het vorige scenario waren gestolen, ondertekenden een valse betalingsopdracht met informatie over de ontvangst van geld op de rekening van de frauduleuze klant en introduceerden deze in het beveiligde gegevensuitwisselingskanaal. Omdat er geen verificatie is dat de betalingsopdracht is ondertekend door de Bank of Russia, wordt deze geaccepteerd voor uitvoering.
Bron: www.habr.com