Following the White Rabbit Blog : web application security

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!

Raising the Bar? Flash Encryption, Obfuscation

RafalLos — Mon, 20 Apr 2009 17:37:00 GMT

On the heels of my OWASP talk regarding decompiling and analyzing Flash [see SWFScan link] files lots of you have asked "So what about Flash file encryption or obfuscation? Does that make my code any more secure?" I've done the research and talked to experts (including our very own Billy Hoffman) - and have a blog post just for those of you starving for this information.

There are a lot of Flash file obfuscators/encryptors out there... all of them hoping to raise the bar for attackers against your client-side Flash code. I'd like to make sure I properly set the background for you here - everything you'll read about is happening on the client side within the user's browser framework, meaning, it's running in potentially hostile territory.

Now let's move on and take a look at some of the ideas we're addressing. First when-ever you're discussing client-run code you have to understand that whether it's encryption, obfuscation, or magic you have one major problem: the client has to know how to un-do the magic. When the Flash! file comes to your client it has to be interpreted by the Flash! player, right? In order for it to do that it has to be readable and understandable by the Flash! player. Think about that. If the code is sent encrypted, say using some strong AES-256 encryption technology, then the player is unable to render it thus creating a quite secure, but completely unusable "blob". In order for the code to be worth anything to the client it has to be de-crypted (or obfuscated). For that to happen you have to have the routine to decrypt | de-obfuscate the blob located within that blob, likely as a pre-cursor to the whole piece of code. You should already see a huge gaping hole here. Here's what this all looks like in terms of process from developer's workstation to client player:

Developer writes some [potentially bad] ActionScript code
Developer "obfuscates | encrypts" the code
User hits page, downloads embedded "blob"
User starts to execute Flash! file
Decryption|De-obfuscation routine runs, produces valid (unprotected) Flash!
Flash! player executes code, movie runs

Immediately, in the above step-by-step you'll notice that step 5 the decryption|de-obfuscation routine has to run on the client to unprotect the SWF file. This essentially breaks down to mean that the deobfuscation|decryption code has to exist on the client, within the protected SWF file. Ask yourself what sort of security that buys you, if you're including the unprotect routine with the protected code.

After wading through many different SWF encryption|obfuscation tools I've come to realize that they're selling to folks who simply don't understand the full scope of the problem. Here is an interesting quote from one vendor's marketing material. I'm not identifying the vendor... mostly to protect them from the questions you would have about their effectiveness.

"PRODUCT X uses Advanced Obfuscation Techniques along side proven Encryption Technology to provide security and protection for your Adobe Flash® SWF Files. Put simply, PRODUCT X prevents other people from decompiling or reverse engineering your SWF movie and stealing the ActionScript Code." How can a vendor make a statement like that, consciously, knowing full-well that this is just like the obfuscation techniques that are being used on JavaScript right now... their effectiveness is only marginal to the determined attacker. You have to continue to put these types of technologies into context because if you're looking at "encrypted content" you'd think that it's secured, much like an "encrypted database" is secured from someone who steals it... until you realize the main difference is that generally the decryption routine is not included with the database but as a separate process. This is the main difference. Since Flash! player has no internal mechanism to decrypt|de-obfuscate flash files the work falls to the application itself, meaning it has to be included into the code blob.

The verdict? If you're depending on a code obfuscation|encryption tool to protect your Flash! files, you should probably re-think your strategy. First ask yourself why you're hoping to hide the client-side code. Intent here is key... because while the tools you're using may temporarily deter a simple Flash decompiler, in the long-run it will not protect your code. As Billy Hoffman notes "Client-code obfuscation|encryption is much like WAF (Web Application Firewall) technology, it's a temporary fix meant to increase the "time to hack" while not providing anything permanent." Including sensitive information on a client-side code blob is never a good idea. This should be self-evident but apparently there is a significant market for Flash! obfuscation|encryption tools so maybe I'm wrong. Here are a few pointers for those of you thinking about writing sensitive client-side Flash! apps...

Never put sensitive information on a client (passwords, 'hidden" URLs, validation routines, encryption routines, etc)
Understand that anything on a client can be compromised because you no longer have control
Any encryption|obfuscation of client-side code has to be un-done in order for the framework to process it... thus only providing marginal security improvement

When all is said and done, to quote Billy Hoffman "It's like boxing a 7 year-old... you're going to win it's just a matter of how hard do you want to try". --Thanks to Billy Hoffman of HP’s Web Security Research Group for his contribution to this blog, and his ongoing effort to protect developers from their own worst enemy... themselves.

Enterprise Web Application Security: Part 1 - The Foundation

RafalLos — Fri, 20 Feb 2009 15:10:00 GMT

The term "Enterprise Web Application Security Program" has been evolving. Generally referring to a corporate IT program which includes web application code in some way and has traditionally meant either a white-box approach or a black-box approach, either through the use of tools or the use of a 3rd party for the assessment.

No matter how you look at it, that's all completely wrong.

First off the thought that a "security program" would begin with code is a failure to launch, in my experience. Web application security deals so much more with non-code items than we'd like to believe, but rarely address. These topics include hosting, server hardening, user-management, and a few others I'm forgetting now. The point is before you can bulid a strong web application security program that withstands not only economic cycles but business trends you have to understand what it is you're building. Much like a home, you can't change plans after the foundation has been laid...or else you will fail.

There are some fundamental components you must consider before you start to lay the foundation for your Enterprise Web Application Security Program... here are some of the most important ones that have to be addressed from day one...

Intended purpose - In order to solve a problem you must know what that problem is; you must understand what the purpose of the program you're building is going to be in business terms.
Long-term vision - Define what you see this program evolving into 6, 12, and 18+ months down the road; clearly identifying a long-term goal will assure that you don't start straying in different directions as you progress
Success criteria - There must be a clear definition of how success or failure will be measured; if there is no way to measure failure you will never understand if you've succeeded (or failed) in your goals. Setting realistic success criteria in a concrete context (as opposed to "secure the company's web applications") makes it real to reach those goals and achieve success, while setting milestones helps you focus on making little changes over time that don't happen overnight
Metrics - Setting success criteria and having clear metrics go hand-in-hand when building a framework and foundation for a successful program. Just as you have to have a goal you must be able to measure that goal accurately, at any given point along your path in order to assess your rate of success
Scope - While it may sound rudimentary to say that your program must have scope it is not to be confused with vision or success criteria. Scope can keep your program in-focus and prevent creep into areas you are not equipped to handle. Scope-creep is one of the most widely identified preventatives to success... if the finishline is always moving you will never be able to reach it
Identified starting point - Yes, it's critical to identify where you are starting- this goes back to gathering metrics and measuring success. Very rarely does a program start at "nothing" actually; there is always some degree of movement already - you must quickly identify your starting point so as to build from that point forward

There you have it - there are six (6) identified components to a foundational approach to building an enterprise web application security program. If you're starting to put together a framework for such a program; no matter whether it's due to compliance needs or internal pressures, make sure you understand at least those six pieces. Write them down, remind yourself regularly of their existence.

As master Yoda said - "Do, or do not do, there is no try".

Next time we will address framing that first step of building your program - the policy.

President Obama's Web 2.0 Campaign Hijacked

RafalLos — Wed, 28 Jan 2009 21:00:00 GMT

Congratulations Mr. President, your Web 2.0 campaign to be the "hip" president has just been hijacked. In an interesting news article published originally on CyberInsecure.com, someone has decided to use the President's popularity to hijack his potential, and unsuspecting, users and drump malware on their machines.

I won't go into details, you can read it all here, but the moral is simple... I've been telling you folks that hackers don't just want your databases and credit card data... they want your CLICKS too. The more popular your site is, the harder someone will try and break it (silently) to inject things like adware/malware for their own purposes... which by now should be obvious - make money.

Protect your sites... and your users.

2009 - One Bold Prediction

RafalLos — Sat, 10 Jan 2009 08:36:00 GMT

Well, it's official, we're all another year older now.

Welcome to 2009, and what I can only hope will be a great year in information security.

I'm sure you've all read your share of scary predictions for 2009, from vendors, journalists, bloggers and such so why should I deprive you of my thoughts? Rather than making some obvious statements about what 2009 will bring and linking them to my company's revenue stream in a sneaky way (everyone already does that) I'm going to be outright about it. This isn't going to be rocket science nor will my prediction be revolutionary... but here it is:

One of your web applications will be penetrated in 2009.

That's right, I said it, mark your calendars. One of the many, many web applications or web services platforms will be broken into, and the scary thing is you probably won't even notice. Maybe you'll notice if the attacker messes up and causes you some downtime, but it's more than likely you'll never notice.

What do I recommend you do? It's simple:

Produce a written policy, authorized and endorsed by your top-level management for a web application security program
Educate your developers and staffers on web app development security best-practices
Get tested. Hire an outside party to penetration test your mission-critical applications and services to find your holes
Implement a program based on people, process and tools to help streamline, automate, and integrate security into the SDLC

This isn't rocket science. Good luck out there in 2009, and don't be a statistic.

Thank you ViViT - Madison, WI!

RafalLos — Thu, 04 Dec 2008 17:42:00 GMT

Had a great time presenting, and talking with you all after. I know I painted a gloomy picture, but remember - you can succeed by taking that first step.

Here's some key points:

Don't let anyone tell you that it's all of nothing...
Risk-management is all about mitigating to a point of acceptable risk
Risk is a 1/x curve, where you will eventually hit that law of diminishing returns
Tools and services are not mutually exclusive
Security vulnerabilities should be measured as defects... lest they be misunderstood

..."A journey of a thousand miles must begin with a single step."

A Perspective on "Dumbing Down" the Security Profession

RafalLos — Tue, 02 Dec 2008 04:41:00 GMT

Let me start off by reminding you that the main mission of this blog is to provide insight and perspective (from more than just the security angle) on web application security and risk management. Keep that in mind as you read on...

I read an article on ZDNet tonight as I usually do to catch up on things I've missed - and something caught my attention and my ire. This article by Shyama Rose made me read, and then re-read just to make sure I didn't miss anything in her train of thought. While I have to say she has some very good points (I will name them below individually) she's pointing out something that is inherently biased, I think, from a consultant's point of view. Googling her name, produces this LinkedIn profile which makes her bias more obvious and understandable. This post is *not* about bashing or negating someone else's opinion, I will only seek to point out some obvious (to me) flaws in the thought process.

Let's analyze the article, for content and idea so that I can make some relevant points. I realize that I may have my own bias, working for a vendor of "web application security automation tools", but bear with me and I will do my best to keep my vendor-bias out of this article.

There indeed is a large market "swelling" but it's not just for source code analysis tools

The vendor-space is actually *shrinking* (trust me on this one) due to the smaller boutique vendors ability to compete in a venture-capital starved market and budgets that increasingly go to a single-source vendor of multiple items (software/hardware/services combined)
Source-code-analysis is a small part of the overall security tools market; in fact - I think that while companies seek to purchase "source code analysis" engines they eventually realize the issues with that*, and instead purchase "web application security scanning tools" (such as WebInspect & AMP from HP/ASC... sorry, couldn't resist)
While tools are a hot commodity right now [emphasis on the commodity], there is no shortage of customers for boutique shops doing manual versions of this type of web application security testing (with a nod to my friends in white hats fighting the good fight) - Tools and services are not mutually-exclusive, rather, part of a comprehensive risk-mitigation strategy

The quote "...deficiencies associated with security guarantees that tools promote" is either absolutely inaccurate or we as security automation tools vendors are doing a terrible job selling our products, period.

Yes, automation-based security tools are in their infancy
Yes, automation-based security tools identify ~35% of the total possible attack surface of an application [more on this in a minute]**
Yes, metrics-based management practices are being increasingly used; why? because that is currently the only way to demonstrate effectiveness. I would love to debate the real-world application of security metrics in a qualitative vs. quantitative approach... anyone?
Yes, some of the most sophisticated security tools are partially signature-based... but the best ones are also data-flow and control-flow analyzers; tools by nature cannot "think"... Skynet, anyone?
Yes, most source-code-analysis tools fail on frameworks. Can you blame them? How many Java-based frameworks are there? What about .Net? How about AJAX? (Here's a fascinating read on AJAX frameworks... http://en.wikipedia.org/wiki/List_of_Ajax_frameworks) -this all relates back to maturity of tools vs. development language advances.
Yes, many tools (source-code-analysis or otherwise) base themselves around an assurance or compliance angle (PCI-DSS and others) - but that's because there is a business need for this, and not because they simply like it that way

Another interesting quote "...the differential between a comprehensive security review and the implementation of analysis in analysis tools is massive and harmful"

Massive? Probably not
Harmful? Absolutely not!

OK, so now that I've got that broken down a bit, let me give a sense of why I feel this article is a bit of a hate on the security tools out there today. Anyone who's ever heard me talk, or read my posts/articles/papers would hopefully agree that I have never, ever advocated tools as a replacement for intelligent people. There's no arguing that, there's no replacing intelligent people. Furthermore, tools in themselves are not a solution and won't magically make your code secure. Sales people will often try and sell you snake-oil and magic pixie dust to make your web applications "magically secure" if you use them. That's crap and we all know it.

So why even consider automation-based web application security tools? It's elemantary my dear Watson! Here's just a few reasons why you should be making that purchase sooner rather than later...

Automation - Automation is what makes tools viable. Tools are great at repeating processes and supplementing the human mind to enable it to move faster and have to do less of the mundane (like finding the "easy stuff"); also... testing is generally done off-hours so while humans need time off... machines and tools do not
Expertise - Do you (as a company) have $100k+ per year to spend on a talented web application security resource? Consider that you may need more than one depending on the size of your enterprise and number (and complexity) of your web applications
Metrics - Even though Shyama seems to be against metrics-based risk mitigation, I am thrilled to have tools that can track web application security defects throughout the lifecycle (development -> QA -> production) and show the ROI and risk-reduction metrics in a nice compact dashboard for my CIO
Process - Every good enterprise web application security process (and enterprise security strategy in general) must have some tools component to complement the people and processes... common sense right?

Let me quickly address the points I put a star next to above:

* Source-code-analysis tools are much more difficult to understand, implement, interpret and get use out of than most black-box testing tools. Also, given that the highest risks are to those applications already in production, it makes sense that black-box testing tools (and not source-code-analyzers) are the go-to choice for enterprises struggling with the "what do I do first?" question.

** This ~35% number is debatable, that is, the rough percentage of security defects a tool can find vs a human analysis. On the whole I think it's reasonably correct but people get too caught up in the details of the number and forget the 80/20 rule altogether. 80% (or more!) of hacks happen employing the "simple things" like SQL Injection and XSS... rather than highly-sophisticated complex logic or multi-stage attacks. I don't have any raw data to back that up - but I'd be willing to bet I'm not wrong. If a simple scan from the WASC group showed 85% of sites scanner were vulnerable to attack that would compromise data... that's tools + automation... and that's a scarry number!

I know this is a lot of information to wrap your brain around, and hopefully you won't judge too harshly for my bias (everyone has some bias...) but I hope I've inspired you to think a little before jumping to conclusion that the world of security-source-code-analysis is going to implode because consultants will go out of business due to security automation tools being used more. That's just a silly conclusion. Do companies rely too heavily on tools? Maybe, but what alternatives are we offering given the cost of "manual" testing vs. automation? I will leave you with some simple math. Say for a moment you have 200 web applications in your enterprise. Of those, taking the top 15% (see my Iceberg Principle presentation for more on this) as mission-critical we have 30 web based applications. Given that most of today's web applications are moderately to highly complex, say 100,000+ lines of code we can do some basic math:

Application Security Automation "Suite"... ~$500k - covers all phases of lifecycle and all applications (not just top 15%)
Outsourced Manual Testing - $10,000 - $20,000/application x 30 applications = $300,000 - $600,000... for just 15 applications

... now, factoring in time and efficiency, and given that most business can't afford to just test their super-critical apps... I think the case for security-automation tools is a case of simple math, don't you? (Of course, my numbers are rough SWAGs... do your own research to see what's right for your enterprise).

CSI Annual Conference - Highlights on Web App Security

RafalLos — Wed, 19 Nov 2008 04:00:00 GMT

Listening to the speakers (yes, this time around I was a spectator only... sort of) and the audience from these past 2 days, and specifically at the Web 2.0 Security Summit here at CSI Annual 2008... I've come up with a few things that I think you (the readers who may or may not have attended) should come away with. These are important points, highlights from a very well organized conference geared towards actual solutions rather than the typical smoke, mirrors, and hand-waving [Trey Ford] you may expect from a security conferences. A nod to Robert Richardson for the guest pass, and an excellent conference.

From the experts

Threats continue to escalate and get more clever in their attack
Browsers cannot be trusted, applications can be compromised - this is not a rosy picture
End-user (and business) "push" is needed to help move browser developers to produce more secure browsers
HTML-spec and standards are actually working against security in some cases (see: ClickJacking)
Web applications are, and will continue to be, the prime target for attackers
Few businesses are prepared to drive standardized security throughout their organization
Metrics - good metrics collection and delivery is one of the secrets to making a security program work for you
Process, services, secure coding tools, code analyzers/scanners and Web App Firewalls are not mutually exclusive
Your business must have a short-term tactical fix and long term strategic plan to succeed
Services and tools are maturing at a great rate - and businesses should understand the purpose of each

Tools are a support mechanism for automation, standardization, and repeatability - they do not replace people
Services allow for independent 3rd party verification (satisfying some regulatory and compliance requirements)
Neither of the above will magically "make your applications secure"

SaaS (Software as a Service) for web app security provides immediate ROI, implementation, and won't use up your CapEx (instead uses OpEx) spending
You can't use the Ostrich approach (head in the sand, ignoring what's around you)
Right now, someone is hacking either your applications, your users or both

The bottom line from the experts? The web is more dangerous than the wild-west; and things are going south fast. There is hope.

From the audience

Managers and practitioners alike are confused and disheartened when it comes to security ... specifically web application security
Despite wanting to do the right thing, managers facing insecure (or worse, unknown) web applications are finding it difficult to implement a program
Between integrations, acquisitions, and poor oversight security teams are struggling to keep up with the avalanche of published web apps
Overwhelming numbers of vulnerabilities presents itself in a feeling of "we're powerless, why not just give up" as one person put it...
Managers are confused on where, when, and how to apply tools to web application security programs
Some managers have their hands tied by long-term contracts with outsource developers which do not properly include information security components

When code is finally turned over to them, are faced with checking the security of that code on their own
... that code, if found defective, will then require re-work at their cost!
Ineffective contractual obligations are making it impossible to have an effective security program

Security metrics are typically a problem...

Some companies don't know what metrics to collect
... others collect them and manually try to make sense of them
... still others have intelligent metrics but haven't been able to translate them into actionable items yet
... still haven't figured out how to take raw metrics and model them for upper-management consumption

Security outsourced services are still too confusing
Compliance is causing more headaches than it is solving
Companies are striving to be compliant... but are still terribly insecure - and managers are getting that but feel powerless to change

The bottom line from the audience? Make security simple, actionable, and consumable for my organization... and do more than just sell me tools or services - help me build a program.

There is good news, and bad news.
The good news is that I feel very strongly that we (HP Application Security Center) can help you accomplish your goals.
The bad news is ... it's still going to be your job to sell it to your upper management and execute...

PCI Compliance Madness - See! I'm not insane!

RafalLos — Sat, 25 Oct 2008 05:41:00 GMT

Rich Mogull over at Securosis totally nailed it. This article he put up talking about the Web Application Firewall (although it's still a mis-named product, see my rant here) vs. secure coding is brilliant. I've been saying this since I can remember hearing about "WAFs"... and it's nice to see someone out there that people actually recognize (Rich is an industry heavyweight) echo this sentiment... although the analogy of using Cajuns and gumbo is probably beyond my abilities :)

Still thinking about this as I sat here and re-read the PCI DSS current standard (and supporting documentation)

{PCI DSS}
6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:

Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes

Installing a web-application firewall in front of public-facing web applications

{/PCI DSS}

A few things immediately hit me that I felt the immediate need to comment on, because my mind now thinks in terms of "if I'm a business leader, how do I find loopholes in this...". Here are my thoughts:

I am having an issue with the term public-facing being there. I'd be OK with business-critical or something that indicates the application/site hosts critical data (such as user information, credit card numbers, etc). What if I'm a business and I have 100 "public-facing" sites, but they just all happen to be brochure-ware. Granted I am a card processor. Does it make sense to put non-mission-critical (or containing no critical data) sites through this review process?
"... after any changes" - so if I change the background, or add new legal verbiage I have to re-submit my site to inspection? That makes no sense from a business perspective... does it?
Notice that it says "Review" and not "Review and mitigate any critical issues found within x time-frame"; does this bother anyone else?
The word "either" implies an OR clause here... why does the PCI DSS council see Security Review and added protection as an OR?

As you can guess, I can come up with no less than 5 scenarios where I'm [assuming I'm a business which should be compliant with this policy] going to be horribly security-deficient while still being PCI Compliant. So once again, I'm going to return back to this question and I want everyone to think about this carefully. Would you rather be PCI Compliant, or secure? Further, does compliance equal security?

Web Application Security 101: Simple SQL Injection

RafalLos — Sat, 04 Oct 2008 05:08:00 GMT

Web application security is a hot topic, no doubting that these days. The awareness is growing and developers are starting to take notice of the security shortfalls in their code. Awareness of attacks like SQL injection, cross-site scripting, and CSRF (Cross-Site Request Forgery) is starting to spread and so are ways to protect against these types of attacks.

With this Security 101 post I'd like to call attention to a particular type of attack that (after nearly 5 years of executing it successfully) is finally starting to trend towards extinction - but sadly still is all-too-common. Let's do this by example...

As you visit your favorite site one of the first thing that the server on the other end of your connection does is checks your browser. It does this for an obvious reason: it needs to know whether to serve you java or ActiveX/.Net -based content. This isn't going to go away since I don't see either Microsoft or Mozilla dropping out of the browser game, so the checking of "user-agent" will continue. Moving on in our example, the server pulls the "user-Agent" header component and has to compare it against known types of browsers. Now, there are a number of ways that the server can check your browser version (against an XML file, using JavaScript from within the page, or using a database call) but it is fairly likely that it will be done with a database call to the back-end database server against a table of supported browsers. Here's where the magic happens if you're an attacker. Most of the time, if the developer is making a database call to check browser version compatibility they are *not* sanitizing that parameter before passing it into the database server. This, of course, leads to SQL Injection.

This absolutely fundamental check can cause a site or application with *zero form inputs* to still be vulnerable to SQL Injection. I've seen it first-hand, so I know it exists in "the wild". Absolutely fascinating since I've had developers ask me why they need to sanitize parameters when they have little (or no) form inputs on a site. My answer is always this example.

The moral of this story is don't get over-confident. Just because your site/application is 'basic' or short of complex inputs it does not necessarily mean that you're invulnerable to attacks like SQL Injection. Check and sanitize all your parameters coming from the user-side. Never, ever, under any circumstances trust data coming from the client. This goes for *any* data, including header fields!

Security Program vs. Shrinking Budget - Part 1

RafalLos — Sun, 13 Jul 2008 06:25:00 GMT

Greetings readers, it's been a while since I wrote up an article - but I've been busy I assure you. I've been gathering up information for the series you're about to read over the coming weeks.

As I travel and speak to large enterprises at the starting stages of implementing web application security programs, I've noticed a trend in the types of challenges CISOs and security program leaders face. While the questions are asked slightly differently from place to place, the enterprise profiles are different, the applications are different - everyone is asking the same thing. CISOs and web application security program leaders are desperate to know how they can implement their fledgling programs with little or no budget.

I know, you're reading this thinking - "we have the same exact problem"... and I'd like to say that I have an answer for you. While it's not going to work 100% of the time, and there is still some work for you to do - I do have the answer.

Think of it- what if you could build a program that has the PPT (People, Processes, Tools) you wanted, without any of the budgetary requirements. What if you could do it without putting a single additional penny into your budget?

Stay tuned. I'll show you how.

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.