Wie is er verantwoordelijk voor de softwarebeveiliging?

Onze levens worden steeds afhankelijker van digitale technologie. Voor cybercriminelen nemen de potentiële opbrengsten daardoor exponentieel toe. Dit resulteert in een ongekend snelle ontwikkeling van innovatieve nieuwe aanvalstechnieken.

Cybercriminaliteit vertegenwoordigt niet alleen een steeds groter risico voor bedrijven en organisaties die afhankelijk zijn van informatietechnologie, maar begint nu ook de vitale infrastructuur en dienstverlening te verstoren waarvan onze maatschappij en soms zelfs onze levens afhankelijk zijn.

Als reactie hierop legt de wetgeving steeds vaker minimumeisen op het gebied van cybersecurity aan organisaties op. Dit gebeurt op basis van nieuwe richtlijnen zoals de tweede Network and Information Security (NIS2)-richtlijn, die in oktober 2024 van kracht ging. NIS2 heeft ervoor gezorgd dat cybersecurity voor organisaties in alle sectoren een hogere prioriteit werd door het opvoeren van de regelmaat van rapportage en het opleggen van hogere financiële boetes (en in sommige gevallen zelfs celstraffen).

De snelheid waarmee cyberbedreigingen in aantal en geavanceerdheid toenemen is echter niet het enige probleem. We implementeren nieuwe digitale technologieën  ook in een steeds sneller tempo, en dat vergroot de complexiteit en het aanvalsoppervlak van onze infrastructuur. Als gevolg hiervan staan CSO’s voor meer uitdagingen dan ooit, net nu er sprake is van een nijpend wereldwijd tekort aan vaardig opgeleide beveiligingsprofessionals. Ze kunnen dus alle hulp gebruiken.

Secure by Design en Secure by Default

Softwareontwikkelaars kenden traditioneel meer prioriteit toe aan functionaliteit dan aan de beveiliging. Dit heeft tot wijdverspreide kwetsbaarheden geleid. Om de kans op misbruik van deze kwetsbaarheden te verkleinen hebben wij als eindgebruikers de verantwoordelijkheid geaccepteerd voor het regelmatig installeren van beveiligingsupdates voor alle softwareoplossingen die we aanschaffen.

In veel landen begonnen organisaties die het nationale beleid inzake cybersecurity uitstippelen in te zien dat cybersecurity tot een ongelijk speelveld was uitgegroeid. Sommige fabrikanten en afnemers droegen meer verantwoordelijkheid dan anderen. Deze organisaties begonnen daarom op het belang te wijzen van het opbouwen van een landelijke cyberveerkracht met behulp van marktwerking en de tools die tot de beschikking van de overheid staan.

Dit resulteerde in de ontwikkeling van “Secure by Design”, een principe dat nader wordt uiteengezet in deze whitepaper.

Secure by Design legt geen strenge nieuwe regels op die aanvankelijk alleen praktisch toepasbaar zijn voor de allergrootste softwareleveranciers. In plaats daarvan reikt het organisaties aanbevelingen aan die zij op vrijwillige basis kunnen toepassen. Deze “hebben ten doel om een internationale discussie aan te zwengelen over topprioriteiten, investeringen en de beslissingen die nodig zijn om een toekomst te realiseren waarin technologie zowel standaard als door ontwerp veilig en veerkrachtig van aard is.”

Secure by Design berust op drie kernprincipes:

1. de verantwoordelijkheid nemen voor de beveiligingsresultaten van klanten
2. het omarmen van radicale transparantie en verantwoording
3. het inrichten van een organisatie- en managementstructuur die het mogelijk maakt om deze doelstellingen te realiseren.

Het doel is om IT-producten en -diensten af te leveren in een configuratie die ‘af fabriek’ krachtige beveiliging biedt, zodat gebruikers geen expert in het product hoeven te zijn om er veilig gebruik van te kunnen maken.

De Secure by Design-belofte

Om softwareoplossingen te kunnen ontwikkelen die inherent veilig zijn dankzij hun ontwerp moet er tijdens elke stap in de ontwikkelingscyclus van software rekening worden gehouden met de beveiliging. Voor veel fabrikanten betekent dit dat zij hun processen en organisatiestructuur ingrijpend moeten wijzigen. Dat komt omdat de huidige, vaak in afzondering opererende functies op het gebied van softwareontwikkeling, operationele processen en de beveiliging moeten worden geïntegreerd in het kader van een gemeenschappelijke DevSecOps-missie.

Een volledige overstap op Secure by Design zal voor veel organisaties een fikse meerjarige investering vereisen. Het goede nieuws is echter dat zij ruim voor de voltooiing van dit traject er de voordelen van zullen zien. Om deze reden bundelde Fortinet in 2024 zijn krachten met andere security-leveranciers en de Amerikaanse Cybersecurity & Information Security Agency (CISA) om Secure by Design praktisch toepasbaar te maken. Samen stelden zij een reeks van maatregelen op die ontwikkelaars van IT-producten en –diensten kunnen treffen om de verantwoordelijkheid voor de beveiliging terug te verleggen van de gebruiker naar de fabrikant.

Leveranciers kunnen de Secure by Design Pledge ondertekenen om blijk te geven van hun streven om veilige software af te leveren. Potentiële klanten kunnen hen op die manier makkelijk onderscheiden van leveranciers die deze toezegging niet hebben gedaan.

Leveranciers die deze belofte ondertekenen, zeggen daarmee toe dat zij op vrijwillige basis zullen werken aan het boeken van jaarlijkse vooruitgang met betrekking tot elk van de volgende zeven maatregelen:

1. Het opvoeren van het gebruik van multi-factor authentication (MFA) in hun producten
2. Het uitfaseren van het gebruik van standaardwachtwoorden
3. Het elimineren van veel voorkomende categorieën kwetsbaarheden die kunnen worden misbruikt voor aanvalstechnieken zoals SQL-injectie en cross-site scripting
4. Het vereenvoudigen of automatiseren van de toepassing van beveiligingsupdates
5. Het opstellen en publiceren van beleid inzake de bekendmaking van kwetsbaarheden dat externe partijen aanmoedigt om kwetsbaarheden in de software op te sporen en aan te kaarten
6. Het opvoeren van de transparantie door een snellere en volledigere bekendmaking van kwetsbaarheden
7. Het toevoegen van logging-functionaliteit die bewijs van indringingspogingen kan aanleveren ten behoeve van snellere detectie en incidentrespons.

Sommige van deze maatregelen, zoals het elimineren van een complete categorie van kwetsbaarheden zoals SQL-injectie kunnen vragen om een overstap op een veiliger programmeertaal of een programmeerkader dat eindgebruikers mogelijk geen direct zichtbare verbeteringen biedt. Daarmee bestaat de kans dat sommige leveranciers pas bereid zijn om de benodigde investeringen te doen zodra hun klanten van hen eisen dat zij de belofte ondertekenen of hen op zijn minst vragen waarom zij dat niet hebben gedaan.

Het opvoeren van de transparantie is evenmin van problemen gespeend. Een snellere en volledigere bekendmaking van kwetsbaarheden zal resulteren in een groter aantal gerapporteerde kwetsbaarheden en patches. Potentiële kopers moeten dan wel begrijpen dat deze hoge aantallen een teken zijn van de vooruitgang die de leverancier met Secure by Design heeft geboekt in plaats van minder veilige producten.

De realiteit is dat alle programmatuur fouten bevat. En het is beter dat deze kwetsbaarheden door de fabrikant worden ontdekt dan dat ze door cybercriminelen worden misbruikt.

Hoe nu verder

Waterdichte beveiliging is wellicht nooit haalbaar. Moderne applicaties bestaan vaak uit ettelijke miljoenen regels code, en het is onmogelijk om software volledig te testen op een schier oneindig aantal aanvalsscenario’s. Secure by Design kan dan ook nooit een perfecte oplossing zijn. Maar naarmate klanten oog krijgen voor het feit dat sommige leveranciers bereid zijn om hun beste beentje voor te zetten en meer verantwoordelijkheid voor de beveiliging op zich nemen zal de sector zich langzaam maar zeker in de juiste richting gaan bewegen.

Softwaregebruikers zullen best practices voor cybersecurity zoals verdediging in de diepte moeten blijven toepassen. Maar naarmate er meer vooruitgang met Secure by Design wordt geboekt zullen we allemaal een stuk veiliger zijn.

Content in licentie gegeven door NITECH.