IMO we should at least analyse at application level i.e. an application access a set of APIs in a particular sequence most of the time, but if there're multiple applications, API access patterns should be very different practically.
On Tue, Feb 16, 2016 at 2:18 PM, Seshika Fernando <sesh...@wso2.com> wrote: > Yep. if 2 is the case, still we dont need userID as it's new behaviour > will be different to the normal behaviour of all similar users so far. > > On Tue, Feb 16, 2016 at 11:43 AM, Fazlan Nazeem <fazl...@wso2.com> wrote: > >> Hi Seshika, >> >> The understanding from the requirement was that a user starts using the >> APIs and after sometime the request pattern changes for this user, and we >> should be able to detect this change. This could happen when the >> credentials of a specific user gets into a fraudulent user. That was the >> reason for including the userid into the state. >> >> I agree with your statement on, if a user was a fraudulent user from the >> beginning itself, we cannot identify his fraudulent activities with the >> approach I suggested. If that is the case then removing the userID from the >> state is the way to go. >> >> Can someone from the APIM team suggest which could be the more practical >> use-case when it relates to a fraudulent user out of the following. >> >> 1. A user is a fraudulent user from the beginning >> 2. A user becomes a fraudulent user after sometime >> >> @Seshika, do you think we could get rid of the userID even if [2] is the >> case. Under the assumption that there will be a lot more genuine users than >> fraudulent users? >> >> >> On Tue, Feb 16, 2016 at 11:19 AM, Seshika Fernando <sesh...@wso2.com> >> wrote: >> >>> Hi Fazlan, >>> >>> Could you explain the thinking behind assigning userID also as one of >>> the classifiers for the state? The reason I'm asking is that users can >>> learn from each others patterns as well. i.e. if a bunch of users are using >>> the same (or similar) set of apis, they will all follow similar request >>> patterns. Where as if we granularize at userID level, the fraudulent user >>> will probably use an anomalous sequence from the beginning. However, since >>> this is per user, the system will learn the fraudulent user's anomalous >>> sequence as a genuine sequence. >>> >>> seshi >>> >>> >>> On Tue, Feb 16, 2016 at 10:50 AM, Fazlan Nazeem <fazl...@wso2.com> >>> wrote: >>> >>>> Hi, >>>> >>>> I am in the process of implementing *Request pattern change detection* >>>> feature >>>> for API Manager analytics and the details are as follows. >>>> >>>> >>>> *Requirement* >>>> >>>> If a particular user access a set of APIs in a specific sequence. It'll >>>> be abnormal to have a different sequence from the same user all of a >>>> sudden. We are planning to use a Markov Chain model to identify this type >>>> of a change in request pattern. >>>> >>>> >>>> *Design* >>>> >>>> A state in the markov model is considered as a combination of UserID >>>> and the API used. The following state diagram illustrates this case(The >>>> state diagram is not complete). >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> The numbers with the arrows are the probabilities from one state to >>>> another(the probability of UserA invoking api_A followed by api_B is 0.1). >>>> These numbers will be calculated dynamically and populated in a DAS table >>>> using Siddhi queries. These numbers will then be used to calculate a metric >>>> named as *Miss Probability. *Using this metric and a suitable >>>> threshold, an alert will be generated once an abnormal request pattern is >>>> detected. >>>> >>>> If we are to consider a more granular approach for the states, then a >>>> single state could be changed into "*UserA_api_A_GET*" , where GET >>>> specified the resource method used in this API. in this case >>>> *UserA_api_A_GET* and *UserA_api_A_POST* will be two different >>>> states. APIM team please clarify on which approach is more useful and >>>> needed for the initial implementation. >>>> >>>> API manager publishes "org.wso2.apimgt.statistics.request" to DAS and >>>> this stream has the *userid, api, method *attributes. These three >>>> attributes could be used to build the markov chain. Please suggest me if >>>> any other combination of attributes would be more suitable than these >>>> three. >>>> >>>> >>>> Suggestions are welcome. >>>> >>>> >>>> >>>> -- >>>> Thanks & Regards, >>>> >>>> Fazlan Nazeem >>>> >>>> *Software Engineer* >>>> >>>> *WSO2 Inc* >>>> Mobile : +94772338839 >>>> <%2B94%20%280%29%20773%20451194> >>>> fazl...@wso2.com >>>> >>> >>> >> >> >> -- >> Thanks & Regards, >> >> Fazlan Nazeem >> >> *Software Engineer* >> >> *WSO2 Inc* >> Mobile : +94772338839 >> <%2B94%20%280%29%20773%20451194> >> fazl...@wso2.com >> > > -- Thanks & regards, Nirmal Team Lead - WSO2 Machine Learner Associate Technical Lead - Data Technologies Team, WSO2 Inc. Mobile: +94715779733 Blog: http://nirmalfdo.blogspot.com/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
