Agile software development has inadvertently put security in the hands of developers--for better or for worse. Do your developers know this? Do they care? How do you and your security team ensure you're shipping secure software while still moving fast?
In this episode we speak with Guy Podjarny and Gareth Rushgrove about how we got where we are when it comes to security, which roles developers and the security team should play, and how to build security tools into the developer workflow in a way that is seamless. Check it out on iTunes or SoundCloud.
1. First, developers need to have the proper training to know how to securely code web applications. This is a key skill left out of most college course on programming. Second, the developers and security staff need to develop Secure Coding Guidelines for each language used at the company. These guidelines will provide the application developers with information on how they should securely code common functions. It is important for security and the developers to work together to generate this document to ensure the guide is useful to developers, allows developers to code in an optimized fashion, and properly addresses security concerns.
2. Once developers have been trained and Secure Coding Practices have been established, the developers need to perform internal checks on the code they are developing to ensure the code is vulnerability free. These internal checks help ensure the Secure Coding Practices are being followed and are a great way to improve developer’s knowledge of how to securely code web applications. Throughout this process, the Security or Quality Assurance (QA) group should perform spot checks to make sure the internal developer code checks are being performed.
3. Once the application is coded, it moves into the QA process where the QA staff is responsible for identifying any defects in the application. Classically, QA testing has focused on testing the usability of an application and stress testing an application under load. However, security vulnerabilities caused by coding are also a defect in the application, because a security vulnerability would allow the application to function in a way it is not intended. Because of this shift, QA is responsible for ensuring the application is securely coded before it moves into production. In many organizations large and small, the QA staff does not have the proper training in Web Application Security or the interest in growing that capability in house. For those organizations, they should team up with an outside company that specializes in Web Application Security to have them perform the QA testing.
4. Once the application passes QA testing, it is time to move the application into staging, which is the final step before it moves into production. At this point, Security should test the application. During this test, it is critical the application be set up exactly as it would be in production. This test must be performed by a group outside of QA and development to ensure the application is reviewed by a fresh set of eyes. If the Security Department has the capabilities, they can perform this test. However we find that many Security Departments do not have application security specialist on staff, so this is frequently outsourced to a third party. Security is ultimately responsible for making sure this test occurs and is performed by a qualified party. If any issues are discovered, development is responsible for making sure they are correctly fixed in a timely manner.
5. Next, the application moves into production. To ensure the application remains secure, a number of steps must be taken. All applications that are in production should have quarterly Black Box Scans and annual Grey Box Assessments performed on them. These Assessments will test the applications for new vulnerabilities that may impact the application. These steps are mainly the responsibility of the Security Department. If any functional changes are made to the application, these changes should go through the complete security SDLC process.