Hi All,

Currently, we have implemented two types of alerts [1] in IS Analytics to
monitor suspicious login attempts and abnormal login sessions. We have
defined set of rules to detect such abnormal login activities using Spark
and Siddhi queries. So you can improve and reuse them as well for
calculating the risk score IMO.

Right now users can only get alerts and they have to act themselves to
mitigate any suspicious login activities. But if we can do the risk score
calculation in real time as for the proposed architecture it can be used to
mitigate any risks from the identity framework level itself. We may be able
to block the user or at least terminate the user session immediately if the
risk score is greater than a particular threshold value. But again we have
to be careful with the false positives as well since it can affect the user
experience.

[1] https://docs.wso2.com/display/IS540/Alert+Types

Thanks,
Ashen

On Fri, Jan 19, 2018 at 9:34 AM, Dimuthu Leelarathne <dimut...@wso2.com>
wrote:

> Hi Ruwan,
>
> I am thinking of using the existing architecture as it is. Right now there
> is an eventing listeners that publish data to DAS. I propose we reuse it as
> it is. Those event listeners that publish data can be X-EventListener,
> Y-EventListener, etc ... There are a lot of data that we can reuse in
> IS-analytics.
>
>
> ​
>
> Whatever the risk calculator does is to reuse the existing data-stores as
> the above diagram.
>
> thanks,
> Dimuthu
>
> ​
>
> On Fri, Jan 19, 2018 at 9:04 AM, Ruwan Abeykoon <ruw...@wso2.com> wrote:
>
>> Hi Pamoda,
>> Can we enhance the architecture a little bit. We need to decouple "Risk
>> Calculator" and "Identity Framework" further.
>>
>> IS needs a mechanism to receive the feedback from the pub/sub channel and
>> make changes in authentication flow.
>>
>> <https://www.draw.io/#G0B0bx735ZWbanc0M5eDhDamowbzg>
>>
>> 1. The Temporal data is a Lucene store. Held at IS side. Central location
>> for all IS cluster.
>> 2. MQ is used, so that any third  party can publish "Risk" or any other
>> information.
>> 3. The authenticator will not request anything from the "Risk
>> Calculator", but queries its own store. This will make things more
>> resilient on chaos scenarios.
>>
>>
>> This allows us to do lot more, e.g
>>
>>
>>
>>    -
>>
>>    Use stream analytics to make fast decisions.
>>    -
>>
>>       E.g. Too many authentications attempts coming from a particular
>>       IP, on a given time window, then upgrade the flow to Two factor
>>       authentication.
>>       -
>>
>>    Use batch analytics to perform simple behavioural decisions
>>    -
>>
>>       E.g. Users who has logged in and has session(not logged out),
>>       tries to log in on another machine, could be prompted with another 
>> screen
>>       saying they have existing sessions on other machine.
>>       -
>>
>>    Throttling and Shaping based on billing tier exceeding conditions.
>>    -
>>
>>    Use ML to do advanced behavioural decisions
>>    -
>>
>>       (Seshika will be interested in this)
>>
>>
>> e.g.
>>
>> var agentChanged = queryAnalytics('lucene', '<lucene-query> e.g. name :
>> agent-change-stream, subject: authenticatedSubjectId');
>>
>> if (agentChanged) {
>>
>>   executeStep({'id' : '2'});
>>
>> }
>>
>> On Fri, Jan 19, 2018 at 8:49 AM, Pamoda Wimalasiri <pam...@wso2.com>
>> wrote:
>>
>>> 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 <hasit...@wso2.com>
>>> wrote:
>>>
>>>> Hi Ruwan,
>>>>
>>>>
>>>> On Tue, Jan 16, 2018 at 9:39 AM, Ruwan Abeykoon <ruw...@wso2.com>
>>>> 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 <hasit...@wso2.com>
>>>>> 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 <ruw...@wso2.com>
>>>>>> 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 <pam...@wso2.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jan 16, 2018 at 8:13 AM, Prakhash Sivakumar <
>>>>>>>> prakh...@wso2.com> wrote:
>>>>>>>>
>>>>>>>>> On Mon, Jan 15, 2018 at 8:28 PM, Dimuthu Leelarathne <
>>>>>>>>> dimut...@wso2.com> 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 <
>>>>>>>>>> joh...@wso2.com> 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 <
>>>>>>>>>>> pam...@wso2.com> 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 : pam...@wso2.com
>>>>>>>>>>>> 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: dimut...@wso2.com
>>>>>>>>>> Mobile: +94773661935 <+94%2077%20366%201935>
>>>>>>>>>> Blog: http://muthulee.blogspot.com
>>>>>>>>>>
>>>>>>>>>> Lean . Enterprise . Middleware
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Architecture mailing list
>>>>>>>>>> Architecture@wso2.org
>>>>>>>>>> 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 : pam...@wso2.com
>>>>>>>> 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
>>>>>>> Architecture@wso2.org
>>>>>>> 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
>>>>>> Architecture@wso2.org
>>>>>> 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 : pam...@wso2.com
>>> 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.*
>>
>>
>
>
> --
> Dimuthu Leelarathne
> Director, Solutions Architecture
>
> WSO2, Inc. (http://wso2.com)
> email: dimut...@wso2.com
> Mobile: +94773661935 <+94%2077%20366%201935>
> Blog: http://muthulee.blogspot.com
>
> Lean . Enterprise . Middleware
>
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Ashen Weerathunga*
Software Engineer
WSO2 Inc.: http://wso2.com
lean.enterprise.middleware

Email: as...@wso2.com
Mobile: +94716042995 <94716042995>
LinkedIn: *http://lk.linkedin.com/in/ashenweerathunga
<http://lk.linkedin.com/in/ashenweerathunga>*

<http://wso2.com/signature>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to