Nog niet zo lang geleden hebben we opnieuw een beoordeling uitgevoerd van de naleving van de vereisten van GOST R 57580 (hierna eenvoudigweg GOST genoemd). De opdrachtgever is een bedrijf dat een elektronisch betalingssysteem ontwikkelt. Het systeem is serieus: meer dan 3 miljoen gebruikers, meer dan 200 transacties per dag. Ze nemen informatiebeveiliging daar zeer serieus.
Tijdens het evaluatieproces kondigde de klant terloops aan dat de ontwikkelingsafdeling, naast virtuele machines, van plan is containers te gebruiken. Maar hiermee, voegde de klant eraan toe, is er één probleem: in GOST is er geen woord over dezelfde Docker. Wat moet ik doen? Hoe de veiligheid van containers evalueren?
Het is waar, GOST schrijft alleen over hardwarevirtualisatie - over het beschermen van virtuele machines, een hypervisor en een server. Wij hebben de Centrale Bank om opheldering gevraagd. Het antwoord verbaasde ons.
GOST en virtualisatie
Laten we om te beginnen bedenken dat GOST R 57580 een nieuwe standaard is die “vereisten specificeert voor het waarborgen van de informatiebeveiliging van financiële organisaties” (FI). Deze FI's omvatten exploitanten en deelnemers van betalingssystemen, krediet- en niet-kredietorganisaties, operationele en clearingcentra.
Vanaf 1 januari 2021 zijn FI’s verplicht om te voeren . Wij, ITGLOBAL.COM, zijn een auditbedrijf dat dergelijke beoordelingen uitvoert.
GOST heeft een subsectie gewijd aan de bescherming van gevirtualiseerde omgevingen - nr. 7.8. De term “virtualisatie” wordt daar niet gespecificeerd; er is geen onderscheid in hardware- en containervirtualisatie. Elke IT-specialist zal zeggen dat dit technisch gezien onjuist is: een virtuele machine (VM) en een container zijn verschillende omgevingen, met verschillende isolatieprincipes. Vanuit het oogpunt van de kwetsbaarheid van de host waarop de VM- en Docker-containers worden ingezet, is dit ook een groot verschil.
Het blijkt dat de beoordeling van de informatiebeveiliging van VM’s en containers ook anders zou moeten zijn.
Onze vragen aan de Centrale Bank
We hebben ze naar de afdeling Informatiebeveiliging van de Centrale Bank gestuurd (we presenteren de vragen in verkorte vorm).
- Hoe moet u virtuele containers van het Docker-type overwegen bij het beoordelen van GOST-compliance? Is het correct om technologie te evalueren in overeenstemming met subsectie 7.8 van GOST?
- Hoe kunnen we virtuele containerbeheertools evalueren? Is het mogelijk om ze gelijk te stellen aan servervirtualisatiecomponenten en ze te evalueren volgens dezelfde subsectie van GOST?
- Moet ik de beveiliging van informatie in Docker-containers afzonderlijk evalueren? Zo ja, welke waarborgen moeten hiervoor worden overwogen tijdens het beoordelingsproces?
- Als containerisatie wordt gelijkgesteld aan virtuele infrastructuur en wordt beoordeeld volgens paragraaf 7.8, hoe worden de GOST-vereisten voor de implementatie van speciale informatiebeveiligingstools geïmplementeerd?
Reactie van de Centrale Bank
Hieronder vindt u de belangrijkste fragmenten.
“GOST R 57580.1-2017 stelt vereisten vast voor implementatie door de toepassing van technische maatregelen met betrekking tot de volgende maatregelen ZI subsectie 7.8 van GOST R 57580.1-2017, die naar de mening van de afdeling kunnen worden uitgebreid tot gevallen waarin containervirtualisatie wordt gebruikt technologieën, rekening houdend met het volgende:
- de implementatie van maatregelen ZSV.1 - ZSV.11 voor het organiseren van identificatie, authenticatie, autorisatie (toegangscontrole) bij het implementeren van logische toegang tot virtuele machines en virtualisatieservercomponenten kan verschillen van gevallen waarin containervirtualisatietechnologie wordt gebruikt. Hiermee rekening houdend, denken wij dat het, om een aantal maatregelen te implementeren (bijvoorbeeld ZVS.6 en ZVS.7), mogelijk is om aan te bevelen dat financiële instellingen compenserende maatregelen ontwikkelen die dezelfde doelen nastreven;
- de implementatie van maatregelen ZSV.13 - ZSV.22 voor de organisatie en controle van informatie-interactie van virtuele machines voorziet in de segmentatie van het computernetwerk van een financiële organisatie om onderscheid te maken tussen informatiseringsobjecten die virtualisatietechnologie implementeren en tot verschillende beveiligingscircuits behoren. Hiermee rekening houdend, zijn wij van mening dat het raadzaam is om te zorgen voor een passende segmentatie bij het gebruik van containervirtualisatietechnologie (zowel met betrekking tot uitvoerbare virtuele containers als met betrekking tot virtualisatiesystemen die op besturingssysteemniveau worden gebruikt);
- de implementatie van de maatregelen ZSV.26, ZSV.29 - ZSV.31 om de bescherming van afbeeldingen van virtuele machines te organiseren moet naar analogie worden uitgevoerd, ook om basis- en huidige afbeeldingen van virtuele containers te beschermen;
- de implementatie van maatregelen ZVS.32 - ZVS.43 voor het vastleggen van informatiebeveiligingsgebeurtenissen met betrekking tot toegang tot virtuele machines en servervirtualisatiecomponenten moet naar analogie worden uitgevoerd, ook met betrekking tot elementen van de virtualisatieomgeving die containervirtualisatietechnologie implementeren.”
Wat betekent het
Twee belangrijke conclusies uit de reactie van de afdeling Informatiebeveiliging van de Centrale Bank:
- maatregelen om containers te beschermen verschillen niet van maatregelen om virtuele machines te beschermen;
- Hieruit volgt dat de Centrale Bank in de context van informatiebeveiliging twee soorten virtualisatie gelijkstelt: Docker-containers en VM's.
In het antwoord wordt ook melding gemaakt van “compenserende maatregelen” die moeten worden toegepast om de bedreigingen te neutraliseren. Het is alleen onduidelijk wat deze ‘compenserende maatregelen’ zijn en hoe de adequaatheid, volledigheid en effectiviteit ervan te meten.
Wat is er mis met het standpunt van de Centrale Bank?
Als u tijdens de beoordeling (en zelfbeoordeling) de aanbevelingen van de Centrale Bank gebruikt, moet u een aantal technische en logische problemen oplossen.
- Elke uitvoerbare container vereist de installatie van informatiebeschermingssoftware (IP): antivirus, integriteitsmonitoring, werken met logs, DLP-systemen (Data Leak Prevention), enzovoort. Dit alles kan zonder problemen op een VM worden geïnstalleerd, maar in het geval van een container is het installeren van informatiebeveiliging een absurde zet. De container bevat de minimale hoeveelheid “bodykit” die nodig is om de dienst te laten functioneren. Het installeren van een SZI daarin is in tegenspraak met de betekenis ervan.
- Containerimages zouden volgens hetzelfde principe moeten worden beschermd; hoe dit te implementeren is ook onduidelijk.
- GOST vereist het beperken van de toegang tot servervirtualisatiecomponenten, dat wil zeggen tot de hypervisor. Wat wordt in het geval van Docker als een servercomponent beschouwd? Betekent dit niet dat elke container op een afzonderlijke host moet worden uitgevoerd?
- Als het voor conventionele virtualisatie mogelijk is om VM's af te bakenen op basis van beveiligingscontouren en netwerksegmenten, dan is dit in het geval van Docker-containers binnen dezelfde host niet het geval.
In de praktijk is de kans groot dat iedere auditor de veiligheid van containers op zijn eigen manier zal beoordelen, op basis van zijn eigen kennis en ervaring. Nou, of evalueer het helemaal niet, als er noch het een noch het ander is.
Voor het geval dat voegen we eraan toe dat vanaf 1 januari 2021 de minimumscore niet lager mag zijn dan 0,7.
Overigens plaatsen we regelmatig reacties en opmerkingen van toezichthouders met betrekking tot de vereisten van GOST 57580 en de regelgeving van de centrale banken in onze .
Wat te doen
Naar onze mening hebben financiële organisaties slechts twee opties om het probleem op te lossen.
1. Vermijd het implementeren van containers
Een oplossing voor degenen die bereid zijn het zich te veroorloven om alleen hardwarevirtualisatie te gebruiken en tegelijkertijd bang zijn voor lage beoordelingen volgens GOST en boetes van de Centrale Bank.
plus: het is gemakkelijker om te voldoen aan de vereisten van subsectie 7.8 van GOST.
minder: We zullen nieuwe ontwikkelingstools gebaseerd op containervirtualisatie, in het bijzonder Docker en Kubernetes, moeten laten varen.
2. Weigeren te voldoen aan de vereisten van subsectie 7.8 van GOST
Maar pas tegelijkertijd de best practices toe op het gebied van het garanderen van informatiebeveiliging bij het werken met containers. Dit is een oplossing voor degenen die waarde hechten aan nieuwe technologieën en de kansen die deze bieden. Met ‘best practices’ bedoelen we door de industrie geaccepteerde normen en standaarden voor het garanderen van de veiligheid van Docker-containers:
- beveiliging van het host-besturingssysteem, correct geconfigureerde logboekregistratie, verbod op gegevensuitwisseling tussen containers, enzovoort;
- het gebruik van de Docker Trust-functie om de integriteit van afbeeldingen te controleren en het gebruik van de ingebouwde kwetsbaarheidsscanner;
- We mogen de veiligheid van toegang op afstand en het netwerkmodel als geheel niet vergeten: aanvallen zoals ARP-spoofing en MAC-flooding zijn niet geannuleerd.
plus: geen technische beperkingen op het gebruik van containervirtualisatie.
minder: de kans is groot dat de toezichthouder zal straffen voor niet-naleving van de GOST-vereisten.
Conclusie
Onze klant heeft besloten containers niet af te staan. Tegelijkertijd moest hij de reikwijdte van het werk en de timing van de overgang naar Docker (ze duurden zes maanden) aanzienlijk heroverwegen. De opdrachtgever kent de risico’s zeer goed. Hij begrijpt ook dat tijdens de volgende beoordeling van de naleving van GOST R 57580 veel van de auditor zal afhangen.
Wat zou jij doen in deze situatie?
Bron: www.habr.com