Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door Joost Schellevis

Redacteur

Een datalek: wat nu?

Het grote publiek

De grote vraag is: moet je je gebruikers - en daarmee ook het grote publiek - op de hoogte stellen van een beveiligingsprobleem waarbij persoonsgegevens zijn uitgelekt?

Als een bedrijf openheid van zaken aan zijn klanten geeft, bevestigt het dat persoonsgegevens zijn uitgelekt. Klanten kunnen dat als bewijs gebruiken om schade te claimen, zegt Jansen.

Het alternatief brengt echter ook bezwaren met zich mee: als persoonsgegevens uitlekken en klanten lopen als gevolg daarvan gevaar, bijvoorbeeld doordat hun creditcardgegevens worden misbruikt, kan het getroffen bedrijf aansprakelijk worden gesteld. Een bedrijf kan zijn klanten dan beter maar inlichten. Dat kan zelfs nuttig zijn als een klant een schadevergoeding claimt, stelt Jansen: "Als een klant weet dat zijn gegevens zijn gestolen, en hij doet niets om zichzelf te beschermen, dan kan de rechter zeggen: dat is je eigen schuld."

De media

Als je een groot aantal gebruikers op de hoogte brengt van een datalek, dan is de kans groot dat een van hen de media tipt. Het is dan wellicht beter om zelf naar de media te stappen, om zo eventuele imagoschade te beperken.

Volgens Aaron Barr, wiens beveiligingsbedrijf eerder dit jaar werd gehackt, is er bovendien een morele verplichting tegenover gebruikers. "Het is alleen wel moeilijk om te bepalen wat je vrij wil geven", zei hij op de RSA-beveiligingsconferentie in Londen.

Burgerrechtenbeweging Bits of Freedom vindt dat bedrijven hun klanten op de hoogte moeten stellen als ze gevaar lopen. "Je hebt daar ook zelf baat bij. Je laat zien dat je je klanten serieus neemt", zegt Daphne van der Kroft, juriste van Bits of Freedom. Volgens Van der Kroft gebeurt het dat mensen spookfacturen ontvangen voor zaken die ze nooit hebben besteld, omdat hun gegevens bij een datalek zijn buitgemaakt door kwaadwillenden.

Als klanten daar direct van op de hoogte worden gesteld, kunnen ze maatregelen nemen. Bits of Freedom wil dan ook dat datalekken waarbij persoonsgegevens in het spel zijn, in een soort openbaar register verschijnen. "Daardoor komt er druk op organisaties om hun beveiliging te verbeteren", zegt Van der Kroft.

Als bij een datalek geen persoonsgegevens worden gestolen, maar bijvoorbeeld alleen intellectueel eigendom, is er minder noodzaak om de media op de hoogte te stellen, al zijn er uitzonderingen. Een voorbeeld daarvan is de aanval op RSA. De hackers bemachtigden informatie die gebruikt kan worden bij een aanval op SecurID-sleutelgenerators, waardoor ook klanten risico liepen. RSA stapte daarom wel naar de media.

Tot slot

Een datalek is nooit volledig te voorkomen. Het scheelt echter een hoop als bedrijven en instanties zich bewust zijn van de risico's, en daar ook naar handelen. Het tijdig bijwerken van software en werknemers leren hoe met social engineering om te gaan is een goed begin. Het is echter ook belangrijk dat organisaties weten wat ze moeten doen als er onverhoopt toch een hacker door de beveiliging komt.

Reacties (40)

Wijzig sortering
Los van het argument dat zeedude aandraagt, - dat er niet echt concrete (danwel uitgewerkte) mogelijkheden worden genoemd om een datalek te voorkomen - mis ik een ander aspect.

Er wordt nu in de conclusie gesteld dat:
"Het scheelt echter een hoop als bedrijven en instanties zich bewust zijn van de risico's, en daar ook naar handelen. Het tijdig bijwerken van software en werknemers leren hoe met social engineering om te gaan is een goed begin."

Dit gaat compleet voorbij aan de vraag wanneer een bedrijf zich bewust zou moeten zijn van de risico's. Met andere woorden, vanaf welk moment is er sprake van een risico?


De vraag wat wanneer een risico is, en de tot op welke hoogte hinder acceptabel is vind ik persoonlijk een veel interessantere discussie. Ik vind dat er nogal makkelijk door IT-ers en beveiligingsexperts wordt geroepen dat bedrijven de zaken niet op orde hebben.

Is het niet veel beter om te kijken wat de mogelijke gevolgen zijn van een datalek, daarvan bepalen wat vereist en wenselijk is en die vereisten bijvoorbeeld wettelijk verplicht te stellen? Hiervoor kun je dan verzekeringsproducten ontwikkelen (net als bij inbraak), maar dan heb je wel direct duidelijk waar je als bedrijf (!) aan moet voldoen. Een soort wettelijk verplichte ISO-normering voor 'online'?

Door inzichtelijk te hebben wat er precies op welke manier beveiligt kan worden (nb. zoals ook de auteur niet echt concreet aangeeft in dit artikel) is voor alle partijen duidelijk wat er moet gebeuren. En heb je veel eenvoudiger het aansprakelijkheids-issue opgelost in het geval van een data-lek.

Nu krijgt de plaatselijke winkelier die naast zijn 25 jarig werkbestaan een webwinkel heeft geopend met open source software behoorlijk wat extra verplichtingen als hij altijd aan de laatste veiligheidseisen moet voldoen.

En dan is dit slechts één specifiek voorbeeld vanuit de 'online' kant. Andere invalshoeken als bedrijfsgrootte, omzet, afzetmarkt/branche, klant(groep), fysieke locatie, werknemerspolicies etc. voor het gemak even buiten beschouwing gelaten.
Die winkelier kan zijn website toch veel beter laten hosten?

Vanaf het moment dat je een iso certificaat hebt gaat de 0day/datalek teller gestaag verder.

ISO is best leuk om processen wat inzichtelijker te maken, maar dan nog een moment opname.

Het laatste waar we op zitten te wachten is noch meer wetten en verplichtigingen.
Het is direct alleen voor de verkoper van die verzekerings producten aantrekkelijk zonder dat de "veiligheid" concreet verhoogt wordt.
Het is natuurlijk ook niet voor niets dat steeds meer bedrijven gewoon kant en klaar bij Amazon in het rek gaan hangen als Merchant. Ja het kost geld en je kan je moeilijker onderscheiden, maar je eigen webshop runnen is gewoon niet zo makkelijk als het lijkt.

[Reactie gewijzigd door Dreamvoid op 25 november 2011 13:28]

Nu krijgt de plaatselijke winkelier die naast zijn 25 jarig werkbestaan een webwinkel heeft geopend met open source software behoorlijk wat extra verplichtingen als hij altijd aan de laatste veiligheidseisen moet voldoen.
En wat heeft "open source" hier dan mee te maken? Dit is net zo veilig of onveilig als closed source software. De licentie vorm zegt niets over de kwaliteit van de software, dat is afhankelijk van de programmeurs. En prutswerk kom je overal tegen, maak je geen illusies.

Software leveranciers zijn nergens voor aansprakelijk te stellen, zie hun leveringsvoorwaarden. En mochten ze toch aansprakelijk zijn, dan is de maximale vergoeding die je kunt krijgen, zo hoog als de licentiekosten die je zelf eerst hebt betaald. De bekende sigaar uit eigen doos.

De licentie vorm heeft niets te maken met de beveiliging, zijn twee verschillende dingen.
mooie informatie, maar ik mis concrete methodes om die datalekken te voorkomen:

- regelmatige security audits (backtrack)

- verificatie code (escaped queries, met een regex kom je al een heel eind, maar uiteindelijk is t altijd verstandig om echt in je code te kijken)

- ids (Host based en of network based):
- ossec -- dmv hashes je data-integriteit verifieren
- suricata/snort -- valt r iemand iets aan?
- fail2ban -- dmv log-scans blokkeren
- honeypots ? preventief loggen van mogelijke portscans/attacks
- andere?

- firewall regels verifieren
- bekende blacklists , als je bijv niets te maken hebt met bepaalde landen zoals tailand kan je de aan dat land aangewezen ip blokken blokkeren.

- ports dichtgooien die niet nodig zijn, eventueel bepaalde services over een ander netwerk te draaien : ssh alleen toegankelijk over je vpn

iemand verder nog idee-en? alu hoedjes? :P
Ipv een honeypot bedoelde je zeker een tarpit. Een honeypot zul je niet zo vaak tegenkomen bij een productie systeem maar eerder bij onderzoekers van malware en dergelijke.

Wat ik mis is vergeten inventaris wat nog aan het net hangt.
Mischien ook wel eens handig om te kijken of bepaalde trust relaties wel scherp genoeg zijn zodat oneigenlijk gebruik niet alsnog via een omweg mogelijk is. Beter nog een gecoordineerde samenwerking, scheelt ook nog eens pieken.
Een mooi verhaal Joost.

Toch merk ik dat het woord 'datalek' te beperkt wordt omschreven.
Een datalek is "bedoeld of onbedoeld belangrijke informatie lekken binnen en buiten een organisatie."

Andere situaties van datalekken zijn bijvoorbeeld:
* Dat bestanden per ongeluk op de verkeerde plaats gezet worden, zodat ze gewoon vanaf internet gezien kunnen worden (onder andere door google)
* Verliezen van PC's, USB stick
* Datadiefstal en datamisbruik door de interne medewerker.
* Gebruik van productiedata in niet-productie omgevingen.

Datadiefstal en datamisbruik
Quote: "Bijna de helft van alle aanvallen wordt volgens Microsoft veroorzaakt door het handelen van de gebruiker - bijvoorbeeld via social engineering."
Ook hier wordt dus blijkbaar alleen gedacht aan de situatie vanuit de hacker.
Kortgeleden in Security.nl: "Een goed betaalde werknemer is gevaarlijker dan hackers."

Productiedata in niet-productie omgevingen
Het is ook eens goed om de beveiligers eens te wijzen dat hun focus niet alleen op een productie omgeving ligt, maar ook niet-productie omgevingen.
Gartner heeft aangegeven van 80% van de bedrijven nog werken met productiedata in niet-productieomgevingen voor doeleinden waar de data niet voor bedoeld is. Deze percentage geldt ook in Nederland met de overheid voorop. Gelukkig vallen veel financiële instellingen onder die resterende 20%.
Volgens de privacywetgeving mag men de privacygevoelige gegevens om de contractuele afspraken na te komen en de bedoelde diensten te leveren. Software ontwikkeling, kwaliteitsborging en testactiviteiten maken daar geen deel van uit.
Toch zijn er bij veel bedrijven dat er nog steeds een kopietje wordt gehaald uit productie en wordt gebruikt voor testactiviteiten.
De aandacht van security is veel lager op testomgevingen, dan de productie omgevingen. De inhoud is gelijk. Het datalek van CheapTickets.nl heeft dit wel weer eens bevestigd.
Veel meer mensen toegang toe, rechten worden breder uitgegeven, etc.

Door het gebruik van productiedata in testomgevingen kunnen ook situaties ontstaan dat er per ongeluk nog een linkje naar de buitenwereld open staat; dat er per ongeluk duizenden SMS'jes worden verstuurd; noem maar op.

Ook dit zijn datalekken en die aandacht is er momenteel nog helemaal niet.

Ga vooral door met zulke artikelen, dat vergroot de bewustwording.
Een belangrijk aspect wordt toch ook veelal over het hoofd gezien: authorisatie.

Door data af te schermen voor gebruikers binnen de organisatie, kun je de risico's van social engineering beperken.

Bijvoorbeeld bij een document control system krijgt bij het inchecken van een document het volledige team onder 1 of 2 management niveau's boven de werknemer toegang tot het document. Gebruikers van andere afdelingen, hoeven zo'n documenten typisch niet in te kijken. Mocht het toch nodig zijn, dan kan toegang manueel gegeven worden.
Bij een inbraak bij 'finance' liggen dan zeker geen gegevens van 'R&D' op straat en omgekeerd.

Eens je zo'n systeem hebt kun je ook behavioral auditing toepassen. Als een gebruiker plots veel documenten opvraagt dan is er mogelijk iets mis (los van het feit of de gebruiker dit al dan niet moedwillig doet).

Ook splitsing van databases kan de impact van datalekken beperken. Als ik me niet vergis past de winkelketen Colruyt in België dit toe. De database met aankopen bevat geen persoonsgegevens (behalve een ID). Een afzonderlijke database met beperktere toegang bevat dan die persoonsgegevens, zonder andere data.

Bij het opstellen van gepersonaliseerde reclame-folders wordt eerst het systeem met aankopen geraadpleegd en wordt de folder samengesteld. Die geprepareerde folder wordt dan door een ander systeem voorzien van de NAW gegevens voor verzending.
Ben het er zeker mee eens dat niet alles altijd te voorkomen is. Maar veel bedrijven/medewerkers zouden meer accuraat moeten zijn met het bijwerken van verouderde software.
Dat laatste zeker, maar bij het ontwerp van eigen software of bij het inrichten van een eigen website zijn eigenlijk 3 aspecten van belang:
+ Valideren van de input; zodat de gebruiker niet alles zomaar kan invoeren.
+ Verwerken van de input; stel dat er alsnog kwaadaardige input kan worden ingevoerd, moet bijvoorbeeld het aantal worden beperkt.
+ Valideren van de output, het systeem moet niet meer teruggeven aan de gebruiker dan nodig, bijvoorbeeld het voorkomen dat foutmeldingen worden gegenereerd
En wat dacht je van alles up to date houden :)
Soms dat is de wil er wel. Maar de middelen niet. Soms is de klant er lastig te overtuigen dat zijn site nodig een update nodig heeft. En alles gratis doen kan ook niet.
Inderdaad, maar als de klant niet wil betalen, dan kun je er als ontwikkelaar niets aan doen.

Het enigste wat je dan zou kunnen doen is de klant er op wijzen dat er beveiligings problemen zijn en je dat voor een "zacht" prijsje wilt doen, wat dan het "zachte" prijsje is mag je zelf invullen ;)
Je kunt dan ook besluiten dat je daar je naam niet aan wil verbinden. Dat is even jammer van de inkomsten, maar ik vind dat je als professional moet weten dat je geen prutswerk hoort af te leveren, puur omdat een klant dat wil.
Als dat je insteek is heb je geen enkele klant kan ik je vertellen. Ook beveiliging is (altijd) een kosten/risico afweging. Het is ook voor een groot gedeelte aan je klant om die afweging te maken, het is aan jou als professional om een goed inzicht in de risico's te geven zodat je klant een overwogen besluit kan nemen.
Heel leuk en aardig, maar zodra je dependencies hebt en je software iets complexer wordt, is het valideren niet meer zo eenvoudig.

Daarnaast moeten de programmeurs ook kennis hebben van hacken om dit soort praktijken te begrijpen en tegen te gaan.

It takes one to catch one ...

Om maar niet te spreken van security-audits die je als bedrijf kan laten uitvoeren op je software om zo dingen te voorkomen en tijdig te repareren.

Echter, zoalng er geen doden bij vallen zullen dit soort zaken weinig prioriteit hebben.
Software ontwikkeling is niet eenvoudig (als je het goed wilt doen). Niet heel veel mensen kunnen dit echt goed (zie de krapte op de arbeidsmarkt). En van die groep is maar een heel klein deel wat ook iets van beveiliging weet/snapt. Basale dingen mag je wel van een doorsnee ontwikkelaar verwachten maar als er echt kritieke data in het spel is wordt een speciale persoon in het team van levensbelang. Mijns inziens kun je niet van ontwikkelaars verwachtten dat ze veilige code afleveren. Ja je mag verwachten dat basale dingen als parameterized queries en dat soort dingen worden afgevangen maar het 'hackproof' maken van een website is een vak apart en vereist een specialist.

Al is het alleen al omdat het qua ontwikkelwerk lastig is om all ontwikkelingen bij te houden, op security gebied gaat dat nog veel harder. In mijn ogen is het onredelijk om van een ontwikkelaar te verwachtten dat hij up to date is met alle security problemen.
Het gebruik van een degelijk framework lost al zo'n gigantisch deel van deze (vaak vrij lompe) fouten op.
Mogelijk nadeel van een framework is dat de sourcecode beschikbaar is en dat mogelijke exploits makkelijker te vinden zijn.
Dit geld voor goedwillende en kwaadwillende mensen.
Mogelijk nadeel van een framework is dat de sourcecode beschikbaar is en dat mogelijke exploits makkelijker te vinden zijn.
Dat is in mijn ogen een voordeel! Security doe je niet by obscurity |:(

Toon maar aan dat het veilig is, dat er geen exploits in zitten. En mocht er toch een probleem zijn, dan kun je deze ook fixen. Met een gesloten systeem kan dat niet en weet je niet goed waar je aan toe bent. Ga jij gokken met de veiligheid van jouw data?
Vraag me af of onder "passende wijze" verstaan kan worden dat wachtwoorden niet als plaintext worden opgeslagen. Was toch weer verbaasd om van WoningNet mijn eigen wachtwoord retour te krijgen... Wat mij betreft zou elke enigszins capabele web developer nu toch wel zou moeten weten dat een password gehashed wordt opgeslagen, bij voorkeur inclusief een salt.
Laatste keer dat ik zo iets opgemerkt had (mijn wachtwoord gewoon in email krijgen bij 'wachtwoord vergeten') en de developer erop gewezen had, meldde mij deze doodleuk dat ik niet kon afleiden uit het feit dat het wachtwoord wel terug gemaild kon worden en niet gereset moest worden, of de wachtwoorden al dan niet versleuteld opgeslagen werden... Tenzij ze symmetrysche versleuteling zouden gebruiken is het natuurlijk het geval niet...


OT: zelf als webdeveloper probeer ik alles zo goed als mogelijk te doen en zoveel mogelijk gevallen te voorzien... Nog geen problemen gehad gelukkig :)

[Reactie gewijzigd door azerty op 25 november 2011 23:42]

Ik mis wel een paar zaken die bedrijven kunnen gebruiken als ze gebruik maken van diensten van een google bijvoorbeeld. Volgend artikel geeft ook wel een mooi overzicht.

http://www.norea.nl/readf...c%20Cloud%20computing.pdf
RSA is nogsteeds niet eerlijk over de actie.

Niet alle tokens zijn vervangen. RSA meldt aan leveranciers: Je moet het zelf inschatten. Tokens met een valid date van over 1 jaar worden gratis vervangen als gewenst. Alles onder een jaar moet betaald voor worden.

[Reactie gewijzigd door 194673 op 25 november 2011 10:23]

Allemaal leuk en aardig dat men het veelal heeft over het voorkomen van lekken, maar hoe krijg je inzichtelijk dat een lek daadwerkelijk heeft plaatsgevonden / is geëxploiteerd?

Hoe is te bepalen dat een ongeautoriseerd toegang tot het systeem heeft plaatsgevonden, en welke acties hierbij mogelijk zijn uitgevoerd cq gegevens zijn ontvreemd?

Het lijkt me dat alle handelingen op het systeem gelogd moeten worden. Maar in het ergste geval kan de aanvaller deze logs ook weer wissen... En betreffende websites, zit men tegenwoordig vaak op een virtuele host, met louter toegang tot een FTP danwel SQL service. Verdere beveiligingsissues dienen dan door de host opgelost te worden oid?
In geval van buiten de WWW gekomen niet meer vertrouwen naar mijn mening
opnieuw installeren die hap
Kwestie blijft: hoe weet men dat er iemand 'buiten de WWW is gekomen'?

Een SHOW DATABASES/DESCRIBE/SELECT * statement direct via commandline aan mysql gevoerd kan in de meeste gevallen onopgemerkt blijven lijkt me. En de mysql credentials zijn in de config files van de WWW in kwestie terug te vinden.

Op dit item kan niet meer gereageerd worden.


Apple iPhone 11 Nintendo Switch Lite LG OLED C9 Google Pixel 4 FIFA 20 Samsung Galaxy S10 Sony PlayStation 5 Politiek en recht

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2019 Hosting door True