In de meeste bedrijven vertrouwt het bedrijf op interne softwareontwikkelingsteams om hun behoeften te vertalen in een betrouwbaar en veilig product dat hen concurrentievoordeel kan opleveren. De meest recente cyberbeveiligingsrapporten suggereren echter nog steeds dat software meestal onveilig is, met meer dan 80% van alle software met grote en kritieke kwetsbaarheden, ondanks een toenemend risicobewustzijn.
Waarom is dit? Omdat applicatiebeveiliging vaak wordt toegevoegd in plaats van ingebouwd. Laten we eens kijken naar de typische manieren waarop een producteigenaar, een ontwikkelteam en een CISO tijdens een project met elkaar omgaan en zien hoe frustrerend dat kan zijn…
De producteigenaar
Als producteigenaar vertrouwt u op ontwikkelaars om uw bedrijf een concurrentievoordeel te geven. Je schrijft verhalen en verwacht van ontwikkelaars dat ze code en algoritmes schrijven om systemen te verbinden en waarde te produceren voor je klanten. In deze fase zijn al je inspanningen gericht op het beschrijven van wat je product gaat doen. Helaas zijn er daarbuiten al een aantal slechteriken die wachten tot jouw innovatieve oplossing wordt uitgebracht. Ze hopen dat ze met een aantal kwetsbaarheden gegevens kunnen stelen die ze op de zwarte markt kunnen verkopen.
De ontwikkelaars
Op basis van alle informatie van je producteigenaar zijn ontwikkelaars begonnen met het schrijven van code. Ze hebben complexe problemen opgelost en zijn met een innovatieve oplossing gekomen. Het is hard teamwork geweest en ze zijn trots op het eindresultaat. Hun product heeft een mooie interface en werkt als een zonnetje. Het is helemaal klaar voor productie. Nu is alleen nog een veiligheidsgoedkeuring nodig.
De CISO
Dit is meestal het moment waarop je als CISO hoort van het bestaan van dit nieuwe spannende project. Het is nu jouw verantwoordelijkheid om het bedrijf te beschermen tegen de inherente risico’s van innovatie. Je beste optie is om een penetratietest aan te vragen, die uiteindelijk een aantal grote en kritieke kwetsbaarheden zal vinden, zoals gebruikelijk onder dergelijke omstandigheden. De software moet worden hersteld: het is een No Go voor beveiliging.
Gevolgen
Vanuit het perspectief van de Product Owner is het veel te duur. Budgetten zijn beperkt, waardoor herstel zelden volledig is. Het is uiteindelijk een afweging tussen risico’s en kosten. Dit verklaart mogelijk waarom meer dan 80% van alle software nog steeds risico loopt.
In dit stadium is voor de CISO de enige manier om het risico voor het bedrijf te verminderen het toevoegen van steeds meer compenserende controles.
Een andere kijk op applicatiebeveiliging
Maar hier is het goede nieuws: bedrijven zijn niet gedoemd om riskante software te maken. Door een aantal geautomatiseerde beveiligingstests voor applicaties in te voeren in hun SDLC (software development lifecycle) kunnen ze veiligere software produceren tegen lagere kosten, omdat herstel minder duur is als het in de ontwikkelingsfase wordt aangepakt.
Het zal niet alleen de afzonderlijke visies van het bedrijfsleven, veiligheid en ontwikkeling met elkaar in overeenstemming brengen, maar het zal ook een positieve revolutie ontketenen waarbij veiligheid ieders zorg is omdat het wordt bereikt door samenwerking in plaats van door dwang.
Als u meer wilt weten over hoe wij uw uitdagingen kunnen ondersteunen met onze Secure SDLC-methode, nodigen wij u uit op onze conferentie tijdens Infosecurity Belgium 2020 “Ontwikkelaars: uw eerste verdedigingslinie tegen cyberbedreigingen”.
Over de auteur:
Met een achtergrond als ontwikkelaar heeft Eric Lefèbvre meer dan 20 jaar gewerkt met webontwikkelingsteams. Voordat hij bij Approach kwam als Als Lead Consultant Secure Delivery leidde hij met succes het internationale programma voor beveiligingskampioenen bij Thomas Cook.
