Christopher Carlson

Christopher Carlson is a Certified Information System Security Professional and is Open FAIR™ Certified. He finished his 39-year career at the Boeing Company as an Associate Technical Fellow before establishing C.T. Carlson LLC to provide information security writings and advisory services. Management highlights at Boeing include leading the company-wide classified computing security program; 777 Program Security Manager; and Chief Security Officer for the sonic cruiser program, forerunner of the 787. Selected technical responsibilities at Boeing included defining requirements and leading implementation of a role-based access management system; introducing secure application development methods; system management of a governance, risk, and compliance system; and leading selection and implementation of a data security and insider threat detection system.

Anthony Carrato

Anthony Carrato is a long-time participant in The Open Group, dating back to the Open Software Foundation in the early 1990s. He was active in the early days of the Architecture Forum; a long-time co-chair of the Service-Oriented Architecture (SOA) Work Group and currently a member of the Steering Committee of the Security Forum. Tony, who retired from IBM in late 2019, is certified as a Distinguished IT Architect in The Open Group Professions program, and has 42 Acclaim badges overall. Tony is currently an Invited Expert of The Open Group Security Forum.

Altaz Valani

Altaz Valani, Director of Research at Security Compass, manages the overall research vision and team. He is a regular conference speaker who conducts ongoing research in the Software Security domain. Prior to joining Security Compass, he was a Senior Research Director and Executive Advisor at Info-Tech Research Group, Senior Manager at KPMG, as well as various positions working alongside senior stakeholders to drive business value through software development. He is a frequent collaborator within industry and academic circles on a wide range of topics related to governance, risk, cybersecurity, and software development. Altaz is currently serving as the Security Forum Vice-Chair.

ArchiMate, DirecNet, Making Standards Work, Open O logo, Open O and Check Certification logo, Platform 3.0, The Open Group, TOGAF, UNIX, UNIXWARE, and the Open Brand X logo are registered trademarks and Boundaryless Information Flow, Build with Integrity Buy with Confidence, Commercial Aviation Reference Architecture, Dependability Through Assuredness, Digital Practitioner Body of Knowledge, DPBoK, EMMM, FACE, the FACE logo, FHIM Profile Builder, the FHIM logo, FPB, Future Airborne Capability Environment, IT4IT, the IT4IT logo, O-AA, O-DEF, O-HERA, O-PAS, Open Agile Architecture, Open FAIR, Open Footprint, Open Process Automation, Open Subsurface Data Universe, Open Trusted Technology Provider, OSDU, Sensor Integration Simplified, SOSA, and the SOSA logo are trademarks of The Open Group.

All other brands, company, and product names are used for identification purposes only and may be trademarks that are the sole property of their respective owners.

(Please note affiliations were current at the time of approval.)

The Open Group gratefully acknowledges the contribution of the following people in the development of this document:

The Open Group gratefully acknowledges the following reviewers who participated in the Company Review of this document:

The following documents are referenced in this Guide.

(Please note that the links below are good at the time of writing but cannot be guaranteed for the future.)

The following documents supplement the contents in this Guide.

This document is the O-AA Security Playbook. It provides guidelines for addressing security in an Agile Architecture – to enable the business to move rapidly in a world of defined and managed risk. Security is a vast topic, and this document does not intend to fully address all IT security considerations for Agile Architectures, but instead offers an overview of the topic with links to additional information as needed. As such, the beginning of this document contains links to supplementary materials to provide detail about topics intentionally left brief. This document is intended to align with the Open Agile Architecture™ Standard [1] and to provide directions for further learning.

An architect designs architectures that manage business risk while enabling the business. They are responsible for the balanced and informed implementation of architectural controls that match the risk threshold set by business stakeholders.

A solution architect works to understand the business problem; design the overall solution; guide the development team(s) as they implement the solution; and, along with the business owner of the solution, provide overall governance for the solution development program. In an Agile program, architecture designs are delivered in chunks, which are often referred to as “sprints”. The solution architect provides overall technical guidance across the sprints.

A security architect supports product and solution architects by emphasizing security in the design.

An Agile security architect reframes the traditional security architect role in several ways:

An Agile security architect cannot work in isolation. They must integrate into the secure development lifecycle and support a continuous integration and continuous delivery model. This document does not suggest one form of Agile or iterative approach over another. Rather, this must be about achieving the right approach based on the organization’s risk threshold, culture, and readiness.

To fulfill the responsibilities named in the previous chapter, an Agile security architect must team with the business organization(s) responsible for risk management, as well as the functional users of the solution. These groups may include business partners or suppliers.

Because a technology-based solution requires infrastructure and operations support in addition to applications development, a security architect must also team with the providers of supporting capabilities; such as cloud providers, network providers, etc. In all cases, a security architect must understand the security capabilities of these providers and map any gaps to be addressed, as well as security requirements and guardrails within which the solution must fit based on policies defined by enterprise security teams.

Unfortunately, security architects are often a scarce commodity within an organization. One approach to expanding this capacity is to add a supplemental role of “security champion”. A security champion works within one or more solution programs to bring security expertise to the stream-aligned team, league, guild, tribe, etc. and to engage a security architect or product owner when required; therefore, a security champion should have at least a moderate level of security skills and knowledge.

An important responsibility of a security architect/champion is to help the development team(s) understand the risk profile of the solution and the existing enterprise security programs and tools, including any security guardrails which constrain choices in the solution. This should include providing the development team(s) with security education and consulting. If, for example, there are automated security testing tools available, the security architect/champion shall provide help in making use of them.

The security architect/champion must also help teams to understand and use existing security policies, practices, tools, etc. in projects. Instead of re-inventing the wheel every time, teams shall start with known, well-accepted policies, practices, tools, etc. – only developing additions if the existing policies, practices, tools, etc. are inadequate.

A specific responsibility of the security architect/champion is to ensure that development teams do not take the approach of “there will be time to make it secure in a later sprint”. This is a very dangerous path and one where security exposures are highly likely. Additionally, the security architect/champion must work with the scrum master to ensure that sufficient time, frequently a full sprint, is allocated for security testing and remediation in the sprint plan.

Finally, a security architect must be part of the technical governance of the architecture program, including participating in sprint reviews and reviews of architectural decisions and any major design changes.

In any organization, threats exploit vulnerabilities and result in asset losses. Security controls are used to reduce the probable Loss Event Frequency (LEF) – the probable frequency, within a given timeframe, that a threat agent will inflict harm upon an asset – and/or probable Loss Magnitude (LM) – the probable magnitude of loss resulting from a loss event – associated with information systems; see The Open Group Standard for Risk Taxonomy (O-RT) [2].

To create a business case for changes in an organization’s security controls (often called the security policy and ideally derived from information protection security standards), a quantitative risk analysis, such as that described by the Open FAIR™ risk analysis, should be utilized; if not using a quantitative risk analysis, there must still be a defined and consistent methodology for establishing and discussing risk to determine an organization’s appetite for risk and risk threshold.

Achieving this agility in security implies an emphasis on continuous evolution. Besides well-known solution architecture practices like scalability and decoupling, an Agile security architecture adds the following:

From the outset, architecting security assumes meeting the needs of various stakeholders. A layered approach shall be used to address distinct security issues, from the business domain down to the technical teams.

When creating a security architecture, measurable quality attributes are essential. The following represents a minimum set of questions that must be asked with each iteration of an Agile security architecture:

An Agile security architecture ultimately provides an ongoing business assurance that the proposed MSA will not introduce any new/additional risk. This is achieved by collaborating with other architects and seeing the gradual emergence of a set of security best practices housed in a Center of Excellence (CoE). This CoE can help create future security-hardened architecture templates that can be reused and can accelerate the creation and deployment of future systems.

As stated in the introduction, this document did not intend to fully address all IT security considerations for Agile Architectures, but instead offered an overview of the topic and provided links to supplementary materials to provide detail about topics intentionally left brief.

These topics, including the role of DevSecOps, governance of an Agile security architecture, and the role of an Agile security architect, may warrant additional publications in the future to more fully explain them.

Another area for future consideration is the impact of requirements from the Cybersecurity Maturity Model Certification (CMMC) [5].