Een datalek: wat nu?

Inleiding

Je zou bijna denken dat het aantal beveiligingsproblemen in het afgelopen jaar enorm is toegenomen. Het lijkt er echter meer op dat de media-aandacht voor dergelijke problemen is gegroeid: de problemen komen vaker en sneller naar buiten, en vooral lekken waarbij persoonsgegevens in het geding zijn, doen het goed in de media.

Bedrijven en organisaties lijken zich er nu wel meer van bewust dat íedereen gehackt kan worden: het overkwam bedrijven als Google, RSA, Sony en Comodo, dus elke organisatie, groot of klein, kan de volgende zijn. Een goede voorbereiding kan echter een hoop ellende voorkomen. Tweakers.net zette oorzaken en gevolgen op een rijtje.

Voorkomen

Het gezegde luidt 'voorkomen is beter dan genezen', maar beveiligingsproblemen en datalekken zijn nooit helemaal te voorkomen. Kwaadwillenden zullen altijd nieuwe wegen vinden om binnen te komen: de enige manier om een computersysteem écht goed te beveiligen, is door de stekker er uit te trekken. Dat wil niet zeggen dat bedrijven en organisaties niet hun best kunnen doen om incidenten te voorkomen.

Een beveiliger kan zijn systemen vrijwel onmogelijk beschermen tegen een zero day-aanval: een exploit die gebruikmaakt van een tot dan toe onopgemerkte kwetsbaarheid in software. Hiermee kunnen systemen ongemerkt geïnfecteerd worden. Uit onderzoek van Microsoft blijkt echter dat slechts een miniem deel van de aanvallen zero-daykwetsbaarheden gebruikt.

Aanvalsmethode
Interactie gebruiker	********** 44,8%
Autorun (usb)	****** 26%
Autorun (netwerk)	**** 17,2%
Infecteren bestanden	* 4,4%
Exploit (update geruime tijd beschikbaar)	* 3,2%
Exploit (update beschikbaar)	* 2,4%
Bruteforce-aanval op wachtwoord	* 1,7%
Macro in Office-document	* 0,3%
Zero day-exploit	* 0,0%

Bron: Microsoft

Bijna de helft van alle aanvallen wordt volgens Microsoft veroorzaakt door het handelen van de gebruiker - bijvoorbeeld via social engineering. Je hebt niets aan alle dure beveiligingssoftware als je gebruikers fouten maken die beveiligingsproblemen veroorzaken. Natuurlijk kunnen bedrijven data loss prevention-software inzetten, die controleert of er geen gegevens het bedrijfsnetwerk verlaten die intern hadden moeten blijven, maar het is zeker zo nuttig om personeel te trainen om rekening te houden met dergelijke scenario's.

Uit een beveiligingsrapport van Verizon Business, waarvoor onder andere de Nederlandse politie gegevens heeft aangeleverd, blijkt dat de helft van de beveiligingsincidenten het gevolg is van hacking. In 49 procent ging het om malware, terwijl in 29 procent van de gevallen een fysieke aanval de oorzaak was. Het aantal social-engineeringaanvallen is volgens Verizon veel lager: 'slechts' 11 procent. Belangrijk is dat 92 procent van de aanvallen 'niet erg ingewikkeld' is. Van de aanvallen zou 96 procent zelfs eenvoudig of relatief eenvoudig te voorkomen zijn.

Woordvoerder Barry van Vliet van Trend Micro vertelde Tweakers.net dat zijn bedrijf enige tijd geleden vreemde telefoontjes ontving van mensen die duidelijk meer over het bedrijf wilden weten. "Onze telefoniste is er echter voor opgeleid om daar rekening mee te houden", zegt Van Vliet.

Begin deze maand bleek nog uit onderzoek dat Amerikaanse bedrijven vatbaar waren voor social engineering. 'Aanvallers' konden aan werknemers allerhande informatie ontfutselen, en heel wat werknemers konden er zelfs toe worden verleid om een bepaalde link in te voeren. Dat laatste is natuurlijk een flink beveiligingsrisico; die link zou bijvoorbeeld naar een browser-exploit kunnen verwijzen.

Het is dus van belang om gebruikers van een systeem op te leiden, maar daarnaast is het uitrollen van software-updates ook wel handig. Dat lijkt een open deur, maar de hack op Sony's PlayStation Netwerk had waarschijnlijk voorkomen kunnen worden als alle software netjes up-to-date was gehouden. Ook het uitschakelen van auto-run-functionaliteit op usb-sticks en netwerkschijven lijkt een aanrader.

Sql-injecties

Niet alleen desktop-pc's van medewerkers zijn het slachtoffer: veel aanvallen richten zich op webservers. Ook daarbij geldt dat een aanval nooit voor de volle honderd procent te voorkomen is, maar dat slordige fouten een groot deel van de problemen veroorzaken.

Heel veel beveiligingsproblemen op websites zijn namelijk te wijten aan één redelijk eenvoudig te verhelpen probleem: sql injection. Dat houdt in dat sql-opdrachten in variabelen worden verstopt; als de software de invoer van gegevens niet goed controleert, kunnen die opdrachten worden uitgevoerd. Te veel ontwikkelaars lijken echter nog niet doordrongen van de noodzaak van input validation. Met het sanitizen van user-input kunnen overigens ook xss- oftewel cross site scripting-kwetsbaarheden worden voorkomen.

Beveiliging

Zoals gezegd kan een beveiligingsincident nooit helemaal voorkomen worden. Daarom is het belangrijk om, voor het geval dát er wat fout gaat, een emergency response plan op papier te hebben. "Vaak is zo'n plan er niet", zegt Jelle Niemantsverdriet van Verizon Business, die als consultant optreedt bij beveiligingsincidenten. In andere gevallen gaat het vaak om een standaardtemplate waar de bedrijfsnaam niet eens is ingevuld.

Volgens Niemantsverdriet zit er soms veel tijd tussen een hack en het daadwerkelijk ontvreemden van gegevens. In een derde van de gevallen gaat het daarbij om luttele minuten, maar in 44 procent van de gevallen zit er een aantal dagen tussen deze twee gebeurtenissen. In die dagen zou een aanval dus nog tegengehouden kunnen worden, zonder dat er gegevens verloren gaan. In 14 procent van de gevallen is het een kwestie van uren; bij één op de tien datalekken gaat het om weken of maanden.

De tijd tussen het uitlekken van data en het ontdekken ervan, is nog groter. Minder dan een procent van de databreaches wordt binnen een kwestie van minuten ontdekt. Het grootste deel van de datalekken, 38 procent, wordt zelfs pas na meerdere weken ontdekt, en 36 procent pas na enkele maanden. "Het ontdekken van een datalek gebeurt vaak ook niet door het slachtoffer", zegt Niemantsverdriet. "In veel gevallen wordt die ingelicht door een derde partij, bijvoorbeeld creditcardmaatschappijen, opsporingsdiensten of de pers."

Bron: Verizon

Het op tijd detecteren van beveiligingsproblemen kan veel schade voorkomen. Diverse partijen leveren software die beveiligingsdreigingen opmerkt: naast standaard beveiligingspakketten is er bijvoorbeeld de al genoemde data loss prevention-software. Ook snel actie ondernemen loont: er zitten in 49 procent van de gevallen enkele weken tussen het ontdekken en het dichten van een lek. In 15 procent van de gevallen is het zelfs een kwestie van maanden. Al die tijd kan onnodig schade worden veroorzaakt.

De eerste prioriteit is het vaststellen van een beveiligingsprobleem, waarna het 'bloeden' moet worden gestopt, zegt Niemantsverdriet. Het kan grote problemen opleveren wanneer dat niet gebeurt. Tweakers.net sprak hierover met een medewerker van beveiligingsbedrijf RSA. Bij een aanval op dat bedrijf werd informatie over de werking van SecurID-sleutelgenerators buitgemaakt. Deze generators worden gebruikt voor two-factor-authentication, waarbij naast een wachtwoord ook een willekeurig gegenereerde cryptografische sleutel moet worden ingevoerd, en zijn er zowel in software- als in hardwarevorm.

Volgens de medewerker had de ernst van het lek ingeperkt kunnen worden, wanneer er eerder was opgetreden. "Na de ontdekking van het lek, en dat was vrij snel, keken we eerst nog naar wat er precies gebeurde. Toen zagen we gegevens verdwijnen. Als we eerder alles hadden stilgezet, waren er minder gegevens verloren gegaan." RSA heeft nooit gezegd hoeveel of welke gegevens zijn buitgemaakt, maar uit voorzorg werden alle sleutelgenerators vervangen.

Het is dus zaak om na het ontdekken van een beveiligingsprobleem zo snel mogelijk te handelen. Het inhuren van externe expertise is duur, maar als een bedrijf zelf niet over de relevante expertise beschikt, kan dat toch veel geld besparen.

Externe partijen, zoals Verizon Business of Fox-IT, hebben vaak veel meer expertise dan een 'gewone' ict-afdeling. Zij kunnen bijvoorbeeld forensische kopieën van harde schijven maken om deze te analyseren. Zo'n onderzoek kan dagen of weken duren en dus veel geld kosten, maar het alternatief is vaak dat het beveiligingsprobleem niet wordt opgelost.

Juridisch

Op dit moment is er nog geen meldplicht voor beveiligingsproblemen. Voor telecomproviders komt er wel een meldplicht aan. Die moeten dan 'een inbreuk op de beveiliging' die 'nadelige gevolgen heeft voor de bescherming van persoonsgegevens' aan de OPTA melden. Het is echter nog onduidelijk wat 'nadelige gevolgen' zijn. Deze meldplicht is vastgelegd in de nieuwe Telecommunicatiewet.

Voor andere bedrijven en organisaties heeft deze meldplicht geen gevolgen, maar er wordt wel gewerkt aan een bredere meldplicht voor datalekken. Het is echter nog niet bekend wanneer het voornemen van het kabinet in een wetsvoorstel wordt omgezet.

Het is eveneens nog onduidelijk welke instanties onder die uitgebreidere meldplicht zullen vallen, maar volgens het kabinet krijgen in ieder geval banken en verzekeringsmaatschappijen een dergelijke meldplicht. Zowel het CBP als klanten moeten dan op de hoogte worden gesteld als door een hack of lek persoonsgegevens kunnen zijn ontfutseld.

Niet vrijuit

Dat er nu nog geen meldplicht is, wil overigens niet zeggen dat bedrijven altijd vrijuit gaan wanneer ze persoonsgegevens van klanten laten uitlekken. De Wet bescherming persoonsgegevens eist namelijk dat persoonsgegevens op 'passende wijze' worden beveiligd. Gebeurt dat niet, dan kunnen klanten een rechtszaak wegens een 'onrechtmatige daad' tegen een bedrijf aanspannen, schrijft jurist Mark Jansen van advocatenkantoor Dirkzwager. De vraag is dan hoe goed de gegevens beveiligd zijn, en hoe gevoelig de gegevens zijn. Het uitlekken van medische dossiers zal waarschijnlijk eerder als onrechtmatige daad worden aangemerkt dan naw-gegevens.

Uit onderzoek van Unisys zou blijken dat bijna een kwart van de Nederlanders bij een beveiligingslek juridische stappen zou ondernemen. Of dat echt zo is, is uiteraard de vraag. Volgens ict-jurist Arnoud Engelfriet is het moeilijk aan te tonen dat je schade lijdt door een beveiligingslek. "Bewijs dat maar eens", zegt hij. "De rechter wil graag dat je met bonnetjes komt om je schade te onderbouwen."

Volgens Engelfriet zou het goed zijn als er in de wet een standaardvergoeding voor datalekken zouden zijn. "Winkels mogen bijvoorbeeld standaard 151 euro van winkeldieven eisen, ongeacht hoeveel schade ze kunnen bewijzen. Als bedrijven zoiets moeten betalen aan een gebruiker wiens gegevens zijn ontvreemd, gaan ze bij 30 miljoen records wel wat investeren in beveiliging."

Ook het College bescherming persoonsgegevens kan actie ondernemen als een bedrijf onzorgvuldig met persoonsgegevens omgaat. Anders dan veel mensen denken, is het CBP allerminst een tandeloze tijger. Het CBP mag overtredingen van de privacyregels onderzoeken en informatie opeisen. Ook het opleggen van een dwangsom behoort tot de mogelijkheden. Bovendien kan een publieke terechtwijzing van het CBP voor imagoschade zorgen.

De privacywaakhond heeft tot dusverre echter nog maar weinig van zich laten horen. Er zijn wel enkele ziekenhuizen op de vingers getikt vanwege een matige beveiliging, maar het is voor zover bekend nog niet gebeurd dat het CBP na een beveiligingslek actief onderzoek verichtte. Naar verwachting zal een meldplicht daar wel verandering in brengen.

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)

[Smen]

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.

[zvbhvb]

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.

[Dreamvoid]

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 23 juli 2024 17:39]

[cariolive23]

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.

[zeduude]

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?

[zvbhvb]

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.

[edvliet]

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.

[H!GHGuY]

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.

[ByteMe_]

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.

[Sniffert]

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

[Kevinp]

En wat dacht je van alles up to date houden

[Lummer]

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.

[Verwijderd]

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

[ari]

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.

[Verwijderd]

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.

[morrowyn]

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.

[Verwijderd]

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.

[Verwijderd]

Het gebruik van een degelijk framework lost al zo'n gigantisch deel van deze (vaak vrij lompe) fouten op.

[Reinstein]

Mogelijk nadeel van een framework is dat de sourcecode beschikbaar is en dat mogelijke exploits makkelijker te vinden zijn.

[OrangeTux]

Dit geld voor goedwillende en kwaadwillende mensen.

[cariolive23]

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?

[djc]

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.

[azerty]

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 23 juli 2024 17:39]

[Sjnirk]

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

[Verwijderd]

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 Verwijderd op 23 juli 2024 17:39]

[bouvrie]

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?

[hackerhater]

In geval van buiten de WWW gekomen niet meer vertrouwen naar mijn mening
opnieuw installeren die hap

[bouvrie]

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.