Securitybeleid is nooit af

[FreedomBot]

Eind 2022 is er een security-audit uitgevoerd bij Freedom. Bij een security-audit wordt gekeken naar kwetsbaarheden in de systemen en de organisatie van een bedrijf. Zwakke plekken en blinde vlekken worden zichtbaar en kunnen direct door het bedrijf worden aangepakt. Aan de hand van het onderzoek wordt het bestaande securitybeleid aangescherpt. Om dit onderzoek goed te doen is een kritische blik door een externe nodig. De security-audit bij Freedom werd uitgevoerd door onderzoeker en ethical hacker Jesse van der Berg. 

Let op: we verwijzen in deze tekst naar andere websites. Deze websites hanteren een ander cookiebeleid dan wij. Je kunt meestal cookies weigeren in het cookie menu, zodra je op de website terechtkomt. Vergeet niet om op 'lijst met derden' of 'partners' te klikken. Ook daar kun je vaak nog cookies weigeren. Wat Freedom vindt van cookies lees je hier.

Privacy en security 

Freedom profileert zich vanaf de oprichting door focus op het gebied van privacy en security. Mede hierdoor onderscheiden wij ons op de Nederlandse providermarkt. Goede privacy en security zijn immers noodzakelijk in de maatschappij en dus ook op het internet. 

Securitybeleid

Om onze klanten en onszelf te beschermen heeft Freedom een securitybeleid. Hierin worden rollen en taken toegekend aan verschillende Freedom medewerkers, staat beschreven waar we aan moeten denken om veilig te blijven en is vastgelegd hoe we security incidenten afhandelen. Eigenlijk is het securitybeleid een to-do lijstje dat nooit af is, maar waar wel voortdurend aandacht voor moet zijn én wat zich blijft uitbreiden.  

Security-audit

In 2022 is de security-audit bij Freedom uitgevoerd door Jesse van der Berg, onderzoeker en ethical hacker. Hij signaleerde een aantal zwakke plekken bij ons, die deels van technische aard en deels van procedurele aard zijn. Dankzij deze audit hebben we zowel datalekken als security incidenten kunnen voorkomen. De zwakke plekken zijn in overleg met Jesse direct aangepakt. We hebben het hele proces uitvoerig geëvalueerd en er zijn verschillende vervolgstappen uit voortgekomen. Zo richten we ons de komende tijd onder andere op een strakkere uitvoer van ons exit- en enter-proces (medewerkers die in en uit dienst gaan) en het securitybeleid inclusief de documentatie daarvan in het algemeen.

Jesse, heel erg bedankt! 

Security Officer Freedom

Uit de audit bleek dat we hard moeten blijven werken om nieuwe zwakke plekken tegen te gaan en scherp te blijven op het handhaven van bestaande procedures. Voor een betere procesbewaking hebben we daarom onze collega Timo Hilbrink benoemd tot Security Officer binnen Freedom. Timo heeft ruime ervaring in deze rol en in de telecomsector. Hij heeft in het verleden aan vele security overleggen en werkgroepen deelgenomen en een aantal daarvan gecoördineerd. We zijn blij dat Timo deze belangrijke rol in het bedrijf op zich heeft genomen. 

Security in 2023

Ook dit jaar zullen we een security-audit organiseren. Zo houden we onszelf scherp en kunnen we de veiligheid van ons bedrijf en onze klanten verbeteren. Een externe, kritische blik helpt enorm om blinde vlekken te voorkomen en veiligheid te kunnen blijven garanderen.

Namens team Freedom wensen we iedereen een veilig internet in 2023 en daarna.

---

Zie het oorspronkelijke bericht op https://freedom.nl/nieuwsartikel/securitybeleid-is-nooit-af

[pa4wdh]

Goed dat jullie dit soort dingen doen

Als ik dan een (kleine) ergernis van mijzelf op dit gebied mag delen: Het zou fijn zijn als de HIBP check optioneel gemaakt wordt, en dat mag wat bij betreft best opt-out zijn. Ik heb de stukken over jullie implementatie gelezen, maar ik ben het meer oneens met het principe. Het plaatst HIBP op een voetstuk waar ze naar mijn mening niet horen. Het heeft mij in ieder geval lange tijd tegen gehouden om me bij Freedom aan te sluiten, totdat xs4all me uiteindelijk geen keuze meer liet …

[mbsnl]

Niet om de “Pwned Passwords API” van HIBP te verheerlijken, maar wat is precies je bezwaar?
Freedom is er heel transparant over wat men doet en waarom. En de technische werking is ook volledig bekend.
Ik kan bedenken:

1. Het biedt geen volledige bescherming, API is altijd onvolledig (vals gevoel van veiligheid)
2. False positives mogelijk vanwege SHA1
3. Afhankelijkheid van 3rd party (dienst beschikbaarheid), maar misschien heeft men daar wel aan gedacht en wordt dan de check tijdelijk overgeslagen (zie 1, vals gevoel van veiligheid).
   Maar geen van deze dingen zie ik echt als een overerkoomlijk bezwaar om dan maar die hele password-check niet uit te voeren.

[pa4wdh]

Zoals gezegd gaat het mij niet om de technische implementatie, ik waardeer de transparantie die Freedom daarover geeft. Als je zo’n check wil doen is dat een nette manier om het te doen, het is meer die “als” die ik graag optioneel zou willen hebben.
De werkwijze van HIBP (gelekte data verzamelen) vind ik sowieso grenzen aan onethisch, in de niet digitale wereld heet dat volgens mij heling. Daarnaast zal het mij persoonlijk een worst wezen of de hash van mijn password toevallig overeenkomt met de hash van het password van iemand anders die ooit eens gelekt is.

[mbsnl]

De werkwijze van HIBP (gelekte data verzamelen) vind ik sowieso grenzen aan onethisch, in de niet digitale wereld heet dat volgens mij heling.

Ah, snap wat je bedoeld. Zo had ik er niet tegenaan gekeken.
Omda het allemaal heel sympathiek oogt, stapt de wereld snel over jou argument heen.
Ga ik eens over nadenken.

[pa4wdh]

Uiteraard snap ik ook de goede bedoelingen wel, zowel van HIBP als Freedom. Ik zou het alleen wel fijn vinden als die keuze gewoon aan mij gelaten wordt of ik die check wil.
Ik vind vooral dat je dat soort partijen niet onnodig op een voetstuk moet plaatsen, alsof ze een autoriteit zijn op het gebied van veilige passwords ofzo. In mijn geval worden de passwords gegenereerd en die zijn best lang, dus als er al een match is verwacht ik eerder een false positive dan iets anders.