het doekje voor het bloeden

Complexiteit maakt per definitie onveilig

Beveiligingstechniek:

Interview het doekje voor het bloeden

Auteur: Frans M. Kanters > Frans Kanters is security watcher en freelance journalist. Hij publiceert regelmatig over kwesties rond informatiebeveiliging (e-mail: [email protected]).

Identificatie en authenticatie vormen een steeds belangrijker aspect binnen beveiliging. Is het zo dat dit met certificaten überhaupt wel zin heeft? Een aantal organisaties ziet op tegen de hoge eisen ten aanzien van PKI overheid voor de elektronische handtekening. (smartcard, FIP140 certificering, EAL4 et cetera). Zal de PKI in de toekomst dan niet alleen gebruikt gaan worden voor authenticatie doeleinden. Om maar met de deur in huis te vallen: is er een alternatief voor PKI? “Om met het laatste deel van de vraag te beginnen, ‘ja’, op zich wel. Het ligt eraan hoe je het opzet. Een PKI wordt op dit moment veelal opgezet als een centrale autoriteit, die zaken controleert, en aan de hand van het resultaat van deze controleslag een certificaat al dan niet toekent. Een certificaat is een set gegevens behorend bij een persoon of computersysteem, gekoppeld aan een sleutelpaar. Voorheen werd

Het invoeren van beleid ten aanzien van informatiebeveiliging kan niet zonder de inzet van technologie. De complexiteit van technische beveiligingsproducten en de snelheid waarmee innovaties zich opvolgen, maken deze invoering lastig. In combinatie met het onjuist ontwikkelen van software wordt een fors aantal beveiligingsincidenten veroorzaakt. Beveiligingstechniek wordt daardoor een soort doekje voor het bloeden. Als technisch beveiligingsconsultant en ethisch hacker komt ing. Hans van de Looy, CEO van Madison Gurkha BV, dit scenario maar al te vaak tegen. Het aanbod aan beveiligingstechniek is enorm; er is echter ook veel techniek die in feite onnodig is. De echte problemen ontstaan pas als mensen met de techniek om moeten (leren) gaan. Daarnaast wordt er een cruciale fout gemaakt: tijdens de ontwikkeling van software wordt te weinig aandacht besteed aan security, en ontstaat er per definitie onveilige programmatuur.

elke PKI (Public Key Infrastructuur) geïmplementeerd als een soort piramidestructuur waarbij de CA (Certificate Authority) aan het hoofd staat, en waaronder alle overige onderdelen hangen. Als je certificaten gaat gebruiken voor het veilig uitwisselen van email dan zijn er al veel langer alternatieven, namelijk het veilig uitwisselen van e-mail gebaseerd op een web of trust. Dit was al beschikbaar voordat PKI bestond. PGP (Pretty Good Privacy) is wel het bekendste voorbeeld hiervan. Momenteel is er een andere open source variant, genaamd GPG (GNU Privacy Guard). Hierbij is er

geen centrale autoriteit. Het vertrouwen naar elkaar uitspreken, van mensen onderling, vormt hierbij de basis. Dit doe je door elkaars publieke sleutel te ondertekenen. Wil je op dit moment op basis van X.509 certificaten iets of iemand authenticeren en veilig informatie uitwisselen, dan kom je al snel terecht bij organisaties als Verisign. Deze hebben een complete structuur ingericht om certificaten uit te delen. Een PinkRoccade en Diginotar zijn in feite onderaannemers van Verisign. De masterkey van Pink is namelijk weer ondertekend door Verisign. Hier zie je dus ook die pirami-

INFORMATIEBEVEILIGING december 2004

23 Jubileumnummer

de terug. Maar ook hier kan een web of trust een bruikbaar alternatief zijn. Recentelijk is het initiatief CACert (http://www.cacert.org) in Australië opgestart. Dit betreft ook een global PKI, die gebaseerd is op de ideeën van een web of trust. De CACert website is er ter ondersteuning - zorgt voor het genereren van certificaten en helpt mensen om zelf gegevens in dat certificaat te plaatsen. Voorts zorgt CACert dat er keypairs gegenereerd worden en dat er uiteindelijk een ondertekend X.509 certificaat kan worden gebruikt door eindgebruikers. De notarisfunctie wordt gedaan door andere CACert gebruikers die - doordat ze hun identiteit door verschillende andere gebruikers hebben laten controleren - punten hebben gekregen. Bij een bepaald aantal punten kunnen deze mensen weer andere mensen controleren of de gegevens juist zijn. Hierdoor gaat de eerdere genoemde piramide structuur van meer traditionele PKI’s op de fles. Mensen geven namelijk zelf aan of zij iemand vertrouwen, en in welke mate. Als er nu voldoende mensen zijn die een bepaalde deelnemer aan CACert hebben gecontroleerd, kan deze persoon een zodanig aantal punten opbouwen dat hij of zij zelf certificaten kan toekennen. Deze kunnen dus gebruikt worden voor e-mail en webservers. Het mooie van een PKI systeem is dat het certificaat in dit geval ook aangeeft dat je met de juiste webservices communiceert, dat deze informatie niet door een willekeurig iemand gewijzigd kan worden en dat de browsers deze informatie ook nog controleert. Het alternatief is dat een organisatie een self-signed certificaat genereert dat aangeeft: ‘Ik ben deze webserver, met deze sleutel’. Het lastige hiervan is dat je niet kunt controleren of deze informatie werkelijk correct is. De strenge eisen die de overheid aan PKI stelt, spelen bedrijven inderdaad parten. Dit is overigens ook een reden dat het zo lang geduurd heeft voordat de overheid met een oplossing voor PKI op de proppen kwam. Als je dergelijk eisen stelt, die wellicht nodig zijn, worden de kosten heel erg hoog. Doet de overheid dit omdat bepaalde instellingen veilig moeten kunnen communiceren, dan kan ik het mij nog voorstellen. Op het moment dat het

Jubileumnummer

24

om communicatie naar burgers gaat, dan wordt het onmogelijk. Gebruikersvriendelijkheid naar de burger toe en een opzet die de burger begrijpt, zijn van groot belang om een PKI-achtige oplossing in te voeren. Dat begrijpen kun je het beste doen door voorbeelden te gebruiken die direct uit de praktijk komen. Door die link te leggen, maak je het juiste gebruik ervan eenvoudiger. Daarnaast moet het gebruikersvriendelijk zijn en blijven. Het laatste is erg lastig, vooral als je kijkt naar technische beveiliging. Het invoeren van DigID zal dan ook op dezelfde problemen stuiten als elke technische beveiligingsoplossing. Op het moment dat het onderwerp cryptografie aan de orde komt, zullen de mensen met vragen komen. Mensen moeten begrijpen dat als je het systeem verkeerd gebruikt, er zaken verkeerd kunnen gaan. De vraag die beantwoord moet worden, is dan ook: waar wordt de PKI oplossing voor gebruikt? Het gevaar bestaat dat je teveel (verschillende) zaken met elkaar wilt combineren. Er worden op een gegeven moment zoveel persoonlijke gegevens gekoppeld aan het certificaat, dat de persoon in kwestie extra moet worden opgeleid. De techniek voor een PKI is beschikbaar. De vertaalslag naar een - vooral gebruiksvriendelijke - invoering van PKI voor een groot publiek is nog steeds niet optimaal. Daar ligt de werkelijke uitdaging.” Is het in de toekomst mogelijk om vooral mobiele gebruikers te authenticeren op basis van locatie en bijvoorbeeld een PDA, smartphone? “Authenticeren blijft lastig. Identificeren kan al, bijvoorbeeld met het IMEI nummer van een GSM in combinatie met de SIM. Mensen staan er veelal niet bij stil dat je via je GSM overal te traceren bent. Dit heeft vooren nadelen. De leverancier van de dienst kan de handel en wandel van abonnees compleet volgen. Deze informatie moet conform wettelijke regelingen voor AIVD (Algemene Inlichtingen- en Veiligheidsdienst), KLPD (Korps Landelijke Politiediensten) et cetera beschikbaar zijn. Voor de opsporing van criminelen is dit goed; maar op het moment dat er misbruik wordt gemaakt van deze informatie heb je de poppen aan het dansen.


Authenticatie van gebruikers van mobiele devices is lastig, omdat er op het device persoonlijke gegevens moeten worden opgeslagen waarmee die identiteit wordt vastgelegd. Je blijft het device identificeren en niet de persoon. Je kunt de telefoon altijd aan iemand anders geven. Als je het device kunt koppelen met goede biometrie kun je de eerste identificatie van de gebruiker goed regelen. Daarna ontstaat een probleem, of het moet worden gecombineerd met een andere continue vorm van identificeren zoals stemherkenning. Hoe ver moet je gaan? Een chip bij mensen inbrengen? De FAR (False Acceptance Rate), het onterecht toestaan en goedkeuren, van vingerscanners is nog vrij hoog. Irisherkenning is lastig bij een mobiele telefoon. Er zijn overigens onderzoeken gedaan naar het profiel van het menselijke oor. Het schijnt uniek genoeg te zijn om de mens te kunnen identificeren. Ik verwacht niet snel een technische oplossing. Overigens moet autorisatie en identificatie trouwens altijd persoongebonden zijn, en niet locatie gebonden. En dat heeft dan weer invloed op de privacy. Als het uiteindelijk mogelijk is om een mobiele gebruiker foutvrij te kunnen identificeren, dan kun je alle privacy wetgeving en regels overboord zetten, omdat je dan alle privacy zelf weggeeft. “ En hoe zie je locatie gebonden authenticatie in het verband dat een gebruiker bepaalde informatie wel op een interne locatie mag inzien, maar niet daarbuiten (in verband met de gevoeligheid van die informatie)? “Dan heb je het meer over de controle van de gegevens zelf in combinatie met de authenticatie van de gebruiker die toegang wil hebben tot die gegevens en de autorisatie die dat al dan niet zal toestaan. Ik zie niet in hoe PDA’s of smartphones daar een positieve bijdrage in kunnen geven. Ook hier zal de authenticatie persoonsgebonden zijn, waarbij de fysieke locatie meegenomen wordt in het besluit om die persoon uiteindelijk de autorisatie toe te kennen om de betreffende gegevens te manipuleren (inzage, danwel wijziging).” Zijn er authenticatie forwarding protocollen naast Kerberos te verwachten voor applicatieontwikkeling?

“Misschien, of eigenlijk vast wel. Maar waarom zou je een nieuwe oplossing hiervoor ontwikkelen als Kerberos al een zodanige marktpenetratie heeft? Het heeft geen nut iets nieuws te ontwikkelen voor het vervangen van iets dat goed werkt. Er komen wellicht andere oplossingen, maar nodig is het waarschijnlijk niet.” Kerberos kent een zwak tot geen keymanagement. De Microsoft variant kent een PKI ondersteuning voor keymanagement, moet dit dan niet worden opgenomen in een Kerberos 6 standaard? “Kerberos is een keydistributie systeem dat gebruikt wordt voor authenticatie. Het zorgt voor de veilige distributie van deze authenticatiegegevens door gebruik te maken van symmetrische sleutel cryptografie in een client-server netwerk. Deze sleutels zijn opgeslagen in een database en worden gebruikt om sessiesleutels veilig te kunnen transporteren naar de verschillende clients en servers en de andere functies van Kerberos te ondersteunen. De grootste kritieken op Kerberos zijn gelegen in het feit dat Kerberos uitsluitend gebruikmaakt van symmetrische sleutels, waardoor het slecht schaalbaar zou zijn, en dat er een singlepoint-of-failure bestaat, namelijk de KDC (Key Distribution Center). Het laatste probleem is relatief eenvoudig op te lossen door gebruik te maken van verschillende KDCs. Het gebruik van asymmetrische sleutelparen, bijvoorbeeld opgeslagen in een Public Key Infrastructure (PKI), zou het eerdere probleem kunnen oplossen, maar dat is niet zozeer een verbetering van het keymanagement alswel een verbetering van de schaalbaarheid. In het verleden is Kerberos altijd gebruikt in relatief kleine omgevingen waarvoor de performance van Kerberos altijd voldoende was. Microsoft heeft met de .NET passport service Kerberos geïntroduceerd in veel grotere omgevingen waar schaalbaarheid, maar ook performance zeker van belang is. De ondersteuning van asymmetrische sleutels heeft ook een nadeel, namelijk dat de verwerking ervan meer rekenkracht kost. RFC 1510 is al meer dan tien jaar een proposed standard. De IETF (Internet Engineering Task Force) heeft een workgroup die zich bezighoudt met de

verdere ontwikkeling van Kerberos. Het gebruik van public key cryptografie (assymmetrische sleutels) is slechts een van de voorstellen die door deze werkgroep wordt meegenomen in de nieuwe standaard. Een andere belangrijke wijziging die waarschijnlijk zal worden doorgevoerd is natuurlijk de vervanging van het DES (Data Encryption Standard) crypto-algoritme door de nieuwe standaard AES (Advanced Encryption Standard). Het feit dat Microsoft vooruitloopt op deze ontwikkelingen en daarbij gebruikmaakt van velden in het protocol die op dit moment nog niet in gebruik waren, is op zijn minst arrogant te noemen. Kortom; nieuwe versies van de huidige standaard zijn in ontwikkeling. Verbeteringen zijn mogelijk. Andere, nieuwe, protocollen zullen wellicht wel ontwikkeld worden, maar zijn waarschijnlijk overbodig.” Welke toekomstverwachting heb je ten aanzien van het gebruik van PET´s? “De enige echte Privacy Enhanced Technology (PET) die ik ken, is alle technologie overboord gooien. Als men op een bepaald moment bepaalde zaken noodzakelijk acht, en daarna weer techniek moet gaan toevoegen om je privacy te beschermen, wordt het zodanig complex dat er problemen ontstaan. Als je werkelijk wilt dat je privacy beschermd is, pas dan geen technologie toe, maar geef simpelweg je persoonlijke gegevens niet prijs. Maar dat is tegenwoordig jammer genoeg bijna onmogelijk. Het juiste gebruik van sterke cryptografie is dan ook meer en meer noodzakelijk. Wel moet er goed gelet worden op de correcte implementatie ervan. En in dit geval hebben we het ook over de veiligheid van de implementatie. Die is zeker voor deze technologie uiterst belangrijk.” Dus PET’s hebben geen toekomst, het CBP heeft misgeschoten hiermee? “Neen, wat ik zei is dat PET alleen noodzakelijke lapmiddelen zijn om onze persoonlijke gegevens te beschermen zodra deze uit handen gegeven zijn en in de huidige technologische infrastructuur zijn opgeslagen en erdoor worden verwerkt. Blijft staan dat deze technologie, die uitsluitend als doel heeft om onze gegevens te beschermen, foutvrij moet worden

geïmplementeerd. Gezien de ‘puinhoop’ die er regelmatig wordt opgeleverd als we het hebben over administratieve systemen ben ik alleen erg sceptisch.” Zijn er technische standaarden te verwachten voor rule-based access control? “Rule-based access control staat nog in de kinderschoenen. Op dit moment maken veruit de meeste systemen gebruik van een of andere RBAC (Role-based Access Control) implementatie. In theorie zijn de beschikbare producten voor RBAC prachtig; je kunt autorisaties toekennen op diverse niveaus en zorgen dat niet iedereen bij bepaalde gegevens kan komen. In de praktijk is het een drama om een dergelijk systeem in te richten en vervolgens te onderhouden. Het idee is goed, de complexiteit die een organisatie ermee op zijn hals haalt, is enorm. De enige organisaties die ik ken die ermee werken zijn militaire organisaties en sommige overheidsdiensten. In andere organisaties kom ik het weinig tegen; als het er al is wordt het als zeer complex en lastig te beheren ervaren. Role-based is trouwens al een hele stap voorwaarts, omdat je niet per persoon autorisaties hoeft toe te kennen, maar dit per rol kunt doen. Je krijgt daardoor binnen een organisatie een beperkt aantal rollen en een systeem dat regelt dat alleen de juiste rollen bij bepaalde gegevens kunnen komen. Er is dus markt voor deze producten en standaarden zullen er uiteindelijk ook wel verschijnen; maar ontwikkelingen om het echt eenvoudiger te maken ben ik nog niet tegengekomen. Bij Rule-based access control worden de beslissingen om iets of iemand aldan-niet toegang te geven on-the-fly gemaakt, gebaseerd op bepaalde beleidsregels die in scripts zijn vastgelegd. De personen die op dit moment bezig zijn met deze nieuwe ontwikkeling geven veelal aan dat het creëren van deze regels en de security policies (beleid) waarop deze gebaseerd zijn ook niet eenvoudig is. Ook deze ontwikkeling is weer binnen een militaire organisatie begonnen. Het voordeel dat deze organisaties hebben is de stringente hiërarchie die er heerst, waardoor ook deze regels relatief eenvoudig kunnen worden weergegeven.


25 Jubileumnummer

Het bedrijfsleven kent ook wel een hiërarchie, maar in veel gevallen wordt deze niet zo strikt gehanteerd, waardoor de implementatie van deze regels in dit soort omgevingen weer veel complexer worden. Dus voordat we technische standaarden zullen zien zal er eerst nog een hoop werk verzet moeten worden in de opzet van correct beleid en de juiste vertaling van dat beleid in de scripts die dit beleid moeten implementeren.” Is er standaardisatie te verwachten voor autorisatie API’s en interfaces, we hebben nu onder meer SAML, XACML, WS-Security en LDAP. Welke standaard maakt de meeste kans en waarom? “Als ik al iets tegenkom is het LDAP, wat overigens erg flexibel qua inzet en beheer is. Voor standaarden gelden twee regels. Of de standaard die de meeste functionaliteit en de grootste mate van gebruikersvriendelijkheid biedt, gaat het worden, of de standaard waarvoor het meeste marketing wordt aangewend, wordt koploper. In dit geval lijkt LDAP volgens beide regels dé standaard voor de toekomst.” Is beveiliging van single user systemen zoals PDA überhaupt te realiseren als de gebruiker toch alles kan omzeilen, wijzigingen instellingen et cetera. Welke trend verwacht je hierin, krijgen we mobiele apparatuur überhaupt veilig? “Ik verwacht dat deze apparatuur steeds beter beveiligd gaat worden. Er is al een aantal redelijke oplossingen beschikbaar. Het is een kwestie van het direct meeleveren van beveiligingsproducten bij de eerste levering door bedrijven. Zorg dat een PDA is voorzien van sterke encryptie en voed tevens de eindgebruiker op. Daarnaast moet er gekeken worden naar de juiste toepassing van technologie. Op het moment dat je encryptie gaat toepassen, maak je gebruik van sleutels. Deze sleutels moeten op een veilige locatie worden opgeslagen. Op het moment dat sleutels worden opgeslagen op de PDA waar een gebruiker bij kan, dan kan een kwaadwillende daar ook bij. Kortom, de informatie ligt op straat. Dezelfde uitdaging vind je terug bij smartcards. Hier zit ook sleutelinformatie in. Dit is zodanig opgeslagen en verborgen op de smartcard dat je daar

Jubileumnummer

26

zonder specialistische en vooral erg dure apparatuur niet bij kunt. Deze technologie van beveiligen is relatief goedkoop en zal ook moeten worden ingezet voor het beveiligen van sleutels op PDA en smart phones. Er is nog veel werk te verzetten, want deze maatregelen worden nog steeds niet standaard in het product opgenomen. Het huidige alternatief bestaat uit PDA’s die worden beschermd met biometrie. Na een aantal foutieve inlogpogingen wordt het systeem compleet gewist, en de data vernietigd. Dit is een relatief veilige oplossing, mits het systeem niet opengemaakt wordt en het geheugen op een andere manier wordt uitgelezen. Probleem is alleen dat deze techniek de PDA relatief duur maakt. De techniek is dus beschikbaar, maar nog niet breed toegepast op betaalbare commodity producten. Het vreemde blijft dat zodra techniek direct is gekoppeld aan geld er veel energie wordt gestoken in goede beveiliging. Denk hierbij aan de eerder genoemde bankpas. Het beschermen van informatie op de PDA vormt in feite hetzelfde probleem als het beschermen van sleutelinformatie op een bankpas of creditcard, maar de stap om deze goedkope beveiligingstechniek in te zetten voor mobiele devices moet nog worden gemaakt. De trend die ik verwacht is dat het wel die kant op zal gaan; beveiliging van die componenten die direct aan geld gekoppeld zijn, zullen dus worden ingezet om andere informatiebronnen te beschermen.” Kunnen we ooit veilig VLAN´s gebruiken, wat moet daarvoor dan nog ontwikkeld worden? “Het probleem op dit moment met VLAN’s (Virtuele LAN’s) is dat je met voldoende technische kennis de TAG’s kunt manipuleren. Deze TAG’s worden gebruikt om aan te geven op welke VLAN een bepaald datapakket moet worden getransporteerd. Op het moment dat je deze informatie kunt manipuleren, kun je datastromen beïnvloeden. Je laat als het ware een pakket springen van het ene VLAN naar het andere. Als je dit beter wilt beveiligen, dan moet je zorgen dat het dataverkeer niet gemanipuleerd kan worden. Waarschijnlijk kunnen bepaalde cryptografische technieken ook bij dit probleem een oplossing bieden. Op


het moment dat een VLAN een cryptografische tunnel is, wordt een pakket dat springt niet op de juiste wijze gedecodeerd, en wordt het dus uiteindelijk niet geaccepteerd. Overigens is dit, voor zover bekend, nog niet beschikbaar.” Hoe zit dit met het internet? Voor het internet kan met bijvoorbeeld SSH, SSL, of IPSec een veilige tunnel worden opgezet. Wel moet de eindgebruiker ermee om weten te gaan. Als bijvoorbeeld tijdens het opzetten van een SSL sessie met het bedrijf tevens een modemverbinding openstaat met een ander netwerk, en het betreffende systeem staat routering toe dan is communicatie tussen het interne bedrijfsnetwerk en het andere netwerk mogelijk. Een eindgebruiker is zich in veel gevallen van geen gevaar bewust, maar het risico dat hierdoor ontstaat, is natuurlijk aanzienlijk.” Welke ontwikkelingen verwacht je in de technieken die gebruikt gaan worden voor IDS/IPS. Zal er naar signature base IDS ook nog iets komen met abnomaly detectie op basis van gebruik van protocollen? “Het grote verschil tussen IPS en IDS is dat een IPS staat tussen de boze buitenwereld en het gedeelte dat je wilt beschermen. Het kan hierdoor volledig ingrijpen op de communicatie tussen deze gebieden. Een IDS signaleert alleen. Een hybride vorm kan na de detectie van ongewenst verkeer beperkt ingrijpen door een TCP sessie af te breken. Het probleem met IPSen is dat je de bescherming op een verkeerd punt legt. Als je de software goed ontwikkelt, heb je deze maatregelen niet nodig. Een IDS om te signaleren zie ik nog wel zitten, als een soort inbrekersalarm. Maar waar het werkelijk om gaat is de beveiliging van je gegevens. Deze beveilig je goed door de systemen en software daarvoor goed te programmeren. Survivable security is een term die dit goed illustreert. Vooral de systemen waar mensenlevens van afhangen, worden op dit moment goed beveiligd. De software moet correct èn veilig zijn, moet zodanig geprogrammeerd zijn dat als er iets dreigt mis te gaan deze potentiële fout wordt opgelost. Daar is goed over nagedacht. Denk bijvoor-

Hans van de Looy

beeld aan ESA (ruimtevaart), nucleaire installaties, magnetronovens, röntgen, CAT en MRI scanners et cetera. Op het moment dat het om administratieve systemen gaat, wordt deze gedachte ineens verlaten. Het moet functioneren. Er wordt weinig aandacht gegeven aan wat het systeem niet moet doen. Kortom; er ontstaan per definitie onveilige systemen. Hierdoor is veel inzet van beveiligingsproducten noodzakelijk. IPS en IDS systemen kunnen wellicht helpen, maar het is niet de juiste benadering, en zeker niet de juiste plek. Een IDS heeft nog wel nut, denk aan het inbrekersalarm. Je wordt geattendeerd dat er iemand probeert binnen te dringen. Een IPS is als term een hype; fabrikanten, leveranciers en klanten lopen daar achteraan. De enige juiste ontwikkeling moet zijn dat je de veiligheid op de juist plekken moet leggen. Zo is het IPS het bekende doekje voor het bloeden. Het bloeden is dat administratieve ontwikkelaars blijkbaar niet weten hoe ze veilige software moeten schrijven. Het wordt tijd dat op de opleidingen, hogescholen en universiteiten, voldoende aandacht wordt gegeven aan

het ontwikkelen van veilige en defensieve software, aanvullend op de al aanwezige aandacht voor correcte software ontwikkeling. Hier moet het beginnen, want al die beveiligingsmaatregelen als virusscanners en IPS et cetera zijn uitsluitend nodig om de gevolgen van slecht ontwikkelde software te compenseren. Waarom hebben we antivirus nodig: omdat er zoveel slechte software wordt ontwikkeld. Als je werkelijk iets wilt oplossen moet je het aanpakken; dus ontwikkel software op de juiste manier.” Maar hiermee kun je niet voorkomen dat mensen software verspreiden, lees virussen, die iets op je systeem installeren, zelfs met goede software kun je niet voorkomen dat de mens het attachment accepteert! “Dat klopt. Maar waar ligt nu de initiële fout? Bij mensen die virussen verspreiden of bij diegenen die attachments zonder blikken of blozen accepteren? Of bij het feit dat bepaalde programmatuur onveilig is geïmplementeerd? Ik denk duidelijk bij het laatste. Mensen gebruiken hun verstand maar ten dele. Dat zie je zowel

bij de verspreiders van virussen, maar zeker ook bij de personen die willekeurige attachments zonder meer openen. Diezelfde personen gebruiken slechts 2 tot 5 procent van de mogelijkheden van hun tekstverwerker of spreadsheet. De onveilige delen van die programmatuur zouden dus slechts zelden gemist worden en kunnen waarschijnlijk ook op een andere, veilige, manier worden geïmplementeerd. Je voorkomt dus niet de gevolgen, maar pakt juist de oorzaken aan! Zorg ervoor dat werkelijk onveilige handelingen alleen met moeite kunnen worden uitgevoerd. Alleen daardoor zorg je uiteindelijk voor een veilige omgeving. Kijk maar naar een willekeurige chemische installatie. Daar moet je echt moeite doen om iets potentieel onveiligs voor elkaar te krijgen. Omdat daarover wordt nagedacht. Het opeenstapelen van lapmiddelen zorgt er uitsluitend voor dat er een nog complexere omgeving ontstaat waardoor het risico dat er nog meer mis kan gaan, op manieren die je eerst niet voor mogelijk had gehouden, alleen maar toeneemt. Daar moeten we vanaf.”


27 Jubileumnummer

Welke van de firewall, IDS/IPS en antivirus technieken hebben dan nog nut? “Een firewall is prima. Zo kan de ergste rommel buiten de deur worden gehouden en kan het interne netwerk ook andere services ter beschikking stellen die niet voor iedereen toegankelijk hoeven te zijn. Een IDS heeft ook nut omdat deze mij attendeert op bepaalde zaken waar ik rekening mee dacht te houden, maar mij toch bedreigen. Het inbrekersalarm. Verder moet het systeem dat de gegevens bevat en verwerkt goed worden geprogrammeerd. Er moeten dus geen buffer overflows inzitten, geen macro’s die misbruikt kunnen worden, geen additionele functionaliteit die we niet nodig hebben. Op dit moment zien de we omgekeerde wereld. We hebben een tekstverwerker die qua functionaliteit mogelijkheden aanbiedt waar vrijwel niemand op zit te wachten. Daarnaast zijn er veel programma’s die functioneel gezien doen wat er wordt verwacht, maar die tevens vol met programmeerfouten zitten. Dit komt omdat men niet netjes programmeert. Men let niet op wat er fout kan gaan. We creëren daarom meerdere layers of defense om deze systemen heen. Veel beveiligingsmaatregelen zijn bedacht om dergelijke fouten tegen te gaan, te compenseren. De industrie heeft anti-spam oplossingen bedacht, omdat er nog steeds geen fatsoenlijk systeem wordt ingezet waarmee individuele mensen (die op enige wijze elektronisch willen communiceren) geïdentificeerd kunnen worden. Er wordt tegenwoordig zelfs HTML e-mail gebruikt. Hierdoor zien de mensen een bepaalde versie van de werkelijkheid, terwijl er onder water een compleet andere versie kan worden verwerkt. Denk aan het relatief nieuwe phishing probleem. Met alle gevolgen van dien. Hier helpt geen firewall tegen, geen IPS, geen anti-virus programma, geen spam-filter. Allemaal lapmiddelen en oplossingen op de verkeerde plek. Meer dan vijfentwintig jaar geleden is mij geleerd dat complexiteit juist zaken onveiliger maakt. Maar wat doen we; we maken de systemen om ons te beschermen alleen maar complexer, door laag op laag te stapelen omdat we de kern niet goed beheersen. En dus zijn we per definitie onveiliger. Zorg er nu voor dat we de oorzaken van de problemen aanpakken en verder dat we op onwenselijke situ-

Jubileumnummer

28

aties attent worden gemaakt waardoor we er adequaat op kunnen reageren. Alleen dan zijn we werkelijk goed bezig om het probleem op te lossen.” Zijn er standaarden in ontwikkeling die het mogelijk maken om systemen van verschillende IDS-IPS leveranciers op elkaar af te stemmen? Is dan correlatie mogelijk in de toekomst en kunnen we dan inderdaad preventie automatisch laten uitvoeren? “Leuk en aardig. In dit geval krijg je dan dat bepaalde onderdelen die men levert op elkaar worden afgestemd. Als je niet uitkijkt, word je compleet afhankelijk van één bepaalde leverancier. Dit is puur marketing gedreven. Het is ook maar de vraag of leveranciers willen toestaan dat informatie uit allerlei verschillende systemen met elkaar gecombineerd worden tot een eenduidig overzicht. Computer Associates is een van de bedrijven die al eerder producten heeft gelanceerd om een integraal overzicht te krijgen van verschillende producten, maar veel kom ik deze cockpits niet tegen. Het gevaar is ook dat een dergelijk hoog niveau van overzicht genereren vanuit vele verschillende apparaten niet eenvoudig is en dus fouten kan opleveren. Hierdoor kan dan weer een vals gevoel van veiligheid ontstaan. Als je echt kritisch kijkt, moet je de systemen zo eenvoudig mogelijk houden en dus is dit uiteindelijk ook weer een stap in de verkeerde richting. Automatisch preventie laten uitvoeren is met de huidige complexiteit vergelijkbaar met het automatisch laten besturen van een auto in Rome. Dit is vragen om een catastrofe.” Welke standaarden zijn in ontwikkeling of moeten ontwikkeld worden om een eenduidige naamgeving voor virussen (malicious code in z´n algemeen) te krijgen zodat we producten daadwerkelijk kunnen vergelijken? “Die is er al enigszins. Het moet verder uitkristalliseren. De vraag is of je dit echt wilt. Je hebt virussen, wormen en wat dies meer zij aan digitaal ongedierte. Deze maken in feite allemaal gebruik van fouten in software. Wat doen we er vervolgens aan? We houden een industrie levend om de initiële fouten op te sporen, en daarna het virus te detecteren en in het beste geval het virus onschadelijk te maken.


Natuurlijk zal er altijd iets bestaan van enige wedloop tussen dreigingen en tegenmaatregelen. Denk aan defensie, de bekende wapenwedloop. In de fysieke wereld wapenen we ons tegen virussen door ons immuun te maken tegen deze virussen. Dit zou ook moeten gebeuren met onze software. Terug naar de bekende tekstverwerker; de inzet van bepaalde macro’s zal dan bijvoorbeeld niet meer mogelijk zijn, en alleen die zaken die echt nodig zijn blijven beschikbaar. Het besef om veilige software te ontwikkelen, komt gelukkig een beetje op. Maar hogescholen en universiteiten hebben nog een lange weg te gaan.” Is de techniek volwassen genoeg om inhoud van berichtenverkeer te kunnen controleren. Welke ontwikkelingen (bijvoorbeeld in het kader van de WBP) zijn er technisch te verwachten? “Het ligt eraan hoe je het bekijkt. Wat virus detectie betreft is het redelijk uitontwikkeld. Een virus is dan ook relatief eenvoudig te detecteren. Eenmaal bekend moet het signature worden verspreid en kan de scanner aan het werk. Kijk je naar SPAM, dan zijn we een eind op dreef, maar er kan nog veel worden ontwikkeld. De natuurlijke taal analyseren om met hoge zekerheid te bepalen of een bericht wel of niet als SPAM geïdentificeerd moet worden, is een uitdaging voor de komende periode.” Er is behoefte aan een algemene logging standaard zodat we vanuit allerlei systemen informatie kunnen verzamelen en correleren. Er is nu nog geen technische standaard, welke verwachting heb je hiervoor? “Logging is prima. Dat er geen standaard is, klopt niet helemaal. Er is bijvoorbeeld syslog, een standaard uit de UNIX wereld. Deze kan zowel lokaal loggen als naar een centrale logserver informatie wegschrijven. Er zijn zelfs ontwikkelingen gaande om dit via een secure kanaal te doen, dus een secure syslog. Je ziet wel vaker dat standaarden ontwikkeld in de UNIX community uiteindelijk in de rest van de wereld (op andere platformen zoals Windows, OS/390, VAX VMS) ook een defacto standaard worden. Denk aan TCP/IP, aan Kerberos, SMTP, HTTP, SNMP, en allerlei andere protocollen waar we bijna dagelijks mee te maken hebben.”

Wordt de kwaliteit van beveiligingsproducten beter, of lopen ze net als software achteruit door de hoeveelheid code en complexiteit? “Klopt, en is eigenlijk al eerder in dit gesprek aan de orde geweest. We lopen achter de zaken aan, laten ons beïnvloeden door hypes en richten daardoor onze aandacht op de verkeerde zaken.” Welke skills zijn er in de toekomst nodig voor applicatiebouwers? “Zorg ervoor dat je netjes programmeert, en leer van je fouten. Houd rekening met de zwakheden van de programmeertaal die je gebruikt. Je weet dat als je C gebruikt en je geen rekening houdt met de lengte van je buffers, je te maken krijgt met buffer overflows, omdat de compiler hier geen controles voor toevoegt. Elke programmeur moet hier dus zelf iets voor regelen. Let tevens goed op het afvangen van foutsituaties. Dit gebeurt in vrijwel geen van de gevallen. Er worden bijvoorbeeld systemcalls naar het besturingsysteem geprogrammeerd, en daarna wordt er volledig vanuitgegaan dat de zaken goed worden afgehandeld. Dit hoeft helemaal niet het geval te zijn. In moderne programmeertalen wordt er veel aandacht gegeven aan het asynchroon afvangen van fouten. Je hoeft het niet meer volledig in de logica zelf te programmeren, maar er zitten standaard een aantal afvangmogelijkheden in de taal gebakken. Je moet deze als programmeur wel toepassen. Het wordt de ontwikkelaar gemakkelijker gemaakt, maar toch wordt het niet of in elk geval onvoldoende gebruikt. De bijsturing is ook nog onvoldoende. Het credo is dat er te weinig geld is voor opleidingen en dus wordt er te weinig aandacht besteed aan dit soort triviale zaken. Mensen die in de industrie terechtkomen, moeten snel geld opleveren. Software ontwikkelen moet ook allemaal snel. Complexiteit in combinatie met snel ontwikkelen van slechte code is absoluut killing voor security.” Draadloze communicatie maakt nog steeds een enorme opmars binnen vooral thuisgebruikers. Bedrijven staan nog niet echt te springen. Waar eindigt dit? Is het überhaupt veilig te maken; bijvoorbeeld met WPA? Gaan

de bedrijven volgend jaar massaal om of zal de afwachtende houding aanblijven? “WPA is een subset van 802.11i. Het is een interim oplossing, maar wel een heel goede stap in de juiste richting. Het maakt gebruik van protocollen die veel beter in elkaar zijn gezet. Ook TKIP was al een stapje vooruit. Wel hebben cryptologen hun twijfel over TKIP. De juiste en volledige toepassing van WPA lijkt beter.”

Wat vind je van RFID (Radio Frequency Identification)? Gaat dit een belangrijke rol in de toekomst spelen voor wat betreft veilige draadloze communicatie? Denk aan toepassingen binnen identity management en het traceren van assets binnen organisaties. Heeft RFID werkelijk potentieel naar de toekomst gezien? Kortom, moeten organisaties in Nederland hier serieus naar kijken: RFID als de security solution? “Zeker, het is goedkoop en eenvoudig te integreren in beveiligingsoplossingen. Wel moet je de ethische kant van het verhaal goed in de gaten houden. De handel en wandel van een individu kan tot op details worden vastgelegd als dit soort identificatiemogelijkheden te pas en te onpas gebruikt worden.” Tot slot: welke technische beveiligingfunctionaliteit mis je in het huidige aanbod in de markt? “Er is eerder een teveel aan beveiligingsproducten beschikbaar; het aanbod is veel te groot. De beveiligingsproblemen moeten op het juiste niveau worden aangepakt. Ontwikkel dus correcte en veilige software. Als je een boomhut bouwt, dan denk je ook

na over een goed stuk stevigheid van de ondersteunende balken. Anders donder je uit de boom. Je moet beveiligingsvraagstukken goed doordenken. Het werken met architecturen helpt, maar moet worden toegepast op de juiste manier en op het juiste niveau. Een forse security architectuur voor een mkb beveiligingsprobleem is waarschijnlijk overkill. Er mist dus niet veel. Het werkelijke probleem is dat er aan de basis nog teveel fouten worden gemaakt. Correcte en veilige ontwikkeling van software, netjes programmeren vormt de crux. Er valt helaas nog veel werk te verzetten. Tot die tijd zullen we zeker veel personen, bedrijven en instellingen zien die telkens opnieuw achter de volgende hype aan blijven lopen, IPSen kopen en elk attachment openen zonder er bij na te denken. Daarnaast zien we gelukkig vaker dat mensen beginnen met nadeken over het werkelijke probleem en daar een eenvoudige en doorzichtige oplossing voor vinden. Simpliciteit heeft als voordeel dat als er al een fout wordt gemaakt deze direct opvalt of in ieder geval eenvoudig kan worden opgespoord. Door complexe software op een veilige manier te configureren wordt de kans dat er per ongeluk iets misgaat al aanzienlijk kleiner gemaakt (zelfs Microsoft heeft dit recentelijk doorgekregen en gebruikt dit nu als het nieuwe credo). Denk hierbij bijvoorbeeld aan het niet automatisch laten uitvoeren van macro’s. Het blijven natuurlijk allemaal lapmiddelen en het overstappen naar veiliger varianten is natuurlijk de enige juiste oplossing. Maar voordat de mensheid niet alleen correcte software kan ontwikkelen, maar ook nog voor een veilige implementatie kan zorgen, zou volgens sommige optimisten nog wel eens 5 tot 10 jaar voorbij kunnen gaan. Daarnaast zal elk systeem, hoe goed en veilig het ook is gemaakt altijd kwetsbaar blijven voor misbruik door mensen. Dus alles wat we uit het verleden over beveiligen hebben geleerd, zullen we ook in de toekomst moeten blijven toepassen. Laten we dan ook niet in de val van schijnveiligheid trappen door er vanuit te gaan dat controle kan worden uitgevoerd door techniek. Juist hier blijft de flexibiliteit, de kennis en het inzicht van mensen vooralsnog noodzakelijk.”


29 Jubileumnummer

het doekje voor het bloeden

Recommend Documents