Hoe om te gaan met privacy-gevoelige data

[Vexxon]

Hallo,

Ik heb een klant en die wil een applicatie laten ontwikkelen waarin hij privacygevoelige data kan beheren.
Aangezien hij deze applicatie van verschillende plekken wil kunnen gebruiken zal het een webapplicatie worden, hierdoor wil ik deze applicatie en de bijbehorende data zo goed mogelijk beveiligen.

Mijn plan:
1. Https! Verdere uitleg lijkt me niet nodig
2. Inloggen in de applicatie gaat via two step authenticatie
3. Data encrypten. De betreffende data bestaat uit meer dan 100 velden en ik vraag me af hoe ik dit ga beveiligen/encrypten. Kan iemand mij voorzien van advise hoe ik dit het beste kan aanpakken en hoe?

[RobIII]

Vexxon schreef op dinsdag 08 september 2015 @ 16:33:

3. Data encrypten. De betreffende data bestaat uit meer dan 100 velden en ik vraag me af hoe ik dit ga beveiligen/encrypten. Kan iemand mij voorzien van advise hoe ik dit het beste kan aanpakken en hoe?

En wat heb je, per onze Quickstart, zélf al gezocht, gevonden, geprobeerd, gelezen etc.?

[NMe]

Je bent zo zwak als je zwakste schakel. Je kan perfect beveiligen met allerlei encryptie en dergelijken, maar als je file system compromised raakt, dan heeft iemand al snel je encryptiesleutels, want die staan in je code of worden van daaruit gebruikt. Je kan prima HTTPS gebruiken, maar als je site vervolgens kwetsbaar is voor SQL-injectie dan heb je alsnog niks.

Er zijn echt talloze hacks om aan data te komen en in veel gevallen maakt het niet uit hoe veilig je de ramen en deuren dichttimmert, want als je de achterdeur open laat komt die inbreuker toch wel binnen.

[Vexxon]

Mijn eerste bevindingen zijn, met betrekking to encryptie, is om de unieke keys per data record te gebruiken en deze niet in de website op te slaan maar in de database. Verder configuratiebestanden versleutelen zodat de connectionstring niet 'makkelijk' te achterhalen valt.

[Killah_Priest]

Vexxon schreef op dinsdag 08 september 2015 @ 18:15:
Mijn eerste bevindingen zijn, met betrekking to encryptie, is om de unieke keys per data record te gebruiken en deze niet in de website op te slaan maar in de database. Verder configuratiebestanden versleutelen zodat de connectionstring niet 'makkelijk' te achterhalen valt.

Even heel simpel gedacht hoor, maar als je de keys om te decrypten in dezelfde DB bewaart als de data dan heb je toch alleen de DB nodig om erbij te kunnen komen?

Ik denk dat het ook wel de moeite waard is om het deel beveiliging (ik weet natuurlijk niet voor welk platform je dit ontwikkeld) voor een deel bij de klant zelf neer te leggen : het encrypten van de data in de DB is natuurlijk jouw pakkie aan : het inloggen zou je echter als het om een Windows omgeving gaat via AD af kunnen handelen, dan is dat simpelweg voor de klant om verder te beveiligen.

En waar moeten wij aan denken bij 100 velden data per record? Strings, images?

[ Voor 4% gewijzigd door Killah_Priest op 08-09-2015 18:56 ]

[NMe]

Killah_Priest schreef op dinsdag 08 september 2015 @ 18:54:
[...]

Even heel simpel gedacht hoor, maar als je de keys om te decrypten in dezelfde DB bewaart als de data dan heb je toch alleen de DB nodig om erbij te kunnen komen?

Da's inderdaad net zoiets als de sleutel van Fort Knox onder de deurmat leggen.

[Vexxon]

Even heel simpel gedacht hoor, maar als je de keys om te decrypten in dezelfde DB bewaart als de data dan heb je toch alleen de DB nodig om erbij te kunnen komen?

True, maar wat is het alternatief.
De keys in een andere database opslaan?

Het gaat waarschijnlijk om rond de 100 velden voornamelijk strings.

[RobIII]

Besef ook dat eens encrypted de strings in essentie waardeloos zijn om er bijv. in te kunnen zoeken MSSQL biedt o.a. "transparante" encrypted storage op file niveau tot kolomniveau en een fatsoenlijk rechtenmodel maar andere RDBMS'en bieden dat vaak (in meer of mindere mate) ook.

[pedorus]

Desnoods encrypt je de partitie. Ik zou niet moeilijk gaan doen met een soort custom oplossing waarbij zowel key en data beschikbaar zijn, dat is alleen maar een leuke uitdaging voor een hacker die vooral onnodige complexiteit toevoegt.

Vergeet ook certificate pinning niet, indien mogelijk (bij niet-browser app sowieso mogelijk). Daarnaast heb je bij dit soort applicaties vaak security audits en dergelijke, eisen aan de hosting, penetratietests, enz.

[lordsnow]

Dit is wel een mooie introductie:
MSDN: Design Guidelines for Secure Web Applications

[Orion84]

OWASP is ook een goed startpunt voor informatie over beveiliging van webapplicaties. En bekijk ook eens de informatie van het CBP (minder technisch, maar gezien je het specifiek over privacy gevoelige data hebt kan dat wel nuttige achtergrond info geven).

Behalve de daadwerkelijke beveiligingsmaatregelen in de applicatie (toegangscontrole, encryptie) is een belangrijk punt ook de controle van de applicatie zelf. Dus voorkomen dat je programmeerfouten maakt waardoor je kwetsbaarheden introduceert (zoals SQL injectie). Op dat vlak is OWASP wel een nuttige informatiebron. Ik weet niet over wat voor schaal en budget we het hier hebben en hoe gevoelig de data is, maar je zou kunnen overwegen om je code door een gespecialiseerde partij te laten testen.

[Gomez12]

pedorus schreef op dinsdag 08 september 2015 @ 20:30:
Desnoods encrypt je de partitie.

Gewoon even uit nieuwsgierigheid, wat voegt dit toe?
Ik neem aan dat je niet vol-continu de partitie zit aan / af te koppelen per request dus dat ding zal 24/7 unencrypted beschikbaar zijn voor alles behalve zo ongeveer het eruit trekken van de hdd bij de hoster.

Ik zie het nut er niet echt van in zegmaar... Je kan het aanzetten als het relatief "gratis" is (bitlocker ik meen zfs etc) maar een grotere storage array zal dat ook gewoon goed verzorgen.
En ik heb ook wel eens constructies gezien met truecrypt etc maar daar wil je helemaal niet aan beginnen qua overhead etc.

[pedorus]

Het voegt dan ook niet zo heel veel toe inderdaad. Als er een echte gerichte inval is, dan zal men de encryptiesleutels weten te achterhalen als de machines aan staan op dat moment. Alleen tegen 'per ongeluk' uitlekken zal het ietsje toevoegen. In principe moet je gewoon zorgen dat het datacentrum goed genoeg beveiligd is.

Edit: linkje over deze evengoed 'best practice': https://cloud.google.com/...are_tracking_and_disposal
En:

quote: http://security.stackexch...ure-data-center-pointless

Two generic things you apparently have missed:

In case of disk failure, having the data encrypted at rest solves the issue of having potentially sensitive data on a media you can't access any more. It makes disposing of faulty drives easier and cheaper (and it's one less problem)

Full disk encryption also makes it harder for an attacker to retrieve data from the "empty" space on the drives (which often contains trace of previously valid data)

And if you're using VMs:
[...]

[ Voor 56% gewijzigd door pedorus op 08-09-2015 22:35 ]

[Gomez12]

RobIII schreef op dinsdag 08 september 2015 @ 20:23:
Besef ook dat eens encrypted de strings in essentie waardeloos zijn om er bijv. in te kunnen zoeken MSSQL biedt o.a. "transparante" encrypted storage op file niveau tot kolomniveau en een fatsoenlijk rechtenmodel maar andere RDBMS'en bieden dat vaak (in meer of mindere mate) ook.

Net afhankelijk van hoe gevoelig je data is is het hierbij ook weer de vraag : Wat staat er in je geheugen?

Het is helemaal fantastisch om alles transparant encrypted op disk te hebben staan, maar als je data en / of je indexen gewoon unencrypted in het geheugen staan dan heb je alsnog een gaatje.

In wezen zeg ik voornamelijk dat encryptie gewoon een afweging tussen snelheid en veiligheid is. Wil je snel iets kunnen zoeken dan moet je zoeken door of de unencrypted data, of je moet een algemene sleutel hebben zodat je je zoek-entry kan versleutelen en daarmee kan zoeken (let wel op dat dit de echt bruikbare encryptie methodes zo ongeveer tot 0 reduceert, want dit werkt voornamelijk leuk bij Rot-13 systemen oid).
Maar optie 2 valt al weer af als je data per klant wilt versleutelen.

Oftewel : Wil je überhaupt erdoorheen kunnen zoeken? Of is dat helemaal niet nodig en moet je enkel detail-pagina's kunnen opbouwen met privacy gevoelige data en gebeurt het zoeken op andere velden.

[GrooV]

Als je het encrypted in DB opslaat los je dit ook niet op, de data zal toch ooit een keer unencrypted naar de klant moeten (HTTPS encryptie niet meegeteld aangezien deze alleen transport is). Je kan wel https en 2fa gebruiken maar als je hosting erg brak is heeft dit nog steeds weinig nut, zoals al eerder gezegd is, je bent zo sterk als de zwakste schakel.

Je zult eisen moeten gaan stellen aan je hosting provider en een audit laten doen op je code. Verder zal je in je code en infrastructuur aanpassingen moeten doen (audit logging, firewall, ed)

Enige echte 100% encryptie is het clientside gaan encrypten, echter kan je dan niet meer zoeken of andere intensieve dingen doen en lijkt me ook niet praktisch

[BlueZero]

Je moet nadenken over de volgende vragen:
- Hoe privacy gevoelig is je data?
- Wat zijn je toegangspunten tot die data
- Voor wie wil je de data per toegangspunt afsluiten.

Stel dat ik een chatapplicatie maak met end-to-end encryptie dan heb je het over Cliënt side versleuteling en ontsleuteling waarbij de private-key/salt alleen beschikbaar is bij de eindgebruiker.

Echter stel dat je heel je database versleuteld en je login is zo zwak dat ik met gemak in je beheer kan komen dan heb je er nog erg weinig aan.

Server:
- Sluit alle poorten die je niet nodig heb
- Open poorten voor (SSH, MySQL etc) alleen voor localhost en jouw ip adres
- Zorg voor software die up to date is.
- Gebruiker unieke en veilige gebruikersnamen en wachtwoorden voor alle diensten (SSH, MySQL)

Code:
- Filter overal alle POST/Header/Sessie data.
- Versleutel Sessie data
- En check OWASP zoals hierboven aangegeven is.

[Juup]

Dit is de OWASP top 10:

1. Injection
2. Broken Authentication and Session Management (XSS)
3. Cross Site Scripting (XSS)
4. Insecure Direct Object References
5. Security Misconfiguration
6. Sensitive Data Exposure
7. Missing Function Level Access Control
8. Cross Site Request Forgery (CSRF)
9. Using Components with Known Vulnerabilities
10. Unvalidated Redirects and Forwards

[Knutselsmurf]

De technische implementatie is slechts een klein onderdeel van het correct omgaan met privacygevoelige gegevens.
Voor de zorg (medische gegevens) is een en ander vastgelegd in een aantal NEN-normen:

• NEN 7510 Informatiebeveiliging in de zorg
• NEN 7512 Informatiebeveiliging in de zorg – Vertrouwensbasis voor gegevensuitwisseling
• NEN 7513 Medische informatica – Logging – Vastleggen van acties op elektronische patiëntdossiers

Let wel, hierin staan geen technische zaken beschreven. Er staat dus niet in hoe je één en ander moet beveiligen, maar er staat wel in wat je moet beveiligen.