InfoSec-Specific Executive Development for CISOs and Aspiring Security Leaders.
Live Faculty-led instruction and interactive labs to build you and your team's InfoSec skills
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.
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 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.
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.
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:
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.
October 19, 2021
By IANS Faculty
Continuous compliance requires continuous monitoring and validation of controls in the environment, as well as integration with governance, risk management and compliance tools and platforms. Understand the processes, tools, stakeholders and focus required for a best practice continuous compliance program.
October 14, 2021
Learn how the DDoS threat is evolving and get a step-by-step playbook to ensure your organization is protected against DDoS attacks and has a response plan in place.
October 12, 2021
Uncertain how to secure your M365 environment? Our Faculty identify and explain the five primary areas of M365 that will provide the best security return-on-investment with the least user experience impacts.