Re: Duo Security concern -- EDU support requested

[Brad Judy <brad.judy () CU EDU>]

Cam,

We¹ve been pulling the Duo logs into our SIEM for more than a year via
some Python one of their customers wrote to pull logs via the API.

Brad Judy
 
Information Security Officer
Office of Information Security
University of Colorado
1800 Grant Street, Suite 300
Denver, CO  80203
Office: (303) 860-4293
Fax: (303) 860-4302
www.cu.edu <http://www.cu.edu/>
 

 






On 4/29/16, 4:38 PM, "The EDUCAUSE Security Constituent Group Listserv on
behalf of Cam Beasley" <SECURITY () LISTSERV EDUCAUSE EDU on behalf of
cam () UTEXAS EDU> wrote:

> 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
> > =======================================