Requirements Development en PASS
PaSS (Proactive Security Strategy) is een Sogeti-breed initiatief met als doel applicatiebeveiliging een bewust deel van het ontwikkelproces te maken waar vanaf het begin rekening mee gehouden wordt.
Met de kennis vanuit PaSS levert Sogeti een gestandaardiseerde aanpak voor het ontwikkelen van softwareapplicaties volgens een Secure Development Proces (SDP). Sogeti kent en ondersteunt de verschillende bekende SDP’s, zoals de SDL van Microsoft, de Touchpoints van Gary McGraw en CLASP van OWASP. SDP’s zijn complementair aan een standaard ontwikkel proces en beschrijven de taken mbt tot applicatie beveiliging binnen het ontwikkel proces. Zo wordt voor elk project de beste aanpak gekozen die het project maximaal ondersteunt.
Security Touchpoint (Gary McGraw)
Touchpoints
Op basis van de Touchpoints beschrijven we hier de link tussen requirements development en een SDP. In elk development lifecycle is een fase waarin de eisen aan de software worden vastgelegd, vergelijkbaar met de “Requirements and use cases”-fase uit de Touchpoints. Voor elke SDP geldt dat we de beveiligingseisen van de applicatie in deze fase vastleggen. De methode van vastleggen kan anders zijn, maar de algemene gedachte is dezelfde.
In de Touchpoints benoemen we requirements en ook security requirements expliciet. Het is meteen duidelijk waar de requirementsanalist zich mee bezig moet houden in de deze SDP. Er worden ook technieken meegegeven voor het vastleggen van de security requirements: In de touchpoints worden hiervoor zowel use cases als ab-use cases gebruikt. Use cases beschrijven dan functionele veiligheidseisen zoals het gebruik van encryptie. Een ab-use case is een beschrijving van de complete interactie tussen een systeem en een of meer actors, waarbij de uitkomst van de interactie schadelijk is voor het systeem, een actor of een of meer stakeholders van het systeem.
In het ontwikkel traject zullen ab-use cases niet dezelfde rol spelen als use-cases. Ze beschrijven immers functionaliteit die niet mogelijk moet zijn.Het doel van ab-use cases is het leren denken als een hacker en misbruik in kaart brengen. Ab-use cases maken het begrijpen van de mogelijke beveiligingsissues voor gebruikers zonder beveiligingskennis makkelijker en laten de applicatie zien vanuit het oogpunt van een hacker. Een ab-use case geeft een beeld van een range van verschillende mogelijke beveiligingsissues. Hoe deze worden opgezet wordt onder andere uitgelegd in whitepaper “Testen van applicatiebeveiliging op basis van Tmap” door PaSS-SC.
Via de volgende stappen stellen we een ab-use case op:
- Gebruik een use case als basis;
- Voeg de hacker toe;
- Voeg mogelijk misbruik op de (reeds bestaande) functionaliteit toe;
- Voeg eventuele oplossingen toe.
Security requirements
Het is goed denkbaar dat we in sommige gevallen duidelijk moeten aangeven dat het systeem bepaalde acties niet ondersteunt: bijvoorbeeld de eis dat SQL statements in een login- of wachtwoordveld niet worden uitgevoerd. De gedachtegang hierachter is dat als je alleen beschrijft wat je wilt, je soms impliciet ongewenste functionaliteit meekrijgt. Het alleen stellen dat de applicatie beveiligd moet worden met een login en wachtwoord sluit niet uit dat SQL statements gebruikt kunnen worden om het systeem alsnog te hacken.
De analist kan COPAFIJTHES, ISO9126 of de T-map kwaliteitsatributen gebruiken gebruiken om non-functional security requirements te beschrijven. Daarnaast kunnen we het voorschrijven van bepaalde security maatregelen zoals encryptie beschouwen als functional security requirements Voor het ontwikkelen van veilige software is het dus noodzakelijk dat de analist een stap verder kijkt. Naast wat het systeem moet kunnen voor de stakeholders moet daarom ook beschreven worden wat niet mogelijk moet zijn- om zo het systeem te beschermen tegen aanvallen van buitenaf.
Voor de requirementsanalist betekent dit een andere manier van denken. In plaats van alleen te kijken wat het systeem of de oplossing moet kunnen wordt er ook gekeken wat er absoluut niet moet kunnen, welke functionaliteit nadelige gevolgen heeft voor de applicatie. Hierbij valt te denken aan ongeautoriseerde toegang maar ook aanvallen gericht op het platleggen van applicatie.
De analist krijgt ook te maken met een extra stake holder, de security officer. De security officer is de gene die weet hoe het bedrijf vorm geeft aan alle security richtlijken. Hij zal ondersteuning moeten bieden bij het vertalen van security richtlijnen van het bedrijf naar specifieke security requirements die door de analist kunnen worden vast gelegd.
Ook moet de analist threat models kunnen lezen en begrijpen. Hieruit kan worden afgeleid wat de prioriteit van de verschillende security requirements is.
Gevolgen voor de requirementsanalist
Voor de requirementsanalist betekent dit een andere manier van denken. In plaats van alleen te kijken wat het systeem of de oplossing moet kunnen wordt er ook gekeken wat er absoluut niet moet kunnen, welke functionaliteit nadelige gevolgen heeft voor de applicatie. Hierbij valt te denken aan ongeautoriseerde toegang maar ook aanvallen gericht op het platleggen van applicatie.
De analist krijgt ook te maken met een extra stake holder, de security officer. De security officer is de gene die weet hoe het bedrijf vorm geeft aan alle security richtlijken. Hij zal ondersteuning moeten bieden bij het vertalen van security richtlijnen van het bedrijf naar specifieke security requirements die door de analist kunnen worden vast gelegd.
Ook moet de analist threat models kunnen lezen en begrijpen. Hieruit kan worden afgeleid wat de prioriteit van de verschillende security requirements is.
Security requirements betekenen een extra toevoeging aan de requirementsadministratie. Alle kwaliteits attributen die van toepassing zijn in het kader van security moet expliciet vastgelegd worden in de requirements administratie.
De analist zal meer als een hacker moeten denken om potentiële lekken, achterdeuren en kwetsbaarheden te ontdekken die een gevolg kunnen zijn van de requirements die zijn geuit door de stakeholders. Hij wordt hierbij wel geassisteerd door de security officer. Samen met de security officer moet de analist de andere stakeholders bewust maken van mogelijke security consequenties van de andere requiremenst die ze hebben geformuleerd. Samen met de security officer zullen er requirements opgesteld moeten worden voor de tegen maatregelenen, voor de security issues als gevolg van de andere requirements.
In een secure development traject zal de analist gedurende alle stappen van het requirements developmentproces ook bezig zijn met de security requirements.
