The CIO’s greatest roadblock to Agile development: Security governance

Today, the greatest roadblock CIOs face when adopting Agile development is not ‘security in general,’ but ‘security governance.’ We can define ‘security governance’ as the establishment of security policies and the continuous monitoring of their proper implementation by stakeholders within an organization. In order to be effective, ‘security governance’ must accomplish two things within a business context:

1. Alignment between IT’s competencies and business needs.
2. Clearly defined security roles, processes, and controls, to the end of delivering programs that are valuable to the business.

Often, however, two notable security governance gaps emerge:

1. The business value to security competency gap.
2. The security policy to Agile execution gap.

What is the business value in closing the security competency gap?

Much of the conversation about Agile development revolves around low-level, project-related work. Even in the early days, when the ‘Agile Manifesto’ provided guidance on “…better ways of developing software,” the clear emphasis was on performing project-related activities to achieve goals and gain stakeholder satisfaction.

Since the release of the original manifesto, countless resources have expanded on the concept, offering practical advice, tools, and processes to advance the art to the point where it is viable in most organizations and enterprises. The topic is discussed at length in various media, conferences, and user groups. What is generally missing from this discussion, however, is the full-fledged integration of security into the Agile framework–at the program level.

Hence, the challenge for CIOs now is to start thinking at a much higher level. Regardless of the methodology chosen (Agile, Waterfall, or Hybrid), CIOs must now consider what essential services are needed by the business. Breaking this down further, they must identify which competencies are required to enable those essential services. Inevitably, some of those essential services will require security competencies within the IT business unit. This type of strategic thinking will enable CIOs to pick out low-hanging fruit, leveraging existing competencies to start delivering immediate value to the business.

If CIOs think they have to start from ground zero, there’s good news: NIST has developed NICE to help organizations consider the appropriate security competencies for their own work environments. Using this type of framework, CIOs can quickly identify which investments need to be made in order to build up a resilient security practice.

The solution: how to go from security policy to Agile execution

Once the security competencies have been built, it’s time to execute. The competencies must be used to build an Agile pipeline that incorporates security from the beginning.

The goal is to create a set of security requirements as early as possible. These requirements, however, must be repeatable and consistent. Reliance on head knowledge and expertise alone is a flawed strategy. A more consistent approach is to use clauses from security standards or frameworks that are auditable, such as ISO 27001 or NIST 800-53. Typically, these standards or frameworks use clauses like “shall” and “should,” to clearly identify the project and program-level actions.

CIOs should leverage these standards and frameworks by translating clauses into clear functional and non-functional security requirements based on the type of applications at hand. This translation can be done by cross-functional development and operations teams and helps to create a repository of well-known requirements for each type of application. Pushing related tasks into the Agile pipeline should be done with intentional traceability against the security requirements. This way, teams have a clear understanding of which security requirements have not been met prior to deployment.

The same logic applies to threat modeling: security threats that are identified should be traceable so that there is consistency in the threat modeling process. While traditional diagram-based threat models have value, they are inherently inconsistent; teams will get different results based on the level of experience and understanding of the entire system.

In the grand scheme

Focusing on Agile at the lowest level of project execution leaves a CIO vulnerable with no clear, strategic definition of those security competencies required to provide business value. Security competencies should provide greater resiliency and compliance, and they should help reduce overall business risk. Not having the right competencies translates into poor project level practices. Project teams can execute Agile efficiently, but they still may lack proper alignment to business goals, resulting in greater technical debt on the CIO and the organization.

Eventually, CIOs will need to take a more pragmatic approach by building an Agile practice that aligns from the strategy level right down to the project level.