In het huidige software ontwikkelingslandschap is het steeds sneller opleveren van software een belangrijk. Organisaties moeten mee in de DevOps beweging om hun concurrentiepositie te behouden of te verbeteren. Om dit goed en veilig te kunnen doen is het van belang om zo vroeg mogelijk in het ontwikkelproces al feedback te verzamelen, om snel te kunnen bijsturen. Dit vatten we vaak samen in de zogenaamde Shift Left beweging. Shift Left is een verzameling van kwaliteitsborging methodieken zoals o.a. unittesting, performancetesting & componenttesting.

 

Naast deze belangrijke testfeedback is ook op het gebied van security een van belang dat men zo vroeg mogelijk een helder beeld heeft van de potentiele security risico’s. De wolf in schaapskleren moet al vroeg worden geïdentificeerd.

Deze methodiek bestaat uit 5 stappen die zich herhalen binnen de Software Applicatie LifeCycle. Het herhalende karakter past ook prima in het herhalende karakter van DevOps,. Of bij het gebruik van deze methodiek wellicht wel DevSecOps, omdat security nu een prominentere rol krijgt.  De stappen die men kan ondernemen zijn:

Hiervoor zijn er al tientallen geleden jaren methodieken bedacht, welke helaas vaak over het hoofd worden gezien. DevOps is een manier om een kortere “time to market” te bewerkstelligen, maar daarnaast ook een lager faalpercentage bij opleveringen.  Het beperken van security issues in productie is hier natuurlijk ook onderdeel van. Threat Modeling is bij uitstek een methodiek om bij dit laatste te helpen.

 

Define: Vastleggen van de securityeisen.

Niet in elke app zullen de securityeisen gelijk zijn. Indien er met persoonlijke data wordt gewerkt zullen er vast eisen zijn vanuit wetgeving c.q. beleid van uit de organisatie zelf. Zorg ervoor dat deze duidelijk zijn.

Diagram: Het maken van een applicatiediagram

Om inzicht te krijgen in de potentiële dreigingen is het makkelijk om de flow van de betreffende applicatie te modelleren. Dit kan men doen in specifieke Threat modeling tooling zoals bijvoorbeeld Thread Dragon. https://threatdragon.org/login

Hierin kan men de applicatie weergeven via een eenvoudige Data Flow Diagram bestaande uit Processen, Stores, Actors en/of DataFlows zoals hier weergegeven.

Identity: Het identificeren van de potentiële bedreigingen

Na het opstellen van het diagram kan men met Trust boundaries koppelvlakken aangeven waar men risico’s herkend. Het model kan na deze stap er als volgt uit zien (De groene stippellijnen representeren de Trust Boundaries):

Mitigate: Het mitigeren van de bedreigingen

In 1999 hebben Praerit Garg and Loren Kohnfelder bij Microsoft het STRIDE Model ontwikkeld. Met dit model kan men per trust boundary de specifieke kwetsbaarheden classificeren. STRIDE is een acroniem voor:

Threat	Schending	Definitie	Voorbeeld
Spoofing identity	Authenticatie	Het verkrijgen van toegang van iemand anders zijn authenticatie informatie	Zich voordoen als Clown Bassie.
Tampering with data	Integriteit	Het ongeoorloofd veranderen van data	Rekeningnummer aanpassen in data.
Repudiation	Niet-afwijzend	Het ontkennen dat men een actie heeft uitgevoerd	“Ik heb die mail niet verzonden”
Information disclosure	Vertrouwelijkheid	Het verkrijgen van data welke niet voor de betreffende persoon is bedoeld	Inzicht in belastingaangifte van de buren.
Denial of service	Beschikbaarheid	Een risico voor de beschikbaarheid en betrouwbaarheid van het systeem	Een crash loop van de website waardoor hij niet beschikbaar is.
Elevation of privilege	Autorisatie	Het toegang krijgen tot functionaliteit zonder de juiste privileges	Mogelijkheid tot uitvoeren van scripts zonder de juiste rechten.

 

Men kan nu per trust boundary inventariseren welke onderdelen van STRIDE hier een bedreiging vormen. In het eerdere voorbeeld kunnen wij aangeven dat Spoofing Identity tussen de browser en webapplicatie een potentieel risico is. Dit risico kan in dit geval bijvoorbeeld gemitigeerd zijn door het gebruik van een signed authenticatie token. Zo kan men alle trust boundaries langs lopen en aan de hand van STRIDE de risico’s inventariseren en bepalen of deze adequaat zijn gemitigeerd.

Validate: Het valideren of alle bedreigingen zijn gemitigeerd;

Na het mitigeren van de potentiële bedreigingen is het nog steeds van belang dat men valideert of er toch geen security leaks of kwetsbaarheden in de applicatie zijn geslopen. Het hebben van geautomatiseerde security scans, dependency checks in de pipeline en real time is nog steeds van belang. Daarnaast kunnen er, nu inzichtelijk is waar de potentiele grootste risico’s zitten, abuse cases worden opgesteld. Op basis hiervan kunnen weer specifieke test scenario’s worden bedacht om de gemitigeerde bedreigingen te valideren.

Tot Slot

Het kan goed zijn om deze modellering techniek in je DevOps proces op te nemen. Hierdoor kunnen potentiële security leaks al vroegtijdig worden geïdentificeerd en kan hierop worden geacteerd. Het neemt initieel niet veel extra tijd in beslag en kan veel opleveren. Het vergroot in ieder geval de security awareness bij alle betrokkenen en dat is altijd winst.

 

Auteur:
Patrick Bes, Bergler Competence Center

« Patrick helpt onze klanten als lead developer en consultant bij vragen op het gebied van .NET Core and Full framework, DevOps, Cloud transition, Microservice transition, DDD, Kubernetes, Azure DevOps, Azure platform, Identity & Access management en Shift Left.»