Following the White Rabbit Blog : QA

Quality Engineers & Testers - StarWest is Coming Up!

RafalLos — Thu, 02 Jul 2009 20:45:00 GMT

I'm thrilled to announce that I have been selected to speak at the StarWest 2009 Quality Conference (SQE) October 5-9th 2009, hosted at the DisneyLand Hotel in Annaheim, CA! Link to the conference website is here (http://www.sqe.com/starwest/Schedule/Default.aspx) and there are a number of awesome speakers as well!

The StarEast conference was chock-full of great speakers, vendors and of course yours-truly... speaking on Security topics and why the quality assurance teams are so crucial to the web application security process. That's right, I've been talking about Q/A engineering and testing teams and why they're so crucial to the success of any enterprise web application security program - but now for the first time you'll get the truth that the IT Security guys probably won't tell you - YOU are the key! My talk on this topic promises to be riveting and will certainly have an impact on formal testing and security organizations...

As an added bonus - if you sign up you'll get money OFF the price of your admission!

Normal 0 false false false EN-US X-NONE X-NONE

Register using special promo code SKWS and save up to $300! Register by September 4^th to add the Early Bird Discount for up to $600 in total savings! Call the client support group at 888.268.8770 or register online at: https://www.sqe.com/starwest/Register/SelectConference.aspx

I'll see you all there!

The Pros of a Con

RafalLos — Thu, 07 May 2009 18:22:00 GMT

My slides are now available for you to revisit (if you would like a copy for yourself, email me), here at SlideShare.net

Most of you already know how much I love to stand in front of fresh set of faces to deliver the message of web application security. Every once in a while I get the rare pleasure of venturing out of my element (the "security" audience) and talking to an audience that doesn't actually have any vested interest in security... yet. This past couple of days spent with QA engineers and software testers at StarEast has been absolutely priceless. I can't tell you how much joy it brings me to see the light bulbs go on as you slowly make the transition to knowing and understanding what should make you lose sleep - that security is everyone's problem.

The audiences that came out to the "Hacking Flash" talk, as well as the "Building Practical Test Cases..." talk were wonderfully interactive and really game me faith in the fact that the message is reading more and more of the right folks. I know I mentioned at least a few times that the QA teams are the key to security's success, and I'll further explain for everyone else why that's the case in a later post - but know it's absolutely, 100%, no-bs truth.

When you get back to your jobs stop by your security team's desks and tell them that you are the secret step in a successful security strategy and program. Take a snapshot of their reaction. Remember, there is generall a 10:1 ration of QA to security staff... and your effectiveness is measured in the depth of cooperation with your security teams in decreasing your enterprise's risk on the web.

Given all that, I want to post some follow-up stories. I would like to get some brave souls to reply to me (either privately or here as a comment) with how you've taken this information back to your organization and utilized it for the company's greater good. What kinds of reactions have you gotten? Please let me know and I would love to have you guest-blog either semi-anonymously, or identifying yourself if you'd like!

Thanks again! Good luck out there.

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.

QA Lesson - Defect vs. Vulnerability

RafalLos — Tue, 03 Feb 2009 20:34:00 GMT

Back in April 2008 one of my very first posts to this blog was titled "Security Vulnerability != Defect; Why?" and it stirred some discussion. Over the past year I've spoken to more QA teams than I can probably remember, and the message has been carried through - but a recent article by Robert Auger at CGI Security gave me a mental nudge and got me to think this through again. As I sat and wrote a reply to Robert's article, I was once again reminded of the example I use; I will share it here for everyone's comment.

Consider the following example of defect versus vulnerability usage... and perhaps you'll be able to use it in your next discussion.

The context for this is a conversation I had with the an IT leader at a very large auto manufacturer, sitting around a conference room table just after I had presented to them some security concepts and why security testing was a critical component to their organization. After I was done, the IT Lead in the room (who won't be named here) looked at me and shook his head. Curious, I couldn't help myself but to ask why he was spending so much money on quality-assurance, but not a penny on security; more importantly why I had not convinced him to spend security dollars. This was his answer, and I think this perfectly illustrates my point, and why I now use defect instead of vulnerability when speaking to QA groups.

paraphrasing... "Vulnerabilities and defects are not the same thing, in fact, vulnerabilities aren't, in my opinion, anywhere near as important as quality defects. In this industry, a defect is illustrated by a brake pedal that goes to the floor as your brakes fail when you mash them to stop in case of an emergency. The brake failure is a defect which can lead to the loss of human life. Defects are taken very seriously, and we do everything we can to avoid them. A vulnerability is much different. A vulnerability is likened to a car that is not theft-resilient. A thief being able to easily break into the car, hot-wire it bypassing the starter-kill mechanisms (obviously without the keys) and drive away is a vulnerability. Which do you suppose you would focus on if you were faced with both in front of you?"

That struck me, and stuck with me. While this IT Lead's analogy was spot-on for the automobile industry... unfortunately it didn't quite hold for the software development organization. A defect was, in most cases, arguably not quite as critical as s security vulnerability - but neither will likely cause a loss of life (one would hope). Anyway... I thought I would share this story so that the next time you're talking QA... remember to use the correct terminology... it makes the point that much more... understandable.