Step By Step Guide: How to Use a Security Pattern

Introduction

This guide describes how to use and apply security patterns. It follows on from the previous guide for How To Write A Security Pattern.

If you have already read through the previous guide you may be now wondering;

  1. How do I initiate the use of security patterns in a project ?
  2. How do I determine the priority for controls and which to implement first ?
  3. How do I keep track all of these security controls in a project ?

The following sections within this guide will provide a walk through on how to address these tasks.

It’s not written as strictly as the previous step-by step guide for writing security patterns as there are far too many topics to cover. Instead, this describes considerations for security in project delivery and how security patterns can assist during project phases.

This guide does intentionally discuss aspects of security that go beyond just the use of security patterns. This is important to try and explain how these aspects fit together.

As best as possible, I’ve provided a list of references both within this document and at the end for continued reading. I’ll also look to continue expanding on various topics in blog posts and articles.

Before we get started on how to use security patterns, let’s quickly look at some fundamental concepts that we need to cover.

Agile Delivery

This document focuses on the inclusion on security patterns within Agile project delivery methodology. Whether you love or hate it, Agile remains a common methodology for product deployment within the industry.

It’s also where taking a traditional top-down approach to security architecture doesn’t align.

Agile is an iterative approach to deployment. The scope of security architecture is often constrained to only covering as much necessary to implement the next project increment.

In this guide we’ll look at how the use of security patterns is well adapted to Agile. We’ll make reference to a lot of Agile terminology, particularly for the phases and principles. If you’re not familiar with Agile, then I suggest some pre-reading. Atlassian maintains some great easy to read documentation if you would like to learn more.

Notably, there are several different variations in agile methodologies that exist today (e.g. Scrum, Lean, Kanban, Extreme Programming). We don’t cover each of these methodologies but we’ll look to reference some of them to highlight how security patterns can be used.

The use of security patterns is by no means exclusive to Agile. If you are looking at security patterns, but use a hybrid or top-down approach, then just treat patterns as any other design artefact.

Reference

Good Security is People, Process and Technology

Good security needs to take into account both people, process and technology. It forms the basis of any security framework within an organisation.

Security patterns are mostly focused on technology assets, but this shouldn’t discount the equal importance to addressing security for the people and process that enable them.

The example security patterns provide some generic notes to people and process, however when developing your own patterns ensure to factor these in, relevant to your organisation.

Shared Responsibility Model within Cloud Providers

As the adoption of cloud computing increases for many organisations, it’s important to relate the use of security patterns against the Shared Responsibility model.

When looking at how security patterns are applied across different service models, particularly for cloud providers (i.e. SaaS, PaaS, IaaS), the implementation of particular security controls needs to be mapped against who is responsible for that technology stack.

If you’re not familiar with this model, then I suggest some pre-reading. AWS and Azure maintain some great documentation if you would like to learn more.

Reference

Control Assurance

We discuss the need for ‘assurance’ frequently in this guide. If you’re not familiar with this term, it’s the process taken to validate the intended design matches what was implemented.

NIST provide the following definition as part of the NIST 800-53 Control Definitions.

Assurance is the measure of confidence that the system functionality is implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security and privacy requirements for the system—thus possessing the capability to accurately mediate and enforce established security and privacy policies.

Reference

Risk Appetite

Last but not least, be mindful that there’s no such thing as ‘zero risk’. Attempting to reach it for security requires offsetting other outcomes. In an ideal world there would be sufficient time and funding to work through everything required for security. Pragmatically however there is always constraints that must be factored in.

Risk appetite is best described as “the level of exposure an organization is willing to take” to achieve strategic objectives.

Knowing the risk appetite for your organisation is important to understand, as it will guide the priority and minimum benchmark of controls required.

Reference

Establishing Security Patterns within a Project

The methodology around developing security patterns is well adapted to the iterative nature of Agile. The use of standard taxonomies allows for incremental planning and enablement of controls within project sprints. Although there is still investment required up front to develop security patterns, the structure of the patterns allow for gradual implementation of security through product development.

Assigning priority to specific controls is done using a risk based approach, mapped against the security threats determined within the pattern.

Security patterns are ‘asset-centric’, which suits the Agile methodology that focusses on delivery for a defined set of products. Patterns can be bounded around the product scope for that the project, and in coordination with the product owner.

Security patterns can alternatively be scoped using a top-down enterprise architecture view. However security patterns are not dependant on it being in place.

If your organisation does maintain enterprise security architecture then incorporate it into the pattern as design requirements (where applicable). That said, attempting to build all possible security patterns using a traditional top-down approach would be time consuming and not recommended (as you’ll likely end up ‘boiling the ocean’).

The recommended approach is to initiate the design of a security pattern based on tangible requirements and scope associated to the project.

Planning For Architecture Within Agile

The overall inclusion of architecture will partly depend on which flavour of Agile your organisation is using. Some Agile frameworks will have well defined phases for the inclusion of architecture whereas others may leave it to evolve more organically during each sprint.

Security patterns are generally expected to be established within early project inception phase. Patterns should look to capture and factor requirements from:

Security patterns can also continue to be developed whilst the project continues through iterative sprints. If we look at the Scaled Agile framework as an example, it maintains clear phases for ‘Architecture Runway’ for this purpose. Using this framework as an example, the design or update of the security patterns could in parallel to sprint cycles.

Reference

Defining The Scope For the Pattern

Up front planning within inception phases of the project should identify the need and scope of the security patterns.

Security patterns start with defining a problem statement. That problem statement will likely be bounded around the project scope for the product.

Engage with Product Owner, Stakeholders and Management Team to assess the security relevant aspects of business requirements. This should also cater for understanding their concerns for risks that they may have identify.

Information collected in this step will help form the basis of the ‘Overview’ and ‘Typical Challenges’ within the Security Pattern.

T-Shirt sizes for Security Pattern

A popular method in Agile is using T-Shirt Sizes as a technique to estimated efforts for user stories and tasks.

Similar principles can be applied to estimating effort for building security patterns. We also can increase or reduce the estimated effort by modifying parts of the security pattern template and depth of analysis.

The actual estimates of effort will be different for everyone, based familiarity with the problem space, use of patterns and complexity. So please take the estimates provided purely as a guide for consideration rather than anything prescriptive.

Within the ‘How To Write A Security Pattern’ guide, we step through the process of constructing a security pattern. Most importantly in that process, we note the fundamental principles that make up a pattern.

  1. Asset centric design
  2. Analysis of the threats
  3. Traceability of threat modelling into security controls
  4. Standardised taxonomy

Below is broken into some variations to Security Pattern template, and how this may correspond to estimates via T-Shirt sizing. Again, this is only a guide for consideration and your actual estimates may differ.

Small Medium Large
Expected usage Lightweight design artefact for small product deployments Default security pattern process, as describe in ‘How-To-Write’ guide. Large enterprise initiatives or critical systems.
Threat Modelling Apply basic analysis using STRIDE threat modelling and map against applicable threats. Apply PASTA threat Modelling and Map against applicable Threats with descriptions Conduct full threat analysis using detailed threat modelling techniques such as ATT&CK CAPEC. Map against applicable threats with descriptions.
Solution Establish target state solution design and principles Establish target state solution design and principles Establish target state solution design and principles. Maintain traceability back to requirements.
Security Controls Map to generic NIST 800-53 Controls Map NIST 800-53 Controls and apply Customised Descriptions Map NIST 800-53 Enhanced Controls and apply customised descriptions
Timeframe to Develop Pattern 2-3 Days 5-7 Days 10+ Days

I recommended investing the effort up-front to building a formal security pattern. The ‘Medium’ T-Shirt size is the documented approach in the How-To-Write guide and should be considered the default position.

Example:

We going to continue with the same example from How-To-Write-Sec-Pattern and look at using the Source Code Management security pattern.

Let’s consider an example scenario to how the need and initiation of the pattern may have occurred.

An organisation may have several different instances of SCM in place across different divisions. This slows their ability for teams to effectively collaborate and a project is initiated to consolidate source code mgmt into a single enterprise platform.

The product owner is looking to address immediate challenges of allowing outsourced partners access and to contribute code. Code repositories are also being utilised across different hosting platforms for on-premise and cloud.

Engagement with project stakeholders also notes there is an immediate concern around outsource developers committing secrets to code. Further investigation with security operations teams note that several security incidents recorded relating to the exposure of secrets.

As such, there is an established need to write a security pattern for these challenges, bounded around the scope of Source Code Management.

Designing For Incremental Security

Now that our security patterns are established, let’s look at how these patterns can be broken into iterative sprints as part of product delivery.

The pattern defines the target state set of controls required for implementation. The iterative nature of agile means that those controls need to be broken into incremental tasks and positioned into backlogs for implementation.

This allows the security posture of the product to develop as the system also matures.

Incremental establishment of security controls support early and frequent delivery of software features required for the product as part of Agile.

The security pattern remains a working benchmark for the Scrum team which encapsulates the security features of the product.

Determining The Priority For Each Control

There will be lots of factors that will influence the priority of controls to be implemented. Determining which controls to prioritise first should always centred around mitigating risk. However other factors of influence may include,

There’s no magic formula for working out the right balance (arguable).

If you are stuck on where to start then here is some tips for pushing forward. As a default starting position, I’d recommend the following

  1. Use NIST.SP.800-53B Control Baselines - NIST publishes a supplementary document to the 800-53 control list that provides recommended priority for each individual control. The priorities assigned are generic but it’s a starting point to establish a baseline.
  2. Validate against risks within current state environment - Identify risks or predisposing conditions in the current environment for your organisation that may affect the likelihood and impact of identified threats. For the threats identified in the pattern, prioritise the security control associated to mitigating them.
  3. Conduct story board point estimates across proposed controls - Allow for input from the Scrum team to size and estimate effort required for implementation of controls. Also group ’like’ controls to help build out security stories for the team to estimate against.

Inclusion within Product Roadmaps

With the priority of controls now established, it needs to now be mapped into the product roadmap. For those controls that have higher priority, assign into early stages for product or architecture backlogs (pending which flavour of Agile your organisation is using).

Also look for any product features that may align to security controls identified. It shouldn’t distract from the priority already assigned to controls but it’s going to be much easier to deliver those controls when it’s aligned with the same priorities for the product.

Refactoring security is inherently difficult, so look to ensure implementation of security controls are clearly identified in product roadmaps and product backlogs as early as possible.

Example:

Based on the initial engagement with stakeholders, we subsequently discuss with security operations and risk management teams. We identify that leaked secrets from source code is a considerable risk for the organisation.

Looking at the security pattern, we note the following security threat specifically relates to leaked credentials from code.

TE-09: Accidental leaks or sharing of information due to human error or mishandling

For this specific threat, we note the following controls should now be given priority within the project.

The security pattern also maps that threat to the affected assets, so we look to coordinate the implementation of those controls within similar features listed in the product backlogs.

Sprint Planning

Engagement with Scrum Teams

It is necessary for the entire Scrum team to understand the approach and principles derived from the security patterns.

Patterns allow for knowledge transfer of the typical challenges and associated security threats identified. Subsequently, it allows each scrum team to evaluate the implications within their sprints. This may also trigger them to consider specifics to product design and refactor their tasks accordingly.

It’s equally important to promote awareness for the security controls required to mitigate against those threats. That said, attempting to communicate the entire pattern(s) to every team member will be a challenge.

For this reason, the ‘Design Principles’ within security patterns are intentionally kept as simple as possible to ensure they are easily communicated to everyone. At minimum, it provides an anchor for all team members to work against. Specialist within the team can then dive further into the details of the security pattern as needed.

Security designers are often shared across teams and with limited time. Security pattern are structured with this in mind to support information sharing and re-usability across multiple Scrum teams.

Establish Security-Focused User Stories

One popular method for establishing and validating security tasks within Agile is building security focussed stories as part of sprint planning.

Attending story board sessions between sprints provides the opportunity to contribute security specific user stories that reflect the priority of controls from the security patterns.

Scrum teams should work through the security controls to define backlog items and assign tasks associated to specific sprint cycles.

If you would like to understand more on this method, there are some working examples provide by SafeCode.

Reference

Using Security Personas

Defining personas is also another popular method in Agile. Creating security personas provides the opportunity for the Scrum teams to break down the security threats in context of their tasks and help them understand the intent for security design principles.

For example, defining personas like ’external attacker’, ‘malware developer’ or ‘malicious insider’ can help teams understand the motive and incentive behind security threats that could compromise their systems.

Reference

Delegation of security tasks within product teams

Before we jump into this topic, let’s quickly discuss the need for delegation.

Security professionals are often considered a ‘specialist’ role and typically required to operate as a shared resource across multiple Scrum teams. It’s a generalised statement and each organisation will operates with differences in team structures and competencies. But given that the industry need for security professionals continues to outgrow the security resources available, I expect this is the case for many people.

All of this only drives out the following outcomes for security professionals operating in fast paced delivery cycles.

Alternatively, a better approach is to look at how to leverage the teams to help deliver security outcomes in order to reduce strain on shared security resources.

Enabling Scrum teams to deliver also supports the principle within Agile. If we look at the success of the ‘Spotify Model’ as a popular adaption of Agile, one of the key fundamentals is too provide as much autonomy as possible to their people in order to help them pivot quickly.

Delegating greater autonomy to Scrum teams can often seem at odds with security. Particularly when considering the threat of rouge insiders or privileged users (usually a key concern to security). It’s a difficult balance to achieve, but an important one.

To address this, we utilise a ‘governance and guardrails’ approach in delegating implementation of different controls across different teams whilst still measuring it’s effectiveness (discussed further in next section).

Security patterns are well adapted for reuse across multiple teams and managing the delegation of specific controls. The guiding principles to the structure of Security Patterns are built with this in mind. As discussed previously, Security Patterns are

  1. Abstracted from specific vendor or technology implementation - Allowing Scrum team greater autonomy in selection of tooling and vendor products to implement specific controls.
  2. Standardise on the use of taxonomies to promote reusability - Allowing security resources shared across multiple Scrum teams to reuse the same patterns as required.

Using Governance and Guardrails

The phrase ‘governance and guardrails’ is used amongst cloud providers as a way of describing models that enable teams to utilise cloud services in their own way. The concepts behind this model are also adaptable to the use of security patterns for enabling teams to operate with greater autonomy.

The focus on ‘governance’ is to ensure oversight of controls delegated to each teams and how to have assurance of those controls being implemented correctly. Any controls delegated to teams for design and implementation will always have the requirement for governance.

As a broad statement, controls that are good candidates for establishing as guardrails will be

  1. Required to address ‘high risk’ threats
  2. Required for mitigating ‘Insider Threats’

Any controls that don’t fall with those categories are potential candidates for delegation. Effectively, controls required as guardrails are consider of high importance. Consider establishing these controls as a centralised security services or policies that can then be applied consistently to all teams.

Reference

Working within the shared responsibility models for cloud services

The shared responsibility model associated with cloud services means that some controls won’t be the responsibility of any Scrum team to design or implement. Some controls will be purely the responsibility of the cloud service provider to manage.

It’s important to remember that security pattern don’t change when consuming cloud services. This is even the case for utilising SaaS or Serverless that provide higher levels of abstraction of the underlying technology services.

What changes is determining which of the controls from the pattern are the responsibility of the cloud provider and how you gather assurance that the controls are sufficiently implemented.

Example:

With the scrum teams now in sprint planning, we schedule a brown bag session to inform the team of the security design principles for Source Code Management Security Pattern.

Design Principles

  1. Never store secrets in code or configuration
  2. Scan code for secrets and credentials during code commits
  3. Enable multi-factor authentication for contributors when available
  4. Validate any client or 3rd party applications requesting access
  5. Add security testing in your CI/CD pipelines to detect vulnerabilities
  6. Regularly rotate credentials such as SSH keys and access tokens used by developers
  7. Maintain clearly separated trust boundaries and access policies between Public and Private GIT repositories

The immediate set of priority controls from the Product Backlog are discussed and reviewed with the scrum team for upcoming Sprint. These controls are described within a user story format for the team to evaluate.

It’s noted that they team is still evaluating different vendor options for source code management including on-premise deployment of Atlassian BitBucket, AWS CodeCommit and GitHub.

Each option will have different considerations on the responsibilities of controls for those different hosting models.

Sprint Delivery and Testing

Product Prototyping

It’s common in Agile for teams to prototype different technology stacks. In fact, Agile encourages this experimentation in order to learn from success or failure. During prototyping, teams may look to assess several different technology vendors or service models as part of testing a potential solution.

Let’s consider a simple scenario where a team is evaluating deployment of their application within containers. They are assessing whether to deploy as (Option 1) self-managed container deployment on IaaS or (Option 2) to consume containers as a PaaS service offering.

Please note. The diagram uses AWS as an example, but this could be any similar PaaS offering from other cloud providers.

As described in the previous section, the security pattern remains the same in both cases. What changes is the responsibility of specific controls and the method of assurance to validate those controls are implemented.

Supporting prototyping or experimentation is challenging from a security perspective. Successful prototypes will likely evolve into formalised deployments during ongoing sprint iterations. Balancing the need for scrum teams to prototype with some controls but without requiring all of them to be implementation can be difficult.

As described in the previous section, use the priority list of controls in the backlog to work through a minimum set needed for the early iterations. Ensure the team understands the overall design principles for the security pattern and takes into consideration overall controls that need to be met in later iterations.

Attend post-sprint review sessions to continually revise with the team the other controls within Product Backlog required in future sprints.

Control Implementation

Most controls listed within security patterns will naturally be associated with a particular list of technology vendors or security services.

Even if the scrum team has been delegated responsibility for design and implementation of a control, there’s still a need for consulting and informing the right solution.

Ensure to provide advice and recommendations on the preferred mechanisms for implementing security controls in order to guide teams on the best outcomes.

Control Assurance

As described in the preliminary parts of this document, assurance is the process taken to validate the intended design of the security controls were implemented correctly.

Assurance is the measure of confidence that the controls are effective and operate as intended. It requires collecting artefacts, conducting interviews and reviewing test results as evidence to validate the controls.

This section is not an exhaustive review of the different procedures and options to conducting assurance, but that shouldn’t understate the importance of it.

The supplementary NIST SP 800-53A document also provides a fairly comprehensive breakdown of the different options for assessing control effectiveness. This includes listing artefacts expected and recommendations to assess each NIST control.

Reference

Gathering Evidence of Control Effectiveness

There’s a range of different methods that can be taken for gathering confidence for the effectiveness of a control. Some controls will be easier than others to assess an measure.

Where controls can be directly assessed through security testing than this is the optimal choice.

Other controls however can’t be as easily tested, particular for controls that are more dependent on process and people. This may require a combination of both documentation, interviews and test results to be assessed in order to have confidence in the effectiveness of the control.

Peer review of controls can be an option for assessing effectiveness. However, self-assessment of controls by the same team implementing them is not recommended. Allowing the team to ‘mark their own homework’ will never be reliable method for assurance.

It always difficult to assess the true effectiveness of the control. Refer back to the NIST SP 800-53A document if you’re stuck on how to measure a particular control.

Remember, good security is the combination of people, process and technology. Ensure that you consider all of these aspects when measuring control effectiveness.

Gathering Evidence within Shared Responsibility Models

As mentioned previously, use of cloud services doesn’t change the design of the security pattern, just the method to how you assess control effectiveness.

Assurance for controls that are the responsibility of the cloud provider requires a different approach then traditional testing methods.

Any controls considered as a shared responsibility will likely have some configuration that can be inspected or tested against.

Controls that are purely the responsibility of the cloud provider typically aren’t made available for direct inspection. Assurance for these controls is mostly reliant on 3rd party accreditation and assessment reports in order to gather confidence for correct implementation. This is particular the case for SaaS providers where most of the controls are likely combined as part of the overall service offering.

For these control, you’ll need to review accreditation reports (for example SOC2 Type 2 Reports). Based on the report details, map the relevant statements back to the objectives of the controls.

You won’t always be guaranteed to find all the information needed in 3rd party accreditation’s and you’ll likely need to engage with the cloud provider to understand more detail.

The most important point to make here, is understand the difference in mindset to assessing the controls implemented by cloud providers. You’re unlikely to be permitted access to directly test controls implemented by cloud providers, and will be reliant on accreditation of cloud services to industry standards.

Measuring Effectiveness Through Continuous Testing

Continuously measuring the effectiveness of a control though automation is ideal where controls have clear test cases and without too many variations to false=positives.

Centralising and automating control assessments reduces the cost and effort compared to manually conducting assessments across each team. It also supports the ‘governance and guardrail’s’ approach to continually measure control effectiveness.

Given security patterns align to NIST, there are some good tools available that can be used for continuous testing and include mapping back to NIST. Automatically mapping those test results back to NIST controls is however a maturing area. Make sure to place consideration to the reliability and accuracy of test cases and how they map to assets.

Reference

So what happens when the control doesn’t work

You’re enviably going to find that despite all your efforts in designing controls, planning for implementation and engagement across the teams that controls haven’t been implemented or aren’t as effective as planned.

There’s a whole range of issues that will lead to this such as

As much as you want to pick up your chair and throw it against the wall, it’s not going to help fix the problem (not to mention career limiting).



So let’s look at how we deal with this.

Agile is built around failures in order to learn and improve on them. So equally, you need to anticipate success and failures in implementing security controls.

Controls that aren’t effective can be compensated with additional controls to reduce the overall impact of the security threats.

This is one of the reasons why Security Patterns maintain traceability back to the original threats that they are mitigating. When a particular control is identified as not being effective, then you’re able to come back to the security pattern to identify the compensating controls associated to those threats.

If this doesn’t help, then NIST SP 800-53 also provides generic recommendations to alternative controls under ‘related controls’ that you can utilise.

Where a sprint or iteration doesn’t deliver the control objective, then place implementation of compensating controls back into the sprint or product backlog.

Incomplete controls are recorded and tracked as ‘Technical Debt’ (or potentially ‘Security Debt’) within the Agile program. These controls require replanning before then being placed back into product or sprint backlogs.

It’s important that incomplete or ineffective implementation of controls during sprints are tracked, as it may also form the basis of subsequent risk assessments.

Example:

The team commences prototyping different options for technology vendors and service models to identify what works best. As part of this, the security controls identified as a priority are also tested. The team also assesses each option’s overall ability to address the controls required from the security pattern.

The team selects BitBucket deployed on AWS EC2 instances (IaaS) and continues to mature the current deployment in a Development environment.

In later Sprint iterations, the solution evolves and is deployed into a formal Non-Production environment. Additional controls are also implemented during these iterations.

For those controls implemented, we look to now validate control effectiveness. Some controls are easier than other to test.

Control SC-08: Transmission Confidentiality and Integrity is one of those examples, that can be easily validated through vulnerability scans and analysing flow logs.

Other controls however require more manual assessment.

Control SC-32: System Partitioning is one of those examples, that may require assessment of multiple artefacts such as

  1. Review of as-is design artefacts or configurations associated to the control implementation.
  2. Interview developers or administrators on implementation of the controls.
  3. Conducting guided test cases to interpret the outcomes from those results.

During testing, it’s identified that Control SI-03: Malicious Code Protection is not correctly configured and disabled previous Sprints.

The delta requirements for improving this control is placed back into the backlog and tracked as technical debt in the project.

Product Release

Determining the baseline of controls required for product release and ‘Definition of Done’ fundamentally comes back to risk appetite for your organisation.

Balancing risk versus reward is no perfect science. Where risks are identified and require acceptance then it’s a decision that needs to be presented back to the program stakeholders.

The end of sprint review prior to product release should conduct an assessment of outstanding risks. For those controls not yet implemented or ineffective then these will need to be assessed as part of the security posture for the product.

Calculating risk is a methodology in itself and it’s something I’ll look to cover in detail. Most organisations will have their own risk management processes and benchmarks which will determine the evaluation process.

When conducting the assessment, keep in mind that the principles to defence in depth in security also means that there should be several controls in place to mitigate any particular threat.

Not having one particular control implemented shouldn’t immediately result in high risk, as there should already be other additional controls (as part of a defence in depth approach) to compensates and reduce risk.

The Agile project should ensure that business stakeholder are informed of risk posture for the product and known risks for releases into Production. At minimum, make sure the risks associated to security are formally documented and recorded under risk management.

Example:

We’re not at the final stages of the project and preparing to release the solution into Production to allow developers to migrate.

The project has only implemented 80% of the controls originally planned for within the security pattern, with a number of those controls considered semi-effective in achieving the expected outcome.

On particular control that was never correctly remediated was SI-03: Malicious Code Protection due to some incompatibilities for particular version. The Product Owner needs to continue release of this solution to meet project timelines and you’ve been asked to evaluate the residual risks for not having these controls.

To assist with the assessment, we refer back to the original pattern to where this control was required. We identify the following compensating controls that assist mitigation of that original threat.


Although these controls don’t remove the risk, it does assist in reducing the likelihood and impact. Additional artefacts for security testing also provide confidence in the security posture of the solution to reduce the associated risk.

The resulting assessment for residual risk is presented back to program stakeholders to determine a decision (ultimately based on appetite for risk).

Conclusion

We’ve discussed a lot of the considerations to using security patterns, with a particular focus to Agile. As mentioned at the start, the use of security patterns is not exclusive to Agile, but it’s where I believe they show the most value.

The final note to make in this guide is understand that Security Patterns are a benchmark to the controls required to protect assets. Chances are you will never actually implement all of them. The objective of security patterns is to provide a process to incrementally applying controls to mitigate security threats (knowing that you’ll never completely eliminate them).

You’ll constantly need to re-adjust, re-plan and re-prioritise controls over time to address changes in the threat landscape. Other factors, such as the pace of change within cloud providers, also means that organisations will continue to pivot to newer technology stacks or service offerings.

Security Patterns are intended to provide that common benchmark over time. Patterns need to be kept updated over time but require less frequency in change.

There is a level of effort and investment needed for writing security patterns. Hopefully this guide has demonstrated the value of that investment.

Browse the existing example Security Patterns that are available including the Source Code Management security pattern discussed in this guide.

About Us

The content on securitypatterns.io is provided as open material and free of charge under creative commons license for non-commerical purposes.

Please provide your support by posting comments or following me on Twitter and LinkedIn if you’ve enjoyed reading and want to stay up to date.

Further Reading