Sunday, March 09, 2008

Website Security Strategies that Work

Inside an enterprise lives an IT security professional responsible for website security. He takes his job seriously because if his employer’s websites get hacked, he gets the late night call from the boss. A big part of the job requires educating developers on the importance of secure coding and informing the business owners of Web security risks. He does this because no amount of patching or firewalling will fend off an attacker with a browser. While doing everything within his power, there’s still a total lack of control in protecting the websites he’s responsible for. He can’t fix the vulnerabilities in website(s) when they’re found without developer involvement.

Does this situation sound familiar? I hear the frustration all the time. The problem is when a vulnerability is identified by either a pen-tester, developer, outsider or whomever, these are the sole and painful options:

1. Take the website down
2. Revert to an older version of the website/code (if it’s secure)
3. Stay up while exposed.

Nothing is better than not having an issue in the first place, but vulnerabilities will crop up despite the best software development lifecycle. Option #1 is typically reserved for occasions where an incident has occurred and option #2 when a product hot-fix is not back-ported to development, which later gets overwritten. So far history shows the vast majority choose option #3 and assume the risk rather than halt business with fixes coming a ways off.

Clearly we need more options - something that allows the mitigation of vulnerabilities without having an impact on business operations.

This is important because 9 out of 10 (or more) websites have vulnerabilities as a result of being built by those who didn’t know or appreciate the severity of today’s attacks. Furthermore I’d say most of the popular ecommerce websites were built either before the discovery of prevalent vulnerabilities such as XSS, SQL Injection, CSRF, etc. or prior to them becoming common knowledge. Consequently we’re burdened by 15 years of insecure website code already in circulation and it’s extremely unlikely code will be rewritten solely for “security reasons.” Over the coming decade their replacement will occur naturally to achieve business goals while taking advantage of emerging technologies and more secure development frameworks.

That means when you take an honest look at website security there must be two different, but equal, website security strategies:

1) Security throughout the SDLC
2) Vulnerability Assessment + Web Application Firewall

Strategy #1 works best for websites soon to be built or undergoing a major rewrite/addition. A Web security program combining executive buy-in, modern development frameworks, awareness training, and security baked into the design and QA simply does wonders. On the other hand, this strategy is often difficult and expensive to implement on an existing website where no such activity took place historically. Even after vulnerabilities are identified it’s time consuming allocating personnel, QA / regression testing the fix, and scheduling production releases. No matter how mature the SDLC, it takes at least days, sometimes weeks, and even months for issues to be resolved. This is where most are today. This will also really challenge true PCI 6.6 compliance when the burden is realized.

That’s why strategy #2 works best for existing websites. The technology integration by which vulnerability assessment results are immediately imported into a WAF creating a “virtual patch.” The integration closes the loop between vulnerability identification and mitigation allowing the opportunity to address the root causes as time and budgets allow. The challenge here is if the vulnerability data source is inaccurate then the virtual patches may cause the WAF to deny valid traffic, allow malicious traffic, or crash entirely. With verified data, the enterprise is able to fully realize its vulnerability assessment investment in real-time, confidently place WAFs in block mode, and provide IT professionals with the control they’ve always lacked. And it would be about time too!

If this solution sounds familiar, that’s because the idea has been used successfully in the past, just never in web application security. Kavado tried in the 2002-2003 era, in 2003-2004 several more vendors attempted using AVDL, and I’m sure there were others, but ultimately all attempts proved unsuccessful for the reasons above. Only recently has the vulnerability scanning and web application firewall technology matured to the point where the combined approach has finally become viable. As the current state of Web security is being realized and business decisions need to be made, having a variety of options available is a great great thing.


Yousif Yalda said...
This comment has been removed by the author.
Yousif Yalda said...

Indeed, I think Web Application Security is new. The solutions you stated are factually great for any business. In all honesty, the strategies you explained should all be used for maximum change in terms of business and security, both operating at a safe and reliable interval. Also, since the media has been playing a rather repetitive role in introducing web security insight, importance, and the ever danger, solutions will begin to integrate and businesses will soon have to participate in conducting every-day operations with security in mind. I'm not saying security has to be their main priority, but it should be a factor that shall be initiated throughout the entire process of development, as a care cycle to both customers and self-credibility for the brand.

Marcin said...

I think the best intermediate strategy between the two solutions you propose is Aspect Oriented Programming. AOP is a step forward towards a more secure, maturer SDLC. I'm sure you're familiar with the concepts behind Aspects and AOP, but if not, Rohit Sethi and Nish Bhalla's "Using Aspect Oriented Programming to Prevent Application Attacks" talk at ShmooCon 2008 was great. I recommend checking it out as soon as the videos are made available. The WAF is just ugh... applying almost 20 year old strategies to ever-more evolving vulnerabilities. 2 steps forward, 3 steps back with that one.

Jeremiah Grossman said...

Marcin, actually I don't know a lot of "AOP", in fact never heard of it. Though it sounds like something I should start getting familiar with. When the video/slides get posted, please do comment them here. I'd like to review them.

S3Jensen said...

I think developer education is extremely important. Educated developers are the first line of defense for secure applications. I feel the industry is seriously overlooking this aspect, the consensus seems to be developers are already overloaded with development issues and attempting to throw security into the SDLC is just too much of a load for them to carry. The current mindset is, we don't expect developers to write secure applications. If we did, then we would need to hold them accountable for their failings. In the end who is to blame for a vulnerable application? Generally, we point the finger at the company as a whole, but in reality the company is failing itself in not properly educating/training developers to write secure applications.

Jeremiah Grossman said...

@Mephisto, while I don't dispute anything you've said, I just can't help but think genie is already out of the bottle. Basically its tough to get developers to code defensively against attacks we don't know exist yet. As an example, output filtering against XSS as a best practices is a relatively new things. Plus, I wouldn't lay 100% of the blame on developers, I've seen plenty of system misconfigs and general carelessness that either comes from design or implementation.

S3Jensen said...

Don't get me wrong Jeremiah, I'm not saying the entire blame belongs on the developer. Security issues can arise anywhere, such as servers, network, even in the frameworks we use. But when the issue is developer created, such as poor input validation. The blame, for the most part, belongs on them, but generally in my experience the developer is disassociated from the issue, as if the one didn't have anything to do with the other. Obviously, everyone involved needs to do their part to ensure the security of the application. However, it seems the developer has usually been the overlooked piece of the appsec puzzle.

Unknown said...

I'm that guy in the enterprise, and your description of my situation is spot on.

How do you handle situations where those developers are contract workers? In my view, simply writing "must know how to write secure code" into your vendor agreement won't get you anywhere.

Any suggestions on how to accomplish that and get buy-in for educating the contract workforce?

Jeremiah Grossman said...

@chris, good question. In addition to the contact language the only way I've managed to pull it off is during the software acceptance phases. As the code comes in you test it for security (static and/or dynamic analysis) with your internal team or an independent third-party. If the code is insecure or not up to specification, send it back with the results. rinse repeat. Over time the developers self-learn because its shorter that way. :)

Anonymous said...

Hello Jeremiah, this is an interesting post. And I agree that its difficult to keep pace with new security threats, unless one dedicates effort ongoing basis, which will actually help those who depend on their websites for revenues. You have a very informative blog, and I will get in touch with you for something win-win.

secure_master said...

Use a ckecklist for website-security: