Modern Multi-factor and Remote Access Technologies

Transcription

1 Modern Multi-factor and Remote Access Technologies ANDREW BRICKEY Senior IT Engineer Identity and Access Management / Core Computing Services NLIT Summit 2016 May 11,

2 Agenda Problem and solution statements Overview of multifactor requirements and potential technologies Overview of remote access requirements and potential technologies Path forward May 11,

3 Problem and solution statements Traditional VPN paired with traditional multi-factor solutions are inflexible and at times too costly (hardware, software, etc) Why can t I have the same remote access for my Microsoft Surface that I get with my iphone and ipad? Is the comparison fair and what can be done to achieve the same level? Is traditional multi-factor used with remote access LOA3? Is it assumed that remote access means full or partial network access? LOA2 x 2 = LOA3 LOA3 < LOA4 (Say what?) LOA3 is fine for remote access transport but not authentication? How do we do what is compliant but maintain seamless access while also increasing functionality and flexibility? Is this impossible? May 11,

4 Multifactor Requirements and Solutions Level of assurance (LOA) defined: The level of assurance is measured by the strength and rigor of the identity proofing process, the strength of the token used to authenticate the identity claim, and the management processes the identity provider applies to it. LOA1: Provides some assurance that the Claimant who participated in previous transactions is accessing the protected transaction or data LOA2: Provides single factor network authentication. Identity presentation is required during enrollment. (Secret tokens, Knowledge Tokens, Look-up Secrets, Out of band tokens, OTP devices) LOA2(secret you know) + LOA2(OTP device you have) = LOA3 LOA3: Provides multi-factor network authentication. Identity proofing is required and verified during enrollment. At least two authentication factors are required. (Know, Have, Are) Multi-factor software cryptographic tokens are allowed at LOA3 LOA4: Provides highest assurance. In-person identity proofing is required. Based upon proof of possession of a key through cryptographic protocol Similar to LOA3 but requires hard cryptographic tokens (FIPS L3) May 11,

5 Multifactor Requirements and Solutions May 11,

6 Multifactor Requirements and Solutions (Continued) Traditional/Proven Examples: LOA1 = An address or randomly generated PIN LOA2 = An assigned/trusted username & complex password combination An x509 certificate issued from a trusted source A single-factor OTP like RSA without PIN LOA3 = RSA token + PIN, x509 Cert + PIN (LOA2 + LOA2) FIPS Level 1 cryptographic solution LOA4 = HSPD12 PIV badge, RSA token with integrated PIN keypad FIPS Level 3 cryptographic devices May 11,

7 Multifactor Requirements and Solutions (Continued) Modern/Future Examples: LOA1 = Google, Facebook, Microsoft account LOA2 = A single-factor OTP like Google Authenticator FIDO U2F Security Key And many more LOA3 = Microsoft Virtual Smart Card (VSC) protected by TPM Windows Hello (Facial, Biometric)? Mobile device with software certificate + device PIN And many more FIPS Level 1 cryptographic solutions LOA4 = USB based YubiKey, Gemalto, PIVKey cryptographic tokens FIPS Level 3 cryptographic devices May 11,

8 Multifactor Requirements and Solutions (Continued) Thoughts on future multi-factor implementation(s): Be compliant but be feature and option rich for the end users Embrace multi-platform technologies but don t limit all devices to the least common of functionality Increase the overall security posture of the network by making it more convenient for system admins to use MFA Embrace future multi-factor technologies by being foundationally prepared to allow for newer credential types May 11,

9 Multifactor Requirements and Solutions (Continued) May 11,

10 Remote Access Requirements and Solutions.. In recent years traditional multi-factor based remote access has evolved but hasn t evolved at the same pace of mobile devices Still using RSA tokens + PIN and Cisco AnyConnect ios and Android devices leveraged a certificate based solution paired with a device PIN to provide limited access to network services Limited access to the network because the devices are BYOD Limited access to the network because device cert + device PIN on BYOD can be iffy when a 5 year old is watching Netflix in the back seat Where can we go from here now that we have newer multi-factor technologies and modern operating systems? May 11,

11 Remote Access Requirements and Solutions.. To find out where we can take newer technologies, we must first define how we want the modern remote access solution to function Requirement #1 Convenient for consumers to use Always connected or easily connected remote experience Token-less experience on many devices Requirement #2 A net increase in functionality for consumers While traditional VPN gave 100% access to the network, maybe it s time to reduce access to 95% of the network while decreasing frustration by 80% Requirement #3 A net increase in security for the network Leverage always on connectivity to stream security telemetry data back to incident response personnel 24/7 rather than waiting for the device to come home Requirement #4 A net increase in supportability for IT support staff Leverage always on connectivity to push updates, configuration changes and other IT related activities 24/7 rather than waiting for the device to come home Requirement #5 Be platform agnostic as much as possible Leverage what Microsoft and other OS platforms have to offer without sacrificing one for the other May 11,

12 Remote Access Requirements and Solutions.. Requirements Summary A remote access technology that provides the device access to a limited subset of the network to provide authentication, monitoring, management and other device functionality This tunnel will leverage a device certificate at minimum with device password being a secondary nice to have requirement. Assumption: Device requires a PIN to boot up, thus adding additional layers A remote access technology that provides the user access to a large subset of the network to provide access to applications, , files and other user focused services This tunnel will leverage LOA3 or LOA4 (preferably) multi-factor technologies through a convenient user friendly experience Assumption: Before the user tunnel is initiated, the device tunnel must be connected and secure The user tunnel will operate in split tunnel mode allowing the user access to local resources at home (printers, etc) and services while traveling May 11,

13 Remote Access Requirements and Solutions.. Solution : Microsoft DirectAccess Fully functional and secure remote access solution built into Windows Server 2012 R2 DirectAccess client built into Windows 8 Enterprise and above DirectAccess provides multiple independent tunnels for the device and the logged on users (Infrastructure and User) Leverages IPv6 technologies but does not require external or internal IPv6 addressing for your enterprise network Traffic is tunneled using IP-HTTPS over TCP port 443* Can be configured to work with existing smart card authentication to provide a seamless single sign-on experience for end-user Is scalable and redundant through the use of load-balancers and Multisite May 11,

14 Remote Access Requirements and Solutions.. DirectAccess : How does it work?. and other Magic DNS64 and NAT64 are used in conjunction with IP-HTTPS auto-assigned 2002::/16 global unicast address (GUA) or internally defined IPv6 prefix * Intranet IPv4 resources are translated via DNS64 into IPv6 addresses to be tunneled by DA server(s) and NAT d via NAT64. IPv6 unique local address (ULA) prefix + internal IPv4 in hex fd86:9f51:a64b: a70:13 ( ) = fd86:9f51:a64b:7777::a70:13 Client IPsec supplicant (aka Windows Advanced Firewall) is leveraged to create IPsec tunnels for intranet traffic going to DA server (gateway) DNS client utilizes name resolution policy table (NRPT) to communicate with DNS64 and determines what traffic flows down the tunnel IPsec connections security rules enforce multi-factor authentication (computer certificate, computer password, user Kerberos/smart card) Multiple IPsec tunnels created Infrastructure Tunnel = System services (Authentication, agents, etc) Intranet Tunnel = User services ( , Files, etc) [CERT + PW] [CERT + User Kerberos] May 11,

15 Remote Access Requirements and Solutions.. DirectAccess Infrastructure and User Tunnels DirectAccess Client Windows Advanced Firewall managed IPsec tunnels Settings controlled by GPOs IPv6 IPsec tunnel over IP HTTPS Name Resolution Policy Table (NRPT) *.internal.local is tunneled Exclusions: Network location server(s) DirectAccess server(s) Legacy VPN concentrator Infrastructure Tunnel Device certificate + Device authentication Established at system startup Intranet Tunnel (User) Device certificate + User authentication Established at user logon Requires smart card authentication DirectAccess Server Windows Advanced Firewall managed IPsec tunnels Settings controlled by GPOs IPv6 IP HTTPS endpoint IPv6 to IPv4 NAT service DNS IPv4 to IPv6 service Two NICs Internet / DMZ Intranet May 11,

16 Remote Access Requirements and Solutions.. DirectAccess : How it looks to normal users? When a user takes their Windows 8/10 device on travel or home, as soon as their device connects to wireless the device infrastructure tunnel immediately starts connecting to the DA server using the LOA2 device certificate and LOA2 password (LOA2+LOA2=LOA3) When a user logs on or unlocks their session using their Microsoft Virtual Smart Card (LOA3) or their YubiKey USB token (LOA4), the user tunnel connects after a short delay without interaction. Access to , file shares, applications seamlessly work* If a user performs a run as using another account, a separate user tunnel is created using those smart card credentials May 11,

17 Remote Access Requirements and Solutions.. DirectAccess : What are the concerns? DirectAccess is enabled per computer so ANY smart card mapped to a user account can connect Traditional internet proxy vs transparent proxy changes the world when tunneling is not forced (Good ol split tunnel discussions) DirectAccess is really easy to setup but majority of the problems with it are not DirectAccess related Smart card logon Applications with hard-coded IPv4 addresses Legacy client OS configurations that simply break DA When DirectAccess works, it works great. When it doesn t work, it s very difficult at times to troubleshoot with no single DirectAccess client log to troubleshoot. Mostly due to DA being integrated into the DNS client, Windows Firewall, IPv6 stack, etc May 11,

18 Bringing is all together.. Multi-factor authentication paired with future remote access technologies.. What does it look like? DirectAccess is not the only solution available that can satisfy the previously defined requirements Cisco AnyConnect currently has most of the features and/or is working to incorporate similar functionality The future of remote access is less about the methodology of creating the transport layer and more about how convenient it is for users to consume the service while not reducing the level of assurance An HSPD-12 PIV card is LOA4 but is just about the most inconvenient multifactor solution available but is the most compliant Windows Hello uses Biometric and Facial recognition to log into a Windows device BUT is not yet smart card authentication therefore does not satisfy checking the box on required smart card logon A device PIN paired with a device certificate is seamless but not as secure as a cryptographic module secured with a PIN May 11,

19 Questions? May 11,