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.

photo

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 Smile with tongue out).  

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” .