[zz]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.
Posted by Jeremiah Grossman
