Waarom DevSecOps een fabeltje is

“Ik haat DevSecOps”, laat AWS CISO Steve Schmidt zich ontvallen op het podium van de Re:Inforce-conferentie. De zaal barst in applaus uit. Wat is het probleem met het stukje ‘Sec’, en waarom wordt het uitgejouwd op een beveiligingsconferentie?

AWS Re:Inforce in Boston is de allereerste conferentie van de cloudreus met een focus exclusief op beveiliging. Het event trok meteen meer dan 7.000 bezoekers en overtrof zo duidelijk de verwachtingen van alle aanwezigen, die hun enthousiasme over de veranderende mindset inzake beveiliging nauwelijks konden bedwingen tegenover Techzine.

Dat er een gezonde interesse zou zijn, komt natuurlijk niet als een verrassing. “De security-track op Re:Invent was altijd al de populairste”, verklaart Mark Riley van Amazons CISO-office. “Een analyse van de aanwezigen toonde echter aan dat de sessies vooral mensen aantrokken met DevOps in hun jobtitel en maar weinigen met security in hun functiebeschrijving. We wilden die andere groep ook bereiken aangezien die uiteindelijk als taak heeft om vat te krijgen op beveiliging binnen hun bedrijf.”

Weg met DevSecOps

Zo was Re:Inforce geboren als securityconferentie. Steve Schmidt, de CISO van AWS, sprak als hoogstgeplaatste AWS-excecutive de massa toe tijdens een keynote. Die massa bestond zoals gepland niet alleen uit DevOps-specialisten, maar ook uit mensen met een algemenere beveiligingsfunctie. Het was tijdens de keynote dat Schmidt zich de quote over DevSecOps liet ontvallen en het applaus oogstte.

 

CISO Steve Schmidt heeft het niet op de term DevSecOps, omdat die volgens hem het verkeerde signaal zendt.

“Je kan toch nooit aan ontwikkeling of operations doen zonder security”, verklaart Schmidt. “Een onderscheid tussen DevSecOps en DevOps impliceert dat het een optie is om applicaties te ontwikkelen en uit te rollen zonder dat daar een beveiligingsaspect bij komt kijken. Dat plan van aanpak mag gewoon niet bestaan.” Schmidt hekelt het ‘Sec’-luik omdat het lijkt aan te geven dat het een derde pijler is die los staat van ontwikkeling en operations, terwijl het de visie van AWS is dat beveiliging nauw verweven moet zitten in die twee takken.

Mentale switch

“Dat is een mindsetverhaal”, geeft Schmidt toe. “Voor ons is security ‘Job 0’”. Dat is een boutade die AWS graag bovenhaalt, maar ook kan concretiseren. Riley: “In iedere organisatie is er een tegenstelling tussen functionaliteit en risico. Te vaak ligt de nadruk nog op de snelle uitrol van functionaliteit, terwijl het omgekeerde vanzelfsprekend moet zijn. Als er een beveiligingsrisico bestaat, kan je een app niet uitrollen.”

Daarvoor moet de tegenstelling tussen ontwikkelaars en beveiligingsteams verdwijnen. “Security mag niet de naam hebben om een obstakel te zijn dat de uitrol van een app tegenhoudt”, vervolgt Riley. “Als dat gebeurt, moet de reflex van ontwikkelaars zijn dat ze zelf iets verkeerds hebben gedaan.” Die reflex kan er enkel komen onder impuls van management. Riley: “Moet er een beslissing gemaakt worden tussen snellere uitrol of veiligheid, dan is het aan C-levels om telkens voor veiligheid te kiezen. Enkel zo zorg je ervoor dat iedereen van het begin af aan zijn verantwoordelijkheid neemt.”

Mee verantwoordelijk voor security

“Idealiter komt de verantwoordelijkheid voor de veiligheid van de code bij die ontwikkelaars te liggen”, voegt Schmidt toe. “Als er een interventie nodig is, dan is daar geen persoon beter voor geschikt dan de programmeur die de code heeft geschreven.”

 

Idealiter komt de verantwoordelijkheid voor de veiligheid van de code bij die ontwikkelaars te liggen.

 

Door security op die manier in de DevOps-workflow te pompen, is er geen ruimte meer voor DevSecOps. Security is immers geen derde luik, maar een essentieel onderdeel van de jobomschrijving van het hele DevOps-team. De mindset lijkt te overheersen in Boston, maar dat is misschien logisch. We de eerste AWS-cloudsecurityconferentie ooit bijwoont, mag zich vermoedelijk pionier inzake beveiliging noemen of heeft toch minstens de ambitie om daar te raken. AWS verwacht daarom veel van de deelnemers.

Early-adopter-effect

AWS ziet de deelnemers als ‘change agents’. Early adopters van de juiste cloudsecuritymindset zeg maar. De cloudgigant hoopt dat zij als evangelisten best practices zullen overbrengen naar minder gepassioneerde mensen in kleinere organisaties, zodat op termijn iedereen een securitycentrische mindset aanneemt.

De beveiligingsbedrijven hebben daar een belangrijke verantwoordelijkheid vindt Schmidt. “Vandaag prediken ze al te vaak angst. In mijn ogen is hun aanpak veel te negatief en dat werkt niet. Het is een beter idee om te vertrekken vanuit het standpunt dat sommige dingen goed en andere dingen slecht lopen, en dan samen te kijken naar concrete zaken die beter kunnen.”

Geen drama maken

Securityverkopers kiezen zelf inderdaad vaak een variant van hetzelfde verhaal: “Aanvallers zijn extreem geavanceerd en jouw beveiliging is ontoereikend, je gaat tenonder tenzij je de juiste oplossing kiest.” Hoewel Re:Inforce een beveiligingsconferentie is, horen we die retoriek nergens. Dat is opvallend aangezien de beursvloer gevuld is met securityspecialisten die net dat verhaal als fundering van hun marketingstrategie gebruiken. Denk maar aan Check Point en het generatieverhaal. “Hier is zoals je ziet zo’n verhaal niet aan de orde”, aldus Schmidt. “Of ze hun strategie ook zelf zullen veranderen, zal afhangen van de reactie van de klanten.”

 

Vandaag prediken securityvendoren al te vaak angst.

 

AWS zelf neemt tot slot ook verantwoordelijkheid. In eerste instantie is het cloudmodel er één van gedeelde verantwoordelijkheid. Wat de provider zelf voorziet, wordt steevast ontwikkeld in een cultuur waar beveiliging een must is. Ook voor de klanten voorziet AWS een houvast. Zo zijn misconfiguraties één van de grootste beveiligingsproblemen in een publieke cloudomgeving.

Veilig by default

“Daarom zijn onze standaardinstellingen altijd veilig”, vertelt Schmidt. “Een firewall zit bijvoorbeeld standaard ingebakken in EC2, en poorten staan altijd gesloten.” Risicovolle instellingen zijn met andere woorden steeds een opt-in.

Verder zien we doorgedreven beveiliging in onder andere encryptie. Op de conferentie kondigde AWS bijvoorbeeld standaard S3-opslagversleuteling aan en ook netwerkverkeer tussen n-instances verloopt voortaan versleuteld zonder cpu-overhead. Die toevoegingen zijn te koop als extraatjes: AWS biedt de beveiligingsopties als standaard aan. Dat illustreert langs de ene kant de toewijding voor security, maar mag je langs de andere kant niet los zien zonder de concurrentie met het Google Cloud Platform en Microsoft Azure in beschouwing te nemen.

Op het einde van de rit is de boodschap duidelijk: beveiliging is een verantwoordelijkheid van iedereen en geen afzonderlijke tak, laat staan een bedrijfsentiteit die flexibiliteit en snelheid tegenwerkt. Het is gewoon een must, en dat besef lijkt steeds meer te groeien.

Gerelateerd: Veilig in de cloud: waarom AWS zijn eigen chips ontwikkelt