Hi, According to the offline discussion done, the design is to incorporate
- api context - method - resourcePath into a single state. This way we could preserve the application level request pattern as Nirmal mentioned. Sheshika can you please verify this approach? For example a state transition would be as follows. - api context (/calc/1.0) api context (/calc/1.0) - method (GET) ---------------------> method (GET) - resourcePath *(add*) resourcePath (*subtract*) On Wed, Feb 17, 2016 at 8:36 PM, Nirmal Fernando <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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> >>>>> [email protected] >>>>> >>>> >>>> >>> >>> >>> -- >>> Thanks & Regards, >>> >>> Fazlan Nazeem >>> >>> *Software Engineer* >>> >>> *WSO2 Inc* >>> Mobile : +94772338839 >>> <%2B94%20%280%29%20773%20451194> >>> [email protected] >>> >> >> > > > -- > > Thanks & regards, > Nirmal > > Team Lead - WSO2 Machine Learner > Associate Technical Lead - Data Technologies Team, WSO2 Inc. > Mobile: +94715779733 > Blog: http://nirmalfdo.blogspot.com/ > > > -- Thanks & Regards, Fazlan Nazeem *Software Engineer* *WSO2 Inc* Mobile : +94772338839 <%2B94%20%280%29%20773%20451194> [email protected]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
