The Principles Place
The principles place in the SDLC
The principles we have outlined so far will help you to develop secure software but this should be one step in a wider secure development process. They will provide a good level of security for your application but they should not be used in isolation. We have included an image below that shows the steps we feel need to be followed in the pursuit of a secure application and where these principles fit in:
The foundations underpinning any secure development efforts must be a clearly defined Secure Software Development Life Cycle (SSDLC) and developer education. If you do not know where, when and how security will fit into your development life cycle then it is very difficult to have security ingrained into requirements and designs. The failure to design applications securely will lead to project delays when the code reaches the security code review and testing steps. Each phase of the SSDLC should have some level of security input and sign off but we will not go into details on how to build an SSDLC in this blackpaper. The developer education should be self-explanatory; this entire article is largely discussing how to educate developers on how to develop securely. A common failure within organisations is the assumption that developers know how to develop securely and they subsequently fail to invest time and money into education programmes. This will never lead to secure software and organisations have to realise that developer education is one step along the path to secure software.
The principles are shown in the image but we won’t dwell on this step, this article explains the principles and why we have created them. The code review step will mandate that a security focused code review be conducted for every development; this review should evaluate the code against these secure development principles.
The final point to address is testing of the development for security weaknesses. This testing should be as comprehensive as possible and test for the vulnerabilities that the secure development principles should protect against.
The important thing to remember for all of the steps is that it doesn’t have to involve a large financial outlay to implement them. We have included information below detailing how we feel you can utilise free resources to build your secure development programme:
SSDLC – The Microsoft Security Development Life Cycle (SDL) is one of the leading SSDLC processes in existence. Microsoft has made a wealth of information available for free so you can base your own SSDLC on their internal processes.
Development Education – An avenue that is often not explored is OWASP chapter meetings. These meetings will have experts from your area presenting on application security topics that anyone can attend for free. The OWASP also have an education project that provides free materials for conducting developer awareness sessions.
Code Review – This is another area where the OWASP can help you. The OWASP Code Review Guide contains guidance on how to review code for many different vulnerabilities. There are a few free tools available and I would recommend the OWASP Code Crawler and Orizon projects to help you with your reviews.
Security Testing – The testing of an application should consist of both manual and automated tests. To help you with your automated testing we recommend using the Burp Suite.
Mapping the principles to specific vulnerabilities
The table shown below maps the secure development principles to common vulnerabilities taken from the three “top x” lists. More information surrounding these mappings can be found on my website (www.securityninja.co.uk/).
We started this article with a proverb and we would like to end it with one of my own. The reason we have created the secure development principles is to help developers create applications that are secure and not just built to prevent the current common vulnerabilities. We feel this proverb sums it up:
“Teach a developer about a vulnerability and he will prevent it, teach him how to develop securely and he will prevent many vulnerabilities.”
The information contained in this White Paper is based on sources which we believe to be reliable but we do not represent that it is accurate or complete. All information is therefore provided for guidance purposes only and does not form any part of a legal contract, agreement or understanding with Realex Payments. You should not take any action on foot of information contained in this White Paper before independently verifying it and taking appropriate financial, banking, investment, legal or other appropriate professional advice.
Content provided by third parties is acknowledged. Otherwise this White Paper is © 2009 Realex Payments. All rights reserved. Except to the extent permitted by law, no part.