Met de volgende economische dip aanstaande en de voortgaande slag om het talent, zullen nog meer grote organisaties hun systemen en hun data uitbesteden. Uitbesteding wordt op enig moment offshoring: met de consolidatie onder de aanbieders en de bijbehorende bedragen is een leverancier die zegt vanuit Nederland te blijven werken een illusie. Het moment nadert – of is al daar – dat echt kritieke systemen voor economische en politieke veiligheid ons land zullen verlaten. En daarmee krijgt informatiebeveiliging een paar extra dimensies.

Data in een ander land is onderhavig aan lokale wetgeving: als je je bedrijfsgegevens op Google Docs neerzet, mag de Amerikaanse justitie dit inzien en mag dezelfde Amerikaanse justitie tevens opleggen dat Google je dit niet vertelt. Dit geldt in diverse gradaties bij alle vormen en plekken van uitbesteding. Je bedrijfsgegevens bevatten niet alleen puur interne spullen, maar ook gevoelig materiaal over je leveranciers en partners: offertes, afspraken en financiële transacties. Daar kunnen ze ook voor langskomen, dus ook als je niets verkeerd doet kun je ermee te maken krijgen. Als justitie bij je inhouse rekencentrum aanklopt, hoor je dat vanzelf – als je het uitbesteed hebt hoor je het níet.

Als de beheerder van je systemen overzee toegang verstrekt aan derden, moet hij daartoe de mogelijkheden hebben. Beheerdersrechten (vaak gewoon root) geven feitelijk toegang tot alle informatie op de systemen. En de lokale beheerder zal echt niet de lokale wet breken om je te beschermen. De aanbieder van outsourcing loopt het risico dat hij de klant schade toe moet brengen. Dat gaat hij niet aan de grote klok hangen. Als hij verstandig is, neemt hij intussen alle maatregelen die mogelijk zijn.

Je kunt bijvoorbeeld zeggen: we nemen alleen gescreende beheerders in dienst. Maar welke garanties geeft dat eigenlijk? Feitelijk is screening dan de énige beveiliging tegen een gerichte actie. En wat zegt gescreend in de praktijk? Dat iemand de wet naleeft en geen foute vrienden heeft. Dus gehoor geeft aan de lokale opsporingsambtenaar die inzage in een systeem eist. Zeker als die ambtenaar een negatieve aantekening in een dossier kan zetten waardoor de beheerder z’n screening en daarmee z’n bron van inkomsten kwijtraakt. Dan zal deze de formulieren van die ambtenaar niet al te kritisch lezen. Niet alle ambtenaren in alle lage lonen landen zijn zuiver op de graat. Zo kan screening het tegenovergestelde bereiken van wat de bedoeling is.

Andersom is het al niet veel beter: een beheerder in een ver warm land die de data hergebruikt of vernielt, is juridisch erg moeilijk aan te pakken. Het hemd is altijd nog nader dan de rok, dus de lokale opsporingsambtenaar en zijn organisatie zullen daar nog minder aandacht aan besteden dan hier. India zit niet te wachten op berichten dat de informatie daar onveilig is, dus reken op politieke druk. Wat een vervelende bijkomstigheid is dat je als klant de beheerder geen computervredebreuk kunt aanwrijven – omdat hij de toegang al had - dus juridisch sta je ook nog heel zwak.

Veel inlichtingendiensten beschouwen het als hun taak de economische groei van hun land veilig te stellen, zoals we vorige week nog konden horen van de Britten die Liberty aftapten. Verder in het verleden hebben iets vergelijkbaars mogen meemaken met de Amerikanen die Boeing ‘hielpen’. Hiermee stellen de diensten dat ze zich bevoegd achten om bedrijfsspionage en misschien zelfs bedrijfssabotage toe te passen. Met het samenklonteren van de informatievoorzieningen van grote bedrijven in outsourcingscentra wordt dit een stuk eenvoudiger; het inbreken in vijf omgevingen is nu eenmaal simpeler dan in vijfduizend. Zeker als die vijf bij elkaar in de buurt staan, misschien wel in je eigen land. Dat het eenvoudiger is geldt overigens ook het opblazen ervan, in een low-intensity Cyberwar scenario.

De hamvraag is of je als leverancier van outsourcing de beveiligingsrisico’s van de klant moet dragen. En dan ook die van de ene klant voor de andere? Hoe kun je je verweren? De risico’s zijn fiks – spionage maar ook sabotage: stel je klant publiceert cartoons met de Profeet in een van haar dagbladen en intussen verhuis je de data van je rekencentrum in Delhi naar het nieuwe rekencentrum in Jakarta. Jij houdt heus niet bij wat al je klanten zoal doen, maar de moslimbroederschap wél! De klanten zadelen je op met een extreem moeilijk kwantificeerbaar risico: je weet immers niet op welke lange tenen ze kunnen gaan staan. Dat een onderdeel van een klant werkzaamheden verricht voor de JSF zullen ze je ook niet vertellen, en al helemaal niet dat ze die informatie neerzetten op het netwerk dat jij beheert: ze overtreden immers zélf de formele regels. Je gaat omgevingen beveiligen zonder zicht op de waarde van de informatie; een garantie voor niet-passende maatregelen.

Het is dan ook zeer interessant als aanbieder om deze gevaren af te sluiten. Als je systemen beheert maar géén toegang tot de informatie erop hebt, of die alleen hebt op een manier dat de eigenaar het merkt, kun je niet in deze onmogelijke positie gebracht worden. Nu zullen niet alle activistische groeperingen deze nuance zien, maar toch. Dit gaat helaas niet zo gemakkelijk met bestaande middelen. Het is een verworven recht van een beheerder om alle rechten op systemen te hebben, hij dreigt gewoon de manager dat hij anders niet kunt garanderen de problemen op te kunnen lossen. Druk op de management-paniekknop, en voilá.

Zorgen dat beheerders geen toegang hebben tot applicaties en informatie van klanten doe je normaliter met het minimaliseren van rechten. Het is een grote inspanning om het te regelen en de techneuten zullen het als omslachtig ervaren en dat zul je horen ook. Least privilege stelt in een niet-gehardende omgeving in de regel bovendien ook niets voor: een beheerder kan op tig manieren meer rechten krijgen. Hernoem cmd.exe naar de screensaver, doe een “net user administrator “ en zet je favoriete wachtwoord. Of zoiets. Dat zijn de eerste trucjes die je als beheerder wilt weten. Er bestaan steviger platformen, maar algemeen geldt dat besturingssystemen niet gebouwd zijn om lokale aanvallen van geautoriseerde beheerders te weerstaan. Dus je techneuten lastig vallen met ‘beperkingen’ die geen enkele serieuze aanval overleven is weggegooid geld. Je moet wat beters verzinnen.

Als aanbieder zul je verregaande eisen moeten stellen aan de systemen die je beheert – en dus aan de budgetten van je klanten die bij je komen om hun kosten te drukken. Je kunt deze vraagstukken niet oplossen in je eigen systemen: daar staat de informatie niet. Bovendien zijn de extra beveiligingskosten in dat geval helemaal voor jou. Daarbij wil de klant om de paar jaar een andere leverancier kunnen kiezen, dus je kunt geen al te complexe eisen stellen. Als het een beetje meezit heb je bovendien meer dan één klant, dus je moet je ook druk maken over de scheidingen onderling. Daarbij heb je elke paar weken een nieuwe beheerder, en na enige tijd verplaats je de boel ook nog naar een ander land met een ander rechtsstelsel en lagere loonkosten. Dat levert geen eenvoudige set funcspecs op, al met al.

- Harde scheiding tussen beheerders en informatie. Gegeven de rechten van beheerders zal dat op de meeste platformen een ‘uitdaging’ vormen. In principe kom je uit op eisen die het meest lijken op wat militaire automatisering onder MLS-capable verstaat. (MLS staat voor Multi-level Security). Een goede start is besturingssystemen met EAL5 of meer te nemen: een Linux, BSD of Solaris met trusted extensies. Of XTS-400 met STOP, maar die beheerders zijn weer zo schaars. Bovendien is het lastig als de klant tóch vasthoudt aan Exchange en Sharepoint.

- Beveiliging niet alleen op de netwerklaag, maar ook in de informatie en de transacties. Daar komt een heleboel crypto bij kijken. Met de gangbare producten kom je er niet.

- Volledig gecentraliseerd beheer van rechten en accounts. Zeg maar dag tegen oncontroleerbare ‘functionele’ en decentrale accounts. Gegeven dat de klant ook accounts op die systemen zal willen hebben (misschien zelfs voor bepaalde beheertaken, al dan niet uit te voeren door concurrenten) is dit een zeer grote en complexe operatie.

- Zonering van het netwerk waarbij beheer volledig out-of-band is. Daarmee voorkom je dat klantomgevingen elkaar beïnvloeden via je beheervoorziening. Dit legt weer een extra druk op het systeem voor gecentraliseerd beheer van rechten en accounts; de huidige generatie IDM systemen is niet ontworpen om over meerdere gescheiden omgevingen te werken. De beheersystemen moeten zo gebouwd zijn dat er via een ander kanaal toegang is als het OS door z’n hoeven gaat. Gegeven de mogelijkheden van virtualisatie of de management console van je bladeomgeving is dat te doen.

- Dynamische toegang. Enveloppenprocedures moet je afschaffen, ze kunnen echt niet meer. Dit traditionele gat in de beveiliging wordt altijd in stand gehouden met de argumentatie dat de beheerder in extreme noodgevallen met alle rechten moet kunnen aanloggen. Leuk argument tegen angstige managers, maar achterhaald. Zeker als de server 3000 kilometer verderop staat. Dynamische toegang kan als er een noodsituatie optreedt met een koppeling van een identity management systeem aan het helpdesksysteem. Als er een incident is geeft dat toegang via de out-of-band voorziening, met een eenmalig wachtwoord - en als het ticket sluit is die autorisatie weer weg. Dit mechanisme moet je ook inzetten om ongeautoriseerde changes tegen te gaan: geen change request, geen toegang.

Met het stellen van dergelijke eisen – er zijn er nog meer – zul je in je eigen vlees snijden: de concurrent die de kop in het zand steekt is ongetwijfeld goedkoper. MLS-capability is notoir duur, dus onveiligheid loont. Het is geen zekerheid dat je rampenscenario ook daadwerkelijk plaatsvindt, dus beveiliging is een twijfelachtige investering. Bedenk echter dat je, als je voor één klant een risico accepteert, je dat automatisch ook doet voor al je andere klanten. Als je dat vertelt aan die andere klanten, zullen ze wel twee keer nadenken voor ze het contract verlengen. Leg dát maar eens uit aan je aandeelhouders.