If you ask enough people how and why a company was hacked, the answer will normally come down to few root causes. Two of the most common root causes of information security breaches today are humans and software related. Almost every aspect of a business today runs on software yet most software development activities do not include any software security engineering activities such as threat modeling or secure developer training. Most software is implemented without really thinking about how to build protection in from a cyber-attack perspective. Companies and systems will continue to be breached until humans are more aware of the risks and software security is completely baked into every step of product development. This includes products such as firmware that resides on all hardware devices to communication protocols such as IPv6 to enterprise applications, websites, mobile and desktop applications. It must be understood that no software can be 100% secure however, all software can be designed, developed and deployed in a secure manner much like a quality control process through implementation of a secure software development lifecycle (S-SDLC).
Secure Software Development
Most organizations today have a process for developing software, this process is customized based on organizations requirements and framework followed by organization. Secure software development introduces key input activities and steps that should be integrated into software development lifecycle in order to build secure and attack-resilient software. The graphic shows an example of a generic Software Development Lifecycle. The lifecycle provides a structured way to build software that completely caters to the needs of the end user. Software development team employ various frameworks such as agile, XP or waterfall to move through this lifecycle quickly to deliver software. Secure development is about injecting appropriate security activities within these phases. The type of activities and frequency of activities heavily depends on the organization.
The current trend of software security engineering
A customer has just sent you an email requesting to prove security of your application or to perform assessment of your software product. You forward the email to your security team to determine exactly what type of assessment will satisfy your customer needs. Your security team tells you about performing activities such as source code analysis, dynamic testing, threat modeling, and security requirements documentation and so on. You hire a 3rd party vendor to help you perform this assessment only to find out cost of assessment is much lower than the actual cost of fixing issues found. Your development team is frustrated because now you have just added hundreds of tasks to their list and potentially re-architecting components of the software. If this sounds all too familiar, you are not alone. This is the current approach to implementing security within software – it’s 100% driven by an external reactive force such as a regulation or customer, which are driven by industry attacks such as the Anthem & Target breach. This industry wide knee jerk reaction trickles down to your developers and you identify issues by performing 3rd party assessment of the application and then fix them in a much more costly and time consuming way or worst never address the issues.
A better way
Attacks will not stop and neither will new regulations that continue to raise the bar on issues related to consumer privacy and security of their data. Organizations who understand this are one step ahead of their customer requirements as well as a step ahead of hackers. Below are four steps to improve software security within your software development teams. This isn’t an easy task but if achieved properly can save an organization tremendous amounts of money and headaches.
Step 1: Establish a case for secure development
Gaining management buy in is critical for your secure SDLC project to be successful. This requires understanding the business drivers for your organization which could be customer driven, cost avoidance, regulations or just general good business practices. Management buy-in includes a budget as well as policy level support. You will also need an internal champion to start implementing this change of process and influencing developer behavior within your software development teams. The best recommendation is to start with one development team versus trying to implement secure development blindly across the whole enterprise or within all your development teams. Start with a team where you understand their product, development culture and their challenges.
Step 2: Start with training
Your initial investment must be in people over software security automation tools. There have been too many times where we have seen security tools purchased and never used properly due to lack of training or fundamental understanding of software security. Also, software security tools are so complex that it is best to first start with training. A great example of first course for your developers might be software security 101, .NET secure programming or Open Source Web Application Security Project (OWASP) Top 10 secure development training. It is important to note that the training you implement for developers must be specific and actionable, there is nothing worse than having to attend security training that is too general or not applicable for your developers. It might be best to try scheduling secure development training in small doses such as lunch and learns on specific topics like covering injection attack for 1 hour with some real world example code from your own organization.
Step 3: Integrate Security Activities
Next step is to integration of security activities within each phase your development lifecycle. This is tough to figure which activities makes sense for your environment because not all phases of the software development lifecycle are followed especially in agile development. In a fast paced development environment, requirements are sometimes developed during design or implementation and testing is conducted as your product is getting ready to be shipped. Our recommendation is to start with light activities such as threat modeling or security design requirements and then add more activities every cycles until it becomes natural for your development team. This will ensure that your development team doesn’t become overwhelmed. The goal here is to slowly change behavior of your developers to start thinking about security as their primary way of solving programming challenges. This is actually very tough to do because there is a normally resistance to change in adding additional tasks for the development team.
Step 3: Perform Selected Security Activities
Microsoft lays out seventeen different security activities for Secure SDLC implementation. At first, performing security activities will feel clunky and out of place for everyone because it is something new for your team. But overtime, activities such as team threat modeling or source code analysis will become the norm. Your development team will figure out how to implement security better than your matrixed application security architect because they are more familiar with the product. Finding existing security flaws within the architecture or security bugs are great opportunities to teach and learn about security for your development teams. When you feel your team has mastered few of these activities – add a few more that are different that challenges them to think differently about security.
Step 3: Rinse, Repeat & Learn
There are very few organizations that get to the point where they are able to measure maturity of the development team from a software security standpoint. Therefore, secure SDLC involves a strong element of continuous improvement. As you learn more, you should implement more activities. If your development team is taking on a new product or creating a new feature, they should continuously take training on various programming language specific security issues to improve their understanding. The training does not have to be formal classes but more so lunch and learns or just simple 1 – 2 hour sessions on specific security topics that can be immediately applied within your development environment. A key part of Secure SDLC is creation of artifacts such as test results, design documents, etc… these documents are important to prove compliance. Also, these documents will help your 3rd party security assessment team to find problems that are not yet known instead of finding problems that are already documented. Automation tool for source code analysis or dynamic testing should be purchased only after your team understands how to do secure development to reduce frustration. These automation tools can generate compliance related artifacts for you.
Step 4: Celebrate Results
Secure development really comes down to great management of your development team. A good manager will always celebrate results like cost control and security defect reduction. Give your development team recognition because after all it is about changing behavior by teaching and rewarding than by ignoring and dictating security at the last minute. You will start to notice that team morale is up and developers are much happier by actually implementing this last step. This inevitably leads to retention of the employee because today good developers are very difficult to find and keep.
In conclusion, to start with secure development the right way be sure to get buy-in from the top management and also the bottom-up through your development teams. When the funding is provided be sure to spend part of you initial investment in humans than over tools, your developers will respect you for it.