Zakelijke eisen en klantverwachtingen zorgen ervoor dat applicatieontwikkeling een continue cyclus is geworden anno nu. Applicaties veilig bouwen vanaf het ontwerp en hun beveiliging in de loop van de tijd behouden, betekent werken met dezelfde continue en cyclische aanpak die we hanteren voor softwareontwikkeling onder de naam DevOps. In dit artikel onderzoeken we hoe organisaties ervoor kunnen zorgen dat hun applicaties bestand zijn tegen cyberdreigingen.
De verschuiving naar links is niet eenmalig
Snelle en iteratieve softwareontwikkelingscycli betekenen frequente wijzigingen in applicatiecode. Het oude model van "beveiliging naar links verschuiven" zou nog steeds van toepassing zijn als applicatieontwikkeling een lineaire tijdlijn was - ontwerpen, bouwen, testen, uitvoeren. Maar onder de noemer Continuous Integration (CI) en Continuous Delivery (CD) als pijplijn heeft deze de tijdlijn veranderd in een continue cyclus waarin ontwikkelaars opnieuw ontwerpen, herbouwen, testen en opnieuw implementeren, met elke opeenvolgende coderelease.
Deze cyclus versnelt ook nog eens: 57% van de ontwikkelaars meldt dat ze hun code twee keer zo snel wordt vrijgeven in vergelijking met voorheen, terwijl 19% zegt dat het tien keer zo snel gaat.
Maar verandering brengt risico's met zich mee. De nieuwste versie van een applicatie kan nieuwe code vrijgeven met ongeteste (beveiligings)kwetsbaarheden die cyberaanvallers kunnen misbruiken. En dat met een gemiddelde tijd die een organisatie nodig heeft om een kwetsbaarheid in een webapplicatie te patchen van 49 dagen. Dit resulteert in een window of opportunity voor aanvallers om die kwetsbare applicatie te misbruiken en deze te gebruiken als opstapje in een (on)georganiseerde cyberaanval.
Het ontwikkelen van veilige applicaties is daarom een doorlopend proces dat bestaat uit het opsporen van kwetsbaarheden en het continu oplossen ervan. Het is geen eenmalige actie, maar vereist dat ontwikkelaars hun applicaties continu testen en verbeteren om kwetsbaarheden bij elke opeenvolgende coderelease te elimineren.
Om dit succesvol te doen, hebben we drie belangrijke pijlers geïdentificeerd voor een betere applicatiebeveiliging:
- Voer tijdens de ontwerpfase oefeningen in het modelleren van bedreigingen uit om de risico's te beperken waarmee applicaties hoogstwaarschijnlijk te maken krijgen
- Train ontwikkelaars om kwetsbaarheden te herkennen, veiligere code te schrijven en DevSecOps-processen te implementeren
- Test applicaties continu om kwetsbaarheden te detecteren en te verhelpen voordat of wanneer deze zich voordoen in elke opeenvolgende coderelease
Deze lijst is niet uitputtend, maar het is het meest effectieve startpunt voor betere applicatiebeveiliging omdat het potentiële kwetsbaarheden gedurende de complete levensduur van de applicatie aanpakt. Met dat in gedachten, laten we eens kijken naar elke oplossing en waar ze in de levenscyclus van applicatieontwikkeling zouden moeten komen.
Threat modelling: het probleem voor zijn
Threat modelling is een oefening die is ontworpen om kwetsbaarheden in applicaties te schetsen. Het doel van de oefening is om de aanvalstypen te voorspellen die een cyber crimineel waarschijnlijk zal uitvoeren om beschermende maatregelen voor uw applicatie te omzeilen. Meestal houdt dit in dat eerst de beveiligingsvereisten voor de applicatie worden gedefinieerd en vervolgens een applicatiediagram wordt gemaakt dat helpt bij het visualiseren van systeemcomponenten, gegevensstromen en beveiligingsgrenzen. De volgende stap is het identificeren van potentiële kwetsbaarheden die aanvallers kunnen misbruiken, voordat uiteindelijk beveiligingsoplossingen voor dergelijke bedreigingen worden gevonden.
Ontwikkelaars trainen om fouten te herkennen en veilige code te schrijven
Applicaties veilig maken vanuit het ontwerp betekent dat beveiliging verweven is met elke feature en functie. De risico's van het niet doen hiervan zijn duidelijk zichtbaar in het veranderende gedrag van aanvallers: afgelopen jaar betrof 25% van de inbreuken aanvallen op webapplicaties. In de meeste gevallen is een aanval op een webapplicatie slechts één stap in een grotere aanvalsketen.
Ontwikkelaars vinden het uitpluizen, verwerken en oplossen van kwetsbaarheden in code die al is vrijgegeven een tijdrovende strijd. Wanneer ze laat in de levenscyclus van de applicatie worden gevonden, betekent het herschrijven van de fundamenten vaak het herschrijven van ALLE code die erop is gebouwd.
DevSecOps maakt beveiliging een standaard en noodzakelijk onderdeel van het softwareontwikkelingsproces. Codebeoordelingen kunnen worden geautomatiseerd met een verscheidenheid aan open-source scripts en tools om kwetsbaarheden te ontdekken. Het implementeren van een DevSecOps-methodologie bevordert de samenwerking tussen ontwikkelaars en beveiligingsteams, zodat ontwikkelaars snel kwetsbaarheden in hun code kunnen identificeren en patchen. Als dit goed wordt gedaan, resulteert dit in veiligere applicaties, zonder vertragingen in de ontwikkeling te veroorzaken.
Ontwikkelaars kunnen zichzelf ook opleiden om te denken als een aanvaller om code te schrijven die per definitie veilig is. Bronnen zoals de OWASP Top 10 geven een lijst van de meest voorkomende kwetsbaarheden in webapplicaties die aanvallers waarschijnlijk als doelwit zullen nemen. Door te begrijpen hoe aanvallers deze kwetsbaarheden identificeren en uitbuiten, kunnen ontwikkelaars applicatiecode schrijven die tot in de basis veilig is.
Hoewel beveiliging een steeds groter deel van hun dagelijkse taken wordt, worden ontwikkelaars niet getraind om kwetsbaarheden te herkennen en veilige code te schrijven als standaard, waardoor ze gedwongen worden om gespecialiseerde trainingen te volgen. Degenen die dat wel doen, worden bevoegd met best practices, tools en technieken voor veilige applicatieontwikkeling en spelen een belangrijke rol bij het verminderen van het risico van een cyberaanval voor hun organisatie.
Test continu om te zorgen dat deze aansluit op uw ontwikkelpijplijn
Het gebruik van pentesten om kwetsbaarheden in applicaties te ontdekken is effectief, maar het gebeurt vaak laat in de softwareontwikkelingscyclus, wanneer fouten in de code moeilijk en tijdrovend zijn om te repareren. Er zijn twee problemen met het vertrouwen op pentesten voor applicaties:
- Pentesten geven slechts een momentopname van kwetsbaarheden op een bepaald moment; zodra nieuwe code wordt geïmplementeerd, zijn de resultaten van een pentest verouderd. Ze kunnen geldig blijven als dezelfde kwetsbaarheden niet zijn opgelost, maar zijn onvolledig als er sindsdien nieuwe kwetsbaarheden boven water komen.
- Bovendien zijn pentesten vanwege de kosten lastig op te schalen naar grote applicatie-omgevingen en te duur om ze regelmatig te herhalen bij elke nieuwe udate of release.
Claranet Continuous Security Testing biedt een nieuwe oplossing voor dit probleem. Het combineert geautomatiseerde scantools die 24x7 draaien met gerichte handmatige pentesten, zodat u kwetsbaarheden kunt opsporen en oplossen zodra ze zich voordoen. Eerst worden alle bevindingen geverifieerd en geëvalueerd. Vervolgens voeren deskundige pentesters verdere handmatige tests uit om complexe kwetsbaarheden te ontdekken die geautomatiseerde scanners niet kunnen detecteren.
Continuous Security Testing biedt snelle, maar gedetailleerde feedback aan ontwikkelaars en beveiligingsteams over kwetsbaarheden in applicaties, webgerichte assets, API's en externe infrastructuur. Als Continuous Security Testing wordt gebruikt om uw pre-productie- of stagingomgeving te testen, stelt het ontwikkelaars en beveiligingsteams in staat om kwetsbaarheden te detecteren en te verhelpen voordat de code de productieomgeving bereikt, zelfs met een snelle CI/CD-pijplijn. Door een "weinig en vaak"-benadering te gebruiken, wordt het werk van kwetsbaarheidsbeheer en het beveiligen van applicaties een hapklaar geheel.
Als onderdeel van Continuous Security Testing biedt Claranet gratis hertesten van de applicaties die binnen het bereik vallen, om ervoor te zorgen dat de herstelmaatregelen van ontwikkelaars succesvol zijn geweest.
Organisaties gebruiken Continuous Security Testing om:
- Kwetsbaarheden sneller te detecteren, zodat ze deze eerder kunnen verhelpen
- Het venster van mogelijkheden voor aanvallers verkorten
- De werklast van hun team voor het beveiligen van applicaties te verminderen door een kleine en frequente aanpak te hanteren
- Hun inspanningen prioriteren, zodat ze de grootste risico's als eerste kunnen verhelpen
Een consistente aanpak
Naarmate meer ontwikkelaars beveiliging in hun codering opnemen, zal het beveiligen van applicaties uiteindelijk een tweede natuur worden, in plaats van een bijzaak. Voorlopig blijft de behoefte aan gespecialiseerde trainingscursussen bestaan. We hopen dat de ontwikkelaarswereld als geheel de cruciale rol in het handhaven van de beveiliging van organisaties zal erkennen en uit zal dragen, en dat meer ontwikkelaars hun vaardigheden zullen diversifiëren om "secure by design" de minimaal acceptabele standaard te maken, in plaats van de gouden standaard.
Op teamniveau is het aandringen op een continue en iteratieve aanpak voor het beveiligen van applicaties (ongeacht of je het DevSecOps of iets anders noemt) van het grootste belang; we moeten beveiliging in de moderne levenscyclus opnemen. Door fouten in elke coderelease uit te banne, kunnen organisaties de beveiliging van hun applicaties (en andere webgerichte activa) behouden en een populaire en snelgroeiende aanvalsroute voor dreigingsactoren afsluiten.
Neem contact met ons op voor meer informatie over hoe ontwikkelaarstraining, threat modelling en Continuous Security Testing de beveiliging van uw webapplicaties kunnen verbeteren.