You're standing in line at the bank when someone walks in. You instinctively look around and notice the newcomer is wearing sunglasses,  and a hooded sweatshirt. His hands are both inside the pockets of his sweatshirt, even though it's warm inside. He chooses a line, and bank robberdances nervously from foot to foot, craning his neck to see to the front of the line. After a few minutes he leaves the line and chooses a new one, growing increasingly agitated at the wait. He keeps looking from the clock to the line to the tellers, and appears to be wringing his hands beneath the cover of his sweatshirt pocket.

Is this newcomer:

a. Suffering from medication-induced photosensitivity?

b. Worried his ex-girlfriend will see him and make a scene?

c. Planning on robbing the bank?

You're suspicious, no doubt, about the newcomer's actions and you probably assume (c). He isn't acting normally which sets off alarm bells in your head. You may not act immediately on your suspicion, but you're certainly going to keep an eye on him. When you can see someone interacting in a social setting you can tell when something isn't quite right. There's normal behavior for any given situation and then there's abnormal or even suspicious behavior.

The problem with technology, and web applications in general, is that you can't see the user. Worse, you can't even really see the entire context of his interactions with the web application because very few security implementations have the capability to evaluate user behavior (interaction with the application) as a holistic experience. Web application security solutions today simply can't tell what's normal behavior across the application.

Oh, it can tell what's normal when interacting with any given variable or page within a web application. Today that's how we determine "bad" (or at least suspicious) behavior from legitimate behavior: based on individual interactions with any given parameter or page in a web application.

Today we can do a lot to determine whether a user may be intent on malicious action or not. We can implement rulesets that examine the interactions against learned or known "good" interactions to help us determine what is not legitimate behavior, and then we can act on that information. But making security decisions based on single interactions on a web site may not be enough to ferret out potential attacks. Rather than determining the bad guy is, in fact, a bad guy based on the fact that he's dancing from one foot to another (he may just need a bio break, after all) we need to evolve to the point where we can examine the behavior of a user across the application, taking into consideration the context of his or her interactions with the application as a whole, rather than as discrete, disconnected events.

We need context.

That context needs to be longer lived than a single session. We need web application security systems more in line with fraud detection systems used by financial institutions. Systems that know John Q Customer logs into the application 99% of the time from Location A so that when he logs in from Location B our "threat posture" is immediately and automatically elevated such that we watch his interactions with the application even closer than we normally would. Systems that recognize that Betty Buyer has always used Internet Explorer to log in, so the fact that she's suddenly using Opera is definitely "outside the bounds" of normal behavior for her, like the suspicious man at the bank wearing a sweatshirt on a humid summer day.

F5-Apps-BagWe need web application security systems capable of understanding the typical flow of application logic between pages and recognizing that it is a potential attack when someone is flitting around the system in an atypical fashion, poking around and looking for potential holes in the wall through which they can exploit some vulnerability. We need systems that can recognize that Page X is never accessed directly, nor from any other page in the system except Page B - and we need to be able to trigger an alarm or "raise the threat level" when it is suddenly accessed, somehow, from Page D instead.

We are slowly evolving our web application security solutions to be more context aware. The solutions of today and the near future are more contextually aware and capable of employing that knowledge to prevent attacks than they were five years ago. But the context is almost always about right now and rarely takes into consideration "normal" behavior of the past. We need historical context as well as current context in order to pull it all together and begin really understanding when a user is a potential threat.

The question has been asked regarding TSA regulations and security policies: Why do we focus on bad things rather than bad people?

The answer is simple: because we can't always tell "bad" people from "good" based on a single interaction. We need history, we need context, we need a holistic view of the person and, in fact, all people who interact with any given system in order to determine what is "normal" and what is not; what may be a potential threat and what is simply an anomaly.

We need to be able to profile behavioral interactions with applications, determine what is typical and accepted, and then act on that information when a user acts outsides those norms. We need systems that automatically recognize atypical interactions with a web application and can upgrade the threat level automatically as necessary, to the point of blocking or stopping the interactions due to excessive atypical behavior.

We can continue to build systems that inspect things (data) rather than behavior but in doing so we will continue to always be one step behind the newest, latest attack method. To get ahead of the attackers we need to start examining behavior of the user contextually and historically and, more importantly, holistically.

 

Follow me on Twitter View Lori's profile on SlideShare friendfeedicon_facebook AddThis Feed Button Bookmark and Share