Sessieronde 6 Titel: Samen betrouwbaar online Sprekers: Eefje van der Harst (SURFnet) Locatie: Boston 17

1. STERKE AUTHENTICATIE VOOR CLOUDAPPLICATIES VIA
SURFCONEXT
Samen betrouwbaar online
Eefje van der Harst – Productmanager SURFconext

2. Waarschuwing vooraf: jargon alert (sorry)
• Sterke authenticatie
• Level of Assurance (LoA) -
betrouwbaarheidsniveau
• Registration Authority (RA)
• Identity Vetting – ID check

3. SURFconext: met je instellingsaccount de
cloud in

4. Concept niet nieuw

5. Inloggen old skool

6. Username/ password; vaak toch wel handig

7. Username/ password; vaak toch wel handig

8. Maar is het ook veilig genoeg?

9. Oordeelt u zelf

10. Bedenk eens wat er mis kan gaan…
• Fraude met cijferadministratie
• Lekken van patenten/
onderzoeksdata
• Persoonlijke gegevens van
gebruikers op straat
• Etc., etc.

11. Ook/ juist in onderwijs behoefte aan veiligere
toegang

12. Hoe organiseer je dat als instelling?
• Veel integratie-effort bij instelling (n=160)
• Per clouddienst een nieuw token?
• Zoveel leveranciers, zoveel tokens. Vendor lock-in
dreigt
• €€€ Duur, vooral bij kleine user base
• Uitgifteprocessen belangrijk voor betrouwbaarheid

13. Uitbreiding SURFconext

14. Wat willen we bieden:
• Betere toegangsbeveiliging tot clouddiensten
• Beperken van risico’s op beveiligingsincidenten
• Eenvoudige uitrol (techniek + proces)
• Concurrerend tariefmodel
• Gemak voor de eindgebruiker:
uniforme toegang met één tweede factor voor meerdere
diensten

15. Sterke authenticatie via SURFconext

16. Token registreren

17. Token activeren

18. Inloggen
1. Iets wat je WEET + 2. Iets wat je HEBT

19. Huidige status dienstontwikkeling
 Prototype self-service portal voor registratie token
 Prototype appplicatie voor ID-check user + activeren token
 Beschikbare tokens in prototype: SMS en Yubikey
 Op basis van prototype uitvoeren pilots met instellingen
 Business model + business case uitwerken ism instellingen
 Pilots succesvol? Dan: dienstontwikkeling, toevoegen aan
SURFconext

20. Doelen pilots
• Wat is nodig om een clouddienst geschikt te maken voor
sterke authentciatie? (time, effort, technical, knowledge)
• Hoe kan een clouddienst differentiëren tussen verschillende
betrouwbaarheidsniveaus gebruiker?
(= alleen op relevante plekken in applicatie afdwingen)
• Hoe organiseren we uitgifteproces tokens?
• Hoe is user experience voor eindgebruiker & Service Desk?

21. Pilot 1: Windesheim

22. Ervaringen Service Desk mbt
registratieproces
 Werkt prima, proces reeds bekend van uitgifte andere
middelen
 Check legitimatie wordt over algemeen serieus genomen
 Registratieproces eenvoudig op te schalen naar grotere
groepen gebruikers

23. Ervaringen eindgebruikers
 Registratieproces werkt prima
 Gebruikers waarderen keuzevrijheid in token (SMS/ Yubikey)
 User experience bij switch tussen applicaties met hoger/
lager LoA in orde
 Telefoon laat een gebruiker niet gauw slingeren
! Yubikey in gedrag nu soms nog onveilig; laat je gemakkelijk
in USB-poort zitten  instructies verbeteren!

24. Overige leerpunten 1e pilot
 Sterke authenticatie via SURFconext werkt
 Applicatie kan goed omgaan met verschillende betrouwbaarheidsniveaus
± ‘Evt. opstartproblemen’ zouden ook bestaan als instelling zelf sterke
authenticatie zou implementeren
! Differentiëren in betrouwbaarheidsniveau nog lastig voor SP (alles of
niets)
! Duidelijkere instructies nodig over veilig gebruik van tokens
! Afhankelijkheid van SURFconext kan extra risico betekenen
! Tariefmodel nog onduidelijk (work in progress)

25. Pilot 2: Deltion college + Sharepoint 2013

26. Pilot 3: Hanze hogeschool & Osiris (ovb)

27. Overige observaties nav gesprekken
instellingen
• Veel interesse bij instellingen in sterke authenticatie
• Scope wisselt: zowel online als lokale systemen
• Niet elke use-case geschikt (looptijd/ techniek/ etc)
Disclaimer:
Dit wordt NIET de holy grail voor alle authenticatie-issues naar lokale (beheer)systemen!
Want: Step-up-authentication-as-a-service alleen voor webbased SPs

28. Use cases voor sterke authenticatie zijn
legio

29. Belang voor hoger onderwijs is groot

30. www.surfnet.nl
Eefje van der Harst
Eefje.vanderharst@surfnet.nl
Vragen?

31. Veilige toegang: risico-afweging nodig
• Hoe bepaal je vereiste
betrouwbaarheidsniveau?
• Wat is juiste risico-
inschatting?
• Wat is gewenste
beschermingsniveau?
Volg internationale
standaarden:
• ISO 29115
• NIST 800-63
• STORK
http://www.surf.nl/kennis-en-innovatie/kennisbank/2014/rapport-handreiking-betrouwbaarheidsniveaus.html

32. Bron: ISO 29115
Betrouwbaarheidsniveaus - Levels of
Assurance
LoA Beschrijving
1 - Laag Weinig of geen vertrouwen in geclaimde over verzekerd (“asserted”)
identiteit
2 - Medium Enig vertrouwen in de geclaimde of verzekerde identiteit
3 - Hoog Veel vertrouwen in de geclaimde of verzekerde identiteit
4 - Zeer hoog Zeer veel vertrouwen in de geclaimde of verzekerde identiteit

33. NB: LoA = registratieproces + middel