Zet Security as Code in om DevSecOps uitdagingen het hoofd te bieden

Security as Code is een stuwende kracht voor de evolutie van applicatiebeveiliging. Het gaat hand in hand met moderne software ontwikkeling en de opkomst van Infrastructure as Code (IaC). Ook helpt Security as Code innovatieve organisaties om de grootste security uitdagingen van deze tijd beter het hoofd te bieden.

De DevOps-methodologie heeft met succes silo's tussen Dev en Ops doorbroken en de cloud heeft ertoe bijgedragen om developers sneller zelfstandig te kunnen laten starten met coderen. Ook kan de infrastructuur die nodig is om de code in de cloud onder te brengen, eenvoudig worden geconfigureerd. Maar in deze fase van configuratie liggen fouten en security-kwetsbaarheden op de loer. Om handmatige stappen te elimineren en de consistentie en veiligheid van software te verbeteren, worden deze configuraties in code neergeschreven, ook wel bekend als Infrastructuur as code (IaC).

IaC maakt schaalbaarheid, snelheid, consistentie, zichtbaarheid en traceerbaarheid van wijzigingen in elke configuratie mogelijk. De uitdaging is dat er nogal wat verschillende factoren zijn waar de DevOps teams en security teams van de organisatie rekening mee moeten houden. Met configuratie instellingen die zijn ingebouwd in de verschillende cloud services, containers, orchestrators, en software build en deployment tools, is het vaak moeilijk voor development en security teams om zeker te zijn van de juiste configuratie.

Door te automatiseren kunnen diverse policies centraal worden geconfigureerd en consistent worden toegepast op alle projecten. Deze innovatie maakt een eind aan de afhankelijkheid van individuele besluitvorming (en de daarmee gepaard gaande kans op fouten), maar het gevaar ontstaat dat er ook een gecentraliseerd doelwit voor kwaadwillenden wordt gecreëerd.

Configuratie kan geautomatiseerd en repetitief zijn gebaseerd zijn op standaarden, maar het kan ook een warboel zijn van eenmalige acties die worden opgezet zonder dat de impact van de keuzes volledig wordt overzien. Hoe dan ook, security is belangrijk voor de hardware, de applicaties, en de infrastructuur waarvan de applicaties afhankelijk zijn, terwijl ze worden ontwikkeld, ingezet en gebruikt. IaC moet daarom met dezelfde nauwgezetheid behandeld worden als de code van de applicatie. Het sleutelwoord hiervoor is automatisering waarmee ook de snelheid waarmee de software gebruiksklaar kan gemaakt worden (time-to-use) versneld kan worden.

Omdat de stap om de IaC naar productie te brengen geautomatiseerd is, zal het van nature per direct gebruikt worden. Vanaf dan kunnen teams zowel de infrastructuur als code in één stap naar de productie brengen. Maar als de code niet veilig is, kunnen kwetsbaarheden samen met deze code worden uitgerold, bijvoorbeeld wanneer er weinig tijd is om de integriteit van de configuratie te testen. Daarom is automatisering van security verificatie noodzakelijk, evenals de noodzaak om ze in te bouwen in zowel het ontwikkel- als het implementatieproces van software, in plaats van steeds afzonderlijke security checks uit te laten voeren door aparte security teams. Uiteindelijk leidt IaC dus tot Security-as-code.

IaC: software security opnieuw uitgevonden

De SolarWinds Orion aanval heeft managers, security professionals en ontwikkelaars wereldwijd aan het denken gezet over security van hun software deployment platformen. De attack benadrukte het falen van de beveiliging van het SDLC-proces. Hackers implementeerden kwaadaardige code in de Solarwinds Orion IT-monitoring- en management software die wereldwijd door duizenden bedrijven en overheidsinstellingen wordt gebruikt.

Dit resulteerde erin dat SolarWinds zonder het te weten software-updates naar zijn klanten stuurde die kwaadwillende code bevatte. De code, die tijdens het bouwproces van de Orion-app werd geïnjecteerd, creëerde in feite een achterdeur naar de IT-systemen van SolarWinds-klanten en verschafte toegang voor malafide doeleinden. Europa staat voor vergelijkbare en toenemende uitdagingen, wat onder meer regelmatig aangetoond wordt door onderzoek van het European Agency for Cybersecurity (ENISA).

De schadelijkste attacks zijn meestal het gevolg van interne onachtzaamheid op het gebied van security hygiëne zoals onafgemaakte patches of wachtwoorden die niet regelmatig vervangen worden. Volgens berichtgeving in de media over Solarwinds vertrouwde de Solarwinds administrator op een eenvoudig wachtwoord dat ongewijzigd bleef. Door geautomatiseerde processen in te voeren kan dit voorkomen worden. Deze kunnen ervoor zorgen ervoor dat wachtwoorden regelmatig worden gewijzigd, terwijl de detectie van gevoelige data grondig kan zoeken naar wachtwoorden of geheime sleutels die in code staan. Terwijl het geweten is dat dit geen goed idee is, komt dit toch vaak voor bij API's die verschillende applicaties met elkaar verbinden.

Stapsgewijs naar security governance en testing

Gelukkig zijn er een aantal belangrijke stappen die organisaties kunnen nemen om de security te verbeteren in het DevOps proces. Tegelijkertijd zal deze automatisering ervoor zorgen dat de time-to-delivery van software sneller verloopt.

De processen en de policies moeten voor elke stap uitgedacht en in detail vastgelegd worden. Bij het bepalen van de policies zijn de volgende vragen belangrijk: In welke mate wordt broncode getest? Gebeurt dat voor elke applicatie? Wat zijn de uitzonderingen? Wie kan uitzonderingen goedkeuren? Worden containers getest? Wanneer? Door wie? Wie heeft toegang tot het deployment process & de bijbehorende software deployment platformen en wat mogen zij aanpassen en veranderen?

Het helpt om de inspanningen en de resourcing voor software security op te splitsen in drie pijlers:

1. Zorg voor veilige code − Test code om kwetsbaarheden te identificeren en weg te nemen. Leg policies vast voor scans en de scope van de applicatie portfolio. Idealiter zouden er meerdere soorten scans moeten worden uitgevoerd, bij de committen van de code en bij het mergen naar de main branch. Overweeg tools die al deze scanners ingebouwd hebben om het beheer van een complexe tool chain integratie te elimineren. Bepaal vervolgens policies voor vereiste acties in het geval van geïdentificeerde kwetsbaarheden.

2. Beveilig de omringende infrastructuur van app’s - test op misconfiguraties en monitor op onverwachte veranderingen. Overweeg:

• a) Containers – wat bevatten ze (libraries en dependencies)
• b) Orchestrators (zoals Kubernetes) – geconfigureerd om te bepalen hoe, waar en wanneer containers draaien, welke apps met welke andere apps mogen communiceren, en welke compute- en storage resources elke app mag gebruiken
• c) Cloud services – de omgeving die virtual machines en containers host
• d) IaC (coded configuraties) zoals API’s, packages, Helm charts, Terraform, etc. Omdat monolithic apps steeds meer opgedeeld worden in microservices, krijgen authenticatie en autorisatie een geheel nieuwe dimensie – en is er een groter gebruik van API's. Deze moeten getest worden en idealiter moeten alle API-oproepen vastgelegd, opgeslagen en bekeken worden t.b.v. audits.

3. Beveilig de software deployment platformen – Beveilig de software deployment platformen tegen aanvallen. De CI pipeline is in wezen de software assemblagelijn, dus het beheren van de toegang daartoe, zowel door mensen, machines en API's, is van fundamenteel belang.

Een geautomatiseerde CI/CD-pipeline heeft als voordeel dat er consequent aanvullende gemeenschappelijke controles voor compliance worden toegepast, zoals scheiding van taken, goedkeuring van samenvoegingen, en meer. Deze mogelijkheden zullen op hun beurt ook interne security audits vereenvoudigen.

Security as Code kan DevSecOps versnellen

Moderne software applicaties vereisen security toepassingen, die zelfs verder gaan dan alleen 'shift left'. Naarmate development cycli versnellen, wordt security as code van het grootste belang. Dit brengt voordelen met zich mee die niet mogelijk zijn met traditionele, op silo’s gebaseerde methodes; voordelen zoals snelheid, inzicht in risico's en controle. Security-as-code strategieën stellen organisaties in staat om zich nu al voor te bereiden op de evolutie van applicatie security, door de security van het begin tot het eind in de software deployment platformen op te nemen.