Cybersecurity wordt in veel gevallen nog altijd gezien als een set aan beveiligingsmaatregelen die aan een bestaande IT-omgeving worden toegevoegd. Bij het Nederlands Instituut voor de Software Industrie (NISI) ziet men dat anders. Begin bij het begin, is hier het motto. Anders gezegd: kijk bij het ontwikkelen van software niet alleen naar de functionaliteit, maar betrek security in alle stappen die nodig zijn om tot de gewenste functionaliteit te komen. Daarbij kunnen we minstens negen zeer nuttige maatregelen nemen, stelt Jan Vlietland van het NISI. Deel 1 in een serie artikelen over het ontwikkelen van veilige applicaties.
Applicaties vormen natuurlijk niet de enige uitdaging als het om IT-security gaat, vertelt Jan Vlietland van het Nederlands Instituut voor de Software Industrie. “Maar het vormt wel een belangrijk aspect. Wie software ontwikkelt op basis van de principes van ‘Secure Development Life Cycle’ kan grote stappen in de goede richting zetten.”
Secure Development Life Cycle
Secure Development Life Cycle ofwel SDLC bestaat uit 4 stappen die continu doorlopen worden. Wie begint met deze aanpak, zal allereerst zijn ‘requirements’ in kaart moeten brengen. Zijn die eenmaal duidelijk, dan kunnen de zogeheten ‘secure design principes’ vastgesteld worden die hier het beste bij passen. Vervolgens kan een ‘secure design’ worden geïmplementeerd. Waarna een aantal validaties dienen te worden uitgevoerd om vast te tellen in hoeverre het secure design ook daadwerkelijk aansluit bij de eerder genoemde requirements. Zijn hierbij aanpassingen nodig, dan kan dit ook weer impact hebben op de gekozen secure design-principes. En zo doorlopen we continu deze ‘life cycle’.
Secure design principes
Hierbij is een cruciale rol weggelegd voor de zogeheten secure design principes. Dit zijn er negen, stelt Vlietland:
- Minimaliseer de mogelijkheden voor aanvallers om actief te worden (minimize attack surface area)
- Zorg voor veilige default-instellingen
- Ga uit van het idee van ‘least privilege’
- Hanteer het principe van ‘verdediging in de diepte’
- Zorg dat eventuele fouten niet tot onveilige situaties leiden
- Heb geen vertrouwen in externe services
- Zorg voor scheiding tussen taken
- Voorkom ‘security by obscurity’
- Hou security eenvoudig
Laten we deze negen stappen of maatregelen eens nader bekijken.
Minimize attack surface area
Iedere nieuwe feature die aan software wordt toegevoegd, levert weer extra risico’s op voor de applicatie. Terwijl het doel van ‘secure development’ nu juist is dat we het risico terugdringen door criminelen minder mogelijkheden voor een aanval of misbruik te bieden.
Een voorbeeld: een webapplicatie kan voorzien worden van een online help waaraan een zoekfunctie is gekoppeld. Die search-functie levert extra risico’s op in de vorm van SQL injection-aanvallen. Hoe kunnen we dit risico verminderen? Door de zoekfunctie bijvoorbeeld alleen voor geautoriseerde gebruikers beschikbaar te maken. Of door de zoekfunctie in te perken door een aantal routines toe te voegen waarmee de ingevoerde zoekdata kan worden gevalideerd. Daarmee kunnen we het risico dat een SQL injection-aanval met succes wordt uitgevoerd drastisch terugbrengen.
Veilige default-instellingen
Als uitgangspunt geldt dat default configuratie-instellingen de meest veilige instellingen vormen die mogelijk zijn. Dat is natuurlijk niet direct hetzelfde als de meest gebruiksvriendelijke instellingen. Maar ga uit van het idee dat het aan de gebruiker zelf is om zijn veiligheidsniveau eventueel te verlagen. Dit dient dan een bewuste keuze en een bewust uitgevoerde actie te zijn. Mits we een dergelijke verlaging van het security-niveau natuurlijk überhaupt willen toestaan.
Ook hier weer een voorbeeld: stel per default in dat wachtwoorden na verloop van tijd verlopen en stel bovendien eisen aan de samenstelling van het gebruikte wachtwoord. We kunnen natuurlijk overwegen dat gebruikers beide features mogen uitschakelen. Dit levert een vereenvoudiging van het gebruik op, maar tevens een verlaging van het security-niveau.
Let overigens op dat werken met ‘secure defaults’ niet hetzelfde is als het uitzetten van alle netwerkverbindingen, sockets en services en dergelijke. Omgekeerd betekent het ook niet dat met secure defaults een 100% veilige omgeving is gecreëerd.
Least privilege
Werken met minimale privileges betekent dat iedere module – een proces, een gebruiker of een programma – alleen toegang heeft tot die informatie en IT-middelen die nodig zijn voor het uitvoeren van de taak waar het om gaat. Een user account krijgt hierbij dus uitsluitend die rechten die essentieel zijn voor de beoogde functie.
Neem als voorbeeld een user account dat bedoeld is voor het maken van back-ups. Die ‘user’ behoeft dan bijvoorbeeld geen software te kunnen installeren. Er dient dus enkel sprake te zijn van rechten om back-ups te maken en back-up-software te starten.
Hetzelfde voor een eindgebruiker met een normaal user account. Beperk het aantal situaties waarin deze gebruiker privileged en met een wachtwoord beschermde superuser-rechten nodig heeft tot het absolute minimum.
Defensie in de diepte
‘Defense in depth’ is een concept waarbij de verdediging uit meerdere lagen wordt opgebouwd. Hierbij kijken we niet alleen naar de applicatie zelf, maar naar de gehele IT-omgeving. Denk hierbij aan firewalls, ‘demilitarized zones’ (DMZ), antivirus software, ‘patching’, ‘secure coding’, versleuteling van files en data, ‘intrusion detection’ en dergelijke.
Het gebruik van meerdere lagen heeft tot doel redundantie aan te brengen. Daarom is het belangrijk dat deze meerdaagse defensie tal van maatregelen omvat die variëren van personele maatregelen, procedures, technische en fysieke bescherming.
Veilig fouten maken
Stel duidelijk vast dat authenticatiemaatregelen zodanig zijn ontwikkeld dat een aanvaller niet kan inloggen. Kijk hierbij dus heel nadrukkelijk naar de ‘error handling’ bij authenticatie. Veel frameworks regelen dit weliswaar voor een developer, maar check dit altijd goed. Bijvoorbeeld door te controleren in hoeverre het mogelijk is dat een foutieve input bij authenticatie de gehele authenticatieprocedure uitschakelt? Of haal als test eens de gehele database met authenticatiegegevens offline en onderzoek wat er gebeurt als dan alsnog geprobeerd wordt in te loggen.
Vertrouw geen services
Een externe service gebruiken introduceert per definitie risico’s. Want wellicht hanteren zij andere security policies, zonder dat we hier invloed op kunnen uitoefenen. We kunnen er simpelweg niet impliciet vanuit gaan dat een externe service veilig is en vertrouwd kan worden. Maak hierbij bovendien geen onderscheid tussen soorten externe services. Maar behandel alles externe services op dezelfde manier.
Ook hier weer een voorbeeld. Een aanbieder van een royalty-programma levert data die gebruikt wordt bij internetbankieren. Deze partij levert bijvoorbeeld het aantal spaarpunten van een gebruiker aan of berekent de korting die de gebruiker hiermee krijgt. Hierbij zal deze data gecontroleerd dienen te worden voordat deze aan de gebruiker getoond wordt.
Geen security by obscurity
Security by obscurity is geen goed idee, zeker niet als dit de enige security control is. Hiermee bedoelen we dat het niet verstandig is allerlei details onzichtbaar te houden. Voorbeeld: ga niet uit van het idee dat zolang de broncode van een applicatie geheim wordt gehouden er bij aanvallers geen kennis over de werking van de software kan ontstaan. Security zal gebaseerd moeten zijn op een aantal maatregelen, variërend van deugdelijke procedures rond wachtwoorden, defensie in de diepte, beperkingen die we aan transacties stellen, een weldoordachte netwerkarchitectuur en dergelijke.
Hou security eenvoudig
De twee fenomenen ‘attack surface area’ en ‘eenvoud’ gaan hand-in-hand. Hou ook de programmacode eenvoudig en zo efficiënt mogelijk. Sommige developers schrijven zeer uitgebreide code, met alle risico’s van dien op fouten en zwakheden. Het kan daarnaast erg modern zijn om tal van ‘entity beans’ op een middleware-server te gebruiken, maar vaak is het veiliger en sneller om ‘global variables’ toe te passen met een mutex-mechanisme (‘mutual exclusive’) die bescherming biedt tegen dubbelzinnige multithreading-condities.
Continue authenticatie
Authenticatie speelt bij secure coding een hoofdrol. Steeds vaker wordt in applicaties de optie van two-factor authentication toegepast. Maar er is nog een andere optie die in het kader van dit artikel erg relevant kan zijn: ‘continuous authentication’. Hierbij wordt de identiteit continu geverifieerd. Hierbij kan gebruik worden gemaakt van biometrische input, maar bijvoorbeeld ook een smartphone of context. Denk bij dit laatste bijvoorbeeld aan GPS-data voor het vaststellen van de locatie van een gebruiker of gegevens over het tijdstip van het gebruik van de applicatie of het doen van een transactie.
Met continue authenticatie is het mogelijk de beveiliging verder te verbeteren. Wordt deze maatregel toegepast dan is het voor een aanvaller bijvoorbeeld veel lastiger geworden om een sessie over te nemen of om misbruik te maken van gestolen apparatuur. Denk aan een smartphone in het geval van two-factor authentication.
In een volgend artikel gaan we nader in op het proces van authenticatie. Maar kijken we ook naar role-based access control en encryptie.
Top-10 cybersecurity-uitdagingen
Cybersecurity heeft betrekking op tal van aspecten binnen een IT-omgeving. Dit zijn de tien belangrijkste uitdagingen waar veel organisaties voor staan:
- De organisatie beschikt niet over een (adequaat) security-programma
- Er is recent geen security-scan gedaan om de risico’s in kaart te brengen
- Er heeft met het oog op wet- en regelgeving geen evaluatie plaatsgevonden van security-issues of gebreken in security controls
- De organisatie beschikt niet over een formeel proces voor het patchen van software of er vindt geen systematische implementatie daarvan plaats
- Er is geen sprake van een zogeheten ‘insider threat’-programma
- De organisatie heeft geen contacten met of in de cybersecurity-wereld
- Er is geen sprake van een goed georganiseerd configuratiebeheer
- Er is geen sprake van een goed georganiseerd beheer rond ‘remote access’
- Er wordt geen of onvoldoende gebruik gemaakt van de beschikbare data rond cybersecurity
- Er is geen plan van aanpak beschikbaar hoe gereageerd dient te worden op een incident
Over het NISI
Het Nederlands Instituut voor de Software Industrie (NISI) is een initiatief van de Universiteit Utrecht. Het NISI ondersteunt de software-industrie met kennis, innovatie en netwerk. Het instituut verzorgt voor de software-industrie hoogwaardige postacademische opleidingen, faciliteert intervisie en praktijkbijeenkomsten, en verbindt software-universiteiten met het bedrijfsleven.
Deze bijdrage werd geschreven door Robbert Hoeffnagel, hoofdredacteur van CloudWorks en Infosecurity Magazine, en verscheen eerder op https://www.infosecuritymagazine.nl/2018/06/05/negen-maatregelen-om-applicaties-veiliger-te-maken
