Thursday, March 26, 2009

Website security needs a strategy

Someone begins watching a basketball game and asks who is winning. You might helpfully answer, “Lakers up 76 to 64.” Imagine if instead you said, “The Lakers are 60% from the field, have 12 rebounds, are 8 of 10 from the line, and the average height of the starting lineup is 6’7.” Sure, these are important statistics, but they certainly do not answer the question. (Inspired by Richard Bejtlich) The person listening would probably think you were trying to be funny, a jerk, or perhaps both. Yet, this is how the Web security industry responds when businesses ask about the security of their websites. “We identified 21 security defects including eight Cross-Site Scripting and four SQL Injection, we are improving our SDL processes, and most of our programmers have been through security training.” Again, important metrics, but still not answering the most important question -- how well defended is a website from getting hacked.

The Web security industry supposedly advocates a strategy based upon risk reduction, but predominately practices defect reduction as the measuring stick. This is NOT the same and provides no assurance that a website is more secure against an attack of certain capability. Then in the next breath, as Pete Lindstrom points out, we ironically consider those with the most identified/patched vulnerabilities as the least secure. Simultaneously the community engages in endless ideological debates about black box testing versus source code reviews, the value of SDL pitted against Web Application Firewalls, certification as opposed to field experience, and vast collections of “best-practices” suggested as appropriate for everyone in every case. Confusion and frustration is a reader’s takeaway. It must be understood that each component can be seen as a piece of the puzzle, if only done so without losing sight of the bigger picture -- which is...

How to conduct e-commerce securely and remain consistent with business goals

To be successful companies need a plan -- a common sense approach to building an enterprise risk-based strategy. A system enabling solutions to be implemented in the time and place that maximizes return, demonstrates success, and by extension justifies the investment to the business in the language they understand. A strategy that perhaps begins by addressing the most common question, “Where do I start?” One simple answer is to locate, value, and prioritize an organization’s websites. Go further by assisting the business units in understanding the relevant issues such as “What do we really need to be concerned about first?” Describe the most likely threats (attackers), their capabilities, motives and which vulnerability classes are most likely to be targeted. Only when you know what you own, how much it’s worth, and what attack types must be defended against, according to business objectives, can security be applied in a risk-based fashion.

The problem CIOs and CSOs are facing is that the pseudo Web security standards available are completely inadequate for accomplishing the task. I am not the first to have called out this need. This is what Arian Evans has been talking at length about. As have Rafal Los, Ryan Barnett, Boaz Gelbord, Michael Dahn, Rich Mogull / Adrian Lane, Wade Woolwine, Nick Coblenz, Richard Bejtlich, Gunnar Peterson and likely many others. Many of the building blocks necessary for building a standard are scattered around the Internet including secure software programs, testing guides, and top X lists. These tactical documents could potentially be leveraged into a higher-level framework and serve as the basis for a mature risk-based enterprise website security strategy. The OCTAVE Method, FAIR, ISO 27001/2, among others, also contain well thought out and accepted concepts which we could use as a model.

It is imperative now more than ever that such a resource exists to satisfy a clearly unfulfilled need. CIOs and CSOs know there is a Web security problem. Now they seek guidance in how to develop a program that is flexible enough to meet their individual needs, which can also demonstrate success in manageable increments. I’ve been in contact with several industry thought leaders and enterprise security managers who have expressed personal interest, even excitement, in building out such a system. It is time to start helping ourselves answer the question, “Who is winning the game?”

I feel very strongly about the importance of this effort and I'll be dedicating personal time to see the idea go forward. To move ahead quickly, the Web Application Security Consortium (WASC) and The SANS Institute are planning to initiating a joint open community project (to be named later). If you would like to get involved, please stay tuned for more details.

Thursday, March 19, 2009

Quick Wins and Web Application Security

Lately I’ve been asking peers why they think comparably few dollars are spent addressing Web application security (by percentage to host/network), which every industry report states represents the largest information security risk. Is the reason that organizations don’t “get it”? Are available solutions ineffective? Do compliance failures need more teeth? Does the market need more time to mature? The answer is crucial, because without funds there is no way to secure the vast majority of insecure websites and we all suffer as a result. A combination of factors is probably a fair estimation, but the more I dig in the more I’m convinced something more powerful and yet mundane hides just beneath the surface. A recent conversation with Joseph Feiman (Gartner) revealed a profound insight. To paraphrase:

During an event a panel of Gartner Analysts asked the audience what the best way is for organization to invest $1 million dollars in effort to reduce risk. The choices were Network, Host, or Application security to which the Gartner analysts made their cases for these three disciplines. The catch was the budget could not be shared between them and must be prioritized into a single initiative. The audience selected Application security. However, the Gartner CSO (who took the role of CIO in the play) overruled the audiences' decision. They instead selected Network security, while at the same time curiously agreeing that Application security would have been the better path. His rational was that that it is easier for him to show results to his CEO if he invests in the Network.

Think about that!

Consider for a moment that Website Security equals Software Security, which it does plus much more. Then a maturing program will often require fundamental changes in business and code development processes. Policies need to be established, developers trained, staff hired, technology acquired, etc. An uphill battle requiring tremendous resources over the course of multiple years with scars and lessons earned along the way. As an example, the Building Security In Maturity Model (BSIMM), a real-world set of software security comparisons, observes 110 different potential activities! At the same time, measuring the value obtained from defect reduction in terms of website risk mitigation is extremely difficult. This is not to say the evolution should not begin, but it’s vital to understand the personal incentives that influence decision making.

A CIOs (and CSO) average tenure at a company is roughly 4 years, so they may view a multi-year website/software security program with immeasurable returns as a risky career move. And rightly so! If the effort takes too long and the business loses patience their credibility suffers. It is much safer to maintain the status quo spending on firewalls, A/V, network scans, and patch management where metrics are easier to quantify, report, and justify. Still, I believe CIOs want to do the right thing if enabled. So I asked my some 900+ Twitter followers (@jeremiahg) for ideas on how one might achieve “quick wins” in Web Application Security with measurable results that CIOs would appreciate. Several good ideas arose, mostly about reporting blocked attacks tied to defense measures, and interestingly not a single one mentioned the Software Development Life-cycle (SDL). I asked why, to which Chris Eng (@chriseng) of Veracode responded, “That's because SDL isn't quick.” It then becomes crystal clear why justifying a proactive budget is difficult to say the least. If we, the experts, don’t know, how can we expect CIOs to do any better?!

What happens when a website gets hacked you ask?

Simple. Risk transference and/or mitigation, but not necessarily reduction. Dollars free up shortly after an incident, but only enough to make the immediate problem go away, quickly, and usually only temporarily. Unfortunately that doesn’t necessarily translate to a lasting software security program. A CIO may first act by terminating the programmer or third-party development shop that authored the code. There is also the option of decommissioning the website entirely; replacing it with an outsourced Software-as-a-Service provider; or bring it in-house to manage internally. A Web Application Firewall could be deployed and a network scanning vendor commissioned to apply the rubber stamp assurance to show anyone asking. The point is, a CIO is compelled to demonstrate a level of success in short order and report why the same incident won’t happen again. They are caught in a position forcing them to react tactically rather than strategically.

Seriously, what other real choice does a CIO or IT Security have!? Getting hacked again and again while implementing an expensive mega software security program whose results lie years away is not particularly attractive or practical. Something needs to happen immediately. This is a big reason why accurate vulnerability assessment results piped into Web Application Firewalls (VA+WAF) has become such an attractive option. A solution capable of identifying vulnerabilities, virtually patching them, and demonstrating success to the business -- in terms of risk reduction. Quick wins are possible in a matter of days or weeks, rather than years. A similar option is desperately needed from the software development side of Web application security field. A program that produces measurable results quickly that can be built upon even after the CIO leaves. A win-win for all involved. If such a model exists, it’s not well advertised.

The only other major budgetary lever is compliance where justification occurs without consideration of or a requirement for risk reduction, “We need money to do X because the standard says so.” For myself, and I think many others too, that is just not good enough. Lest we forget, compliance != security. So I’m asking again...How do you achieve quick wins in Web Application Security, rooted in software, with measurable results that CIOs would appreciate?

Detecting Private Browsing Mode

I shared the original concept with Collin Jackson who developed the proof-of-concept code. The basic idea is one might want know if a Web user is in the Private Browsing mode in Safari and Firefox, the Incognito mode in Google Chrome, or the InPrivate mode for Internet Explorer 8. The way it works is by having someone visit a unique (never before seen) URL and then checking to see whether a link to that URL is treated as visited by CSS (standard color history hack). And if they haven't, then you know some privacy feature is actively blocking.

Definitely not anything super serious, but worth putting out there in case someone might have further ideas.

Monday, March 16, 2009

Web Security Readers Digest

Over the last two weeks I visited 5 different cities across the U.S. As such I haven't had much time to blog, however did get a chance to get in some reading. Plane rides are good for that. There is a tremendous amount going on in Web security, far more than I could ever dig deeply enough into and blog adequately. So here is the abridged version of the things I found particularly interesting, in no particular order.

1) Robert Auger published “Socket Capable Browser Plugins Result In Transparent Proxy Abuse”, which appears to be a solid candidate 2009’s Top Web Hacking Techniques. Yet more Intranet hacking goodness, but this time with a CERT VU#435052. Serious style points.

"When certain transparent proxy architectures are in use an attacker can achieve a partial Same Origin Policy Bypass resulting in access to any host reachable by the proxy via the use of client plug-in technologies (such as Flash, Applets, etc) with socket capabilities."

2) The software security gods give unto the people a Building Security In Maturity Model (BSIMM). Nine world-class software security initiatives were studied that include Brad Arkin (Adobe), Eric Baize (EMC), Alex Gantman (QUALCOMM), Eric Grosse (Google), David Hahn (Wells Fargo), Steve Lipner (Microsoft), and Jim Routh (DTCC). Want to get some insight into the what the big boys are doing interally? This is the best way to compare your program to theirs.

3) Yes, Software-as-a-Service is all the rage. Yes, Software-as-a-Service in many cases is more superior and less expensive than enterprise software. Yes, as Software-as-a-Service vendor specliazing in Website vulnerability assessments, I'm more than biased. The things I like about Software-as-a-Service best though can be summarized by the following comment...

"In the traditional software sales model, the idea is to impress the customer in the beginning, make the sale and collect the big check. While the customer is certainly valued, this is really a model that benefits the software company. Conversely, SaaS is a recurring revenue model where vendors gain maximum value by retaining customers over the long term."

That is precisely how we approach our business and why our renewal rates are sky high. It is in our best interest to make sure customers are well taken care of. Coversely if you buy some security software brand X, then basically you are on your own.

4) Penetration testing is dead, long live penetration testing, and here I thought Brian Chess (Fortify Software) was calling for the death of my business. :) Brian does a good job refining comments he made earlier about how pen-testing must adapt or die.

"People are now spending more money on getting code right in the first place than they are on proving it's wrong. However, this doesn't signal the end of the road for penetration testing, nor should it, but it does change things."

This is hard to disagree with and he even takes time to share some nice words about us...

"If you'd like a sneak preview of what the future holds, check out the work White Hat Security has done to integrate their vulnerability measurement service with Web application firewalls. This is attack and defence working together in a creative new way."

5) Rich Mogull and Adrian Lane of Securosis release a monster! Building a Web Application Security Program. Amazing that is has taken this long for the Web security industry to produce a document of this kind and quality. If you a plan in place, don't know where to begin, or find the generic "sofware security" guidance just isn't going to get it done for your enterprise, this document is the one for you.

6) Isn't it fun the run a social network? Religious wars erupt on Facebook, in this case, it involves some Web Hacking. “A group named 'Christians on Facebook' has been taken over it seems by pro-Islam members.” Reminds me of the days back at Yahoo!

7) This quote by Pete Lindstrom I found particularly thought provoking...
“If finding vulnerabilities makes software more secure, why do we assert that software with the highest vulnerability count is less secure (than, e.g., a competitor)?”

8) Criminal uses Google Earth to perform reconn searching lead roof tiles, which he would steal and sell to scrap metal dealers.

9) If you care about such things, you already know about it and its old news. Heartland, RBS WorldPay no longer PCI compliant.

10) Software tools do NOT scale! Neil MacDonald of Garnet was in this case talking about static application security testing (SAST) tools, A tool alone cannot solve what fundamentally is a development process problem. Can I get an AMEN! The very same issue plaguing dynamic testing tools I blogged on a while back. Technology helps, but people matter most.