Tag: inloggen

Wachtwoordgedrag werknemers zeer risicovol

  door

Werknemers en systeemfouten zijn de voornaamste oorzaken dat er datalekken plaatsvinden, zo beweert het Ponemon Instituut…Daarbij worden het niet regelmatig wijzigen van wachtwoorden, het hergebruik van gebruikersnamen en wachtwoorden en het onbeheerd achterlaten van de computer als het meest risicovolle gedrag omschreven (bron).

We kunnen natuurlijk naar de medewerkers blijven wijzen en we kunnen ze de zwakste schakel blijven noemen, maar geef ze eens ongelijk. Welk mens kan er 10 inlognamen met 10 verschillende wachtwoorden (bestaande uit cijfers, letters en leestekens) onthouden? Dan resten er voor de medewerkers een aantal opties:

  1. Men schrijft de inlognamen en wachtwoorden op
  2. Men hergebruikt de inlognamen en wachtwoorden
  3. Men gebruikt voor ieder systeem een andere inlognaam/wachtwoord combinatie en moet ieder dag de helpdesk bellen

Inmiddels zijn veel bedrijven al serieus bezig met single sign on en bij de een lukt dat beter dan bij de ander. Maar het is in ieder geval een stap vooruit. We blijven ons als bedrijf echter verbazen over het feit dat de medewerker zijn inlognaam/wachtwoord maar niet lijkt te kunnen onthouden. Wat we daarbij echter vergeten is dat die medewerker zeer waarschijnlijk nog vele andere inlognamen en wachtwoorden te onthouden heeft die we als bedrijf niet op het netvlies hebben.

Naast de zakelijke werkplek (waar we al snel 5 of meer inlognamen hebben) heeft de medewerker waarschijnlijk ook nog wel een eigen emailadres (met inlognaam en wachtwoord), misschien heeft hij nog een LinkedIn account (met inlognaam en wachtwoord). Zit de medewerker niet toevallig op Facebook en Hyves (bieden met hun eigen inlognaam en wachtwoord) en Twittert hij niet zo af en toe (met inlognaam en wachtwoord).

Oh wacht, daar komt een aanslag van het Energiebedrijf. Of we even de meterstanden digitaal in willen vullen (met inlognaam en wachtwoord). De Belastingaangifte hebben we gelukkig net achter de rug dus kunnen we even buiten beschouwing laten. Oh ja, UPC (of Ziggo of een van de andere partijen) heeft gebeld, de nieuwe factuur staat online (met inlognaam en wachtwoord). Nou ja, inmiddels snap je de strekking van het verhaal.

Maar naast accounts met een inlognaam en wachtwoord moeten we ons ook nog identificeren bij de bank (met een pincode) en is je telefoon ook nog beveiligd (met een pincode). Heb je meerdere bankrekeningen en/of telefoons dan heb je natuurlijk ook meerdere pincodes. Maar goed, ook hier begrijp je de strekking van het verhaal.

Je moet inmiddels wel een hoogbegaafd iemand met een fotografisch geheugen zijn als je echt voor ieder systeem een aparte inlognaam, wachtwoord of pincode wilt bedenken en onthouden. Voor een enkeling is dat misschien weggelegd, maar voor het merendeel zulle we toch terug vallen op optie 1 of 2 en eerlijk gezegd kan ik het je ook niet echt kwalijk nemen.

Beveiligingsincidenten

  door

Als we beveiliging goed (genoeg) inrichten dan kunnen we er op vertrouwen dat we de risico’s voldoende hebben afgedekt. Preventief zijn we bezig om juist die activiteiten op te pakken die bijdragen aan de continuïteit van onze organisatie. Toch zullen we zien dat preventieve maatregelen alleen niet genoeg zijn, nee, we zullen ook detectie moeten inregelen voor het geval er toch iets onverwachts gebeurt. We moeten met onze repressieve en correctieve maatregelen daarop in kunnen spelen om zo snel mogelijk terug te gaan naar de “business as usual”.

De vraag die daarbij speelt is:
Is er vastgelegd wat verstaan wordt onder beveiligingsincidenten?

Vanuit de IT zijn we gewend om te werken met incidenten. Een verstoring van de applicatie melden we bij de helpdesk zodat we zo snel mogelijk weer aan het werk kunnen. Logisch en als we er echt serieus mee bezig zijn dan richten we het incident management proces in conform ITIL.

Daar moeten we vooral mee door blijven gaan, want dit is zeker een aspect dat bijdraagt aan de continuïteit van de organisatie. Toch moeten we ook na gaan denken over wat we exact verstaan onder een beveiligingsincident. Deze kan veel overeenkomsten vertonen met een incident (conform IT), maar kan wel degelijk op een andere wijze worden opgelost.

Om het niet te cryptisch te maken even een kort voorbeeld: stel je komt terug van vakantie en bent je wachtwoord vergeten. Je probeert 3x in te loggen en blokkeert helaas je account. Helpdesk bellen en na een paar minuten kun je gelukkig toch weer aan de slag. Een incident dat we op moeten lossen omdat je anders liever weer terug gaat naar je vakantieadres. Maar stel nu dat tijdens jouw afwezigheid een collega geprobeerd heeft om met jouw account in te loggen. Hij moest even in je mailbox zijn om een mailtje te lezen. Jij komt terug en kunt niet meer inloggen, terwijl je er zeker van bent dat je het juiste wachtwoord hebt gebruikt. Verstaan we dit nog onder een incident of hebben we het hier toch eerder over een beveiligingsincident?

Enerzijds is het dus niet altijd gemakkelijk om de juiste definitie te hanteren voor beveiligingsincidenten, maar anderzijds is het ook nog lastig om ze te detecteren. Hoe kan de medewerker van de helpdesk nu weten of het een incident is omdat jij je wachtwoord bent vergeten of dat het een beveiligingsincident is omdat een collega geprobeerd heeft in te loggen?

Lekker relevant zul je zeggen. Ik ben net terug van vakantie en wil (of moet) weer aan de slag. Toch is het voor de beveiligingsaanpak relevant. Misschien probeert die collega namelijk nog wel meer illegale activiteiten uit te voeren. Stel dat het was gelukt om in te loggen en dat hij namens jouw een mail had gestuurd aan de directeur die hij voor stommeling uit maakt dan zijn de gevolgen wel anders.

Vanuit beveiligingsoptiek willen we graag weten welke beveiligingsincidenten zich voordoen. Hier kunnen we namelijk onze aanpak op bijstellen. Doen we de juiste dingen en doen we de dingen nog juist? Het verschil tussen een incident en een beveiligingsincident kan hier het verschil in maken.