ShareValue | DevSecOps: Security begint bij Development

DevSecOps: Security begint bij Development

De afgelopen jaren zijn bedrijven druk bezig geweest met het implementeren van Agile en Scrum. Nu veel bedrijven daar al stappen in hebben gezet, is het tijd voor de volgende ontwikkeling in de werkwijze bij softwareontwikkeling; DevOps.

devopsZoals de naam al zegt, werken bij DevOps de Developers samen met de collega’s van Operations. Deze samenwerking zorgt voor continuïteit in het proces: ontwikkelen zonder overhead. Veel bedrijven zijn bezig met deze stap, maar uit recent onderzoek is gebleken dat slechts zo’n 7% van de bestaande DevOps teams daadwerkelijk op het gewenste niveau samenwerken. Denk hierbij aan ‘on demand’ kunnen deployen, serverproblemen binnen een uur kunnen herstellen en het hebben van een ‘failure rate’ van hooguit 15%. Hier is dus nog een verbeterslag te maken.

Hoe veilig is je software?

Zelfs als de samenwerking tussen Developers en Operations goed loopt en je binnen bovenstaande 7% valt, dan is de wereld nog niet perfect: je mist nóg een belangrijk onderdeel: security. 

Het Security-team is namelijk niet betrokken bij het DevOps proces. De toevoegingen waar zij nog mee komen moeten vaak last-minute (vlak voor livegang) worden verwerkt, waardoor het moment van livegang verschuift. In het ergste geval gaat het hier om een grote aanpassing binnen de software.

Er zijn veel dingen die ervoor kunnen zorgen dat de veiligheid van je applicatie in de problemen komt. Je hebt niet alles zelf in de hand; ook externe factoren spelen een grote rol hierin. Denk bijvoorbeeld aan Open Source componenten die je als Developer veelvuldig gebruikt. Het gebruik van deze componenten kan oplopen tot zo’n 80% van de volledige software. Deze externe componenten (dus niet door eigen Developers ontwikkeld) kunnen zomaar gevoelig zijn voor hackers. Een goed voorbeeld was de hack op Ticketmaster in 2018. Kwaadwillenden konden informatie van klanten achterhalen door misbruik te maken van een beveiligingsfout in een extern component.


“Fundamentally, if somebody wants to get in, they’re getting in. Accept that.

Number one, you’re in the fight, whether you thought you were or not.

Number two, you almost certainly are penetrated.

We need to shift from prevent to assume breach.”

General Michael Hayden – Former CIA & NSA Director

 

Onbewust

Het grootste probleem van dit alles is dat men zich eigenlijk niet bewust is van het hele onderwerp van software beveiliging. Wat we niet kennen is er niet, of het overkomt ons niet. Als het gebeurt, handelen wij daar reactief naar. Onderstaande toont aan dat het “probleem” er wel degelijk is, en hoe sneller wij ons hiervan bewust worden, hoe sneller wij hiernaar kunnen gaan handelen.

  • Hooguit 20% van de code die naar productie gaat, is eigen code.
  • 1 van de 16 Open Source componenten die gedownload worden heeft een kwetsbaarheid die bekend is (CVE: Common Vulnerabilities and Exposures).
  • 31% van de bedrijven is gehackt of vermoedt dat het gehackt is door een kwetsbaarheid in een Open Source component.
  • 97% van alle succesvolle exploits leiden terug naar 10 bekende kwetsbaarheden.
  • 8 daarvan zijn al lang geleden gepatcht.
  • Weet jij welke package naar productie gaat? Welke versie dit is? En of deze kwetsbaarheden bevat?
  • Op het moment dat je een nieuw project start op basis van Open Source componenten, bevat dit meteen beveiligingsproblemen. Bijvoorbeeld bij een Angular/.NET Core project, bestaat deze meteen uit 20 security vulnerabilities en 123 outdated packages, waar je normaal gesproken geen weet van hebt. 

Tijd voor een nieuwe mindset. Tijd voor DevSecOps.

devsecopsOm de veiligheid van je software, en daarmee de kwaliteit en continuïteit, te waarborgen is het van belang om het Security-team direct te betrekken bij het ontwikkelproces. Zo kan veel al worden afgestemd bij het bepalen van de architectuur van de applicatie. Preventief werken in plaats van reactief. Deze werkwijze staat ook bekend als Shift-Left-Security. Een simpele term voor een nieuwe uitdaging: security nauwer bij het ontwikkelproces betrekken betekent (nog) meer samenwerking tussen verschillende teams. Door eerder en intensiever samen te werken, voorkom je dat men een mogelijk beveiligingsrisico doorschuift tot aan de release, of dat men niet genoeg tijd of focus heeft om dit tijdig te verhelpen.

Er zijn voordelen aan het Shift-Left-proces: zo leert development en operations meer over potentiële risico’s en hoe deze te voorkomen. Ook leren zij hoe en waarom bepaalde maatregelen genomen moeten worden.

De eerste stap in dit proces is om ontwikkelaars bekend te maken met security: zij moeten begrijpen dat het Security-team geen groep boemensen is die veranderingen tegenhouden, maar dat ze daar zitten met een reden. De rol van het Security-team is het bewaken van de veiligheid van de applicatie en het wijdere IT-landschap. Men moet begrijpen dat je elkaar kan helpen risico’s vooraf in kaart te brengen en deze te tackelen. Veiligheid begint dus bij de Developer. Wanneer een Developer zich van begin af aan meer bewust is van de security, en het effect op zijn werkzaamheden daarvan, houdt hij er van begin af aan ook meer rekening mee. Zo hoeft hij niet later weer terug te gaan naar zijn eerdere werk om daarin security-gerelateerde aanpassingen te doen. Dit is fijn voor zowel de continuïteit van het werk en de focus van de Developer. Daar wordt iedereen blij van.

Risico’s zijn er in alle formaten. Van phishing mails, social engineering en rondslingerende USB-sticks tot aan ‘gratis’ extra (geïnfecteerde) servers bij een bestelling geleverd krijgen of het per ongeluk online zetten van van Secret Access Keys (zie afbeelding hieronder).

screenshot incl blur

Ook vanuit kostenperspectief, voornamelijk vanwege de tijd die het kost, is dit een mooie stap in de goede richting. De kosten van het oplossen van bugs en security issues nemen exponentieel toe naarmate de applicatie verder in het ontwikkelproces is, tot aan productie. Uiteindelijk verandert het in Technical Debt, dat uiteindelijk een tijdbom wordt: wachtend tot het fout gaat.

Hoe verder je de moeilijke taken vooruitschuift, hoe complexer en dus duurder het wordt om deze aan het eind op te lossen. Houd daarom de ontwikkelcyclus kort zodat de aanpassingen kleiner zijn, risico’s beperkt blijven en eventuele reparaties eenvoudiger toe te passen zijn.

Nog enkele voorbeelden van hoe goed iets mis kan gaan

Zoals hierboven beschreven, kan het goed mis gaan wanneer je jezelf afhankelijk maakt van Open Source-componenten. Een voorbeeld van zo’n afhankelijkheid was “left-pad”. Een JavaScript component waar weer duizenden andere componenten van afhankelijk waren.

Na een discussie met een ander bedrijf besloot de eigenaar om zijn component te verwijderen uit NPM. Resultaat: duizenden mislukte builds en deployments.

Een ander voorbeeld was Heartbleed. Dit was een bug in de meest gebruikte implementatie van het SSL-protocol. Een bug waar men nog steeds last van heeft. 

Maar; het gevaar stopt niet bij Open Source. Ook duurbetaalde softwarepakketten zoals Telerik kunnen fouten bevatten. Hier word je wel van op de hoogte gehouden, daar betaal je ten slotte ook voor. Je moet echter wel zelf je softwarepakket updaten, dat gaat niet automatisch. En als je dat niet doet, heb je toch weer een risico.

Automatisering & Tooling

Developers zijn meester in het automatiseren. Juist de development pipeline is interessant om zo ver mogelijk te automatiseren. Naast het bouwen en het testen van de applicatie is dit de perfecte plek om security-tests in te bouwen. Een mooi voorbeeld van een stuk tooling is WhiteSource: een softwarepakket wat alle Open Source componenten in kaart brengt en rapporteert welke componenten fouten bevatten, verouderd zijn of dubieuze licenties bevatten.

whitesource

 

Ook Microsoft komt met extra tooling voor Azure DevOps, het “Microsoft Code Analysis Extension”-pakket bevat interessante tooling zoals Credential Scanner. Zeker de moeite waard om naar te kijken.

Security in de pipeline

Enkele punten voor het (her)inrichten van het ontwikkelproces om security in jouw pipeline mee te nemen:

  • Continuous Integration / Continuous Deployment
  • 4 ogen principe tijdens elke fase (bijv. development, build, release)
  • Automatisch testen
  • Statische code analyse
  • Scan voor Credentials, Connection Strings en API Keys, etc.
  • Scan Open Source componenten
  • Breng licenties in kaart
  • (Azure) Key Vault 
  • Monitoring / Insights
  • Sla de build artifacts op een veilige locatie op
  • Externe (Open Source) code kan risico’s bevatten (bijv. kwetsbaarheid, licenties)
  • “Assume Breach instead of Prevent Breach”
  • Vertrouwen, aansprakelijkheid, transparantie en Communicatie met teams onderling en overstijgend
  • Slechte code eindigt in Technical Debt
  • Bedenk een goede branching strategy
  • Maak gebruik van “Pull Requests” in combinatie met code reviews
  • Release software snel, en vaak

 

security across the pipeline

 

Zoals je ziet is security vandaag de dag een essentieel onderdeel van het algemene ontwikkelproces en zou elke organisatie van DevOps naar DevSecOps moeten overstappen. Mijn ShareValue-collega's en ik weten hoe waardevol zo’n team is en vinden het dan ook heel leuk om daaraan mee te werken.

Wil je hiermee aan de slag en kan je wel een Developer in je team gebruiken die hier ervaring mee heeft? Neem contact met ons op om vrijblijvend de mogelijkheden te bespreken.

 

19-11-2019 | Alex

Vond je dit een interessant bericht? Deel het!

© ShareValue 2019