The Rise of Application SOCs

I completely agree. The application level security operation center is a must for anyone that wants to defend enterprise grade applications from attackers. However, there is an important balance between the necessity of automated response and requirements for human analysis.  Its just not feasible for a human to analysis every generated event. That's where we leverage the magic from a low/zero false positive detection network within the application itself.

I had the fortune of working a few years in the Motorola network security operation center and am using that knowledge, along with AppSensor concepts, to form the foundation of an Application SOC at Mozilla.

From Dailydave:

So when I gave the FIRST talk, one of the questions was 
"What is the solution?" which when people ask that usually 
has a slight overtone of "It's easy to knock the blocks down, 
but not to set them up!" to it.

Here's what I see:

The major problem with 90's era technology (i.e. scanners/
sniffers!) is that they are in a very high noise/low signal 
environment. This is as true for static code analysers as 
it is for IDSs and Web Application Firewalls.

Immunity sees lots of success (and has for many years) with 
organizations that have done high level instrumentations 
against their applications, and then used powerful data 
mining tools to look at that data.

But with all Things That Really Work (tm), there are many 
traps:
1. Analysis is mind bogglingly expensive. It takes lots of 
time, you never know if you're going to find something 
useful, and the people and tools to do it are expensive. 
Palantir is just one example of how hard this problem is 
in general, but even just having the DISK SPACE to do it 
on is prohibitive.

2. Choosing what to instrument is extremely hard as well. 
There's some work being done on this:
http://www.owasp.org/index.php/Category:OWASP_AppSensor_Project

3. Visualization is hard - security visualization often 
is great once you already have found something (i.e. "Here 
it is in a pretty graph"). If you haven't already found 
something, visualization is a hard thing to make "exploratory". 
Especially with lots of data.

________________________________________________________

So what you see is the start up of what I like to call the 
"Application SOC". It's like a network SOC, but way more 
expensive, and with the chance of being actually useful! :>

I'll go more into this whole thing when El Jefe goes into 
Beta, but for now, who has gotten caught by something like this?

- -dave

-Michael Coates

OWASP AppSec USA Call For Papers

OWASP AppSec USA
UC Irvine Conference Center
September 7 - 10, 2010


Call For Papers ends June 30. More Info

Submit now at Easy Chair

Topics of Interest:

- Business Risks with Application Security.
 - Starting and Managing Secure Development Lifecycle Programs.
 - Web Services-, XML- and Application Security.
 - Metrics for Application Security.
 - Application Threat Modeling.
 - Hands-on Source Code Review.
 - Web Application Security Testing.
 - OWASP Tools and Projects.
 - Secure Coding Practices (J2EE/.NET).
 - Privacy Concerns with Applications and Data Storage
 - Web Application Security countermeasures
 - Technology specific presentations on security such as AJAX, XML, etc.
 - Anything else relating to OWASP and Application Security.

-Michael Coates

Questions & Answers from AppSensor Presentation

Today's presentation on Automated Application Defenses to Thwart Advanced Attackers was a success with great attendance and many good questions. Missed the presentation? Check out the recorded version here.

Links of interest:
OWASP AppSensor Project
AppSensor Detection Points
AppSensor Code
OWASP ESAPI Project

Not enough time was available to answer all of the questions so I thought I'd post those questions and answers here:

Q: Why not build secure application right away? Training the developer and thorough penetration testing prior to release the app to the internet?
A: Totally agree. The application intrusion detection concepts described within the presentation are intended to be performed after you've developed your secure application. So take all of your current security practices: threat modeling, secure SDLC, penetration testing, etc, and then add on the application intrusion detection concepts described by AppSensor.  This is intended to be a method of detecting and eliminating malicious users before they possibly locate a vulnerability in your app (that you weren't aware of).

Q: Isn't that just a little like the "honey-pot" strategy? Why not build a real attacker trap in each application, which is not reachable by normal usage of the application by a legitimate user?
A: It is very similar. We are basically implementing detection points that can be though of as "trip-wires" or "honey pots". The detection points are intended to detect a user doing something bad.  A good detection point will have a near-zero false positive rate.

Q: I've always referred to frameworks like this as traffic and/or application policing strategies. As you inspect traffic or data, you dynamically detect malicious behavior and deny applicable end points/attackers.
A: Yes, that is basically the idea here.  AppSensor just helps people implement this idea by providing the types of traffic/attacks that they should be looking for. Also, we are working to provide the code via ESAPI.

Q: How well would the AppSensor integrate with web sites created with Lotus Domino or SAP's web interface?
A: There's no reason AppSensor couldn't work in any web application provided you have the ability to modify the source code.

Q: After a while the attacker will know the pattern that you are checking for .. thus they might get brighter as well. First question - how do we hold pace with the attacker's learning curve. Second question - how do we know, that our traps are working? Should we ad a monitoring interface to the traps themselves that we use to generate test trapping responses?
A: The attackers may get smarter, but odds are you are already facing very smart attackers. You don't really need to worry about an attacker learning about the detection points if you ultimately lock out the malicious user's account anyway. However, if account creation is not controlled then there is the potential that the attacker could just create another account and continue probing. But, the attacker would have to be very interested in your site to recreate a new account after every 3 failed attack attempts.
When building the detection points (traps) you should definitely test each one of them prior to production deployment. You'll be testing that the detection point properly captures the particular attack it was designed for.

Q: We should not generate a warning message for the attacker but stay silent and chase him. (Referring to the option to send a message back to the user when the detection point fires).
A: This is totally up to you as the application owner.  Some applications may wish to display a warning message to the user while other apps will remain quite as you indicated.

Q: We should enable the traps (detection points) after we have done our own penetration testing and test the traps?
A: Yes, definitely test the detection points to ensure they are working correctly. Its also worthwhile to observe how the detection points fire during a penetration test.  This might also lead you to new detection points that need to be implemented.

Q: Have you thought about a standardized central monitoring device that these trapped application can interface with?
A: Yes, you could format your log message and then use centralized monitoring via ArcSight, QRadar or any other Security Information and Event Manager.


Hope this helps. Please post any other questions.



-Michael Coates

Online Presentation - Thursday - Automated Application Defenses to Thwart Advanced Attackers

Watch my online presentation provided by BrightTalk in the embedded player below.

Topic: OWASP AppSensor & Automated Application Defenses to Thwart Advanced Attackers

When: Thursday, June 3 12pm Eastern / 9am Pacific

Where: Watch via this link or the embedded player below.  




-Michael Coates