Hi all, The figure shows a high-level architecture for the risk score calculation. [image: Inline image 2]
- Authentication Data Publisher in the Identity Framework publishes the authentication events to a database - Authenticator requests a risk score from the risk score calculator. - Risk score calculator accesses the user login and geolocation databases and calculates the risk score. We will be considering IP address Geolocation Number of failed attempts between two successful logins when generating the rules to calculate the risk score. Regards, Pamoda On Tue, Jan 16, 2018 at 9:48 AM, Hasitha Hiranya <[email protected]> wrote: > Hi Ruwan, > > > On Tue, Jan 16, 2018 at 9:39 AM, Ruwan Abeykoon <[email protected]> wrote: > >> Hi Hasitha, >> There is a question about MAC address, which is not available beyond an >> IP router. What we do is browser fingerprinting with a cookie or something. >> >> *>> i.e I usually login to my personal Gmail using my phone. If I use my >> MAC machine suddenly, google sends an email if this is you. * >> IS 5.5.0 has default ability to do this with "Conditional >> Authentication", by fingerprinting the browser. >> >> Got it! Thanks for the explanation. > >> >> >> Cheers, >> Ruwan >> >> >> On Tue, Jan 16, 2018 at 9:20 AM, Hasitha Hiranya <[email protected]> >> wrote: >> >>> Hi all, >>> >>> We can also consider the MAC address or some machine ID of last >>> successful login as well. >>> >>> *i.e I usually login to my personal Gmail using my phone. If I use my >>> MAC machine suddenly, google sends an email if this is you. * >>> >>> Also previous success login location is also important. >>> >>> *i.e If I log into Facebook From Sri Lanka and after one day of >>> travelling if I log from United States, Facebook is suspicious and throw me >>> some security questions.* >>> >>> Thanks >>> >>> On Tue, Jan 16, 2018 at 9:09 AM, Ruwan Abeykoon <[email protected]> wrote: >>> >>>> Hi Pamoda, >>>> Here are some of my thoughts, and not in order or organized. >>>> >>>> User Behavior analytics (*UBA*) >>>> >>>> - >>>> >>>> Implement multi-dimensional clustering (this will detect general >>>> user behaviours. Not of an individual) >>>> - >>>> >>>> Implement clickstream analytics (This will have knowledge of >>>> individual, but keep the records indexed with UserID hash, so that, we >>>> can >>>> conform to GPDR) >>>> >>>> >>>> Both above algorithms may be run on a separate JVM, (or a feature on >>>> top of analytics). DAS will publish data to UBA. DAS will detect the fields >>>> in the analytics dimensions, which can be configured by the end user >>>> (Identity Admin). >>>> >>>> - >>>> >>>> This will cater 95% of UBA cases. >>>> - >>>> >>>> Events can be generated from IS well as any other application. E.g. >>>> Tomcat Filter, .Net Handler. >>>> - >>>> >>>> Self learning(or appears learning) *without ML.* Will be purely >>>> math based (statistics, and probability) >>>> - >>>> >>>> Automatic detection of new knowledge. >>>> >>>> >>>> >>>> - >>>> >>>> Uses DAS Siddhi. Should not use Spark. >>>> - >>>> >>>> Need to provide a gadget to visualize the clustered data and drill >>>> down. >>>> >>>> >>>> Clickstream >>>> >>>> - >>>> >>>> Click stream analysis is done with probability matrix of >>>> time-correlated events. >>>> - >>>> >>>> We keep a matrix in memory per each user, backed by DB. >>>> - >>>> >>>> Updates done on memory copy and periodically synced to DB (since >>>> few lost events does not really make much difference in probability >>>> matrix). >>>> - >>>> >>>> HA can be done with sharding of UserID. >>>> >>>> >>>> >>>> Analysis >>>> >>>> - >>>> >>>> Each event is sent to cluster analytics and clickstream analytics. >>>> - >>>> >>>> They will provide a result in a probability array of each type of >>>> anomaly. >>>> - >>>> >>>> Admin is given a UI to configure threshold of probability values, >>>> which he think important. >>>> - >>>> >>>> Admin can select an action(this is a Siddhi event publisher. One is >>>> to publish to JMS topic towards IS) >>>> - >>>> >>>> IS can decide upon authentication flow using its “Conditional >>>> Authentication in IS 5.5.0” >>>> >>>> >>>> Cheers, >>>> Ruwan >>>> >>>> On Tue, Jan 16, 2018 at 9:09 AM, Pamoda Wimalasiri <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Jan 16, 2018 at 8:13 AM, Prakhash Sivakumar <[email protected] >>>>> > wrote: >>>>> >>>>>> On Mon, Jan 15, 2018 at 8:28 PM, Dimuthu Leelarathne < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi Pamoda, >>>>>>> >>>>>>> Authentication history is a broad term. How do we plan to identify >>>>>>> exceptions? >>>>>>> >>>>>> >>>>> As authentication history, we can consider >>>>> >>>>> - number of consecutive invalid login attempts (as suggested by >>>>> Johan) >>>>> - geo velocity: time and location of the previous successful login >>>>> and the current login. >>>>> >>>>> >>>>> >>>>>> >>>>>>> thanks, >>>>>>> Dimuthu >>>>>>> >>>>>>> On Mon, Jan 15, 2018 at 8:04 PM, Johann Nallathamby <[email protected] >>>>>>> > wrote: >>>>>>> >>>>>>>> *[-IAM, RRT]* >>>>>>>> >>>>>>>> Apart from the business transaction value, following factors can be >>>>>>>> considered for risk calculation. >>>>>>>> >>>>>>>> 1. Environment - IP, network, geographical location, time of the >>>>>>>> day, device/OS/Device fingerprinting >>>>>>>> 2. Context - Previous successful login time, consecutive invalid >>>>>>>> login attempts followed by a successful attempt >>>>>>>> 3. User behavior - typing speed, etc. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Johann. >>>>>>>> >>>>>>>> On Mon, Jan 15, 2018 at 4:50 PM, Pamoda Wimalasiri <[email protected] >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I'm currently working on a risk score calculation method for the >>>>>>>>> authentication request of IAM. I'm still doing the background >>>>>>>>> research on >>>>>>>>> the behavior of other similar approaches [1] and the technologies >>>>>>>>> that can >>>>>>>>> be used. >>>>>>>>> >>>>>>>>> According to my research, the risk score can be calculated based >>>>>>>>> on parameters such as >>>>>>>>> >>>>>>>>> - IP address >>>>>>>>> - Geographical location >>>>>>>>> - Authentication history >>>>>>>>> >>>>>>>>> Are we considering only the past data here ? >>>>>> >>>>>> We should include the current active sessions too. For example if the >>>>>> user is already in an authenticated session and if she/he is trying to >>>>>> authenticate again, the 2nd attempt might be an attacker. >>>>>> >>>>>> >>>>>>>>> - Time of day >>>>>>>>> >>>>>>>>> In existing approaches, the total level of risk is calculated by >>>>>>>>> the sum of weighted scores of each parameter. >>>>>>>>> >>>>>>>>> Any suggestions are highly appreciated. >>>>>>>>> >>>>>>>>> [1] https://backstage.forgerock.com/docs/am/5.5/authenticati >>>>>>>>> on-guide/index.html#authn-adaptive >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Pamoda >>>>>>>>> -- >>>>>>>>> >>>>>>>>> *Pamoda Wimalasiri* >>>>>>>>> Software Engineer - WSO2 >>>>>>>>> >>>>>>>>> Email : [email protected] >>>>>>>>> Mobile : +94713705814 <+94%2077%20936%207571> >>>>>>>>> Web : https://wso2.com/ >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> *Johann Dilantha Nallathamby* >>>>>>>> Senior Lead Solutions Engineer >>>>>>>> WSO2, Inc. >>>>>>>> lean.enterprise.middleware >>>>>>>> >>>>>>>> Mobile: *+94 77 7776950* >>>>>>>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby >>>>>>>> <http://www.linkedin.com/in/johann-nallathamby>* >>>>>>>> Medium: *https://medium.com/@johann_nallathamby >>>>>>>> <https://medium.com/@johann_nallathamby>* >>>>>>>> Twitter: *@dj_nallaa* >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Dimuthu Leelarathne >>>>>>> Director, Solutions Architecture >>>>>>> >>>>>>> WSO2, Inc. (http://wso2.com) >>>>>>> email: [email protected] >>>>>>> Mobile: +94773661935 <+94%2077%20366%201935> >>>>>>> Blog: http://muthulee.blogspot.com >>>>>>> >>>>>>> Lean . Enterprise . Middleware >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Prakhash Sivakumar >>>>>> Software Engineer | WSO2 Inc >>>>>> Platform Security Team >>>>>> Mobile : +94771510080 <+94%2077%20151%200080> >>>>>> Blog : https://medium.com/@PrakhashS >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Pamoda Wimalasiri* >>>>> Software Engineer - WSO2 >>>>> >>>>> Email : [email protected] >>>>> Mobile : +94713705814 <+94%2077%20936%207571> >>>>> Web : https://wso2.com/ >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> *Ruwan Abeykoon* >>>> *Associate Director/Architect**,* >>>> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> * >>>> *lean.enterprise.middleware.* >>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *Hasitha Abeykoon* >>> Associate Technical Lead; WSO2, Inc.; http://wso2.com >>> *cell:* *+94 719363063* >>> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> *Ruwan Abeykoon* >> *Associate Director/Architect**,* >> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> * >> *lean.enterprise.middleware.* >> >> > > > -- > *Hasitha Abeykoon* > Associate Technical Lead; WSO2, Inc.; http://wso2.com > *cell:* *+94 719363063* > *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> > > -- *Pamoda Wimalasiri* Software Engineer - WSO2 Email : [email protected] Mobile : +94713705814 <+94%2077%20936%207571> Web : https://wso2.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
