It is almost 8 years now, since OWASP has become the de-facto standard for developers, architects and designers to develop secure applications. Security Professionals use OWASP testing guide as a bible to ensure a comprehensive assessment. This article highlights some of the key changes derived from the 22 pages of OWASP TOP Ten 2010 release document.

Highlights from OWASP TOP TEN 2010

On 19th April 2010 OWASP Top Ten 2010 release, Dave Wichers (OWASP Board Member and COO Aspect Security) who has managed the OWASP project since inception, says “This year we have revamped the Top 10 to make it clear that we are talking about Risks, not just Vulnerabilities. Attempts to prioritize vulnerabilities without context just don’t make sense. You cannot make proper business decisions without understanding the threat and its impact to your business”

These are Risks, not just Vulnerabilities!

OWASP Top Ten always wanted to emphasize on risks rather than listing the most common vulnerabilities. This time it is clearly highlighted in the document that how threat agents, attack vectors, weaknesses, lack of security controls, technical and business impact can help understand the risk for the organization. The following diagram depicts how the overall risk should be determined

Ranking criteria is redefined
In the previous Top Ten lists of 2004 and 2007, the ranking (A1…A10) of a particular vulnerability was determined based on how frequently a particular vulnerability was discovered in the applications. But now, it is linked to various parameters such as attack vectors, weaknesses, impact etc. which first determine the overall risk (probability ‘X’ impact), based on which the ranking is assigned. The general scenarios have been considered to assign rankings.

“Malicious File Execution” is ousted
OWASP Top Ten 2007 vulnerability “A3 – Malicious File Execution” is removed from the Top Ten 2010 list, as this vulnerability was mostly observed in PHP applications and now PHP itself is getting shipped with more secure configurations to mitigate this risk.

“Improper Error Handling and Information Leakage” is removed from the list. Not really!
OWASP Top Ten 2007 vulnerability “A6 – Improper Error Handling and Information Leakage” has been removed from the Top Ten 2010 list. However it is covered under the newly added “A6 – Security Misconfiguration”.

“Security Misconfiugration” has made a comeback!
“Security Misconfiguration” has made a comeback in this list again. It was in the 2004 Top Ten list as “Insecure Configuration Management” but later removed from the 2007 list.

There is a reason for this, the application cannot be considered secure if application code is written using secure coding practices alone. The prevailing weakness in underlying infrastructure OS, Web  Server, Application Server, Database etc. may allow an adversary to compromise the system or gain unauthorized access to application or data. For Example, the recently reported vulnerability “Microsoft IIS WebDAV Remote Authentication Bypass” may allow an adversary to bypass security restrictions and access to sensitive information.

Many times, administrators may forget to remove or disable default applications, ports, accounts, privileges, services etc. in the application. Consider a scenario where a securely written financial application deployed on the JBOSS server and the administration interface of this is accessible with default credentials over the internet.

In addition to this, if an application is using any third party framework or libraries like struts, hibernate etc. then due diligence should have been done to ensure that it is free from security issues and patched properly.

“Unvalidated Redirects and Forwards” – The new guy on board!
Phishing attacks have been a growing concern. An adversary crafts a malicious URL that redirects users to a malicious website which then performs phishing and installs malware. If your application is using ‘Redirects’, it could be potentially vulnerable to this flaw. Sometimes a malicious user of the application utilizes this vulnerability to redirect him to the page to which he is not authorized to access.  

“Stop chasing the Top Ten; it’s high time to build an Application Security Program now!”
It becomes very difficult to handle large masses of vulnerabilities in the application code once it is shipped to production and issues such as cost, downtime, developer’s availability etc comes in spotlight when you sit down to fix the security bugs. With proliferating number of attacks and regulatory pressures (e.g. PCI DSS), organizations must establish an effective capability for securing their applications. So OWASP recommends that organizations must establish an application
security program to gain insight and improve security across their application portfolio.

But, where do you begin ?
Following steps can help you get there.

1. Initiate the Application Security Program. Make sure you have the senior management’s approval and support to drive the program.

2. Categorize applications according to their risk level. Take help from the security experts if required.

3. Establish standards, polices, secure coding guidelines, secure design/architect principles and call them as a baseline.

4. Integrate security controls in the Software Development Life Cycle (SDLC) itself. For example: Conduct threat modeling and secure design review at the design phase, follow secure coding guidelines while writing code, review code for security vulnerabilities, write misuse test cases for security testing, conduct penetration testing before moving to the production, consider secure configuration while deployment, monitor continuously etc.

5. Finally, measure effectiveness of program with metrics and keep management informed about the improvements and cost-savings with the program.

Conclusion
The OWASP Top Ten has taken major steps towards highlighting the fact that there is a shift required from “Identifying Vulnerabilities” to “Managing Risks” of the applications. This new focus on ‘Risks’ is destined to extend organizations to have better understanding and management of application security across the organization. It is also worth to note here that writing secure code would not be alone sufficient to secure the application, but the security of coupled third party components and underlying infrastructure has to be considered in order to have all doors properly closed. It also emphasizes on building the application security program which would help measure and manage “Application Risks” and ultimately improvise application security across the enterprise.

If you wish to download the complete document on OWASP Top 10 2010, you may visit -

http://www.owasp.org/index.php/Top_10



About Author
Jaykishan Nirmal, Lead Consultant, Aujas Networks Jaykishan Nirmal is Lead Consultant with the Secure Development Lifecycle practice at Aujas and is responsible for conducting threat modeling, security code reviews and risk assessments. He has rich experience working on consulting assignments in the LPO, Banking, Finance, Insurance, FMCG, IT and IT Services domain. He is also a frequent course instructor on secure coding principles and security awareness.

He graduated in India from the Nirma University with Bachelor of Technology in Engineering and has a Diploma in Cyber Forensics. He can be reached at jaykishan.nirmal@aujas.com

About Aujas

Aujas is a Global Information Risk Management (IRM) services company. We provide management consulting and technology lifecycle services in the area of information risk. Our objective is to offer effective IRM services on business and technical issues. Our Service portfolio Includes Information Risk advisory services, Secure Development Lifecycle services, Identity and Access Management services, Managed Information Risk services, Vulnerability Management services and Converged Security services.

For more information, write to contact@aujas.com