Security is Hard: Part 1

Situation:  New website needed for Acme Corporation. The business team has decided we need more widget sales. The web team has promised more sales if they can host a new web application on some new hardware. <Sarcasm>Lucky for me, a security architect is required on all new project designs.</sarcasm> Walking into the first design meeting is like entering the House of Commons…  It’ll be a day full of insults and yelling before anything gets done.  

This situation repeats.. over and over and over and over. Such is the life of a security monkey.

 

Security is hard. The happy monkey in me says “If it was easy, it wouldn’t be worth doing”…

 

http://drawception.com/pub/panels/2012/4-10/W8L3Yt66hM-2.png

 

 

 

 

 

 

 

which is quickly followed by rage monkey.

His comments are not quite appropriate for official tech tips.

 

In the interest of all of our sanity, I want to take this small bit of web space and talk about what goes through a security geeks mind when we are designing and securing an application.

 

Questions!

Every design, review, looksie, etc all starts with questions. If the application team has the answers, it helps the entire process. I try to keep my question list a reasonable size.  I like to have a morning meeting, bring donuts and ask:

-What is the purpose of the app/site/widget?  (Sales, forums, chat, information, games, video, media, etc)

-Is it publically accessible?

-Will people be logging in?

-Will there be any privileged data?

and the killer:

-Take me through a user on the site.    

I like to use the mental exercise to find as many nooks and crannies of the application. If the application team says “The user logs in”, I dig to find out how they log in, where the auth comes from, who, how, why, when, etc.  This one question can take hours,  so I recommend a big whiteboard and coffee.

 

Mapping

I’m a visual monkey. So after all the talking, I take every ounce of data we talked about, and map it out. This brings up a really big point. A good security monkey documents… everything.  Each ape has his/her own way of documenting. Some stick with a collection of text docs, others pull in some form of project management software and go all out.

With all the data I can get my paws on, I start to map out how the data logically flows, where the servers sit, and identifying all the ingress/egress points I can identify.

It can start modestly or go right into deep visio work. I like drawing, so the whiteboard is my friend.

SecureIT

Now the fun begins. The monkey wheels start churning.  We know (as best we can) of what we need to defend. For the mental fun here, I’ll stick with F5 gear (cause I can ).  

So, if that’s the logical flow, we’ve got a pretty straightforward path set to think about. (assuming this information is full and correct)

Immediate Defense Thoughts(not comprehensive):

DDoS

Business Logic Attacks

Application Level Attacks

On the Paths:

1. User into Application and back

2. Application calls to internal network for Files and Database

3. Application calls to external bob.com

 

In the never ending pursuit for simplicity in design and management, I am going to use my F5 as a central workhorse. They are a thousand ways (and more) to do this, and a thousands reasons for each method. My big question/concern/consideration that I always ponder is how much risk is acceptable to the application. This is a question that should back to the application owners. I like to give the rough numbers and try to explain that the numbers are not a guarantee. 

“With X number of hours, we can achieve Y level of risk  (use the standard Cost benefit analysis, or whatever measurement the company likes to use)”

Let me pose a question:

How can I, using just one HA pair of F5 devices, get a stable, secure, and fast implementation for this site?

 

If you think you have the best solution,  put it in a comment below! Have no idea? Well, you’ll have to wait for the next segment of “Security is Hard” .

 
 
Published Aug 08, 2012
Version 1.0
adn
news
security
tech tip

Was this article helpful?

2 Comments

Sort By
  • Michael_Skreeno's avatar
    Michael_Skreeno
    Icon for Employee rankEmployee
    Aug 09, 2012
    Good article! I like the way you start with high level open ended questions and drill down to each function of the environment. Clearly breaking down the way each tier of components will interact and considering the total possible attack surface is key when defending an environment.

     

     

    One of the fastest ways I know of to get the results with one HA pair of devices is to configure it with Local Traffic Manager (LTM) and Application Security Manager (ASM). With BIG-IP's default deny behavior you can limit all of your layer 3 and 4 attack surface to the appropriate virtual servers and ports. With the application level awareness of BIG-IP you can parse and perform the deep packet inspection needed.

     

     

    With LTM's features alone you can start to ensure traffic constrains to expected patterns. With the HTTP profile you can limit HTTP request header size, header count, encrypt session cookies, and more. iRules are also another powerful tool for mitigation of risk since you can build white and blacklists of IPs, URIs, and a number of other things.

     

     

    Add ASM into the mix and you can really raise the bar. ASM has the ability to build a policy which includes both positive and negative security models plus the anomaly detection for your DDoS attacks. Policies can be built automatically or manually with a variety of templates. The policy configuration can be very broad or very specific based on the desired risk mitigation. ASM also integrates with a variety of vulnerability assessment tool output that you can use to create AND further build a policy.

     

     

    Nice job staying grounded in reality with security since with any configuration there will be the "With X number of hours, we can achieve Y level of risk" or risk mitigation (negative or positive security :) ).

     

     

    Keep up the good work!