Afspraken die je met leveranciers moet maken over security

Belangrijke acties die je moet ondernemen als het gaat om keten-security, is allereerst in kaart brengen met welke leveranciers je zaken doet en inventariseren in welke mate deze leveranciers toegang hebben tot systemen en data van je bedrijf. Wat betekent het voor jouw organisatie als deze leverancier gehackt wordt? In augustus was dit nog het geval bij vijf Limburgse gemeenten. En als een leverancier weliswaar geen toegang heeft tot jouw data, maar wel essentieel is voor je processen, wat betekent het als deze leverancier niet kan leveren? Denk bijvoorbeeld aan de ‘kaashack’ bij Bakker Logistiek waardoor Albert Heijn geen kaas geleverd kreeg. Ligt jouw bedrijf in zo’n geval ook stil of is er een alternatief om toch door te draaien?

Vervolgens is het belangrijk om in gesprek te gaan met je leveranciers over security en de juiste vragen te stellen. Zo is het voordat je een contract sluit belangrijk om inzicht te krijgen in hoe de leverancier met security omgaat. Dit doe ik overigens zelfs in mijn privéleven. Zo vroeg ik aan de leverancier van de app die wordt gebruikt op het kinderdagverblijf van mijn dochter hoe de app beveiligd is. Het antwoord was dat de organisatie niet wilde investeren in security en dat er dus ook weinig aandacht voor was. Zeker aangezien er persoonlijke informatie via die app wordt gedeeld, is dit goed te weten zodat je proactief om maatregelen kunt vragen.

Essentiële zaken om naar te kijken bij het bewaken van security in de leveranciersketen zijn: Uit welke zaken blijkt dat informatiebeveiliging goed op orde is: hebben ze ISO-certificering? Is er intern een verantwoordelijke voor security aangesteld? Welke eisen stelt het bedrijf zelf aan leveranciers op het gebied van security? Is er een actieplan als er een datalek is en klantgegevens op straat liggen? En worden er regelmatig security-testen uitgevoerd? Allemaal essentiële vragen voordat je met een partij in zee gaat.

Wie is verantwoordelijk voor security-testen?

Ook is het slim de vraag op tafel te leggen bij wie überhaupt de verantwoordelijkheid ligt om de systemen te testen; bij de klant of de leverancier? In het laatste geval moet in het contract worden vastgesteld hoe vaak de security-testen moeten worden uitgevoerd en waar deze aan moeten voldoen. Volstaat een geautomatiseerde test of is diepgravend onderzoek door een security-expert nodig? Ook moet worden beschreven of de leverancier verplicht is de resultaten te delen en welke details vrijgegeven moeten worden.

Als bij het uitvoeren van een security-test blijkt dat er kwetsbaarheden zitten in de software van een externe leverancier, wil je uiteraard dat deze worden opgelost. De vraag komt dan al snel bij de leverancier te liggen die niet altijd de urgentie ziet en bovendien kosten moet maken om de kwetsbaarheid op te lossen. Voor wie zijn deze kosten? Het is slim om dit soort zaken ook op te nemen in het contract en hier hele concrete afspraken over te maken.

Dit voorkomt dat je mogelijk voor onaangename verrassingen komt te staan. Zo heb ik bij een klant gezien dat een leverancier 100.000 euro vroeg voor het oplossen van de ernstige kwetsbaarheden die we tijdens een securitytest hadden gevonden. Als je voor je bedrijfskritische processen afhankelijk bent van deze leverancier, heb je vrijwel geen andere keuze dan te betalen of te besluiten naar een andere oplossing te migreren.

Als goede afspraken ontbreken kun je ook in lastige situaties terechtkomen als het misgaat. Stel je voor dat je buiten kantoortijden ontdekt dat je gehackt bent via de software van de leverancier. Wie kun je dan bellen? Of stel dat de leverancier niet wil meewerken aan extern onderzoek en zegt het zelf op te lossen. Hoe krijg je dan zekerheid dat systemen die zijn aangevallen daadwerkelijk zijn opgeschoond van virussen en de hackers buiten de deur zijn gezet? Ook hebben we verschillende keren meegemaakt dat een leverancier onderzoek naar een security-incident dwarsboomde door geen toegang te geven tot bron- of logbestanden of erop te staan zelf eerst onderzoek te willen doen. Hierdoor gaat kostbare tijd verloren en kunnen zelfs sporen worden vernietigd.

Interne vangrails

Bij keten-security gaat het uiteraard niet alleen om maatregelen die je met de leverancier treft. Intern moeten er ook goede vangrails komen. Daarvoor is het raadzaam de al eerder genoemde inventarisatie te maken van waar een leverancier allemaal toegang toe heeft en met welke rechten. Denk aan je klimaatbeheersysteem, CRM-pakket of de financiële software. Hebben deze partijen rechten om bijvoorbeeld via een VPN-verbinding de software te beheren en zo ja, krijgen zij daarmee direct toegang tot het hele netwerk of alleen tot de applicatie? Bij dit laatste lijkt het logisch leveranciers alleen toegang te geven tot de eigen applicatie. Toch ben ik iedere keer weer verbaast over hoe vaak wij voor het uitvoeren van een securitytest via VPN - met ook nog eens een zwak wachtwoord - volledige toegang krijgen tot een netwerk. Daarmee staat als de leverancier gehackt wordt de deur naar het gehele netwerk wagenwijd open. Het feit dat er het afgelopen jaar verschillende ransome-incidenten zijn geweest waarbij de aanvaller binnen kwam via een VPN-account van een leverancier bewijst dat dit nog steeds een populaire methode is voor hackers om binnen te komen.

Het is vrijwel onmogelijk om security in de keten helemaal waterdicht te krijgen. Maar door je bewust te zijn van de risico’s en de mogelijkheden om met relatief simpele acties deze te verkleinen, kun je de weerbaarheid van je organisatie aanzienlijk vergroten.