Security Professionals
- ipfw add deny all from eindgebruikers to any
FAQ beveiliging bij backups - 1ste aanzet
De FAQ over public key, gaf mij het idee voor een FAQ over beveiliging bij backups. Ik heb hierover de afgelopen tijd met veel moeite weinig informatie verkregen.
Als voldoende mensen vragen zoals in deze FAQ zouden stellen, gaan backup leveranciers deze informatie wel via eigen FAQ verschaffen. Nu denken zij vaak dat het vertrouwelijke zaken betreft: 'security by obscurity' is een zeer slechte aanpak, die veel geaccepteerd wordt, denk ik.
Inhoud
Q0 - Voor wie en waarom is inzicht beveiliging van backups van belang?
Q1 – Is ‘backup encrypted met AES!’ niet voldoende?
Q2 - Wat is de relatie tussen gebruikerswachtwoord en encryptiesleutel?
Q3 - Hoe kan het wachtwoord of de sleutel gebruikt worden?
Q4 - Hoe wordt het wachtoord/sleutel omgezet in een encryptie sleutel?
Q5 - Wordt het wachtwoord en/of encryptiesleutel opgeslagen?
Q6 - Wat zou bekend moeten zijn over de Encryptie/decryptie methode
Q7 - Encryptie sleutel alleen gebruiken voor toegang tot de echte sleutel?
Q8 - Ja dit ook nog ….
Q0 - Voor wie en waarom is inzicht beveiliging van backups van belang?
Voor voor het MKB, een ZZP'rs en ook soms voor consumenten, is het essentieel te weten of de backup goed beveiligd is en dus of de leverancier op dit gebied te vertrouwen is. Waarom zou een leverancier op dit gebied niet te vertrouwen zijn? Is ‘backup encrypted met AES!’ niet voldoende?
Let wel dat deze FAQ vooral over inzicht tot de vertrouwelijkheid van backups gaat. Een ander aspect als beschikbaarheid speelt ook een rol binnen beveiliging: ‘1 backup is geen backup’ en ‘1x per schrikkeljaar is niet voldoende’. Beschikbaarheid werd nog eens duidelijk door gebeurtenissen rondom een IT-journalist. De (niet-)beschikbaarheid van informatie (via een recente backup) was maar een van de beveiliging aspecten die daar speelden.
Q1 – Is ‘backup encrypted met AES!’ niet voldoende?
Een goed onderbouwde publicatie over password managers en een over cloud storage geven aan dat leveranciers beveiliging 'niet altijd' als top prioriteit zien. Bovendien is er een grote variëteit aan oplossingen, met voor en nadelen, ook qua beveiliging.
Ook zijn er onbegrijpelijke incidenten met z.g. beveiligde USB sticks die alle informatie toch in klare vorm opsloegen. En er is een incident (2008) met beveiligde USB disks van verschillende fabrikanten waarbij bleek dat de gebruikte controller-chip zeer slechte beveiliging bood terwijl AES geclaimd werd door de chip fabrikant.
Q2 - Wat is de relatie tussen gebruikerswachtwoord en encryptiesleutel?
Het wachtwoord geeft toegang tot de backup faciliteit, bijvoorbeeld om de files te selecteren of voor een restore. De backup informatie zelf wordt/is echter gecodeerd (encrypted). Daarom is is naast het wachtwoord een sleutel nodig voor encryptie (bij backup) of decryptie (bij restore) van de informatie. Het kan zijn dat de gebruiker een aparte sleutel moet opgeven, naast het wachtwoord.
Q3 - Hoe kan het wachtwoord of de sleutel gebruikt worden?
a) Het wachtwoord/sleutel van maximaal .... tekens wordt direct gebruikt als encryptiesleutel. Aaanbeveling:
Kies een zeer sterk wachtwoord/sleutel van het maximale aantal symbolen en laat iemand uitrekenen hoelang dit bescherming geeft. Alles onder de 20 symbolen geeft weinig hoop op een goede beveiliging. Kies random gekozen symbolen of nog beter in deze situatie: gebruik Diceware, welke met korte woorden werkt. De zeer lange kraaktijden zijn hierbij goed uit te rekenen, ook omdat het woordenboek bekend is (mag bij aanvallen gerust gebruikt worden)
b) De encryptiesleutel wordt door de leverancier bepaald. Het wachtwoord speelt hier een ondergeschikte of geen rol in. Gevolg:
De leverancier, inbrekers en ander volk zouden kunnen beschikken over de sleutel en kunnen de backup decoderen mochten zij daar toegang toe krijgen. Vragen aan de leverancier kunnen uit deze FAQ wordt afgeleid.
c) Het wachtwoord/sleutel wordt gebruikt als basis voor de omzetting tot een encryptie sleutel. Gevolg:
Gecombineerd met client side encryption kan dit een Fort Knox oplossing leveren. Bij 'client side encryption' wordt de backup informatie op de laptop zelf encrypted, voorafgaande aan de verzending. Die verzending op zich zou overigens ook weer SLL of TLS (in ieder geval een open protocol) moeten gebruiken voor beveiliging van de data communicatie.
Q4 - Hoe wordt het wachtoord/sleutel omgezet in een encryptie sleutel?
Het wachtwoord wordt omgevormd tot een (vaak sterkere) sleutel die bij de encryptie wordt gebruikt. Invulling van de volgende punten geeft een deskundige een goed inzicht in de sterkte van de omgezette sleutel.
- Van het wachtwoord worden alle/maximaal ..... tekens gebruikt.
- Het gebruikte deel van het wachtwoord wordt niet/wel aangevuld met een string van ..... bits. Dit 'salt' bestaat uit het email adres/willekeurig gekozen/anders .......
- Daarna wordt het aangevulde wachtwoord wel/niet omgevormd tot een z.g. hash code. Deze omzetting gebruikt de ........... hash methode.
- De hash methode wordt niet/.............. keer herhaald.
- De uitkomst van de omzetting levert een encryptiesleutel op van ....... bits
Q5 - Wordt het wachtwoord en/of encryptiesleutel opgeslagen?
Het wachtwoord en de encryptiesleutel zijn cruciaal voor de beveiliging van de backup informatie. Zonder de sleutel kan een derde de backup niet decoderen tot de oorspronkelijke inhoud. Dit mits de gebruiker een sterk wachtwoord heeft gebruikt. Bij gebruik van een sterk wachtwoord en een geverifieerde implementatie van een goede encryptie methodes als AES, kost het een derde jaren of decennia om toegang te krijgen tot de oorspronkelijke inhoud. Dat biedt bescherming mocht deze derde er in slagen toegang te krijgen toto de encrypted backup.
Een derde kan echter wel gemakkelijk toegang krijgen als het wachtwoord of de sleutel bijvoorbeeld op een verloren of gestolen laptop of USB stick/disk staat. Daarom is het van belang te weten waar het wachtwoord of de sleutel wordt bijgehouden. Het veiligste is als deze in een digitale kluis (kunnen!) staan, waarvan het kluiswachtwoord alleen in een brein is opgeslagen.
Invulling van de volgende punten geeft inzicht:
-Het wachtwoord wordt niet/wel opgeslagen op de client/de server/.....
- De hash code wordt wel/niet opgeslagen op de client/de server/.....
- De sleutel wordt wel/niet opgeslagen op de client/de server/.....
- De gebruiker moet het wachtwoord of sleutel niet/wel bij elke backup opgegeven
- De gebruiker moet het wachtwoord of sleutel niet/wel bij elke restore opgegeven
Q6 - Wat zou bekend moeten zijn over de Encryptie/decryptie methode
De encryptie methode doet de uiteindelijke codering. De encryptie methode maakt mbv de sleutel een gecodeerde versie van de backup of file. Deze gecodeerde versie kan alleen door decryptie met dezelfde sleutel gedecodeerd worden tot de oorspronkelijke inhoud. (Dit alleen als een sterke sleutel gebruikt wordt).
Zelfs als de gekozen methode betrouwbaar lijkt (zoals AES), wil dat niet zeggen dat de ontwikkelde software die AES encryptie doet, geen fouten bevat. Het is van belang te weten welke methode gebruikt wordt en of de software door onafhankelijken is onderzocht op fouten.
Invulling van de volgende punten geeft inzicht:
- Als encryptie algoritme wordt de AES-128/......... methode gebruikt.
- De gebruikte encryptie modules (libraries) :
a) zijn zelf ontwikkeld en niet/wel onafhankelijk geverifieerd door FIPS/Common Criteria/...... , zie afgegeven verklaring ...... door .............. .
b) zijn de open source libraries van ........
c) zijn de libraries van TKZIP/......., die niet/wel onafhankelijk zijn geverifieerd
Q7 - Encryptie sleutel alleen gebruiken voor toegang tot de echte sleutel?
De hopelijk afgeleide of opgegeven sleutel kan ook gebruikt worden om alleen een 2-de sleutel te decoderen. Dit is dan de echte sleutel voor codering van de backup. Voordeel is bijvoorbeeld dat de gebruiker het wachtwoord of sleutel kan veranderen, zonder dat alle backups opnieuw encrypted (na een decryptieslag) moeten worden met de nieuwe sleutel.
De vraag is dan hoe de eigenlijke sleutel bepaald wordt en waar die wordt opgeslagen. Truecrypt doet veel moeite een werkelijke random sleutel aan de maken door muisbewegingen van de gebruiker. In de USB stick wereld was 1 fabrikant die alle sticks dezelfde sleutel gaf, makkelijk om te produceren.
Voor backup software is de vraag dus van belang hoe in dit indirecte geval de sleutel bepaald wordt.
(ik heb op dit punt nergens informatie gevonden/kunnen krijgen)
Q8 - Ja dit ook nog ….
Als voldoende mensen vragen zoals in deze FAQ zouden stellen, gaan backup leveranciers deze informatie wel via eigen FAQ verschaffen. Nu denken zij vaak dat het vertrouwelijke zaken betreft: 'security by obscurity' is een zeer slechte aanpak, die veel geaccepteerd wordt, denk ik.
Inhoud
Q0 - Voor wie en waarom is inzicht beveiliging van backups van belang?
Q1 – Is ‘backup encrypted met AES!’ niet voldoende?
Q2 - Wat is de relatie tussen gebruikerswachtwoord en encryptiesleutel?
Q3 - Hoe kan het wachtwoord of de sleutel gebruikt worden?
Q4 - Hoe wordt het wachtoord/sleutel omgezet in een encryptie sleutel?
Q5 - Wordt het wachtwoord en/of encryptiesleutel opgeslagen?
Q6 - Wat zou bekend moeten zijn over de Encryptie/decryptie methode
Q7 - Encryptie sleutel alleen gebruiken voor toegang tot de echte sleutel?
Q8 - Ja dit ook nog ….
Q0 - Voor wie en waarom is inzicht beveiliging van backups van belang?
Voor voor het MKB, een ZZP'rs en ook soms voor consumenten, is het essentieel te weten of de backup goed beveiligd is en dus of de leverancier op dit gebied te vertrouwen is. Waarom zou een leverancier op dit gebied niet te vertrouwen zijn? Is ‘backup encrypted met AES!’ niet voldoende?
Let wel dat deze FAQ vooral over inzicht tot de vertrouwelijkheid van backups gaat. Een ander aspect als beschikbaarheid speelt ook een rol binnen beveiliging: ‘1 backup is geen backup’ en ‘1x per schrikkeljaar is niet voldoende’. Beschikbaarheid werd nog eens duidelijk door gebeurtenissen rondom een IT-journalist. De (niet-)beschikbaarheid van informatie (via een recente backup) was maar een van de beveiliging aspecten die daar speelden.
Q1 – Is ‘backup encrypted met AES!’ niet voldoende?
Een goed onderbouwde publicatie over password managers en een over cloud storage geven aan dat leveranciers beveiliging 'niet altijd' als top prioriteit zien. Bovendien is er een grote variëteit aan oplossingen, met voor en nadelen, ook qua beveiliging.
Ook zijn er onbegrijpelijke incidenten met z.g. beveiligde USB sticks die alle informatie toch in klare vorm opsloegen. En er is een incident (2008) met beveiligde USB disks van verschillende fabrikanten waarbij bleek dat de gebruikte controller-chip zeer slechte beveiliging bood terwijl AES geclaimd werd door de chip fabrikant.
Q2 - Wat is de relatie tussen gebruikerswachtwoord en encryptiesleutel?
Het wachtwoord geeft toegang tot de backup faciliteit, bijvoorbeeld om de files te selecteren of voor een restore. De backup informatie zelf wordt/is echter gecodeerd (encrypted). Daarom is is naast het wachtwoord een sleutel nodig voor encryptie (bij backup) of decryptie (bij restore) van de informatie. Het kan zijn dat de gebruiker een aparte sleutel moet opgeven, naast het wachtwoord.
Q3 - Hoe kan het wachtwoord of de sleutel gebruikt worden?
a) Het wachtwoord/sleutel van maximaal .... tekens wordt direct gebruikt als encryptiesleutel. Aaanbeveling:
Kies een zeer sterk wachtwoord/sleutel van het maximale aantal symbolen en laat iemand uitrekenen hoelang dit bescherming geeft. Alles onder de 20 symbolen geeft weinig hoop op een goede beveiliging. Kies random gekozen symbolen of nog beter in deze situatie: gebruik Diceware, welke met korte woorden werkt. De zeer lange kraaktijden zijn hierbij goed uit te rekenen, ook omdat het woordenboek bekend is (mag bij aanvallen gerust gebruikt worden)
b) De encryptiesleutel wordt door de leverancier bepaald. Het wachtwoord speelt hier een ondergeschikte of geen rol in. Gevolg:
De leverancier, inbrekers en ander volk zouden kunnen beschikken over de sleutel en kunnen de backup decoderen mochten zij daar toegang toe krijgen. Vragen aan de leverancier kunnen uit deze FAQ wordt afgeleid.
c) Het wachtwoord/sleutel wordt gebruikt als basis voor de omzetting tot een encryptie sleutel. Gevolg:
Gecombineerd met client side encryption kan dit een Fort Knox oplossing leveren. Bij 'client side encryption' wordt de backup informatie op de laptop zelf encrypted, voorafgaande aan de verzending. Die verzending op zich zou overigens ook weer SLL of TLS (in ieder geval een open protocol) moeten gebruiken voor beveiliging van de data communicatie.
Q4 - Hoe wordt het wachtoord/sleutel omgezet in een encryptie sleutel?
Het wachtwoord wordt omgevormd tot een (vaak sterkere) sleutel die bij de encryptie wordt gebruikt. Invulling van de volgende punten geeft een deskundige een goed inzicht in de sterkte van de omgezette sleutel.
- Van het wachtwoord worden alle/maximaal ..... tekens gebruikt.
- Het gebruikte deel van het wachtwoord wordt niet/wel aangevuld met een string van ..... bits. Dit 'salt' bestaat uit het email adres/willekeurig gekozen/anders .......
- Daarna wordt het aangevulde wachtwoord wel/niet omgevormd tot een z.g. hash code. Deze omzetting gebruikt de ........... hash methode.
- De hash methode wordt niet/.............. keer herhaald.
- De uitkomst van de omzetting levert een encryptiesleutel op van ....... bits
Q5 - Wordt het wachtwoord en/of encryptiesleutel opgeslagen?
Het wachtwoord en de encryptiesleutel zijn cruciaal voor de beveiliging van de backup informatie. Zonder de sleutel kan een derde de backup niet decoderen tot de oorspronkelijke inhoud. Dit mits de gebruiker een sterk wachtwoord heeft gebruikt. Bij gebruik van een sterk wachtwoord en een geverifieerde implementatie van een goede encryptie methodes als AES, kost het een derde jaren of decennia om toegang te krijgen tot de oorspronkelijke inhoud. Dat biedt bescherming mocht deze derde er in slagen toegang te krijgen toto de encrypted backup.
Een derde kan echter wel gemakkelijk toegang krijgen als het wachtwoord of de sleutel bijvoorbeeld op een verloren of gestolen laptop of USB stick/disk staat. Daarom is het van belang te weten waar het wachtwoord of de sleutel wordt bijgehouden. Het veiligste is als deze in een digitale kluis (kunnen!) staan, waarvan het kluiswachtwoord alleen in een brein is opgeslagen.
Invulling van de volgende punten geeft inzicht:
-Het wachtwoord wordt niet/wel opgeslagen op de client/de server/.....
- De hash code wordt wel/niet opgeslagen op de client/de server/.....
- De sleutel wordt wel/niet opgeslagen op de client/de server/.....
- De gebruiker moet het wachtwoord of sleutel niet/wel bij elke backup opgegeven
- De gebruiker moet het wachtwoord of sleutel niet/wel bij elke restore opgegeven
Q6 - Wat zou bekend moeten zijn over de Encryptie/decryptie methode
De encryptie methode doet de uiteindelijke codering. De encryptie methode maakt mbv de sleutel een gecodeerde versie van de backup of file. Deze gecodeerde versie kan alleen door decryptie met dezelfde sleutel gedecodeerd worden tot de oorspronkelijke inhoud. (Dit alleen als een sterke sleutel gebruikt wordt).
Zelfs als de gekozen methode betrouwbaar lijkt (zoals AES), wil dat niet zeggen dat de ontwikkelde software die AES encryptie doet, geen fouten bevat. Het is van belang te weten welke methode gebruikt wordt en of de software door onafhankelijken is onderzocht op fouten.
Invulling van de volgende punten geeft inzicht:
- Als encryptie algoritme wordt de AES-128/......... methode gebruikt.
- De gebruikte encryptie modules (libraries) :
a) zijn zelf ontwikkeld en niet/wel onafhankelijk geverifieerd door FIPS/Common Criteria/...... , zie afgegeven verklaring ...... door .............. .
b) zijn de open source libraries van ........
c) zijn de libraries van TKZIP/......., die niet/wel onafhankelijk zijn geverifieerd
Q7 - Encryptie sleutel alleen gebruiken voor toegang tot de echte sleutel?
De hopelijk afgeleide of opgegeven sleutel kan ook gebruikt worden om alleen een 2-de sleutel te decoderen. Dit is dan de echte sleutel voor codering van de backup. Voordeel is bijvoorbeeld dat de gebruiker het wachtwoord of sleutel kan veranderen, zonder dat alle backups opnieuw encrypted (na een decryptieslag) moeten worden met de nieuwe sleutel.
De vraag is dan hoe de eigenlijke sleutel bepaald wordt en waar die wordt opgeslagen. Truecrypt doet veel moeite een werkelijke random sleutel aan de maken door muisbewegingen van de gebruiker. In de USB stick wereld was 1 fabrikant die alle sticks dezelfde sleutel gaf, makkelijk om te produceren.
Voor backup software is de vraag dus van belang hoe in dit indirecte geval de sleutel bepaald wordt.
(ik heb op dit punt nergens informatie gevonden/kunnen krijgen)
Q8 - Ja dit ook nog ….
Reacties (11)
05-09-2012, 10:36 door
sjonniev
Ik zorg ervoor dat data altijd versleuteld opgeslagen is, op lokale schijf of netwerkshare.
Dan komt het ook netjes versleuteld op de backup terecht. En er is niets te gluren voor de systeembeheerders.
http://www.sophos.com/en-us/products/encryption/safeguard-lancrypt.aspx
Dan komt het ook netjes versleuteld op de backup terecht. En er is niets te gluren voor de systeembeheerders.
http://www.sophos.com/en-us/products/encryption/safeguard-lancrypt.aspx
[/quote]Ik zorg ervoor dat data altijd versleuteld opgeslagen is, op lokale schijf of netwerkshare.
Dan komt het ook netjes versleuteld op de backup terecht. En er is niets te gluren voor de systeembeheerders.[/quote]Dan hoop ik wel dat je je bestanden individueel versleutelt en niet alles in bijv. een truecrypt container stopt.
Er zijn weinig systeembeheerders die een paar TB groot truecrypt container willen terugzetten vanwege 1 corrupt docje.
Dan komt het ook netjes versleuteld op de backup terecht. En er is niets te gluren voor de systeembeheerders.[/quote]Dan hoop ik wel dat je je bestanden individueel versleutelt en niet alles in bijv. een truecrypt container stopt.
Er zijn weinig systeembeheerders die een paar TB groot truecrypt container willen terugzetten vanwege 1 corrupt docje.
05-09-2012, 13:54 door
Dick99999
Door sjonniev: Ik zorg ervoor dat data altijd versleuteld opgeslagen is, op lokale schijf of netwerkshare.
Dan komt het ook netjes versleuteld op de backup terecht. En er is niets te gluren voor de systeembeheerders.
http://www.sophos.com/en-us/products/encryption/safeguard-lancrypt.aspx
Dat Sophos ziet er goed uit. Maar ik vraag me af of je met een PC-backup programma, die de bestanden onversleuteld leest (decryptie is immers transparant) ook niet onversleuteld naar de backup schrijft?Dan komt het ook netjes versleuteld op de backup terecht. En er is niets te gluren voor de systeembeheerders.
http://www.sophos.com/en-us/products/encryption/safeguard-lancrypt.aspx
07-09-2012, 08:32 door
sjonniev
Door Dick99999:
Door sjonniev: Ik zorg ervoor dat data altijd versleuteld opgeslagen is, op lokale schijf of netwerkshare.
Dan komt het ook netjes versleuteld op de backup terecht. En er is niets te gluren voor de systeembeheerders.
http://www.sophos.com/en-us/products/encryption/safeguard-lancrypt.aspx
Dat Sophos ziet er goed uit. Maar ik vraag me af of je met een PC-backup programma, die de bestanden onversleuteld leest (decryptie is immers transparant) ook niet onversleuteld naar de backup schrijft?Dan komt het ook netjes versleuteld op de backup terecht. En er is niets te gluren voor de systeembeheerders.
http://www.sophos.com/en-us/products/encryption/safeguard-lancrypt.aspx
Er zijn minstens 2 manieren om dat op te vangen: Je draait de backupsoftware op een machine zonder lancrypt (op een server bijvoorbeeld), of je sluit de backupsoftware uit van transparante ontsleuteling. Dat laatste is ook handig voor browsers. Als een website via je browser een bestand pikt (ik bedoel, wanneer je een bestand upload) blijft het bestand lekker versleuteld.
08-09-2012, 09:01 door
Dick99999
Ook bij backup in geval van versleuteling op file niveau krijg je volgens mij dat de 'changed-block only' mode van een backup niet meer werken kan (zie ook 2-de reactie, encryptie op container/disk niveau).
Ik heb net nog even mijn Thunderbird Inbox backup bekeken: er kwamen een paar emails bij. Ocster Pro maakte een backup van alleen 200KB (van de 335MB inbox). Bij encryptie op file niveau zou dat een backup van de volledige inbox van 335MB zijn, klopt dat?
Bij het verzenden/upload van een encrypted file via je browser, moet je toch ook de sleutel aan anderen geven? Dat lijkt mij niet de bedoeling.
Ook bij versleuteling lijkt mij een veilige backup met eigen versleuteling de voorkeur hebben. Bovendien heb je dan slechts de sleutel van het backup systeem te managen.
Lijkt mij een goed item voor de FAQ: Wat als files al versleuteld zijn?
Ik heb net nog even mijn Thunderbird Inbox backup bekeken: er kwamen een paar emails bij. Ocster Pro maakte een backup van alleen 200KB (van de 335MB inbox). Bij encryptie op file niveau zou dat een backup van de volledige inbox van 335MB zijn, klopt dat?
Bij het verzenden/upload van een encrypted file via je browser, moet je toch ook de sleutel aan anderen geven? Dat lijkt mij niet de bedoeling.
Ook bij versleuteling lijkt mij een veilige backup met eigen versleuteling de voorkeur hebben. Bovendien heb je dan slechts de sleutel van het backup systeem te managen.
Lijkt mij een goed item voor de FAQ: Wat als files al versleuteld zijn?
08-09-2012, 10:58 door
sjonniev
Het klopt inderdaad dat "changed-block only" niet meer werkt. Voor het versleutelen van e-mail gebruik ik liever e-mail versleuteling, zodat vertrouwelijk mails versleuteld zijn, maar niet het volledige inboxbestand.
Bij het versturen van een versleuteld bestand aan collega's hoef je de sleutel niet uit te delen, bij het delen met derden kun je gebruik maken van een passphrase (beide methoden pas ik toe op bijvoorbeeld Dropbox.
Backup- of systeembeheerders zijn geen bevoegde gebruikers voor zover het de inhoud van de bestanden betreft. Die hebben wel alle access rights nodig maar krijgen geen sleutels voor de gebruikersdata (wel voor hun eigen data). Security-officers zijn ook geen bevoegde gebruikers, dus ook al kunnen ze bij sleutels krijgen ze geen access rights voor gebruikersdata (uiteraard wel voor hun eigen data). Alleen bevoegde gebruikers hebben dus sleutels en access rights.
Systeem- en backupbeheerders zijn dan wel verantwoordelijk voor de beschikbaarheid van de data, maar niet voor de vertrouwelijkheid ervan. Voor security officers geldt het omgekeerde.
Breken boeven dan in in je datacenter (hackend door de firewall, of met een shovel en nemen ze je storage fysiek mee), is er geen exposure van vertrouwelijke gegevens en heb je geen last van een meldingsplicht. Tevens ben je dan als beheerder of security officer verschoond van een plekje bovenaan de lijst van verdachten, wanneer er voor een goede functiescheiding gezorgd is. Dat helpt ook wanneer je data op pastebin of zo terecht is gekomen.
In mijn optiek hoeft een bedrijf dat de zaken op deze manier geregeld heeft dus niet ook nog eens versleuteling van een backuppakket te beheren.
In andere woorden: de enige plaats waar vertrouwelijke gegevens zich onversleuteld mogen bevinden, is in het werkgeheugen van de PC van de bevoegde gebruiker, op het moment dat hij of zij ermee aan het werk is. Zodra op "save" geklikt wordt, wordt er op het werkstation versleuteld, ongeacht of de data naar een lokale folder, usb-stick of share gaat.
Voor al die bedrijven die niet aan functiescheiding of bestandsgewijze versleuteling (willen) doen: Je bent onhandig en gevaarlijk bezig wanneer je je backups niet versleuteld! Backup tapes verdwijnen soms zomaar!
Bij het versturen van een versleuteld bestand aan collega's hoef je de sleutel niet uit te delen, bij het delen met derden kun je gebruik maken van een passphrase (beide methoden pas ik toe op bijvoorbeeld Dropbox.
Backup- of systeembeheerders zijn geen bevoegde gebruikers voor zover het de inhoud van de bestanden betreft. Die hebben wel alle access rights nodig maar krijgen geen sleutels voor de gebruikersdata (wel voor hun eigen data). Security-officers zijn ook geen bevoegde gebruikers, dus ook al kunnen ze bij sleutels krijgen ze geen access rights voor gebruikersdata (uiteraard wel voor hun eigen data). Alleen bevoegde gebruikers hebben dus sleutels en access rights.
Systeem- en backupbeheerders zijn dan wel verantwoordelijk voor de beschikbaarheid van de data, maar niet voor de vertrouwelijkheid ervan. Voor security officers geldt het omgekeerde.
Breken boeven dan in in je datacenter (hackend door de firewall, of met een shovel en nemen ze je storage fysiek mee), is er geen exposure van vertrouwelijke gegevens en heb je geen last van een meldingsplicht. Tevens ben je dan als beheerder of security officer verschoond van een plekje bovenaan de lijst van verdachten, wanneer er voor een goede functiescheiding gezorgd is. Dat helpt ook wanneer je data op pastebin of zo terecht is gekomen.
In mijn optiek hoeft een bedrijf dat de zaken op deze manier geregeld heeft dus niet ook nog eens versleuteling van een backuppakket te beheren.
In andere woorden: de enige plaats waar vertrouwelijke gegevens zich onversleuteld mogen bevinden, is in het werkgeheugen van de PC van de bevoegde gebruiker, op het moment dat hij of zij ermee aan het werk is. Zodra op "save" geklikt wordt, wordt er op het werkstation versleuteld, ongeacht of de data naar een lokale folder, usb-stick of share gaat.
Voor al die bedrijven die niet aan functiescheiding of bestandsgewijze versleuteling (willen) doen: Je bent onhandig en gevaarlijk bezig wanneer je je backups niet versleuteld! Backup tapes verdwijnen soms zomaar!
08-09-2012, 11:00 door
sjonniev
Oh ja, wanneer je gaat versleutelen, hier mijn twee slagzinnen:
Key management is key.
Cryptographic majesty is king.
Key management is key.
Cryptographic majesty is king.
08-09-2012, 14:27 door
Dick99999
Mijn vergelijking is een 3-poot: de encryptie metode(wiskundig), de implementatie ervan (software of firmware) en de encryptie sleutel (wachtwoord, omzetting/versterking en beheer). En een driepoot kan niet op 2 poten staan. Vaak is het moeilijk om iets over poot 2 te weten te komen.
Sophos wordt voor mij steeds aantrkelijker(met dank). Hoe zit dat met de 3de poot? Als je een passphrase doorgeeft moet de sleutel er bijna wel bijzitten. Dus hoe goed is die beveiligd?
Even terug naar de FAQ, het probleem van deels (native)versleutelde backups is volgens mij data mining. Loop door de geweldige berg (backup) aan onversleutellde data heen en je weet het een en ander over het versleutelde deel, denk ik.
Sophos wordt voor mij steeds aantrkelijker(met dank). Hoe zit dat met de 3de poot? Als je een passphrase doorgeeft moet de sleutel er bijna wel bijzitten. Dus hoe goed is die beveiligd?
Even terug naar de FAQ, het probleem van deels (native)versleutelde backups is volgens mij data mining. Loop door de geweldige berg (backup) aan onversleutellde data heen en je weet het een en ander over het versleutelde deel, denk ik.
08-09-2012, 15:23 door
sjonniev
Als ik heel eerlijk ben moet ik hieraan toevoegen dat toegang tot je sleutelring alleen mogelijk zou moeten zijn met je private key, die alleen terug te vinden zou moeten zijn op je smart card, of cryptographische token.
Voor data die met derden gedeeld moet worden, die versleuteld is op de USB stick of in de cloud, is een passphrase onvermijdelijk. Je kunt een passphrase afspreken of per versleutelde e-mail sturen, je kunt sleutels met passphrases importeren in je eigen omgeving (zodat je hem niet meer hoeft in te tikken, en dankzij PKCS#5 kun je met een passphrase een sterke sleutel gebruiken. Het valt of staat dus met de kwaliteit van de passphrase. Met de dataversleutelingssleutels en sleutelversleutelingssleutels (wat een woorden) zit het wel goed.
Voor data die met derden gedeeld moet worden, die versleuteld is op de USB stick of in de cloud, is een passphrase onvermijdelijk. Je kunt een passphrase afspreken of per versleutelde e-mail sturen, je kunt sleutels met passphrases importeren in je eigen omgeving (zodat je hem niet meer hoeft in te tikken, en dankzij PKCS#5 kun je met een passphrase een sterke sleutel gebruiken. Het valt of staat dus met de kwaliteit van de passphrase. Met de dataversleutelingssleutels en sleutelversleutelingssleutels (wat een woorden) zit het wel goed.
11-09-2012, 19:38 door
Dick99999
Door sjonniev:
................, en dankzij PKCS#5 kun je met een passphrase een sterke sleutel gebruiken. Het valt of staat dus met de kwaliteit van de passphrase. Met de dataversleutelingssleutels en sleutelversleutelingssleutels (wat een woorden) zit het wel goed.
Bij Sophos of i.h.a? Indien het laatste, wat denk je van usb sticks waarvan de hele serie dezelfde sleutel gebruikt, produceert lekker makkelijk. Of een usb drive die aes gebruikt omdat de chip dat zegt te doen, maar niet deed, sorry foutje in de specs. Ook bij password managers is het onderzoek gepresenteerd op de blackhat van maart j.l. echt een openbaring. ................, en dankzij PKCS#5 kun je met een passphrase een sterke sleutel gebruiken. Het valt of staat dus met de kwaliteit van de passphrase. Met de dataversleutelingssleutels en sleutelversleutelingssleutels (wat een woorden) zit het wel goed.
Kortom voldoende aanknopingspunten om mijn poot 2 (implmentatie) en 3 (alles rondom de encryptie sleutel) goed te onderzoeken of gedegen reviews te vinden, als poot 1 in orde is. En volgens mij ook als de leverancier van een leveranciers eigen oplossing zeer betrouwbaar is.
12-09-2012, 10:05 door
sjonniev
Door Dick99999:
Kortom voldoende aanknopingspunten om mijn poot 2 (implmentatie) en 3 (alles rondom de encryptie sleutel) goed te onderzoeken of gedegen reviews te vinden, als poot 1 in orde is. En volgens mij ook als de leverancier van een leveranciers eigen oplossing zeer betrouwbaar is.
Door sjonniev:
................, en dankzij PKCS#5 kun je met een passphrase een sterke sleutel gebruiken. Het valt of staat dus met de kwaliteit van de passphrase. Met de dataversleutelingssleutels en sleutelversleutelingssleutels (wat een woorden) zit het wel goed.
Bij Sophos of i.h.a? Indien het laatste, wat denk je van usb sticks waarvan de hele serie dezelfde sleutel gebruikt, produceert lekker makkelijk. Of een usb drive die aes gebruikt omdat de chip dat zegt te doen, maar niet deed, sorry foutje in de specs. Ook bij password managers is het onderzoek gepresenteerd op de blackhat van maart j.l. echt een openbaring. ................, en dankzij PKCS#5 kun je met een passphrase een sterke sleutel gebruiken. Het valt of staat dus met de kwaliteit van de passphrase. Met de dataversleutelingssleutels en sleutelversleutelingssleutels (wat een woorden) zit het wel goed.
Kortom voldoende aanknopingspunten om mijn poot 2 (implmentatie) en 3 (alles rondom de encryptie sleutel) goed te onderzoeken of gedegen reviews te vinden, als poot 1 in orde is. En volgens mij ook als de leverancier van een leveranciers eigen oplossing zeer betrouwbaar is.
Als je Sophos file based versleuteling toepast (op USB sticks of wat dan ook), wordt elk bestand met zijn eigen sleutel versleuteld.
Maar wanneer de sleutel goed beschermd is, en de implementatie in orde, zie ik geen probleem in het sector based versleutelen van meerdere USB sticks met dezelfde sleutel. Uiteraard moet je zo'n sleutel dan toch niet te lang willen blijven gebruiken. Met Sophos krijgt elke stick trouwens sowieso zijn eigen datasleutel, en delen ze alleen de sleutelversleutelingssleutel (net als bestanden).
En het helpt wanneer een product voorzien is van Common Criteria (EAL3 of hoger) en FIPS (140-2) certificeringen. Dan is in ieder geval de documentatie een beetje op orde :)
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
