Hyperguarding your Web Applications

Posts Tagged ‘Amazon Web Services’

First dWAF?

Posted by hyperguard on December 18, 2009

We’re glad to see others are seeing the importance and worth in a distributed Web Application Firewall (dWAF); however, we wouldn’t call Akamai’s recent news the first WAF in the cloud.  The technology is a black list filter for requests.

Adrian Lane @ Jeremiah: in reference to Jeremiah’s point on white list vs. black list

…I am making the assumption that Akamai relieves their customers from specific ‘black list’ threats and the burden on web site WAFs, but does not relieve customers of the need to build their own ‘white list’ of policies.

Today’s WAF technology looks very differentBlack, white and gray listing is considered a basic functionality.  Proactive features like session protection, form field virtualization, learning and assisted security policy refinements are a must. Exchanging information with web application security related products, such as web application security vulnerability scanners or static code analysis tools, are a must-have.

For these reasons, art of defence launched the first fully fledged dWAF for their customers at RSA 2009.  More recently, we’ve made this service available to AWS customers or solution providers so they can protect their applications by applying hyperguard SaaS either as software plug-in to an existing web server Amazon Machine Image (AMI), or by using AoD’s custom AMI.  The technology behind this is going to be implemented at other various cloud service providers in the near future so they can offer a true dWAF (at least) in their cloud.

Follow the discussion on Twitter @hyperguard.


Posted in Post | Tagged: , , | Leave a Comment »

‘Tis the Season for Overflow Help (look to the Cloud?)

Posted by hyperguard on November 18, 2009

The holiday season is upon us and the weight has potential to crush under-resourced e-commerce dependent companies. 100,000’s of visitors per day can turn into a mad rush of millions, bringing online sales crashing down. Amazon Web Services (AWS), Google and other cloud providers are preparing to provide overflow capacity for those in need.

The world is not all roses, however, and companies should understand that beyond their secure network perimeter lay security threats (ahem, OWASP’s new Top 10) targeting the application itself. Since it takes a company an average of 67 days to fix a common webapp issue such as Cross-site Scripting, the holiday season could spell trouble for these companies without adequate security measures in place to provide protection such as a ‘virtual patch’ (like a cloud-based WAF), until the real patch can be developed.

Just imagine all the lost revenue in the 67 days it would take to fix the problem at the code level without shoring up the vulnerability in the meantime.

Don’t agree with the 67-day estimate? Javed Ikbal of zSquad illustrated why this is common (even the possibility 67 aren’t enough!) in a painfully humorous way:

Day 1-10: Denial. We don’t have that problem
Day 11-20: Management: Must we do this? Why couldn’t you do it right the first time
Day 21-25: Finger-pointing phase. Who is going to pay for this? Is this funded? Who is the project manager?
Day 26-35: Project plan developed. Resource not allocated
Day 36-45: Pre-meetings and meetings. Project still not funded
Day 46: CTO chews out VP of software engineering
Day 47: Project is funded
Day 48-49: Research
Day 50: Vulnerability fixed
Day 51-55: Regression testing. The fix broke 10 other things.
Day 56-60: Fix the new items
Day 61-65: More regression testing
Day 66: Meeting where VP of engineering tries to take all credit
Day 67: Promoted to Production

Posted in Post | Tagged: , , , | Leave a Comment »