Veiliger innoveren met devsecops 2/2

In het vorige artikel over veiliger innoveren met devsecops werden de achtergronden van deze ontwikkeling geschetst. Na de theorie volgt nu een concreet voorbeeld, KPN.

De KPN-case

KPN is een organisatie die 24/7 met security te maken heeft en waar de druk permanent te innoveren hoog is. KPN had rond 2016 veel back-end systemen met eigen front-ends die ieder een klein deel van de klantinformatie ontsloten. Dat maakte het voor gebruikers, zowel medewerkers als klanten, lastig om goed inzage te krijgen in de benodigde gegevens. Wijzigingen doorvoeren was ook complex en tijdrovend. Daarom is besloten om een schil over die systemen heen te leggen, zodat gebruikers op één plek alle relevante informatie vonden. Die schil werd agile ontwikkeld en blijft ook onderwerp van voortdurende doorontwikkeling.

In eerste instantie leverde deze methode wrijving op met de security organisatie van KPN, die gewend was op projectbasis te werken. Dit betekende onder andere een risk assessment aan het begin van een ontwikkeltraject, een penetratietest aan het eind en vervolgens tussentijdse assessments wanneer innovatie plaatsvond. De security specialisten kregen nu te maken met tientallen scrumteams die iedere twee weken wijzigingen aanbrachten in de productieomgeving. De KPN security policy, die toen voor alle systemen en processen gold, bestond uit een paar honderd regels. Iedere innovatie moest aantonen aan die lijst te voldaan. Door de overgang naar agile begon dit proces een onevenredige hoeveelheid tijd te kosten. Xebia en KPN hebben samen die lijst tegen het licht gehouden en gekeken welke regels bij iedere sprint relevant zijn, welke periodiek aangetoond moeten worden en welke helemaal niet relevant zijn voor softwareontwikkeling. Op die manier is de lange lijst teruggebracht tot een set van een tiental vragen. Afhankelijk van het antwoord op de eerste vraag verschijnt een subset aan vervolgvragen die voor dat type ontwikkeling relevant is. Van een paar honderd regels naar een tiental vragen lijkt misschien een te grote versimpeling, maar essentieel is dat die vragen dienen als filter. Er wordt beter gekeken naar wanneer iets relevant is. Een deel van de eisen heeft bijvoorbeeld betrekking op de fysieke en netwerkbeveiliging van het datacenter. Dat hoeft niet bij iedere sprint getoetst te worden als ontwikkeld wordt in een eerder gevalideerd datacenter. KPN controleert het datacenter nu periodiek onafhankelijk van de sprints.

Verantwoordelijkheden helder

Het grote voordeel van de korte lijst is dat hoofd- en bijzaken veel duidelijker van elkaar te scheiden zijn. Alle betrokkenen bij softwareontwikkeling weten nu precies waar zij verantwoordelijk voor zijn. Bij de lange lijst waren verantwoordelijkheden veel minder duidelijk, met het gevaar dat niemand zich echt eigenaar voelde. Hierdoor werden afwijkingen vaak veel te laat geïdentificeerd. Bij de korte vragenlijst is meteen duidelijk: “Wie is hiervoor verantwoordelijk”, “Hoe raakt dit andere aspecten van security” en “Welke aspecten zijn nu echt kritisch”. Het is daardoor ook gemakkelijker geworden om risicoprofielen toe te passen.

Ieder team binnen KPN weet nu wat de spelregels zijn. Zolang ze binnen deze spelregels blijft, kunnen ze met deze veel kortere set aan controles doorgaan. Wil iemand de spelregels verruimen, dan moet hij ook rekening houden met aanvullende controles. Daardoor weet iedereen op voorhand wat de impact is van een beleidswijziging of een innovatie. Dit heeft ertoe geleid dat security kennis nu breder belegd is, KPN veel vaker en makkelijker wijzigingen kan doorvoeren en de tijd die innovatie kwijt is om te kijken of aan het juiste security level voldaan is, verminderd is. Ook is het aantal security incidenten is sindsdien behoorlijk gedaald. Door security procedures te vereenvoudigen en het thema vanaf het begin van ieder ontwikkeltraject mee te nemen, durft de business veel sneller met nieuwe dingen te komen. Ze maken zich minder druk om wat er allemaal op hen wordt afgevuurd. Tegelijkertijd kunnen de agile teams zich veel meer focussen op innovatie en zijn ze minder tijd kwijt met het fixen van dingen die zijn omgevallen.

 Devsecops als katalysator

Het project bij KPN startte in 2016 en over de jaren is dankzij devsecops en voortschrijdend inzicht de werkwijze verder aangescherpt. De lijst waarmee in 2016 is gestart diende vooral om de laatste tollgate te versimpelen en bestaat nog steeds.

Het toegenomen bewustzijn en draagvlak leiden tot een forse toename van zowel security automation als ‘security & privacy by design’ als uitgangspunten. En dat komt omdat de teams vanaf het begin af aan denken over risico’s en mitigaties. Dankzij devsecops is security een katalysator geworden van innovatie bij KPN.

Over Redactie ISP Today

ISP Today is het Nederlandstalige platform voor de Internet Service Providers in Nederland. We presenteren nieuws van redactionele kwaliteit met relevantie voor de Nederlandse ISP community. Internet Service Providers en met name de mensen daarachter staan centraal op ISP Today.

Laatste artikelen