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: Amazon, Amazon Web Services, Application Secuirty, LinkedIn | Leave a Comment »
Posted by hyperguard on September 24, 2009
We had some great feedback from developers in LinkedIn about this issue. Some thoughts worth sharing below.
Brian Hidgen chimed in with his thoughts:
“I perform security code reviews of internally written and commercial packages every day. It is stunning how many problems I see. Why does XSS still happen? For one, time pressure. Developers are under time constraints to deliver so they cut corners and push things out. Management for the most part does not take security seriously or they adopt a see no evil mindset and ignore the problem until they get bitten down the road. Lack of understanding is a big one too. I have been a developer for a long time and I was not trained or even sensitized to the issue until relatively recently. I know a lot of my colleagues past and present are in the same boat. We aren’t doing Cobol on a mainframe either, we are all Java/.Net/Ajax/Web 2.0 developers. The problem simply isn’t well understood and not enough attention is paid to it.”
Milton Smith shared a little more with us:
“The problem with XSS, and cyber security in general, is awareness. People don’t see security as a problem until it impacts them. Next, highly secure software is a consumer EXPECTATION. It’s not generally a feature consumers are willing to pay extra to include in their products.
Building secure solutions takes: education, training, tools, process improvements, etc. As such, it’s all too easy for commercial software vendors to bargain away the features consumers cannot see, like security. Other areas of non-functional requirements suffer as well: performance, scalability, reliability, and diagnostics.
The causes for XSS are well known. Poor cyber security is like showering in a glass bathroom blissfully unaware everyone is watching.”
Posted in Post | Tagged: Cross-site scripting, LinkedIn, scalability, software development | Leave a Comment »