Step By Step Guide: How to Write a Security Pattern

Introduction

In this guide, I’ll be walking through a step-by-step break down on How To Write A Security Pattern.

I’ve always struggled to find good resources that describe the process of building your own security architecture, in particular security patterns. There’s plenty of architecture frameworks out there which provide the general building blocks, but it’s always still left me stuck on where to get started and the process to how it’s applied.

This guide will step you through the process for constructing security patterns, provide a sample template for doing so and reference example patterns that you can use to adapt for your own purposes.

So what makes up a security pattern?

If you run a google search for ‘Security Patterns’, you’ll find the term is used fairly broadly, with a lot of different opinions to what a pattern should represent.

I don’t believe there is a ‘correct’ level of detail to what is considered a security pattern, as different designers will analyse problems at different levels. A security analyst may be primarily concerned with patterns relating to specific software coding whereas the enterprise security architecture may be primarily interested in trust relationships between the organisation and third parties.

That all said, fundamentally a security pattern represents a defined and re-usable solution to a recurring security problem.

Within this guide we define security patterns as design artefact that are

This guide is intended to be an opinionated view on how to write a security pattern. You may look to tweak or change parts of this process for your own needs and in fact, I encourage you to do so in parts of this guide.

Why develop a security pattern?

With increasing demand and speed of deployments within information technology industry, the need for smarter ways to develop security architecture and design is also increasing. Where 10 years ago deployment cycles were planned around quarterly or monthly releases, the industry continues to push for faster cycles.

In turn, any time and effort being placed into writing security architecture and design must support the creation of artefacts that are re-usable, adaptable and promote information sharing amongst fellow peers in order to keep pace.

This is where we look to use security patterns.

Arguable, we could turn to writing a security policy or standards for achieving the same outcomes that we look to provide with security patterns. However, I find using security standards problematic for the following reasons.

  1. Not maintaining the rationale to why specific controls are required. There’s lots of security standards that don’t include context to why these controls are required. Some standards may include the rationale within introductory notes, but this is typically at the discretion of the writer in regards to the level of detail provided and its relevance to the prescribed controls.

  2. Lack of traceability between security controls to the threats being mitigated. Not maintaining traceability to original threats and requirements becomes problematic when trying to later evaluate the residual risk of controls that cannot be met or implemented. This becomes an even greater challenge for standards that are written several years ago or by different stakeholders.

  3. Standards split into similar control groups, can become disconnected from each other. Standards are typically broken into groups of similar control sets with a set of motherhood statements to cover all applicable assets. This works fine in simple cases but problematic when trying to determine all of the controls required for protecting a specific asset.

In contrast, this guide for developing security patterns creates ‘asset centric’ designs that looks to maintain the linkage to how different controls complement each other to protect an asset. Patterns maintain traceability between the threat modelling and what controls required, rather than standards that can become just a tick box exercise on attempting to apply every possible control.

Most importantly, security patterns formulate designs that can be repeatably applied as the implementation of assets differ between different technology vendors, migrate into different hosting environments or utilised through different provider models.  

Let’s Get Started

The following pages will provide a walk-through of how to construct a security pattern.

Keep in mind during this process, that there is nothing stopping you from re-iterating back on previous steps when working through the sections. I’ve rarely been able to successfully write a security pattern from start to finish in just a single iteration so don’t be surprised if you need to come back to a previous step as your thinking matures and evolves. More often than not, I’ll go back to a particular section to tighten some of the definitions or the scope of the problem being addressed.

As stated earlier, this process is intended to be an opinionated view to how to write a security pattern. You may wish want to consider including additional steps to meet your specific requirements for your company or organisation.

Steps

  1. Identify the problem and scope

  2. Prepare and Research

  3. Identify the assets

  4. Threat Modelling

  5. Describe the target state solution

  6. Define and map security controls objectives

  7. Describe Security Pattern

  8. Summary and Conclusion

Let’s first look at the structure of a security pattern template

Structure of a Security Pattern

There are a few different elements to discuss here on how the structure has been put together in this guide. The steps will walk you through the usage but let’s firstly look at what is involved.  

Topic Description
Asset Centric Design There are a few different ways to model a security pattern, whether it be asset, service or process centric. This guide focuses on defining patterns against assets as opposed to other approaches. Assets within this guide are best defined as any technology platform and the logical functions or components within them.
Analysis of the threats Threat modelling is one of the most important (and challenging) steps in developing the patterns. It's easy to get a bit lost and wondering whether you've under or over cooked this analysis. The guide provides a process for stepping through it and tips for striking the right balance
Traceability of threat modelling into security controls The use of control objectives (rather than specifying the actual controls for a given technology stack) is a conscious decision within this guide to promote re-usability of the patterns. You may be tempted to jump in and just list out the specific controls relevant to your technology stack. Keep working through the pattern template and read through the sample use cases to how these patterns are utilised and how the investment into building a security pattern pays off in the long run.
Standardised taxonomy This guide standardises on the list of threats and controls used to promote traceability. The guide utilises Security Control Objectives published under NIST Special Publication 800-53 [1]. It also utilises its own standard list of Security Threats.

[1] This guide uses NIST Special Publication 800-53 (Rev. 5) Security Controls.

In the proceeding sections of this guide, I’ll provide reference how the security pattern for Source Code Management. It’s probably not the best example for demonstrating the value of security patterns but does simplify the example so that we can focus on the process to how it was developed.

Step 1 - Identify the problem space and scope

Ok, let’s take the first important step. Determine the problem space and scope to define what is the problem that you are trying to solve. This should fundamentally be key starting point for any work when writing security architecture.

There’s a lot of different initiatives that may trigger you to write a security pattern. Some examples include

Defining the problem statement should cover the following

Topic Description
Contain the scope to a single problem space. As best as possible, try to provide a concise summary of the problem that is being addressed by the pattern. This will help in later steps when focusing on which threats modelling will be used. The problem statement should not contain a lengthy discussion of the impacts or consequences, but a brief statement to what problem your trying to solve.
Describe the problem in context of the assets affected by it. You should start thinking about what type of assets are affected when describing the problem space. These represent the logical technology or entity being affected by the problem and will be the focus of both threat modelling and security controls being modelled.
Reference any historic use cases or examples for the described problem Although patterns are abstracted from technology stacks, I do find it helpful to include examples in this section that may directly reference issues to specific technology stacks. This helps keep the pattern grounded without get too abstracted from what you're analysing.

Additionally, you should start to identify the factors that will influence the design.
Topic Description
List any dependencies to developing the pattern. This should factor in any dependencies that may guide a particular solution within the pattern. This may include any relevant external Regulatory and Compliance requirements, requirements maybe extracted from a security strategy or from enterprise security reference architecture.
Describe any initial assumptions and constraints As for any design artefact, you should identify any overall assumptions and constraints to the problem space, which also may guide a particular solution. This should clarify the challenges of the problem and any trade-offs that must be considered.

If you don’t identify any specific items straight away then just keep pushing forward. You’ll likely come back to this section as your pattern evolves and thinking matures.

Example

Let’s look at building out our initial problem space for example use case which is source code management.

We build an initial problem statement is ‘How to ensure the protection of company developed source code from external and internal threats’. We’ll use this as the anchor for our scope in this pattern (although we may tune this statement later on to something more succinct.

In consider this problem space, there will be consideration needed to the cloning, branching and merging of those repositories. We’ll need to also consider the different users that may access these repositories whether they are internal users, partners or potentially public.

We also want to ensure that any code being published out to the public for information sharing is clearly separated from any code repositories being maintained as private.

Now let’s consider the assets. The most obvious assets to consider is the source code repository. But we also should consider other assets such as how that repository maybe replaced onto developer workstations or 3rd party applications that may look to connect to it.

For simplicity of the example, we’ll leave out considerations for any regulatory requirements. It would be at this point however that we may consider implications to regulatory standards such as SOX or PCI-DSS for source code management.

We draft up the following list

Step 2 - Prepare and Research

Now that you’ve formed an initial view to the problem space and the scope, you should start collating your notes.

Chances are, there’s already existing material or research available for reference. If not, then you may end up building out your own research and analysis.

Building out this research will form the basis of your threat modelling as well as an initial view of the controls required to address those threat.

Here’s some general tips for researching …

In collating your research, try and roughly break out your notes into three main topics

  1. Any examples for security threats, risks and/or vulnerabilities that relate to the assets (defined in Step 1)
  2. General notes on industry best practise and recommended solutions to addressing the problem space (defined in Step 1)
  3. Any recommended security control(s) that are anticipated for the pattern.

This step provides a way of collating and structuring your analysis. Keep in mind however that it can’t generate it for you. You need to spend time researching and understanding the problem space, so that you can break it apart.

Contain your research based on the original scope of the assets that you’re building the security pattern (so that you thinking doesn’t break away on too many tangents).

Example

Here’s a quick example (but not exhaustive) for researching source code management and considerations

In doing so we’ve identified the following types of threats and vulnerabilities to be used in the analysis, along with example controls recommended from vendors (again … this is not an exhaustive list)

  1. Security flaws within software code may be introduced at any stage of the software development lifecycle
  2. Exposure of private source code may lead to loss of intellectual property
  3. Sensitive information such as passwords, API keys, access tokens could be accidentally committed into a git repository and subsequently exposed to any user with read access.
  4. Source code management software can be vulnerable to remote code execution through manipulation of parameters and arguments in git commands.

Here’s an example for overall notes taken and broken into the 3 sections.

Step 3 - List out the specific assets

This is where you will start to develop the initial work done during Step 1 to define the assets. You’ll need to identify and characterise the different assets, and logically group these assets together.

There’s lots of ways to categorise an asset. Within these security patterns, we look to define an asset as technology system and services that are either

  1. Autonomous set of applications services or functions
  2. Discrete set of technology capabilities or components within a platform or system

Note: People or resources that interact with those systems are covered separately in this guide.

The following list is provided as an indicative list of different logical groups of assets that may exist. You’ll need to break down which specific assets from this list are affected within the define problem scope. This is not an exhaustive list and you’ll likely build out different sub-categories to these groups.

Further breaking down the asset list and any sub-layers can be done considering the different system components or resources. This includes the entry or exit points to those components.

Tip:

Example:

Within the scope of the problem statement, we’ve identified and categorised the following types of assets.  

Step 4 - Threat Modelling

This step will potentially be the most difficult section to complete in this guide but also the most important. Threat Modelling will allow you to create a more robust and well-rounded view of the security controls required to address the potential risks.

We should quickly divert a bit from the process to make mention that there are many different threat model methodologies that exist. Not all of them are the same, some are comprehensive whilst others are fairly abstract. Some methods focus specifically on risks or concerns whilst others will deep dive into particular vulnerabilities or flaws in a system.

I won’t step through an exhaustive discussion for all of the different models, but fundamentally there exists a range of different methodologies to analysis threats pending the level of detail you wish to dive into. If you’d like to read more check out the following

Fundamentally you can use any technique, provided it remains abstracted from specific vulnerabilities with vendor technology and have traceability back to the relevant threat taxonomy. We utilise a generic threat model to build a brief narrative to how different threats in relation to the scope of the problem. The analysis for threat modelling should identify the following in context of assets

  1. Threat Event

  2. Characteristics and Description

In this guide, I’ve standardised on the use of PASTA threat modelling technique. We only look to leverage Steps 1 – 4 from that methodology. Given that the security patterns are a logical abstraction of the assets, there isn’t much value is performing a full risk assessment on the assets. A meaningful analysis on likelihood and impacts will only be useful when applying the security patterns not writing them, so in this guide we only focus on Threat Event, Sources and Characteristics.

To promote useability within the patterns, we also utilise pre-defined taxonomies for categorising security threat events. This taxonomy is not intended to be an exhaustive list of all different threat events but is designed to consider the different types of threat events that exist. You may have your own threat events that aren’t listed which you can look to categorise and include.

Identifying the threats

Start with as generalised set of threat descriptions as they relate to the scope of the problem set. These should be based on the what was listed in the problem statement, but now more a refined set of statements that are specific to each asset item listed in the previous step.

Good threat modelling should incorporate feedback from different stakeholders and team members including system owners, developers and other solution architects. Also look to validate threats against any historic statistics, use cases, incidents or attacks where possible

Remember, don’t model threats outside the scope of the problem (as defined under Step 1). Also, don’t attempt to model risks that cannot be controlled, just note them as out of scope for the document.

Categorise against Threats Events taxonomy

Now that you have a mapping of the different threats you should now start to map out the Threat Event Taxonomy. We’ll now refine, split or combine some of these statements as you start to break apart the different threat events.

Identify each threat and look to characterise the potential threat events, relevance of the events, and the threat sources that could initiate the events.

Example:

So let’s put this into practise. Based on the research notes taken under Step 2 for Threats, Risks and Vulnerabilities we expand on this analysis and categories this against the threat taxonomy and break down the individual events. From the initial research we map these to the threat taxonomy list.

To refine and mature the analysis, identify additional threat events not yet considered such as ‘Violate isolation in multi-tenant environment’. This adds another interesting threat event for consideration for how tenets overlap between contributors could lead to code being committed incorrectly to the wrong code repository or subverting permissions boundaries across different repositories.

We subsequently finish up with the following.

Step 5 - Describe the target state solution

Great work on making it this far.

In this next step of the process, we describe the target state solution. It describes at a high level how the pattern addresses the problem statement and gives rationale behind design decisions made later in the pattern.

This section of the pattern will be customised to your own organisational requirements for security. It looks to build out the pattern in context the security principles, architectures or frameworks relevant to your company.

The solution should factor in any relevant security requirements prescribed through your organisation. This includes enterprise reference security architecture, security policy or standards, and applicable regulatory or compliance requirements.

List out design requirements and their implication to the solution

In our initial Step 1, we identified any considerations or requirements relevant to the problem space.

Specifically

For each of these requirements or considerations, you should now look to describe the implications that this has on the target state solution and design.

Within this section, you’ll look to incorporate any relevant guidance or requirements to the solution as prescribed within external Regulatory and Compliance requirements. For example, their maybe regulatory requirements regarding data sovereignty relevant to hosting location of specific assets.

Consider any security principles that should be incorporated into design requirements. For example, principles describing how these assets are segmented and the security related boundaries between them for separation between environments, criticality of systems or sensitivity of data.

This should also capture any requirement described under internal organisational policy and standards. For example, generalised statements that describe how those specific assets are managed and administrated.  

Example:

For purposes of this example, we’ll use just some generic reference models and principles that are publicly available.

We’ve referenced a generalised set of security principles described under Jericho Forum® Commandments aimed at building a de-perimeterised security architecture.

These requirements are summarised as the following

1. The scope and level of protection should be specific and appropriate to the asset at risk.
2. Security mechanisms must be pervasive, simple, scalable, and easy to manage.
3. Assume context at your peril.
4. Devices and applications must communicate using open, secure protocols.
5. All devices must be capable of maintaining their security policy on an un-trusted network.
6. All people, processes, and technology must have declared and transparent levels of trust for any transaction to take place. 
7. Mutual trust assurance levels must be determinable.
8. Authentication, authorization, and accountability must interoperate/exchange outside of your locus/area of control.
9. Access to data should be controlled by security attributes of the data itself.
10. Data privacy (and security of any asset of sufficiently high value) requires a segregation of duties/privileges.
11. By default, data must be appropriately secured when stored, in transit, and in use.

Reference: https://publications.opengroup.org/w124

Provide an overview

The pattern should include an overview to the solution. This represents the design solution proposed by the pattern and how it solves the original problem statement(s). This should include a short statement or description and complemented with relevant diagrams.

The description should cover an explanation of the solution as a whole and principles to the design.

The diagram(s) should communicate the expected target state of the solution and interactions between different assets identified in Step 3.

A common example for this would be reference architecture that prescribed trust boundaries between different assets such as network security zone model or identity and access management model.

It’s also important to note any related security patterns and the relationship between this pattern and others. It should highlight whether the pattern may represent a broader set of patterns that are applied together.

Collate requirements and describe the solution

The target state solution requires the following high-level summary of controls to be applied. It includes the rationale for design decisions and how it addresses the requirements.

This solution should include a break down for the following items

Describe the design principles

The principles should be as simple as possible to summarise the core security controls (as described in the solution). It should be documented in simple terms so that it is easily communicated and understood.

As a general rule, I look to document no more than 10 principles for the pattern.

Actors [Optional]

This is an optional section and will be specific to your organisation for internal teams, groups or departments.

In this section, consider

Example

Location [Optional]

This is an optional section and will be specific to your organisation for location.

This should represent any design decisions relating to location of the assets. Cover any considerations or constraints within the design that relate to location. In particular, any regulatory or compliance requirements which specific to a particular region, country or geo-location.

Example

Sequencing [Optional]

This is an optional section and will be specific to your organisation for workflows or processes.

Any process flows relevant to describing the design of the solution. This is a summary to any considerations to how the state of the assets may change within a given sequence of events (e.g. Asset during build versus deployment).

These should not be detailed workflows, interactions between components or process driven threat modelling. This should be kept as overall descriptions to the different ways the asset may be utilised, managed or operated.

Example

Step 6 - Controls Mapping

So now we start to get to the fun part of building out our security pattern.

We’ve done a lot of work to break down the different design principle and the threat models. It’s this work that is used to select, map and define the control(s) within the pattern.

It’s important to note however that this step won’t automatically generate an answer to what security controls are required within a security pattern. This step is about building completeness in your rational to why those controls are needed, ensuring that you’ve looked at all the different angles and that you don’t get caught up designing of one particular control. You’ll leverage the research that you’ve done in Step 2, threat modelling in Step 4 and design principles in Step 5 to help populate the expected controls required to mitigate the threats and meet design requirements.

This process can be labour intensive, so you’ll likely want to step through the mapping of threats, assets and control objectives within a spreadsheet so that you can filter and pivot on the different mappings as needed. Yes, this step could probably be better automated but for this guide we’ll just use a spreadsheet. I’ve provided a copy of the spreadsheet template used to perform this mapping (but you may develop your own process for achieving the same outcomes).

Decompose threats and map to each asset

This step is about expanding the existing threat analysis, identifying assets affected by each threat to build out a set of asset-based threat profiles

For each of the threats listed, you will now want to map in the individual assets items that are affected by it. When you start to work through this list, you should start to see some assets being more applicable to particular threats than others.

Don’t worry if a particular threat affects all assets. That’s fine. But you’ll likely also have some threats that are specific to an asset or a sub-component.

As part of this step, it’s also a good check point to reflect back on the scope, threat modelling and categorisation of assets. You should be asking yourself the following questions.

Tip: As a rule of thumb I typically look to aim for no more than 10 assets and no less than 5. I also subsequently aim for roughly for describing 5 - 8 different threats. Otherwise the pattern starts to become too complex. If this is the case, then you may need to consider breaking apart this pattern into two separate problem spaces in order to make the design pattern more manageable.

Mapping control objectives to threats

The threat analysis is used for evaluation of applicable security control objectives, by helping to indicate which control objectives are relevant to each threat scenarios, and subsequently to the assets where they are most effective.

As described previously, we standardise on the use of control taxonomy by using NIST Special Publication 800-53 Release 5. We utilise just the standard list of controls (and not the enhanced control list) to reduce too much complexity in the pattern

This step will be time consuming if you’re not familiar with the NIST 800-53 control framework, so spend some time first reading through the different control categories and some of the descriptions.

Using this taxonomy won’t provide any magic formula to which controls are required. What is does is provide completeness to your thinking and ensuring that you’ve evaluated all the control groups relevant to addressing the identified threats. Ultimately it facilitates a defence in depth within your security pattern.

When selecting relevant controls, the research conducted under Step 2 should help with the identification of relevant controls that are required to address these threats. You’ll also have identified expected controls for the target state solution in the previous step, as derived from any specific requirements.

Not all of the controls listed under NIST will be as relevant in writing security patterns. For example, control objectives around project management probably won’t get utilised under this process (not suggesting that these are important to security in broader context, just not as applicable within design of security patterns)

Using the spreadsheet template, I find the best process is to take the list of control objectives and create vertical columns across them representing the different threats that we’re initially identified (mostly because it just easier working with the 300 + control objectives as a vertical list rather than horizontally). Within the spreadsheet, I’ll mark which control objectives are relevant to mitigating the identified threat. That way I can filter and build pivot tables later on for the mapping later on. That said, feel free to perform this mapping using whatever method works best for you.  

Example:

We’ll now proceed with mapping our controls.

Here’s some screenshots of the mapping performed within the spreadsheet template. You’ll notice I’ve got two tabs that are used for performing the following mappings.

  1. ‘Map threats to assets’ – Step through each threat and identify the affected assets

  1. ‘Map controls to threats’ - Identify the mitigating controls for each threat.

I won’t step through the process for each item, but let’s take the mapping performed for the first threat TE-09 regarding secrets within source code.

Stepping through the controls list, most of those controls won’t mitigate that specific threat (applying DOS protection or resource availability won’t mitigate this threat) but a few become apparent.

Step 7 - Build the security pattern

Ok, so this is where you’re pattern finally takes shape and builds out the security pattern. We’re effectively going to collate the asset-centric view for controls required and customise the control description relevant to the pattern.

Now that we have a mapping of Threats to Assets and Threats to Controls, we can build out the relationship between Assets to Controls.

Collate and extract the security pattern for each asset

In this step we extract the list of mapped control objectives for each asset.

This is done by identifying for each asset, which threats are applicable (reversing the mapping done in previous step) to then collate the list of controls applicable to mitigating that threat.

Example:

Build the list by filtering down the mapping of control objectives on each threat, and identify the mapping of those threats against each specific asset. Then copy that list of controls into a per asset list. Using this process to extract the control list per each asset will likely result in same control being duplicated in your list, so you’ll need to filter those out.

What you should end up with is a flip of the previous mapping to extract an asset-centric view to the security pattern. For each of these lists, you’ll now copy this back into to pattern template for the designated ‘control list’ sections.

By collating and filtering the Assets -> threats -> Controls, you should end up with something like this.

I effectively use the spreadsheet to collate the control objectives into each column that represents the assets, then filter and remove duplicates from each list item. As mentioned early, this part of the process could be better automated but for the time being I’ve used spreadsheet magic to generate the lists.

Customising the control descriptions

Now that you’ve developed the lists for different control objectives per asset, customise the description of each control objective to address the specific concerns in context to the asset. I still retain the original control ID and title (as defined under NIST SP 800-53) but the description is updated in context of the asset. You could keep the original control descriptions, but keep in mind each description provided under NIST SP 800-53 are written as generic statements for a broad set of assets. This is great as a generalised list but this guide is about developing security patterns is to ensure the controls are written in context of the asset.

Based on initial research performed, you should now start to see a natural fit for control descriptions and where they align into the control objectives list. Alternatively, if you get stuck you may look to tweak the existing descriptions provided by NIST or simply replace it with anything that is more specific to the asset.

Each description should be written and aligned according to the design principles that were identified.

This part can be a lengthy process, but adds the true value to the security pattern rather than just a list of generic statements. Keep in mind, you won’t always get a perfect mapping of the controls to a specific control objective from the NIST catalogue. Like all models, it has its limitations.

Lastly, don’t fill out every control objective if it’s not relevant. Remove those that maybe duplicating the same control or don’t make sense to be applied to that asset.

Example:

Let’s take control ‘SA-11: Developer Testing and Evaluation’.

The NIST 800-53 description provides some generalised statements for ‘Require the developer of the system, system component, or system service, at all post-design stages of the system development life cycle’.

This isn’t particularly helpful when considering source code management.

What I look to customise this description to represent (considering the threat analysis and design principles from previous step) is that the source code is scanned during code commits to identify sensitive data such as private API Keys or credentials.

So for this control objective, I now customise the description to represent the following.

Including a pattern diagram

Once you’re comfortable with the control list then I recommend to include an overall diagram.

The diagrams included in the patterns are not necessarily important to the control objectives but a picture does paint a thousand words. I use this section just to summarise ‘on a glance’ the different assets and control objectives that have been identified.

Example:

The following diagram is the template used for describing the pattern.

Final review

As a final review, proof read your pattern. Hopefully you will have matured your analysis in looking at the different controls required for each asset.

This in turn may have you re-evaluating controls that you’ve initial identified in the previous mapping exercise that you can now look at and question whether the control is relevant or overlapping with other controls listed.

Admittedly it takes some back and forth in rethinking some of the previous mapping of applicable assets to threats and applicable controls to mitigate those threats.

It’s easy to get a bit of fatigue in stepping through spreadsheets so I usually make a first pass on the mapping then come back and refine/reassess the previous work. It will also force you to really think about how the assets have been identified and logically grouped

Example:

In provide a final and retrospect review for Source Code Mgmt pattern, it took some time to try and draw the line on what assets were in scope or not.

When first determining the assets in Step 1, I actually separated different asset depending on whether the git repository was primary site or replicated/mirror to a remote or partner site.

I later consolidated these asset types as ultimately it was producing the same list of controls needed and separating them was only adding to time/effort needed in completing the pattern.

I also found that I tend to over map the different mitigating controls on Step 6. In Step 7, I went back to the previous step and removed any that aren’t adding value or don’t appear relevant.

Ultimately the aim of the pattern is not to create endless lists of controls, but to ensure you’ve got completeness in considering the different types of controls that can mitigate the threats.

Step 8 - Conclusion

Congratulations! You’ve now completed building your security pattern.

The first set of patterns that I built out took some effort to complete, so don’t be discouraged if the first pattern takes some time for developing.

My first set of patterns built took a 2-3 weeks to complete but now that I’ve been working with (and refining this process) I’ve found that I can building out a security patterns a much faster pace and churn out a minimal pattern in just a few days.

Some final notes to this guide…

Don’t let process get in the way of good judgement. If you see a threat, principle or control that you feel should be included then don’t exclude it just for the sake of maintaining the process.

Please continue reading in the Step by Step guie for How to Use a Security Pattern or 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