Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial DirectorDo your vendors' security practices and application lifecycle standards meet your business needs? Perhaps your business deals with personally-identifiable information (PII) or is otherwise regulated and you have to know more details beyond what a typical Web vulnerability scan would uncover? Or – this can be a big gotcha – your lawyers approved a contract or SLA that either ignores application security or puts the liability back in your business' court.
I perform a lot of Web application security assessments for SaaS and cloud providers, and based on what I see, there are a lot of gaps creating business risks that you probably don't want to overlook. I'm not talking about the typical cross-site scripting and parameter manipulation type issues common in many Web applications. Instead, I'm seeing weak authentication mechanisms that are easily circumvented, SQL injection, and shared servers open to privilege escalation and data hopping where an attacker can not only access your application data but also that of every other business on the server. These Web flaws are not easily uncovered by some high-level security scan as mandated by PCI DSS or other Web security seal. Instead, they're flaws that require manual analysis and a keen eye for what to look for.
Perhaps this is a side-effect of the "let's scan it and go live" mentality of certain SaaS/cloud vendors. As it's been from the beginning, the focus is one time to market rather than making things right with software before it goes into production. After all, many investors and executives want to milk the SaaS/cloud marketing hype while the gettin's good.
Here are questions you should ask your software vendors to keep them honest and ensure their application lifecycle shortcomings involving requirements and testing don't negatively impact your business as well.
Can you show me an independent Web security assessment report in addition to your latest
vulnerability scan and SAS 70 audit?
If you want to know where things really stand with regards to exploitable Web vulnerabilities –
especially ones involving application logic – the latter two just won't cut it.
How are you analyzing security across the board to ensure that all user roles of the
application are tested for vulnerabilities?
Quite often I see where things check out fine with certain user roles while others are riddled with
vulnerabilities. Looking at the system as a true outsider (i.e. no authentication) isn't good
enough.
Have you performed a remediation validation test to ensure that the original problems
reported have since been resolved?
You need to ensure that not only have fixes been made, but they have been validated. Furthermore,
you have to be concerned with regression where the vendor has fixed one thing and broken
another.
How are you integrating the results of your Web security assessments back with your
application lifecycle management processes?
Is their team just fixing the issues to get by or are they learning from what's taken place and
making improvements in requirements, coding, and QA phases of your lifecycle?
Are critical findings addressed immediately? How quickly are all other issues
resolved?
Some application lifecycle management processes prevent critical issues from being resolved
reasonably quickly. What steps are taken to ensure issues are fixed and released in a timely
manner?
What technical and operational changes are you making to ensure these security issues don't
arise again?
Many Web security vulnerabilities are the result of misconfigurations, weaknesses in the patching
process, and a general lack of security standards. Find out how these issues are being resolved
above and beyond the development stage.
Be it the cloud, Intranet, client-server, whatever – you have to ensure your vendors are doing what's right when it comes to security. Getting answers to these questions may not be easy, but if your business represents enough money – and, thus motivation – the vendor will likely accommodate.
Don't expect perfection, but do hold others accountable for software they're developing for you as the end user or on your behalf or for others to use. Ignoring application security – assuming its someone else's responsibility – will only perpetuate the problem which, in the end, does no one any good.
About the author: Kevin Beaver is an independent information security consultant, speaker and expert witness with Atlanta-based Principle Logic, LLC. He has over 20 years experience in the industry and specializes in performing independent information security assessments revolving around compliance and information risk management. Kevin has authored/co-authored seven books on information security including the ethical hacking books, Hacking for Dummies and Hacking Wireless Networks for Dummies (Wiley). He's also the creator of the Security On Wheels IT security audio books.
This was first published in June 2010
Join the conversationComment
Share
Comments
Results
Contribute to the conversation