A featured contribution from Leadership Perspectives, a curated forum for enterprise technology leaders, nominated by our subscribers and vetted by the CIOApplications Editorial Board.

Adobe

Security as a Service

In most organizations, departments and employees work toward a common goal to fulfill an overarching mission and strategy, but oftentimes, when zoomed in, these goals can seem misaligned.

Engineers’ top priorities tend to be set on delivering innovative new products and features that customers will love. The security team's top priorities are to help protect the company, these groups can work together to accomplish both goals and help ensure that these innovative new products and features are built and enabled in a secure manner, and that the software delivered is worthy of customers’ trust.

Adobe’s Service Lifecycle (SLC) model leads teams through the processes needed to design, plan, implement and deploy code and software. Security was not always the most consistent or understood component of this process. While it’s a security team’s dream for every engineer to understand the intricacies of each security requirement necessary for their product, this isn’t always an easy task. Product teams are constantly bombarded from all sides with various requirements and processes, security included. We realized a change needed to be made to the process to facilitate a higher level of collaboration and understanding between engineering teams and security teams. Thus, we incorporated some of the existing SLC into the Secure Product Lifecycle (SPLC), which has not only helped define and measure what security means to our organization but has also helped create a positive and collaborative security culture.

Securing leadership and engineering support

To launch any major initiative or program, the top level needs to buy in. To get buy-in, we need to understand teams’ challenges and appeal to their motivations. Taking time to understand how a team works, as well as their unique priorities, processes, goals and challenges is crucial to not only working collaboratively but also finding what incentivizes them.

Before we took off working our SLC which we incorporated into what is now the SPLC, we spent hours consulting with dozens of members across the engineering, product and program management teams to understand what they do day-in and day-out, the obstacles they face and their motivations. Through this discovery phase, several common themes emerged and we realized (a) we could be doing more to ensure our many security requirements and processes were communicated more clearly and consistently, (b) we could be doing more to ensure security requirements and processes were more easily integrated into engineering workflows, and (c) we could be doing more to improve organization around the security process we had in place. Given that engineers are consistently under pressure to deliver new features for our customers, and must move quickly and efficiently to do so, the themes and process improvements will serve as a great benefit to our engineering teams.

Keeping our engineering teams’ goals in mind, it also became clear that we needed to strengthen the partnership to help make their lives easier.

One process improvement identified to reach this objective is streamlining the way the engineering teams receive important security information and how they are trained to implement security requirements. To this end, we started using the teams’ existing JIRA queues as our source of truth to track security work and use a consistent system of labels and priorities to make sure that issues reported are picked up and actioned by the teams in a manner consistent with the response required by the security team.

While every component of our SPLC model is crucial to its success – whether it’s key performance indicators, checkpoints, testing or threat modeling – there are a few key steps, when scaling, that stand out as force-multipliers.

Building a Security Champion network

We wanted to help our engineers by making it easier to implement secure by design principles into their work. From the start, we asked ourselves how to reach this goal when engineers already had in place “regularly scheduled programming.” This is when we began developing and implementing the ‘Security Champions’ program.

We asked the engineering leadership of each team to appoint one engineer who would serve as a “Security Champion” for their team, keeping in mind two key qualities. First, they needed to be a seasoned engineer who had extensive knowledge about the applications and business, and second, they needed to have some genuine interest in security.

Security Champions are - just as their name implies - security advocates, charged with keeping their teams in the loop on the newest security requirements and galvanizing them to act.

When we first introduced the program, we had a handful of Security Champions. Since then, this number has grown significantly, driven partly by the need to keep up with how quickly Adobe is building and delivering software, and the sheer size of some of our products. Our Security Champions are passionate about the work they do and their role as a Security Champion is a formal part of their role at Adobe. While Adobe requires every engineer to go through several levels of security training via a Ninja Belt program, many – our Security Champions in particular – have taken it upon themselves to achieve higher levels of security knowledge as well, through specialized trainings and projects that take a significant amount of dedication and time. The role is the Security Champion’s to own – some have started their own weekly security newsletter, while others have gone as far as to work with their management team to turn it into a full-time role.

Scaling the security team

It’s no easy task to manage security requirements across dozens of products, which are constantly changing and expanding. Building the network of Security Champions and training them on security requirements was just one step in the right direction toward scaling. With the speed at which we’re developing software, the security services also needed to be able to scale even further to fit the needs of our engineering teams.

Wherever we can, we operate our SPLC ‘as a service.’ We automate and centralize the requests from teams and develop repeatable processes to help streamline security tasks and reporting. We integrate with our engineering workflows by using the same tools and workflows that they use to develop and track the development of the software they’re building.

It’s no easy task to manage security requirements across dozens of products, which are constantly changing and expanding

Designing and building strong automation and reporting have helped us increase the efficiency of our security team and scale our efforts. Our automated reporting allows us to respond quickly to relevant information and our centralized data allows us to have a current picture of the security and business priorities for a given team. This allows us to have the comprehensive, most up-to-date view when we work with the teams to improve their security posture.

In Conclusion

Engineers and security teams are on this journey together. It is important to remember that a company’s goals must align to bring customers a delightful experience, and being worthy of their trust is a key part of that. As a security team, it’s imperative that all work adds value across the organization and that security programs help further collaboration and can also scale to meet the needs of the engineering teams that security partners with.

The articles from these contributors are based on their personal expertise and viewpoints, and do not necessarily reflect the opinions of their employers or affiliated organizations.