Containers: hoe zit het met de security?

Containers zijn ‘cool’: 26 procent van de bedrijven zetten containers al in als onderdeel van hun IT-strategie. 451 Research verwacht dat het aantal bedrijven dat investeert in containers zal groeien met 40 procent per jaar, tot een totale investering van 2,7 miljard dollar wereldwijd in 2020. Containers helpen software- en operationele teams sneller en efficiënter nieuwe business-applicaties te ontwikkelen en te implementeren. Ook vereenvoudigen ze het DevOps-model door het bouwen, testen en draaien van applicaties gemakkelijker te maken. Maar als bedrijven containers in plaats van traditionele IT willen inzetten, vergt dat flinke aanpassingen.

Gecontaineriseerde applicaties versnellen het tempo van softwareontwikkeling, waardoor het mogelijk is containers zonder tussenkomst van operationele- en securityteams te bouwen en in te zetten. Dat kan betekenen dat ze niet grondig gecheckt zijn op securityfouten en kwetsbaarheden. Ook gaat een update of verandering doorvoeren bij containers heel anders dan bij applicaties die op fysieke-, virtuele- of cloudinstances draaien. Genoeg reden dus voor CISO’s en securityteams om te kijken hoe ze security kunnen verankeren in de processen, voor de daadwerkelijke implementatie van containers.

Containersecurity moet flexibel en geautomatiseerd zijn zodat het niet het ontwikkelproces belemmert. Maar het moet tegelijkertijd wel de juiste richtlijnen volgen om te zorgen dat veiligheid en compliance gewaarborgd zijn.

Het containersecurity-model

Voor de meeste mensen in de IT-wereld is het OSI-model wel bekend. Helaas past de security van containers niet helemaal binnen dit model omdat het - net als een ui - uit verschillende lagen bestaat. Deze lagen moeten teams allemaal in overweging nemen. Elke laag heeft namelijk zijn eigen problemen en risico’s die voor securityuitdagingen kunnen zorgen. Het is belangrijk dat securityteams deze problemen en risico’s constant in hun achterhoofd houden bij het inzetten van containers en orkestratietools.

Het eerste potentiële probleem is de aanwezigheid van niet-gevalideerde externe software binnen container­images. Dit omvat alle software­componenten die zijn gedownload van onbetrouwbare bronnen en toegevoegd aan containerimages. Dit vormt een uitdaging voor beveiligingsteams bij het effectief beoordelen en beheren van de image-integriteit van containers die niet door het bedrijf zijn gecontroleerd en beheerd.

Daarnaast kan er sprake zijn van niet-gestandaardiseerde configuraties en inzet van containers. Dit betekent dat er binnen de containerimages elementen worden opgenomen die er niet horen, wat IT-omgevingen een hoger risico geeft op cyberaanvallen en mogelijk het verlies van gevoelige informatie, vooral omdat deze elementen niet worden bijgewerkt of hersteld.

Een derde probleem kan zich voordoen op het gebied van container-to-container-communicatie - ook wel bekend als East-West-verkeer - via openstaande poorten. Securityteams doen er goed aan om deze communicatie te monitoren. Dit omdat het de normale op host gebaseerde monitoringopties omzeilt en het detecteren van specifieke aanvalsmanieren, zoals lateral movement, verhindert.

Verder kan het tijdelijke karakter van containers voor securityteams een probleem vormen. Containers zijn namelijk bedoeld om snel te ontstaan en dan weer te verdwijnen zodat ze aan de flexibele behoeften van klanten­omgevingen kunnen voldoen. Dat betekent dat containersecurity dynamischer dan ooit moet zijn, wat kan leiden tot beperkte governance en ongeautoriseerde toegang.

En als laatste gaat het updaten van containers anders dan bij standaard IT-beheerprocessen, of deze assets nu fysiek, virtueel of cloudgebaseerd zijn. In plaats van een patch door te voeren binnen specifieke software of besturings­systemen bij te werken, heeft elke containerimage een aantal eigen componenten. Dat maakt het update­proces op zich niet moelijker, maar vereist wel een alternatieve aanpak. Om al het containerverkeer veilig te maken, moeten securityteams dus vier dingen kunnen:

• Op de eerste plaats moet discovery en het volgen van containeromgevingen mogelijk zijn. Aangezien containers constant ontstaan en weer verdwijnen, is het essentieel om bij te houden hoeveel containerimages er zijn.
• Ten tweede moeten securityteams kunnen voorzien in effectief vulnera­bility-management, compliance-procedures en container-native Intrusion Detection & Prevention. Traditionele tools gaan niet samen met de inzet van containers. Het is dus zaak dat securityteams vanaf het begin agents inbouwen in de basis-containerimages.
• Ook moeten bedrijven voor een optimale samenwerking tussen security- en DevOps-teams adaptieve security-frameworks hebben die het team kan integreren met de DevOps-procedures en die kunnen werken als onderdeel van Continuous Integration en Continuous Deployment. In de praktijk betekent dit dat beveiliging moet worden geïntegreerd in iedere Jenkins- of Circle CI-instance. Hiermee is het mogelijk het gehele proces te beheren in plaats het als een afzonderlijke service uit te voeren.
• Tot slot is het ook belangrijk dat organisaties hun operationele monitoring en incidentresponse-strategieën updaten. Softwareteams moeten ook nadenken over hun release-strategie, zodat security­processen eerder worden meegenomen.

Al met al hebben containers veel potentie. Steeds meer organisaties onderzoeken deze nieuwe manier om op grote schaal applicaties in te zetten. Bij het implementeren van containers moet security echter geen bijzaak zijn. Bedrijven halen alleen het meeste uit deze nieuwe aanpak, als ze weten hoe ze containers veilig beheren.

Marco Rottigni is Chief Technical Security Officer EMEA bij Qualys