Een bijkomend voordeel van het werken met geautomatiseerde beheerprocessen in de cloud is het verlagen van de kans dat kwaadaardige software voor lange tijd in een cloud-omgeving aanwezig is. Het automatiseren van cloudbeheerprocessen leidt tot efficiëntie en snelheid, maar ook tot een verlaging van beveiligingsrisico's. Dit draagt bij aan de businesscase voor het verder automatiseren van cloudbeheerprocessen.
Wat opvalt bij de evaluatie van ransomware-aanvallen is dat kwaadaardige software vaak al langer op systemen aanwezig is, ver voordat deze daadwerkelijk in actie komt en data gaat versleutelen. Dit kan bijvoorbeeld als er misbruik wordt gemaakt van zero-day-kwetsbaarheden. Moderne ransomware weet zich goed te verbergen op systemen waardoor detectie niet gegarandeerd is. Natuurlijk kan goede detectie-software helpen bij het opsporen van dit soort situaties, maar er komt ook hulp uit onverwachte hoek, namelijk door de inzet van ‘wegwerp-servers’.
Image
De software die binnen ons bedrijf ontwikkeld wordt, draait binnen Docker-containers. De Docker-containers vormen een gecontroleerde omgeving waarbinnen de software draait. Een Docker-container wordt gemaakt op basis van een Docker-‘image’. We passen ‘hardening’ toe bij het tot stand brengen van de containers. Dat betekent dat alleen de ondersteunende (systeem) software wordt geïnstalleerd die ook echt door onze software wordt gebruikt. Alle overbodige software wordt niet geïnstalleerd.
Een Docker-container-image is nadat deze eenmalig is gebouwd niet te muteren (immutable). Bij elke herstart is de software weer terug in de staat zoals hij oorspronkelijk is ontworpen en daarmee ook ontdaan van eventuele ransomware. De container-images worden tevens continue gescand op kwetsbaarheden voordat ze worden uitgerold in de cloud.
De installatie van Docker-containers in de cloud (op virtuele servers) doen we met behulp van Kubernetes. Kubernetes zorgt voor een geautomatiseerde uitrol van de containers (Kubernetes-pod’s) op virtuele servers waarbij de continuïteit van de dienstverlening is gewaarborgd. Kubernetes bewaakt de belasting van de van de virtuele servers en schaalt automatisch bij of af. We kunnen hierdoor de Docker-containers vervangen zonder grote serviceonderbreking.
Infrastructure-as-code
Naast de software in Docker-containers (toepassingen) wordt ook de infrastructuur (servers, Kubernetes cluster, storage, networking) door middel van code gedefinieerd en volledig automatisch uitgerold. Onze cloud-engineers programmeren dit in scripts. De code die zij daarvoor schrijven wordt net als die van onze softwareontwikkelaars ondergebracht in Git-repositories. Dit staat ook wel bekend onder de naam infrastructure-as-code (iac).
Als onderdeel van de beheerprocedures rond onze cloud-omgeving worden infrastructuur inclusief toepassingen met een hoge frequentie compleet vervangen. De oude omgeving wordt verwijderd. Dit zorgt ervoor dat er weer een volledig gecontroleerde en bekende omgeving staat, waar alleen software op draait die wij erop gezet hebben (clean install).
Nooit lang aanwezig
Door bovenstaande werkwijze zijn de software en de virtuele servers nooit lang aanwezig in de cloud. Mocht er kwaadaardige software zonder ons medeweten geïnstalleerd zijn, dan wordt deze verwijderd op het moment dat de hele omgeving inclusief virtuele servers wordt vervangen. De kans dat zich kwaadaardige software binnen onze omgeving bevindt is daarmee niet weg, maar de kans dat deze zich lang op onze omgeving bevindt is wel een stuk kleiner geworden.
Kijk aan, een nieuwe Don Quichot die in elke server een draak ziet terwijl ransomware zich niet richt op de server maar op de data waardoor de immutable container leuk maar nutteloos is als je geen back-up hebt. Zero-day-kwetsbaarheden zijn tenslotte gaten in de verdediging die bekend zijn bij de aanvaller maar niet bij de verdediger waardoor er nog geen patch voor is. Neem aan dat de auteur geen garanties geeft over de code zelf waardoor ik benieuwd ben wat er nu eigenlijk opgelost wordt. Statistisch gezien is de kans op verstoringen in de service keten namelijk groter door de korte lifecycles van code welke zonder integraal testen in productie worden genomen. Wederom wijs ik daarom op de ‘immutable’ back-up welke vaak als een roll-back gebruikt wordt doordat cowboys testen in de productieketen.
@Een outlid:
Ik ben het met je eens in de zin dat de auteur van het artikel een wel heel simplistisch beeld heeft van veiligheid.
Ik moet echter ook zeggen dat ik het met de auteur eens ben dat je door het gebruik maken van Docker containers en Kubernetes, in combinatie met een (ik neem aan: Flatcar) Docker host het aantal aanvalsvectoren op het systeem enorm doet afnemen.
Natuurlijk is veel afhankelijk van de afhankelijkheden waarmee het systeem is opgebouwd (bijv. welke versie van Log4J wordt er gebruikt – *als voorbeeld, er zijn zoveel meer foutieve versies van andere ondersteunende applicaties*). En je hebt gelijk: als je een zeef bouwt waar een emmer bedoeld was moet je niet verbaasd zijn als de vloer nat wordt; een SQL injectie wordt niet voorkomen door een Docker container of Kubernetes omgeving.
Maar je moet toegeven dat het laten afnemen van aanvalsvectoren door iets wat relatief lage invloed heeft op de functionaliteit van de applicatie een goede aanpak is.
Overigens is het artikel inhoudelijk erg mager, ik had van een expert op het gebied van Cloud computing en Security meer verwacht.
Ransomeware richt zich eerst op de server, om daarna bij de data te kunnen.
de auteur pleit net als oulid voor iac, maar dat zal hem tegen zijn toorn niet redden 😉
zelf werk ik ook alleen nog maar met iac en zoveel mogelijk met containers en het bijzondere daarvan vond ik dat ik daardoor juist beter beeld krijg welk deel reproduceerbare programma’s zijn en welk deel onvervangbare data die backed-up moet worden.
lange lifecycles omdat bij korte toch niet integraal getest wordt, dat klinkt een beetje als laten we alles bij het oude laten.
want vroeger was alles..
Ter verduidelijking het volgende: Dit artikel gaat over de periode dat kwaadaardige software als achtergrondproces draait in het geheugen van een (virtuele) server, en nog niet is overgegaan tot het versleutelen van data. Deze periode kan best lang zijn (weken/maanden).
Vaak maakt de software onderdeel uit van een bot net, en is er ergens op internet een master die het versleutelingsproces triggert. Omdat de verdediger in het geval van een Zero-day-kwetsbaarheid de handtekening van de kwaadaardige software niet makkelijk herkent, is detectie door de verdediger niet gegarandeerd. Er draait in dat geval op de server een niet gedetecteerd kwaadaardig achtergrondproces. Het vervangen van de desbetreffende virtuele server inclusief alle achtergrondprocessen door een clean install, verwijdert ook alle onbekende kwaadaardige achtergrondprocessen. Dit werkt alleen als de clean install zelf niet geïnfecteerd is. Daarom is hardening en het van de grond af gecontroleerd opbouwen van een clean install belangrijk. Het klopt dat een back up voor een immutable container belangrijk is. Die maken we dan ook als onderdeel van dit proces.
Over het integraal testen in de verschillende fasen van onze CI/CD-straat schrijf ik in de toekomst mogelijk nog een blog. Onze software wordt inderdaad niet zonder integraal testen in gebruik genomen. Ook hanteren we diverse quality gates die voorkomen dat software die niet aan onze eisen voldoet uitgerold wordt. Het aantal verstoringen in onze serviceketen is zeer sterk gedaald door het uitgebreid (grotendeels geautomatiseerd) testen van de software voordat de frequente kleine wijzigingen worden doorgevoerd. Roll-backs komen steeds minder vaak voor, vaker wordt er gekozen voor een Roll-forward.
Jan Willem,
Dank voor je reactie maar kwaadaardige software lijkt me een diffuus begrip als kwaadwillende gebruik kunnen maken van kwetsbaarheden die onopzettelijk in de code zijn gekomen maar nog niet als zwakheid gezien worden. Of wel bekend zijn maar gewoon niet opgelost worden om allerlei redenen want ik kan een lange lijst voorbeelden geven maar ik denk dat je wel begrijpt wat ik bedoel als we kijken naar je opmerking over de achtergrond processen. Ik wacht je volgende bijdrage af maar het Trustworty Computing (TwC) initiatief van Microsoft bleek op wat pragmatische problemen te stuiten en één daarvan waren verwachtingen welke door alle marketing gewekt werd:
https://www.microsoft.com/security/blog/2022/01/21/celebrating-20-years-of-trustworthy-computing/
Ter leering ende vermaeck wijs ik je met bovenstaande link op de geleerde lessen want hoewel er niks mooiers is dan managed services moet je snel handelen als een kwetsbaarheid algemeen bekend wordt en voorzien is van een makkelijk te gebruiken exploitatie. Maar bovenal leert ervaring dat er olifantenpaadjes om de ‘quality gates’ heen lopen, integraal testen zegt niks als je niet integraal de SERVICE keten beheerd. Oja, ik ben het eens met de hardening van het platform maar hoeveel functionaliteiten zijn afhankelijk van zwakheden?