Thursday, July 25, 2019

The Five Pillars of a Successful Application Security Program

You've been given task to build out or improve an application security team. Congratulations. You now have a key question to answer: "how will your application security efforts help your organization balance application delivery with application security?" Will you have an answer?

Maybe you are lucky and can slowly work towards an answer to this question since your company has just decided to build out an application development team or, like me in my current role, the answer is a bit more complex since you've moved to an organization in which application development has been going on for years but never has been really governed from a security perspective. Vendors can help but they really are focuse on their own tools.

This post will try to provide you with some considerations for building or improving your application security from something other than a vendor perspective. I draw a lot from my own experience in the field. My journey to becoming a security practioner included some stops leading large high visibility commercial application development teams building API platforms and products for hundreds of millions of users. You've likely used some of the products. Simply by the nature of our product and the frequency with which every appsec defect was reported in the news demanded formalizing an application security program long before appsec was really something defined. Since then, I've defined and implemented a number of application security programs at a number of different organizations.

A key learning from my experience is that there is no "one size fits all" solution to application security. Each organization brings its own unique goals, risk appetite, and requirements. Your organization will need to plan accordingly.


So, let's start with defining five pillars of any successful app security program
1. Prepare And Align the Business
2. Develop Coding Standards
3. Train Developers and Architects
4. Find Code Vulnerabilities
5. Measure and Report

Most of these are self explanatory. Below, I'll cover the pillars that need more context and provide some thoughts and tips to supplement the pillars where necessary in more detail.

Let's get started....

Prepare and Align the Business - This is a pillar because like anything in our space, a rigorous app security program will be difficult to implement without support from executives throughout the business. The business thrives as internal capabilities are improved from in-house software. These software releases gain their own momentum internally to the business especially when additional revenue is anticipated from the functionality in a given release. You'll need to prepare the business for the expectations around application security, define the value that having secure applications can bring, and make their leaders aware of potential impacts. Not easy but your business reputation with customers makes the effort worthwhile. .

The initial scope of your initial program will be important. What expectations will you be setting?Are you only focused on new code? Legacy code? Everything? My suggestion would be to start with some tightly focused objectives, work through any process issues, report the initial measurements, achieve the objectives, and then expand your efforts as you find success and the business becomes more accustomed to the program.

Build and Communicate an Application Security Roadmap: While not a pillar, a roadmap is a key tool for setting application security expectations with the business. Without a roadmap, there is no appsec program. It's likely better defined as uncoordinated activity around scanning in the app security space. Your roadmap provides the linkage of current activities to future objectives and helps to answer questions about current and future state.

The value add of your application security program should increase over time. For instance, if there are gaps, when and how will those gaps be filled? If your scanning is currently disruptive due to the amount of rework needed by the dev team late in the release cycle, what's the path and resourcing necessary to reduce vulnerabilities "upstream" so fewer issues are found in the initial scans?

Include Internal and Third Party Developers In Your Standards: Writing standards is a pillar but these standards should span more than simply coding standards. I've seen organizations whose application security policy and standards consisted of a simple link to the OWASP documentation. While OSAWP is important, this approach is hardly tailored for the broader range of application security requirements for your org.

What happens if your organization wants standards that are somewhat dfferent from the linked documentation. To use policy language for a moment, what are the "musts" and "shoulds" applicable to your organizational capabilities and risk appetite. For instance, in my current organization, many of the "shoulds" listed in OWASP are shown as "musts" in the application security standards for our organization.

As previously mentioned, the key differentiators are broader that just code standards. Thee is lots to think about here. Internally, what is the scope of the app security standards? What is the governance process and frequency of review? What are the application seurity training standards and to whom do they apply? How does security governance differ from Test/QA? These are just some of the questions that your application security standards and policies might cover.

One key gap I often see is not defining security standards for code developed by third parties. Where will vendors store code? Your repository? Theirs? What are the security standards for their repositories if your organization's code is stored there? How about cardholder data? I'd highly recommend that you ensure that contractual constructs are in place to contractually ensure that vendors are following your organization's security standards.

You'd think these vendor questions would be obvious and easy governance wins. That said, prior to having the contractual constructs in place, I've experienced vendors that tried refusing to let us scan their code for vulnerabilities, had stored code in publicly accessible repositories, said our cloud provider had controls in place to mitigate their poor coding, and also contractually had no responsibilities for fixing security defects. None of these had been covered in standards or contracts.

Resolving these issues required a two fold approach:
  1. Writing standards and policies that specifically covered code risks by third party developers
  2. Engaging with the contracts team to codify these standards into the contracting process.
Scan As Part of An Automated Build Process: While true security is the product of training architects and devs to understand the security risks they write, we can't turn devs and architects into true security professionals. Various types of static and dynamic code scanning will always be a pillar of a successful application security program and the timing of these scans matters. I'll repeat this just in case you missed it above: scanning code near the end of a release can be very disruptive process. Presenting a large number of security defects close to release lowers the probability of key defects being fixed. This is especially true if the release has taken on momentum for business reasons.

App delivery can be balanced with security. One suggestion might be to automate scans into the build process. This way, issues can be identified with each build and, assuming that the dev team has an existing process when builds fail, the small number of issues can be fixed within an timely and existing process already owned by the dev team. Automated governance then simply becomes a normal part of the app development process. Win-win.

Note that there will be some work associated with the automation depending on your tools and skillsets of your security team. Your roadmap can help to set expectations around the timeframe and resources needed to make balancing delivery with security through automation a reality.

Don't forget to pen test any online functionality that involves thegranting of credentials, self service, or purchases.

Align Outcomes With Risk Tolerance: All of this governance described in thi post wll result in finding issues. That said, not everything can always be fixed every release. I'd recommend clearly defining app security defects that are absolutely outside your risk tolerance and need to be fixed even at the expense of delaying a release. Pre-determining what is acceptable to release may also be of value. These decisions should be reflected in your app development team's prioritization mechanisms.

If you are using an agile framework, I'd recommend engaging your BOs and POs to help the understand the app security process, objectives, and impacts on decisions of prioritization around non-functional requirements. Early alignment with agile trains will make things easier.

Develop Metrics: Metrics are also great not only showing progress but also for communicating gaps. Lots of questions can be answered with metrics. For instance, as we ramp up developer training around secure coding, are we finding fewer vulnerabilities in the initial scans? If not, why not? There are lots of things to measure. Not all of them are helpful to your program. Ensure that your metrics are answering key questions.

So, as you can see, a true app security program involves planning for far more than simply code scanning. In this post, we've identified five pillars for any successful application security program and also some tips for implementing them. These pillars can be used to stand up a new app sec program or improve an existing one. Like any security initiative, alignmet and engagement are key. Success with app security is no different.

Taken from a Linkedin article that I wrote earlier in 2019.
Follow me on Twitter for the latest blog updates: @Opinionatedsec1

SEE ALSO

Develop Security Metrics That Also Are Your Remedy Negotiation

Cybersecurity Needs Style Points

Intentional Choices For Security Teams and Digital Transformation

No comments:

Post a Comment