Gisteren was de keynote van de Black Hat briefings, ooit bedoeld om vanuit het perspectief van een hacker informatie te verschaffen om te zorgen dat je je beter kon verdedigen. De bedenker en oprichter van Black Hat, Jeff Moss trapte af met te vertellen dat er deelnemers uit 111 landen aanwezig zijn op Black Hat en dat we nog steeds niet bepaald “in control” zijn. Hij had een aardig verhaal, we hebben meer mensen nodig in Security (duh) en diversiteit is goed (nog een keer duh) en nog een paar andere open deuren. Daarna gaf hij het woord aan Chris Krebs, een begenadigd spreker die wel erg gericht was op de Amerikaanse markt maar die niet zo’n positief verhaal had. Het gaat niet goed op het gebied van cybersecurity en hij verwacht dat het nog erger wordt voordat het beter wordt en, by the way, de overheid is ook niet goed georganiseerd en dat gaat ook nog wel even duren. Chris is de voormalig directeur van CISA, Cybersecurity and Infrastructure Security Agency (cisa.org), een overheidsinstelling dus, dus hij weet vast waar hij het over heeft.
En het is allemaal de schuld van de developers
De keynote is vast terug te kijken, maar heel veel nieuws ga je denk ik niet horen, maar ik heb zelden zo’n negatief verhaal gehoord op een Amerikaans event.
De boodschap was dan uiteindelijk wel positief, we hebben de bodem nog niet bereikt, maar het gaat wel beter worden. Software blijft kwetsbaar, de hele beweging naar de Cloud heeft het enorm complex gemaakt en de attack surface is alleen maar groter geworden. In een andere sessie werd beweerd dat er in het eerste kwartaal van dit jaar 10x zoveel malware verspreid werd dan in het eerste kwartaal van vorig jaar. Ransomware as a Service, Malwarekits die je kan kopen, het is een lucratieve business geworden waar je steeds makkelijker in kan stappen.
Poeh, zware kost voor een artikel op LinkedIn, marketingtechnisch ook niet altijd wenselijk. Ik had in mijn eerste blog van deze week ook al een stuk getypt over het verval van Las Vegas en de “dark side” van deze stad, heb ik toch maar niet gebruikt.
Security Jedi’s?
Hoe komen we dan door die dip heen en zorgen we met elkaar dat het wel beter gaat worden? Later op de dag was er een sessie van Adam Shostack, een bijzondere man die een bekend boek over threat modeling heeft geschreven (en er komt binnenkort een nieuw boek uit). De titel van zijn sessie is “A fully trained Jedi, you are not”, hoog nerd-gehalte dus met allerlei star-wars vergelijkingen.
Shift Left, maar dan goed
Zijn boodschap was wel helder, alle securityproblemen beginnen bij software en de hele “Shift Left” beweging werkt niet. Ook al zo lekker positief dus.
Gelukkig gaf hij ook wat handvatten om wel een positieve verandering in te zetten, een aantal die overlap hebben met de sessie waarover ik gisteren schreef.
Shift left in security betekent dat je al tijdens het ontwikkelen van software aandacht hebt voor security in plaats van dat je dat later in het proces (test, productie) doet. Dat maakt het makkelijker en goedkoper om bugs en zwakheden op te lossen. Het probleem nu is dat security als het ware opgelegd wordt, het moet van de securityafdeling, dus je moet het doen en er zit te weinig intrinsieke motivatie bij en dat is een risico.
DevSecOps
Shift left impliceert dat je het Development proces aanpakt en duidelijke verantwoordelijkheid bij de Developers neerlegt. Er verandert dan nogal wat:
- Deliverables, security als Quality Attribute (mijn toevoeging)
- Taken die uitgevoerd moeten worden
- Skills die je nodig hebt om die taken uit te voeren
Eerder deze week heb ik geschreven over het veranderen van de IT-organisatie, terug naar welke waarde leveren we als organisatie en welke diensten en applicaties hebben we nodig om dat te doen, veilig, veerkrachtig in het geval er toch iets gebeurt. Adam schetste iets vergelijkbaars, stel de vraag: “Wie levert wat aan wie en hoe wordt dat dan geleverd”. Het idee achter deze vraag is dat je helder krijgt wat je developers moeten weten en kunnen om hun werk goed te doen en ze duidelijke doelen mee te geven (dat kwam in een andere sessie dan weer naar voren, als je een team hebt die duidelijk kunnen aangeven wat hun rol, hun bijdrage in de organisatie is dan presteert een team een stuk beter).
Trainen van Developers
Als duidelijk is wat de rol van de developers is, welke rol security daarin speelt en duidelijk is wat de developers dan moeten leveren dan kan je gericht training ontwikkelen. Ik ga er niet al te diep op in, maar Adam is fan van “Bloom’s Taxonomy” als learning framework. Samengevat in deze context gaat het om training bouwen en leveren die:
- Past bij de rol
- Waarin de trainingstijden redelijk zijn
- Met duidelijk geformuleerde doelen
- Creëer een community, zorg dat mensen elkaar kunnen vinden en helpen
- Let op dat het niet te veel wordt, let op “rode vlaggen”, burnouts komen steeds vaker voor (waren ook sessies over deze week)
- Knip de training in kleine stukjes
- In 1 training sessie tussen de 5 en 9 stukjes informatie geven (meer kunnen we toch niet onthouden)
Samengevat
Developers hoeven geen volledige securityspecialisten te zijn maar ze moeten wel weten welke bedreigingen er zijn, welke rol zij spelen en op welke manier zij bijdragen aan de doelen van de organisatie.
Training op maat, in kleine stukjes, onderdeel van de werkroutine en zo stap voor stap secure development verbeteren en echt Shift Left in security toepassen.
Er is overigens steeds meer tooling op de markt die hierbij helpt, Snyk bijvoorbeeld, kan een versnelling geven in dit hele proces.
Things will get better, tot morgen!