Hallo Arnoud,

Je zou een tool moeten hebben die als een soort guard over de database gelegd kan worden en waarin je rules kan vastleggen wat iemand wel en niet mag doen en waarin logs worden bijgehouden wat er gebeurt en actie wordt ondernomen wanneer een rule wordt overschreden b.v. bij het copieren van data uit de database de sessie stoppen of een gedetailleerde trace aanzetten. Eigen personeel kan de guard niet bedienen of uitzetten zodat deze niet gemanipuleerd kan worden...

Ten tweede zul je de beveiliging van je systeem moeten loskoppelen van het beheer van je systeem........het digitale politiebureau (lijkt me wel een mooie business case !!)

Ik vind "afdoende" ook een beetje een vreemd begrip. Afdoende is mijn inziens niet alleen een maatregel is die de stand der techniek weerspiegelt, maar ook dat het financieel verantwoord moet zijn. Stel je hebt een extranet achtige oplossing voor 10 klanten die een omzet genereren van 20.000 per jaar op een totale bedrijfsomzet van 2 miljoen, ga je daar duizenden euro's aan beveiligings technieken aanhangen? Volgens de wet zou je dat moeten doen, want de techniek is er. Het enige wat zo'n bedrijf kan doen is wat basis maatregelen nemen zoals SSL en bij het laten ontwikkelen van de webapp extra investeren in het testen van security.

Daarnaast denk ik dat je de oorzaak van veel lekken kunt vinden in drie categorieen:

- De onwetende: Programmeurs die zichzelf programmeren eigen hebben gemaakt, of ze hebben het wel geleerd maar in een tijdperk dat security er niet toe deed. Hierdoor zijn security best practices niet bekend of van geen waarde voor hen.

- De manager/tijdsdruk: Tijd voor veel testen is er niet, want tijd kost geld.

- Product aansprakelijkheid op software: Deze hangt samen met bovenstaande. Omdat er wettelijk geen product aansprakelijkheid is op software, spenderen bedrijven minder geld en tijd aan security. Sterker nog, als een lek gevonden wordt, bijvoorbeeld bij een pentest, dan kunnen ze nog meer cashen omdat ze dan de lekken mogen dichten!
Zodra er product aansprakelijkheid is op software gaat er meer tijd en geld naar security en denk ik dat je al een deel van het probleem opgelost hebt.

Nu het antwoord op de vraag:
Je kunt als bedrijf niet meer doen dan best practices aanhouden, zoals sterke wachtwoorden, alle gebruikers input en output (xss) valideren en vervolgens alleen indekken. Documenteren wat je hebt gedaan aan security, en wat je procedures zijn.

Just my two cents...

Ehm... Je kan bij MySQL toch de database connecties beperken vanaf bepaalde hostnames/IPs? Stel, database server adres is "databeest.openbsd.cc", dan kan ik instellen dat `ie alleen connecties toestaat vanaf "websurfer.openbsd.cc", is dat geen redelijke oplossing? Ik kan je zo niet uit mijn hoofd vertellen hoe je dat kan configureren, maar een zoekopdracht doet wonderen ;)

je kunt er de "de stand der techniek" op loslaten, maar mensen zijn altijd in staat deze techniek te omzeilen, zeker de mensen die de techniek bedienen.

De overheid heeft in mijn optiek de plicht om bedrijven regelmatig op de hoogte te houden over de do's and dont's op dit gebied, en een gepaste straf bij overtreding lijkt me ook op zijn plaats.
Niet achter gesloten deuren een paar miljoen boete uitschrijven, maar met een paginagrote advertentie en een google-ad met je billen bloot.

De waarde van databases,en hun ongekende mogelijkheden overstijgen vaak de boete die je kunt krijgen door deze te misbruiken, en bedrijven nemen dit risico gewoon mee in de businesscase.

Zendoptimizer installeren, en alle php files met de mysql wachtwoorden coderen met php guard.
Enkel admin rechten geven aan de database. Gebruikers die toegang hebben tot bepaalde gegevens documenten laten tekenen.
En verder logfiles geregeld nakijken.

Wat hij zegt :-)

Coderen, loggen en versleutelen.

PCI DSS bij de hand houden en je boeren verstand gebruiken. Helaas zijn er geen duidelijke richtlijnen die je kunt aanhouden, al helpen de richtlijnen, die de markt zelf opgesteld heeft: pci-dss, BS7799 etc. : http://www.17799central.com/iso17799.htm

Het grote probleem is dat dit (de regels van de WBP om de boel moeten beveiligen) net zo open staan ter interpretatie als de nieuwe uitbreiding op de telecomwet (dataretentie). De techniek gaat sneller dan de wetgeving maar de wetgevende partij gaat wel eisen stellen, daar waar er niets (goed) omschreven is.

hallo Arnoud,
Het volgende onderdeel in jou vraag wekte voornamelijk mijn interesse

.

Hetvolgende is een onpraktische, maar volgens de letter van de wet zeer correcte manier van aanpakken. (volgens mij dan toch).

De kans bestaat dat een systeembeheerder, of iemand met directe toegang tot de database de informatie kan inzien en zo inbreuk plegen op de wet. Om dit gedrag, noem het maar het "god syndroom", te verhelpen kan de data in de database versleuteld worden opgeslagen. In dit geval kan er op twee manieren worden gewerkt, enerzijds met een universele sleutel of anders met een persoonlijke sleutel. (zie ook wat verder) Nadeel van het geëncrypteerd opslagen van data is dat er geen bewerkingen meer mogelijk zijn met de gegevens. (zo is het natuurlijk zeer moeilijk om gecodeerde velden alfabetisch te rangschikken. Daarom kan men opteren om enkel de echt persoonlijke gegevens te coderen, en de gegevens die bedoeld zijn om statistisch te verwerken ongecodeerd te laten. Hierdoor kan de database zijn functionaliteit behouden en worden persoonlijke gegevens toch beschermd.

als voorbeeld:
VOORNAAM -- ACHTERNAAM -- STRAAT -- AANTAL BEZOEKEN
jos -- verbeke -- antwerpsesteenweg -- 232
[ENCRYPTED] -- verbeke -- [ENCRYPTED] -- 232


de universele sleutel methode mist zijn doel wanneer deze het encryptie - algoritme als een functie bij in de database zit. Het moet gecompiled toegevoegd worden aan alle applicaties (ASP, PHP, word, ect...) die data uit de database moeten halen (liefst met een gelogde handshake). Nadeel is een de encryptie gebroken is is er geen bescherming meer en reverse engeneering op het extern encryptie algortime maakt dit best moglijk.

de individuele sleutel methode zorgt ervoor dat iedere encryptie anders is opgebouwd en dat de data beter beveiligd is. De sleutel (bv rijksregisternummer) blijft bij de persoon zelf (eventueel in een koekje). Nadeel is hiervan is dan weer dat gegevens niet intern in het bedrijf ontsleuteld kunnen worden. De data kan enkel nog worden opgevraagd door contact op te nemen en de sleutel daadwerkelijk te vragen aan de persoon in kwestie. (dit maakt het geheel dan weer vatbaar voor social hacks, maar op inbreuken op grote schaal worden zeer moeilijk.)

Het toepassen van een gemengde vorm is in bepaalde gevallen nog een betere oplossing. De universele sleutel wordt gebruikt voor gegevens die nodig zijn voor de interne functies binnen de organisatie (bv email adressen zodat mailings kunnen verzonden worden). Individuele sleutels worden behouden veer echt vertrouwelijke informatie.

In beide gevallen is het natuurlijk vanzelfsprekend dat het om een de sleutel niet veranderd over een verloop van tijd. Het upgraden van het sleutelalgoritme wil ook zeggen dat heel de database herschreven moet worden.

@H2os: categorie 4: interne medewerkers die nieuwsgierig zijn of slechte medoelingen hebben.

Een van de dingen die me altijd opvallen, is dat web applicaties vaak meer data vasthouden dan nodig is. Een goed security policy beleid moet imho ook inhouden dat niet meer nodige data worden geschoond, en dat ontwikkelaars er altijd bij stilstaan "wat heb ik nou minimaal nodig voor de functionaliteit" - en dan ook niet meer dan het minimaal noodzakelijke bewaren. Bijvoorbeeld: om afstanden te berekenen, kun je volstaan met een postcode zonder huisnummer; dat zal wat minder nauwkeurig zijn, maar security-wise prima. Of je kiest ervoor om bij een webshop het afleveradres elke keer aan de gebruiker te vragen, in plaats van het eindeloos te bewaren. Na verzending (plus zeg een week of vier voor 't geval dat een klant ontevreden is) voor wordt het adres gewist uit de database. Kortom, wat er niet is, kan ook niet openbaar worden.

Of een ander real-life voorbeeld: inloggen op security.nl gebeurt mbv. je e-mail adres en een wachtwoord. Ongetwijfeld komt een boel e-mail adressen op straat te liggen als de database van security.nl eens wordt gekraakt. Via brute forcing zijn de wachtwoorden ongetwijfeld ook snel te kraken. Stel dat dat onacceptabel was, dan zou je per gebruiker in de database een hash kunnen opslaan van e-mail adres en wachtwoord (achter elkaar geconcateneerd). Bij inloggen zou de gebruiker zijn velden invullen, de app zou dit hashen, en vergelijken met wat in de database staat. Dan log je wel of niet aan; maar in de database staat gewoon het e-mail adres niet, en ook niet een (gecrypt) wachtwoord. In dit voorbeeld "bestaat" het plaintext e-mail adres en het wachtwoord alleen tijdelijk, totdat je inlogt. Je verliest met deze aanpak wellicht de functionaliteit dat de site je een nieuw wachtwoord kan mailen, maar so what - dan meld je je toch gewoon nog een keer aan met een ander wachtwoord? Heb je een nieuw account, werkt ook. Ik zou zelf veel liever hebben dat een site uitlegt dat vergeten wachtwoorden onherstelbaar zijn vanwege security-overwegingen (omdat de site zelf die data ook niet heeft!) dan dat mijn e-mail adres en wachtwoord in een door mij onbeheerde database staan waarbij ik niet weet hoe goed of slecht de security is geregeld.

Qua privacy en security is het gebruik van trapdoor-functies (hashing) een prima uitkomst. Zo verbaast het mij ook nog altijd dat webshops mijn creditcard nummer kennen na maar 1 bezoekje. Kennelijk slaan ze het op, en toveren 't weer tevoorschijn zodra ik bij hun site aanlog. Waarom slaan ze niet een hash op van de string voorletter/achternaam/kaartnummer/vervaldatum, en communiceren met de bank mbv. die hash? De bank zou met de hash pas mijn naam en creditcard nummer kunnen terugzoeken. Ook hier geld voor de webshop: wat je niet hebt, kun je niet kwijtraken. Security-wise een goed idee, want het aantal plekken waar mijn naam en creditcard nummer voorkomen, wordt gereduceerd tot 1 instantie - de bank. Alle webshops vallen af. (En ja, ik weet dat hash-collisies mogelijk zijn. Bij SHA512 is de kans uitermate klein, en er zijn manieren om collisies te voorkomen. Technisch kan 't allemaal.)

Maar goed, allemaal leuke ideeen, maar het betekent wel er meer geinvesteerd zou moeten worden in web apps die security-wise goed in mekaar steken. En ik begrijp ook wel dat apps onder stress worden ontwikkeld, en dat er geen tijd/budget is voor verfraaiingen. Iemand (overheid?) zou stringente eisen moeten opstellen om apps aan dit soort criteria te toetsen; want "afdoende beveiliging tegen misbruik" is natuurlijk veel te vaag en een mager doekje voor 't bloeden.

IS het niet verstandig om gewoon heel de database te versleutelen met bijv truecrypt.
Okee als je in de database bent dan helpt het niet maar het voorkomt het stukje data diefstal door de schijf te jatten al.
Daarnaast alleen info opslaan die hoogst noodzakelijk is.
Van deze hoogst noodzakelijke gegevens de gevaarlijke gegevens like CC gegevens encrypten met een key per persoon die in een aparte file of database word bewaard.
Verders je site beschermen tegen SQL en XSS flaws enz.
Daarnaast je cage/rack en je server fysiek beschermen.
Je database server op een andere server ook met encryptie enz.
Je database alleen benaderbaar via je webserver.
Geen ftp verkeer maar scp en ssh.

"Ik vind "afdoende" ook een beetje een vreemd begrip. Afdoende is mijn inziens niet alleen een maatregel is die de stand der techniek weerspiegelt, maar ook dat het financieel verantwoord moet zijn. Stel je hebt een extranet achtige oplossing voor 10 klanten die een omzet genereren van 20.000 per jaar op een totale bedrijfsomzet van 2 miljoen, ga je daar duizenden euro's aan beveiligings technieken aanhangen? Volgens de wet zou je dat moeten doen, want de techniek is er."

De wet zegt helemaal niet dat je dat moet doen. Afdoende is een subjectieve term, en er wordt helemaal niet aangegeven hoe zwak of sterk de maatregelen dienen te zijn. Je kunt dus kiezen voor hele simpele beveiliging, of dure en complexe systemen. De rechter is geen pentester die gaat kijken of hij je beveiliging kan kraken ;)

@Anoniem 15:24: de rechter gaat inderdaad niet testen. De rechter komt pas in beeld als de beveiliging al gekraakt is en iemand een schadeclaim indient met het verwijt dat je niet afdoende beveiligd hebt. En dan laten beide partijen een deskundige opdraven om te bepalen of de beveiliging up-to-date was of niet.

Perfectie is trouwens niet nodig; het moet afdoende zijn voor het soort gegevens. Een lijstje met e-mailadressen voor een nieuwsbrief hoef je niet met drie encryptieslagen en 3 master keys op smartcards te beveiligen. Patiëntgegevens wellicht wel.

Iedereen bedankt voor de reacties tot zover. Het zijn allemaal goede tips, maar wel heel uiteenlopend. Er zijn dus maar weinig algemene regels over beveiligen van dit soort gevoelige informatie.

Een paar maatregelen die ik zeker zou voorstellen
1. Goede functiescheiding binnen de organisatie bewerkstelligen
2. Functiescheiding implementeren in een autorisatiemodel
3. Logging van alle toegangspogingen tot gegevens (geslaagde maar ook mislukte).
4. Daadwerkelijk analyse van logs laten uitvoeren door een andere partij dan de beheerders.
5. Bij verdachte situaties nader onderzoek (laten) uitvoeren.

Beveilgingsbewustzijn kweken onder beheerders en gebruikers.

Leer mij het ICT wereldje kennen.... ;)

Je zal ook nooit een 1,2,3 hap-klaar te implementeren, antwoord krijgen over iets wat zo 'concurrentie-gevoelig' ligt.
Juist jij zou toch moeten begrijpen dat kennis macht is en op het Inet is nog altijd 'de slimste', 'de baas' is .... deze jongens gaan dus echt het achterste van hun tong, niet aan jouw (op een openbaar fora) laten zien.
Ieder hosting-bedrijfje hanteert inderdaad wel zijn eigen set 'trucs', de meeste zijn voor de kenners slechts security by obscurity, maar als je 'Night's' stappenplan volgt vanuit je eigen kennis en kunde, moet je al een eind komen.

PS: heb je ambities in die richting ?

[sarcasm mode on]
NB: Bedankt Night !
[sarcasm mode off]

Denk dat het afhankelijk is van de waarde van de data.
Er zal dus Risk management toegepast moeten worden.
Bij onbetekende data kan het al voldoende zijn om de rechten goed te configureren.
Maar bij bijvoorbeeld staatsgeheimen zal de lat veel hoger liggen en zal gebruik moeten worden gemaakt van sterke encryptie en goed beschreven procedures met wat er met de data gedaan moet worden.

Wanneer kunnen de technisch beveiligingmaatregelen als afdoende worden beschouwd tegen gegevensdiefstal?

- een 1-laags beveiliging mag niet als afdoende beschouwd worden.
Er kan immers op ieder moment informatie beschikbaar komen over een lek in je beveiligings-software/-systeem waar door het voldoende bescherming meer bied. lees: er komt ooit informatie beschikbaar waar door je beveiligings-software/-systeem niet voldoende bescherming meer bied de vraag is alleen "wanneer?".

- een 2 laags beveiliging kan als afdoende beschouwd worden als bijde technologieeen up-to-date zijn en er nog geen public informatie is te vinden over hoe 1 van de 2 beveiligingen (rendabel) is te kraken/omzeilen
Het is namelijk zeer onwaarschijnlijk dat voor bijde beveiligingstechnieken binnen korte tijd een (rendabele) methode word gevonden om hem te kraken/omzeilen

- een 3 laags beveiliging kan als afdoende worden beschouwd als alle technologieën up-to-date zijn en er nog geen informatie is te vinden over hoe 2 van de 3 beveiligingen (rendabel) is te kraken/omzeilen

Welke maatregelen en hoe zwaar ze moeten zijn is is afhankelijk van:
-kosten voor implementatie en beheer
-kosten bij diefstal van persoonsgegevens
-aantal persoonsgegevens
-gevoeligheid van de gegevens
-de toegankelijkheid van de gegevens (via internet=heel toegankelijk , op papier in de kast op kantoor=minder toegankelijk)

zoiets misschien?

Greetingz,
Jacco

Hier is geen absoluut antwoord op te formuleren. Juridisch gezien zal het moment in tijd, dat een ongeautoriseerde gebruik of misbruik maakt van de gegevens, bepalen wat afdoende beveiligd betekent.

Ik zou dus zeggen dat er voor dit soort systemen iets als een security lifecycle process moet worden gedefinieerd. Constant controleren, evalueren en aanpassen aan de stand van technologie op dat moment.

Gr.

Edie

Naar mijn mening is het allereerste wat je doet het maken van een risico-analyse. Om welke gegevens gaat het, wat is het beleid voor opslag, toegang en verwijdering van die gegevens (zowel intern als extern) en welke risico's worden er gelopen bij de opslag of het opvragen van de gegevens. Dit brengt risico's en dreigingen in kaart. Je kunt een redelijke inschatting maken van de waarde van de informatie, en daarnaast is er in veel gevallen een wettelijk kader waarbinnen uitspraken gedaan zijn over het bewaren van gegevens.

Op basis van de risico analyse ga je een inschatting maken van de waarschijnlijkheid dat een bepaalde dreiging of een bepaald risico ook daadwerkelijk een probleem gaat worden. Op basis van die analyse ga je technische en administratieve beveiligingsmaatregelen nemen, waarbij je in het oog houdt dat de informatie die je probeert te beveiligen een bepaalde waarde heeft, en dat het nooit de bedoeling kan zijn dat de waarde van de informatie en de totale kosten van de beveiliging erg ver uit elkaar liggen. Dat betekent niet dat je geen goedkope maatregelen kunt nemen die het beveiligingsniveau fors vergroten (sterke passwords, MAC filtering op je wireless) maar meer dat een all-singing, all-dancing PKI oplossing niet altijd de juiste keuse is.

Na de implementatie van alle maatregelen is het tijd voor validatie en verificatie van die maatregelen. Je huurt een pentest-bedrijf in, en laat ze hun gang gaan. Soacial engineering, technische attacks, alle registers gaan open om te kijken of men in staat is om de beveiligingsmaatregelen te doorbreken.

Ik denk dat als je in staat bent om aan de rechter te laten zien datje nagedacht hebt over je beveiliging, een risico-analyse gemaakt hebt en vervolgens een onafhankelijke derde partij de mogelijkheid hebt gegeven om een test uit te voeren op je netwerk en daar een rapport van hebt, dat er redenen genoeg zijn om te bepalen of je al dan niet afdoende maatregelen genomen hebt om de informatie te beveiligen.

Idd, dit komt voor mij al dichter in de buurt van dat wat er nodig is, en overstijgt de bovenstaande opsomming van technische oplossingen ("Welke maatregelen" ). Maatregelen hoort naast techniek ook bv organisatie en proces te bevatten, om het daarmee afdoende (dit is m.i.: redelijk, zorgvuldig) te maken:

"afdoende" maatregelen":
1 zorg dat je het veilig maakt via een risicoafweging methodiek. Betrekken van financiele overwegingen is prima (en redelijk), maar laat onverlet dat het belang van bescherming persoonsgegevens zwaarwegend is.
2 zorg dat je het veilig houdt (bv de stand vd techniek kan veranderen, dreigingen en kwetsbaarheden ook of kunnen zich nieuw voordoen: regel een monitor en verbeterprogramma in die )
Bv, implementatie van (gedeelten) in de geest van een standaard als iso27001.

Vervolgvraag is: zou de rechter deze "expertinsteek" voldoende vinden?

Een mogelijk antwoord voor deze vraag kun je vinden op http://www.xs4all.nl/~rvy/ib-bev-cbp.html:



Het rapport is te vinden op http://www.cbpweb.nl/documenten/av_23_Beveiliging.stm

Frank

Zucht, al die mensen die hier roepen dat strong crypto de enige of enig juiste oplossing is moeten maar eens nadenken over het key management probleem.

Grappig dat er bijna alleen gekeken wordt naar de data zelf (encryptie en secure access) terwijl er niet over de logging wordt nagedacht. Wanneer je de toegang effectief kan personaliseren (idd dmv secure access) en alle relevante acties zo worden gelogd dat er niet mee geknoeid kan worden ben je volgens mij al redelijk op de juiste weg.

Het zal altijd een risico afweging zijn waarbij kosten, gebruiks(on)gemak en veiligheid worden gewogen. Zolang de logging goed gebeurd heb je in ieder geval altijd een gedegen overzicht van de handelingen en ben je dus in controle.