I was recently reminiscing with a friend regarding some of the hairier projects we had worked on together. One in particular stood out. It was for a financial services company. While the project itself had no specific security requirements, the company decided toward the end of the project that it needed to have security standards that included security audits for all applications that were going into production. Our application happened to be the next one going into production so we got to be the first ones to go through the new security audit process.
Although the project stakeholders didn’t have any security requirements in mind when we started the project, we had insisted on a few requirements ourselves such as session timeouts, encrypted passwords in the database and SSL only access to the application. These seemed to make sense and in the heady days of 2003 seemed to be some kind of best practice since no one knew what a XSS was back then.
The security audit included several phases:
- Penetration Testing
- A source code review
- Architecture review
- Deployment review
- Review of the security requirements and features in the application
All of these phases were conducted by different people, that never talked to each other and managed by the CISO’s office. The CISO was the Chief Information Security Officer for the company. Since I was the chief architect for the project I was the main point of contact for the CISO’s security audit manager.
One of the worst things that can happen when you are behind and working hard to get an application out the door is for an outside entity that had no experience with your application to come in and conduct an audit. Audit’s take time and often take time from your most valuable resources, your development team. You know the people that are working hard to get the application out the door, the ones already working in crunch mode.
Because of time and resource constraints, security, like many non-functional requirements, comes up short as a priority when not making the release date is a possibility and frankly, when was the last time you worked on a project where the release date wasn’t in jeopardy at the end of the project (if not the beginning).
In order to deal with my stressed out developers and looming deadline I decided to restrict the security auditors access to the team and allowed them to interact just with me. While it served my primary goal of keeping distraction away from my developers it also allowed me to gain a good deal of insight into security audit practices and processes.
This insight helped me come up with some ideas on how to more effectively work security into a fabric of development rather than just gluing it on at the end:
- Have security requirements from day one. Stakeholders and business users don’t know how to create security requirements. It is the job of the technical team to come up with them, explain them to the stakeholders and sell their priority to the stakeholders.
- Many aspects of security testing can be automated and run as part of a Continuous Integration cycle. This includes penetration testing and static code analysis. While automated testing isn’t a complete solution to security testing it will help reduce the overall cost and increase the effectiveness of your security testing efforts.
- Conduct internal audits and correct problems as they are discovered. While it isn’t easy to take time out or a full project schedule to audit yourself, someone will find the time to audit you. You will be lucky of the someone is a security consultant you pay to audit your application.
- Don’t take the tools and security consultants word for it. Take the time to understand the problems and their solutions. You know your application better than a security consultant. They are good at finding problems and suggesting solutions but their advise is based on industry standard solutions that may or may not be right for your application.
- Adopt some security practices into your software development process, like threat modeling and business risk analysis. Adding new process steps into a cost conscience organization can be a challenge. The bright side of these practices is that they can speak to the stakeholders in a language they understand – money and more specifically the risk the company takes on by not addressing security issues.
Following these practices wouldn’t lead to the end of external security audits it will help you get through them easier and it will certainly help your applications decrease it’s security risk profile, which is the real goal of external security audits.
