Meer over Security Testing en DEVOPS
In het kader van onze “security testing voor DEVOPS” trainingen bespreken we regelmatig in detail hoe security testing optimaal kan worden ingeregeld in een DEVOPS setting (of Continuous Delivery, waarvoor DEVOPS een randvoorwaarde is).
DevOps is een samenvoegsel van een aantal processen en methoden voor het nadenken over communicatie en samenwerking tussen ontwikkelaars, beheerders en de QA functie. Deze processen en methoden worden vaak geimplementeerd door het software delivery proces in hoge mate te automatiseren.
Het achterliggende doel daarbij is om de voorspelbaarheid, efficientie, veiligheid en onderhoudbaarheid te maximaliseren.
Bij nSEC/Resilience zien we security als een kwaliteitsattribuut; net als andere kwaliteitsattributen van software is de komende tijd nog wel te verwachten dat er in een bepaalde mate een menselijke hand nodig zal zijn in het accuraat beoordelen van dergelijke kwaliteitsattributen vanuit alle mogelijke facetten.
Dat betekent niet dat security testing een uitzonderingspositie moet innemen in DEVOPS of Continuous Delivery. Er zijn security controles die bij elke release herhaald moeten worden en geschikt zijn voor automatisering. Denk dan aan het identificeren van bekende vulnerabilities door bijvoorbeeld het automatisch scannen met Nessus en OWASP ZAP; daarmee kan al een groot deel van nieuw geintroduceerde maar vaker nog regressie issues vroeg worden gevonden. Maar ook minder voor de hand liggende controles kunnen worden geautomatiseerd; parameter tampering kan met een webdriver zoals Selenium worden uitgevoerd.
Bij nSEC/Resilience zetten we in op optimale maturity van betrokken agile teams; daarbij hoort ook optimale integratie met de business en andere stakeholders zoals de betrokken IT architecten en security officers. Om de team maturity te optimaliseren maken wij ons hard voor het integreren van natuurlijke taal in het IT domein (domain specific language) in het specificeren van de uit te voeren security tseten, zoals dat ook op het gebied van functional testing de trend is. Vastlegging van de uit te voeren security testen in een domain specific language zoals Gherkin stelt het team in staat hun security controles al in het design stadium af te stemmen en uit te werken met stakeholders. Bijvangst is dat toeval bij het vinden van issues zoveel mogelijk wordt uitgebannen; de gespecificeerde testen maar ook configuratie van de gebruikte tools wordt consequent ingezet.
Voorbeeld Gherkin script dat op HTTPS controleert:
Scenario: login form is available through HTTPS only
Given a new browser window
And the login page is displayed
And the HTTP request and response for the login is executed
Then the protocol should be HTTPS
nSEC/Resilience heeft erg goede ervaringen met het opzetten van de beschreven automated security testing met Selenium en Cucumber als Gherkin processing tool en Jenkins als automation server. Hierbij kan bijvoorbeeld OWASP ZAP worden gebruikt als security scanner, maar kan er ook worden gekozen voor een specifieke andere scanner of mix van tools.
Wij worden blij van alles wat testen is! We horen dan ook graag wat uw situatie is om samen te kijken of we met automated security testing uw organisatie nog beter kunnen maken!