Security at the Design is Not Just Lip Service: AppSec Starts at the User Story

I was speaking with an experienced Application Security Architect recently when he made a stunning statement: he spends the majority of his time in Jira reviewing user stories that may introduce risk into the company’s applications. After many more conversations, I’ve come to realize that this is not unique – the same sentiment resonates with many practitioners in the AppSec industry. In many ways, this is a great example of the “shift left” philosophy of identifying potential risks before they reach production. At the same time, it highlights how far we still have to go before application security is deterministic, automated, consistent, and efficient

The rapid growth in recent years in the speed of development is making “Security at the Design” ever more critical. Business priorities are changing rapidly and new user stories, feature requests, and bug fix requirements are changing on a daily basis. Every new change request has the potential to introduce risk into the system. At the same time, Agile development moves fast and Engineers often begin development without a security review because the AppSec team is outnumbered (by 159 to 1, according to BSIMM)!

Waiting for implementation and discovering issues in testing (or even production!) is no longer an option. The later an issue is discovered, the more rework is required, leading to higher costs and slower delivery. This is why security risks now need to be identified at the design.

Unfortunately, identifying the user stories that require AppSec attention is also increasingly difficult and security professionals are struggling to keep up with the sheer volume of change requests.

The AppSec engineer is responsible for securing the output of several hundred developers across multiple teams; waiting for vulnerabilities and other security weaknesses to reach production is simply not a viable strategy. Preventing security issues before they are implemented is the most efficient (and some would even say the only) way their organization can effectively understand and remediate risk.

When Application Security engineers look through user stories, they are looking for a number of things, including:

• Is a new type of data going to be added to the application? Does it involve Personally Identifiable Information (PII), Protected Health Information (PHI), credit card information, or other sensitive types of data?
• Will there be a change in connections between services or data flows?
• Will there be new data flows with a third-party? How will “secrets” like tokens be managed?
• Will authentication or authorization changes be made?
• Which developer is making the change and what is their skill set?
• Will changes be made to Internet-accessible APIs?
• Will the change be made to a business-critical application?
• Will core infrastructure components be changed?

The answer to any of these questions can ignite a conversation between Security and Development teams or trigger a defined security process, such as a Threat Model or Security Code Review. As an Application Security professional, there are a few keys to making security at the user story successful:

• First, you must understand the current state of your applications and code with complete accuracy. Relying on a design document that is rarely updated is simply not good enough when applications are changing so rapidly. This requires a real-time inventory. It is often useful to prioritize “first of a kind” changes (such as the first time PII fields are added to a repository) over additions to existing types (e.g., new PII fields added to a repo that has existing PII fields).
• You also need to understand your developers. A user story that requires changes to authorization controls that is assigned to a develop with no security experience is far riskier than that same ticket assigned to an experienced Security Champion
• Automation is required to ensure consistency. When there are multiple development teams in different locations working with different AppSec engineers, it is impossible for anyone to know which types of changes will be flagged as risky. Addressing this requires a governance engine with a ruleset that is applied to all applications and teams based on their business impact. In addition, appropriate processes can be triggered at every SDLC phase (feature request, commit, PR or CI/CD), such as a risk assessment questionnaire for every new feature that involves PII.
• If a potential issue is discovered, it’s essential that the appropriate experts are notified who can evaluate the risk, understand its implications, and work towards a resolution. This often means establishing a Security Champions program inside of the Engineering organization.

The Apiiro Approach to Security at the Design

All risk is contextual and Apiiro takes this approach to securing applications at the feature request, commit, PR and CI/CD time, before deploying to production. In agile, the code is the design. There is often no formal process for documenting changes that must pass a detailed security review by Application Security professionals who are overworked and outnumbered.

We have often spoken about providing risk-based Application Security from design to code to cloud, but a “shift left” approach is actually the opposite. Configuration data in the cloud can be used to better understand risk at the coding and design stages.

The Apiiro platform analyzes text, code and configurations across the entire SDLC in order to build a risk graph that provides a comprehensive risk assessment at each stage of the SDLC.

Apiiro:

• Creates and maintains a real-time application & infrastructure inventory that is continuously updated with every change
• Use Natural Language Processing (NLP) to analyze the user stories themselves.
• Identifies potential Security Champions by looking at both code commits and pull request discussions to identify security expertise in the development team
• Triggers the appropriate security progress when a risk is identified in a user story, from a threat model to a design review to a penetration test by alerting the proper people and providing them with the contextual information to successfully perform those tasks

With a comprehensive understanding of risk, creating an effective Application Security program that starts at the user story is finally possible.