+1 On Thu, Feb 18, 2016 at 10:22 AM, Fazlan Nazeem <[email protected]> wrote:
> 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
