...
Failed Authentication Counter
Berkeley was interested Benn reported that UC Berkeley has been interested in counting failed authentication as a way of looking at pas ward password entropy and reset policies for for the bronze and/or silver profiles. There was the straw man strawman proposal posted to spaces wiki
Looked using a SYSLOG to export to a central accumulator
Which would put relevant events in a simple database table
Which a monitor could pull
And send an email or
Cut off an assurance qualifier
Thought we Could do reporting out from credential stores using existing technology and aggregating results w existing technology
But the monitor was the big gap
Brett from U Nebraska Lincoln had a similar system that he demoed at Idnetity week
the wiki athttps://spaces.at.internet2.edu/display/InCAssurance/Failed+Authentication+Counter+Strawman
Berkeley has contracted with The news is that Berkeley has signed a contract w Unicon to build out this monitor
It will be open source under the BSD ? license
Developmetn will be open in that we have a GITHUB ? Where the code will be placed as developed
Will be using internal issue tracker for project management purpose but it will be world readable
Docuemntation is internal
Need to make that more accessible
The development is about to kick off
So code should be going out soon
A couple of months before we have reasonably full featured project
But moving along
Still to be Determined where final home of the project will be
Benn can talk about what the monitor will be capable of
Or at least what is scoped into the SOW
Minute 26.
Ann is interested in that
Sure
Not that much
Failed Authentication monitor. Things are moving along and development is about to start. It should be a couple of months before there is reasonably full featured project. This will be an open source project. Code will be in GitHub.
The scope of the work involves an aggregator that writes failed authentication The aggregator writes failed auth events to a database that logs the subject, the time, and IP address and a service
. The monitor periodically (TBD) queries this
Periodically is TBD
. There will be thresholds with actions fired off at a given thresholdSo . So for example, the system might be configured so that after 10K events, email this addressActions are e-mail . The email might go to the subject,
Or or to an arbitrary another email address
Notify such as the security teamOr . Another action that could be triggered might be to cut a ticket to an issue tracking system. End goal is ability to stop asserting an IAQ for someoneHave . There may be the ability to add or remove somebody to a group (such as Grouper)
Berkeley will track IAQs in one or more Grouper groups
Where , where removing somebody from the group would effectively remove them from LDAP
Expiring credentials directly is another potential action
Or send a message (in JSON?) to an endpoint
Updating LDAP directly rather than going through a group store
Fire . The idea is that the the system will fire off the appropriate actions and record history that it did that. There would be an API into it for user level and Admin operations, such as obtaining current counts for a user
. That could be tied into the user identity portal, so you can put a report out for notification when the user logs in
Need integration w credential management apps to reset the counter
. Obtaining and setting thresholds .
Configured will be configurable via a database
Configuration options would be set via a UI, possibly after the 1. 0 release
Benn will send links to the Assurance list as portions are released publicly
Ann: Benn could also put info on the Assurance wiki, the straw man and the requirements document are in the wiki already
===
Karen, add anything?
Nothing , thanks for asking though
===
Scott, nothing to add
====
David, general comments, I have now linked the draft documentation page into the project status pDi