insight Of het nu gaat om kleine of grote systemen, ik vind het fijn om veilige software te bouwen. Ik weet, dat ik daarin niet alleen ben. Sterker nog, ik durf wel te stellen dat iedereen veilige software wil maken. Hoewel ik dat al best een tijdje doe (software bouwen in het algemeen bedoel ik dan), vind ik het ook nog steeds lastig in een paar zinnen te beschrijven wat dat dan is… veilige software. Als het al zou lukken, dan is zo’n beschrijving ook weer niet eeuwig houdbaar. Zeker in de IT geldt: wat vandaag als definitie wordt aangenomen, kan morgen weer achterhaald zijn. Wat dat betreft had de oude Griek Heraclitus wel gelijk: ‘verandering is de enige constante’. Voor mij is dat misschien ook waarom software bouwen zo interessant blijft.
Het hangt ervan af
Dus een beschrijving of definitie geven van veilige software is ingewikkeld, maar is het ook lastig om te ‘doen’? Het antwoord is, net als zo vaak in de IT: ‘dat hangt ervan af’. Als je veilige software ziet als iets dat je éénmalig ontwerpt en realiseert, ja dan is het heel lastig. Als je daarentegen veilige software ziet als een bewegend doelwit en je processen zijn zo ingericht dat daar rekening mee gehouden wordt… en je steeds leert en verbetert… dan valt het wel mee. Begin met de basis, het fundament. Benut wat je nu weet van de omgeving, het gebruik en de gestelde eisen. Haal vervolgens tijdens het bouwen van de software steeds zoveel mogelijk informatie op (denk aan risico modellen, privacy eisen, informatiebeleid, etc.). Bouw door op wat je hebt: software beveiligen gebeurt door maatregelen in ‘laagjes’ op elkaar te stapelen.rnrnHet sleutelwoord in de vorige paragraaf is wat mij betreft: ‘steeds’. Dit is dus niet iets wat je één keer moet doen, maar wat je regelmatig terug laat komen. Ik voeg dus graag (en met regelmaat) op basis van nieuwe ideeën en inzichten zaken toe, waarbij ik functionaliteit en beheersbaarheid natuurlijk niet uit het oog verlies. In dit artikel wil ik enkele van die ideeën benoemen, vooral de wat recentere. Sommige zijn in mijn eigen teams ontstaan terwijl andere weer uit de vakliteratuur komen.
“Veiligheid is een onderdeel van elke fase in het leven van een product of dienst. Van ontwerp tot realisatie, elke iteratie weer.“
Vroeger
Vroeger was het leven simpeler, het IT leven dan. Ik denk nog even terug aan de tijd dat software veiligheid nog gelijkstond aan het installeren van firewalls (‘we maken een DMZ!’) en het laten uitvoeren van een penetratietest door een extern bureau. We zagen in die tijd software veiligheid als een zogeheten ‘Gate’. Kwam je daar doorheen, dan was je software veilig. De vergelijking ligt voor de hand, dus ik maak hem maar: de ‘Security Check’ op de luchthaven. Dit was oorspronkelijk alleen een ticket controle op de runway, net voor het instappen. Tegenwoordig is dat het gelaagde model, dat we allemaal wel kennen. Verschillende checks en validaties zorgen ‘in laagjes’ voor de veiligheid van toestellen, luchthaven en passagiers. En we zien nog maar een klein deel, want achter de schermen vindt geautomatiseerd nog een veelvoud van controles plaats.rnrnDit is misschien wel de grootste verandering die we op dit thema in de jaren hebben moeten maken. Daar waar we vroeger gewend waren software achteraf te toetsen en te beveiligen, is het nu een onderdeel van elke fase in het leven van een product of dienst. Van ontwerp tot realisatie, elke iteratie weer.
De laagjes
Laagjes dus. Voor we hier naar gaan kijken wil ik het nog hebben over het doel van dit alles. Natuurlijk willen we veilige software, maar omdat de echte definitie lastig te geven is neem ik een uitgangspunt.
Niets mis mee wat mij betreft, maar dit geeft wel aanleiding om het te hebben over het volgende. Om te kunnen werken aan veilige software heb je mensen nodig die zich doordrongen zijn van deze risico’s. Ik bedoel hier niet per se ‘van de hoed en de rand’, maar wel het besef dat elke wijziging of feature nieuwe kwetsbaarheden kan introduceren. Ik heb het ook niet alleen over ontwikkelaars, want het gaat hier duidelijk om alle betrokkenen. Dus ook een Product Owner of een Business Process Owner. We noemen dit ook wel de security cultuur of veiligheidsklimaat. Er moet in een organisatie voldoende ruimte, aandacht en budget zijn om continu te werken aan veilige software.
Mob Testing
Je kunt de Evil User Stories behandelen als normale User Stories en ze door teamleden laten oppakken. Er zijn echter ook andere methoden om hier mee aan de slag te gaan, bijvoorbeeld met iets als ‘Mob Testing’. Deze methode gaat als volgt: het hele team werkt aan dezelfde Evil User Story, op dezelfde locatie, samenwerkend achter één computer. Eén teamlid zit achter het toetsenbord (de ‘Driver’), één teamlid geeft de aanwijzingen (dat is de ‘Navigator’) en de rest (de menigte, oftewel de ‘mob’) kijkt mee en stelt vragen of maakt opmerkingen. Dit is een variant op Mob Programming, maar bij testen werkt het ook.
Afhankelijkheden
De software die ik en mijn teams maak is al lang niet meer helemaal van ons. Ze bestaan voor een deel uit frameworks, tools, packages, dependencies, plugins…. Deze componenten zijn in de meeste gevallen Open Source projecten van derden en vallen daarmee buiten scope van Code Reviews en dergelijke. Wanneer er dus kwetsbaarheden optreden in dat deel van de software, lopen we het risico hier te laat -of geheel niet- achter te komen.rnrnEen passende oplossing kan zijn om de gebruikte componenten te analyseren en tegen een openbare database van geregistreerde kwetsbaarheden aan te houden. Hiermee kun je op verschillende momenten in de software lifecycle bepalen of er een verhoogd risico is. Ik noem hier als voorbeeld Dependency Track van OWASP. Dit is een tool, die op basis van de ‘Bill of Material’ bepaalt welke componenten gebruikt worden en gebruikt de National Vulnerability Database om deze te scannen.
CI/CD, SDLC
De software development lifecycle (de SDLC) is een belangrijk mechanisme als het om veiligheid gaat. Het is het proces wat bij het maken en uitbreiden van software steeds doorlopen wordt. Daarmee is het ook het proces waarin al onze inspanningen (ook als het gaat om security) terug te vinden zijn. Neem bijvoorbeeld een Continuous Integration u0026amp; Continuous Deployment pipeline. De plek waar wijzigingen van ontwikkelaars worden samengevoegd en (na de juiste checks) worden uitgerold op een omgeving. In dit CI/CD proces is feedback ongelooflijk belangrijk! Het vertelt of de code qua syntax correct is (‘it builds!’), maar ook dat vitale onderdelen nog steeds werken zoals bedoeld is (de ‘unit tests’ slagen!) èn dat de wijzigingen van individuele ontwikkelaars elkaar niet in de weg zitten.rnrnIk stelde al eerder, dat er bij het ontwikkelen van software altijd risico’s ontstaan. Niet al deze risico’s zijn vooraf in te schatten en we moeten desondanks snel kunnen reageren met maatregelen. De SDLC moet dus ook ‘voorzien in het onvoorziene’. Ik denk daarom vooral aan automatische validaties, maar ook aan het ‘in place’ hebben van draaiboek voor het geval er iets misgaat ondanks alle maatregelen.rnu003culu003ern tu003cliu003eDependency Management: vergelijk gebruikte afhankelijkheden (dependencies) met een openbare database met kwetsbaarheden;u003c/liu003ern tu003cliu003eStatic Application Security Testing: feedback op basis van statische code analyse, bijvoorbeeld met een tools als SonarQube of SonarCloud;u003c/liu003ern tu003cliu003eDynamic Application Security Testing: feedback op basis van gesimuleerde aanvallen op software. Kijk maar eens naar een tool als OWASP ZAP;u003c/liu003ern tu003cliu003eContinuous Testing en Continuous Feedback: testen, valideren en ophalen van feedback in elke fase van het ontwikkel- en voortbrengingsproces;u003c/liu003ern tu003cliu003eEmergency Patch Management: zorg voor een doordacht en beproefd proces als het gaat om het snel uit kunnen brengen van reparaties aan de software.u003c/liu003ernu003c/ulu003e