Samenvatting in 1 zin

juni 27, 2006

Op juridisch acceptabele wijze integer digitaal bewijs verzamelen gebruik makend van identiteit en authenticiteit.


Trigger, constraints, and result

juni 25, 2006

Dit gedeelte gaat primair over het verzamelen van bewijs. Dit is dus de tweede stap in “the Journey from Computer to Courtroom1.”

Trigger

In mijn vorige post gaf ik al aan dat er op technisch vlak triggers kunnen zijn om een forensisch onderzoek te starten. In dat geval ging het om een technische gebeurtenis die aanleiding geeft tot het starten van het onderzoek. Maar er kunnen natuurlijk ook niet-technische triggers zijn. Het kan zijn dat er bijvoorbeeld fraude of verduistering is ontdekt en dat er electronisch bewijs nodig is om dat te staven. Ik wil er nu echter niet verder op ingaan gezien de eerder bepaalde probleemstelling (zie https://johnbart.wordpress.com/2006/05/31/vergaring-van-digitaal-bewijs-binnen-de-kaders-van-de-wet/)

Note: In beide scenario's moeten de al verzamelde gegevens snel en goed gefilterd kunnen worden op voor het onderzoek relevante gegevens.

Constraints

    Gegevens moeten zo verzameld zijn dat deze (of een gefilterde deelverzameling daarvan) bruikbaar zijn in een rechtszaak, op een wijze die acceptabel is voor de rechter. Met andere woorden, is er sprake van wettig en overtuigend bewijs (art. 338-344a, WvS)?

  • De integriteit van de gegevens moet vaststaan. Dat betekent dat de gegevens niet, per ongeluk noch opzettelijk, veranderd mogen zijn. Om dat onomstotelijk te kunnen vaststellen worden de gegevens (bijvoorbeeld) dagelijks of tweemaal daags gekopieerd naar een ander medium/bestand, er wordt een hash of een digitale handtekening over die hoeveelheid gegevens berekend en de gegevens + hash/handtekening worden in een database opgeslagen. Om vast te stellen dat de kopie van de gegevens identiek is aan de originele gegevens, wordt over de originele gegevens tegelijkertijd een hash/handtekening berekend die gelijk moet zijn aan de hash/handtekening van de kopie. De uitkomst van de vergelijking wordt met de kopie-gegevens bewaard.
  • De gegevens moeten zodanig beveiligd worden dat deze niet gewijzigd kunnen worden in de periode tussen het kopiëren en dat iedere poging daartoe geregistreerd wordt. Er kan ook voor worden gekozen om logs en dergelijke tegelijkertijd naar verschillende media weg te schrijven zodat de zekerheid dat logs juist zijn groter is.
  • De integriteit van het opslagmedium voor de verzamelde gegevens moet worden gewaarborgd. Het systeem zal dus aantoonbaar goed beveiligd moeten zijn (naar de stand der techniek of beter?).
  • De herkomst van de gegevens moet vast staan. Dit is een vorm van identificatie/authenticatie. Ten dele kan dat worden bereikt door een goede procesbeschrijving op te stellen, waarin in ieder geval duidelijk wordt aangegeven welke gegevens worden verzameld (van welke hosts, op welk netwerk segment, etc.) en hoe dat wordt gedaan. Anderzijds kunnen devices met behulp van certificaten toegang krijgen tot andere devices. Ten eerste kan de host die gegevens verzamelt (HdDV) zichzelf zo authenticeren aan de host waarop gegevens worden verzameld (HwDV) Ten tweede kan de HdDV zonder twijfel2 vast stellen wie de HwDV is.
  • De verzamelde gegevens moeten hanteerbaar zijn. Het verzamelen van gegevens heeft alleen nut als op een vrij eenvoudige wijze relevante informatie kan worden geproduceerd, die ook nog aantoonbaar “juist” is. “Juist” betekent hier dat is voldaan aan de eisen van integriteit en authenticiteit van de gegevens, en dat bij het bewerken van de gegevens om relevante informatie te verkrijgen geen interferentie3 is opgetreden of, als er wel interferentie is opgetreden, dat bekend is wat die interferentie is.
  • Het verzamelen van gegevens en eventueel genereren van bewijs mag geen (of slechts weinig) invloed hebben op het functioneren van de business. Dit kan worden uitgesplitst in technische en niet-technische elementen:
    • De impact op systeem performance mag niet groot zijn. Dit kan worden bereikt door het verzamelen van gegevens op tijden te doen, waarop de systemen niet of weinig worden gebruikt.
    • De impact op (technische) resources, zoals opslagcapaciteit, mag niet onoverkomelijk zijn. Er kan bijvoorbeeld voor worden gekozen om slechts een gedeelte van alle gegevens te bewaren of een combinatie met het al gebruikte backup systeem te creëren (waarbij dan waarschijnlijk wel aanpassingen nodig zijn om aan bovenstaande eisen te kunnen voldoen).
    • Systemen om gegevens te verzamelen moeten qua aanschaf- en onderhoudskosten normaal zijn en binnen een goedkeurbaar budget passen. Het opzetten van een PKI zal daarbij een flinke drempel zijn.
    • Systemen om relevante informatie te genereren moeten qua aanschaf- en onderhoudskosten normaal zijn en binnen een goedkeurbaar budget passen.
    • Wie de systemen wanneer mag gebruiken moet aan stricte regels zijn onderworpen, omdat privacy gevoelige informatie verwerkt wordt. Wellicht moet dit van te voren worden aangemeld. Het aanstellen van een privacy-functionaris is hierbij ook een mogelijkheid.
    • Het gebruik van systemen om relevante informatie te genereren moet niet onnodig ingewikkeld en tijdrovend zijn. De benodigde personele resources moeten binnen de perken blijven.
    • Er moet redelijke zekerheid zijn dat de toegepaste methode en technieken voldoende zijn om wettig en overtuigend bewijs te leveren. Er zal daarom vooraf toetsing moeten plaatsvinden door justitiële autoriteiten. Een door de betrokken partijen getekende verklaring kan worden uitgegeven die het resultaat van de toetsing beschrijft en het kader waarbinnen de toetsing is gedaan aangeeft. De toetsing moet een regelmatig terugkerende gebeurtenis zijn.
    • Als de business grensoverschrijdend is (levering in het buitenland en/of buitenlandse vestigingen) moeten wetten en regels in de betreffende landen ook in aanmerking worden genomen en moet daar wellicht ook toetsing plaatsvinden.
    • Toetsing moet plaatsvinden met betrekking tot wet- en regelgeving aangaande privacy (WBP), met name voor situaties waarin de gegevens worden verwerkt tot informatie, omdat daarbij een koppeling kan ontstaan tussen de gegevens en personen (zie ook punt 1. Privacy in https://johnbart.wordpress.com/2006/06/19/uitwerking-randvoorwaarden/).

Result

Als met bovenstaande constraints rekening is gehouden, kan wettig en overtuigend bewijs worden overlegd aan de justitiële autoriteiten. Bij het overdragen van de informatie wordt een procesbeschrijving en eventueel bestaande documentatie meegeleverd, zodat de rechter kan zien hoe het bewijs is verzameld en verifiëren dat het voldoet aan de eisen die de wet stelt.

Als het framework eenmaal is opgezet kan op betrekkelijk eenvoudige en betrouwbare wijze (“druk op de knop”) het bewijs worden geleverd. Veranderende omstandigheden zoals wijzigingen in de infrastructuur en wijzigingen in de wet- en regelgeving zullen wijzigingen in de methode en technieken vereisen, maar het framework hoeft niet dramatisch te worden aangepast.

1Zie: Ch. 4.9 uit “Handbook of Legislative Procedures of Computer and Network Misuse in EU Countries” by RAND Europe, 2003

2Dit vereist het gebruik van een goed opgezette PKI

3Interferentie is wijziging van de gegevens ten gevolge van het bewerken.


Blueprint & Framework

juni 23, 2006

De “Blueprint” richt zich op een aanvulling op een IAM-systeem, zodat de informatie die er in zit direct bruikbaar is in geval van een forensisch onderzoek. Het framework dat ik eerder heb aangegeven zou hier een rol kunnen spelen:

  • het IAM-systeem kan zodanig worden opgezet dat de integriteit van de data gewaarborgd is. Dit kan bijvoorbeeld bereikt worden door het digitaal signeren van alle data en log files binnen het IAM-systeem. Daarvoor zou je een PKI op kunnen zetten, zodat de digitale handtekening verifieerbaar is. Als alternatief kan een product als Tripwire worden gebruikt. Tripwire detecteert alle veranderingen aan bestanden en geeft aan of de veranderingen geauthoriseerd zijn.
  • De data en log files worden periodiek gekopieerd naar een read-only device. Met behulp van bijvoorbeeld de PKI omgeving wordt vastgesteld dat de kopie exact is. Ook software als EnCase kan hierbij van dienst zijn; hiermee kunnen images worden gemaakt.
  • Ter verificatie kunnen meerdere kopieën worden gemaakt, zodat vaststaat dat het proces herhaalbaar is. Dit kan in een pilot fase worden gedaan om aan te tonen dat het proces bij herhaling hetzelfde resultaat geeft.
  • Zorg ervoor dat identificatie en authenticatie gegevens deel uitmaken van de verzamelde data; dit ligt echter voor de hand bij een IAM-systeem
  • Een pilot fase kan uitwijzen of periodiek kopieren van alle data beheersbaar is. Als dat niet het geval is moet een keuze worden gemaakt welke data van belang kan/zal zijn.

Verder wordt het IAM-systeem geïnstalleerd op servers met een gehardened OS, zodat erop inbreken vrijwel onmogelijk wordt.

Trigger:

Een Intrusion Detection systeem kan worden gebruikt om pogingen tot inbraak te detecteren. Als alternatief (of tevens) kan een programma als NetWitness trends in kaart brengen, zodat anomalieën in het netwerkverkeer gemakkelijk worden gezien en kunnen worden bestreden. Van te voren wordt vastgesteld bij welke grenswaarde sprake is van een mogelijke trigger die een vooronderzoek van de al verzamelde data rechtvaardigt.

TripWire kan zo worden ingesteld dat bij bepaalde veranderingen een alert wordt gegeven.


Voorzet Blueprint

juni 22, 2006

Enige drang tot concretiseren lijkt mij zinvol. Gelukkig zie ik dat ook bij Joseph en Alf.

Zelf wil ik komen tot een opdracht voor een aanvulling op een IAM-systeem waartoe een “Blueprint” moet worden opgesteld. Uiteraard is hiervoor budget benodigd en die zou ik willen verkrijgen middels ’n volgend document gericht aan het topmanagement waarvan de opbouw de volgende is:

 

– Probleemstelling en doel,

– Onderbouwing naar topmanagement

– Verzoek voor budget met een globale kostenindicatie voor het opstellen van de blueprint (waarin globaal de totale kosten worden aangegeven),

– De functionele eisen waaraan het systeem moet voldoen

– Randvoorwaarden

– Aantoonbaar maken van betrouwbaarheid van de bewijsvoering 

 

Een aanzet tot uitwerking van dit rapport

Probleemstelling en doel: hiervan is al veel te vinden en te “lenen” bij de zuster-weblogs)

Onderbouwing naar topmanagement

De kern van de onderbouwing is:

  • het in controle zijn en het aan kunnen tonen daarvan (de wetgeving stelt hier steeds meer eisen aan: b.v. Tabaksblat en Sox)
  • het minder tijdrovende en verstorende zijn van het verzamelen van bewijslast
  • de efficiëntie en effectiviteit van de bewijslast. 
  • de preventieve werking die van dit systeem uitgaat (de medewerkers moeten ervoor tekenen dat zij weten en dat zij toestemming verlenen dat bepaalde gegevens over hun handelen worden vastgelegd)

– Verzoek voor budget voor een blueprint

De bleuprint moet worden gezien als een eerste verkenning om na te gaan of het beoogde doel realiseerbaar, werkbaar en betaalbaar is. Uiteraard dient een kostenindicatie voor deze eerste fase worden gegeven. Het topmanagement moet duidelijk gemaakt worden dat na deze eerste fases een beslismoment komt om al dan niet door te gaan. Het is dan ook van belang in de blueprint een reële inschatting wordt gemaakt van de totale kosten. Om deze inschatting te maken zullen de hieronder aangeven functionele en technische eisen moeten worden uitgewerkt en zonodig aangevuld.

De functionele eisen waaraan het systeem moet voldoen

  • de vast te leggen gegevens (van personen de rollen, de autorisaties, de toegang tot systemen, gebouwen, specifieke ruimtes, netwerk (lokaal en remote), op welke tijdstippen toegang is verkregen en gebruik is gemaakt van de autorisaties, email is verzonden en ontvangen
  • de eenduidige relatie tot natuurlijk persoon (voor fysieke toegang dient een ieder gebruikt te maken van een geregistreerde batch, voor bij het gebruik van een “financieel, personeels- of klantsysteem of een ander vertrouwelijk systeem dient naast het wachtwoord men zich te authenticeren met een harde token.
  • Uiteraard functionele eisen m.b.t. rapportage van de gegevens, de wijze waarop en toegangsbeveiliging hiervan.

Randvoorwaarden

  • Juridische voorwaarden: inmiddels al heel veel bij de zuster WEBlogs en in deze weblog te vinden. Maar ook de melding hiervan bij het college van de WBP.
  • Technische randvoorwaarden (integriteit van de data, de toegangbeveiliging tot deze data, de continuitietseisen aan het systeem, incl. backup en recovery, encryptie toepassen, patchmanagement, relasemanagement, hoe de opslag van de data is geregeld
  • Voorwaarden wederzijdse erkenning van de lidstaten (zie Evonne en Ralph)
  • Voorwaarden bij gebruik: specifieke procedures (wie, wat en wanneer toegang tot deze gegevens, 4-ogen principe), de medewerker laten tekenen dat zij weten en dat zij toestemming verlenen dat bepaalde gegevens over hun handelen worden vastgelegd, afspraken maken met OR, bewaartermijnen vaststellen

Aantoonbaar maken van betrouwbaarheid van de bewijsvoering 

  • vastleggen dat voldaan is aan de relevante wetgeving
  • vastleggen dat voldaan is aan de huidige stand van techniek v.w.b. authenticatie,  beveiliging (vertrouwelijkheid en integriteit), systeemeisen, functiescheiding
  • het toepassen van cross-systemen: als voorbeeld de koppelingen met het systeem voor de fysieke toegang: indien je niet met je id-card toegang hebt verkregen tot een kantoor (dus niet als “aanwezig” de het systeem bent geregistreerd), krijg je geen toegang tot het interne datacom-netwerk. Dit draagt bij aan de volledigheid van de aanwezigheidsregistratie (als je niet bent aangemeld kan je niet werken) en aan de beveiliging van het netwerk (wireless werken vanaf buiten het kantoor is niet mogelijk).

Framework

juni 21, 2006

Framework

Voor het opzetten van een framework dat het mogelijk maakt forensische data met de druk op een knop te genereren is het nodig dat:

1. de integriteit van de data gewaarborgd is

2. de verzamelde data gegarandeerd een een op een kopie van de originele data is, maar dat als een een op een kopie niet mogelijk blijkt, tenminste precies bekend is welke veranderingen hebben plaatsgevonden.
3. dat het verzamelen van de data een herhaalbaar proces is

4. dat identificatie en authenticatie gegevens deel uitmaken van de verzamelde data

5. dat de hoeveelheid verzamelde data geoptimaliseerd is (niet te weinig, maar ook niet te veel)


Uitwerking randvoorwaarden

juni 19, 2006

1. Privacy

Bij het vergaren van gegevens moet rekening worden gehouden met beperkingen die de Wet Bescherming Persoonsgegevens (WBP) oplegt.

Om er maar een paar te noemen:

  1. Wanneer is er sprake van persoonsgegevens?

Bij het verzamelen van electronische sporen uit logging en audit trails van een IAM systeem zal er sprake zijn van een koppeling van IP gegevens en identiteit. In het IAM systeem bevat de identiteit mogelijk bijzondere persoonsgegevens waarbij voor de verwerking daarvan mogelijk ondubbelzinnige toestemming van de betrokkene nodig is. Kan die toestemming vooraf al worden verkregen bijvooreeld door werknemers een verklaring te laten tekenen?

  1. Volgens artikel 7 worden persoonsgegevens voor welbepaalde, uitdrukkelijk omschreven en gerechtvaardigde doeleinden verzameld (doelbinding), verder uitgewerkt in Art. 9.
  2. Volgens Artikel 8c moet de gegevensverwerking noodzakelijk zijn voor het nakomen van een wettelijke verplichting waaraan de verantwoordelijke onderworpen is (gerechtvaardiging))
  3. In artikel 10 wordt de bewaartermijn gelimiteerd.
  4. In artikel 11 worden eisen gesteld aan de redenen waarvoor persoonsgegevns worden verzameld.
  5. Hoe ga je om met de verplichting betrokkenen te informeren dat er gegevens worden verzameld en wat doe met het recht op inzage? Is er een manier om de informatie te anoniem te maken en toch indien nodig te herleiden tot een persoon?

Waarschijnlijk moet een forensisch syteem dat gegevens verzameld dus op voorhand al worden aangemeld bij het CBP.

2. Opsporingsbevoegdheden en vereisten

Het verzamelen van gegevens heeft tot doel bewijsmateriaal aan te leveren dat als geldig bewijs kan dienen zonder dat er een expert aan te pas hoeft te komen (documentary vs. supporting evidence).

Wetboek van Strafvordering (inbeslagneming, doorzoeking, doorzoeking ter vastlegging van gegevens, vorderen van gegevens, …)

De rechter stelt vast welk bewijs toelaatbaar is en wat de bewijskracht is. Art 2.10 lid 4 BW staat toe dat geschriften op elektronische wijze bewaard worden, mits aan een aantal voorwaarden is voldaan.

Forensische principes

Waarom forensics? Wat is eigenlijk het proces dat plaatsvindt? Volgens mij zijn er drie elementen, n.l. trigger, constraints en result.

  1. Trigger: er gebeurt iets waardoor een onderzoek wordt gestart om bewijs te verzamelen
  2. Constraints: er zijn voorwaarden die aan het onderzoek worden gesteld, zoals de wet, beschikbare tijd, beschikbare mankracht, beschikbare onderzoekstijd (minimale downtime)
  3. Result: er komt een onderzoeksresultaat. Dit bewijs moet juridisch waterdicht zijn, voldoen aan de wettelijke eisen en toelaatbaar zijn in een rechtzaak

Bij het verzamelen van bewijs is het van belang ervoor te zorgen dat de bewijsgaring verloopt zoals dat bij een politieonderzoek (dat volgens de regels wordt gedaan) gebeurt. Alle gegevens die er al zijn (access logs, e.d.) moeten bewaard worden zodanig dat vast staat dat ze accuraat en ongewijzigd zijn (time stamping, hashing, ttp, pki) en dat bovendien de bewaarde gegevens te managen zijn (duration of log keeping, size of logs).

Een van de belangrijkste items is wellicht up-to-date documentatie. Zodat onomstotelijk komt vast te staan welke data of welk device is gecompromitteerd. En welke plaats het heeft in het netwerk. Of de data / het device kan worden geisoleerd.

Een andere vraag is in hoeverre het verzamelen van bewijs herhaalbaar is of invloed heeft op de omgeving zelf, m.a.w. door het verzamelen en opslaan van bewijs verandert de omgeving. Is die dan nog wel representatief? Of binnen welke grenzen is die nog representatief?


juni 7, 2006

Inmiddels is al veel te vinden bij de “zuster” weblogs over de juridische eisen waaraan het gewenste systeem, zal moeten voldoen. Zie bijvoorbeeld de weblog van Evonne en Ralph (werknaam voor een dergelijk systeem: Digital Evidence Collector), en die van Coen, Gertjan en Martin. En over de technische security eisen waaraan het systeem moet voldoen om vertrouwen van integriteit te wekken (weblog van Johan en Sacha). Zelf vind ik dieper spitten in die richting, althans op dit moment, niet effectief. Het lijkt me zinvol om voorzichtig een aanzet te maken tot een ideevorming over het systeem. 

 

Aanzet tot clustering van eisen:

         Welke gegevens zijn nodig, wat mag en wat mag niet juridisch gezien worden verzameld; de voorwaarden waaronder het verzameld mag worden (zoals melding bij college WBP, bekend stellen onder personeel,…….)

         Vertrouwen in systeem: certificering (PKI), allerlei technische integriteiteisen (back-up en recovery-procedures, beveiliging tegen inbraak, , redundantie, standarisatie); functiescheiding bij beheerders goede autorisatieprocedures,…………….

         Hoe wordt een eenduidig de relatie met een natuurlijk persoon vastgelegd; altijd aanloggen met biometrie (wat je bent) of is een wachtwoord (wat je weet) in combinatie met een RSA-token (wat je hebt) voldoende?

         Hoe krijg ik mijn topmanagement zo ver dat zij hieraan geld uit geeft, welke drives heeft zij nodig: wettelijke verplichtingen, cover your arch ? Binnen 5 jaar meer rechtszaken ter verantwoording over onvoldoende/ niet adequate maatregelen?

         ????

          

Gegevens:

Er zijn vele misdrijven van stalking tot informatiediefstal, maar waar meestal de drive zit is  eigen gewin, geld dus. Als voorbeeld een financieel systeem. De gegevens die in eerste instantie een bijdrage leveren tot selecteren van een of meerdere verdachten zijn die gegevens waaruit je kan afleiden wie waartoe toegang heeft, welke autorisaties zijn toegekend, welke handelingen zijn verricht en op welk moment. Uiteraard zij, indien er meerdere personen bij  betrokken zijn, de communicatie en/of communicatie-patronen behulpzaam.

De relatie, althans voor een relevant deel van de gewenste gegevens, ligt voor de hand met een “ Identity en een Role based Access managementsysteem”.  In een dergelijk systeem wordt bijgehouden, wie welke rollen heeft waartoe zij geautoriseerd zijn en hoe zij zich dienen te authenticeren. Je kan o.a. verplicht stellen dat een ieder die met een financieel systeem werkt, zich met bijv. een RSA-secure-id token moet authentificeren. De systemen houden loggings bij welke user-id’s wat en op welke tijdstip hebben gedaan. Ook aan deze loggings worden dan de eisen gesteld om aan de benodigde integriteit te voldoen.

Te denken valt daarnaast aan cross-controles zoals eerder beschreven met systemen voor de fysieke aanwezigheid of remote access.   

 

Wordt vervolgd