Wetenschappelijke bron voor verwijderen via overschrijven?

[Millennyum]

Voor mijn werk (archiefafdeling gemeente) ben ik bezig een advies op te stellen over onder meer de manier waarop bestanden in ons toekomstige digitale archief permanent verwijderd kunnen worden. Voor vernietiging van archiefbescheiden bij overheidsorganen zijn wettelijke regels opgesteld, dus het is belangrijk dat vernietiging grondig gebeurt.

Ik ben op zoek naar een wetenschappelijke bron om in mijn advies naar te verwijzen over het aantal keer dat een bestand overschreven moet worden, wil het 100% zeker niet meer terug te halen zijn.

Ik vind diverse websites waar de aantallen 7x en 35x op genoemd worden. Zo raadt de redactie van HCC Magazine gebruikers aan informatie minimaal 7x te overschrijven, en meldt ze tevens dat officiële instanties zelfs 35x aanhouden. In de FAQ van dit subforum staat: "Volgens de US veiligheidsrichtlijnen is het het beste om de schijf minimaal 7 maal achtereen te overschrijven met enen en nullen in volledig willekeurige volgorde. Datarecovery is hierbij onmogelijk".

Helaas is er dus niet echt eenduidigheid en niemand verwijst naar een officiële bron of test ('US veiligheidsrichtlijnen' is een beetje algemeen om terug te kunnen vinden...). Als ik Google dan vind ik voornamelijk softwaretools om bestanden te verwijderen, maar dat is allemaal commercieel en dus ook niet wetenschappelijk verantwoord.

Kan iemand mij misschien op weg helpen, of heeft iemand een link naar een goede bron voor me?

Ik ben dus NIET op zoek naar gegevens over de kwaliteit van formatteren, maar specifiek wat betreft overschrijven van bestanden.

Alvast bedankt!

[Diabolical]

De overheid zelf heeft hier richtlijnen voor opgesteld.

Wellicht informeren bij de Rijksarchief inspectie dienst?

[Millennyum]

De overheid zegt gewoon dat het zo vernietigd moet worden dat het niet meer reconstrueerbaar is. De Archiefwet, het Archiefbesluit en de aanverwante regelingen zijn nog steeds vooral gebaseerd op papieren archieven, maar de definitie van 'archiefbescheiden' is zo geformuleerd dat digitale archieven er ook onder vallen.

[twiekert]

Lijkt mij dat digitale archieven toch iets anders behandeld moeten worden als papier . Vergeet bijvoorbeeld je backup(tapes) ook niet, daar staat je data nog lang en breed om als je het van de schijven op de server gewist hebt.

[A_L]

De 7 keer komt volgens mij van Department of Defense (DoD) van Amerika. Zo zit bijvoorbeeld bij ghost een utility die deze optie biedt. Dit schijnt om DoD 5200.28-STD te gaan.

In de de faq staat hoe je het handmatig onder linux kunt uitvoeren.

Ik heb wel een wetenschappelijk artikel gevonden over "Secure Deletion of Data from Magnetic and Solid-State Memory" van de University of Auckland, maar deze is wel van 1996.

offtopic:
Ik post uit de toekomst!

[ Voor 29% gewijzigd door A_L op 07-01-2006 23:16 . Reden: wetenschappelijk artikel ]

[Millennyum]

Twiekert: Precies, dat is dan ook een van de problemen die ik moet tackelen. Dus als iemand nog goede ideeën heeft, of voorbeelden van hoe ze dit bij jouw eigen organisatie oplossen, hoor ik het graag!

A_L: ik heb die DoD-richtlijnen inderdaad gisteren gevonden, dankzij een vriendelijke Tweaker die ze me toemailde. Ik vond ze nogal onleesbaar, maar in een ander document dat deze richtlijnen toelichtte, stond dat het aantal keer dat een bestand overschreven moet worden om het onleesbaar te maken, afhankelijk was van het type medium. Een bestand op een CD-ROM zou bv. maar 1x overschreven hoeven te worden.
Ik kan alleen niet vinden of de DoD-richtlijnen op onderzoek gebaseerd zijn, of dat die mensen daar ook maar iets geroepen hebben...

[edit] A_L: hoe kan jouw bericht nu 1 minuut later dan dat van mij gepost zijn en toch boven dat van mij staan

[ Voor 73% gewijzigd door Millennyum op 09-01-2006 09:46 ]

[Soldaatje]

Hoe kan een data-recovery bedrijf nog data terughalen als er minimaal een keer overgeschreven is?

[KopjeThee]

Soldaatje schreef op zaterdag 07 januari 2006 @ 23:06:
Hoe kan een data-recovery bedrijf nog data terughalen als er minimaal een keer overgeschreven is?

Misschien is het een idee om eens contact op te nemen met zo'n bedrijf. Zij weten vast wel wat er aan de hand moet zijn om het onmogelijk te maken de data terug te halen :-)

[Soldaatje]

kopjethee schreef op zaterdag 07 januari 2006 @ 23:11:
[...]


Misschien is het een idee om eens contact op te nemen met zo'n bedrijf. Zij weten vast wel wat er aan de hand moet zijn om het onmogelijk te maken de data terug te halen :-)

Het gaat mij er niet om of de data weg is, maar als je 1 keer alles invuld met willekeurig nullen en enen hoe je het dan nog terug halen, volledig.

Trouwens waarom zou iemand gemeentelijke data naar een data-recovery bedrijf sturen tegen kosten van enkele duizenden euro's om misschien wel niets terug te vinden.

[Sleepie]

Soldaatje :
Dat kun je oa hier lezen :

Het wissen van bestanden
Over diskwipe tools kunnen we kort maar duidelijk zijn: ze werken niet (goed genoeg). Althans, niet als het om extreme situaties gaat. Als men echt gaat spitten op je harde schijf, is de kans groot dat een deel van de informatie die jij dacht te hebben gewist nog te achterhalen is. De kop van je harde schijf schrijft namelijk niet altijd op precies dezelfde plaats op de disk. Als je dus later een file wilt wissen kom je een klein beetje naast het originele spoor (of track) te zitten, waardoor je het midden van het spoor wel overschrijft, maar de rand niet. De originele disk-kop zal die rand niet kunnen lezen, maar speciale apparatuur heeft daar geen moeite mee. Hoe vaak je de track dus ook overschrijft, je kunt nooit meer op die "rand track" komen. Floppies die op een andere computer beschreven zijn kun je per definitie niet wissen, omdat het verschil in stand van de koppen te groot is. Het is duur om een schijf zo te ontleden, en het lukt niet altijd ... maar het kan dus wel. Programma's als PGP hebben een ingebouwde wisfunctie, waarbij instelbaar is hoe vaak een file overschreven moet worden. De super paranoia Gutmann standaard staat op 35 keer overschrijven, met bepaalde karakters. PGP wipe zit bij PGP tools, source code beschikbaar.

[Verwijderd]

Hoe vaak je de track dus ook overschrijft, je kunt nooit meer op die "rand track" komen.

@Sleepie: Als dat zo zou zijn dan zou dus de data die je als eerste op een nieuwe hdd zet ook op de rand terecht komen, maar wanneer je daarna er iets overheen zet, kom je dus nooit meer bij die rand. Dus heeft het geen zin om 10.000 x over je data te heen schrijven want je komt toch nooit over die rand.

Ik dacht dat het zo zat:

Als je het maar een paar keer overschrijft dan kun je het toch nog terug halen. Dit komt omdat data op een hdd dmv magnetisme erop wordt gezet. Zelfs data die een keer overschreven is, is weer terug te halen doordat de data die je wilde wissen nog heeeel iets magnetiseerd. En dan klinkt het dus heel logisch dat 35x meer effect heeft dan 10 x overschrijven, omdat bij 35x je oorspronkelijke data steeds minder magnetiseerd (net zo lang to het niet meer te lezen is, zelfs niet met speciale aparatuur).

Maarja dan kom je bij het volgende punt. Die specials apparatuur wordt natuurlijk steeds verfijnder, dus hdd's die ze nu niet meer kunnen lezen kunnen ze misschien over 10 jaar wel lezen. Of ze er over 10 jaar nog wat aan hebben is natuurlijk de vraag.

[ Voor 74% gewijzigd door Verwijderd op 07-01-2006 23:55 ]

[Vinnienerd]

Je kunt het beste je HD data encrypten met een key die je op een USB-stick bewaart.

[Soldaatje]

Vinnienerd schreef op zaterdag 07 januari 2006 @ 23:50:
Je kunt het beste je HD data encrypten met een key die je op een USB-stick bewaart.

Waarom dan?

@Searoar: Ik denk dat jullie allebei wel gelijk kunnen hebben. Als je er vaniut gaat dar er de eerste keer in het midden van het spoor geschreven wordt, en daarna wordt gewist in het midden, er van het eerste keer van schrijven aan de buitenkant nog een residu is van magnetisme. Na 35x wordt dat residu weer vervangen door de andere magnetische velden.

[Verwijderd]

Waar ga je je archief opslaan?
Meestal werken ze bij gemeentes etc. met jukeboxen (oid), etc waar een HD cache in zit, voor verwijderen vernietig je gewoon de CD's of WORM disks.

Welke software/hardware gebruiken jullie eigenlijk voor te archiveren?

[_Ernst_]

Soldaatje schreef op zondag 08 januari 2006 @ 00:11:
[...]


Waarom dan?

@Searoar: Ik denk dat jullie allebei wel gelijk kunnen hebben.

Dat denk ik ook. Ik heb altijd het gedacht dat het was zoals Searoar zei, maar wat Sleepie zegt is ook een goeie, dus ik denk een combinatie van beide..


Je HD encrypten is overigens onzin. Een encryptie kan gebroken worden, en voor een goed recovery bedrijf lijkt me die encryptie dan ook totaal geen probleem (als je nagaat dat ze ook al in staat zijn de data van een in stukjes gezaagde hd af te halen )

[John2B]

_Ernst_ schreef op zondag 08 januari 2006 @ 00:20:
[...]
Je HD encrypten is overigens onzin. Een encryptie kan gebroken worden, en voor een goed recovery bedrijf lijkt me die encryptie dan ook totaal geen probleem (als je nagaat dat ze ook al in staat zijn de data van een in stukjes gezaagde hd af te halen )

Beetje kort door de bocht, als het toch te kraken is dan kun je wissen ook achter wegen laten want dat kan ook aardig worden teruggehaald. Als je beide toepast moet je wel knap wat werk doen en geld inzetten, EN de informatie moet natuurlijk wat opleveren ...misschien iets voor Peter R. Vries.

Ik neem aan dat je de disken wil wissen om ze te verkopen? nu weet ik niet hoe oud ze zijn maar ik ken bedrijven die disken met gevoelige data zelf vernietigen door ze onder hoge druk plat te persen...maar ja dat is het andere uiterste.

ON TOPIC:
Ik vraag mij ook af of die gearchieveerde data maar op enkele disk staat (en gebackup hoop ik) want als deze zo belangrijke data verloren gaat door een defecte disk, die je dus niet meer kan wissen...wat dan?

Als je toch wil gaan voor veiligheid, zorg dat je je data zowiezo encrypt, Je data weg schrijft op een redundand opslag zoals RAID5 (dan heb je ook het probleem niet met wissen van je schijf, achteraf) en kan je altijd nog voor de zekerheid de disk een keer of tien overschrijven.

Nou ja, on topic....leuke discussie dat wel, wie weet wat voor leuke ideen naar boven komen.

[ Voor 6% gewijzigd door John2B op 08-01-2006 20:26 ]

[Millennyum]

Encrypten is geen optie, een gemeente is wettelijk verplicht om de gegevens te vernietigen en onleesbaar voor anderen opslaan valt daar niet onder

Ik weet niet precies hoe de data zal worden opgeslagen, want het systeem is momenteel nog in ontwikkeling. We werken samen met leverancier COSA, die het systeem voor ons voor een deel op maat maakt. Ik ga binnenkort met de systeembeheerder praten over wat zij precies in gedachten hebben wat hardware betreft.

[ShadowLord]

Het enige wat werkt is fysieke vernietiging van de schijven. Alle andere methodes zijn leuk en meestal ook praktischer toepasbaar, maar ze zijn vaak te recoveren. Dit brengt wel exponentieel toenemende kosten met zig mee. Daarom kun je vaak zeggen 'deze data is X waard, dus als we zover wissen dat het 10*X zo duur is om te recoveren is het goed.

Is dit niet acceptabel, dan zal er dus fysieke vernieting plaats moeten vinden. Dus HDD ontleden en dan de platters in een verbrandingsoven.

Overigens wordt het steeds moeilijker data te recoveren. Er zijn steeds minder 'overbodige' magnetische deeltjes in de HDD door betere efficiency in het gebruik van de platters. Dus zijn er ook minder deeltjes die de oude data kunnen verraden (even simpel gezegd).

[Millennyum]

Tja, het probleem is juist dat je straks één groot digitaal archief hebt, en dat daar bijvoorbeeld maandelijks een aantal bestanden uit vernietigd moeten worden. Deze bestanden worden met behulp van een query gevonden. Ook al zet je de data van het archief op een andere disk dan de backups van de rest van je systeem zeg maar, je wil nog steeds de backup van de rest van je archief behouden...

Ik ben echt erg benieuwd of er tweakers bij een overheidsorganisatie werken waar zo'n digitaal archief al geimplementeerd is, en hoe ze het hebben opgelost!

[Verwijderd]

Millennyum schreef op maandag 09 januari 2006 @ 15:21:
Tja, het probleem is juist dat je straks één groot digitaal archief hebt, en dat daar bijvoorbeeld maandelijks een aantal bestanden uit vernietigd moeten worden. Deze bestanden worden met behulp van een query gevonden. Ook al zet je de data van het archief op een andere disk dan de backups van de rest van je systeem zeg maar, je wil nog steeds de backup van de rest van je archief behouden...

Ik ben echt erg benieuwd of er tweakers bij een overheidsorganisatie werken waar zo'n digitaal archief al geimplementeerd is, en hoe ze het hebben opgelost!

Ik snap het nog niet helemaal?
Hebben jullie je archief gewoon op harddisks staan??

[Sleepie]

Verwijderd schreef op zaterdag 07 januari 2006 @ 23:46:
lang verhaal

Om eerlijk te zijn dacht ik zelf ook zoiets. Maar een zoektochtje (vond de probleemstelling wel interesant) leverde mijn quote op.
Ik denk dat beide gelden. Kan me best voorstellen dat een HD kop nooit exact op dezelfde plaats zijn data schrijft.
Combineer dat met jouw verhaal en er zal altijd een magnetische trace achterblijven die door specialistische apparatuur uitgelezen kan worden.

[ShadowLord]

Millennyum schreef op maandag 09 januari 2006 @ 15:21:
Tja, het probleem is juist dat je straks één groot digitaal archief hebt, en dat daar bijvoorbeeld maandelijks een aantal bestanden uit vernietigd moeten worden. Deze bestanden worden met behulp van een query gevonden. Ook al zet je de data van het archief op een andere disk dan de backups van de rest van je systeem zeg maar, je wil nog steeds de backup van de rest van je archief behouden...

Dat maakt niet echt uit. Zolang de HDD onderdeel uitmaakt van je archief is een gewone delete afdoende. Mischien 1 overwrite erbij zodat een undelete tool niet werkt, maar meer is echt niet nodig. De HDD's zijn dan namelijk nog steeds onder jullie beheer en is er geen kans op uitlekken (lees: die kans is even groot als voor de 'active' data). Ook zal veel keren overschrijven de HDD's veel sneller laten slijten wat ook nadelig is (je zal meer HDD's moeten aanschaffen én laten vernietigen).

Pas als de HDD jullie beheer verlaat (weggooien dus) heb je een probleem: Nu kan er buiten jullie toegangscontroles iedereen bij de data. Op dat moment zul je de HDD pas grondig hoeven te vernietigen.

[eamelink]

ShadowLord schreef op woensdag 11 januari 2006 @ 11:22:
[...]
Dat maakt niet echt uit. Zolang de HDD onderdeel uitmaakt van je archief is een gewone delete afdoende. Mischien 1 overwrite erbij zodat een undelete tool niet werkt, maar meer is echt niet nodig. De HDD's zijn dan namelijk nog steeds onder jullie beheer en is er geen kans op uitlekken (lees: die kans is even groot als voor de 'active' data). Ook zal veel keren overschrijven de HDD's veel sneller laten slijten wat ook nadelig is (je zal meer HDD's moeten aanschaffen én laten vernietigen).

Pas als de HDD jullie beheer verlaat (weggooien dus) heb je een probleem: Nu kan er buiten jullie toegangscontroles iedereen bij de data. Op dat moment zul je de HDD pas grondig hoeven te vernietigen.

Dat betwijfel ik. Als de gemeente zou kunnen besluiten om de HD naar een recovery bedrijf te brengen, en de data terug te laten halen, was de data dus blijkbaar níet vernietigd. En de data móet vernietigd zijn volgens de wet.

Anders zou je nooit een archief hoeven vernietigien; gewoon zorgen dat er niemand bij mag komen...

[LauPro]

Hier wordt denk ik iets te moeilijk gedacht. De intentie van de overheid is dat gegevens niet in handen kunnen vallen van derden nadat de apparatuur bijvoorbeeld afgeschreven is en wordt verkocht.

Als je ervoor zorgt dat er geen fysieke toegang is tot de systemen waar deze documenten worden opgeslagen (bijvoorbeeld in Redbus oid) dan kan je iig al voorkomen dat er een harde schijf uit een array wordt gesloten.

Op dit moment hoef je de zaak alleen softwarematig goed te beveiligen. Volgens mij heb ik een keer voor ext2 een soort extentie gezien die bij verwijderen van een bestand (zoals eerder beschreven) daadwerkelijk een x aantal keer die ruimte op vult met random gegevens. Maar dit brengt de performance natuurlijk niet ten goede, aangezien er bij het 'verwijderen' van een bestand (van bijvoorbeeld een paar honderd MB) vele GB's aan data moet worden weggeschreven.

Als een HDD afgeschreven wordt dan zal men natuurlijk de data definitief moeten verwijderen. Wat dan precies de maatstaven zijn weet ik niet, wellicht dat 100 uur achtereenvolgens random beschrijven met data voldoende is. Andere optie is om een machine te gebruiken die sterk magenisch veld op werk, echter meestal zijn de harde schijven daarna niet meer bruikbaar evenals een scredder oid.

[TetsuoShima]

Weet je de makkelijkste manier om ervoor te zorgen dat je data nooit meer terugkomt, als je de schijf tenminste ook niet meer nodig hebt, is hem open hameren en dan een zeer krachtige elektromagneet er een paar uur langs leggen, af en toe de magneet bewegen. Daarna nog goed de schijf verder kapot proberen te maken, bekrassen,..., noem maar op, eventueel door een metaalvergruizelaar. Ik ben er vrij zeker van dat ze dan ze dan geen nuttige data meer bevatten...

Maar als je da schijven nog wel nodig hebt, tja..., dan werkt die methode natuurlijk niet...

[M@rijn]

http://dban.sourceforge.net/

Op deze CD staan enkele technologieen die aanbevolen worden vanuit de amerikaanse overheid.

[Millennyum]

eamelink heeft gelijk: het gaat er niet om dat niemand bij de data kan komen, het is stomweg wettelijk verplicht om die dingen te vernietigen. Punt.

Wat beteft het vernietigen van de hele HD of wat dan ook waar de backup op staat: dat vernietigt inderdaad je te vernietigen bestanden, maar het vernietigt ook de backup van de bestanden die je WEL wil bewaren. En dat is dus niet de bedoeling, want in geval van een crash wil je die backup terug kunnen zetten.

Ik hoop dat het probleem nu voor iedereen duidelijk is....

[John2B]

Wat is de reden van het vernietigen van deze archief bestanden, is dat om de bereffende gegevens niet meer te benaderen voor intern gebruik, of omdat de disken het bedrijf om wat voor reden dan ook verlaten?

ONTOPIC
Als het archief nu wordt opgeslagen op dataserver die op basis RAID5 is volgens mij het probleem opgelost.

Indien er een disk uit deze raidset word vervangen of voor andere doelen wordt gebruikt kan je met de (gestripte) data niets meer doen, of zelf achterhalen.

[eamelink]

John2B schreef op woensdag 11 januari 2006 @ 14:54:
Wat is de reden van het vernietigen van deze archief bestanden, is dat om de bereffende gegevens niet meer te benaderen voor intern gebruik, of omdat de disken het bedrijf om wat voor reden dan ook verlaten?

Als je het topic nu eens leest.....

Hij werkt bij een gemeente, en die gemeente is verplicht om bepaalde data na een bepaalde tijd te vernietigen.

ONTOPIC
Als het archief nu wordt opgeslagen op dataserver die op basis RAID5 is volgens mij het probleem opgelost.

Indien er een disk uit deze raidset word vervangen of voor andere doelen wordt gebruikt kan je met de (gestripte) data niets meer doen, of zelf achterhalen.

En dat helpt ook geen zier. De bedoeling is om een schrijf draaiend te houden, maar bepaalde bestanden erop definitief te vernietigen. Niet een schijf eruit halen ofzo...

[LauPro]

Millennyum schreef op woensdag 11 januari 2006 @ 14:07:
eamelink heeft gelijk: het gaat er niet om dat niemand bij de data kan komen, het is stomweg wettelijk verplicht om die dingen te vernietigen. Punt.

Dus je mag geen Windows gebruiken? Want daar beland nogal wat data in de swap file of het memory. Dus dan denk je een bestand te hebben verwijderd, maar dan staat het nog ergens in de swapfile. Na een paar keer swappen is dat wel weer weg, maar de kans is wel aanwezig dat er nog data achter blijft. Ik vraag me af welk OS wel geschikt zou zijn, want bijna elk OS doet aan caching. Volgens mij komt Linux dan nog het beste in de buurt, echter zal het uitschakelen van de diskcache dramatische gevolgen hebben voor de performance. Wat te denken van de cache op RAID-controllers of in harde schijven?

Maargoed, als het echt zo punctueel moet worden uitgevoerd dan zou ik adviseren een bedrijf in de hand te nemen die gespecialiseerd zijn in dergelijke beveilingen.

Hoe vernietigen jullie nu dan papier? Toch niet met een versnipperaar? Daar je die stoken weer naast elkaar kan leggen, of staat er een machine die er allemaal stukjes van 2x2mm van maakt oid?

[Millennyum]

Gemeenten hebben contracten met gecertificeerde archiefvernietigingsbedrijven om het papier te laten vernietigen.

Dat cachen is inderdaad ook een probleem waar ik nog niet aan gedacht had.

edit:
Ik ben overigens een zij, geen hij

[ Voor 13% gewijzigd door Millennyum op 11-01-2006 16:31 ]

[eamelink]

LauPro schreef op woensdag 11 januari 2006 @ 16:24:
Dus je mag geen Windows gebruiken? Want daar beland nogal wat data in de swap file of het memory. Dus dan denk je een bestand te hebben verwijderd, maar dan staat het nog ergens in de swapfile. Na een paar keer swappen is dat wel weer weg, maar de kans is wel aanwezig dat er nog data achter blijft. Ik vraag me af welk OS wel geschikt zou zijn, want bijna elk OS doet aan caching.

Een gemiddelde database server gebruikt echt geen HD om te swappen hoor

Volgens mij komt Linux dan nog het beste in de buurt, echter zal het uitschakelen van de diskcache dramatische gevolgen hebben voor de performance. Wat te denken van de cache op RAID-controllers of in harde schijven?

De cache op de harddisk wordt zo vaak gebruikt dat data vrij snel weer vernietigd is

Hoe vernietigen jullie nu dan papier? Toch niet met een versnipperaar? Daar je die stoken weer naast elkaar kan leggen, of staat er een machine die er allemaal stukjes van 2x2mm van maakt oid?

Er zijn genoeg bedrijven die archiefvernietiging verzorgen, en ook wel voor digitale meuk, maar meestal betekent dat gewoon de HD in de oven, en dat is net niet de bedoeling hier

[LauPro]

eamelink schreef op woensdag 11 januari 2006 @ 16:29:
Een gemiddelde database server gebruikt echt geen HD om te swappen hoor

Een databaseserver is volgens mij wel het meest slechte voorbeeld van goede verwijdering van data. Veelal worden intern de records slechts gemarkeerd voor verwijdering ipv daadwerkelijk verwijderen dit omwille de performance. Hoe minder i/o's hoe sneller.

De cache op de harddisk wordt zo vaak gebruikt dat data vrij snel weer vernietigd is

Op harddiskniveau kan je idd niet snel iets achterhalen. Maar stel dat er een SAN aanwezig is met een paar controllers welke ieder een paar GB cache hebben (met back-up batteries uiteraard ). Dan kan het volgens mij zo voorkomen dat een document nog weken ergens blijft 'handen' zonder dat je het weet. Je moet wel heel specialistisch zijn om die data nog te kunnen destileren, maargoed om uit de swap files restoren zijn al een legio aan utilities beschikbaar.

Er zijn genoeg bedrijven die archiefvernietiging verzorgen, en ook wel voor digitale meuk, maar meestal betekent dat gewoon de HD in de oven, en dat is net niet de bedoeling hier

Wat me net te binnen schoot was dat we eigenlijk allemaal te moeilijk denken. Je moet kijken op volumeniveau en niet op harddiskniveau. Als je nou een volume maakt met encryptie dan valt er van die data op de harde schijven niets meer te bakken. Swap is dan nog wel een gevaar, maar aangezien die op een encrypted volume staat valt dat nog te bezien. De caches kan je afvangen door de servers fysiek te beveilingen (Dell heeft bijvoorbeeld speciale beugels met sloten die je voor de server kan monteren).

[JackBol]

Millennyum schreef op woensdag 11 januari 2006 @ 16:28:

edit:
Ik ben overigens een zij, geen hij

offtopic:
zo'n idee had ik al, gezien je avatar en sig

[ Voor 4% gewijzigd door JackBol op 11-01-2006 16:58 ]

[begintmeta]

eamelink schreef op woensdag 11 januari 2006 @ 16:29:
...
Een gemiddelde database server gebruikt echt geen HD om te swappen hoor
...

Dan zou je natuurlijknog moeten nagaan of op clients(in swapfiles of waar dan ook) te vernietigen bestanden staan, of niet?

Misschien kun je hier of bij hem (kijk maar eens naar deze link(die al was gegeven), en eventueel in de referenties van dat artikel of zoek naar de auteurs van de gerefereerde artikels.) nog wat meer informatie krijgen. (naast bij de misschien bekende Nederlandse autoriteiten)

Is encryptie vernietigen LauPro (de topicstartster zei al van niet)? Dan zou je inderdaad de gegevens kunnen versleutelen en als ze dan vernietigd moeten worden de sleutel onherstelbaar vernietigen (bijvoorbeeld door het papier of de diskette waar de sleutel op staat op gangbare wijze te vernietigen, maar dat zal bij greote hoeveelheden bestanden/sleutes vrij onwerkbaar worden natuurlijk.).

[ Voor 44% gewijzigd door begintmeta op 11-01-2006 17:50 . Reden: De post even wat beter gemaakt ]

[Jazzy]

Millennyum schreef op woensdag 11 januari 2006 @ 14:07:
Ik hoop dat het probleem nu voor iedereen duidelijk is....

Je vraag is me duidelijk maar ik denk dat je eerst moet weten heo je archief opgebouwd gaat worden. Pas dan kun je kijken welke data op welk moment vernietigd moet worden en hoe dat het beste zou kunnen. Op dit moment weet je nog niet eens op welk media de data staat.

[Millennyum]

Ik wacht nog steeds op antwoord van degene die over backups van het systeem gaat, om een afspraak te plannen (ambtenaren hè...).
Ik laat jullie meer details weten zodra ik ze zelf heb!

Overigens is digitale archivering relatief nieuw en zijn er dus maar erg weinig gemeenten die het op dit moment al op orde hebben. Afkijken van anderen is dus helaas erg beperkt.

[Verwijderd]

Als systeembeheerder GGZ hanteer ik de volgende richtlijnen als het om complete vernietiging gaat waarbij dataherstel natuurkundig onmogelijk is.

5x 0000 pattern
5x 0101 shake 1
5x 1010 shake 2
5x 0110 shake 3
5x 1111 pattern
5x 0000 pattern

Een dertigvoudige shake waarbij het verkrijgen van elke 'willekeurige' combinatie onmogelijk is geworden zolang er natuurkundige wetten bestaan.

Deze methode kan gedaan worden met de betaalde versie van Active Killdisk.

Als ze een boel tijd over hebben kun je er nog bovenop een Guttmann-pattern overheen gooien

[LauPro]

@Exuimtum: dat gaat om het 'verwijderen' van een complete harde schijf. Niet zoals hier wat een bestand dat moet worden verwijderd achteraf niet kan worden terug gehaald. Al hoewel ik me idd af vraag hoe je dat met back-ups wil gaan doen. Want wanneer is het verwijderen van een bestand 'perongelijk' of een actie dat echt daadwerkelijk moet gebeuren. Of gaat het verwijderen van een bestand via een aparte tool dan?

[eamelink]

LauPro schreef op woensdag 11 januari 2006 @ 22:20:
@Exuimtum: dat gaat om het 'verwijderen' van een complete harde schijf.

Waarom? Je kan toch ook gewoon enkele bestanden met die patterns overschrijven?

[naftebakje]

Volgens mij heeft TS een advocaat nodig, met kennis van computers. Die advocaat kan dan de wetteksten ontcijferen naar de realiteit, met name hoe dit moet opgevat worden. Als er dan problemen zouden zijn, kan er altijd teruggevallen worden op die advocaat.

Als er op een cursusblok iets gemeentelijks geschreven wordt, dat later moet vernietigd worden, dan moeten die bladen die erachter zitten (en een doordruk van je stylo bevatten) ook niet geshred worden, terwijl het wel erg gemakkelijk is uit die bladen erachter te achterhalen wat er geschreven werd.
Volgens mij zal de situatie dusdanig mogen vergeleken worden, en zal de data gewoon gewist (als wissen in windows en dergerlijke) mogen worden op de actieve datadragers (die binnen het archief blijven). Pas als die datadragers het archief verlaten (kapot, versleten) moet de data daadwerkelijk vernietigd worden. Maar alleen een advocaat of rechter kan/mag hierover wettelijk geldende uitspraken doen vrees ik.

[Reptile209]

Millennyum schreef op woensdag 11 januari 2006 @ 16:28:
Gemeenten hebben contracten met gecertificeerde archiefvernietigingsbedrijven om het papier te laten vernietigen.

Dat cachen is inderdaad ook een probleem waar ik nog niet aan gedacht had.

edit:
Ik ben overigens een zij, geen hij

Aan de andere kant (met het oog op swappen e.d.): de kans bestaat met een papieren archief natuurlijk ook dat er een kopietje/printje in een buro blijft liggen... een echte, 100% dekking krijg je denk ik nooit, tenzij je elk bestand op een aparte HD zet en die omsmelt na gebruik. En dan nog .
Meestal is de wetgever al tamelijk tevreden met "redelijkerwijs onmogelijk" en "uiterste zorg" enzo.
PC aan de straat zetten omdat 'ie een virus heeft is meer iets voor Justitie

[John2B]

naftebakje schreef op woensdag 11 januari 2006 @ 22:50:
Volgens mij heeft TS een advocaat nodig, ----------------------- moet de data daadwerkelijk vernietigd worden. Maar alleen een advocaat of rechter kan/mag hierover wettelijk geldende uitspraken doen vrees ik.

Inderdaad, en als die uitspraak is gedaan, is ook gelijk duidelijk in hoeverre data moet worden vernietigd binnen het archief en/of bij het verlaten van het archief.

In de tussentijd kan natuurlijk (zoal dit topic) worden onderzocht welke mogelijkheden erzijn met behulp van de huidige techniek. (wetenschappelijk ondersteund zou natuurlijk heel mooi zijn)

De vraag is dus welke techniek; overschrijven met nullen, enen, wisselend patroon, 10x, 35x, magnetiseren of vernietiging.

[ShadowLord]

Millennyum schreef op woensdag 11 januari 2006 @ 14:07:
eamelink heeft gelijk: het gaat er niet om dat niemand bij de data kan komen, het is stomweg wettelijk verplicht om die dingen te vernietigen. Punt.

Wat beteft het vernietigen van de hele HD of wat dan ook waar de backup op staat: dat vernietigt inderdaad je te vernietigen bestanden, maar het vernietigt ook de backup van de bestanden die je WEL wil bewaren. En dat is dus niet de bedoeling, want in geval van een crash wil je die backup terug kunnen zetten.

Ik hoop dat het probleem nu voor iedereen duidelijk is....

Ik denk dat je met de regels zoals je ze nu voorstelt een dilemma hebt. Immers het is niet mogelijk om zeker te zijn van complete datavernietiging terwijl de HDD nog gebruikt moet worden, maar de HDD mag ook niet vernietigd worden, want hij moet nog gebruikt worden.

Echter, je moet ook even de prakteik voor ogen houden. De reden dat een papieren archief vernietigd moet worden is omdat anders iedere willekeurige medewerker en zelfs externe personen door je afval kunnen graaien en zo alle data simpel kunnen lezen. Bij HDD's is dit niet het geval: er is zeer speciale apparatuur voor nodig.
Bij een goede wisactie (dus minimaal 1x overschrijven om een undelete te voorkomen) kan er niet meer 'zomaar' data bekeken worden. Als je dus alle HDD's die de controle van de gemeente verlaten goed vernietigd kan er geen data bij derden komen.

Nu zou je je voor kunnen stellen: wat als iemand van de gemeente er mee aan de haal wilt? Dan zal deze persoon de HDD mee naar buiten moeten nemen. Immers, de apparatuur voor HDD recovery neem je niet zo even in je binnenzak mee naar binnen. je hebt hievoor een clean-room nodig en speciale magnetische detectors die ook niet echt klein zijn

En voor het mee naar buiten nemen verwijs ik je weer terug naar boven: hiervoor is toch al een goede beveiliging aanwezig, anders kan diezelfde persoon natuurlijk ook met actieve data aan de haal gaan!

Het enige scenario wat je niet afdekt is dat de gemeente besluit oude data die vernietigd is terug te halen. Nu kun je je afvragen hoe waarschijnlijk dit scenario is. Dit is namelijk uiterst illegaal en is niet echt makkelijk te verbergen. Maar het blijft natuurlijk wel een 'loophole'. Je zou hierover moeten navragen bij een advocaat of een vergelijkbaar iemand die beter met de wetgeving en de praktijk op de hoogte is.
Echter, ik vermoed dat dit geen probleem is. Anders zouden gemeenten helemaal geen computers kunnen gebruiken, omdat er altijd overal wel wat data achterblijft (swapfiles, HDD's van lokale computers waarop je office aplicaties temp bestanden aanmaken, etc).

[LauPro]

Een schijf meenemen als medewerker is volgens mij niet zo moeilijk. Ik kan me best voorstellen dat er bij de overheid kwesties spelen waarbij dit soms gewoon 'noodzakelijk' is (denk aan klokkeluiders). Als een array op een server is RAID1 draait dan trek je er een schijf uit en zet je er niet een nieuwe in en de array rebuild weer. Doe je dit aan het einde van vrijdag middag dan is geen haan die er naar kraait en kan je wbvs voor de zondageditie al de informatie beschikbaar hebben.

[Gomez12]

* Gomez12 denkt dat er veels te moeilijk gedacht wordt. Volgens mij heeft ts alleen een papiertje ( contract) nodig waarin de leverancier van software x verklaart dat alle data verwijderd wordt met zijn tooltje zodat als er problemen zijn er altijd naar het papiertje verwezen kan worden.

Vergelijk het met je papieren archief opruiming : Jij gooit niet persoonlijk de blaadjes in het vuur. Dus iedereen in het traject tussen gemeente geeft papiertje weg, en papiertje wordt echt verbrand ( / weet ik veel wat er mee gebeurt ) kan het papiertje inzien / kopieren. Waarom vind de overheid deze regeling goed genoeg omdat de gemeente een contract met de verbrander heeft afgesloten, zodat de gemeente niet meer verantwoordelijk is.

Zo een soort contract moet je ook met een softwareleverancier weten te sluiten en je bent klaar. Want het echt 100% onder eigen beheer en eigen verantwoordelijkheid verwijderen is zo goed als onmogelijk zonder dat je performance er onder gaat leiden.

Volgens mij gaat het alleen maar om waar leg je de verantwoordelijkheid voor als het fout gaat. Leg die gewoon bij de leverancier van je software en de regering vindt jouw regeling goed. Hoe de leverancier het afhandelt is zijn probleem.

[Gomez12]

LauPro schreef op woensdag 11 januari 2006 @ 23:43:
Een schijf meenemen als medewerker is volgens mij niet zo moeilijk.

offtopic:
Je bent bekend met het feit dat er tegenwoordig netwerken bestaan???

Een beetje medewerker heeft volgens mij geen toegang tot de serverruimte, als iedere medewerker er gewoon een schijf uit een draaiende machine kan halen heb je een heel ander probleem en zou ik me nog lang niet druk maken over hoe je iets moet verwijderen, maar eerst eens denken over hoe je ervoor zorgt dat je productie gegevens niet gejat kunnen worden

Ik kan me best voorstellen dat er bij de overheid kwesties spelen waarbij dit soms gewoon 'noodzakelijk' is (denk aan klokkeluiders). Als een array op een server is RAID1 draait dan trek je er een schijf uit en zet je er niet een nieuwe in en de array rebuild weer. Doe je dit aan het einde van vrijdag middag dan is geen haan die er naar kraait en kan je wbvs voor de zondageditie al de informatie beschikbaar hebben.

Volgens mij werken de meeste klokkenluiders of vanuit zo'n hoge positie dat ze die hdd niet nodig hebben of met zo weinig gegevens dat ze alles net zo goed van papier hadden kunnen halen.
Nogmaals als iemand gewoon een hdd uit een machine kan trekken heb je een heel ander probleem ( want al je software security's vervallen als je eenmaal fysiek de schijf in handen hebt dus dan kan de postkamer de correspondentie van de gemeenteraadsleden lezen en leuk zien hoe er nu gestemd wordt of de postkamer ontslagen moet worden of niet )

offtopic:
Dit is een zeer sarcastische reactie, maar ik had een betere reactie van jou verwacht. Je gaat nu in op dingen die heel erg anders geregeld horen te zijn en niets met de Topicstart te maken hebben.

[ Voor 9% gewijzigd door Gomez12 op 12-01-2006 00:24 ]

[Verwijderd]

in welke tijdspanne moeten verwijderde bestanden "echt" (=> onleesbaar) verwijderd zijn?

Stel dat het niet op een paar uur aankomt, dan zou je misschien het volgende systeem kunnen hanteren:
je hebt 2 identieke harde schijven voor je data (en een derde voor je OS, => vanop deze schijf worden de verschillende stappen dan gestuurd)

beginsituatie:
op de eerste dataschijf staat al je gevoelige data. de tweede is leeg of gewoon gepartitioneerd op identieke wijze als de eerste schijf.
tijdens de dag worden er vanalle lees en schrijfbewerkingen gedaan op de eerste data schijf. (hier is weinig niks speciaals gedaan bij het deleten, al kan in principe wel een simpele beveiliging gebruikt worden zoals het bv 2 maal overschijven van dat gebiedje). na de werkdag gaat het systeem de eerste schijf automatisch kopieren naar de tweede schijf. als dat afgerond is, wordt de eerste schijf automatisch volledig overschreven (met allemaal verschillende patterns, zoals bv die 35 keer herschrijven hierboven vernoemd), automatisch geherpartitioneerd zoals de staat van de tweede schijf aan het begin van de dag (leeg dus). terwijl moet er alleen nog automatisch ervoor gezorgd worden dat de partities de juiste letters heeft of dat de mountpoints naar de juiste harde schijf verwijzen.
de volgende dag gebeurt dan weer hetzelfde scenario.

Je kan eventueel het systeem uitbreiden met 3 schijven, waarbij 1 schijf in "opgekuiste toestand" wacht, een tweede als "werkschijf" gebruikt wordt, en een derde kan dienen als backup (met de wijzigingen van de vorige dag erop). in dit geval duurt het dus 2 dagen eer alle verwijderde data voor zeker verwijderd is.

effie kort in stapkes resumeren:
1) 2 identieke dataschijven
2) dag 1: schijf A is de werkschijf , schijf B is "lege" schijf
3) einde dag 1: data wordt over gecopieerd van schijf A naar schijf B
4) schijf B wordt gemount als schijf A en vice versa
5) schijf A (van dag 1) wordt gewist en alle data wordt vernietigd volgens de algoritmes en klaargemaakt als "lege" schijf

resultaat op dag 2: schijf B is de werkschijf, schijf A is de "lege schijf"

nog een bemerking misschien:
eventueel kan uiteraard ook het proces meerdere keren per dag uitgevoerd worden, als de hoeveelheid data in een bepaalde tijd kan overgepompt worden van de ene naar de andere schijf. Het wissen en onleesbaar maken van de schijf kan uiteraard ook gebeuren terwijl de andere in gebruik is

Ik hoop dat je er wat aan hebt, en dat je er aan uit kan. Dit systeem heb k zelf net bedacht (ik ben geen specialist, en mogelijk zijn er al mensen die dit voor mij hebben bedacht) en dacht dat t mogelijk wel bruikbaar kon zijn. mijn inziens is dit zowel in windows als in linux perfect te realiseren.

mvg
mooseman007

[Wim-Bart]

Een handige link:
Beleid voor informatiebeveiliging

[TD-er]

Verwijderd schreef op woensdag 11 januari 2006 @ 19:32:
Als systeembeheerder GGZ hanteer ik de volgende richtlijnen als het om complete vernietiging gaat waarbij dataherstel natuurkundig onmogelijk is.

5x 0000 pattern
5x 0101 shake 1
5x 1010 shake 2
5x 0110 shake 3
5x 1111 pattern
5x 0000 pattern

Een dertigvoudige shake waarbij het verkrijgen van elke 'willekeurige' combinatie onmogelijk is geworden zolang er natuurkundige wetten bestaan.

Deze methode kan gedaan worden met de betaalde versie van Active Killdisk.

Als ze een boel tijd over hebben kun je er nog bovenop een Guttmann-pattern overheen gooien

Zolang dat patroon aangehouden wordt voor het verwijderen (overschrijven) van de data zal het nog theoretisch terug te halen zijn wat er stond, op een magnetisch medium.
Pas wanneer die methodes in random volgorde uitgevoerd worden zal het erg lastig worden.
Bij het overschrijven van de data pas je namelijk een magnetische lading aan, die een analoge waarde heeft.
Dus een "1" overschrijven met een "0" zal niet een lading van 0 opleveren, maar ergens tussen de "1" en de "0" in. Nog een keer overschrijven met een "0" zal het nog meer naar een niveau van 0 laten gaan, maar het niveau zal nog steeds niet 0 zijn.
Wanneer je het wispatroon weet, kun je dus aan de hand van een analoge meting van de magnetische lading met een vrij grote zekerheid (ruis gaat meespelen) bepalen wat erop gestaan heeft.
In de praktijk zul je dus niets meer kunnen achterhalen als het gemeten verschil kleiner is dan het ruisniveau. Maar wat nu het ruisniveau is, hoeft dat over 10 jaar nog niet te zijn.

Kortom zoals al eerder aangegeven is, op een magnetisch medium kun je eigenlijk de data niet verwijderen en dat is ook eigenlijk niet nodig wanneer de schijven zelf nog in beheer zijn.
Een keertje overschrijven met 0-en zou dus eigenlijk al genoeg moeten zijn. Dus niet file deleten en dan een file aanmaken die even groot was, maar de huidige file herschrijven. Let er dus ook op dat het filesysteem/medium netjes dezelfde sectoren gebruikt. Flashgeheugen (bijv CompactFlash modules) wil dit namelijk nogal eens anders doen.

Een ander probleem is echter waar de kopieen staan.
- backup-tapes
- cache
- undo informatie op filesystem niveau, zoals bijvoorbeeld met Novell mogelijk is. (salvage van files)
- tape-index op flash geheugens in de tapes (dan weet je vanaf welk punt van de tape je interessante magnetische lading zou kunnen tegenkomen)
- computers van werknemers (identificatie van files dus mischien een idee, zodat je accounts kunt nalopen)

Meer dingen kon ik zogauw niet bedenken, maar ik vermoed dat het langzaam maar zeker wel duidelijk is dat het werkelijk deleten van de data eigenlijk pas kan als de schijven het pand verlaten door defecten of afschrijving en dus door het medium te vernietigen.
Wanneer je er met de aangesloten controller de data niet meer van kunt lezen is het voor deze toepassing vernietigd.
Indien er toch tooltjes zijn die de data analoog uit kunnen lezen zonder dat je de schijf uit elkaar moet halen, dan is er nog het probleem dat ze die ook moeten kunnen uitvoeren en elk goed OS zou dat tegenhouden. (geen idee of die tools er zijn)
Indien mensen dergelijke toegang tot de machine hebben, wie zegt dan dat ze niet een extra schijf kunnen plaatsen die een backupje trekt van alle interessante data voordat het verwijderd wordt.

[Millennyum]

Leuke discussie

Overigens is het vernietigen van archiefbescheiden niet in eerste instantie bedoeld om inzage door onbevoegde derden te voorkomen. Het gaat erom dat de wet vereist dat je archief in 'geordende en toegankelijke staat' verkeert. Om geen ongelooflijke hoeveelheid overbodig materiaal te bewaren, wat allemaal ruimte, moeite en geld kost, zijn er verplichtingen opgenomen in de regelgeving om op termijn de voor bewijsvoering minder relevante documenten te vernietigen. De termijn waarbinnen je documenten moet bewaren verschilt dan ook per type document.

Een archief is dus in eerste instantie bedoeld voor bewijsvoering en verantwoording, niet voor de afgesloten opslag van geheime gegevens. Dus het maakt niet uit als er per ongeluk een doordrukje of kopie van een archiefdocument in de organisatie blijft liggen, het gaat erom dat het origineel uit het archief verwijderd wordt zodat het archief ordelijk en toegankelijk blijft.

Het probleem met digitale bestanden is, dat er geen onderscheid meer is tussen origineel en kopie. De wetgeving gaat wel nog steeds uit van dit onderscheid. Wellicht kun je stellen dat backups geen onderdeel uitmaken van het archief en dus 'kopieen' betreffen die niet vernietigd hoeven te worden. Maar of dat juridisch houdbaar is, zou ik niet weten. Zou wel zo makkelijk zijn, maar ik denk dat de archiefinspectie hier wel moeilijk over gaat doen...
Het probleem blijft natuurlijk dat, wanneer het noodzakelijk is om een backup terug te zetten, de reeds vernietigde bestanden opnieuw eruitgevist moeten worden.

Maar dan blijft ook nog steeds de vraag staan hoe vaak je de gegevens in je 'daadwerkelijke' digitale archief, dus niet de backups, moet overschrijven om ze fatsoenlijk verwijderd te hebben. En dat was eigenlijk mijn oorspronkelijke vraag

[ Voor 10% gewijzigd door Millennyum op 12-01-2006 10:08 ]

[LauPro]

Gomez12 schreef op donderdag 12 januari 2006 @ 00:21:

offtopic:
Dit is een zeer sarcastische reactie, maar ik had een betere reactie van jou verwacht. Je gaat nu in op dingen die heel erg anders geregeld horen te zijn en niets met de Topicstart te maken hebben.

Wat ik ermee duidelijk wilde maken is dat je op deze manier data mee naar huis kan nemen zonder dat iemand het werkt. Natuurlijk kan het ook wel via het netwerk, maar meestal lopen daar loggers mee (wie heeft welk bestand benaderd, etc). Valt dan een beetje op als je een share leeg trekt. Schijf uit een array halen kan buiten het OS om, en geeft misschien 3 logboek entries die je heel eenvoudig kan verklaren met 'schijf vervangen' (wat regelmatig voor komt). Maar je hebt wel een beetje gelijk, het is ietwat off-topic.

@Millennyum: ik begrijp uit je verhaal dat het dus in principe meer om een regelement van orde gaat dan om echt een eis. Dat documenten die uit het archief worden gehaald op een juiste manier moeten worden afgevoerd lijkt me inmiddels duidelijk. Maar als het verwijderen van documenten te doen is om de kosten te drukken dan vraag ik me af. Ik weet niet wie er is aangesteld om documenten te verwijderen, maar stel dat die man/vrouw per dag 1 GB aan 'documenten' weet te verwijderen, dan lijkt mij uitbreiden van het volume met een extra schijf goedkoper? Is dat regelement dan nog wel aan orde? Aangezien een functie meer geld kost dan het beheer van die bestanden.

[begintmeta]

Millenyum, je vraag over de technische implementatie verschilt natuurlijk nogal van de vraag wat de eisen aan het verwijderen zijn. Hoewel het volledig digitaal archiveren vrij nieuw is, heb je het over een archiefinspectie die moeilijk zou kunnen doen. Heeft die nog geen rekening gehouden met voorwaarden van digitale archieven (dat zat er nu toch al enkele tientallen jaren aan te komen, dus dat zou ik wel wat sloom vinden)? Als ze wel hebben nagedacht, kunnen ze je daar vast verder helpen.

Ik denk dat je met behulp van de al aangeleverde links en posts wel wat aan wat wetenschappelijks kunt refereren. Wat zijn de voorwaarden waaraan je advies moet voldoen?

[Millennyum]

De wetgeving loopt inderdaad gewoon erg achter en er zijn maar weinigen (of geen) die op dit moment een digitaal archief hebben waarbij alles exact volgens de wetgeving is opgebouwd. De archiefinspectie is heel huiverig voor digitale archieven, omdat de bewaartermijn van de media nog niet op lange termijn gegarandeerd kan worden. En wetgeving aanpassen gaat altijd traag.
Ik denk dat vele overheidsinstanties met smacht zitten te wachten op iemand die een oplossing heeft… het leek me dan ook een mooie discussie voor op GoT

Overigens gaat het echt om landelijke wetgeving, en geen reglement van orde dat per gemeente verschilt. Dat betekent dat je gewoon de regels moet volgen, ongeacht hoeveel personeel dat kost.

Voor papieren archieven wordt momenteel 1x per jaar de (zeer uitgebreide) procedure doorlopen om archiefbescheiden te kunnen vernietigen. Het duurt namelijk lang voordat de lijsten met te vernietigen dossiers zijn samengesteld. In de digitale situatie kan dat veel sneller, dus kun je denken aan bijvoorbeeld wekelijks of maandelijks vernietigen.


Ik heb hier steeds veel extra informatie gegeven omdat ik het een erg interessante discussie vind. Maar misschien moeten we inderdaad even teruggaan naar de kern van mijn vraag. Die gaat dus niet over backups, maar over het aantal keer dat een bestand overschreven moet worden om het niet meer terug te kunnen halen (en de vraag of eigenlijk dit wel mogelijk is, maar dan is de discussie wat ‘acceptabel’ zou moeten zijn).

Ik ben bezig al de links die jullie hebben gegeven door te spitten, en er zit veel interessants tussen. Ik laat nog wel weten of ik iets bruikbaars vind!

[TD-er]

De vraag of data nog weer teruggehaald kan worden, hangt ook deels af van hoeveel er teruggehaald "mag" worden voordat het zeg maar gevaarlijk wordt.
Bij het terughalen na X keer overschrijven zullen er namelijk steeds meer leesfouten optreden (ik ga hier dus van uit dat een data-rescue bedrijf bezig gaat met specialistische apparatuur en semi-oneindig budget).
Wanneer die data dan gewoon plain-tekst is, zal je veel sneller bepaalde dingen kunnen terugvinden. (bijv Janssen die uitkering bla ontvangt etc.) Dit komt omdat gewoon taalgebruik veel redundante informatie bevat.
D.t .s e.n voo.b..ld
20 characters, 6 onleesbare tekens, maar nog steeds leesbare tekst.

Waneer de data echter veel minder redundantie heeft (zip-file bijvoorbeeld) dan is het veel lastiger om een correct beeld te krijgen van de bestanden die erin stonden.

Gewone plain-tekst data kun je dan ook beter minstens een keer overschrijven met een soort van plain-tekst. Denk aan Lorem-Ipsum (met een aantal random parameters) Kijk ook maar naar de binnenkant van de enveloppen die een bank (de postbank in elk geval) gebruikt om gevoelige data in te versturen. Doordat daar allemaal cijfers door elkaar heen staan kun je de tekst op de brief niet onderscheiden. Als dat een ruitjes patroon zou zijn geweest, had je die tekst wel kunnen lezen.

Kortom zolang het overschrijven van de data maar niet met een vast patroon gaat, zal het al heel snel praktisch onmogelijk zijn om de data terug te halen. Mogelijk al na 2 of 3x.

[naftebakje]

Dat systeem met meerdere (set's) opslagmedia, waarvan 1(eventueel redundant) de data opslaat, de andere gewist wordt, en op het einde van de dag de data op de ene naar de gewiste dataopslag gekopieerd wordt, lijkt me erg goed.
Je kan dan alle mogelijke wismogelijkheden uitproberen, je hebt toch een hele dag om die niet-actieve dataopslag te wissen.
Verlies van gegevens voorkom je door de 2 set's dataopslag redundant uit te voeren, RAID-arrays of dergerlijke.
Het probleem met backups los je op dezelfde manier op: ene set backup's gebruik je, terwijl je de andere set volledig wist. En telkens je backupt, zet je alleen de huidige (niet-gewiste) bestanden op je back-up medium (die volledig gewist is). En wanneer je je backup nodig hebt, kunnen er maar gewiste bestanden van bijvoorbeeld een dag geleden op staan, die kan je toch snel weer opnieuw wissen.

[JeroenE]

Millennyum schreef op donderdag 12 januari 2006 @ 10:06:
Een archief is dus in eerste instantie bedoeld voor bewijsvoering en verantwoording, niet voor de afgesloten opslag van geheime gegevens. Dus het maakt niet uit als er per ongeluk een doordrukje of kopie van een archiefdocument in de organisatie blijft liggen, het gaat erom dat het origineel uit het archief verwijderd wordt zodat het archief ordelijk en toegankelijk blijft.

Je bedoelt te zeggen dat het alleen maar vernietigd wordt vanwege het kosten aspect: je wil niet onnodig 'rotzooi' bewaren waar je niets meer aan hebt en er voor zorgt dat je de andere gegevens lastiger kan terug vinden.

Als dat het geval is dan maakt het dus eigenlijk niet uit of de bestanden echt "vernietigd" zijn in de zin dat ze niet meer zijn terug te halen. Als ze er niet meer zijn door ze 'gewoon' te verwijderen is je archief "ordelijk en toegankelijk".

Maar dan blijft ook nog steeds de vraag staan hoe vaak je de gegevens in je 'daadwerkelijke' digitale archief, dus niet de backups, moet overschrijven om ze fatsoenlijk verwijderd te hebben. En dat was eigenlijk mijn oorspronkelijke vraag

Volgens mij ben je het gewoon moeilijker aan het maken dan het is. Hetgeen je nu vraagt is iets totaal anders dan wat je in de paragraaf hierboven beschrijft.

In andere berichten schrijf je dat het kostenaspect niet belangrijk is. Als je dan echt zeker wil weten dat alles vernietigd is dan is het antwoord vrij simpel. Koop op gezette tijden een broertje van je huidige digitale archief. Kopieer alleen de gegevens die bewaard moeten blijven naar het broertje. Vernietig het eerste digitale archief door de disken samen te persen, te schredden en gooi ze daarna in een hoogoven.

[Millennyum]

Hoezee, het document op http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html gaf uitsluitsel: het legt uit dat er 3 standaard encoding schemes zijn en dat er verschil is tussen het aantal keer / de patronen waarmee je bestanden hierin moet overschrijven om het bijna niet meer vindbaar te maken. Het artikel eindigt met een methode, bestaande uit 35 stappen, waarmee alle meest voorkomende bestanden grondig genoeg worden overschreven. En hij geeft nog een schema van de patronen waarmee overschreven moet worden ook!
En aangezien het door een academicus geschreven is, is het nog wetenschappelijk verantwoord ook!

Oftewel: 35x overschrijven biedt genoeg zekerheid.

Dank

Jeroene: ik zei hierboven al dat de discussie offtopic is gegaan omdat het gewoon een interessant onderwerp is. In de startpost leg ik gewoon mijn oorspronkelijke vraag uit. En ik zeg nergens dat het kostenaspect niet belangrijk is

[TD-er]

Hmm Ergens doet dit een beetje vreemd aan.
Wel opnemen dat iets 35x overschreven moet worden (wat erg veel is), maar het niet erg vinden dat er ergens nog kopieen van rondzwerven. (backup-tapes bijvoorbeeld)

Ik zou dan in elk geval in het document opnemen wat er gedaan moet worden indien een backup van langere tijd terug teruggezet moet worden, zodat niet per ongeluk een vernietigd document terug gezet kan worden.

Ook iets grappigs wat ik me net zit te bedenken...
Hoe zet je de boel klaar om te vernietigen? kopieer je het eerst naar een nieuwe map en het liefst ook nog op een andere schijf?

[Millennyum]

TD-er schreef op donderdag 12 januari 2006 @ 15:14:
Hmm Ergens doet dit een beetje vreemd aan.
Wel opnemen dat iets 35x overschreven moet worden (wat erg veel is), maar het niet erg vinden dat er ergens nog kopieen van rondzwerven. (backup-tapes bijvoorbeeld)

Tja, ik ben het volledig met je eens, maar op dit moment hebben we weinig keuze. Anders konden we die dure archiefvernietigingsbedrijven ook wel achterwege laten.

Ik zou dan in elk geval in het document opnemen wat er gedaan moet worden indien een backup van langere tijd terug teruggezet moet worden, zodat niet per ongeluk een vernietigd document terug gezet kan worden.

Natuurlijk, dat sowieso.

Ook iets grappigs wat ik me net zit te bedenken...
Hoe zet je de boel klaar om te vernietigen? kopieer je het eerst naar een nieuwe map en het liefst ook nog op een andere schijf?

Hoe bedoel je dat? Ik heb niet zo heel veel kennis op dit gebied, maar het is toch een kwestie van de entry in de db meerdere malen overschrijven?

[M@rijn]

Gewoon die dban CD gebruiken is hier goed gekeurd door m'n collega's (ook ivm de DOD mogelijkheden), en met zoiets hoef jij je toch niet bezig te houden? Dump het lekker bij I&A neer

[TD-er]

Millennyum schreef op donderdag 12 januari 2006 @ 15:58:
[...]
Hoe bedoel je dat? Ik heb niet zo heel veel kennis op dit gebied, maar het is toch een kwestie van de entry in de db meerdere malen overschrijven?

Als het in een database zit, dan heeft 35x overschrijven helemaal geen zin.
Een database server past caching toe, dus als je 35x iets gaat lopen aanpassen, dan zal dat echt niet 35x op de schijf geschreven worden.

[JeroenE]

Jeroene: ik zei hierboven al dat de discussie offtopic is gegaan omdat het gewoon een interessant onderwerp is. In de startpost leg ik gewoon mijn oorspronkelijke vraag uit.

Op je TS heb ik niets aan te merken, maar door vragen etc komt dit natuurlijk wel bovendrijven. Het is mij een raadsel waarom je wel zou willen dat iets "echt" vernietigd is in je archief, maar dat er geen regels zijn mbt de backups. Ik snap wel dat jij daar niets aan kan veranderen, maar dan is het wellicht raadzamer om navraag te doen bij degene die de regels hebben gemaakt.

En ik zeg nergens dat het kostenaspect niet belangrijk is

Om 12:08 schreef je:

Overigens gaat het echt om landelijke wetgeving, en geen reglement van orde dat per gemeente verschilt. Dat betekent dat je gewoon de regels moet volgen, ongeacht hoeveel personeel dat kost.

Mijn excuses dat ik dat hebt geextrapoleerd naar niet-personele kosten, maar ik vermoed dat die in een dergelijk geval ook geen reden zijn om iets niet te doen.

[Verwijderd]

Hoe bedoel je dat? Ik heb niet zo heel veel kennis op dit gebied, maar het is toch een kwestie van de entry in de db meerdere malen overschrijven?

Ligt nogaal hoe een en ander opgeslagen wordt.
Je hebt hier nog geen uitsluitsel gegeven van de manier van opslag,
misschien worden de documenten wel apart opgeslagen en niet in een DB ??

Enige details over gebruikte soft- & hardware zou geen overbodige luxe zijn.

btw. Ik kan het hier wel eens navragen over dat vernietigen, we leveren nogal eens
registratie & archief software aan gemeenten.
_{zie hier wel een en ander van nijmegen staan , maar heb er verder niks mee van doen,
werken jullie met meerdere leveranciers daar in nijmegen toevallig, dus naast COSA andere (misschien andere afdelingen binnen de gemeente?)}

Kan je wel vertellen dat ik nog nooit iets gehoord heb over 35x iets in een DB te overschrijven,
zoals gezegd heeft dat weinig nut ivm caching, heb ik het nog niet over transaction logs, BI/AI files etc. (al vraag ik me aan de andere kant weer ff af, of dit soort zaken altijd van toepassing zijn op binaire inhoud als documenten etc)

[ Voor 41% gewijzigd door Verwijderd op 12-01-2006 17:01 ]

[Gomez12]

Verwijderd schreef op donderdag 12 januari 2006 @ 16:43:
[...]


Ligt nogaal hoe een en ander opgeslagen wordt.
Je hebt hier nog geen uitsluitsel gegeven van de manier van opslag,
misschien worden de documenten wel apart opgeslagen en niet in een DB ??

Enige details over gebruikte soft- & hardware zou geen overbodige luxe zijn.

btw. Ik kan het hier wel eens navragen over dat vernietigen, we leveren nogal eens
registratie & archief software aan gemeenten.
_{zie hier wel een en ander van nijmegen staan , maar heb er verder niks mee van doen,
werken jullie met meerdere leveranciers daar in nijmegen toevallig, dus naast COSA andere (misschien andere afdelingen binnen de gemeente?)}

Kan je wel vertellen dat ik nog nooit iets gehoord heb over 35x iets in een DB te overschrijven,
zoals gezegd heeft dat weinig nut ivm caching, heb ik het nog niet over transaction logs, BI/AI files etc. (al vraag ik me aan de andere kant weer ff af, of dit soort zaken altijd van toepassing zijn op binaire inhoud als documenten etc)

En dan vraag ik me weer af wat is een digitaal document voor de gemeente??? Is dit een word-bestand ( dus 1 binair gegeven ) of is dit een samenraapsel van dbase gegevens waardoor er door een nieuwe combinatie een nieuw ( geprint ) document kan verschijnen???
Vb :
Een aanvraag voor de bijstand, is dit alle velden in de dbase die op het geprinte formulier staan ( dus ook naam etc ) of is het alleen het veldje bijstandsaanvraag in 1 tabel ( naam etc wordt uit andere tabellen gehaald ) Wat is nu je document in een dbase???

Dan nog even daargelaten dat er inderdaad backups worden gemaakt en dat er waarschijnlijk ook transaction logs zijn etc.etc.
Alles verwijderen ( en dan ook echt alles ) is wel een leuke uitdaging.
1 : Haal het vinkje in de dbase weg en zorg ervoor dat niemand met data-recovery tools het vinkje kan terughalen. ( moet dus met filetools want 35x overschrijven in de dbase heeft geen nut oftewel zoek jij maar eens in je dbase bestand op welke hdd-sectoren dit is weggeschreven )
2 : Haal alle transaction logs van dit vinkje weg.
3 : Leeg de dagelijkse / wekelijkse / maandelijkse / jaarlijkse backup van dit vinkje
4 : Verwijder bij alle clients die het kunnen zien het vinkje in alle mogelijke caches.
5 : Verzeker je ervan dat in je test-omgeving het vinkje ook weg is.
Ben ik nog iets vergeten???

[ Voor 21% gewijzigd door Gomez12 op 13-01-2006 01:00 ]

[Millennyum]

Verwijderd schreef op donderdag 12 januari 2006 @ 16:43:
[...]
btw. Ik kan het hier wel eens navragen over dat vernietigen, we leveren nogal eens
registratie & archief software aan gemeenten.
_{zie hier wel een en ander van nijmegen staan , maar heb er verder niks mee van doen,
werken jullie met meerdere leveranciers daar in nijmegen toevallig, dus naast COSA andere (misschien andere afdelingen binnen de gemeente?)}

Graag! Ik werk alleen niet bij de gemeente Nijmegen, maar bij gemeente Arnhem. Ik woon in Nijmegen.

Gomez12 schreef op vrijdag 13 januari 2006 @ 00:53:
[...]
En dan vraag ik me weer af wat is een digitaal document voor de gemeente??? Is dit een word-bestand ( dus 1 binair gegeven ) of is dit een samenraapsel van dbase gegevens waardoor er door een nieuwe combinatie een nieuw ( geprint ) document kan verschijnen???

Het gaat om verschillende typen bestanden, zowel Word-documenten als PDF-bestanden als e-mailtjes die rechtstreeks in het systeem geimporteerd worden. Daarnaast zitten er een hoop meta-gegevens in op basis waarvan er via Word-sjablonen nieuwe documenten gegenereerd kunnen worden.

Ik heb net die persoon van onze ICT-afdeling aan de telefoon gehad en hij kon me in het kort het volgende vertellen:

Ons digitale archief is niet echt een database, maar bestaat uit een soort 'adressenbestand met verwijzingen naar de directories waar de bestanden in staan'. Dus als ik het goed begrijp heb je een database met verwijzingen en meta-gegevens, en daarnaast losse digitale bestanden.
Dat zou dus betekenen dat je de bestanden wel meerdere malen kunt overschrijven om ze te vernietigen, maar dat je een probleem krijgt wanneer je de meta-data ook wil vernietigen (ik weet niet of dit ook verplicht is overigens)?

Ze zijn er nog niet helemaal over uit hoe ze het met ons nieuwe systeem gaan aanpakken, maar op dit moment worden backups gemaakt door het te backuppen spul naar een schijf te kopiëren en deze weer vervolgens naar speciaal daarvoor bedoelde magnetische backuptapes te schrijven. De 'tussenschijf' wordt dagelijks overschreven met andere gegevens, de backup tapes worden doorgaans een jaar bewaard.

[TD-er]

Wanneer die tussenschijf dagelijks overschreven wordt, hoef je daar waarschijnlijk niet echt zorgen om maken, want de overschreven data is al min of meer random, tenzij het in het theoretische geval het laatste bestand vernietigd is en er geen nieuwe bestanden zijn toegevoegd, maar voor de zekerheid zou je kunnen eisen dat nadat de backup op tape klaar is, dat je de hele schijf laat overschrijven met random-data.
Om te weten welke bestanden er namelijk vernietigd zijn en waar ze stonden heb je al dusdanig veel meer inside-info nodig dat je een geheel ander probleem hebt.

[Verwijderd]

Millennyum schreef op vrijdag 13 januari 2006 @ 14:40:
[...]
Graag! Ik werk alleen niet bij de gemeente Nijmegen, maar bij gemeente Arnhem. Ik woon in Nijmegen.

Doen we, ik probeer het maandag nog ff na te vragen. _{btw misschien moetj e toch maar ff met een sales van hier praten}

Het gaat om verschillende typen bestanden, zowel Word-documenten als PDF-bestanden als e-mailtjes die rechtstreeks in het systeem geimporteerd worden. Daarnaast zitten er een hoop meta-gegevens in op basis waarvan er via Word-sjablonen nieuwe documenten gegenereerd kunnen worden.

zo werkt onze software ook in principe.

Dat zou dus betekenen dat je de bestanden wel meerdere malen kunt overschrijven om ze te vernietigen, maar dat je een probleem krijgt wanneer je de meta-data ook wil vernietigen (ik weet niet of dit ook verplicht is overigens)?

Ja zeker is dat ook verplicht, maar als het goed is, zijn dat instellingen per documentsoort/type, archiefsoort/type en kan je dit regelen/instellen in de software zelf.


Maar ik vraag het me sterl af, hoe dat zit met die documenten vernietigen, zoals ik al eerder zei, als je b.v. je gegevens op een jukebox achtig systeem opslaat, weet je nooit welke bestanden bijelkaar komen te staan (misschien dat dit wel mogelijk is, maar betwijfel het). Zodoende kunnen bestanden met verschillende vernietingsdata op een en dezelfde WORM schijf terecht komen, en wat dan?

Wel interessant onderwerp trouwens op zich.

[ Voor 17% gewijzigd door Verwijderd op 13-01-2006 15:30 ]

[Verwijderd]

ik zou de schijf begraven in mijnen hof

[begintmeta]

Even een kickje, er is een tijdje terug een studie verschenen: Craig Wright, Dave Kleiman, Shyaam Sundhar R.S.: Overwriting Hard Drive Data: The Great Wiping Controversy^link. Darin wordt nog eens onderzocht hoe het zit. Een keer met nullen overschrijven schijnt te voldoen, om een bekend bit te reconstueren is dan nog een kans van 56%, voor een byte dus nog geen 1%.

[AlexanderB]

lekkere trap 3 jaar na dato.
het probleem met overschrijven is dat je nooit helemaal netjes "binnen de hokjes kleurt"
als je de platters uit de schijf haalt en scant met speciale apparatuur, schijn je nog n heleboel terug te kunnen vinden, de grens ligt, (wat ik gelezen heb, bron kwijt natuurlijk) idd op minstens 25x randomfill voordat niemand dr wat mee kan..

[begintmeta]

Er zijn wel wat andere wat recentere topics^{o.a. 1,2} die over dit onderwerp gaan, maar dit lijkt me toch wel het geschiktste. Het stuk van Gutmann (is al in dit draadje aangehaald overigens, heb je misschien over het hoofd gezien, of je bedoelt toch iets anders) dat jij misschien bedoelt heeft het over 35 maal overschrijven. Dat is ook ongetwijfeld veiliger, maar is het nodig?

[ Voor 11% gewijzigd door begintmeta op 16-01-2009 22:04 ]

[Gomez12]

begintmeta schreef op vrijdag 16 januari 2009 @ 22:03:
Dat is ook ongetwijfeld veiliger, maar is het nodig?

Dat is een afweging die ieder voor zich moet maken.
Heel simpel gesteld is het voor een specialistisch bedrijf mogelijk om je data na x keer verwijderen terug te halen, is een concurrent bereid de tarieven van dat specialistische bedrijf te gaan betalen?

Voor een mkb zaakje met een server-hdd lijkt het me overkill om die 35x te wipen ( maar omgekeerd, in 1 weekend is dit waarschijnlijk wel gedaan, dus valt het wel weer te overwegen )
Voor een MS met een source-control server hdd lijkt het me wel weer goed te doen, genoeg concurrenten die bereid zijn om het geld daarvoor neer te leggen...

En vergeet ook zeker niet de security by obscurity, dat werkt bij heel veel belangrijke dingen niet. Maar voor een mkb-bedrijfje kan het best volstaan om 1x te wipen en dan de workstation-hdd in een bak met 100 andere hdd's te gooien, de kans dat er belangrijke data op een workstation hdd staat gekoppeld aan de kans dat iemand die hdd gaat restoreren en de data herkent alszijnde van je bedrijf is ongeveer nihil

[kalizec]

Sowieso is het volledig overbodig om de data meer dan 1 keer te verwijderen tenzij je de disk 'weg' doet. En als je dat gaat doen, tja dan is denk ik het smelten van de glazen platters de enige 100% zekere manier om de data echt 'weg' te krijgen. Een schijf zou tussen vrijdagmiddag 17:00 en maandagochtend 09:00 toch prima een keer of tien overschreven moeten kunnen worden. Dus als je meer wilt, dan trek je er toch een hele week voor uit.

[begintmeta]

De kans dat je en kwart van de bits een platte tekstbestand van 80kB foutloos kan herstellen, als je weet waar op de disk de bits zich bevonden (wat meestal niet het geval zal zijn), is natuurlijk ook na een keer overschrijven slechts 0,56¹⁶³⁸⁴⁰, ofwel erg klein. Volgens het nieuwe artikel.. Dus of je er een leesbaar bestand uit krijgt is dan maar zeer de vraag.

[ Voor 12% gewijzigd door begintmeta op 17-01-2009 01:17 ]

[Gomez12]

begintmeta schreef op zaterdag 17 januari 2009 @ 01:14:
De kans dat je en kwart van de bits een platte tekstbestand van 80kB foutloos kan herstellen, als je weet waar op de disk de bits zich bevonden (wat meestal niet het geval zal zijn), is natuurlijk ook na een keer overschrijven slechts 0,56¹⁶³⁸⁴⁰, ofwel erg klein. Volgens het nieuwe artikel.. Dus of je er een leesbaar bestand uit krijgt is dan maar zeer de vraag.

Tsja, misschien dat die kans bij een bestand van 80kb opgaat, maar dat is dan ook zo klein dat het niet ter zake doende is over het algemeen.

Pak een dbase van 80Gb en ga daar eens recoveren, je krijgt hem waarschijnlijk niet 100% terug, maar er komt wel genoeg data naar boven om het bestand redelijk te lezen met specialistische tools.

Zelfde met een PST van 2Gb, 1 specifiek mailtje heeft misschien die kans om gerecoverd te worden, maar als je de mailtjes eromheen redelijk terugkrijgt is het over het algemeen ook al goed genoeg.
Als jij 100.000 mailtjes naar 1 geheim te houden emailadres hebt gestuurd dan is de kans dat je 1 specifiek mailtje op 1 specifieke plaats terugvindt misschien zo groot, maar de kans dat je ergens het geheim te houden emailadres intact aantreft is al 100.000x zo groot. De kans dat je uit 100.000 gedeeltelijke emailadressen op het oog het juiste emailadres samenstelt vergroot de kans nogmaals met een factor x.

Kwaadwillenden gaat het over het algemeen niet over 1 specifiek ding van 80kb, maar meer over het totaal-overzicht en dat valt redelijk uit de recovery resultaten te produceren...

[Nvidiot]

Gomez12 schreef op zaterdag 17 januari 2009 @ 11:12:
[...]

Tsja, misschien dat die kans bij een bestand van 80kb opgaat, maar dat is dan ook zo klein dat het niet ter zake doende is over het algemeen.

Pak een dbase van 80Gb en ga daar eens recoveren, je krijgt hem waarschijnlijk niet 100% terug, maar er komt wel genoeg data naar boven om het bestand redelijk te lezen met specialistische tools.

Zelfde met een PST van 2Gb, 1 specifiek mailtje heeft misschien die kans om gerecoverd te worden, maar als je de mailtjes eromheen redelijk terugkrijgt is het over het algemeen ook al goed genoeg.
Als jij 100.000 mailtjes naar 1 geheim te houden emailadres hebt gestuurd dan is de kans dat je 1 specifiek mailtje op 1 specifieke plaats terugvindt misschien zo groot, maar de kans dat je ergens het geheim te houden emailadres intact aantreft is al 100.000x zo groot. De kans dat je uit 100.000 gedeeltelijke emailadressen op het oog het juiste emailadres samenstelt vergroot de kans nogmaals met een factor x.

Kwaadwillenden gaat het over het algemeen niet over 1 specifiek ding van 80kb, maar meer over het totaal-overzicht en dat valt redelijk uit de recovery resultaten te produceren...

Hierbij ga je er wel vanuit dat je weet exact waar op de disk die e-mail adressen te vinden zijn. In de praktijk weet je dit niet en is het dus kansloos.

Sterker nog, die 56% voor 1 bit geldt alleen als de schijf volledig nieuw is, dat ligt aanmerkelijk lager voor een disk die gebruikt is, wat in de praktijk het geval zal zijn.

Komt nog bij dat het bit-voor-bit lezen op deze manier niet iets is wat je even in een los middagje gaat doen voor 80GB aan data. Ten eerste is de apparatuur nogal prijzig, ten tweede ben je aardig wat tijd kwijt per bit.

Concluderend zou je kunnen zeggen dat 1 pass voldoende is. Indien er echt belangrijke data op staat waar bijvoorbeeld de NSA in geinteresseerd is moet je de schijf gewoon smelten en niet gaan klooien met overschrijven.

[begintmeta]

Inderdaad.

Voor zover ik het verder begrijp: je herstelt 100 bits, dan weet je natuurlijk nog niet welke 56 daarvan de juiste zijn. De kans dat je dat (geheel) juist gokt is is dan wat pakweg overeen komt met 2.02518374×10^-29. De kans op het goed kiezen van de 560 juiste van 1000 herstelde bits wordt al 5.00603351×10^-297.

Je hebt trouwens bij een digitaal systeem hoe dan ook al een kans van 0,5 per bit om het correct te herstellen, 0,56 is dan niet zo enorm veel beter, toch (de kans de juist herstelde bits van de 100 goed te gokken wordt dan natuurlijk wel aanzienlijk kleiner (bij 100: 9.91165302×10^-30), maar we blijven het over enorm kleine getallen hebben)?

[ Voor 31% gewijzigd door begintmeta op 17-01-2009 13:13 ]

[kalizec]

Sorry, maar als deze kansberekeningen kloppen niet voor wat je aan het uitrekenen bent. Kortom, je rekent het verkeerde uit. (De cijfertjes zullen vast kloppen).

Om iets verwijderd te hebben moet er niets meer terug te halen zijn dat nog van enige betekenis is. Als de kans op het terug halen van een enkele bit idd 56% is dan klopt het dat voor een byte de kans 56%^8 is. En als een e-mailadres 16 karakters lang is dan klopt het dat voor dat e-mailadres de kans inderdaad 56%^128 is. (Wat inderdaad een heel erg klein getal is.)

Echter als je geen data enkele data terug wilt kunnen halen, dan moet je die kans dus voor alle bytes op de HD doen.

Rekenvoorbeeld
Stel 1 HDD van 500GB
Gevuld met e-mailadressen van allemaal 16 karakters lang.

Voor een e-mailadres zijn er geen 256 verschillende geldige tekens, eerder 64. Dus 2^6. Deze liggen ook nog eens in blokken (dichter bij elkaar). Dus de kans op één teken is 56%^6.

Ik ga er voor het gemak even van uit dat er niet nog meer 'relaties' af te leiden zijn. Zoals ".nl" of ".com" of moet een geldige domeinnaam zijn.

De kans op 16 'geldige' bytes is dan 56%^6^16 = ±2,9 * 10 ^ -6.

Echter er mag geen één e-mailadres terug gevonden worden. Dus we moeten ons getal vermenigvuldigen met het aantal blokken van 16 bytes op die harde schijf.

500.000.000.000 bytes op een schijf van 500GB. (Anders had ik wel GiB geschreven).

500.000.000.000 / 16 = 31.250.000.000.

±2,9 * 10 ^ -6 * 31250000000 = ±90000.

Dus als ik een HD van 500GB pak tot de nok toe gevuld met e-mailadressen. Dan ga ik na één keer wissen nog zo'n 90000 geldige e-mailadressen terug kunnen vinden.

[Nvidiot]

kalizec schreef op zaterdag 17 januari 2009 @ 13:48:
[...]
Dus als ik een HD van 500GB pak tot de nok toe gevuld met e-mailadressen. Dan ga ik na één keer wissen nog zo'n 90000 geldige e-mailadressen terug kunnen vinden.

Klopt, maar ook hier ga je er weer vanuit dat je weet *waar* die e-mail adressen staan. Dat weet je niet, dus gaat dit verhaal niet op.

[ Voor 64% gewijzigd door Nvidiot op 17-01-2009 13:55 ]

[kalizec]

Nvidiot schreef op zaterdag 17 januari 2009 @ 13:55:
[...]

Klopt, maar ook hier ga je er weer vanuit dat je weet *waar* die e-mail adressen staan. Dat weet je niet, dus gaat dit verhaal niet op.

Het gaat er helemaal niet van uit dat je weet waar ze staan. Immers ze staan over de hele schijf verdeeld en dus overal. En zodra je er een gevonden hebt weet je waar die begint en eindigt en de vorige eindigt en de volgende begint.

[Nvidiot]

kalizec schreef op zaterdag 17 januari 2009 @ 13:57:
[...]
Het gaat er helemaal niet van uit dat je weet waar ze staan. Immers ze staan over de hele schijf verdeeld en dus overal. En zodra je er een gevonden hebt weet je waar die begint en eindigt en de vorige eindigt en de volgende begint.

Jawel, je vult namenlijk de disk van voor tot achter met dit e-mail adres. Je weet dus dat de 2e 16 bytes gelijk zijn aan de eerste en aan de derde etc. Daar wordt het inderdaad makkelijker van. In een normaal geval zal er zeg 100 000 keer een e-mail adres op de schijf staan, op willekeurige plekken. Dat is niet terug te halen omdat je niet weet welke bytes hetzelfde moeten zijn.

[kalizec]

Nvidiot schreef op zaterdag 17 januari 2009 @ 14:31:
Jawel, je vult namenlijk de disk van voor tot achter met dit e-mail adres. Je weet dus dat de 2e 16 bytes gelijk zijn aan de eerste en aan de derde etc. Daar wordt het inderdaad makkelijker van. In een normaal geval zal er zeg 100 000 keer een e-mail adres op de schijf staan, op willekeurige plekken. Dat is niet terug te halen omdat je niet weet welke bytes hetzelfde moeten zijn.

In mijn voorbeeld ging ik uit van een volledig gevulde schijf met e-mailadressen. Als jij een andere aanname wilt doen krijg je inderdaad een andere uitkomst. Maar goed ik blijf er bij, de kans is zeker niet iets als 2^-259 of andere dergelijke onzinnige uitkomsten zoals ik hierboven gezien heb.

Een schijf die voor een database gebruikt wordt heeft zijn kolommen niet op een willekeurige plaats staan. Er zal zeker een regelmaat in zitten. We hebben het hier over een archief, niet een simpele desktop. Databases proberen fragmentatie altijd zoveel mogelijk te voorkomen en bevatten vrijwel altijd ook meta-informatie rondom waar de kolommen beginnen en eindigen etc.

Maar goed, zeg dat er maar 100 000 e-mailadressen op staan. Als ik een kans van 56%^6^16 heb om een blok van 16 leesbare tekens terug te halen is de kans dat ik een van die 100 000 adressen op een schijf van 500GB terug vindt als volgt.

56%^6^16 * de kans dat een van die adressen op een door mij herstelde plaats staan.

De kans dat een van die 100 000 addressen op 'toevallig' de juiste plek staan is als volgt.
100 000 / (500 GB / 16 bytes) / 16 (die laatste / 16 omdat de alignment precies goed moet zijn).
Totale kans is dan ongeveer 2 uit tien miljoen (2 * 10 ^ -7).

Kanttekeningen
Rest de vraag echter of het wel redelijk is om aan te nemen dat die bytes zo willekeurig zijn, immers, niet elke combinatie van bytes levert een geldige domeinnaam op. Ook gaat die 56% uit van een gebrek aan clustering. Als er ook maar enige 'clustering' is en de willekeur van herstelbare data niet perfect verspreid is, dan neemt de kans dat er iets te herstellen valt heel rap toe.

Verder is er iets waar al deze aannames geen rekening mee houden. Als je een schijf wiped, dan wiped je HD de sectoren die geremapped zijn vanwege een vermoedelijke bad sector niet. Dat betekent dat als je HD ook maar een enkele onleesbare bit vond in die sector en vervolgens die sector heeft geremapped dat hij de overige 511 bits dus niet meer schoonmaakt bij een wipe. Hetgeen weet betekent dat als je een lowlevel-format met een toolje uit zou voeren (de disk vergeet dan welke sectoren geremapped waren en begint vrolijk opnieuw) dat je plots klaps informatie uit die beschadigde sectoren kunt halen (thans uit het deel van die sector dat niet beschadigd was).

[Gomez12]

Nvidiot schreef op zaterdag 17 januari 2009 @ 11:20:
[...]

Hierbij ga je er wel vanuit dat je weet exact waar op de disk die e-mail adressen te vinden zijn. In de praktijk weet je dit niet en is het dus kansloos.

Nee, ik ga ervanuit dat de hele schijf gerecoverd wordt. Als iemand op een willekeurige server-schijf uit een raid-array al precies weet op welk bitje wat stond, dan heb ik uberhaupt een ander probleem...

Tijd en geld voor het totaal recoveren zijn imho niet echt boeiend, enkele bits recoveren is sowieso geen realistisch scenario waar je bang voor hoeft te zijn. Niemand weet wat waar precies staat, dus moet iedereen wel de complete disk recoveren.

En dan gaan er veel meer dingen meespelen als enkele bitjes, dan ga je patronen zien etc waardoor die 56% een stuk hoger gaat uitkomen over het totaal.

Sterker nog, die 56% voor 1 bit geldt alleen als de schijf volledig nieuw is, dat ligt aanmerkelijk lager voor een disk die gebruikt is, wat in de praktijk het geval zal zijn.

Dat geldt alleen als je uitgaat van enkele bitjes, als je uitgaat van de complete schijf dan kan enigszins gebruikt juist weer positief gaan tellen, 1 bestand wat verplaatst is en nog 5x gekopieerd daar heb je als losse bitjes niets aan, maar over het totaal kan je dan uit die 6 fragmenten wel 1 redelijk bestand maken als je kan achterhalen dat het hetzelfde bestand is.

Komt nog bij dat het bit-voor-bit lezen op deze manier niet iets is wat je even in een los middagje gaat doen voor 80GB aan data. Ten eerste is de apparatuur nogal prijzig, ten tweede ben je aardig wat tijd kwijt per bit.

Concluderend zou je kunnen zeggen dat 1 pass voldoende is. Indien er echt belangrijke data op staat waar bijvoorbeeld de NSA in geinteresseerd is moet je de schijf gewoon smelten en niet gaan klooien met overschrijven.

Tja, ik heb ook nooit gezegd dat de angst reeel is.

kalizec schreef op zaterdag 17 januari 2009 @ 14:52:
[...]
Verder is er iets waar al deze aannames geen rekening mee houden. Als je een schijf wiped, dan wiped je HD de sectoren die geremapped zijn vanwege een vermoedelijke bad sector niet. Dat betekent dat als je HD ook maar een enkele onleesbare bit vond in die sector en vervolgens die sector heeft geremapped dat hij de overige 511 bits dus niet meer schoonmaakt bij een wipe. Hetgeen weet betekent dat als je een lowlevel-format met een toolje uit zou voeren (de disk vergeet dan welke sectoren geremapped waren en begint vrolijk opnieuw) dat je plots klaps informatie uit die beschadigde sectoren kunt halen (thans uit het deel van die sector dat niet beschadigd was).

Normaal gesproken ( bij echte datarecovery bedrijven ) wordt er geen low-level format met een tooltje gedaan hoor. Je sloopt gewoon de platters uit de behuizing en plaatst ze aan je eigen controller die gewoon geen bad-sector skip kent.

[ Voor 20% gewijzigd door Gomez12 op 17-01-2009 15:04 ]

[GemengdeDrop]

Ik weet niet of het wat waard is maar, voor zover ik weet kan je je niet echt wapenen tegen 'de grote jongens' die met magnetic scanning microscopes of nanometer-schaal je platters gaan zitten stofzuigen. Er blijft zelfs na tig keer overschrijven misschien nog wel wat achter en echte zekerheid heb je nooit ivm met sector reallocation/wear levelling, caches etc.

Het meest gevaaarlijke is als een bestand in feite op meerdere plekken tegelijk wordt opgeslagen. Dan heb je dus dubbele mogelijkheid om data terug te krijgen inclusief dubbele checksums etc.

Op software niveau kan je denk ik het beste dit doen:
* zorg ervoor dat vanaf het begin (lees meteen als je de schijf koopt) alles (lees ALLES: ook de os en swap partitie) gecrypt is.
* Als je de boel wil wissen: ga de key 200 keer overschrijven met random pattern. En dan de rest van de data nog eens 10 keer random. Als er dan toevallig nog een paar bitjes van je key te recoveren zijn dan in ieder geval niet de hele key. Cryptografisch gezien heb je dan je data 'vernietigd' . Kijk eens hoe truecrypt dit doet (staat wel in de documentatie)

Als je ECHT zeker wilt zijn dat er niks meer terug te halen is dan is er IMHO maar één oplossing. Smelt je hele hardeschijf. klinkt idioot, maar extreme hitte (1000 graden ofzo) zal zowieso elk spoortje van magnetisme van een hardschijf verwijderen en als je nog meer paranoide bent kan je 'm zelfs smelten. Dan neem je ook meteen alle chips op de schijf mee.

Edit: een mooi plaatje van het terughalen van overschreven data door het NIST:
http://www.trnmag.com/Sto...ic_microscope_071900.html

[ Voor 4% gewijzigd door GemengdeDrop op 17-01-2009 15:53 ]

[begintmeta]

Voor het artikel hebben ze dus overigens inderdaad een magneetmicroscoop gebruikt.

In mijn voorbeeld ga ik uit van het gegeven dat je alle bits op een schijf recovered en dat de inhoud van de schijf onbekend is. Je weet verder dat je per bit 0,56 kans hebt dat het nu de juiste waarde heeft. Welke van die gerecoverde bits echter horen bij de juist gerecoverde bits en welke horen bij de onjuist gerecoverde bits weet je niet. Volgens mij gebruik ik dan toch de juiste kansberekeningen? De kans dat je uit 100 bits de (statistisch aanwezige) 56 juist gerecoverde kiest is

[kalizec]

Sorry, maar als je een 'vermoeden' hebt over wat voor data je naar 'kijkt' dan kun je met een grotere dan 50/50 kans zeggen of een bepaalde bit juist gerecovered is of niet.

Voorbeeld
Het is zelfs bij een geheel gewiste schijf nog bekend waar het begin en einde van een sector ligt.
Dus ik weet welke gerecoverde bit op welke plaats in welke byte zit. Dit betekent dat ik kan kijken naar patronen. Bepaalde byte-combinaties komen aan het begin van een sector heel veel vaker voor dan andere. Dit heeft ook gevolgen voor wat er 'waarschijnlijk' is voor bepaalde bits.

Als ik vervolgens op zoek ga naar een FAT of NTFS tabel dan weet ik meteen al waar op de schijf die zou moeten staan. Ook weet ik dat bestandsnamen eerder letters en cijfers zullen hebben dan leestekens zoals. De meeste tekens zijn zelfs illegaal als onderdeel van een bestandsnaam.

Tot slot heb ik bij NTFS zelfs nog meerdere explaren van mijn tabel. Ik kan hier dus veel meer over zeggen dan 123 aan mag genomen worden. Als ik vervolgens een idee heb van wat voor bestand waar ongeveer staat (ook dit valt weer uit die tabellen te halen) dan heb ik vervolgens weer een beter idee waar de bestanden staan die spullen plain-text opslaan. Vervolgens kan ik daar weer hetzelfde trucje uithalen met vaak en minder vaak voorkomende bytes.

[GemengdeDrop]

Wel een en het ander hangt af van of de kansen voor elk individueel bit gecorreleerd zijn of niet. Ik kan me goed voorstellen dat dit zo is.

Indien niet: het recoveren van elke bit staat dan op zichzelf. Kwestie van kansen vermenigvuldigen lijkt me. Het gaat niet om 'kiezen' van de juiste waarde, maar om de kans dat je de juiste waarde uit de meting krijgt toch? Wanneer ik dan een serie van N bits wil recoveren die verder niet gecorreleerd zijn en waarbij de kans op recovery ook niet gecorreleerd is dan krijg ik toch gewoon (kans)^N ?

edit: stel dat ik een crypto key wil recoveren. Ik wil dus alle 128 bits goed hebben right ? anders is er geen beginnen aan. dan heb je dus 0.56^128 = 10^(-33) = zeer klein getal. Maw, de kans dat iemand nog voldoende van je schijf kan plukken is zeer klein. Het wordt iets beter als je minder bits hoeft te recoveren vanwege een fout in de crypto ofzo, maar zelfs al had je maar 100 bits nodig...
Dit is toch het soort van cijfers dat van belang is?

[ Voor 29% gewijzigd door GemengdeDrop op 17-01-2009 16:14 ]

[begintmeta]

Kalizec, ik ben het helemaal met je eens dat de kans in praktijk vrijwel altijd groter zal zijn dan in mijn voorbeeld. De bits zijn inderdaad meestal niet onafhankelijk van elkaar.

Als je e-mail adressen wil vinden zou je op een onoverschreven schrijf bijvoorbeeld naar 01000000 zoeken, na het wissen staat er 00000000 en met je magneetmicroscoop vind je in net wat meer dan 99% van de gevallen iets anders dan 01000000, maar de kans dat de 1 op 1 'blijft staan' is 56%. Je zult dus als je weet waar de bytes beginnen iets vaker een 1 vinden op de tweede positie waar een @ stond. Dan kun je daaromheen weer zoeken etc.

Overigens is het wel grappig dat je puur op kansberekening ook zonder de schijf te hebben zinvolle gedeelten zou kunnen recoveren .

[ Voor 4% gewijzigd door begintmeta op 17-01-2009 16:18 ]

[kalizec]

Als er geen sprake was van correlatie dan was het inderdaad een simpele vergelijking in de trans van A boven B * C ^ D.

GemengdeDrop schreef op zaterdag 17 januari 2009 @ 16:04:
edit: stel dat ik een crypto key wil recoveren. Ik wil dus alle 128 bits goed hebben right ? anders is er geen beginnen aan. dan heb je dus 0.56^128 = 10^(-33) = zeer klein getal. Maw, de kans dat iemand nog voldoende van je schijf kan plukken is zeer klein. Het wordt iets beter als je minder bits hoeft te recoveren vanwege een fout in de crypto ofzo, maar zelfs al had je maar 100 bits nodig...
Dit is toch het soort van cijfers dat van belang is?

Het klopt dat je met encryptie heel veel winst kunt boeken in veiligheid tegen dit probleem. Echter ook hier is nog steeds in enige mate sprake van correlatie. (Immers als de gevonden sleutel niet bij de gevonden bits past dan nog is de kans dat de werkelijke sleutel dichter bij de gevonden sleutel ligt groter dan dat ie er ver vanaf ligt). Maar toegegegeven de correlatie wordt er heel snel zwakker van. (En de hoeveelheid rekenwerk die nodig is om de boel te herstellen neemt astronomisch snel toe).

• Als ik een situatie moest creëren die zo veilig als mogelijk was dan zou ik
• inderdaad een PC inrichten waarbij de schijf van seconde meteen geencrypt was.
• Dat dat encrypten on-the-fly werd gedaan.
• Dat die sleutel nergens opgeslagen werd behalve in het hoofd van de gebruiker.
• Dat die sleutel zo lang mogelijk was, maar minimaal een flinke zin.
• Dat het systeem altijd uit stond als de gebruiker niet aanwezig was.
• Dat het systeem op geen enkele wijze aangesloten was op de buitenwereld, zelfs de stroom zou lokaal gegenereerd worden op basis van een dieselaggregaat.
• Dat de gebruiker minstens 10 minuten na afsluiten nog steeds aanwezig was. (Om RAM-lezen, na reboot te voorkomen).
• Dat de gehele computer in een kooi van Faraday werd geplaatst.
• Dat de gebruiker van de computer in een tweede kooi van Faraday werd geplaatst. (Tegen bugs).
• Tot slot zou ik hetzelfde systeem voorzien van 'dummy' informatie zodat er zeker wat te vinden valt, zodat ze niet persé door hoeven te zoeken.

• In geval van onbeperkte middelen of wens tot nog hogere veiligheid tegen het in handen vallen van de data in andermans handen zou ik dan:
• De gebruiker de ruimte met het systeem nooit laten verlaten.
• Een gebruiker kiezen met een gestoord lange termijn geheugen en de sleutel dagelijks veranderen
• De gebruiker en het systeem boven een zwart gat hangen en bij 3 foute invoerpogingen de boel er in flikkeren.

[edit]

begintmeta schreef op zaterdag 17 januari 2009 @ 16:14:
Overigens is het wel grappig dat je puur op kansberekening ook zonder de schijf te hebben zinvolle gedeelten zou kunnen recoveren .

Dat heet 'goed gokken' op basis van de kennis die je hebt over de correlatie. (Maw je weet dat een e-mailadres altijd een @ moet bevatten, bijvoorbeeld.)

[ Voor 7% gewijzigd door kalizec op 17-01-2009 16:32 ]

[begintmeta]

Een van de auteurs heeft nog een stukje online gezet, duidelijk moet zijn dat het in dit artikel gaat om de recoverymogelijkheden met magneetmicroscopen (die hier ook regelmatig worden aangehaald) te ontkrachten.

[GemengdeDrop]

begintmeta schreef op zaterdag 17 januari 2009 @ 16:52:
Een van de auteurs heeft nog een stukje online gezet, duidelijk moet zijn dat het in dit artikel gaat om de recoverymogelijkheden met magneetmicroscopen (die hier ook regelmatig worden aangehaald) te ontkrachten.

Cewl. Dus als ik het goed begrijp zeggen ze dat variaties in temperatuur alleen al voldoende gaan zijn om met een paar wipes de boel onleesbaar te maken? MAW, ze zien wel een zekere bias in de distributie van meetwaarden als ze die correleren aan apriori kennis van de oorspronkelijke data, maar ze zeggen dat je er in de praktijk niet zo veel mee kan?

Nouja. Kan je weer rustig gaan slapen