Our Application Security Journey

Building a Secure Software Development Capability… and Culture

Mike Goodwin, Sage Technical Fellow and VP Product Security & Architecture

Introduction

Sage was formed in 1981, only a short time after the inventor of the World Wide Web, Sir Tim Berners-Lee, first worked at CERN. So, obviously, at that time Sage was initially known for desktop-based software rather than SaaS. Fast-forward to today and for several years now, Sage has been transforming from a desktop software company to a SaaS company. A big part of this transformation (and the part that I have been most deeply involved in) has been a step-change in the way we treat security our Software Development Lifecycle (SDLC) approach. This post is a personal reflection on our journey along that road so far and draws out four elements that I think are the most foundational aspects of our program.

Each of these foundational elements is an important topic in its own right and it’s not possible to do justice to each of them in a single, medium-length article. This article should be viewed as an overview and I will follow up with more articles diving deeper into each subject area. Check back here for updates to find links to these new articles:

· Securing our culture

· Building maturity in our security approach

· Measuring security effectiveness using offensive security

· Security champions

· Securing applications using threat modelling

Background

At the start of our journey, we had several centres of good security practise in our software development teams — including some genuine experts — but no established programme with a mandate to drive continual, consistent improvement in our approach at a global scale.

Around that time, I was just coming out of a very interesting and demanding project at Sage and I was looking around for a new challenge. By coincidence, an opportunity came up to join a recently created team with a responsibility for, amongst other things, the security of our SaaS offerings. Now, the opportunity to significantly influence the software development approach of an FTSE100 software company doesn’t come up very often, so I jumped at the chance.

From being a team of one initially, we are now a well-established team with global reach, made up of application security specialists, compliance experts, security architects and red teamers. We work closely with a large and active community of security champions (more on those later) and a wider team of around 2500 technology colleagues.

Securing our culture

One of our early choices that set the tone for our approach was to focus on nurturing a culture where people want to deliver good security simply because it is the right thing to do. This is partly because that approach is a great fit for Sage’s overall corporate culture, but also because in a large and diverse company like Sage where teams are given a lot of autonomy, it is the most effective way of delivering consistently good security across the organisation.

The security team needs to work carefully and continue to support this culture. We can’t behave like gatekeepers or a police force — although that is sometimes needed. Instead, we must genuinely become enablers for our colleagues:

· If a team ends up experiencing our security gate in a painful way, we have failed in some way

· We lean in and help rather than saying “No”

· We rely on credibility, expertise and reputation, rather than job title or position

· We build open, collaborative working relationships

· We always try to “push security to the left”

· We aim to build a capability across Sage rather than sitting in an ivory tower

This probably sounds like common sense, but it is not easy to achieve. A key factor is in the hiring process: When we are hiring into the security team, we put as much emphasis on interpersonal skills as we do on security knowledge. Most people who have tried to hire security specialists will know about the skills shortage in our industry and if you reduce the skilled candidate pool further by asking people to be great communicators, this can obviously make hiring even harder. However, the mindset and approach of the security team can make or break the security culture. So, while we are flexible on location, experience level, formal qualifications and technical background, we are not flexible on the need to work well with people.

Building maturity and measuring progress

There are many, many activities that teams could do to strengthen their security approach, so how do you choose? What do you introduce first? And how do you know if it is really helping?

At Sage, we base our planning on a maturity model called the Building Security in Maturity Model (BSIMM). Currently, like version 10, BSIMM is based on observations of what real companies are doing in practice. This makes it a very pragmatic model that helps improve security over time, focussing on the most effective (and cost-effective) activities first.

BSIMM offers a membership option, but also publishes its model free of charge under a Creative Commons license.

The model recommends many security activities across the development lifecycle, grouped under 12 headings:

1. Strategy and metrics

2. Compliance and policy

3. Training

4. Attack models

5. Security features and design

6. Standards and requirements

7. Architecture analysis

8. Code review

9. Security testing

10. Penetration testing

11. Software environment

12. Configuration management and vulnerability management

Within each category, the activities are divided into 3 maturity levels, representing the level of adoption of each activity that BSIMM have observed in their member organisations. This allows organisations using BSIMM to plan a broad programme with even progress across their SDLC. Teams can assess their level of maturity both in absolute terms and relative to other organisations by counting which activities they include in their SDLC.

BSIMM assessments are a measure of the inputs to secure software development. While these inputs are certainly a strong indicator of good practise, they do not give you an objective measure of effectiveness. In other words, BSIMM doesn’t tell you about the outputs of the various security activities you are doing. Our main measure for outputs is the number and severity of vulnerabilities that are introduced by our SDLC. The better our SDLC is, the few vulnerabilities we will introduce. It is important to focus on both the inputs (the activities you perform) and the outputs (the vulnerabilities that you introduce).

At Sage, we measure the output of our security activities using various forms of offensive security testing. We use a blend of three different forms of offensive security:

· Application penetration testing

· Bug bounty programs

· Red team exercises

The way we choose which approach to use for any given scenario is explained in a previous blog post.

Security champions — the cornerstone of our approach

One of the most important measures we have implemented is establishing a strong community of Security Champions (referred to by BSIMM as the security Satellite). This is identified as a specific activity in BSIMM and at version 10 of BSIMM, it was reported that 86% of the top 35 BSIMM organisations have security champions. For us, it is so foundational to our approach that I don’t think of it as an activity as such; along with the core security team, our security champions are the cornerstone of our approach.

So, what are they? Well, they are a community of colleagues from our technology teams — mainly software developers and testers but also including software architects and other roles. They are not full-time security professionals, but they have a strong interest in and passion for security and they channel this to help build the security capability of their teams. They are a form of a virtual security team that acts as a force multiplier for the core security team. In terms of numbers, we have around 15 security champions for each full- time security team member.

Their position in the development teams mean that Security Champions are involved with the daily stand ups, huddles and water-cooler conversations which is where many of the actual security decisions get made. Their role is to champion security at all points of the software development lifecycle. This includes being a centre of expertise for the rest of their team, promoting and leading a wide variety of security activities and (if needed) standing up for security when prioritising work items for the teams.

In a large, geographically dispersed organisation like Sage, it would be very hard for us as a centralised security team to properly keep our arms around all these decisions from the “code-face”.

We provide specialist security training to all our technology teams, but because security champions are so pivotal, we put special focus on the development of their security capability, including:

· Providing long-term, structured training programmes for them to support their own security journey

· Holding regular meetings, capture-the-flag competitions and security conferences to help them share ideas and strengthen their community

· Encouraging them to participate in local security focussed meet-up groups such as their local OWASP chapters

Some of our champions have achieved high-end security qualifications such at the Certified Secure Software Lifecycle Professional (CSSLP). Others have developed to the point where they have joined our security team on a full-time basis. Given the importance and difficulty of finding the right people for our core security team, this is tremendously valuable to us.

Secure by design

BSIMM contains many recommendations for security activities across all aspects of software development. In my experience, one of the most foundational and important activities, especially for helping to build a wide security capability, is Application Threat Modelling. This is a structured approach to help software development teams think about how their application might be attacked and then design ways to mitigate these attacks.

There are several ways of doing Application Threat Modelling ranging from formal through to less formal approaches such as card games (e.g. OWASP Cornucopia) and informal whiteboard sessions. Generally, the technique has three stages:

1. Decomposing your application into its component parts, usually using a diagram.

2. Asking questions about the decomposed application to try to guess how someone might attack it — these are called threats.

3. Designing ways to block, avoid or minimise the threats — these are called mitigations.

I have written about some of the practical benefits of Application Threat Modelling in a previous blog post and provided some practical tips to help teams get started. For this blog I want to focus on two reasons why I think it should be a foundation for any application security programme.

Firstly, more than any other security activity, I have found that application threat modelling encourages application builders to think hard about the security of their application. In fact, it forces them to. In my experience this tends to drive a deep understanding of why and how different security mitigations are needed. This deep understanding leads to more transferable and reusable knowledge than other activities.

Secondly, Application Threat Modelling is fundamentally a team activity. The best threat modelling sessions I have been seen have included people from all aspects of the application team — developers, business analysts, architects, testers and operators. This means that many different people get exposed to security thinking and can contribute meaningfully to it. So, the understanding it promotes is wide as well as deep.

Conclusion

Sage has been on a journey, continually strengthening our approach to secure software development for several years. While there is always more to learn and different organisations can plan their own paths, I have identified in this post a few foundational elements of our programme that I would recommend to anyone who wants to steer their organisation towards building more secure software:

· Focus on the behaviours needed to nurture a strong security culture across your organisation

· Plan to build your security maturity over time and measure the effect using offensive security testing

· Build a community of security champions to amplify the effect of your security team

· Use application threat modelling to build a deep and wide understanding of the security of your applications