“When you present your business case, make sure that you identify the specific business problems in your organisation that will be addressed through your security architecture, and explain in business language how the solutions will bring specific business benefits”

Sherwood, Clark and Lynas

2 Strategy & planning

2.1 A Short Introduction into DevOps

Development + Operations = DevOps

DevOps is best described as a set of practices to optimize development and operations, representing a convergence of various managerial and philosophical concepts (Kim et al., 2016 pp34).

DevOps is also described as a cross-functional way of working (Wikipedia, 2021) across and within teams to optimize development and delivery.

DevOps started as a cultural shift aimed at streamlining intergroup communication and improving operational efficiency, “it’s about building the culture and providing value to an organization” (Fayer, 2019, pp6)

Founding DevOps leaders describe DevOps as the result of applying Lean principals and The Agile Manifesto to technology value streams, they generally agree that DevOps is a logical continuation of the Agile journey (Kim et al., 2016, pp34)

Whichever the definition preferred, DevOps empowers developers with the systems and information necessary to quickly build, test, deploy and operate business driven changes, by removing wastage from the business value chain.

Famously controversial concepts such as developers being able to release and manage their code in production without waiting for the typical change management and formal sign-off phases in classical model are core tenets of DevOps, often making it difficult to establish in more traditional organisations (Slade, 2021).

Forbes claimed six years ago that every company is a technology company (Forbes 2014). As controversial as it still sounds, the fact remains that high performing companies are using DevOps to successfully out-perform their more traditional peers (Kim et al., 2016, pp26).

Gene Kim (et al.) postulate that through DevOps entire start-up companies could be created in weeks (Kim et al., 2016, pp16), so it’s clear that security architecture must also be able to function at this speed, and if not, it risks becoming a bottleneck in the organisation’s flow – adding wastage in the organisations value chain.

2.2 The Three Ways & SABSA

The DevOps methodology, outlined by Gene Kim (at al.) in the book The DevOps Handbook and The Phoenix Project, promotes the “Three ways” that modern organisations can harness the productivity that DevOps can bring to the software development lifecycle in an organisation (Kim et al., 2016).

The Three Ways is comprised of three key areas; Flow, Feedback and Continuous improvement and together these three terms classify the core concepts behind DevOps practices.

DevOps can also be classified using the DevOps CAMS principals of Culture, Automation, Measurement and Sharing (Fayer, 2019, pp6).

Both classification methodologies highlight the many linkages evident when comparing the core concepts behind DevOps and SABSA Enterprise Security Architecture.

Figure 1 Comparing DevOps and SABSA core concepts

Flow – SABSA and DevOps methodologies work toward eliminating waste from value chains by being business focussed.

Feedback – SABSA specialises in performance targets for monitoring and alerting processes, both SABSA and DevOps encourage these processes within feedback loops to provide continuous feedback to the organisation.

Continuous Improvement – SABSA drives the process of improvement throughout each iteration of the Risk Management Process lifecycle and DevOps drives continuous improvement through each iteration of inception to market.

Both SABSA and DevOps focus on the effective and economical management of risk in the organisation. DevOps applies its focus directly to the development-operations process whereas SABSA is typically applied to an organisation’s information security architecture.

Dr Senge indicates that these feedback loops are a key ingredient to systems thinking (Kim et al., 2016, pp29) so it seems obvious that security architecture assessments must also be integrated into the rapid feedback loops that DevOps prescribes.

DevOps requirement for such a rapid turn-around of the feed-back loop, further suggests that that the risk assessment process should be automated to provide immediate benefit to the organisation.

With an automated security assessment integrated into the DevOps pipeline, the benefits for the organisation would be in the provision of assurance that the business products (software code) meet architecture requirements within minutes of a code commit. This would effectively minimise the wait and processing times to less than a few minutes before acceptable code is deployed into production.

Hsu suggests “the most effective and efficient way to implement secure coding is to provide an easy-to-use tool for every developer—to be parts of his/her daily tasks” (Hsu, 2018).

While Static Analysis Security Testing (SAST) tools have been present within the market for over a decade (Koussa, 2018), few products are focussed on architecture assessment and they don’t leverage SABSA to provide critical traceability back to the organisation’s goals.

“Adopting [DevOps] principles in isolation will cause business goals and IT goals to become misaligned” (Fayer, 2019, pp4). SABSA’s business-driven nature and clear architectural rules make it a suitable candidate for integration into the DevOps environment to extend the pipeline to provide fast, automated and traceable security assessments aligned with business goals.

The assessment process would require significant inputs in the form of a populated relational data model, clearly defined security architecture requirements and a mechanism for detection and reporting of security architecture issues.

3 Design

3.1 The Three Ways – Flow

The first of the three ways, Flow, represents the ability of an organisation to understand the flow of value across the organisation. In the SABSA methodology this is represented by Business Value Chains located at the intersection of the Contextual layer and Process Domain in the SABSA Matrix.

Business value chains are composed of a set of activities that are performed to deliver a complete product. The value chains concept was instantiated by Michael Porter and is a decision support tool, developed from the study of physical manufacturing, to enable competitive advantage (Value Chain Analysis – Research-Methodology, 2015).

Revealing a similar pedigree in its Lean roots, DevOps also attempts to quantify the software development lifecycle in more physical terms, likening it to the sorts of physical manufacturing and assembly lines of large-scale equipment manufacturers.

Figure 2 High-level value chain

A high-level business value chain is built (figure 2) mapping how a business idea has value added from inception to market.

“Mapping can help you to collect and analyze data about the efficiency of individual steps and their value contribution to overall business outcomes” (Fayer, 2019, pp14). The value chain is a key representation of the organisation’s value so each component of the value chain needs to be further broken down to understand which sub components and value streams require optimization and protection.

Business value chains should be stored in a business value chain registry. The registry should be supported by formal management and training processes and document the chain owner and chain subcomponents. Channelling both DevOps and SABSA concepts, the registry should be published in such a way that the aggregated risk from affected value chain sub components can be determined.

3.1.1 Batch Sizes

Flow, also building on learnings from physical manufacturing environments, seeks to limit work in progress, preventing bottlenecks and optimizing batch sizing to limit wastage in the value chain (Kim et al., 2016, pp23)

Figure 3 Source: “Machine Learning and Technical Debt with D. Sculley,” Software Engineering Daily podcast, November 17, 2015, http://softwareengineeringdaily.com/2015/11/17/machinelearning-and-technical-debt-with-d-sculley/

The matrix (figure 3) describes how defects and technical debt remove value from the value chain. It also demonstrates that security architecture and other non-functional requirements are not visible to the user, so the value they add is in enabling the visible features and treating the defects.

In traditional models a product is assembled in large batches. These large batches sizes are expected to increase productivity through consolidating tasks performed because the setup time for each different task is minimised, however Kim (et al.) notes that in reality this tends to increase the amount of work in the work queue. DevOps frowns on long work queues because when work is in a queue it does not provide any value for the customer (figure 3) (Kim et al., 2016, pp20).
Large batch sizes and their increased work-in-progress waiting times threaten the capability to meet business time dependencies (Kim et al., 2016, pp41).

Time dependencies are a SABSA security artefact and are represented at the intersection of the SABSA contextual layer and time domain in the SABSA matrix.

Time dependencies are “time-related aspects of business security in terms of both performance and sequence (business transaction throughput, lifetimes and deadlines, just-in-time operations, time-to-market, etc.)” (Sherwood, Clark and Lynas, 2005, pp61).

These time dependencies are used in DevOps throughout the product lifecycle (lifetimes, cycle times, deadlines and inception-to-market) for new business products (software).

DevOps design patterns such as the Release Canary and Cluster Immune System implicitly rely on time dependencies as part of the monitoring system to determine if a solution needs to be partially deployed, automatically rolled back or fixed forward (Kim et al., 2016, pp197).

“Time is a critical metric of DevOps adoption” (Fayer, 2019, pp 15). For time dependencies to be effective they need to be managed in a register linked with risk owners and published to support the organisation’s value chain.

While there is awareness of the need for security to be involved in the early stages of the software development lifecycle in both SABSA and DevOps, in practice formal review and sign-off for bespoke developed business products against enterprise security architecture is typically only performed manually at the start and end of a project of major milestone.

Errors found in the earlier in the delivery process require less effort to remedy (Fayer, 2019, pp16). Conducting the security assessment late in the delivery process misses the opportunity to prevent defects being passed down stream (Kim et al., 2016, pp46) and by the end of the project the ability to economically catch and address any quality failures has passed (Kim et al., 2016, pp342).

In security architecture, batch sizes are relevant because the organisation needs continuous assurance that the business products developed by development teams meet the organisation’s security architecture requirements and batch sizes directly affect the speed and resources consumed in generating this assurance.

It is typical, in large waterfall-oriented organisations, for a security assessment report to run into the hundreds of pages listing the security issues found at the end of the development cycle. By their nature these reports are terse and often hard to process by developers. Small errors can cascade into voluminous documentation so assessing code changes in smaller batch sizes will improve the signal to noise ratio for developers.

In these large organisations development departments will typically seek ESA endorsement at the beginning and the end of a project (Kim et al., 2016, pp61). This essentially replicates the large batch size as the system is assessed only once all the components within the software application have been selected and integrated.

Because the development is complete, there are many lines of code and code dependencies to review and the security assessment process becomes significantly more time and resource consuming. “our ability to meaningfully critique code changes goes down as the change size goes up” (Kim et al., 2016, pp288).

This time-consuming pain-point increases business value chain waste in the form of wait time as the whole organisation waits for the enterprise security architecture team to review and accredit the product for use (Kim et al., 2016, pp96)

This wait time is a wastage as this is precious time that the customer could consuming the product and the wait itself adds no value to the end product (figure 3).

Small batch sizes can be seen as a control to reduce work-in-progress queues and also present an opportunity for the organisation’s security architecture.

By adopting the smaller batch size concept for enterprise security architecture assessments, the organisation can potentially afford to resource more frequent and detailed assessments of bespoke business products against enterprise architecture requirements.

Where a breach of requirements is found, action can be taken to repair the problem earlier in the development lifecycle saving significant costs.

The problem is outlined by Justin Arbuckle, formerly the chief architect at GE Capital “When it came to information security and compliance, we found that blockages at the end of the project were much more expensive than at the beginning—and Infosec blockages were among the worst” (Kim et al., 2016, pp342).

This example demonstrates how smaller batch sizes decrease wait times, increase the opportunity for continuous security assurance and ultimately increase value for the customer.

As a result of this research, it’s clear that to extend DevOps with SABSA, security assurance reviews (part of the SABSA risk management process lifecycle) are required throughout the development lifecycle rather than at the start and end of a project.

3.1.2 Handoffs

Flow also discusses reducing the number of handoffs. Handoffs occur when one team hands work over to another team for processing. In modern organisations this can involve considerable wait while the receiving team schedules the resources necessary to complete the processing task (Kim et al., 2016, pp52).

Handoffs often reduce the context for the receiving team who may not receive all the information necessary to conduct their process or may not even understand the relevance of their process in context with the previous process. As discussed in The DevOps Handbook, when handoffs occur without the required information supplied, they can be passed between teams multiple times before all the information is assembled to allow processing. These hand-offs and wait-times considerably increase wastage in the value chain (Kim et al., 2016, pp55).

DevOps promotes daily code commits, early and often. Adopting the principal of small-batch-size assessments for security architecture means the number of handoffs to enterprise architecture for security assessment and accreditation would be increased!

Hsu suggests that this rapid release cycle is both an opportunity and a challenge to security. “The challenge is that a short period of frequent releases may not include enough time to do a full cycle of security testing” (Hsu, 2018)

This is an example of systemic risk being introduced as an unwanted by-product of the introduction of an ‘unrelated’ control, however it is expected that the employment of automation provides an effective counter-measure.

Kim (at al.) suggests that as developers channel Agile practices to create user stories, Operations can create Ops-stories that “represent work activities that can be reused across all our projects” (Kim et al., 2016, pp325). SABSA also seeks to develop reusable components “to provide generic, re-usable, modular approaches to the construction of new infrastructure and applications” (Sherwood, Clark and Lynas, 2005, pp147). These reusable components enable automation to reduce hand-off and wastage in the value chain.

Automation is also key contributor to decreasing handoffs and a key counter measure for the increased number of hand-offs created by the smaller batch-sizes (Kim et al., 2016, pp143).

Automation decreases wait times and human error by allowing teams to execute processes in other domains safely without having to log jobs and wait in queues.

Automation and reduced team dependencies are key DevOps ingredients necessary to decrease the number of handoffs and resulting wasted time, optimizing the value chain. (Kim et al., 2016, pp53)

Kim (et al.) also state that requiring another team to complete “tedious, error-prone and manual tasks that could be automated” is a key example of an ineffective quality controls. (Kim et al., 2016, pp54)

With the approach confirmed by Hsu, “The best approach is also to provide related automation security tools to do the job” (Hsu, 2018), Fayer suggests an organisation could expect a reduction in errors of at least 22% (Fayer, 2019, pp17). It’s clearly important that the development process has the self-service automation capability to be able to safely publish products that have passed the required quality control assessments.

Optimization of business value chains, in this instance through the removal of wastage in the form of manual tasks, is a key success factor driver for a high performing enterprise security architecture.

3.2 The Three Ways – Feedback

The second way, Feedback, describes how to provide the appropriate level of feedback to the organisation’s development process.

SABSA encourages feedback throughout the risk management lifecycle, each phase provides input to the next phase and the final phase provides the input for the next iteration (Sherwood, Clark and Lynas, 2005, pp505).

A key requirement for the feedback loop is detailed feedback. If feedback information is incomplete it may not provide the required telemetry to support continuous improvement. (Skelton and Pais, 2019)

Through continuous improvement, DevOps encourages monitoring of systems to generate this telemetry to measure systems status and health (Kim et al., 2016, pp223)

This is a linkage between the DevOps and SABSA knowledge domains because SABSA also prescribes the use of telemetry and further suggests the use performance thresholds to measure and provide early warning of changing risk.

3.2.1 OODA

DevOps encourages rapid feedback loops so that developers can immediately begin to measure the effectiveness of changes to products. The faster these feedback loops can be executed and more changes that can be managed successfully, the more value is built into the product.

To that end DevOps bears all the hallmarks of John Boyd’s OODA loop which is, as John Boyd summarised in a lecture named Patterns of Conflict from the mid-1980’s, focussed on executing feedback loops quicker than the competition (Patterns of Conflict, 2007).

Adam Bowen, Innovation lead at Delphic explains that DevOps “speeds OODA Loops by automating the many numerous touch points that are required in software delivery: support desk, infrastructure” (Bowen, 2016).

However, on its own this statement doesn’t go a long way to explaining that DevOps amplifies the feedback loop to drive more experiments (A/B testing) and measure the results (Kim et al., 2016, pp278).

If OODA loops are a technique to out-manoeuvre the enemy, then DevOps is a technique to out-deliver the competition.

DevOps enabled organisations are able to form many more hypothesis about their business products and conduct the experimentation necessary to validate hypothesis to update functionality faster than their competitors (Kim et al., 2016, pp273), “identifying which ideas don’t work and reinforcing those that do” (Kim et al., 2016, pp68)

As a result, it is clear that enterprise architectural processes need to provide the level of feedback detail required by development teams to understand the results of experimentation.

DevOps encourages rapid feedback to developers, maintaining the developer’s context and ensuring a quicker resolution to the problem. This rapid feedback allows developers to see the results of the changes they make in near real-time.

Kim (at al.) detail examples where developers may submit a change and then may begin working on another project before any assessment report is generated. Depending on how long it takes the developer will then need to switch back to the original change and re-understand the problem again to resolve any issues. This context switching costs valuable time and adds wastage to the business value chain (Kim et al., 2016, pp49).

Slow feedback doesn’t just add wasted time to the value chain, Dr Senge indicates an absence of feedback is a key contributor to significant quality and safety problems (Kim et al., 2016 pp29), both of which are significant risks to the organisation’s business value chains.

Feedback forms an important part of the control loop concept explored by Sherwood, Clark and Lynas in Enterprise Security Architecture A Business-Driven Approach, “This control loop concept is of critical importance in managing the security of a business system” (Sherwood, Clark and Lynas, 2005, pp86)

Feedback also lets development teams understand the context of the changes they are making and through the SABSA principals and benefits, see how these changes support the organisations over-all mission.

Kim (et al.) suggests that pushing quality closer to the source is a key component to decreasing the time it takes to produce working products that meet the business specifications. (Kim et al., 2016, pp32)

Hsu suggests organisational specifications and guidelines won’t be effective if they are not integrated into daily DevOps tasks (Hsu, 2018), so it is recommended that these enterprise architecture assessments be incorporated into an automated feedback process to provide feedback on developer changes soon after they make a change so that cycle times (the time from commit to production deployment) can be measured in minutes (Kim et al., 2016, pp42).

Automated feedback on compliance with architectural security requirements may provide significant benefit for organisations where the security team does not reside in the same location as the development teams. In this instance the organisation will typically see additional wastage in the business value chain as developers need to wait for feedback submitted from different time zones, further impacting the time between when the developer requests an assessment and when the developer receives the results.

Kim (et al.) discuss the ability to raise awareness when these business time dependencies or quality requirements are breached. The Andon cord was a physical implementation of Jidoka (Wikipedia, Andon (manufacturing), 2020), a method to shut down the production line in the Toyota manufacturing plant. When the manufacturing process exceeded a specific time or quality dependency the line could be shut down and so that solutions experts could swarm the problem (Kim et al., 2016, pp62).

Clearly when a developer contributes changes that are not compliant with the organisations enterprise security architecture the system should automatically pull the Andon cord and shut down the build pipeline.

The developer who broke the build can then receive specialist advice by email (Appendix 5) in the form of a report from the enterprise security architecture team regarding the problem that broke the build and how to fix it (Appendix 2).

The report will also allow architects and free developers to “swarm” the problem (Kim et al., 2016 pp61) and restore the build by either fix-forward (accept and update architecture) or roll-back the change to be compliant with the architecture once more.

3.3 The Three Ways – Continuous improvement

DevOps’ “The third way” is continuous improvement. Continuous improvement seeks to channel the telemetry as feedback into the decision-making process in a similar fashion to the SABSA control system concept (Sherwood, Clark and Lynas, 2005, pp597) forming another linkage between the two methodologies.

DevOps advocates the rapid execution frequency of the feedback loop. The feedback loop consists of an experiment containing a hypothesis, A-B testing and (hopefully) ends with a global core functionality update. “The teams keep repeating and iterating, using any new learnings to inform the next experiments.” (Kim et al., 2016 pp 97)

SABSA’s risk management lifecycle channels these feedback loops to develop continuous improvement at an enterprise level, but the concepts are wholly compatible no matter what layer of the organisation they are applied at.

Feedback allows the developer to associate the problem with the change and because they are using a small batch size (i.e., branching and committing daily) understanding the problem and fixing the change does invoke any context loss for the developer responsible.

This feedback should be used as a way for the whole organisation to grow (Kim et al., 2016 pp44) so it is requirement that reports should be stored and used for global understanding not just for the developer.

3.3.1 Continuous Architecture

Architecture needs to stay current and so analysis of multiple security assessments against the organisational architecture can show trends or patterns that form vital inputs to keeping the organisations architecture capable and current.

Because architecture is not static and requires management and review, it is necessary to have processes to manage and update the enterprise security architecture regularly using the results of this operational feedback.

Sherwood Clark and Lynas propose that “All business information must be integrated and shared across all functional departments and applications, moving towards a truly knowledge-driven business;” (Sherwood, Clark and Lynas, 2005, pp200) Thus, it is critical that the results of security assessments be available not only for assurance purposes but to drive a knowledge sharing within the organisation.

3.3.2 Architectural Test Coverage

It is expected that the organisation will update and increase the number of assessment rules over time.

Kim (at al.) recommends a slow but steady approach to growing the number of automated tests that an organisation can run it its development pipeline. It’s recommended to start with only a small number of architectural tests that can be managed and scaled up, as the organisations skills mature.

As Mike Bland, previous head of the Testing Grouplet at Google, put it “Level 1 was to quickly establish a baseline metric, Level 2 was setting a policy and reaching an automated test coverage goal, and Level 3 was striving towards a long-term coverage goal.” (Kim et al., 2016, pp337).

3.3.2.1 Content versioning systems

In DevOps, content versioning plays a significant role in supporting the continuous improvement of software, environments and their supporting processes.

While most organisations use Content Versioning Systems (CVS) for records, documents and bespoke source code, DevOps prescribes the use of CVS for all assets involved in the development, deployment and operation of the business including configuration processes required to build new development, integration, test and production environments.

Kim (et al.) explains “there are orders of magnitude more configurable settings in our environment than in our code. Consequently, it is the environment that needs to be in version control the most” (Kim et al., 2016, pp146).

Extending these DevOps practices with SABSA value suggests that not only should the enterprise architecture artefacts (documents, repositories etc) be stored in CVS, but also the supporting management processes, as they are also part of the environment.

Clearly, enterprise security architecture (and supporting processes) needs to be in a structured format that can and is, stored and managed, within a content version system.

3.3.2.1.1 Opportunity

As SABSA artefacts can be stored in version control provided by the DevOps environment this version control also provides an opportunity in the form of a potential integration hook to assess source code for compliance. As Hse suggests, in Hands-On Security in DevOps, the DevOps Continuous Integration, Continuous Delivery (CI/CD) pipeline is the most effective way to add security practices to the organisations existing development processes (Hsu, 2018).

By harnessing the source control services typically provided in a DevOps environment enterprise security architecture teams could integrate with development teams through the version control service Application Programming Interfaces (APIs) to provide frequent review.

3.3.3 Governance

DevOps typically works against corporate boundaries and organisational structures to create cross-skilled teams with full accountability for their actions (Wikipedia (DevOps), 2021).

Figure 4 An extract of the organisation’s structure, In this modelling technique blue boxes represent roles focussed on in this paper

“One of the goals of DevOps culture is to help eliminate siloed structure” (Fayer, 2019, pp7). The organisation’s position structure (figure 4) distinguishes the importance the organisation places on business product development by mandating that the DevOps Team Managers report directly to the Chief Operations Officer.

Fayer proposes that “DevOps is about a culture shift” and for a successful enablement, the organisation’s structure should reflect that shift (Fayer, 2019, pp20).

Each DevOps team is comprised of Operations, Development, Architecture, Support and Security Officers. “Trusting individual groups and departments to make local decisions in support of an umbrella strategy shortens feedback cycles, reduces the human resources, and keeps the decision in the hands of experts” (Fayer, 2019, pp21).

While many individuals may have broad skill sets across the technology stack (full stack developers) many other team members will have specialties that are used in the development and operation of bespoke business solutions. Together these different roles (recorded in a JDF and managed by HR) will support the diverse set of skills necessary to support rapid business product experimentation and innovation.

The organisation’s “reverse Conway” (Skelton and Pais, 2019) structure leverages Conway’s law. Conway’s Law states that “organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. The larger an organization is, the less flexibility it has and the more pronounced the phenomenon” (Kim et al., 2016, pp107).

Conway’s law describes how the organisation structure can influence the systems being designed. As a result, the organisation formed two “Two Pizza” DevOps teams (Denning, 2019) that perform business product development. These small teams of a dozen officers ensure the team has the appropriate resources and skills, a shared understanding of the project, limits development sprawl, enables autonomy and provides leadership and training (Kim et al., 2016, pp120).

Traditional organisational structures, with separate development and operational teams, usually operate as separate knowledge silos and fiefdoms where each team reports to a separate manager with different KPIs and objectives (Kim et al., 2016 pp115). Analysis of these fiefdoms shows these silos can contribute to the “Downward Spiral” where organisations collapse under the weight of their own technical debt (Kim et al., 2016, pp20).

This is because traditional organisational structures aren’t typically flexible enough to support the rapid creation and (and disbandment) of project groups questing for business product functionality.

Skelton and Pais agree, “Organizations that rely too heavily on org charts and matrixes to split and control work often fail to create the necessary conditions to embrace innovation”. (Skelton and Pais, 2019)

3.3.3.1 DevOps and Domain Models

The organisations enterprise security domain framework models the organisation’s risk domains (figure 5). These risk domains include customers, hardware manufacturers and software component manufacturers in the organisation’s greater enterprise. The domain modelling language mandates formal rules for domain models which in turn demonstrate how risk influences each domain.

A risk from a 3^rd party software component (figure 5) can influence the risk tolerances of the DevOps Team Manager beyond their risk appetite.

Figure 5 Depicts a situation where a software component available in the market introduces a risk to the attribute performance targets for the DevOps TP Team.

Zooming further into the organisation’s domain model (figure 6) demonstrates how the resulting risk performance is aggregated up through the model.

Figure 6 Mapping systemic flows of risk laterally to peer domains and vertically to parent domains

In this situation the increased risk against a DevOps manager’s attribute performance target is beyond the primary target (1).

This risk impact flows up to impact the Chief Operations Officer’s performance targets (2). If the impact on the COO’s target is within tolerance (less than the primary target) then the COO may choose to treat the increased risk. Risk treatment may include accepting, mitigating, transferring or avoiding the increased risk.

If the risk impact against the COO’s attribute targets is beyond the primary target then the risk flows to the Chief Executive Officer (CEO) (3) and the Chief Financial Officer (CFO) (5), potentially affecting the CEO and CFO’s attribute targets and presenting the same accept/mitigate/transfer/avoid treatment options. If the risk is not managed, it will in turn affect the board’s performance requirements (4).

Risk is also transferred to the peer domain, by way of influence on the Marketing Director’s performance targets (7). In this example the risk affects the Marketing Director’s attribute targets and if beyond the Marketing Director’s primary targets also affects the COO (8).

Figure 7 The domain modelling technique represents rules for the flow of risk appetite (down) and the aggregated risk performance (up). The thick line indicates the domain in scope.

SABSA domains work to group elements under common sets of security policies and SABSA domain models are useful to visualise the way that cross-functional DevOps teams work together.

The teams redefine separate development and operations teams into small autonomous, multi-skilled, multi-role, generalist teams with accountability for application development and operations.

These small teams have been proven to “improve flow by removing queues and wait time” in high-performing organisations (Kim et al., 2016 pp116).

Mathew skeleton describes several simple DevOps models in the book Team Topologies, but the visual format doesn’t describe the DevOps team autonomy and accountability except to define the overlap between development and operations. The SABSA domain model on the other hand, describes accountability, flows of risk appetite (down) and risk aggregation (up) and relationships between risk domains of the enterprise. These models clearly depict accountability establishing a clear view of responsibilities across the organisation.

In the SABSA domain model, each domain has a policy authority who owns and is accountable for the goals of that domain. SABSA uses attributes (proxy assets) to measure the effect of risk on these goals. Attributes are a normalised representation of goals. An attribute profile includes the performance target of the attribute. When risks are detailed (as a result of a strengths, weaknesses, opportunities and threats) the potential impact of these risks on the performance targets of the attribute are measured.

In this example the CEO’s goals and attributes set the risk appetite for the COO’s goals and attributes which in turn set the appetite for the DevOps TP Team #1 Manager’s goals and attributes. Attributes are assigned performance targets to measure the effect of risk on the domain in scope. This is an example of risk appetite flowing down through the domain model.

Within each DevOps team, each domain is fully accountable for carrying out their work. In their blog post, titled “DevOps: Using Agile’s Matrix”, SaintHax42 describes this accountability as “If a team is responsible for a task, other teams cannot dictate steps they must take to do it (outside of company guidelines, like security, CAB, etc, of course). A team is allowed to meet the needs of the downstream teams in whatever way they want” (DevOps: Using Agile’s RACI Matrix, 2020). SaintHax42 is of course describing the high levels of autonomy and accountability that DevOps teams operate with and this can be represented using a SABSA domain model.

Figure 8 details how a conflict in architecture is raised to the super domain for resolution

“A dedicated architecture team is usually a [DevOps] anti-pattern” (Skelton and Pais, 2019) so the organisation’s model places architecture teams within both DevOps teams.

This might prompt the reader to identify a situation where the two DevOps teams have employed conflicting architectures. In a DevOps environment, this is permitted as long as those separate architectures are optimized to support the business product development and any conflict (with standards) resolved by the patent domain. “Critical decisions [..] should not carry a decision-by-committee overhead” (Fayer, 2019, pp 21). The domain model (figure 8) describes the resolution where architectures are chosen that are conflicting – the incompatibility is resolved at the super domain (COO).

In this paper, the goals assessed and attributes presented belong to the DevOps TP Team #1. As the owner of the attributes, the DevOps TP Team #1 is accountable for the attribute performance and the ability to meet organisational goals.

3.3.3.2 DevOps and RACI models

Some DevOps advocates reject the use of RACI models in DevOps proposing that the two are incompatible because RACI models would typically be used to layer responsibilities for various parts of the organisations systems, whereas DevOps attempts to unify responsibility to make everyone in the team responsible. (Fellows, 2014)

Kim (et al.) agrees, “when we conflate deployment and release, it makes it difficult to create accountability for successful outcomes” and suggests that decoupling the two activities into a single team brings a shared responsibility (Kim et al., 2016, pp193).

However, SaintHax42 describes using RACIs within DevOps to manage constraints and bottlenecks in the delivery process. “After the RACI is filled in for a flow, you want to see what your constraint is doing [and] the next step is to protect your constraint” (DevOps: Using Agile’s RACI Matrix, 2020)

Figure 9 A value-chain based Extended RACI

While mapping flows into a RACI provides some insight into ownership and presence of constraints and bottlenecks (figure 9), these issues are not linked with organisational risk, making the accurate assessment of suitable treatments difficult if not technically impossible.

Figure 10 Introduces attributes to the RACI Matrix

The introduction of business attributes to the RACI table establishes the link to business risk and empowers developers with the authority and autonomy needed to rapidly develop quality products, because everyone can immediately trace the risk to organisational objectives, through SABSA traceability, helping DevOps officers understand theirs, and everyone else’s, responsibilities.

3.4 Summary

This research presented clearly demonstrates SABSA and DevOps share similar goals. The concepts of Flow, Feedback and Continuous improvement are wholly compatible with SABSA methodologies because they seek organisation growth through improvement and elimination of waste.

DevOps’ advocacy for extended monitoring telemetry and reporting, combined together with SABSA performance targets provides the fundamental granular data necessary for SABSA real-time risk dashboards, supporting improved decision support and increasing the organisation’s risk management maturity.

Figure 11 Architecture management console built to facilitate continuous improvement of architectural requirements

4 Conclusion

The timely delivery of an automated security assessment capable of positive and negative risk assessment, with the ability to prevent or publish a software change, reduces delays, increases assurance of compliance and increases developer knowledge through continuous learning.

This research has successfully demonstrated the extension of DevOps using SABSA techniques to provide the organisation the automated assurance that their software products meet organisational security requirements.

The software prototype developed clearly meets the quality and assurance requirements of the business by demonstrating the value added to the value chain from extending the DevOps pipeline with SABSA architecture.

The results of the extension of the DevOps pipeline with SABSA risk assessments led to additional benefits to the organisation classified through DevOps’ Flow, Feedback and Continuous Improvement;

4.1 Flow

The ability to automatically commission an assessment without requiring additional resources from architecture meets the DevOps requirement for less hand-offs and decreased wait time and benefits the business by minimising waste in the business value chain.

Regular testing with small batch-sizes of code changes demonstrated that when assessment is not passed, there is significantly less technical debt and code rework required.

One of the unique selling points of SABSA is that it has a scalable scope (SABSA Executive Summary – The SABSA Institute, 2020) and SABSA approaches include initial implementation of SABSA in a tightly scoped environment so that complexity doesn’t derail the implementation.

While the SABSA Methodology does not prescribe a batch-size per se, it’s of value to SABSA to feed the learnings and benefits of DevOps’ business time dependencies in terms of small batch-sizes back into the approach used for SABSA projects.

For example, smaller batch-sizes, even without the automation promoted in this paper, will optimize value in the organisation by fuelling more regular architectural assessments on smaller code-changes rather than attempting to assess the whole project at the beginning or end of the project or major milestone.

4.2 Feedback

The gatekeeper role of the build flag provides the business assurance that code that does not meet the requirements will not be released into production. This gives the organisation greater assurance that the organisations security requirements are met.

Extending the DevOps pipeline with SABSA provides valuable rapid and informative feedback loops to the DevOps teams. The speed at which developers can receive feedback greatly reduces wait-time and resultant value chain wastage.

The feedback generated by the automated reporting provides the developer with a comprehensive document describing the problems and solutions found as a result of their changes. The document is clearly written, includes a detailed dynamically built SABSA traceability diagram and includes a written description of this SABSA traceability to provide the reader the context to understand the issue. The value provided by the feedback means that the developer can immediately set about remediating problems and harnessing enablers. This increases organisational productivity and reduces wastage in the business value chain.

4.3 Continuous Improvement

In this paper the SABSA traceability report (Appendix 2) provides the linkages necessary for developers to understand how risk affects the organisations goals. As Hsu succinctly states in Hands-On Security in DevOps, “education should also support the goal” (Hsu, 2018). These educational linkages prompt continuous learning and improvement, helping developers meet organisational goals and objectives, by describing risk impact and providing the necessary wisdom through current and previous assessment reports (figure 36).

“Making security tools (threat modelling, secure coding, security framework) easy to use for developers is the key to shifting security to the left in the development cycle” (Hsu, 2018).

Figure 12 Reviewing previous assessment reports

DevOps methodology insists that all the components of the deployment pipeline are stored in content versioning systems to support automated deployment and operation of the pipeline. As discussed previously this should include the security architecture.

SABSA promotes regular review and management of architecture to maintain vitality and SABSA artefacts are usually stored in corporate knowledge systems, but synthesizing both DevOps and SABSA methodologies together shows that enterprise architectural artefacts and the supporting processes should also be stored within the same programming-oriented content versioning system used by developers.

Storage of the DevOps assessment tests and supporting SABSA architecture in the content versioning system means that the build pipeline, including the automated security assessment process can be rebuilt automatically, as and when needed, providing environments on-demand that are completely self-serviced. This benefits the business by significantly reducing hand-off to the enterprise architecture team to configure the assessment process in new environments reducing developer wait-time.

This idea seems a useful contribution to the SABSA framework, suggesting that architecture and supporting processes (where possible) to be stored in a way that is itself programmatically leverageable by DevOps automated environments.

This paper proves that an automated security assessment using SABSA traceability is possible and provides value to the organisation through the integration of the SABSA Framework into the modern DevOps environment.

The concepts were developed through a comparison of DevOps and SABSA methodologies, the design was built using information architecture leveraged to support both SABSA and DevOps. The prototype application was developed and implemented to prove the capability is possible. The result is a research paper with a prototype application that fully illustrates and validates the business benefits of the proposition.

Figure 13 Jenkins Build Timeline for the SABSA-ESA project

The console output in Appendix 4 demonstrates the real-time execution of the enterprise security architecture assessment.

The assessment report in Appendix 2 is the actual live result of the security assessment executing (figure 37) due to a code change committed to a project hosted on GitHub

A demonstration of this functionality can be arranged as part of the deliverables for this research paper. Please contact the author for further information.

5 Appendix 5 – Sample Email

A sample email is included to demonstrate how the enterprise architecture assessment report is delivered to the developer.

6 Bibliography

Kim, G., Debois, P., Willis, J., Humble, J. and Allspaw, J., 2016. The Devops Handbook. 1st ed. Portland, OR: IT Revolution Press.

Kim, G., Behr, K. and Spafford, G., 2018. The Phoenix Project, 5Th Anniversary Edition. Portland, OR: IT Revolution Press.

Skelton, M. and Pais, M., 2019. Team Topologies. 1st ed. Portland, OR: IT Revolution Press.

Sherwood, N., Clark, A. and Lynas, D., 2005. Enterprise Security Architecture. Boca Raton, FL: CRC Press.

Hsu, T., 2018. Hands-On Security in DevOps. Birmingham: Packt Publishing.

Fayer, L., 2019. DevOps and Business. Sebastopol, CA: O’Reilly Media Inc.

Malisow, B., Berti, J., Andrews, L. and Stoffell, K., 2018. (ISC)² CISSP certified information systems security professional official study guide. ISC2.

Agilemanifesto.org. 2001. Manifesto for Agile Software Development. [online] Available at: <https://agilemanifesto.org/iso/en/manifesto.html> [Accessed 10 January 2021].

Database Management. 2021. Database Entities In E/R Modeling. [online] Available at: <https://databasemanagement.fandom.com/wiki/Database_Entities_in_E/R_Modeling> [Accessed 10 January 2021].

Sixsigmadaily.com. 2021. [online] Available at: <https://www.sixsigmadaily.com/what-is-an-andon-cord/> [Accessed 10 January 2021].

Reddit.com. 2020. Devops: Using Agile’s RACI Matrix. [online] Available at: <https://www.reddit.com/r/devops/comments/jg9ss0/devops_using_agiles_raci_matrix/> [Accessed 12 January 2021].

Denning, S., 2019. How Amazon Became Agile. [online] Forbes. Available at: <https://www.forbes.com/sites/stevedenning/2019/06/02/how-amazon-became-agile/?sh=22c2124231aa> [Accessed 12 January 2021].

Fellows, M., 2014. Devops For The Enterprise: RACI Destroys Devops | Web, Apis & All Things Digital | Onegeek. [online] Onegeek.com.au. Available at: <http://www.onegeek.com.au/articles/devops-for-the-enterprise-raci-destroys-devops> [Accessed 12 January 2021].

Koussa, S., 2018. What Do SAST, DAST, IAST And RASP Mean To Developers?. [online] Softwaresecured.com. Available at: <https://www.softwaresecured.com/what-do-sast-dast-iast-and-rasp-mean-to-developers/> [Accessed 15 January 2021].

Smith, S., 2021. [online] Yourbusiness.azcentral.com. Available at: <https://yourbusiness.azcentral.com/ways-spreadsheets-used-business-3648.html> [Accessed 17 January 2021].

Bowen, A., 2016. Completing The OODA Loop Of Devops – Devops Online. [online] DevOps Online. Available at: <https://www.devopsonline.co.uk/completing-the-ooda-loop-of-devops/> [Accessed 17 January 2021].

Patterns of Conflict. 2007.

Directed by J. Boyd. Quantico, Virginia: USMC Archives.

Slade, R., 2021. Devops: Watch Out For These 5 Common Snags – Informationweek. [online] InformationWeek. Available at: <https://informationweek.com/devops/devops-watch-out-for-these-5-common-snags/a/d-id/1339818> [Accessed 17 January 2021].

Bartley, R., 2020. Use SABSA To Architect Your Iaas Cloud Security. [online] Gartner. Available at: <https://www.gartner.com/en/documents/3982900/use-sabsa-to-architect-your-iaas-cloud-security> [Accessed 17 January 2021].

En.wikipedia.org. 2021. Devops. [online] Available at: <https://en.wikipedia.org/wiki/DevOps> [Accessed 17 January 2021].

Research-Methodology. 2015. Value Chain Analysis – Research-Methodology. [online] Available at: <https://research-methodology.net/theory/strategy/value-chain-analysis-2/> [Accessed 17 January 2021].

En.wikipedia.org. 2020. Andon (Manufacturing). [online] Available at: <https://en.wikipedia.org/wiki/Andon_(manufacturing)> [Accessed 18 January 2021].

En.wikipedia.org. 2021. Regular Expression. [online] Available at: <https://en.wikipedia.org/wiki/Regular_expression> [Accessed 18 January 2021].

The SABSA Institute. 2020. SABSA Executive Summary – The SABSA Institute. [online] Available at: <https://sabsa.org/sabsa-executive-summary/> [Accessed 18 January 2021].

Gingrich, K., 2017. How TOGAF Complements Devops And Serves A Different Need. [online] Skillsoft. Available at: <https://www.skillsoft.com/blog/2017/05/how-togaf-complements-devops-and-serves-a-different-need> [Accessed 18 January 2021].

McNamee, K., 2018. Information model vs. data model – Software Superglue. [online] Blog.softwaresuperglue.com. Available at: <https://blog.softwaresuperglue.com/2018/11/09/information-model-vs-data-model/> [Accessed 30 January 2021].

SABSA and DevOps

1 Contents