A recent uptick in the importance of application security driving the debate
During a recent visit to a client site, I took part in a discussion where the Development Department and the Security Department were arguing over which group was responsible for the security of web applications. Security felt it was the responsibility of the developers, and the developers felt it was the responsibility of security. I commonly see this debate taking place inside organizations, so I wanted to spend this blog post discussing where that responsibility lies.
When this discussion comes up, the first thing that needs to be defined is what exactly we are talking about when we say “the security of web applications”. For this blog post, we are going to limit the scope of Web Application Security to “ensuring the web application is securely coded to avoid security vulnerabilities and defects”. However, it is important to remember that developing and maintaining a secure web application does not stop at making sure the application is properly coded. A mature Web Application Security program incorporates security into their software development life cycle. This includes activities such as:
- Application threat modeling being performed when generating requirements for applications
- Security requirements properly gathered
- Reviewing the architecture of the application
- Regularly assessing application until they are removed from production
It is equally important to make sure the infrastructure supporting the web applications is also secure and properly monitored. However, covering all these items is beyond what can be covered in a short blog post.
It’s both (of course), but what does that mean?
The simple answer to this often debated question is both development and security are responsible for ensuring the security of web applications and they need to work together; neither group can achieve their goals alone. However, each group has their own separate set of responsibilities when it comes to developing secure web applications.
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.
As you can see, ensuring web applications are secure is not just the responsibility of one group. Instead, it takes a team effort to accomplish this important goal. In closing, I’d like to also state that many security organizations do not have expertise in house to provide training, develop secure coding standards, or properly assess web applications, and instead rely on third parties such as SecureState to provide these services.
So what is your take on this debate? Who do you think is responsible for security in web applications? Join the discussion in the comments section of this post!