Enabling a “secure by requirement” approach

AUTHOR: VARUN AGGARWAL, ENGINEERING MANAGER, SECURITY & PRIVACY, ADOBE CAMPAIGN One of the major projects underway at Adobe, which includes the Adobe Campaign team where I serve as

“security champion,” is the effort to migrate solutions to our container-based infrastructure platform. The easier to build and package promise of containers along with the ability to use

orchestration tools to help scale and manage those applications are key reasons Adobe and many other cloud-based solution providers are leveraging container platforms to evolve their

solutions. This effort, as with any major project, can present its own unique security challenges. In a container environment, each internetworked service runs its own business logic about

how data will and should be handled by adjacent services. This offers many benefits in more rapid application development, but such distribution of logic could potentially complicate

regulatory compliance requirements. What’s more, containerization can also increase potential attack surface. Navigating these challenges requires proper management of the technology as we

build applications that use it — and security by design needs to be at the forefront. To keep pace, security needs to be addressed at the earliest possible stage in the development

lifecycle. This “shifting left” approach is one we’ve made a foundation of our application security strategy. However, it requires more than simply saying, “we’re going to conduct security

reviews at design time.” On the Campaign team — as well as other teams working on similar projects — we took a holistic approach to the shift, and found five important steps that helped

ensure the success of our “security by requirement” approach: 1. DEFINE SECURITY REQUIREMENTS BEFORE CODING EVEN BEGINS. With a growing focus on a “secure by design” strategy, it’s easy to

skip over the most important first step: defining and communicating the security requirements BEFORE design even begins. Security requirements should be clearly defined and understandable,

so that each developer working on the design is aware before the first line of code is even written. Besides, what good is a security design review — which are typically not conducted until

the design has almost been finalized — if you don’t know what you’re looking for? 2. ELECT A SECURITY EXPERT ON THE PRODUCT TEAM. Security professionals should participate in the design

process, not after design is complete. At Adobe, we call this person the project’s “Security Champion.” Having someone on the design team who can connect the product design to the security

requirements is critical. 3. FORMALIZE THE THREAT MODELING PROCESS. The security team can use tools, such as Threat Dragon by OWASP, to create models and list potential threats in one place.

At Adobe, we manage the models in a separate git repository and the team works on them just like a developer manages code: Each reviewer in the modeling process produces an artifact and

tracks it in the repository. This helps other reviewers in the process add to the model and makes reviewers accountable for their work before they can close out the review. 4. CREATE A

SEPARATE CHECKLIST FOR SECURITY. Often, the threat modeling process ends with logging tickets for the development team. This rarely works out well since these tasks often compete with other

priorities that the development team must complete before the project is ready for production. This can have the unfortunate effect of pushing security tasks to lower priority than they

should be. However, if you create a separate security checklist and make completion of all items on the list a requirement for product release, you can help ensure that the development team

has addressed the tickets raised during the threat modeling process and the resulting design changes have been reviewed as well. 5. ITERATE THE SECURITY PROCESS. Just like iterative

development cycles provide information to improve designs, they can also glean important data to further improve security. “Calibrating” security requirements and strengthening the threat

model on an ongoing basis is critical to continually reducing potential attack surface. Findings from penetration tests can also be used in subsequent iterations to identify potential weak

areas and easy targets. Plus, if you label and group vulnerabilities into useful categories, such as SSRF and XSS, you can better highlight the attack surfaces that need to undergo more

focused requirements calibration. These five steps have helped our development teams working on this project to not only think about and include security mechanisms earlier in the

development process, saving time and resources, but it has also enabled us to make great strides toward the overall success of our container-based applications. The lessons learned from this

effort will help us enable earlier course correction if needed by baking in security controls earlier to reduce potential cost of any functionality changes introduced later. This is a core

benefit of “shift left” methodology and will serve us well in our move to broader use of our container-based platform.