It is difficult to apply a capability maturity model (CMM) to agile processes because the two approaches often conflict with one another. A CMM approach assumes a finite set of goals, each of which can be met to varying levels of coverage or rigor. In
contrast, an agile approach involves continual review and adjustment based on the gaps between the current state and the desired future state. However, by embracing the mindset that accompanies agile, it is possible to achieve the same goals as a
CMM, but in a non-prescriptive way.
Conflicting Models
As information security practitioners you are often accustomed to adopting a framework and iterating within that framework, making targeted components better over time. While the desire to blend the two approaches is understandable, it is unlikely to
work in practice.
The agile approach – whether implementing it in small pockets or enterprise-wide via the SAFe approach, for example, – has, at its heart, the idea that it is not possible to prescriptively meet stakeholder needs. Agile is a response to the
more traditional waterfall model, in which projects are well-defined prior to implementation, broken into phases, and then approached phase-by-phase until the stakeholders receive the tool/application/process they want.
Early agile developers realized stakeholders in the waterfall approach often changed their minds about what they wanted once the project was underway. Because of this tendency, it didn’t matter how much rigor people put into the process; the end
result was always somewhat off from what people actually wanted.
Within agile, the entire notion of prescription was thrown away, replaced by an idea that work should be done in “sprints,” with each sprint running a finite amount of time (traditionally two weeks) and designed to achieve a small set of achievable
goals. After each sprint, the new functionality is demonstrated, and the stakeholders are given a chance to further refine their vision and set the goals for the next sprint. This approach allows the work being done to gradually converge with stakeholder
expectations – getting closer sprint after sprint.
Unfortunately, CMM approaches are prescriptive in nature, so while it is possible to use CMMs to inform agile processes, it is not possible to blend them together without losing either the vision from the CMM or the rapid responses that come from agility.
In effect, attempting to do this turns the waterfall model into a cascade – or a set of small waterfalls that all flow into one another, but that do not allow for the sort of fundamental transformation SAFe both promises and demands.
Agile Iteration
Agile processes are successful because they put work into a cadence model, in which different iterations can set the expectation for different deliverables based on business needs and resource availability. A standard pattern is to start each sprint cycle
with a review of current needs and short-term projected capacity. This information is then used to plan the next sprint – usually two weeks of work – after which team members typically review the requirements, ask clarifying questions,
design tests to define what success means for the sprint, and begin the work. At the end of the sprint, the work is reviewed first by the development team and later by a larger group that includes the stakeholders who need the new capabilities offered
by the sprint. After the sprint is complete, the cycle starts over again, with another review of current needs and short-term projected capacity.
In agile, some items are desired by stakeholders but cannot be done within the planned sprint due to blocking dependencies or resource constraints. By adding such items to the “backlog” – or list of desired capabilities that cannot be
met – agile allows the review of current needs to involve “backlog grooming,” or a periodic process of reviewing elements not being done and identifying whether they can be completed in the next iteration.
Using an agile approach with a functioning backlog allows for a link to a CMM. While the CMM is still in direct conflict due to its prescriptive nature, it is possible to take the requirements from a CMM and treat the CMM itself as something of a stakeholder.
Prioritizing Compliance and Security
Once the generalized backlog exists, internal processes must be developed to help the project managers manage the backlog. Typically, organizations will prioritize in one of two ways: security-focused or compliance-focused.
An agile environment often uses the concept of minimum viable product (MVP). This approach allows a development team to create a “strawman” project quickly, so it can be used, reviewed and critiqued by various stakeholder groups. While security
groups operating under something like SAFe may not be creating traditional products, it is possible to map the MVP concept to a minimal compliance stance (MCS). Such an approach provides assurance that once MCS is reached, any reasonable auditor working
against a standard audit framework would be able to give the organization a passing grade. Common compliance models would be PCI, HITRUST, SOC 2, ISO 27001, etc., or combinations thereof.
Usually, once MCS is reached, organizations will shift their focus to security elements and, instead of filling the backlog from the Cybersecurity Maturity Model Certification (CMMC), the Capability Maturity Model Integration (CMMI) or any of the compliance
frameworks, they will use a combination of threat modeling and risk assessment and possible controls review – using the 20 Center for Internet Security (CIS) controls, penetration testing, etc. – to identify which features should be implemented
on a sprint-by-sprint basis. As this is done, an organization may decide to further postpone existing backlog items, create new backlog items that may enhance compliance or pivot entirely to a different set of control types.
As the process matures, the organization may identify tasks to be postponed indefinitely and remove them from the backlog, storing them instead on a risk register so the annual risk assessment process can consider them and move them back to the backlog
if the team believes the risk should be addressed in the short term.
Adopting Agile for Security
It is very possible to adopt SAFe and similar approaches and apply them to information security work. However, it must be done in alignment with agile principles and in a way that adapts security concepts to those principles – not the other way
around. Some do’s and don’ts here include:
- Do: Take the time to reach the Agile Manifesto and any supporting documents for your agile implementation.
- Do Not: Split apart an agile framework and cherry pick components for existing programs. Such an approach keeps all the inefficiencies of the current approach and adds time to deal with agile.
- Do: Split apart your security requirements into smaller sprint-compatible elements (often called “stories” in agile).
- Do Not: Allow the agile prioritization process to continually de-prioritize security/compliance issues to such a level that it causes you to fail external audits.
- Do: Take the time to translate your agile-security practices back into “regular” security speak when speaking with auditors and others who may question the appearance of ignoring standard practice.
- Do Not: Give up too early. Agile’s core success depends on flexibility being used to identify and address failures, so early stages of a new program can involve a lot of failure.
- Finally, moving a security practice to agile can make a lot of traditional practitioners uncomfortable. Expect to be challenged and have ready answers for common issues (like separation of duties). If you are a manager, be prepared to re-train people
and do not be afraid to terminate those who provide resistance and fail to embrace the new system. Agile can be highly successful, but not if resentful team members are sabotaging the program from the inside.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.