Re: Duo Security concern -- EDU support requested

[Cam Beasley <cam () UTEXAS EDU>]

all —

i wanted to offer an update.
thanks to everyone who reached out to Duo about this.
i’ve included the unedited response from Duo below and have provided a few other related comments.


\\ UT Comments \\

1) it appears some institutions have created their own registration portal and maintain it themselves. UT Austin did 
the same with a previous 2FA vendor and learned that this approach is not something we wanted to repeat with Duo. the 
maintenance logistics were too great and we felt we should use Duo’s features. we admit that if someone built their own 
tool they would be able to more easily track and react to events. again, we deemed the logistics of maintaining such a 
tool too great and we do not have the resources for this.

2) some responses i’ve received indicate that other institutions rely on the admin portal to review and audit logs. our 
concerns and responses revolve around using the API to get the information. not all of the things needed have been 
available in the API but are available in the admin portal.  Duo has since mentioned that they all be deploying a 
self-serve portal option in future.

3) Duo documentation currently states not to trust features available in the API until they are documented and that 
they could change, appear or disappear at any time.
that said, they will be making changes to relax this position as they now implement versioning with their API.

4) we are not receiving change notifications. we would like to receive notification of when a feature is added (e.g. a 
change log). Duo has noted that they will begin more proactive communications to customers regarding changes in API and 
other areas of their product.

5) user Registration: we have reviewed findings regarding user registrations being available. it appears the API has 
changed since we looked at it and we can now get user registration information from the authentication log.  this was 
not presented to us when we spoke to Duo a week ago.  the documentation has not caught up to this feature being 
available. given item #3, we do not know if this could change. we were never informed that this change occurred. this 
is a feature request that we submitted.

6) user status changed to active status: we might have missed this one being available from the API, but it could have 
been introduced after our last look.  it wasn’t mentioned by Duo as being available to us when we asked a week ago.  

7) user status changed to locked out status: this doesn’t appear to be available. in our discovery, a log entry is not 
generating at the actual occurrence of the lock. a log entry indicating a failed authentication due to a locked account 
does occur.  for instance, a user fails to login five times, receives a failed login message, and each of those failed 
attempts are logged. Duo will lock the account; but, a log message is not generated. then, on the sixth attempt, the 
user will fail to login again; but, this time, the log states the reason as locked account.  Duo has said that they 
will be expanding on the currently logging to address this.

\\ Duo Response \\

Thank you for sharing your concerns. We value your feedback and have engaged our Product Development and Security teams 
to evaluate both the feasibility and security implications of your request.  It is important to note that we do not 
view the features you are requesting as security gaps. 

The events you mention below are logged in our system, and we are regularly looking at improving the administration 
experience to surface emergent events.  Instructions on how to access this log data can be found at the end of this 
note. In terms of proactive alerting, we are looking at this from two different perspectives: End Users and 
Administrators.

End User Alerting
After careful consideration, we have decided not to pursue alerting end users for the following reasons:
        • With user registration, the user is fully involved in the enrollment process.
        • With user deregistration, deletion can only be invoked by an administrator.
        • If an adversary has compromised a device, end user notifications about status changes would be sharing 
information that tips off the adversary as to how to proceed.
                • All four user statuses (active, bypass, disabled, locked out) empower adversaries with better 
intelligence. 
                • While an “active” status may convince an attacker to give up, a “bypass” status may encourage them to 
proceed with their attempt to infiltrate an organization.
        • All four user statuses (active, bypass, disabled, locked out) are remediated by administrators, not by end 
users. This is why we are prioritizing administrative logging and access to that data.
Ultimately, we want to minimize friction for end users to only aspects of the product that they can control themselves 
(authentication, self-remediation, managing devices). We do see value in notifying end users about device registration 
and/or deregistration on their Duo account. We will be exploring additional notifications through our Duo Mobile 
application.

Administrator Alerting
We do plan to support Administrator alerts in two ways. 
        • First, we know that many of our customers are using SIEMs, so we plan to publish an official Splunk module 
this year. We are in the early planning stages right now, but we will share more details in Q3 of this year and will 
reach out with questions around use cases.
        • Second, we are assessing in-product notifications for administrators; however, we want to be thoughtful about 
how noisy this will be for our customers. We are going to start off with alerting around security notifications, and we 
will grow capabilities from there. This is a longer term project.

In addition to the above, we are working on a complete refresh of our Dashboard in Q3 of this year.  One of the goals 
of the redesign will be to improve our ability to surface actionable data for your administrators - for example, locked 
out users that your help desk can work with immediately.

How to access log data 
        • user registration (users)
                • For bulk enrollments: Users -> Pending Enrollments
                • For Admin Panel: Reports -> Administrator Actions -> user_create
                • Admin API: https://duo.com/docs/adminapi#administrator-logs
                        • Action: “user_create”
        • user de-registration (phone)
                • For phone deletion: Reports -> Administrator Actions -> Disassociated phone
                • For user deletion: Reports -> Administrator Actions -> phone_delete
                • Admin API: https://duo.com/docs/adminapi#administrator-logs 
                        • Action:phone_disassociate
        • user status changed to locked out status
                • Reports -> Authentication Logs -> Disabled*
                • *We are in the process of updating this response to “Locked Out”
                • Admin API: https://duo.com/docs/adminapi#authentication-logs 
                        • Result: Failure | Reason: Locked Out
        • user status changed to active status 
                • Reports -> Administrator Actions -> Click Modified User
                • Admin API: https://duo.com/docs/adminapi#administrator-logs 
                        • Action: user_update | Description: active
        • user status changed to bypass status
                • Reports -> Administrator Actions -> Click Modified User
                • Admin API: https://duo.com/docs/adminapi#administrator-logs
                        • Action: user_update | Description: bypass
        • user status changed to disabled status
                • Reports -> Administrator Actions -> Click Modified User
                • Admin API: https://duo.com/docs/adminapi#administrator-logs 
                        • Action: user_update | Description: disabled


\\\\\\\\\\\\\\\\\\\


hope this helps,


~cam.




> On Apr 26, 2016, at 7:46 AM, Cam Beasley <cam () utexas edu> wrote:
>
>
> [ATTN: Duo Security campuses]
>
>
> colleagues -
>
> i wanted to share something we’ve discovered in our deployment of Duo in hopes that more attention from customers 
> will help motivate the vendor to address an important security gap.  Duo has tentatively projected a solution for 
> late-2017, but has said that more feedback from EDU customers would allow them to bump it up on their development 
> schedule.
>
> ————-
> issue
> ————-
>
> based on our testing, there is significant security gap around user notification for certain Duo events.
> these Duo events provide NO user communication and we believe users should have an option of being kept in the loop:
>
>        - user registration
>        - user de-registration
>        - user status changed to active status
>        - user status changed to bypass status
>        - user status changed to disabled status
>        - user status changed to locked out status
>
> this issue is made worse by the fact that many of these events are not reflected directly in the logs Duo generates.  
> as a result, there are very limited options for us to ensure the security of our users for these types of events.
>
> ————-
> action
> ————-
>
> if you agree that this is a gap you would like for Duo to address sooner than 18-mos from now, then please reach out 
> to your respective Duo representative as soon as possible.
>
> please let me know if you have any questions.
>
> thanks very much for your help,
>
>
> ~cam.
>
>
>
> --
> Cam Beasley
> Chief Information Security Officer
> Information Security Office
> The University of Texas at Austin
> security () utexas edu | 512.475.9242
> http://security.utexas.edu
> =======================================
> https://www.facebook.com/utaustiniso
> https://twitter.com/UT_ISO
> =======================================

Attachment: smime.p7s
Description: