governance

Note-to-self: (e)ID kaart als waarborg?

Hoewel je het in privé omstandigheden waarschijnlijk wat minder zal tegenkomen, zullen heel wat professionele collega’s (en zeker consultants en/of security specialisten) de situatie wel herkennen dat je bij het bezoek aan een organisatie door de receptionist of bewaker gevraagd wordt om je identiteitskaart af te geven in ruil voor een (tijdelijke) toegangsbadge. Bij het inleveren van die badge krijg je dan nadien je identiteitskaart (aka eID) terug, normaalgezien.

Naar aanleiding van een aantal weerkerende discussies die ik afgelopen tijd met verschillende klanten en collega’s had, over het gebruik van de (elektronische) identiteitskaart als onderpand of waarborg, ben ik bij het opzoekings-/onderzoekswerk een aantal interessante bronnen en referenties tegengekomen.

Die zijn relatief makkelijk te vinden, ware het niet dat de links van de vroegere ‘privacy commission” (NL/FR) niet meer correct doorverwijzen naar de Belgische GBA , waardoor heel veel oude publieke referenties jammer genoeg niet doorverwezen worden, maar stranden op een onbeschikbare pagina.

Ter info, het lijkt erop dat je de oude URL zelf kan omzetten:

  • van <privacycommissie.be/nl/><topic>
    • naar: <gegevensbeschermingsautoriteit.be/><topic>
  •  of, van <privacycommission.be/fr/><topic>
    • <autoriteprotectiondonnees.be/><topic>

Dus ik hoop dat onderstaande info alvast interessant is en nuttig om te delen, al is het maar als geheugensteun voor toekomstige discussies [of om bepaalde discussies aan de receptie vanaf nu meteen kort te sluiten 🙂 ].

Eerst en vooral, focus ik hier op de BELGISCHE eID en de Belgische wetgeving. Voor de buitenlandse identiteitskaarten is er wat meer opzoekingswerk nodig en wellicht is de wetgeving daar anders of heeft andere nuances in de toepassing…

De basis over het gebruik van de eID en het RRN/SSN (Rijksregisternummer, Social Security Number), vind je terug bij FOD Binnenlandse zaken.

Uiteraard vind je daar alle details in de wetgeving, maar hier voldoet de FAQ over de eID. Die vindt je hier: http://www.ibz.rrn.fgov.be/nl/faq/identiteitsdocumenten/eid/

Eerst en vooral, moet je een duidelijk verschil tussen

  1. het overhandigen van de ID als waarborg en
  2. het tonen van een identiteitskaart, en
  3. het gebruik van de RRN/SSN

Als je in de FAQ de “Historiek” sectie overslaat, kom je meteen op de kern van de zaak, die aan de basis ligt van alle antwoorden op de kernvraag en de tweede vraag.

“Moet ik verplicht mijn identiteitskaart bij me hebben?”

“Het KB (koninklijk besluit) van 25 maart 2003 betreffende de identiteitskaarten bepaalt dat iedere Belg vanaf de leeftijd van 15 jaar, zijn identiteitskaart steeds bij zich moet hebben. “

Meer info: http://www.ejustice.just.fgov.be/eli/besluit/2003/03/25/2003000227/justel

De volgende vraag in de FAQ is ook uitermate interessant als we de oorspronkelijke vraag willen beantwoorden.

“Mag men bij het onthaal van een openbaar gebouw een identiteitskaart vragen en bijhouden?

/../. Dit is het geval bij elk verzoek van de politie, in het kader van haar wettelijke en reglementaire opdrachten, alsmede bij elke vraag naar certificaten en uittreksels door gemeentelijke of door andere openbare diensten.

Over het algemeen sluiten deze bepalingen de mogelijkheid niet uit om naar de identiteitskaart te vragen bij het onthaal van een gebouw dat tot de openbare of privésfeer behoort. Het spreekt voor zich dat voornoemde bepalingen niet toelaten dat het onthaalpersoneel, bijvoorbeeld, de identiteitskaart langer bijhouden dan nodig om kennis te nemen van de identiteit.

Wat de verplichting betreft om zijn identiteitskaart voor te leggen (zonder dat deze bijgehouden wordt), bepaalt het koninklijk besluit van 25 maart 2003 dat de identiteitskaart voorgelegd moet worden “als de houder het bewijs van zijn identiteit dient te leveren”, dit wil zeggen dat dit beoordeeld moet worden in functie van het algemene principe dat geldt voor de bescherming van de persoonlijke levenssfeer, namelijk dat het doel waarvoor de voorlegging van de kaart wordt geëist, wettig, bepaald en expliciet moet zijn. Het feit om zich te moeten verzekeren van de identiteit van de bezoekers in het licht van het eigendomsrecht en van de noodzaak om de veiligheid van een gebouw te verzekeren, lijkt aan deze criteria te voldoen. Het is echter niet gerechtvaardigd om de identiteitskaart bij te houden tijdens de duur van het bezoek. Het feit om aan een derde te vragen om zijn identiteitskaart voor te leggen, moet bepaald worden door een wet, een besluit of een intern reglement.”

Op de website van Agoria staat ook een goed artikel met meer praktische uitleg van deze situatie. (artikel dd 23 april 2015)
Bron: https://www.agoria.be/nl/Mag-een-onderneming-de-identiteitskaart-van-bezoekers-controleren

“Volgens het KB van KB van 25 maart 2003 betreffende de identiteitskaarten mag de identiteitskaart enkel door daartoe bevoegde personen en enkel in welbepaalde gevallen gecontroleerd worden.

In een onderneming mogen alleen bewakingsfirma’s waaraan de beveiliging van het bedrijf wordt uitbesteed of interne bewakingsdiensten voorlegging van identiteitsdocumenten vragen. Ze mogen deze documenten enkel laten voorleggen gedurende de tijd die nodig is om de identiteit te controleren bij toegang tot niet-publiek toegankelijke plaatsen.

Hoewel het opvragen van de identiteitskaart niet geregeld wordt door de privacywet, is voorzichtigheid geboden wanneer men de informatie op de identiteitskaart leest, kopieert en in een bestand opneemt. Dat is immers een “verwerking van persoonsgegevens”. In dat geval moet de privacywet dus worden nageleefd (informatieverplichting, recht op inzage, verbetering, …).”

En dan komen ze tot de kern van de zaak

“De noodzaak om een persoon te identificeren betekent niet dat een kopie moet worden gemaakt van de identiteitskaart. Een visuele controle van de identiteitskaart volstaat.

De commissie stelt vast dat in sommige gevallen aan personen wordt gevraagd hun identiteitskaart als waarborg af te geven (bijvoorbeeld gedurende de tijd waarin een audiogids wordt gehuurd voor het bezoek aan een tentoonstelling). Die praktijk is niet aanvaardbaar aangezien de houder van de identiteitskaart hierdoor zijn wettelijke verplichting om zijn identiteitskaart bij zich te hebben niet kan nakomen.”

Voor alle duidelijkheid, de paragraaf daaronder verwijst nog naar de oude links van de Privacy commissie :

“In afwachting van toekomstige koninklijke besluiten heeft de Privacycommissie in een themadossier ‘De elektronische identiteitskaart en onze privacy’ op haar website een aantal aanbevelingen geformuleerd. “

Dit moet zijn: https://www.gegevensbeschermingsautoriteit.be/eid

Agoria verwijst dus naar het artikel van de Belgische privacy commissie, correctie: tegenwoordig de GBA of gegevensbeschermingsautoriteit, die dit topic dus al eerder aangekaart heeft.

De gegevensbeschermingsautoriteit bespreekt het onderwerp hier: https://www.gegevensbeschermingsautoriteit.be/eid-welke-wetgeving-is-van-toepassing

Die wijkt uiteraard niet af van de Belgische wetgeving op de identiteitskaart, maar ze voegen er wel nog een aantal interessante voorbeelden aan toe, in het licht van privacy en data protection…

“Enkele voorbeelden van wat mag en niet mag:

  • een videotheekuitbater mag je identiteitskaart vragen wanneer je een dvd huurt. Stel dat iemand de dvd niet terugbrengt, dan kan hij die persoon contacteren;
  • wanneer je een verblijf in een hotel boekt, is de uitbater wettelijk verplicht om je te identificeren;
  • bij een bezoek aan een tentoonstelling moet je soms je identiteitskaart afgeven als waarborg voor de audiogids. Dit is onaanvaardbaar: niet alleen moet je je identiteitskaart op elk moment bij je hebben (ook tijdens je bezoek aan de tentoonstelling), maar je loopt ook nog eens het risico dat je elektronische handtekening en je pincode gestolen worden;”

Dus in het kort de conclusie over het gebruik van de eID als waarborg is daarmee: nee, niet toegelaten.

Trouwens, ter info: als je de GBA website doorzoekt op ‘eid’ krijg je nog een hele hoop extra informatie, met bespreking van praktische situaties.

Zoek even op: https://www.gegevensbeschermingsautoriteit.be/search/site/eid

Het laatste voorbeeld dat de GBA in het voorgenoemde artikel geeft, verwijst naar een andere interessant onderwerp: het gebruik van het RRN/SSN nummer..

“Het rijksregisternummer dat op elke eID staat, mag enkel verwerkt worden als de verantwoordelijke voor de gegevensverwerking daartoe gemachtigd is door het Sectoraal comité van het Rijksregister. Meer informatie hierover  is beschikbaar op de specifieke pagina over de machtigingsprocedure bij het Sectoraal comité van het Rijksregister. In het algemeen geldt wel dat een verantwoordelijke die geen taak van openbaar belang heeft, het rijksregisternummer niet zal mogen gebruiken”

Jammer genoeg heeft de GBA zijn naamsverandering op hun website nog niet helemaal verteerd, want de link moet eigenlijk wijzen naar: https://www.gegevensbeschermingsautoriteit.be/algemene-machtigingen-rr

Waarmee we belanden bij het gebruik van het RRN (Rijksregisternummer) or “SSN (social security number)” in het Engels.

Dit is een onderwerp op zichzelf en het is niet m’n bedoeling de details te bespreken. Te meer ook omdat GDPR belangrijke bepalingen bevat hierover.

Kort door de bocht, in essentie (*):

“Het verwerken van het rijksregisternummer is bij wet verboden.”

… tenzij machtiging, volgens de wet (http://www.ejustice.just.fgov.be/eli/wet/2003/03/25/2003000234/justel):

  • “Het identificatienummer van het Rijksregister mag niet worden gebruikt zonder machtiging of
  • voor andere doeleinden dan die waarvoor die machtiging is verleend.”

En die machtigingen zijn onderworpen aan strikte regels en worden niet zomaar toegekend. Wat dus enige inventiviteit vergt om dit op te lossen in het operationeel gebruik voor identity and access management, IT Security of data protection voor burgers.

Meer info (*) kan je in dit interessant artikel (dd 26 feb 2018) vinden: https://gdpr.wolterskluwer.be/nl/nieuws/rijksregisternummer-en-privacy/.

Overzicht Referenties

Wetgeving

eID

Privacy:

Rijksregisternummer:

En ook:

Advertisements

That alphabet of Security starts with I of “Identity”

It’s an understatement to say security is moving fast, it’s changing very rapidly and the pressure to keep up with it, increases too.

From various angles, people in IT (as in Information Technology), are under fire to keep the infrastructure secure. Cloud is getting mature, new features pop up every week.
It’s almost a contradiction, but also legislation is catching up to close the holes regarding the protection of people’s security and privacy.

In many cases, the first reaction of customers, management, ITPros, Developers, DevOps,… is to look for the ultimate and ideal tool that will help to plug the security hole.

But if you only focus on the tooling, you’ll discover rather sooner than later, it is not sufficient to get your security watertight.
One of the basic reasons is that tools can’t be implemented properly without involving people and processes. I don’t need to explain the PPT (people-proces-technology) or PPP (people-proces-products) triade, right?

Lots of security management approaches and certifications handle this triad (ISO27001, CISSP, … I’ll cover that another time.

(credits: smart picture of ITGovernance.co.uk)

Rather than diving into the search for a tool, you better take a step back and consider first.

What’s the primary function of security?
Protecting an item that you want to keep (safe), right?

[The reason (“why”) for keeping it safe = the CIA triad, Confidentiality, Integrity and Availability]

When you think about the processes (“how”) to secure  an asset (anything that is worth securing), there are 3 basics actions you need to define

  • authorization: what you can do with the asset (the CRUD stuff, create/read/update/delete)
  • identification: who needs the authorization?
  • authentication: the method to proof your identity (using passwords, passes, cards, 2FA, MFA, …)

This is essentially the foundation of my credo “no security without identity”

Just by interpreting the basic components of security, you directly hit the “PROCESS” part of the PPT triad.
Now, here’s were most technical people get into trouble… not knowing how to put this in practice.

But let me ask you a simple question: within the normal, usual businesses or companies, where does the identity process typically start?
Yes, correct, HR (Human Resources)

The second question: can you name at least 2 typical high-level HR processes (for people).
Answer: something like “hire” and “fire”, or synonyms like “onboarding/off-boarding”, “termination”, “end-of-life” (but that sounds pretty dramatic when talking about people…).

These 2 events announce the beginning and the end of a lifecycle, the identity lifecycle.
And to make it complete, you also need to define the life-in-between as people change over time.

BTW, just a small side step here: this does not apply to humans only, but any other asset in your environment has pretty much the same cycle and it does not matter if it’s considered “IT” or not… computer, certificates, smart cards, disks, tapes, … but also cars, documents, …

This idea to consider the lifecycle as universal, is a great approach to explain the “identity lifecycle” to non-techies that get involved in the identity lifecycle processes.

This is the common ground you can use to talk to HR people, business managers, Executive level, …

Now, if you look on the internet for pictures on identity lifecycle management, you’re smashed with a lot of complex schemas…

google_identitylifecycle

Many of results are variations of 3 essential processes

hire-change-fire1

Depending on your background you might name them differently, like:

1AA.png

For the sake of simplicity, when teaching IDM and security workshops I usually only keep the keywords “Hire”, “Change” and “Fire”.
Short and easy to remember for most people.

For your understanding, the circle approach  would assume you start over again after the “Fire” block, but that’s not always the case. The cycle might stop.
So, the approach below is easier to visualize for most people.

Clockwise:

  1. Starting the cycle at (1),
  2. updating the identity at (2),
  3. exiting the cycle at (3)

hire-change-fire2

As I mentioned, earlier, virtually any IT or asset related proces is basically working like this.

Now, let’s take it a step further… How does identity management control security?

A first thing to consider is the typical length of the hire-change-fire modules.

How many tasks/steps does it usually take to complete each of the 3 steps?
Keep the asset in mind and keep it simple…

Typical actions in a hire process:

  • signing contract
  • getting an network/AD account
  • getting an email address
  • getting building access
  • IT stuff (laptop, …)
  • …

Pretty straight forward…
How much time would it take, in simple cases to start working?  Hours if not days.

What about the change process? For example, you get promotion to team lead or head of department…

  • hand over your tasks to peers
  • get ramped up on new job
  • in some cases, there is segregation of duties, getting rid of existing rights permissions
  •  getting access to new environment
  • changing communications channels (notifications to stakeholders of change)
  • …

In reality, this usually takes a few weeks.

And what are the typical things your consider for the “fire” process?

  • informing stakeholders/customers
  • disabling the account
  • changing password
  • lock account
  • removing access
  • extracting documentation form personal storage
  • move documents to manager or team
  • handing over ownership
  • knowledge transfer
  • data backup/archiving
  • cleaning the mailbox
  • deleting the account (* not always allowed for various reasons)
  • sending legal / tax documents
  • and more…

As you can understand, this entire termination process might take months… In many situations the termination process must be executed in different steps, like:

  • Disabling the account till x+30 days (for example, revert in case the person gets a renewal)
  • Removing access on x+60 days
  • Kill mailbox on X+90
  • Remove the account on X+1y (or even: never)

In some cases accounts must be kept for legal reasons or tracking/cybersecurity reasons…

The further you go in the lifecycle, you need to combine more tasks, and tasks or decisions get more complex.

Overall you can distinguish 2 properties of these processes: duration and complexity. Both go up.

complexity

procesduration

Now, when considering security, why is this important?
Instead of discussing the impact of successful processes, it’s easier to find out what happens if it fails.

WHAT IF… (the process fails)??

Let’s run through the cycle again….

What if the “Hire” process fails?

  • you can’t access the building
  • you do not get an account
  • you can’t logon
  • you can’t access documents
  • …

Basically, on your first (few) day(s) you can’t work. Sorry!
But what’s the balance for security: just great, because the risk is nearly 0, except for a bad start and a bit of reputation damage..
At the end: you can’t do any harm, essentially.

In case of the “change” process, a larger part of the tasks and operations will impact the security posture.

When your “change” process fails,  for example

  • you can still access your old documents
  • you get more access (eg collecting access of your old and new role)
  • you start collection sensitive accesses over time
  • managers don’t know
  • user profiles get copied from existing colleagues in the same team (no ‘reset’ or the permissions before the new ones are assigned)
  • …

So for this second piece of the circle, the impact might be significant, over time.

But for the “end-of-life” the story is completely different, a failing “deprovisioning” scenario has major impact on the business and IT process

  • accounts stay active
  • accounts not being disabled
  • access not removed
  • active accounts not detected
  • account with highly privileged access still active
  • accounts being deleted too soon
  • unauthorized users that have access to critical resources
  • hackers go undetected for a long time, using sleeping accounts
  • hardware not returned,
  • data stolen,
  • over-use of budgets to software licenses that are not revoked
  • access badges allow unauthorized access to your building and environment
  • failure to ‘deprovision’ old hard disks properly expose your company data to interested (unauthorized) parties…
  • …,

It’s clear that a failing deprovisioning/end-of-life process has major impact on your enterprise security.

risk.png

And hackers or disgruntled employees like that.

Of course you can imagine the benefits of an efficient and effective end-of-life process. It’s the opposite.

Does that require you implement an automated identity management?
No.

That’s where ISO27001 and eg GDPR surprises a lot of people.

Once you’ve got the basic processes in place you can discuss tooling, not the other way around.

questforsecurity

You have
no security without managing your identity.

you want
no identity without security.

Did I mention  that I’ll be presenting more of this fun stuff on TechoRama 2017.
Check it out here: http://sched.co/9M94

I’m very proud to present a session on the ABC of identity: Maximizing security with 10 simple processes.

 

Note-to-self: Internet, privacy and copyright (blogs, #TNWIKI, …)

While working on TechNet Wiki Governance, I stumbled into some useful links.

Saving it to my external memory for quick reference: