“It is not necessary to change. Survival is not mandatory.” — Edwards Deming
As an early adopter of Agile methodology, I’ve witnessed firsthand how the framework has revolutionized software development.
But as software development became faster and more efficient, security concerns became more complex and pressing.
To bridge this gap, I developed the Agile Security Engineering Framework while working on security engineering at Microsoft.
This framework incorporates Agile principles into security engineering, allowing teams to develop secure software with minimal disruption to the Agile development process.
Through years of experience and collaboration with fellow Agile practitioners, I’ve refined this framework and seen it successfully applied in various projects.
Agile Security Engineering Framework
What’s important about the figure is that it shows an example of how you can overlay security-specific techniques on an existing life cycle.
Baking Security into Your Life Cycle
In this case, I simply overlay some security activities on top of an Agile software cycle.
Rather than make security a big up front design or doing it all at the end or other security approaches that don’t work, we’re baking security into the life cycle.
The key here is integrating security into your iterations.
Key Security Activities
Here is a summary of the key security activities and how they play in an agile development cycle:
- Security Objectives – This is about getting clarity on your goals, objectives, and constraints so that you effectively prioritize and invest accordingly.
- Security Spikes – In Agile, a spike is simply a quick experiment in code for the developer to explore potential solutions. A security spike is focused exploring potential security solutions with the goal of reducing technical risk. During exploration, you can spike on some of the cross-cutting security concerns for your solution.
- Security Stories – In Agile, a story is a brief description of the steps a user takes to perform a goal. A security story is simply a security-focused scenario. This might be an existing “user” story, but you apply a security lens, or it might be a new “system” story that focuses on a security goal, requirement, or constraint. Identify security stories during exploration and during your iterations.
- Security Guidelines – To help guide the security practices throughout the project, you can create a distilled set of relevant security guidelines for the developers. You can fine tune them and make them more relevant for your particular security stories.
- Threat Modeling – Use threat modeling to shape your software design. A threat model is a depiction of potential threats and attacks against your solution, along with vulnerabilities. Think of a threat as a potential negative effect and a vulnerability as a weakness that exposes your solution to the threat or attack. You can threat model at the story level during iterations, and you can threat model at the macro level during exploration.
- Security Design Inspections – Similar to a general architecture and design review, this is a focus on the security design. Security questions and criteria guide the inspection. The design inspection is focused on higher-level, cross-cutting, and macro-level concerns.
- Security Code Inspections – Similar to a general code review, this is a focus on inspecting the code for security issues. Security questions and criteria guide your inspection.
- Security Deployment Inspections – Similar to a general deployment review, this is a focus on inspecting for security issues of your deployed solution. Physical deployment is where the rubber meets the road and this is where runtime behaviors might expose security issues that you didn’t catch earlier in your design and code inspections.
The sum of these activities is more than the parts and using a collection of proven, light-weight activities that you can weave into your life cycle helps you stack the deck in your favor. This is in direct contrast to relying on one big silver bullet.
Chunking Up Security for Reviews and Inspections
Note that we originally used “reviews” which are more exploratory, but we later optimized around “inspections.” The distinction is that inspections use criteria (e.g. a 12 point inspection.)
We share the criteria using security checklists for design, coding, and deployment inspections.
There are two keys to chunking up security so that you can effectively focus on it during iterations:
- Security stories
- Security frame
Stories are a great way of chunking up value.
Each story represents a user performing a useful goal. As such, you can also chunk up your security work, by focusing on the security concerns of a story.
Security “Hot Spots”
A security frame is a lens for security.
It’s simply a set of categories or “hot spots” (e.g. auditing and logging, authentication, authorization, configuration management, cryptography, exception management, sensitive data, session management.)
Each category is a container for principles, patterns, and anti-patterns.
By grouping your security practices into these buckets, you can more effectively consolidate and leverage your security know-how during each iteration. For example, one iteration might have stories that involve authentication and authorization, while another iteration might have stories that involve input and data validation.
Together, stories and security frames help you chunk up security and bake it into the life cycle, while learning and responding along the way.
You Might Also Like
What is Agile?
Agile Architecture Framework
Agile Lifecycle Framework
Agile Performance Engineering Framework
Baking Performance into the Life Cycle
Extreme Programming at a Glance
Scrum at a Glance
Software Methodologies at a Glance
Software Performance Frame
Software Performance Hot Spots
Software Performance Inspections
Waterfall to Agile
Leave a Reply