Bedrijven, leveranciers en samenwerkende organisaties koppelen steeds vaker hun ICT-systemen met elkaar. Om efficiënter te werken worden bestanden via apps en allerlei vormen van digitale gegevensuitwisseling gedeeld. Hoewel dit veel bedrijfskansen biedt, brengt het ook beveiligings- en privacy-risico's met zich mee. Ketenbeveiliging wordt daarom steeds belangrijker.
Over deze blogger
Martijn Sprengers MSc is werkzaam als IT Security Consultant bij KPMG IT Advisory. Hij studeerde af op het gebied van Computer Security en heeft meer dan 5 jaar relevante ervaring met IT-beveiliging. Hij is gespecialiseerd in de vele facetten van het beoordelen van IT-beveiliging: ethisch hacken, social engineering, penetratie testen, red teaming en IT-auditing. Klanten zijn onder meer grote bedrijven, zoals financiële instellingen, overheden en petrochemische organisaties. Onlangs heeft Martijn zich verder gespecialiseerd op het gebied van industriële IT-beveiliging (Industrial Control Systems), met een focus op nieuwe ontwikkelingen en bedreigingen.
Als je kijkt naar de beveiliging in een keten van samenwerkende bedrijven, dan zijn niet alleen de leverende partijen belangrijk. Kun je er bijvoorbeeld zeker van zijn dat door jou vervaardigde software of (digitale) producten geen schade bij anderen aanrichten? Een beveiligingsincident bij één partij kan grote gevolgen hebben voor de andere organisaties in de keten. Organisaties proberen zich daarom op allerlei manieren in te dekken tegen aansprakelijkheid, bijvoorbeeld door audits of assurance-opdrachten te laten uitvoeren. Maar wat is precies de waarde daarvan? En hoe zorg je ervoor dat de beveiliging van de keten echt gewaarborgd is?
Certificeringen
Assurance-rapporten worden opgesteld op basis van een audit door een derde, onafhankelijke partij. Ze zijn een veelgebruikt middel om er zeker van te zijn dat een keten goed beveiligd is, maar toch bieden ze lang niet altijd de bescherming die je verwacht. De reden is dat ze van oorsprong vooral gericht zijn op generieke ICT en de bijbehorende processen. Denk aan het waarborgen van de betrouwbaarheid van (uitbestede) ict-diensten. Een ISAE3402-rapport gaat bijvoorbeeld over de beheersing van uitbestede financiële processen die relevant zijn voor de jaarrekeningcontrole, of een ISAE3000-rapport gaat over uitbestede niet-financiële processen. Voor het testen van die diensten gelden echter heel andere regels dan voor het testen van ketenbeveiliging. De vaak beperkte scope maakt het meestal onmogelijk om zekerheid af te geven over security van één partij, laat staan over de beveiliging van de gehele keten. Het is namelijk van belang dat de partij die een assurance-rapport opstelt zowel diepgravende kennis heeft van de bedrijfsprocessen, de branche waar het bedrijf actief is én ICT-beveiliging. Dat je ISO27001/2 gecertificeerd bent, wil niet zeggen dat je niet gehackt kan worden. Sterker nog, het kan een gevoel van schijnveiligheid geven.
Papieren werkelijkheid
Belangrijke vragen bij zo’n ‘right-to-audit’ zijn: Wat wordt er precies gecontroleerd? Hoe ver mag de partij die de controle uitvoert, gaan? Opdrachtgevers geven vaak inzicht in de documentatie van de ICT-infrastructuur, maar dat biedt nog geen zicht op de in de praktijk gebruikte configuraties van systemen. Partijen geven regelmatig vooraf aan dat ze volledige openheid van zaken geven. Maar op het moment dat bijvoorbeeld een penetratietest wordt voorgesteld, wordt er op de rem getrapt met het argument “dit past niet in scope van het onderzoek”. Daardoor wordt feitelijk alleen de ‘papieren werkelijkheid’ gecontroleerd en niet hoe de configuratie daadwerkelijk is ingericht, met alle gevolgen voor beveiliging van dien.
SLA’s zijn zinloos zonder KPI’s
Vaak worden afspraken vastgelegd in een SLA (Service Level Agreement). Vanuit beveiliging gezien zijn die afspraken echter weinig waard als er niet op wordt gerapporteerd en gehandeld. Door heldere KPI’s (Key Performance Indicators) voor beveiliging op te stellen en die te controleren, kunnen veel problemen voorkomen worden. Een klant van ons had bijvoorbeeld met zijn hostingpartij vastgelegd dat alle wachtwoorden uniek moesten zijn. Toen wij dat controleerden, bleek dat niet het geval te zijn. Wij adviseerden de hostingpartij de wachtwoorden aan te passen en onze klant om hier beter op te sturen. Bij een volgende controle, een jaar later, bleken de wachtwoorden wel versterkt te zijn, maar het bleek alleen te gaan om de applicatie-accounts en niet de database-accounts. Die waren nog allemaal standaard ingericht. Om die reden heeft het beveiligingsrisico dat criminelen de database-omgeving konden manipuleren een jaar geduurd. Dit voorbeeld geeft aan dat je afspraken wel kunt vastleggen, maar dat ze ook gecontroleerd moeten worden door een partij met kennis van ICT.
Vergeet middleware niet
Een andere veelvoorkomende fout die wordt gemaakt met de beveiliging van ketens is dat de middleware vaak over het hoofd wordt gezien. Ik was een tijd geleden nog bij een partij waarbij in de SLA was vastgelegd dat de afnemer van de hostingdiensten verantwoordelijk is voor de business-applicaties. De hostingpartij nam de verantwoordelijkheid voor de beveiliging van het OS en het netwerk op zich. Wie verantwoordelijk was voor middleware als JBoss, Tomcat, Websphere stond niet zwart op wit. Kwaadwillenden konden door kwetsbaarheden in de middleware te misbruiken alsnog het onderliggende besturingssysteem en de apps compromitteren. De zwakste schakel in de beveiligingsketen werd hierdoor alsnog gebroken.
4 tips voor ketenbeveiliging
Managers die nadenken over ketenbeveiliging en contractmanagement zou ik graag het volgende willen meegeven:
1. Leg verantwoordelijkheden vast bij inkoopproces
De basis voor goede ketenbeveiliging begint bij het inkoopproces. Loop bij de aanschaf van nieuwe software, apparatuur of diensten eerst met de juridische afdeling alle algemene voorwaarden langs en leg de basis voor beveiliging goed vast.
2. Scheidt leveranciers en contracten
Leg per leverancier duidelijk vast wie voor welk onderdeel van het contract verantwoordelijk is. In een SLA (Service Level Agreement) worden afspraken over bijvoorbeeld levertijden vastgelegd, maar ook over security. Voorbeelden hiervan zijn security baselines, consistentie van configuraties, opvolging van incidenten en vulnerability-monitoring.
3. Bewaak het contractmanagement
Bewaak of afspraken daadwerkelijk worden nagekomen en het contract wordt nageleefd. Hier is de meeste winst te behalen als er gezorgd wordt voor bijvoorbeeld een maandelijkse rapportage over de afgesproken security-vereisten.
4. Let op je leverancier
Organisaties richten zich bij beveiliging soms te veel op hun eigen systemen. In een keten schuilt het gevaar bij de partijen waar men vertrouwen in heeft opgebouwd. Criminelen kunnen bijvoorbeeld door besmetting van toeleveranciers jouw bedrijfssystemen binnendringen.
