Re: MFA Deployment Questions

[Tim Lane <tim.lane () GRIFFITH EDU AU>]

Hi All,



I've had quite a few responses on MFA including many institutions asking
for the feedback to be collated and provided back to the forum, so in the
absence of having established a survey I have summarised both the responses
received as well as some insights from our  USA counterparts.



*(1) If you have an MFA deployment, is this just for staff, or only for
students or for both?  What about Alumni?'*


The extent of MFA rollout varies significantly across Universities from
virtually nothing to the entire cohort of all staff and students. In
general however the priority of rollout appears to be based on staff first
and then optionally students. The main identified drivers for providing MFA
to staff before students are outlined below:


   - *Credentials Misuse *– it is generally identified that there is a
   direct threat associated with staff in broad based phishing as well as
   senior staff being targeted (Spear Phishing, Whaling, BEC etc).  Phishing,
   malware/keystroke logging, password handling, weaknesses in lifecycle
   account management and the use of shared accounts has resulted in staff
   generally being prioritized.  Additionally, staff have access to sensitive
   data across a number of key systems such as Finance, HR and Student,
   Learning Management as well as other systems.  This level of access
   compares to a lower level of access by Students and while Students also
   receive phishing emails generally their access to applications does not
   have the potential to impact the University as much as Staff access does.
   - *UX -* There is a requirement to manage the balance between the
   security benefits of MFA against the user experience impact.  As rollouts
   can be quite involved and extended, rolling out to staff first allows for
   initial pilot groups to be established (particularly with IT Staff,
   selected key senior staff as well as third party contractors) as well as
   focusing on the most at risk areas.  Getting a solid MFA pilot established
   first allows the rollout to effectively managed prior to going to
   students.  While both Staff and Students can be Opt in, however rolling out
   to staff as a contained pilot together with Opt was seen as providing for
   greater flexibility.  Additionally students may require a greater level of
   externally based change management and engagement for MFA.


 *(2) What were the main business/technical drivers surrounding the
decision on the above deployment*


   - *Business drivers – *core business drivers associated with MFA
   included  risk management over key systems or users to protect against
   specific threats (phishing and other password compromise) or alternatively,
   compliance with policy or regulatory requirements, or as a security option
   for members of the institution concerned about data privacy and credential
   theft
   - *UX and acceptance by the user community *– the deployment strategy
   has a reliance on achieving reasonable takeup and MFA needs to be viewed
   as a security enhancement.  Risk management in terms of deployment scope
   from both reducing risk but also managing user impact is seen as an
   important consideration for both initial rollout and then ongoing management
   - *Technical Drivers: Architecture *– as IAM is a complex area selecting
   MFA solutions can involve long rollout timeframes including the requirement
   for inventory applications to determine if they are compatible with
   federation (such as SAML OpenID Connect), LDAP or RADIUS. Also institutions
   have needed to make decisions regarding the sole reliance on smartphones
   alone else reviewing the need for other OTP coexistence options.
   - *Transformation in MFA – *increasingly MFA is focused on improvements
   such as behavioural analytics, adaptive authentication and methods that
   are threat resistant and user friendly.  Therefore, particularly with the
   mobile and cloud journey, institutions are looking for risk based
   analytics and adaptive authentication techniques (contextualised or
   step-up security) which are seen as relevant now while more advanced
   predictive and prescriptive analytics are seen as being necessary for
   future rollouts.



 * (3) What systems based scope was MFA implemented for: *


 While there are various approaches, roadmap priorities are frequently
cited as:


   - VPN, IT privileged and contractor based RDP/SSH system access
   - Privileged access to On Prem web applications and core business
   applications (HR, Finance etc.) and/or other select high risk applications
   - Identity federation and web SSO, or Authentication based on Remote
   Authentication Dial-In User Service (RADIUS) and Lightweight Directory
   Access Protocol (LDAP)
   - Cloud based Email (increasingly prioritised due to phishing).

 The May 2017 EDUCAUSE Almanac (*based on the EDUCAUSE Core Data Service
and the EDUCUASE Center for Analysis and Research*) cites the top uses of
MFA by USA based educational institutions as:


   - Business-critical applications (e.g., financial or HR systems) (32%)
   - E-mail (10%)
   - IT administrative access (8%)
   - Remote access (8%)

Information previously collected from the EDUCAUSE MFA Cohortium cites the
Top Ten Applications for MFA as:  https://spaces.internet2.
edu/display/scalepriv/Top+Ten+Applications+for+MFA+in+Higher+Education





* (4) What MFA solution do you use? *



This is based to a large degree on existing architecture and scope of
deployment and can include a hybrid of off the shelf and home grown
solutions.  However Duo is very popular and increasingly MS Azure MFA
Server (with Premium Licence) is gaining traction as we move toward MS
cloud (O365 SaaS and Azure).  MS MFA and Duo provide strong support for
most popular use cases.  Other identified providers include Okta, RSA,
SecureAuth, Symantec, SafeNet, Authy and Centrify.



I’ve included a link to PPT slides from a 2017 EDUCAUSE presentation
titled *“Beyond
Passwords: A Discussion on How Campuses Are Successfully Deploying
Multifactor Authentication.”
<https://events.educause.edu/~/media/files/events/special-topic-events/security-professionals/2017/presenter-resources/beyond-passwords_slides.pdf>*
 This showcases 4 USA based Universities who have undertaken significant
MFA deployments.



Additionally, several Australian/NZ Universities are well underway with MFA
rollouts, again Duo seems to be very popular.





* (5) Preferred auth factor style for best UX?*



A phased Opt in approach seems to be a core part of many institution’s UX
decision.



Mobile device as a token (mobile push modes and OTP generating apps)
dominate in popularity as traditional key tokens and hardware one-time
password (OTP) tokens are relegated to legacy. Mobile Push appears to be
the default with SMS on the decline (NIST cite SMS as deprecated
<https://www.schneier.com/blog/archives/2016/08/nist_is_no_long.html>).



Mobile Push and OTP App are supported by most vendors, with hardware based
OTP options the second most supported method. There is also increasing
support for MFA using wearables and FIDO Universal Second Factor (U2F) such
as Yubico.


Functions such as bypass codes and credential wallets are seen as desirable.


It is noted that enrollment processes need to include risk-appropriate
identity proofing and providing ongoing self-serve options are essential to
ensure that not only enrollment is secure but that ongoing management and
maintenance can be more easily supported.



 Regards,


Tim





On Thu, Oct 26, 2017 at 4:13 PM, Tim Lane <tim.lane () griffith edu au> wrote:

> Hi Cybersecurity Members,
>
> we are reviewing approaches to MFA and would appreciate responses on the
> below questions:
>
> (1) If you have an MFA deployment, is this just for staff, or only for
> students or for both?  What about Alumni?
>
> (2) What were the main business/technical drivers surrounding the decision
> on the above deployment?
>
> (3) What systems based scope was MFA implemented for: i.e.
>
>    - Only for key identified apps (example email etc)
>    - VPN
>    - Privileged Access (Admin roles)
>    - Identity federation and SSO, LDAP etc
>    - Access to on Prem web apps/cloud apps
>    - Remote Desktop
>    - Other
>
> (4) What MFA solution do you use?
>
> (5) Preferred auth factor style for best UX?
>
> Thanks in advance,
>
> Regards,
>
> Tim
>
>
> *Tim Lane| Cybersecurity Projects Manager*
>
> *Office of Digital Solutions*
> *Griffith University* *| Nathan Campus | QLD 4111 | Building location N12
> Room - 1.02J*
> *T +61 7 3735 7838 <+61%207%203735%207838> | email **tim.lane () griffith edu au
> <tim.lane () griffith edu au>*
>
>
> *Cybersecurity is Everyone's Responsibility!  *
> https://www.griffith.edu.au/cybersecurity
>
>
>
> PRIVILEGED - PRIVATE AND CONFIDENTIAL
>
> This email and any files transmitted with it are intended solely for the
> use of the addressee(s) and may contain information which is confidential
> or privileged.  If you receive this email and you are not the addressee or
> responsible for delivery of the email to the addressee(s), please disregard
> the contents of the email, delete the mail and notify the author
> immediately.


-- 
*Tim Lane| Cybersecurity Projects Manager*

*Office of Digital Solutions*
*Griffith University* *| Nathan Campus | QLD 4111 | Building location N12
Room - 1.02J*
*T +61 7 3735 7838 <+61%207%203735%207838> | email **tim.lane () griffith edu au
<tim.lane () griffith edu au>*


*Cybersecurity is Everyone's Responsibility!  *
https://www.griffith.edu.au/cybersecurity



PRIVILEGED - PRIVATE AND CONFIDENTIAL

This email and any files transmitted with it are intended solely for the
use of the addressee(s) and may contain information which is confidential
or privileged.  If you receive this email and you are not the addressee or
responsible for delivery of the email to the addressee(s), please disregard
the contents of the email, delete the mail and notify the author
immediately.