Jason Taylor on Security Testing

Posted October 18, 2007 by Jason Taylor

Tester Question: My team has decided to get serious about security in the next release of our product.  We’ve talked about penetration testing and some developers want to perform security code reviews.  I’ve heard about threat modeling but don’t really know how it can help us.  What steps should we take to improve our chances of releasing a secure application? What should I be focused on as a tester?

To ship a product you can be confident in you should integrate security engineering activities into every aspect of your development lifecycle.  You are on the right track in your thinking, however, there is more to security than penetration testing and the occasional code review. Penetration testing is a great way to find vulnerabilities that may have slipped through the cracks during design and implementation, but shouldn’t be relied on as anything more than a backstop.  Security code reviews can find a large number of vulnerabilities but is still not enough. Trying to ship a secure application is an asymmetric problem. Your adversaries have the advantage of time and numbers and they will use this to attack your application mercilessly.

It is not possible to ship an application that you are 100% confident in, but you can use all of the advantages in your favor to improve your odds and make it as hard as possible for attackers.  What advantages you may ask? You have inside knowledge of the application, ready availability of source code, and access to the developers writing the code. Add these facts to a disciplined security engineering process and you may just have enough confidence to sleep at night without visions of black-hat hackers hounding your dreams.

There are many different software development processes, your team may be using waterfall, iterative, agile, RUP, or something else entirely. The good news is that security engineering basics apply equally to any of these approaches.  A holistic, disciplined approach to security will see your team executing each of these activities through the course of application development:

• Security Objectives. Define security objectives and requirements early in the process.
• Design Guidelines for Security.To avoid vulnerabilities introduced by poor design choices, your design should use proven design practices, patterns, and principles.
• Threat Modeling. Threat modeling helps you identify the threats and vulnerabilities relevant to your application.
• Architecture and Design for Security.The architecture and design review process analyzes the architecture and design from a security perspective.
• Code Review for Security. All code should be subject to code inspections where the emphasis is on identifying security vulnerabilities.
• Security Testing. Use a risk-based approach and use the output from the threat modeling activity to help establish the scope of your testing activities and define your test plans.
• Deployment Review for Security.When your application is deployed, check that weak or inappropriate configuration settings do not introduce security vulnerabilities.

These are activities that the entire development team should plan for, include in the schedule, and be involved in from project inception through deployment and maintenance. I imagine, however, that you are most interested in learning what you can do as a tester to provide the most impact.  Here is an outline of what I think the test role is through each activity:

• Security Objectives. Test the objectives against what you know the customer will want to do with your application.  For instance, if you are storing sensitive data is there an objective for safe handling of that information?
• Design Guidelines for Security. Review the guidelines against the types of security testing you will perform later.  Are there guidelines in place to reduce the number of bugs you’ll find? For instance, if you know you’ll be testing for buffer overflows are there design guidelines in place for input and data validation?
• Threat Modeling. You should be actively engaged in every aspect of threat modeling. The purpose of the threat model is to put yourself in the mindset of an attacker in order to discover assets of value, threats against those assets, and attacks that will realize the threats. Not only are testers superb at thinking in this way, but you can use this as good practice for when you start your testing later.  Additionally, you can use the threat model as a key input when building your attack plans for testing.
• Architecture and Design for Security. This is your chance to find security bugs before a single line of code is written. Use the opportunity to probe for common design weaknesses such as poor authentication and authorization, failure to protect sensitive data, and failure to create a centralized input and data validation architecture.
• Code Review for Security. If you are comfortable reviewing code, you should participate in the reviews as a code reviewer and find vulnerabilities in the code. If you aren’t comfortable with the code itself, you can still participate by asking targeted questions from the perspective of an attacker.  This is especially useful in group code reviews. You should probe for information such as: Where did this data come from? Can we trust the data source? Where will the data end up? Will it be placed in persistent storage (such as a database) or echoed back to the user?
• Security Testing. This is where you shine. Use the threat model as input to make sure you are testing against real risk scenarios and that the bugs you find will have large enough business impact that they will be fixed.  You will also be involved in discussions regarding which bugs to fix and which to leave.  Some security bugs are straightforward and must be fixed, others are grey and may result in more risk fixed than if you leave it in place. Use your threat modeling experience and put on your attacker’s hat to think about maximum possible impact so the worst case scenario is always understood if the bug will be left in the product.  BTW – difficulty in exploitation is not a good reason to leave a bug unfixed, my experience is that attackers will always find a way.
• Deployment Review for Security. You should do a final sweep before deployment to make sure that the application is secure in the deployment environment.  If you are shipping a  web application this often means reviewing configuration files, checking default users, and ensuring that security functionality (such as encrypting data on the wire) is turned on.

As you can see, you can add a lot of value during each step; even those that are not test-focused.  If your team adheres to a disciplined security process and you play your part, I think you will find your application significantly more secure. 

Additional Resources

• For an introduction to Security Engineering activities, see Security Engineering Explained.
• For more information on each activity, see the patterns & practices Security Engineering site.
• For a list of security webcasts, whitepapers and other resources from Security Innovation, see the Security Innovation Resource Center.

Discuss your security questions with Jason on the Software Testing Discussion Forum.