Bij de meeste incidenten met een klantportaal wordt er niets gekraakt. Iemand logt in met een wachtwoord dat bij een andere dienst gelekt is, of typt zijn gegevens over op een pagina die er precies zo uitziet als de echte. Daar helpt geen enkele maatregel in de software tegen.
Dat is ook het goede nieuws: aan die kant kun je vanmiddag beginnen zonder dat er iemand aan de applicatie hoeft te werken.
Begin bij jullie eigen accounts
Gebruik een wachtwoordmanager. Wachtwoorden gaan bijna altijd mis op hergebruik. Eén webshop waar iemand ooit iets besteld heeft raakt zijn database kwijt, en datzelfde wachtwoord opent jullie portaal. Met een manager als Bitwarden of 1Password heeft elke dienst zijn eigen wachtwoord zonder dat iemand iets hoeft te onthouden. Mooi meegenomen: zo'n manager vult alleen in op het juiste domein, dus op een nagemaakte inlogpagina blijft het veld leeg.
Zet tweefactorauthenticatie aan. Naast het wachtwoord een code uit een app op je telefoon, of een fysieke sleutel. Een gelekt wachtwoord is dan op zichzelf waardeloos. Kies een authenticator-app en geen sms: een telefoonnummer laat zich met wat overtuigingskracht naar een andere simkaart verhuizen. Voor iedereen met beheerrechten zou ik dit verplicht stellen. Dat zijn de accounts die overal bij kunnen.
Ruim accounts op. De medewerker die vorig jaar vertrok, de klant die geen klant meer is, het testaccount uit de bouwperiode. Elk account dat blijft staan is een deur waar niemand meer naar kijkt. Spreek af dat dit gebeurt bij uitdiensttreding. Bij de jaarlijkse opruiming is het te laat.
Log nooit in via een link uit een mail. Een nagemaakte inlogpagina kost een aanvaller een half uur en is met het blote oog niet van de echte te onderscheiden. Ga naar het portaal zoals je er altijd naartoe gaat: via je bladwijzer, of door het adres te typen.
Wat er in de applicatie hoort te zitten
Deze punten horen bij het bouwen zoals remmen bij een auto horen. Je kunt van buiten alleen niet zien of ze er zijn, dus vraag ernaar. Wat wij standaard meenemen staat op de pagina over beveiliging van applicaties en websites.
Rollen en rechten. Iedere gebruiker ziet alleen wat van hem is. Dat valt in twee lagen uiteen: wat iemand op zijn scherm krijgt, en wat de server toestaat als hij daar zelf omheen werkt. Alleen die tweede laag beveiligt iets. Het webadres van andermans factuur is meestal het eigen adres met een ander nummer erin. De vraag aan je bouwer luidt dus: wordt bij elke opvraging opnieuw gecontroleerd of deze gebruiker hier recht op heeft?
Logging van gebruik. Wie heeft wanneer welk document ingezien of gewijzigd. Zolang alles goed gaat kijkt niemand ernaar. Zegt een klant dat hij een brief nooit gekregen heeft, of lijkt er een account misbruikt, dan is dit het enige waarmee je kunt reconstrueren wat er werkelijk gebeurd is. Spreek meteen af hoe lang die regels bewaard blijven, want ze bevatten zelf ook gegevens.
Een certificaat dat zichzelf vernieuwt. Al het verkeer over https, en verkeer op http dat automatisch wordt doorgestuurd. De klassieke misser zit in de vervaldatum. Certificaten zijn tegenwoordig drie maanden geldig, en op de dag dat er een verloopt krijgt iedere bezoeker een waarschuwing van zijn browser die er precies zo uitziet als een echte inbraak.
Wachtwoorden die niemand terug kan lezen. Hier is één test die je zelf kunt doen: vraag om je eigen wachtwoord op te sturen. Krijg je het, dan worden wachtwoorden verkeerd opgeslagen. Een goed systeem kan je alleen een nieuw wachtwoord laten instellen.
Sessies die aflopen. Wie zijn laptop laat openstaan hoort na verloop van tijd opnieuw te moeten inloggen. Handig daarbij is een knop om jezelf op alle apparaten uit te loggen, voor als een telefoon kwijtraakt.
Een rem op eindeloos proberen. Zonder rem kan een aanvaller duizenden wachtwoorden per minuut uitproberen. Met een paar pogingen en dan even wachten is diezelfde aanval onbegonnen werk.
Back-ups die weleens teruggezet zijn. Een back-up die nooit is uitgeprobeerd is een aanname. Vraag wanneer het herstel voor het laatst getest is en hoe lang dat duurde. Dat getal zegt meer dan hoe vaak er een back-up wordt gemaakt.
Onderhoud. De meeste kwetsbaarheden zitten in het framework en de bibliotheken om het maatwerk heen. Die krijgen updates omdat er lekken in gevonden zijn. Achterstallig onderhoud is het enige beveiligingsrisico dat vanzelf erger wordt.
Vragen aan je bouwer
Hiermee heb je in een half uur een redelijk beeld. Op elk punt hoort een concreet antwoord te komen. Blijft het bij geruststellende taal, dan is een code review de manier om het te laten nakijken.
Wie heeft toegang tot de productieomgeving en de database, en hoe wordt die toegang beëindigd als iemand vertrekt?
Worden de onderdelen van de applicatie periodiek bijgewerkt, wie bewaakt dat en valt het binnen het onderhoudscontract?
Waar staan de back-ups, hoe lang gaan ze terug en wanneer is er voor het laatst een herstel getest?
Wordt vastgelegd wie wat heeft ingezien, en hoe lang blijft dat bewaard?
Staan er persoonsgegevens in, en ligt er een verwerkersovereenkomst?
Wat gebeurt er als het tóch misgaat: wie constateert het, wie meldt het, en binnen welke termijn?
Waar begin je?
De eerste drie punten kosten samen een middag en nemen het grootste deel van het risico weg.
Zet tweefactorauthenticatie aan voor iedereen met beheerrechten.
Neem een wachtwoordmanager in gebruik en vervang de wachtwoorden die elders ook in gebruik zijn.
Loop de gebruikerslijst van het portaal langs en verwijder wat er niet meer hoort te staan.
Stel de zes vragen hierboven aan je bouwer en leg de antwoorden vast.
Pak op wat daaruit komt, te beginnen bij achterstallig onderhoud.
Zet die middag deze week in de agenda. Wat er daarna nog nodig is, volgt vanzelf uit de antwoorden die je krijgt.
