Security en Privacy bij software ontwikkeling

Security en Privacy bij softwareontwikkeling

Tijdens de ontwerp en ontwikkelfase van applicaties moet reeds voldoende aandacht voor security en privacy zijn. Hiermee worden applicaties eenvoudiger en efficiënter compliant en minder vatbaar voor cyber criminaliteit.

Onze pragmatische en bewezen aanpak, op basis van 8 stappen, introduceert beveiligings- en privacyoverwegingen in alle fasen van het ontwikkelingsproces. Het helpt ontwikkelaars om veilige software te bouwen, te voldoen aan de vereisten voor beveiligingsnaleving en de ontwikkelingskosten te verlagen.

Onze aanpak bestaat uit richtlijnen, best practices, tools en processen die helpen om veiligere producten en services te bouwen. Deze werkwijzen worden regelmatig bijgewerkt om rekening te houden met nieuwe technologieën, zoals clouddiensten, IoT en AI en ook de ontwikkelingen in het dreigingslandschap.

De volgende 8 stappen vormen de basis van onze aanpak:

Zorg voor training van betrokken medewerkers om het bewustzijn te vergroten en bewust te maken van gedeelde verantwoordelijkheid voor veilige ontwikkeling;
Definieer scenario’s en stel zo potentiële risico’s en bedreigingen op een gestructureerde manier vast. Doe dit op basis van waarschijnlijkheid en impact van potentiele risico’s en dreigingen.
Bepaal een organisatie specifiek basisbeveiligingsniveau met bijpassende KPI’s, op basis van wettelijke, branche- en interne normen en rekening houdend met de gedefinieerde scenario’s alsmede bekende kwetsbaarheden en incidenten.
Creëer een controleerbare omgeving en proces dat voldoet aan de gestelde vereisten zodat achteraf eenvoudig een audit kan plaatsvinden om het bestaan enerzijds en de werking anderzijds van de procedures en maatregelen te toetsten.
Bescherm data adequaat middels encryptie en rolgebonden toegangsbeleid. Zorg er zodoende voor dat data te allen tijde adequaat wordt beschermd tegen onbedoelde openbaarmaking of wijziging wanneer deze wordt verzonden of opgeslagen. Voer de vereisten van de AVG in de architectuur reeds door.
Houd controle over gebruikte componenten van derden en gebruik alleen goedgekeurde tools.
Voer regelmatig een penetratietest uit. Toetst daarbij ook de eerder gedefinieerde scenario’s en stel deze indien nodig bij.
Beschik over een standaardprocedure bij incidenten (‘incident response’) gekoppeld aan een continuiteitsplan (‘business continuity planning’) en test deze regelmatig.

Zorg voor training van betrokken medewerkers

Zorgen voor veilige applicaties met voldoende waarborgen voor privacy is de verantwoordelijkheid van alle betrokkenen: ontwikkelaars, servicetechnici, programma- en projectmanagers moeten de basisprincipes van beveiliging begrijpen en toepassen. En weten hoe ze beveiliging in applicaties, software en services kunnen inbouwen om deze producten en diensten veiliger en compliant te maken en houden. En dit alles terwijl wordt tegemoetkomen aan de gestelde functionele- en technische vereisten alsmede een hoge mate van gebruikersvriendelijkheid wordt geboden. Effectieve training zal beveiligingsbeleid, -praktijken, -normen en -vereisten voor softwarebeveiliging aanvullen en versterken, en worden geleid door inzichten die zijn afgeleid van gegevens of nieuw beschikbare technische mogelijkheden. En uiteraard wordt op deze manier ook informatie gedeeld over incidenten en situaties waar het mis is gegaan, om te leren van fouten en het in de toekomst beter te doen.

Hoewel beveiliging ieders taak is, is het belangrijk dat niet iedereen een beveiligingsexpert hoeft te zijn, noch ernaar moet streven om een bekwame penetratietester/ethical hacker te worden. Door ervoor te zorgen dat iedereen het perspectief van een kwaadwillende aanvaller begrijpt wordt het bewustzijn vergroot en is beveiliging geen dode letter. Vervolgens is de samenwerking met deskundigen, zoals de experts van Sygnius, eenvoudiger omdat achterliggende noodzaak wordt begrepen en ervaren.

Definieer scenario’s

Een adequaat beveiligingsbeleid gaat uit van de aanname dat er geen 100% veiligheid en bescherming tegen cybercriminaliteit bestaat en dat er beperkingen zijn zoals de hoogte van het budget. Dit betekent dat er keuzes gemaakt moeten worden en dat er een minimaal basisbeveiligingsniveau gedefinieerd moet worden, met andere woorden, een voor de organisatie haalbaar en realistisch beveiligingsniveau. De keuzes om dit niveau te definiëren worden naar ons oordeel medebepaald aan de hand van waarschijnlijkheid (welke dreiging is waarschijnlijk en welke is dat niet) en de impact (welk gevolg heeft een dreiging wanneer deze plaatsvindt). Een potentiële dreiging met een lage waarschijnlijkheid en een lage impact behoeft logischerwijs minder aandacht dan wanneer deze wel waarschijnlijk is met bovendien een grote impact. In het laatste geval kan de continuïteit van de onderneming op het spel staan en is het belangrijk vooraf na te denken over scenario’s. De praktijk is echter minder zwart/wit over waarschijnlijkheid en impact, bovendien verandert het dreigingslandschap voortdurend, en dat vergt zorgvuldig nadenken over welke scenario’s voor de organisatie relevant(er) zijn.

Aangezien 70% van de potentiële bedreigingen van buiten de organisatie komt en 30% van binnenuit, begint het definiëren van scenario’s met het analyseren en vastleggen aan welke potentiële beveiligingsrisico’s de organisatie en applicaties kan worden blootgesteld. Vervolgens wordt per risico de impact van een dergelijke gebeurtenis en de waarschijnlijkheid ingeschat. Deze analyse wordt vervolgens besproken met alle betrokken stakeholders vanuit verschillende perspectieven en belangen.

Het werken met scenario’s stelt het ontwikkelteam in staat om technische maatregelen voor deze scenario’s te bespreken, definiëren en documenteren en de scenario’s en risicoanalyses steeds aan te vullen met technische overwegingen en eventuele bekende kwetsbaarheden en incidenten. Door deze gestructureerde aanpak toe te passen en aan de hand van risicoanalyse scenario’s te definiëren, bespreken en documenteren kan een ontwikkelteam effectiever en goedkoper beveiligingsproblemen identificeren, de risico’s van die bedreigingen bepalen en vervolgens beveiligingsfuncties selecteren en passende maatregelen treffen. Dit alles in de context van de geplande operationele omgeving, want applicaties staan niet op zichzelf maar begeven zich te midden van een bestaande technische omgeving of cloud infrastructuur. Een veilige applicatie in een onveilig netwerk leidt immers tot een ongewenste situatie: waarschijnlijke blootstelling aan een bekend risico.

In de praktijk nemen security experts van Sygnius reeds deel aan het ontwikkelteam tijdens de ontwerp en ontwikkelfase en helpen wij organisaties met de toepassing van risicomanagement van hun IT-functie. Ook denken wij mee met het ontwikkelen en kritisch evalueren van scenario’s waarmee niet zelden kosten bespaard kunnen worden en de basisbeveiliging verbeterd. Hierbij putten wij uit de ervaring van meer dan 300.000 analyses zodat wij snel kunnen vergelijken en benchmarken.

Bepaal een organisatie specifiek basisbeveiligingsniveau met bijpassende KPI’s

Uiteraard staan softwareontwikkeling en de scenario’s (stap 2) niet op zichzelf. Er zijn immers ook externe eisen en factoren waarmee rekening gehouden moet worden. Te denken valt aan wet- en regelgeving alsmede vereisten die branche specifiek zijn. Maar ook bekende dreigingen en kwetsbaarheden en lering getrokken uit eerdere incidenten. Dit alles wordt door ons vertaald naar beveiligingseisen, die een zogenaamd ‘basisbeveiligingsniveau’ vormen.

Ongeacht de gebruikte ontwikkelingsmethodologie, moeten de vereisten voor dit basisbeveiligingsniveau regelmatig worden bijgewerkt. Dit vanwege wijzigingen in wet- en regelgeving, (door-)ontwikkeling van functionaliteit van de applicaties zelf en ook veranderingen in het bedreigingslandschap. Zoals hiervoor toegelicht is het optimale moment om de beveiligingsvereisten te definiëren de eerste ontwerp- en planningsfase aan de hand van scenario’s. Door deze vroege planning kunnen ontwikkelteams beveiliging en privacy integreren op een manier die verstoring tot een minimum beperkt en zeer kosteneffectief is.

Factoren die van invloed zijn op de minimale vereisten voor basisbeveiliging zijn onder meer, maar zijn niet beperkt tot:

Gedefinieerde scenario’s (stap 2)
Wettelijke bepalingen (zoals de AVG) en branchevereisten (bijvoorbeeld WBNI)
Interne standaarden (te denken valt aan ISO, protocollen en best practices)
Beoordeling van eerdere incidenten
Bekende bedreigingen en kwetsbaarheden
Benchmarking (door vergelijking met onze >300.000 analyses)

De minimale vereisten zorgen er tevens voor dat er als het ware een grens of norm wordt bepaald waartegen beveiligingskwetsbaarheden kunnen worden afgezet wanneer deze aan het licht komen. Dit helpt ook bij het opstellen van een plan van aanpak wanneer deze kwetsbaarheden worden aangetroffen die er voor zorgen dat het basisbeveiligingsniveau niet meer wordt gehaald en dus een ‘critical’ of ‘important’ classificatie hebben.

Alle kwetsbaarheden die worden ontdekt met deze ‘critical’ of ‘important’ beoordeling moeten dan binnen een bepaald tijdsbestek worden verholpen en daaraan worden key performance indicators (KPI’s) gekoppeld. Deze KPI’s stellen de organisatie in staat de aanpak van deze kwetsbaarheden eenduidig te volgen en ervoor te zorgen dat de benodigde beveiligingstaken tijdig worden voltooid middels een gedocumenteerd proces. Deze werkwijze zorgt voor een nauwkeurige tracking en rapportage van beveiligingswerk en waarborgt het basisbeveiligingsniveau.

Creëer een controleerbare omgeving

Onze aanpak wordt door accountants en auditors gezien als aanpak die ontwikkelaars helpt om veilige software te ontwikkelen en beveiligingsfuncties gestructureerd te implementeren en documenteren. Dit aan de hand van het aantonen van de ‘opzet’, het ‘bestaan’ en daarnaast de ‘werking’. Dit betekent dat de functies aantoonbaar goed zijn ontworpen voor beveiliging, in relatie met de belangrijkste dreigingen voor de organisatie en dat dit ook adequaat gedocumenteerd is voor auditdoeleinden.

Om de voor dit doel benodigde beveiliging te bereiken, vertrouwen ontwikkelaar doorgaans op beveiligingsfuncties zoals cryptografie, authenticatie en logboekregistratie. In veel gevallen is het selecteren en implementeren van deze beveiligingsfuncties en maatregelen zo ingewikkeld gebleken dat verkeerde ontwerp- of implementatiekeuzes weer leiden tot (nieuwe) kwetsbaarheden. Wij helpen organisaties daarom bij het consistent toepassen van passende beveiligingsmaatregelen en met een consistent begrip van de bescherming die ze bieden -en welk restrisico er overblijft-, aan de hand van scenario’s met het oog op het basisbeveiligingsniveau. Niet meer dan nodig maar ook niet minder van vereist.

Bescherm data adequaat middels encryptie en rolgebonden toegangsbeleid

Data is steeds eenvoudiger toegankelijk, zowel binnen als buiten de traditionele werkomgeving. Met de opkomst van mobiele applicaties, opslag in de cloud en thuiswerken is het nog belangrijker om ervoor te zorgen dat alle data – inclusief beveiligingsgevoelige informatie en beheer- en controlegegevens – wordt beschermd tegen onbedoelde openbaarmaking of wijziging wanneer ze worden verzonden, geraadpleegd en opgeslagen. Versleuteling (encryptie) wordt doorgaans gebruikt om deze bescherming te bereiken.

Gebruik alleen goedgekeurde en erkende coderingsbibliotheken om ervoor te zorgen dat deze eenvoudig kunnen worden geïmplementeerd en indien nodig gemakkelijk kunnen worden vervangen. Het maken van een verkeerde keuze bij het gebruik van enig aspect van cryptografie kan echter catastrofaal zijn. De inrichting en implementatie van encryptie moet daarom naar ons oordeel aan experts worden overgelaten.

Toegang tot data moet (technisch) worden beperkt tot personen die daar uit hoofde van hun functie, op dat moment, toegang tot nodig hebben. Het opzetten van een rolgebonden toegangsbeleid met tijdelijke toekenning van toegangrechten is daarvoor essentieel alsmede het bewaken van de juiste toepassing en werking daarvan. En ook technische en fysieke maatregelen die zorgen dat data, wanneer deze op grond van het basisbeveiligingsbeleid verwijderd moet worden, ook daadwerkelijk aantoonbaar adequaat verwijderd wordt zijn essentieel.

Houd controle over gebruikte componenten van derden

Software en applicaties worden tegenwoordig veelal ontwikkeld met behulp van componenten van derden (zowel commercieel als open source). Bij het selecteren van welke componenten van derden u in uw applicaties wilt gebruiken, is het belangrijk om de impact te begrijpen die een (potentieel) beveiligingsprobleem in deze componenten kan hebben op de beveiliging van het grotere systeem of applicatie waarin ze zijn geïntegreerd. Het hebben van een inventarisatie van deze componenten en een plan om te reageren wanneer daarin nieuwe kwetsbaarheden worden ontdekt, is onderdeel van het basisbeveiligingsniveau. Wij raden aan om ook aanvullende maatregelen te overwegen, afhankelijk van het basisbeveiligingsniveau van uw organisatie, het type component dat wordt gebruikt en de mogelijke impact van een beveiligingsprobleem. Wij werken met een eenvoudige geautomatiseerde oplossing die eenvoudig raadpleegbaar en bij te werken is zodat u overzicht krijgt, heeft en behoudt.

Ontwikkelaars moeten er bovendien naar streven om steeds de nieuwste versies van goedgekeurde ontwikkeltools (zoals compilerversies) te gebruiken.

Voer een regelmatig een penetratietest uit.

Penetratietesten zijn een beveiligingsanalyse van code, systeem of netwerkinfrastructuur die wordt uitgevoerd door bekwame beveiligingsprofessionals (ethical hackers) die de acties van een kwaadwillende hacker simuleren. Het doel van een penetratietest is om (potentiële) kwetsbaarheden te ontdekken die het gevolg zijn van bugs in gebruikte componenten zoals Citrix, netwerkinrichting, codeerfouten, configuraties of zwakke punten bij de operationele implementatie. Penetratietests vinden doorgaans de meest uiteenlopende kwetsbaarheden en worden vaak uitgevoerd als opvolging van onze geautomatiseerde scan en biedt handmatige codebeoordelingen om een hoger niveau van analyse te bieden dan normaal mogelijk zou zijn.

Wij adviseren om periodiek opnieuw een penetratietest uit te voeren om vast te stellen dat eerder gedetecteerde aandachtspunten zijn opgelost en nieuwe dreigingen te ontdekken die zijn ontstaan of het gevolg zijn van ontwikkelingen in de te testen applicatie of omgeving zelf.

Beschik over een standaardprocedure bij incidenten en test deze regelmatig

Het opstellen van een incident response plan is cruciaal om adequaat en planmatig te kunnen reageren wanneer er zich een dreiging manifesteert.

Een incident respons plan zou minimaal het volgende moeten bevatten.

Zorg voor een duidelijke leiding/sturing en toewijzing van verantwoordelijkheden, communicatieplan en betrekken van alle relevante stakeholders.
Koppel het plan aan de ontwikkelde scenario’s en rapporteer conform de gesproken KPI’s.
Anticipeer op situaties waarin de scenario’s niet hebben voorzien.
Stel een protocol op voor opvolging van beveiligingsincidenten en bij het ontdekken van kwetsbaarheden (inclusief code die is overgenomen van anderen binnen de organisatie en voor code/componenten van derden).
Zorg voor uitwijkmogelijkheden en afspraken met leveranciers.
Zorg dat het plan is afgestemd met en onderdeel uitmaakt van het continuiteitsplan (‘business continuity planning’) van de organisatie als geheel.
Test het plan regelmatig en evalueer de uitkomsten met stakeholders (zoals bijvoorbeeld leveranciers en de betrokken verzekeraar).
Maak het plan organisatie breed bekend en beschikbaar.

Tot slot

Wij bij Sygnius zijn van mening dat door het introduceren van het minimale beveiligingsniveau en het nadenken over beveiliging en privacy in alle fasen van het ontwikkelingsproces leidt tot een effectievere en kosten efficiëntere ontwikkeling. Ontwikkelaars kunnen hiermee de kans op kwetsbaarheden in producten en diensten enorm verkleinen en kunnen voorkomen dat dezelfde beveiligingsfouten worden herhaald.

Onze aanpak is mede gebaseerd op Microsoft Security Development Lifecycle (SDL)

Neem contact op met Sygnius om te ontdekken wat wij voor elkaar kunnen betekenen.