Secure Software Development

Update 13 – Inzicht –herfst 2011
Beveiliging kan in alle fases van het software-engineering traject ingebouwd worden. Niet alleen biedt het een goed vangnet voor beveiligingsfouten, het geeft de bouwers ook meer controle en feedback over de beveiliging. In sommige gevallen wordt het bouwen zelfs leuker.

Als programmeur ben ik een creatief persoon, dat wil zeggen, het maken van dingen geeft mij plezier. Het liefst krijg ik mijn programma’s zo snel mogelijk werkend, zodat ze doen wat ze moeten doen en ik verder kan gaan met het volgende programma. Voordat ik bij Madison Gurkha kwam werken was ik heel gelukkig met deze leefwijze. In de loop der jaren ben ik een illusie armer en een stuk minder optimistisch. Ik herken mijn vroegere naïeve optimisme in veel applicaties die wij onderzoeken en voel me haast schuldig als ik in een rapport de ontwikkelaars moet teleurstellen. Ik kan me helemaal voorstellen dat het denken aan wat er allemaal mis kan gaan, de aandacht afleidt van het ontwikkelen zelf. En dat is vrij logisch: van slecht nieuws kunnen we behoorlijk moedeloos worden en geen zin meer hebben in het bouwen. De makkelijkste manier om hiermee om te gaan is dan ook om het slechte nieuws te negeren (dat komt later wel).

Wij merken dat een verse blik en een kritische ‘hackermindset’ van grote waarde zijn

Om deze neiging tegen te gaan is het belangrijk dat we het veilig ontwikkelen van software op één of andere manier in het software-ontwikkelproces inbouwen, zodat we een aantal vangnetten hebben die ons eraan herinneren waarom beveiliging belangrijk is. Madison Gurkha raakt vaak pas betrokken bij een ontwikkeltraject als er een beveiligingsonderzoek moet worden gedaan. Soms is dit aan het begin van een traject, bij het bekijken van een ontwerp, maar meestal wordt onze hulp ingeroepen als een applicatie zo goed
als af is. Tussen die twee momenten bestaan echter nog veel meer gelegenheden om aandacht te besteden aan de beveiliging van software.

secure software developmentIn het bouwen van software zijn, onafhankelijk van de ontwikkelmethodologie die wordt gebruikt, een aantal fases te onderscheiden:
1. Verzamelen van requirements;
2. Maken van een ontwerp of architectuur;
3. Bedenken van tests;
4. Implementeren van de software;
5. Uitvoeren van tests;
6. Onderhoud (verwerken van feedback).

In ieder van deze fases is het mogelijk om beveiliging te integreren.

1. Verzamelen van requirements
Tijdens het verzamelen van requirements kunnen ook security requirements worden vastgelegd. Dit gebeurt op basis van een risico-analyse. We zien in de praktijk vaak dat deze requirements niet erg specifiek zijn. De technische kennis van beveiligingsrisico’s ontbreekt vaak bij de bedenkers van de requirements. Het gevolg is onduidelijkheid voor de softwarebouwers, waardoor belangrijke aspecten over het hoofd worden gezien. Een ander probleem van security requirements is dat deze alleen maar in de ontkennende vorm kunnen worden geformuleerd, we noemen dit anti-requirements. Een voorbeeld is ‘ongeautoriseerde objecten zijn niet zichtbaar voor de gebruiker’. Met een dergelijke requirement dient in de hele applicatie rekening te worden gehouden. Een manier om de security requirements vast te leggen is door het schrijven van use cases die specifiek op misbruik van de software zijn gericht, de zogenaamde abuse cases. Wij merken hierbij altijd dat een verse blik en een kritische ‘hacker-mindset’ hier van grote waarde zijn.

2. Maken van een ontwerp of architectuur
Op basis van de risico-analyse en de use cases kan een specifiekere risico-analyse worden gedaan tijdens de ontwerpfase. Door te kijken naar de datastromen in de applicatie kan worden besloten op
welke punten beveiligingscontroles moeten worden geïmplementeerd. Een plaatje kan hierbij helpen, zoals een Data Flow Diagram (zie afbeelding). Bij ingewikkeldere systemen gebruiken wij zelf ook een DFD om aanvalsscenario’s te bedenken als we een applicatie onderzoeken. Het maken van zo’n analyse in de beginfase van de ontwikkeling kan al veel beveiligingsproblemen voorkomen, omdat het de ontwerpers dwingt te kijken naar de beveiliging.

3. Bedenken van tests
Met de abuse cases kunnen vervolgens tests worden gedefinieerd, die specifieke scenario’s testen. Hier is het belangrijk de dekking van de tests zo groot mogelijk te krijgen, vooral bij de scenario’s die anti-requirements testen.

4. Implementeren van de software
De fase van de implementatie is uitermate belangrijk. De code is immers de plaats waarin alle beveiligingseisen tot uitdrukking komen. Een coding standard gericht op beveiliging en een corresponderende code review kunnen al veel implementatiefouten detecteren. Uiteraard moet binnen het ontwikkelteam enige kennis aanwezig zijn van secure programming, al is het maar in de vorm van een enkele expert.

5. Uitvoeren van tests
Testen die gericht zijn op beveiliging zijn wel bekend voor de klanten van Madison Gurkha. Zelfs als de eerder genoemde praktijken worden uitgevoerd, blijkt een onafhankelijk onderzoek door experts nuttig te zijn. De reden hiervoor is simpelweg dat softwarebouwers (het zijn immers ook maar mensen) zaken over het hoofd zien. Maar een extern beveiligingsonderzoek is niet de enige soort test. Geautomatiseerde fuzzing tests, waarbij de applicatie willekeurige invoer te verwerken krijgt, blijken verrassend vaak beveiligingsproblemen bloot te leggen.

6. Onderhoud (verwerken van feedback)
Software-onderhoud bestaat uit het aanpassen van de applicatie op basis van ervaringen uit de praktijk. Beveiligingservaringen kunnen hier natuurlijk in worden meegenomen. Als blijkt dat bijvoorbeeld veel wachtwoorden makkelijk te raden zijn, kan gekozen worden voor een andere authenticatiemethode.

Het is niet voor niks dat secure software development de laatste jaren steeds meer aandacht krijgt van beveiligingsexperts. Zo zien we meer boeken over dit onderwerp, wordt er actief gewerkt aan de OWASP Development Guide en brengt ook Microsoft hun Security Development Lifecycle onder de aandacht. Toch is deze aandacht nog onvoldoende. Vaak worden wij relatief laat in het proces betrokken en is er binnen projecten onvoldoende technisch inhoudelijke IT security-kennis voorhanden om IT security in het proces verankeren. 

We hebben dan ook besloten de bestaande Secure Programming training breder aan te bieden. Naast de in-company variant, biedt Madison Gurkha vanaf heden in samenwerking met AT computing een klassikale versie. Met de kennis die wordt opgedaan in deze training kunnen veel organisaties in de praktijk brengen wat ik in dit artikel beschrijf. Wellicht kunnen we daar eens van gedachten wisselen over dit onderwerp?

@Secura 2018
Webdesign Studio HB / webdevelopment Medusa