Tip

Effective Web application security risk assessment in 12 steps

Sachin Kediyal, Reviewed by: Plash Chowdhary & Megha Anand

Over the years, application security awareness amongst organizations has significantly improved. Organizations are now more aware about the financial losses, legal and regulatory liabilities they have to bear

Requires Free Membership to View

if the Web applications are compromised and are hence, investing heavily on people, processes, tools, and technology to build a healthy application security posture.

Organizations are gradually shifting towards Agile or Rapid Application Development software development life cycle (SDLC) processes to reduce the Web application development timeframe. A methodology like Agile provides flexibility and control to quickly change the business/end user requirements in SDLC. With the advent of these time saving SDLC methodologies, the onus lies on the application security auditors to undertake a thorough Web application security assessment within a stipulated timeframe. This guide split into two parts highlights important parameters for an effective Web application security assessment. Part I discusses key factors such as collecting information, risk profiling, choosing the right security tools, and others.

Information collection: The first step in any Web application security assessment is to gather as much information about the target Web application. Auditors can set up a pre-assessment kickoff meeting with the application team to capture the business and development scenarios associated with the target Web application. The meeting enables the auditors to ensure things like: 

• Target Web application’s URL is accessible

• Auditor’s internet protocol (IP) addresses are white listed on the firewalls

• Test data is present in the target Web application

• Deliverables such as Web application security assessment report, scope and format are defined

The auditors should at least be aware of the following application specific information:

• Details like assessment URL, test credentials and IP address

• Types such as Internet and Intranet

• Environments such as development, test/stage/user acceptance testing and production

• Data classification such as public, internal, confidential and restricted

• User base and roles

• Underlying application architecture, technology and supporting services

• Application size in number of Web pages (static + dynamic) and code base size (in lines of code)

• Assessment time window in time zones

• Contact details of key personnel in order of priority

Risk profiling and effort estimation: This is a major step while planning for Web application security assessment. Depending upon factors like the Web application’s data classification, size of the code base, user roles and assessment time window, assign efforts to each of the assessment steps/phases. The various steps/phases involved in a Web application security assessment could be:

• Automated vulnerability scanning

• Manual penetration testing

• Mapping black box findings in the application’s source code

• Assigning risk rating to the identified security flaws

• Reporting

A successful security assessment is critically hinged on the auditor’s ability to prioritize and balance the efforts, without skipping any of the mandatory steps. For instance, it is wise to concentrate more on manual pen-testing rather than automated vulnerability scanning to check for potential authorization issues in a Web application having too many user roles with different access privileges.

Application fingerprinting: It should be done before trying actual exploits on the Web application. Auditors must understand the Web application dynamics, nature of user interfaces, data flow between various components, defining priorities on pages/interfaces, underlying components, common vulnerabilities and exposures, and known vulnerabilities. Application fingerprinting helps auditors acclimatize with the application and accordingly plan for Web application security assessment.

Define the scope, trophies/objectives: It is important for auditors to consider the scope and define trophies/objectives for Web application security assessment. The scope defines the areas of the Web application to be included or excluded from the risk assessment strategy. The objectives/trophies for an assessment should be defined before embarking on it, as they provide an auditor a clear understanding of the kind of result expected from him. They also keep the auditor in control of the assessment, thereby reducing the chances of deviating from the actual strategy/plan. For instance, possible risk assessment objectives/trophies for a public facing static Website could be to check if the site is vulnerable to any kind of defacement or denial-of-service attacks.

Role-based access control matrix: Creating a role-based access control matrix for the Web application with different user roles mapped against the functionalities they are authorized to access greatly helps auditors, especially in the manual pen-testing phase, to identify authorization related security issues. Below is an example of a sample role-based functionality matrix:

 

Application Functionalities

Roles

Create

Account

Modify

Account

View

Account

Delete

Account

Account

Search

Manage

User

Normal User

No

No

Yes

No

No

No

Supervisor

Yes

No

Yes

No

Yes

No

Manager

Yes

Yes

Yes

No

Yes

No

Administrator

Yes

Yes

Yes

Yes

Yes

Yes

 

Choose appropriate security tools: Security assessment tools work best only if the auditors properly analyze and verify results obtained from them and improvise accordingly using manual assessment techniques. Zeroing down on the right security tools (open source or licensed) is an important factor in determining the outcome of a Web application security assessment. Several factors such as the Web application’s dynamics, underlying technology/platform, auditors’ expertise in handling specific security tools, as well as the accuracy of the tools, their performance, characteristics and ease of operation ought to be considered. Security tools help in automating the Web application security assessment process, thereby saving the auditors’ time and efforts. The effort saved could be reinvested to improve the assessment quality and effectiveness. For instance, using SQL injection fuzzers instead of manual injection techniques to find possible vulnerable points in a large Web application helps auditors focus more on exploiting the identified vulnerabilities.

(The second part of this tip will be featured next week on SearchSecurity.in)

About the author: Sachin Kediyal is a security consultant with IBM GBS - Security & Privacy consulting practice. He held various roles and responsibilities ranging from developer to infosec consultant, while working for organizations like IBM, Tata Consultancy Services and Micropro in a career span of over six years. An application security professional with expertise in security risk assessments, he is an active volunteer member of OWASP India, and has conducted numerous training on application security and secure coding for his clientele. He can be contacted on kediyal.sachin@gmail.com.

This was first published in November 2010

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.