5 dingen die we geleerd hebben na een Notice and Takedown Request

11 mei 5 dingen die we geleerd hebben na een Notice and Takedown Request

Notice and Takedown Request?

De hostingprovider van Guardian360 ontving op 4 mei ’s morgens een ‘Notice and Takedown Request’ van het security operations center (soc) van een grote Nederlandse organisatie. Deze organisatie had geconstateerd dat er een website gehost werd met als doel het achterhalen van gegevens van bezoekers. Om te voorkomen dat ingevoerde gegevens misbruikt zouden gaan worden en er nog meer gegevens buitgemaakt zouden worden, heeft de Nederlandse organisatie aan de hostingpartij verzocht de website offline te brengen.

Wat was er aan de hand?

De betreffende website was door Guardian360 ontwikkeld voor haar Phishing As A Service dienst. (https://www.guardian360.nl/oplossingen/phishing-as-a-service/) Met deze dienst meten we of medewerkers van opdrachtgevers bewust zijn op het gebied van informatiebeveiliging. We meten bijvoorbeeld hoeveel e-mail ontvangers de mail openen, op een link klikken en/of gegevens achterlaten.

Belangrijk om te vermelden is dat wij de testen alleen uitvoeren op verzoek van een klant en emails alleen richten aan mensen die een email adres hebben binnen het bedrijfsdomein. De opdrachtgever levert zelf deze adressen aan, daardoor gaat het altijd om een gecontroleerde groep die de emails ontvangt. Daarnaast slaan wij de ingevoerde gegevens niet op, wij registreren alleen dat een van de ontvangers op de link in de email geklikt heeft en gegevens achtergelaten heeft.

Wat is het doel van de Phishing As A Service dienst?

Met behulp van onze rapportage kunnen klanten bepalen of ze het bewustzijn niveau acceptabel vinden, of dat ze bijvoorbeeld elearning gaan inzetten om het te verhogen. Om na een maand of drie een nieuwe test uit te voeren, op basis van een ander scenario, zodat verbeteringen zichtbaar worden.

Het goede nieuws is dat een minimaal een medewerker van onze klant zo bewust is, dat hij/zij een phishingmelding gedaan heeft bij de Nederlandse organisatie.

Het slechte nieuws is dat onze goed bedoelde actie ertoe geleid heeft dat een aantal instanties onnodig gealarmeerd is. Voor ons aanleiding om het gehanteerde scenario niet meer in te zetten en “lessons learned” te onderkennen.

Wat hebben we geleerd?

1. Dat minimaal een medewerker van onze klant zo bewust is, dat hij/zij een phishingmelding gedaan heeft;
2. We hebben het in Nederland best goed op orde! Binnen een dag na de phishingmelding werd onze hostingprovider benaderd door het soc van de Nederlandse organisatie. Daarnaast acteerde de security officer van SIDN ook snel en waren de communicatielijnen kort. Hulde!
3. In lijn met voorgaande punt: omdat we een .nl domein gebruikten werden er een aantal Nederlandse organisaties aangehaakt waardoor een en ander sneller verliep. Wanneer we een ander top level domein hadden gekozen was alles waarschijnlijk veel minder snel, efficiënt en effectief gegaan.
4. Om een goede phishingcampagne op te zetten moet deze zo realistisch mogelijk zijn. Daarvoor is het nodig om (mogelijk) inbreuk te maken op auteursrecht en andere rechten. Hier is nog geen passende wetgeving voor en/of jurisprudentie over. Daardoor opereren we nu in een grijs gebied en wordt ons werk bemoeilijkt. We blijven zoeken naar manieren om zo realistisch mogelijk te testen en de overlast voor derden te minimaliseren.
5. Binnen de organisatie van de opdrachtgever wil je dat er enerzijds zo min mogelijk mensen op de hoogte zijn van de test en anderzijds wil je dat abuse meldingen in eerste instantie binnen de organisatie van de opdrachtgever opgevangen worden. Zodat externe partijen niet belast worden met deze meldingen. We zullen hier in de toekomst meer aandacht aan schenken.