Following the White Rabbit Blog : process

Defining Security as a Business Requirement

RafalLos — Thu, 05 Feb 2009 04:53:00 GMT

This post is a follow-up to the previous one on QA: Defect vs. Vulnerability. All the highly-intelligent responses I received got me thinking further, and so here I present my additional thoughts.

This may not be revolutionary - but given the response I received regarding the terminology difference between defect and vulnerability I think the only logical conclusion we can reach is that if security is not a foundational business requirement, we're sunk.

To expand on this point a little more I think it's important to follow non-technical critical-thinking here. Anything that does not make it into the functional specification of an application [web or otherwise] is an afterthought. It has been conclusively [and repeatedly] proven that anything that is not "baked in" as a requirement is nearly impossible to fix later on, as an after-thought. So we're presented with a puzzler. Security must be a business-level requirement. So how then does one translate vulnerabilities into a business requirement, sanely? Simply stating "... the application shall be free of unintended design flaws and security vulnerabilities" is like asking an architect to build a structure that will withstand every known (and unknown) possible attack - it's simply illogical.

Strangely, program leads that manage these large-scale web applications at the heart of nearly every major breach want concise, identified things to not put into the code... but since that list is a moving target the security team gets penalized for the nature of security itself. This is the reason why black-listing input is a losing proposition... you're always going to be in an arms race with the bad guys... and you'll never win.

I've heard some recent conversations hit the wire around using the CWE Top 25 or some other list as a definitive list of coding errors to avoid in web applications but I'm not sure if that will actually solve the problem. The problem with this approach is and will be that these lists are exclusionary measures. These lists illustrate what we must exclude to be [more] secure. Turning it around and making statements like validate all input makes little more sense, especially given that input validation must be defined in the context of the situation, and there is never a one-size-fits-all answer. To illustrate the point further - input validation may mean excluding certain character sets/patterns and pre-defining acceptable input options ... but this does not account for things like free-form input or other use-case specific examples.

In the end, the crux of the problem lies in the nature of security vulnerabilities. Security vulnerabilities are a moving target and although they can be loosely defined and lumpted into Top 7/10/25 lists it is not logical to consider these lists complete or even functional for designing software. Will a web application be secure if it follows the CWE Top 25 and addresses those issues? What about the OWASP Top 10? I don't think anyone has that answer, or at least is willing to stake their reputation on it.

So back to defining security as a business-level requirement... can it be done? Can one clearly articulate requirements to secure data/transactions/processes/whatever *before* the technologists get involved; meaning, before the means to execution are defined? I will leave that up for debate.

Misunderstanding the Purpose of Automated Tools

RafalLos — Wed, 11 Jun 2008 02:29:00 GMT

Let's get this out in the open - there is a misunderstood purpose of automated tools in web application security. Based on my personal experiences in front of both management and engineering teams in the last few months, I feel this needs to be addressed, and addressed now.

I know that as a vendor of tools, we would like everyone to use our wares to find and mitigate their web application security vulnerabilities - but no one here is dilusional. No one here in the HP ASC will ever tell you that buying/implementing our tools will give you total security for your web applications. No one here will ever advocate our tools as the sole solution to an enterprise web application security strategy.

So why do other vendors do it? More to the point - why is it that I am often asked the question... "So can you tell me if we implement (the HP ASC Security Suite, or some subset thereof) we will have secure web applications?" Still scarrier - why do people get upset at me when I answer them with a stout "No... our tools are but one part of a holistic strategy". Before you think that this can't possibly be anyone you know, or any manager you work for... think again. The list of places and teams that have posed this question starts in government, leads to the education sector and trails into large enterprises just the same.

I know there is some level of education that has to happen, and to some degree vendors are to blame for trying to sell "Magic Bullet" solutions at times to make the sale but the reality is no one piece of software will fix your web security woes holistically. Let me elaborate, and explain my case.

First, tools are just one piece of the security pyramid (People - Process - Tools). I've had that slide in my presentations as far back as I can remember presenting, and it's served me well but I do think it's time to preach that a little more emphatically. People and Process are the other two key factors to a successful web-app-sec strategy - without them the tools are of very little use. It's like having a 500Hp sports car with a nice manual gearbox and not being able to drive a manual and having no gas in the tank. Building a successful practice takes all 3 pieces of the pyramid to be well-established in order to function. While the *people* are the foundation of the whole pyramid, the processes and tools keep the pyramid from collapsing on itself. Without the other 2, no one piece can stand alone...

I'm writing a piece on the P-P-T (People/Process/Tools), but in the mean time ... this should give you something to think about. Let's just be clear one more time... no "tools" can solve the web application security problem holistically... but I will continue to argue that HP's ASC Suite provides the most comprehensive, most complete lifecycle solution out there, bar-none.

Overcomplicating the developer-security relationship

RafalLos — Thu, 05 Jun 2008 20:39:00 GMT

Greetings readers. As I travel and meet with large enterprise customers of HP's I've learned something new that I wanted to share. Maybe it's only obvious to me, and maybe I'm behind the times - but it appears to me that we (and by "we" I mean us security folks) have vastly over-complicated our relationship with developers. Shame on us.

If you don't agree with me, read on. If you already agree, simply nod your head and move on, as I'll be preaching to the choir.

My point is that as the IT Security function we have entirely forgotten what makes a good security process work - simplicity and adoption. We've made our proceses so hard to follow that our adoption rates are abismal and yet we wonder why our application security programs are failing.

Without telling you what tools you should be using (so I don't sound like a sales pitch) here are the things that work more than they fail...

K.I.S.S. - Keep It Simple Security! Why do things need to be complicated to be powerful & effective?

Model your process around the target audience - find out how your developers work and make sure the tools you recommend are inline with that function. If your developers do weekly builds but write code all day long ask yourself if it makes sense to "security check" that code at build time, or from within the IDE as they write it?
Check --> Understand --> Remediate - Your process must be this simple. The security check must be ultra-simple to execute, it must give developers the ability to understand what is wrong (watch the false positives!) and it must provide them with immediate feedback on how to remedy the situation

Use the carrot, not the stick - Forcing people to use something makes you a tyrant; helping them succeed makes you a trusted advisor

Gather metrics
Use metrics to reward those developers who are getting better
Public floggings are a great way to make sure people are too afraid of the results to use your process

Avoid work duplication

Developers love shortcuts; quite simply - help your developers do something right once and then re-use that process/module for the future
Allow others to learn from the lessons of the one.

Just some thoughts... don't take my word for it though. Sit down with your developers. Ask them what would make "security" work for them and you'll hear many of the above things said!

Good luck.