Security risk assessment methodology: How to conduct a risk assessment

In my previous article, Application security assessment, part 1: An opportunity for VARs and consultants, I explain the value of providing Web application security assessments for your customers. So how do you conduct an application security assessment? The key is to establish and follow a repeatable methodology, such as the following.

The value of application security assessments Read part one of this series, An opportunity for VARs and consultants, to learn why your customers need a Web application security assessment.

Begin by creating a project plan with your customer that details both tasks to be performed and their timing. Include customer-authorized test windows, proposed on-site dates if required, as well as projected dates for major project milestones. Also identify, with the customer's help, critical documents and artifacts that you will use to plan and conduct scanning and testing. Requested information may include:

• Network architecture diagrams
• IP addresses and URLs for application testing
• Test windows and schedule information
• Application user and administrator guides
• Application credentials

Conduct the application security assessment remotely, beginning with application functional security testing. Test the customer Web application up to an agreed upon number of unique user roles, looking for functional security flaws that may expose the customer to risk.

Next, assess the effectiveness of the application-layer security controls by attempting to gain unauthorized access to the application. Try to bypass authentication, authorization, input validation and other controls, using the following hacking techniques:

• Parameter tampering – Modify query strings, POST parameters and hidden fields in an attempt to gain unauthorized access to data or functionality.
• Cookie poisoning – Modify data sent in cookies to test the application's response to unexpected cookie values.
• Session hijacking – Attempt to take over a session established by another user to assume the privileges of that user.
• User privilege escalation – Attempt to gain unauthorized access to administrator or other users' privileges.
• Credential manipulation – Modify identification and authorization credentials in an attempt to gain unauthorized access to other users' privileges.
• Forceful browsing – Misconfigured Web servers will send any file to a user, as long as the user knows the file name and the file is not protected. Attempt to exploit this security hole and "jump" directly to private pages.
• Backdoors and debug options – Many applications contain code left by developers for debugging purposes. Debugging code typically runs with a higher level of access, making it a target for potential exploitation. Developers may also leave backdoors in their code. These backdoors, if discovered, could potentially allow an intruder to gain additional level of access. Attempt to identify debugging code and backdoors.
• Configuration subversion – Misconfiguring Web servers and application servers is a common mistake. The most common misconfiguration is one that permits directory browsing. Hackers can utilize this functionality in order to browse the application's directories (such as cgi-bin/). Attempt to do so yourself by simply typing in the directory name.
• Input validation bypass – Remove client-side validation routines and bounds-checking to ensure controls are implemented on the server.
• SQL injection – Submit specially crafted SQL commands to input fields to validate input type controls.
• Cross-site scripting – Submit active content to the application in an attempt to cause a user's Web browser to execute unauthorized code. This test is meant to validate user input type controls.
• Note: Immediately notify the customer of all "high" severity findings, which expose the customer to immediate risk of security compromise.

When you have completed the application security assessment, analyze the results for false-positives to ensure their accuracy. Also analyze each finding for severity and criticality.

Finally, deliver a concise Report of Findings and Recommendations detailing weaknesses identified within the customer's Web application. Where appropriate, provide recommendations for correcting security exposures.

About the author

Adam Rice is a Manager at VeriSign's Global Security Consulting. VeriSign's Global Security Consulting Services help Fortune 500 companies understand corporate security requirements, navigate the maze of diverse regulations, identify security vulnerabilities, defend against and respond to attacks, reduce risk, and meet the security compliance requirements of your business and industry.

Adam has authored several white papers and technical articles on security professional services and emerging threats to the Internet community. He has an extensive background working in security professional services product development and business delivery.

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.