Doel van onze weblog

juni 27, 2006

Hoe dient een organisatie procedureel en technisch ingericht te worden, om in geval van (het vermoeden van) een misdrijf de aanwezige digitale sporen als toelaatbare juridische bewijslast te kunnen laten dienen.

Advertenties

Outsourcen van Forensische Expertise

juni 25, 2006

Bij het inrichten van de betaalapplicatie zijn veel uitgangspunten en voorwaarden genoemd waardoor het uitvoeren van forensisch onderzoek in geval van fraude of andere genoemde misdrijven vergemakkelijkt kan worden. De vragen die daarbij ook spelen zijn of dit technisch wel haalbaar is en of de kosten die daaraan zitten niet te hoog zullen zijn.

Een ander vraag is of een organisatie zelf wel genoeg expertise heeft om forensisch onderzoek uit te voeren. Is een systeembeheer, na het volgen van een opleiding, een forensisch expert? Kan een systeembeheerder toelaatbaar bewijsmateriaal veilig stellen?

Tegenwoordig is het een trend om je ICT te outsourcen, dus waarom zou je niet de stap zetten om te denken aan het outsourcen van Forensische Expertise?

Bij het outsourcen van Forensische Expertise kun je als organisatie afspraken maken over wat verwacht wordt in geval van fraude of misbruik. Daarnaast kan het outsourcen kostentechnisch voordeel opleveren op het gebied van opsporing van mogelijke fraude en vervolging en kun je zeker stellen dat forensisch onderzoek wordt uitgevoerd door experts, die op de hoogte zijn van de laatste technische en juridische ontwikkelingen.

De verwachting van de experts is dat het outsourcen van Forensische Expertise een nieuwe trend zal worden in de komende jaren. Maar of zij gelijk gaan krijgen???


Geen local admins etc..

juni 25, 2006

De thin client oplossing van Sacha is een goed voorstel. Alhoewel deze ook geplaatst had kunnen worden onder de categorie Technische inrichting werkstations. Daar hebben we het immers over het hardenen van werkstations, met de thin client oplossing kunnen we ons met dat hardenen misschien beperken. Maar beheer enerzijds en technische inrichting anderzijds zijn natuurlijk onlosmakelijk met elkaar verbonden.

Het beheer van werkstations blijft wel een punt. Door wie en hoe worden de werkstations initieel ingericht, opgeleverd en nadien onderhouden en beheerd? Bij het beheer van netwerkcomponenten is een lijst opgenomen waaraan beheer en beheerders moeten voldoen. Deze zelfde lijst is ook voor werkstations van toepassing. Een aanvullende eis wil ik daar nog expliciet aan toevoegen en dat is dat voor werkstations, waarop onze betaalapplicatie operationeel is, geen local admins of iets dergelijks zijn gedefinieerd. Gewone gebruikers moeten van het werkstation gebruik kunnen maken met de daarvoor aangewezen gebruikersfunctionaliteit maar mogen nooit beheeracties op dit werkstation uitvoeren of op de een of andere wijze instellingen kunnen wijzigen. Dat is voorbehouden aan beheerders die daarvoor zijn aangewezen en die voldoen aan de opgesomde maatregelen.

Als gebruikers zelf de technische instellingen van een werkstation zouden kunnen beinvloeden, dan kunnen de digitale sporen, voorzover die daarop aanwezig zijn, nooit als juridische bewijslast dienen.


Te stellen eisen aan het beheer

juni 25, 2006

Het beheer moet aan eisen voldoen, zodat in geval van een rechtszaak de verkeersgegevens van deze componenten, juridisch worden geaccepteerd. Dat veronderstelt in ieder geval een "zorgvuldig" beheer.

Maar wat houdt dat dan in?

  • In ieder geval dient het aantal beheerders zeer beperkt te zijn, een aangewezen beheerder en eventueel een vervanger.
  • De beheerders dienen voor de betreffende component voldoende te zijn opgeleid, eventueel gecertificeerd.
  • De beheerders tekenen een code of conduct, waarin onder meer geheimhouding is meegenomen.
  • Beheerders zijn gescreened: er is minimaal een verklaring van goed gedrag overlegd bij indiensttreding.
  • Ten behoeve van het beheer is een goed gedocumenteerde beheerdersmanual beschikbaar. Het beheer, zoals dat daarin omschreven staat, dient te gebeuren conform leveranciersvoorschriften.
  • Ik wil niet zeggen dat beheer ITIL-gewijs moet zijn ingericht maar change -, configuration -, incident en problem management moeten in ieder geval voldoende zijn uitgewerkt. De desbetreffende component beschikt over een uniek CI en komt met volledige omschrijving voor in een configuration database. Iedere change of incident met betrekking tot deze CI wordt vastgelegd en procedureel afgehandeld. Etc..
  • De toegang tot de component moet voldoende zijn afgeschermd zodat alleen de aangewezen beheerder toegang kan krijgen en instellingen kan wijzigen.
  • In geval van vakantie en ziekte kunnen overige beheerders toegang verkrijgen door middel van bijv. een envelopprocedure. Een envellop die bij hoofd Operations wordt bewaard en die wachtwoord of toegangscode bevat, voor voorkomende noodgevallen. Deze procedure voorziet er natuurlijk ook in dat alle noodgebruik wordt vastgelegd en dat na gebruik het wachtwoord wordt gewijzigd.
  • Alle beheerderacties worden door de beheerders zelf vastgelegd en omschreven. Maar ook technisch worden alle uitgevoerde beheerderacties gelogd (deze log is overigens natuurlijk niet manipuleerbaar) zodat achteraf controleerbaar is wie wat wanneer heeft gedaan.
  • Beheerders zijn overigens goed op de hoogte (hiervoor beschikken zij over schriftelijke instructies) van de geldende incident management procedures. Dat betekent dat zij in geval van een incident precies weten wat van hen verwacht wordt, met name hoe zij verkeersgegevens veilig moeten stellen.

Dit is een eerste opzet van een lijst maatregelen waaraan

  1. het beheer en
  2. beheerders

moeten voldoen. In de vakliteratuur, met name bij organisaties als Norea etc. is nog veel meer hierover te vinden.

Vast staat dat beheer zorgvuldig moet zijn ingericht zodat in geval van bewijsvoering de digitale sporen als bewijs kunnen dienen en het tevens aannemelijk is dat het beheer zodanig is ingericht dat er met de desbetreffende component niet is "geknoeid".


Beheer werkstations

juni 24, 2006

Bij het gebruik van een betaalapplicatie kun je het netwerk op diverse manieren inrichten. Echter door het gebruik van een thin client oplossing wordt het beheer van de werkstations in het netwerk mijns inziens aanzienlijk vergemakkelijkt.

De keuze voor deze oplossing betekent dat gegevens op de server benaderd worden vanaf het werkstation, maar de gegevens worden echter niet op het werkstation verwerkt of opgeslagen. Dit betekent dat men zich bij het verzamelen van digitale sporen kan richten op de gegevens op de server. Dit betekent dan natuurlijk wel dat de beveiliging en het beheer van de server zo is ingericht dat men de digitale sporen en bewijzen kan veilig stellen.

Identificatie en authenticatie zullen in deze oplossing een belangrijke rol spelen. De inrichting van identificatie en authenticatie is onder de categorie toegangsbeveiliging verder uitgewerkt.


Sterke authenticatie

juni 23, 2006

Toegangsbeveiliging moet zodanig worden ingericht dat onomstotelijk vaststaat dat de onder een bepaald account uitgevoerde handelingen ook daadwerkelijk zijn gedaan door de eigenaar van dat account. Het gaat hierbij vooral om logische toegangsbeveiliging, daartoe zal ik me ook verder beperken. Logische toegangsbeveiliging omvat 3 zaken:

  • identificatie: het kenbaar maken van de identiteit van personen

  • authenticatie: verifiëren of de persoon die zich kenbaar maakt ook betreffende persoon is

  • autorisatie: het toekennen van rechten aan een persoon.

 Normenkaders en standaards waaraan logische toegangsbeveiliging moet voldoen zijn er in overvloed te vinden. Vooral bij organisaties als Norea, GVIB, ISACA, PI etc.. Maar welke van deze normenkaders hebben het predikaat echt een door alle relevante partijen geaccepteerde standaard te zijn. Een standaard die, als wij logische toegangsbeveiliging overeenkomstig hebben ingericht, in geval van een rechtszaak overeind blijft en niet ter discussie wordt gesteld. Ik ben deze nog niet tegengekomen. Voor de betaalapplicatie waar wij het in onze opdracht steeds over hebben zal iets van “sterke authenticatie” geregeld moeten zijn. In de praktijk wordt een onderscheid gemaakt tussen zwakke en sterke authenticatie. Zwakke authenticatie is het controleren van de identiteit door middel van bijvoorbeeld een wachtwoord. Sterke authenticatie is identiteitscontrole door een combinatie van iets wat men bezit met iets dat men weet: een wachtwoord of pincode. Het bekendste voorbeeld hiervan is natuurlijk de pinpas. Toegang tot een kritische betaalapplicatie zal men alleen mogen verkrijgen op basis van sterke authenticatie, in ieder geval meer dan alleen maar aanloggen door middel van userid en wachtwoord (los van het feit of dat een sterk of zwak wachtwoord mechanisme is). Hierbij moeten we vooral denken aan biometrische of smartcard oplossingen. Biometrie staat nog veel ter discussie en wordt vaak nog als onbetrouwbaar ervaren. Smartcardoplossingen zijn er zat, maar welke hiervan zijn gecertificeerd? Of hebben in ieder geval de status dat ze getest zijn door een voldoende onafhankelijke partij en het predikaat hebben dat de log ervan als juridische bewijslast zou kunnen dienen? Dat kom ik in mijn zoektocht nog niet tegen. Nergens is bijvoorbeeld bepaald dat als TNO een dergelijke smartcard oplossing zou hebben getest en goed bevonden, dat dan ook goed genoeg is voor juristen. 

Waar het in ieder geval om gaat is dat wij niet alleen maar kunnen volstaan met het achteraf bewijzen van misbruik van een betaalapplicatie. Ook vooral zullen wij er voldoende aan moeten doen om er voor te zorgen dat alleen geauthenticeerde en geautoriseerde personen toegang krijgen tot de applicatie en functies daarbinnen. En dat we er vervolgens op moeten kunnen vertrouwen dat iedere uitgevoerde handeling eenduidig herleidbaar is naar de account die is ingelogd. Sterke authenticatie hoort daar in ieder geval in de een of andere vorm bij.


Gang van zaken in geval van een incident (2)

juni 22, 2006

Binnen Security Incident Management zullen ook een aantal processen moeten worden ingericht om de benodigde forensische informatie te verzamelen, te onderzoeken en veilig te stellen. 

Nadat door de organisatie is vastgesteld met betrekking tot welke incidenten we forensische informatie willen verzamelen (in ons geval misbruik, (ongebruikelijke/ongeautoriseerde) wijziging van gegevens of een stoornis in de betaalapplicatie), moet worden vastgesteld hoe de gegevens veilig moeten worden gesteld en wie deze gegevens veilig moet gaan stellen. Wordt een forensisch team ingesteld, voert de systeembeheerder de forensische taken uit? 

Het incidentproces begint bij de detectie van een incident. Johan stelt dat het voor het detecteren van incidenten procedureel niet vastgelegd kan worden. Detectie is echter van groot belang in het incidentproces. Het ontwikkelen van awareness met betrekking tot incidenten bij de medewerkers is dan ook van groot belang. Procedureel kun je dus wel vastleggen dat medewerkers getraind zullen worden op beveiligingsbewustzijn en het detecteren/herkennen van incidenten. 

Na het detecteren en melden van een incident zal de Security Incident Manager de ernst van het incident moeten bepalen, in dit geval of er sprake is van een zwaar beveiligingsincident. Hierbij wordt tevens bepaald of forensisch onderzoek noodzakelijk is en moet worden ingesteld. 

Het beleid en procedures rond het forensisch onderzoek, het veilig stellen van het bewijs en het overdragen van bewijs moeten duidelijk worden vastgelegd. Johan heeft een aantal belangrijke punten met betrekking tot het beleid en de procedures al deels uiteengezet. De organisatie moet er in ieder geval voor waken dat het onderzochte en vastgelegde forensische informatie toelaatbaar is als geldig bewijs alvorens men over gaat tot juridische stappen.

Naast het voorkomen van zware beveiligingsincidenten is het ook belangrijk van incidenten te leren. Beveiligingsincidenten dienen geëvalueerd te worden en indien nodig dienen maatregelen genomen te worden om de dergelijke incidenten in de toekomst te voorkomen. De gegevens met betrekking tot deze incidenten dienen daarom gedocumenteerd te worden in een kennisbank.


Gang van zaken in geval van een incident

juni 20, 2006

Security Incident Management is een proces dat een aantal procedures/werkwijzes moet omvatten. Het moet voorzien in het volgende:

Het detecteren van misbruik kan in principe door iedereen gebeuren. Dat kan een systeembeheerder zijn, maar ook een willekeurige medewerker. De wijze waarop iets wordt gedetecteerd kan ook verschillen; de systeembeheerder achterhaalt misbruik door het beoordelen van logging, een willekeurige collega ziet iemand achter een pc zitten die daar niet thuishoort of ziet iemand een applicatie gebruiken die normaal voor anderen bedoeld is. Voor het detecteren kan dan ook niets procedureels worden vastgelegd; dit moeten we gewoon vrij laten en iedereen die denkt iets te detecteren moet dat vooral doen.

Het aanmelden is een ander verhaal. Voor het aanmelden van een incident dient in de organisatie incident management te zijn ingericht. Iedere medewerker dient op de hoogte te zijn van dat proces, of moet bijv. via intranet kunnen achterhalen, hoe het aanmelden van een incident dient te verlopen (betrokken afdelingen, email, telefoonnummer, etc.). Zo dient het incident na melding ook een uniek incidentnummer te krijgen en te worden vastgelegd in een incidentendatabase.

Bij het vastleggen van het incident maken we onderscheid naar gewone incidenten en beveiligingsincidenten. Beveiligingsincidenten kunnen weer worden onderscheiden naar gewone beveiligingsincidenten (bijv. een user reset) en zware beveiligingsincidenten. Fraude en misbruik van onze betaalapplicatie horen bijv. in deze laatste categorie thuis.

In het geval van zware beveiligingsincidenten treedt een bijzondere procedure in werking, de hoe kan het ook anders "zware beveiligingsincidentprocedure".

Dit betekent dat

  • de verantwoordelijke lijnmanager wordt ingelicht
  • deze de betreffende persoon op het matje roept en vooralsnog even op nonactief stelt
  • deze persoon wordt dan ook voorlopig de toegang tot het bedrijf ontzegt, dus inleveren toegangsbadge
  • een freeze van het betrokken werkstation plaatsvindt door onder meer het werkstation te isoleren in een afgesloten ruimte, een kopie image van de harde schijf en daar over heen een hash, het veiligstellen van logs van de betaalapplicatie
  • verkeersgegevens (internet en email) van de betreffende persoon worden vastgelegd
  • het account/id van de betreffende persoon voorlopig wordt geblokkeerd, zodat er voor deze geen toegang meer is tot ICT van de organisatie, ook niet vanuit een thuiswerkplek
  • indien aanwezig wordt de compliance officer geinformeerd
  • Personeelszaken op de hoogte wordt gebracht
  • Juridische Zaken op de hoogte wordt gebracht
  • Juridische Zaken zal indien nodig en tzt justitie inschakelen, daarvoor is meestal één vaste aangewezen persoon in de organisatie.

Voorts wordt er in de organisatie natuurlijk niet over deze casus gepraat; voor iedereen die betrokken is geldt geheimhouding; dit zal ook worden gevraagd aan degeen die het incident initieel heeft aangemeld.

De hele gang van zaken in deze procedure, zoals beschreven, moet achteraf controleerbaar en traceerbaar zijn. Dat betekent dat alles goed en uitvoerig gedocumenteerd moet worden:

  • achteraf moet bijv. vastgesteld kunnen worden dat de betreffende medewerker op tijdstip x op nonactief is gesteld; dat kan door de medewerker dit mondeling mede te delen en daar een schriftelijke verklaring aan toe te voegen
  • achteraf moet vastgesteld kunnen worden op welk moment door Juridische Zaken met justitie contact is opgenomen, wie dat heeft gedaan, wie het aanspreekpunt bij justitie was, welke materiaal daarbij is overhandigd etc.
  • achteraf moet vastgesteld kunnen worden wanneer het incident is gemeld, door wie, en wat het incident nummer is etc.

De hele gang van zaken dient volgens een vaste procedure te verlopen. Communicatielijnen en rollen dienen daarin helder te zijn, een ieder weet exact van hem/haar verwacht wordt.

Als dat vooraf zo kan worden ingericht, dan zijn we een heel eind op weg met security incident management.


Misbruik van onze betaalapplicatie (2)

juni 16, 2006

Naast het door Johan beschreven misbruik van de betaalapplicatie, waarbij hij met name ingaat op de wetgeving in artikel 138a WvSr,  kan er ook sprake zijn van het opzettelijk veroorzaken van een stoornis in de betaalapplicatie waardoor betalingen beschadigd raken, onbruikbaar gemaakt of vernietigd worden. Dit kan schade opleveren voor het bedrijf zelf, maar ook voor de andere betrokken bedrijven of bancaire instellingen.  

Het opzettelijk veroorzaken van stoornis in een geautomatiseerd werk wordt in principe strafbaar gesteld in artikel 161sexies WvSr. Probleem hierbij is echter dat deze wet alleen van toepassing is indien er sprake is van een computersysteem dat dient ten algemene nutte welke iedereen ten dienste staat.

De conclusie moet dan ook zijn dat we het in het geval van de betaalapplicatie doorgaand hebben over een computersysteem dat binnen een organisatie gebruikt wordt en daarmee kan dit dus niet onder artikel 161sexies WvSr als strafbaar feit worden gezien. 

Vervolgens kan er ook nog sprake zijn van het onbruikbaar maken of veranderen van gegevens in de betaalapplicatie. Het veranderen van gegevens is strafbaar gesteld in de artikelen 350a (met schuld) en 350b (met opzet) WvSr. Deze artikelen beschermen het ongestoorde gebruik van computergegevens tegen onder meer onbevoegde verandering of het ontoegankelijk maken van die gegevens. 

In zowel artikel 350a als 350b WvSr worden twee gedragingen strafbaar gesteld:  

  • Het vernielen en veranderen van gegevens, en 
  • Het ter beschikking stellen en verspreiden van gegevens die bedoeld zijn om schade aan te richten door zichzelf te vermenigvuldigen in een geautomatiseerd werk. 

Criteria voor strafbaarstelling van het onbruikbaar maken of veranderen van gegevens:

  1. Er moet sprake zijn van gegevens.
  2. De gegevens zijn door middel van een geautomatiseerd werk opgeslagen, worden verwerkt of worden overgedragen.
  3. De gegevens worden opzettelijk en wederrechtelijk veranderd,  gewist, onbruikbaar of ontoegankelijk gemaakt, dan wel
  4. Er worden opzettelijk andere gegevens aan toegevoegd. 

Criteria voor strafbaarstelling van het verspreiden van gegevens die schade aan kunnen richten:

  1. Het opzettelijk en wederrechtelijk ter beschikking stellen of verspreiden van gegevens die bedoeld zijn om schade aan te richten.
  2. De gegevens richten schade aan door zichzelf te vermenigvuldigen in een geautomatiseerd werk. 

Conclusie is dat het onbruikbaar maken of veranderen van gegevens en het verspreiden van gegevens in de betaalapplicatie die schade aan kunnen richten, gezien kan worden als een strafbaar feit op basis van artikel 350a en 350b WvSr.


Misbruik van onze betaalapplicatie

juni 15, 2006

Sacha en ik zijn het er inmiddels over eens geworden dat we als uitgangspunt in deze blog nemen het bewijzen van misbruik van een betaalapplicatie.

Maar wat is dan misbruik? En als we al weten wat misbruik is, is er dan sprake van een strafbaar feit? Vooral niet gehinderd door enige juridische kennis zal ik proberen hier iets over te schrijven.

De betaalapplicatie is bedoeld voor het doen van betalingen van het bedrijf naar andere rekeninghouders, zijnde banken of bedrijven. In geval van normaal gebruik is er sprake van geautoriseerde betalingen, dwz dat in opdracht van het bedrijf door iemand, die daarvoor is aangewezen, een bepaalde betaling van het bedrijf naar een andere bank of bedrijf wordt gedaan, daarbij is er sprake van een bepaald overeengekomen bedrag en een bepaald en goedgekeurd rekeningnummer.

Misbruik houdt dan in dat de applicatie wordt gebruikt door iemand die niet daarvoor is aangewezen (en bevoegd) of dat betalingen worden gedaan waarvoor geen opdracht door het bedrijf is gegeven: bedragen die niet juist zijn en/of die worden overgeboekt naar rekeningen die niet juist zijn.

Maar is dat dan strafbaar?

De applicatie wordt gebruikt door iemand die daartoe niet is bevoegd. Hij zal dan normaal niet over de logische toegangsrechten daarvoor beschikken, maar op de een of andere manier heeft hij zich wel toegang weten te verschaffen tot de applicatie. Hier is sprake van een strafbaar feit, want er is volgens CC II sprake van computervredebreuk: hij die opzettelijk en wederrechtelijk binnendringt in een geautomatiseerd werk of in een deel daarvan. Van binnendringen is in ieder geval sprake van indien de toegang tot het werk wordt verworven

  • door het doorbreken van een beveiliging
  • door een technische ingreep
  • mbv valse signalen of een valse sleutel
  • door het aannemen van een valse hoedanigheid.

De applicatie wordt gebruikt door iemand die daartoe is bevoegd. Hij zal dan normaal over de logische toegangsrechten voor gebruik van de applicatie beschikken. Alleen heeft hij een niet door het bedrijf geautoriseerde betaling gedaan, een betaling waarvoor het bedrijf géén opdracht heeft gegeven: bedrag niet juist of rekeningnummer niet juist. Is hier sprake van een strafbaar feit? In ieder geval niet van computervredebreuk, want er is op normale wijze toegang verkregen tot de applicatie. Maar er is natuurlijk wel sprake van oplichting/diefstal. Misschien zelfs van valsheid in geschrifte indien de gedane betaling is ondertekend namens “het bedrijf” hetgeen bij deze ongeautoriseerde betaling niet het geval is.

In beide gevallen zal er dus, denk ik, sprake zijn van een strafbaar feit.