3 Tips to get your secure development program started

The hardest part of anything we do is typically just actually starting it. How many things have you thought about doing, but were not sure on how to proceed? What is that first step? We know we have to do something, but what?

This is no different when we think about application security and a secure development program. We have to start it. It is absolutely a necessity for any development program. So what should we do?

It is important to understand that security doesn’t happen overnight. There are a lot of ways to implement secure development, but none of them are a silver bullet. No one tool, or even a group of tools, will magically solve the problem.

Set Expectations

How do you want security to fit into your development process? Who is accountable for application security? In many organizations this is not clearly understood. Most people would say the application security team is responsible for application security. Is that how you want your organization to be? Do you want an external team responsible for security, or do you want the teams that actually create the products to take that responsibility?

Just because a team is responsible does not mean they are expected to not introduce flaws. This is a common misconception. There is no guarantee in security. Nothing is 100% and it should not be expected. What should be expected is that the development teams are responsible for creating quality products and security is a part of quality.

Setting the expectations for each team up front will limit confusion and make it clear what needs to be done. No more using the excuse that security is someone else’s job. Why would you not look for security issues while doing a peer code review? Why would you not test for security issues during the QA process? Why would you not build up a threat model while doing your design sessions?

There is no reason that these teams cannot perform these tasks. Training can be provided, or advisors can be obtained to help build this up.

Understanding your environment

When you are building your program up fresh, the most important step is to understand your development organization. What does it look like for a feature to go from conception to production? What teams are involved along the way?

If you don’t understand your environment and just start implementing security tools, you will be playing catch up from that point forward. Sure, you are always playing catch up, but there are more efficient ways to do it. By understanding your current processes, you can start to identify the right tools and processes to target that will cause the least friction but provide the highest value.

Training

You have set your expectations and you understand your environment. The next step is to start engaging the teams to build security into their processes. Unfortunately, most developer or qa training does not cover security topics. Fortunately, training on the basics of security is often not that complex or overwhelming.

Let’s take a quick example, peer code review. Hopefully everyone is doing some sort of code review when their developers are creating the application. Currently, most people will focus on coding standards or guidelines for that organization. Did you use the proper libraries that we have approved? Is the code readable and make sense?

Security is no different. It is focusing on standards and guidelines as well. Did you encode all output to the browser? This is pretty straight forward. Data is either encoded or not. That is simple to identify. There may be other rules you have based on your application configuration, but those environmental things should be common knowledge and documented.

In that example, you are protecting against XSS by properly encoding the data, without digging into security terms or the vulnerability. You are just enforcing your standards and guidelines.

This is no different than the majority of security checks. Provided the right training, this can be embedded into your existing teams with little friction or overhead.

Wrap Up

Every program starts somewhere. Don’t spend too much time debating on the first step. Select something that makes sense for your organization and work to implement it. Make sure that you are involving the development teams and other members of the organization to verify that what you want to do fits.