Wanneer DevOps en cyberbeveiliging botsen • The Register

Gesponsorde functie Beveiligingsbugs in code lijken een beetje op realityshows en Instagram-beïnvloeders: een irritatie die we ooit wilden tolereren, maar die later is uitgegroeid tot een veel ernstiger probleem.

De National Vulnerability Database (NVD) classificeerde in 2001 minder dan 2.000 veelvoorkomende kwetsbaarheden en blootstellingen (CVE’s). Vorig jaar bereikte dat aantal voor het eerst de 20.000. Dat komt deels omdat we ze beter kunnen detecteren dan vroeger, maar het is ook te wijten aan een wildgroei aan software. Het brengt het probleem van applicatiebeveiliging naar huis. Dus hoe kunnen we de rotting stoppen en die bug-nummers naar beneden krijgen?

Madou, mede-oprichter en CTO van het bedrijf Secure Code Warrior, zegt dat de beveiliging is achtergebleven in de ruimte voor softwaretoepassingen. “In de afgelopen 10-15 jaar hebben we verbeteringen aangebracht in de beveiliging op andere gebieden, zoals netwerk en eindpunten”, zegt hij. “Applicatiebeveiliging ging niet zo snel.”

Een deel van het probleem was dat ontwikkelaars zoveel andere problemen moesten aanpakken die over het algemeen voorrang hadden. Uit het State of Developer-Driven Security-onderzoek van Secure Code Warriors in 2022 bleek dat beveiliging de laatste prioriteit was in een peiling onder ontwikkelaars, bijvoorbeeld door slechts 14% genoemd. Terwijl reguliere krantenkoppen die fouten in de code benadrukken die hebben geleid tot datalekken, betekenen dat ze het zich niet langer kunnen veroorloven om beveiliging op de lijst te zetten, is de oorsprong voor die houding tot op zekere hoogte culturele toevoegingen Madou.

Code over de muur gooien

Applicatiebeveiliging en softwareontwikkeling zijn van oudsher niet geïntegreerd. Softwareontwikkelaars zorgden voor de codering, terwijl een tweede groep applicatiebeveiligingsmensen ervoor verantwoordelijk was dat de software zich goed gedroeg. Dit betekende dat codeurs beveiliging als het probleem van iemand anders zagen.

Tot overmaat van ramp was de relatie vaak disfunctioneel. “Die twee groepen konden niet goed met elkaar overweg omdat applicatiebeveiligingsmensen op problemen wezen en de ontwikkelaars vertelden hoe slecht hun code was”, zegt hij.

De groepen werkten ook op ad hoc basis dan op een reguliere, gestructureerde manier. De softwareontwikkelingspraktijken van Waterfall verergerden dat probleem omdat de teams aan het einde van het softwareontwikkelingsproces de applicatiebeveiliging behandelden.

Een softwarescan levert misschien resultaten op, maar liet bijvoorbeeld weinig tijd over om ernaar te handelen. In plaats daarvan moesten bedrijven de kwetsbaarheden opsporen. De ergste werden zo goed mogelijk aangepakt terwijl het team probeerde software over de streep te krijgen. De rest eindigde als technische schuld voor een andere dag.

De Secure Code Warrior-enquête suggereert dat ontwikkelaars prioriteit geven aan het aflossen van die technische schuld. Het is een moeilijke lijn om te bewandelen, omdat ze de ergste beveiligingsproblemen moeten oplossen terwijl ze proberen te voldoen aan de functionaliteitsvereisten van het bedrijf.

“Ze hebben een baseline, wat betekent ‘we kunnen niet meer problemen introduceren, maar we gaan ook niet de technische schuld verminderen'”, legt Madou uit.

Deze traditionele benadering van softwareontwikkeling zet cyberbeveiliging op de laatste plaats door beide partijen in staat te stellen verantwoordelijkheid te ontlopen. Het creëerde de perfecte voedingsbodem voor softwarekwetsbaarheden, die moeilijk te patchen zijn in een watervalontwikkelingsproces.

Als een steek in de tijd negen bespaart, dan is het omgekeerde waar; als je het te laat laat, ontstaat er een duur gat. Het repareren van software helemaal aan het einde van de productiecyclus is veel duurder.

“Als een beveiligingsbug kritiek genoeg was, zou je een off-cycle release krijgen”, zegt Madou. Dat veroorzaakt meer overhead, omdat de bug zou worden teruggeschopt naar technici die hem in de eerste plaats misschien niet hebben gecreëerd. “Dus moeten ze zich dan vertrouwd maken met de code en het probleem voordat ze een oplossing vinden.”

Deze reactieve benadering van beveiliging tast ook de betrouwbaarheid van de software aan, waarschuwt Madou. “Softwarebeveiliging hangt samen met kwaliteit”, benadrukt hij. Als de een lijdt, heeft de ander dat ook. Kwaliteit was overigens een andere topprioriteit in het ontwikkelaarsonderzoek van Secure Code Warrior.

De opkomst van agile en DevOps

Agile-ontwikkeling introduceerde kortere iteraties waardoor ontwikkelaars hun release-cadans konden verhogen. Hoewel dit een goede zaak was voor ontwikkelaars, bleef de beveiliging achter. Frequentere releases vragen om snellere scans, wat app-beveiligingsteams niet gewend waren.

Deze nieuwe vereiste veranderde de manier waarop app-beveiligingsteams hun prestaties moesten meten. Metrieken veranderden, van simpelweg rapporteren hoeveel problemen beveiligingsprofessionals in de code konden vinden tot hoe snel de ontwikkelaars en het beveiligingsteam ze samen konden oplossen.

“Het betekende ook dat het applicatiebeveiligingsteam moest weten hoe ze moesten programmeren”, legt Madou uit. Recruiters moesten op zoek gaan naar mensen met een ontwikkelaarsachtergrond in plaats van bijvoorbeeld netwerkexperts te werven.

Degenen die het goed deden, konden de reparaties inline afhandelen, dichter bij de productiebron, maar het was niet gemakkelijk. “De overgang gebeurt niet van de ene op de andere dag en niet alleen door modewoorden te gebruiken”, zegt hij. “Veel mensen gebruikten de juiste terminologie, maar werden niet snel geleverd.”

De evolutie van de DevOps-cultuur veranderde de zaken opnieuw, waardoor de release-cadans nog verder werd versneld. Het had positieve en negatieve gevolgen voor de beveiliging van applicaties, legt Madou uit.

Sommige DevOps-culturen moedigden een benadering van ‘snel bewegen en dingen breken’ aan die bijvoorbeeld de softwarebeveiliging aantastte. Een veelvoorkomend refrein is dat je een functie altijd kunt testen en terugdraaien als je het niet wilt, hoewel mensen dat in werkelijkheid vaak niet doen.

“Dit betekent dat je nu ineens, door die snelle ontwikkeling en productie en dingen uitproberen, problemen in productie neemt”, zegt Madou. Dit is met name een probleem bij het gebruik van onvolgroeide pijplijnen voor continue integratie en continue implementatie (CI/CD) die onvoldoende gated beveiligingsmaatregelen hebben.

Aan de andere kant maakte DevOps ontwikkelaars theoretisch meer verantwoordelijk voor wat ze hadden geschreven, omdat ze het nu in productie moesten beheren. Het bracht de beveiliging ook nog verder naar voren in het softwareontwikkelingsproces, waarbij prioriteit werd gegeven aan de ontwerp- en vroege coderingsfasen, waardoor het platform werd gecreëerd voor een meer geïntegreerde benadering van applicatiebeveiliging.

De noodzaak om programmeurs les te geven

Maar procesveranderingen alleen zijn niet genoeg om veiligheidsbewuste ontwikkelaars te creëren, waarschuwt Madou – educatie is een belangrijke factor. Helaas onderzoeken traditionele universitaire programma’s deze discipline niet diep genoeg.

“Het aanleren van applicatiebeveiliging is een moeilijk probleem omdat elke taal en elk framework zich anders gedraagt”, legt hij uit. Dat maakt het een leerproces op de werkvloer. “Het is aan de organisaties om nieuwe medewerkers bij te scholen in de beveiligingsaspecten van de taal, het framework en de bibliotheken die ze dagelijks gebruiken om veilige software te bouwen.”

In de praktijk hebben veel bedrijven niet de tijd of het geld om les te geven in veilige softwareontwikkeling. Ze willen gewoon dat werknemers coderen en verzenden. Als er training is, is er vaak weinig certificering nodig om praktische, hands-on veilige codeerervaring te bewijzen.

Dit is waar Secure Code Warrior om de hoek komt kijken. Madou, die een PHD in applicatiebeveiliging heeft, werkte bij een beveiligingsbedrijf dat gespecialiseerd was in het vinden van beveiligingsbugs in code. “Na zeven jaar begon ik te beseffen dat het niet zo moeilijk is om problemen in code te vinden”, herinnert hij zich. Immers, zowel zwarte hoeden als witte hoeden doen het de hele tijd. “Maar als je de ontwikkelaars niet leert veilig te coderen, zullen de bugs blijven komen”, zegt hij.

Opleiding op de werkvloer

Secure Code Warriors is expliciet bedoeld om ontwikkelaars te onderwijzen over het werk en veilige codering te promoten. Het leerplatform is een onderwijssysteem met leermiddelen in 60 computertalen, van C tot COBOL. Deze hebben niet alleen betrekking op degenen die de controlestroom behandelen; het platform bevat ook declaratieve talen die worden gebruikt om bijvoorbeeld infrastructure-as-code-omgevingen op te zetten. Het brengt deze cursussen op één lijn met begeleide leertrajecten om ontwikkelaars te helpen bij het onderwijzen van specifieke kwetsbaarheidstypen.

Het leerplatform gebruikt beoordelingen om te controleren hoe goed de ontwikkelaars deze informatie verwerken en bevat een gamification-element. Ontwikkelaars kunnen codeersimulaties uitvoeren om hun vaardigheden in praktijkscenario’s te testen.

Secure Code Warrior gaat verder met gamification met toernooien waar programmeurs met elkaar kunnen concurreren om hun veilige coderingspraktijken te demonstreren. Het leaderboard kan potentiële kandidaten markeren om de applicatiebeveiligingsinspanningen aan de kant van de ontwikkelaar te sturen.

Het bedrijf biedt ook software-integratie met tools voor het opsporen van fouten, zoals GitHub’s CodeQL, waarbij tekstzoekopdrachten uit scanrapporten worden gebruikt om educatieve bronnen over de kwetsbaarheid in kwestie te vinden. Dat helpt programmeurs om de gebreken op het werk op te lossen.

Madou zegt dat volwassen bedrijven het platform vaak gebruiken om de beveiligingsproblemen af ​​te lossen die wegkwijnen als technische schulden. Hij adviseert hen om een ​​specifiek probleem te identificeren dat hun organisatie bedreigt, zoals SQL-injectiefouten die door een team van onwetende ontwikkelaars in de loop der jaren zijn ontstaan.

“We proberen erachter te komen wat het kroonjuweel in de organisatie is en wat de grootste bedreiging is”, zegt hij. “Dan willen we het programma graag uitrollen en ervoor zorgen dat iedereen wordt bijgeschoold.” Dat stelt het ontwikkelteam in staat om eerst de grootste gaten in de codebasis te repareren, waardoor de grote risico’s worden geëlimineerd. Vervolgens kan het bedrijf het proces herhalen totdat het alle dringende problemen met de applicatiebeveiliging heeft opgelost.

Organisaties moeten zich sterk maken voor het platform voordat ze het kunnen gebruiken. “Compliance is een goed uitgangspunt om iets te introduceren waar de hele organisatie op lange termijn van kan profiteren”, vult Madou aan. Het aanvinken van compliance-boxen moet echter het begin zijn van de waarde van het platform, niet het einde. Als het op de juiste manier wordt gebruikt, kan het een bedrijf helpen de verwachtingen van de regelgeving te overtreffen en de beveiliging tijdens de hele levenscyclus van softwareontwikkeling te stimuleren.

De weg naar het beveiligen van code is lang en moeilijk, en het kan zijn dat bedrijven hun ontwikkelaars mee moeten slepen op hun reis. Als het gaat om het bijbrengen van de juiste praktijken en waarden om de volgende headline-genererende datalek te voorkomen, helpt alle beetjes.

Gesponsord door Secure Code Warrior.

Leave a Reply

Your email address will not be published.