Guia passo a passo: como escrever um padrão de segurança

Introdução

Neste guia, eu vou estar andando através de uma quebra passo-a-passo em Como Escrever um Padrão de Segurança.

Sempre lutei para encontrar bons recursos que descrevam o processo de construção de sua própria arquitetura de segurança, em particular padrões de segurança. Há muitas estruturas de arquitetura por aí que fornecem os blocos gerais de construção, mas isso sempre me deixou preso em onde começar e no processo de como ele é aplicado.

Este guia irá passar pelo processo de construção de padrões de segurança, fornecer um modelo de amostra para fazê-lo e referenciar padrões de exemplo que você pode usar para se adaptar para seus próprios propósitos.

Então, o que compõe um padrão de segurança?

Se você executar uma pesquisa no Google para ‘Padrões de Segurança’, você verá que o termo é usado de forma bastante ampla, com muitas opiniões diferentes do que um padrão deve representar.

Não acredito que haja um nível “correto” de detalhes para o que é considerado um padrão de segurança, pois diferentes designers analisarão problemas em diferentes níveis. Um analista de segurança pode estar principalmente preocupado com padrões relacionados à codificação específica de software, enquanto a arquitetura de segurança corporativa pode estar principalmente interessada em relações de confiança entre a organização e terceiros.

Dito isto, fundamentalmente, um padrão de segurança representa uma solução definida e reutilizável para um problema de segurança recorrente.

Dentro deste guia, definimos padrões de segurança como artefato de design que são

  • Escrito no contexto de um problema de segurança e como ele afeta o ativo.
  • Abstraindo a partir de implementações específicas de fornecedores ou tecnologias.
  • Padroniza o uso de taxonomias para promover a reutilização.
  • Mantém a rastreabilidade dos controles prescritos para as ameaças que estão sendo atenuadas.

Este guia destina-se a ser uma visão opinativa sobre como escrever um padrão de segurança. Você pode olhar para ajustar ou mudar partes deste processo para suas próprias necessidades e, de fato, eu encorajo você a fazê-lo em partes deste guia.

Por que desenvolver um padrão de segurança?

Com o aumento da demanda e da velocidade das implantações no setor de tecnologia da informação, a necessidade de formas mais inteligentes de desenvolver arquitetura e design de segurança também está aumentando. Onde há 10 anos os ciclos de implantação foram planejados em torno de lançamentos trimestrais ou mensais, a indústria continua a pressionar por ciclos mais rápidos.

Por sua vez, qualquer momento e esforço que esteja sendo colocado na escrita da arquitetura e do design de segurança deve apoiar a criação de artefatos que sejam reutilizáveis, adaptáveis e promovam o compartilhamento de informações entre outros pares, a fim de manter o ritmo.

É aqui que procuramos usar padrões de segurança.

Discutível, poderíamos recorrer à escrita de uma política de segurança ou padrões para alcançar os mesmos resultados que procuramos fornecer padrões de segurança. No entanto, acho o uso de padrões de segurança problemáticos pelas seguintes razões.

  1. Não manter a lógica de por que controles específicos são necessários. Há muitas normas de segurança que não incluem contexto para o porquê desses controles são necessários. Algumas normas podem incluir a lógica dentro de notas introdutórias, mas isso é tipicamente a critério do escritor em relação ao nível de detalhe fornecido e sua relevância para os controles prescritos.

  2. Falta de rastreabilidade entre os controles de segurança para as ameaças sendo mitigadas. Não manter a rastreabilidade de ameaças e requisitos originais torna-se problemático ao tentar avaliar posteriormente o risco residual de controles que não podem ser atendidos ou implementados. Isso se torna um desafio ainda maior para padrões que são escritos há vários anos ou por diferentes partes interessadas.

  3. Padrões divididos em grupos de controle semelhantes, podem ser desconectados uns dos outros. As normas são tipicamente divididas em grupos de conjuntos de controle semelhantes com um conjunto de declarações de maternidade para cobrir todos os ativos aplicáveis. Isso funciona bem em casos simples, mas problemático ao tentar determinar todos os controles necessários para proteger um ativo específico.

Em contraste, este guia para o desenvolvimento de padrões de segurança cria projetos ‘centrados em ativos’ que buscam manter a vinculação à forma como diferentes controles se complementam para proteger um ativo. Os padrões mantêm a rastreabilidade entre a modelagem de ameaças e quais controles são necessários, em vez de padrões que podem se tornar apenas um exercício de caixa de carrapato na tentativa de aplicar todos os controles possíveis.

Mais importante, os padrões de segurança formulam projetos que podem ser repetidamente aplicados à medida que a implementação de ativos difere entre diferentes fornecedores de tecnologia, migram para diferentes ambientes de hospedagem ou são utilizados por meio de diferentes modelos de provedores.

Vamos começar

As páginas a seguir fornecerão um passo adiante de como construir um padrão de segurança.

Tenha em mente durante esse processo, que não há nada que o impeça de reografar de volta em etapas anteriores ao trabalhar nas seções. Raramente fui capaz de escrever com sucesso um padrão de segurança do início ao fim em apenas uma única iteração, então não se surpreenda se você precisar voltar a um passo anterior à medida que seu pensamento amadurece e evolui. Na maioria das vezes, voltarei a uma seção específica para apertar algumas das definições ou o escopo do problema que está sendo resolvido.

Como dito anteriormente, esse processo pretende ser uma visão opinativa de como escrever um padrão de segurança. Você pode querer considerar a inclusão de etapas adicionais para atender aos seus requisitos específicos para sua empresa ou organização.

Passos

  1. Identificar o problema e o escopo

  2. Preparar e Pesquisar

  3. Identifique os ativos

  4. Modelagem de ameaças

  5. Descreva a solução de estado-alvo

  6. Definir e mapear objetivos de controles de segurança

  7. Descreva o padrão de segurança

  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

  • A security risk or issue raised by a project team
  • A security concern based on issues noted within a similar organisation
  • A new product or capability being brought into the organisation

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 …

  • Look for any related articles or blogs that relate to the problem space. Blog websites such as Medium are great for this which can provide insight to threat modelling, recommended solutions or controls
  • Research papers and articles under NIST Publications are great resources and often well written. It can sometimes take a while to find what your looking for but worth the effort when you do.
  • Read through vendor recommended security best practise that relate to the assets in scope (from Step 1). This will often provide a view to recommended controls and also typically provide some introduction explanation to security concerns
  • Cloud providers will often have recommended patterns or security benchmarks associated to an asset. Again, this will provide a view to the types of recommended security controls.
  • Reference CIS Benchmarks if available for that asset. These are great because they are system-centric. If the type of system or asset is listed (or something similar from a different vendor) then these are useful for understanding specific vulnerabilities or potential mis-configuration that could occur.
  • Vulnerability databases. Don’t get too caught up on specific vulnerability, but understand what they are and the different threats to those assets.

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.

Passo 3 - Listar os ativos específicos

É aqui que você começará a desenvolver o trabalho inicial feito durante a Etapa 1 para definir os ativos. Você precisará identificar e caracterizar os diferentes ativos, e logicamente agrupar esses ativos.

Há muitas maneiras de categorizar um ativo. Dentro desses padrões de segurança, procuramos definir um ativo como sistema de tecnologia e serviços que são ou

  1. Conjunto autônomo de serviços ou funções de aplicativos
  2. Conjunto discreto de recursos ou componentes de tecnologia dentro de uma plataforma ou sistema

Nota: Pessoas ou recursos que interagem com esses sistemas são cobertos separadamente neste guia.

A lista a seguir é fornecida como uma lista indicativa de diferentes grupos lógicos de ativos que podem existir. Você precisará dividir quais ativos específicos desta lista são afetados dentro do escopo de problema definido. Esta não é uma lista exaustiva e você provavelmente construirá diferentes subcategorias para esses grupos.

  • Dispositivo: dispositivos de estação de trabalho (por exemplo, laptops, desktops usados pela equipe organizacional), pontos finais de uso especial (por exemplo, dispositivos IOT, caixas eletrônicos), dispositivos móveis de ponto final (por exemplo, smartphones, tablets, laptops de clientes)
  • Aplicativo: Aplicativos de negócios, serviços de monitoramento e análise, aplicativos de interação do consumidor (por exemplo, Web, mobile), serviços de gerenciamento de conteúdo,
  • Plataformas: Sistemas físicos, Virtualização, Containerização, Middleware
  • Gerenciamento: Serviços de Plano de Controle, Hosts Bastion, Gerenciamento de Configuração, Serviços de Orquestração e Automação,
  • Dados: Bancos de dados (por exemplo, bancos de dados de contas); Armazenamento de dados de objetos, sistemas de arquivos, armazenamento de blocos, caches de dados, serviços de diretório, gerenciamento de segredos
  • Rede: Componentes de rede ou dispositivos (por exemplo, roteadores, switches, firewalls), serviços de rede (por exemplo, servidores DNS, servidores DHCP, VPN, SD-WAN)

A quebra adicional da lista de ativos e quaisquer subcamadas podem ser feitas considerando os diferentes componentes ou recursos do sistema. Isso inclui os pontos de entrada ou saída para esses componentes.

Ponta:

  • Não categorize nenhum ativo que seja considerado como serviço não funcional para segurança, pois você acabará se colocando em um loop mais tarde ao analisar controles mitigadores.
  • Minha regra geral é apenas dividir as camadas a um ponto onde elas podem ser avaliadas e agrupar-se com base em ameaças aplicáveis. Não analise subcomponentes que não sejam necessariamente relevantes para o escopo do problema (ou modelagem de ameaças subsequentes).
  • Não se destendo além do que seria considerado um conjunto de funções lógicas generalizadas. A lista de ativos só precisa ser dividida

Exemplo:

No âmbito da declaração do problema, identificamos e categorizamos os seguintes tipos de ativos.  

Passo 4 - Modelagem de Ameaças

Esta etapa será potencialmente a seção mais difícil de ser concluída neste guia, mas também a mais importante. A Modelagem de Ameaças permitirá que você crie uma visão mais robusta e bem arredondada dos controles de segurança necessários para lidar com os riscos potenciais.

Devemos rapidamente desviar um pouco do processo para fazer menção de que existem muitas metodologias diferentes de modelos de ameaça que existem. Nem todos são iguais, alguns são abrangentes, enquanto outros são bastante abstratos. Alguns métodos se concentram especificamente em riscos ou preocupações, enquanto outros mergulharão profundamente em vulnerabilidades ou falhas particulares em um sistema.

Não passarei por uma discussão exaustiva para todos os modelos diferentes, mas fundamentalmente existe uma gama de diferentes metodologias para analisar ameaças até o nível de detalhe que você deseja mergulhar. Se você quiser ler mais confira o seguinte

Fundamentalmente, você pode usar qualquer técnica, desde que permaneça abstraída de vulnerabilidades específicas com a tecnologia do fornecedor e tenha rastreabilidade até a taxonomia de ameaças relevante. Utilizamos um modelo genérico de ameaça para construir uma breve narrativa de como diferentes ameaças em relação ao escopo do problema. A análise para modelagem de ameaças deve identificar o seguinte no contexto dos ativos

  1. Evento de Ameaça

  2. Características e Descrição

Neste guia, eu padrlizei sobre o uso da técnica de modelagem de ameaças PASTA. Só procuramos aproveitar as etapas 1 – 4 dessa metodologia. Dado que os padrões de segurança são uma abstração lógica dos ativos, não há muito valor na realização de uma avaliação completa de risco sobre os ativos. Uma análise significativa sobre probabilidade e impactos só será útil na aplicação dos padrões de segurança que não os escrevem, por isso, neste guia, focamos apenas em Evento de Ameaça, Fontes e Características.

Para promover a usuabilidade dentro dos padrões, também utilizamos taxonomias pré-definidas para categorizar eventos de ameaça à segurança. Esta taxonomia não se destina a ser uma lista exaustiva de todos os eventos de ameaça diferentes, mas foi projetada para considerar os diferentes tipos de eventos de ameaça que existem. Você pode ter seus próprios eventos de ameaça que não estão listados que você pode procurar categorizar e incluir.

Identificando as ameaças

Comece com o conjunto generalizado de descrições de ameaças à medida que se relacionam com o escopo do conjunto de problemas. Estes devem ser baseados no que foi listado na declaração de problema, mas agora mais um conjunto refinado de declarações que são específicas para cada item de ativo listado na etapa anterior.

Uma boa modelagem de ameaças deve incorporar feedback de diferentes partes interessadas e membros da equipe, incluindo proprietários de sistemas, desenvolvedores e outros arquitetos de soluções. Procure também validar ameaças contra quaisquer estatísticas históricas, casos de uso, incidentes ou ataques, sempre que possível

Lembre-se, não modele ameaças fora do escopo do problema (conforme definido na Etapa 1). Além disso, não tente modelar riscos que não podem ser controlados, apenas anote-os como fora de escopo para o documento.

Categorizar contra a taxonomia de Eventos de Ameaças

Agora que você tem um mapeamento das diferentes ameaças, agora você deve começar a mapear a Taxonomia do Evento de Ameaça. Agora vamos refinar, dividir ou combinar algumas dessas declarações à medida que você começa a quebrar os diferentes eventos de ameaça.

Identifique cada ameaça e procure caracterizar os potenciais eventos de ameaça, a relevância dos eventos e as fontes de ameaça que poderiam iniciar os eventos.

Exemplo:

Então vamos colocar isso em prática. Com base nas notas de pesquisa feitas sob o Passo 2 para Ameaças, Riscos e Vulnerabilidades, expandimos esta análise e classificamos isso contra a taxonomia da ameaça e despreendo os eventos individuais. Desde a pesquisa inicial, mapeamos isso até a lista de taxonomia de ameaças.

Para refinar e amadurecer a análise, identifique eventos adicionais de ameaça ainda não considerados como “Violar o isolamento no ambiente multiconquinte”. Isso adiciona outro evento de ameaça interessante para considerar como os princípios se sobrepõem entre os contribuintes poderia levar a que o código seja cometido incorretamente ao repositório de código errado ou subvertando limites de permissões em diferentes repositórios.

Posteriormente, terminamos com o seguinte.

Passo 5 - Descreva a solução de estado-alvo

Ótimo trabalho em chegar até aqui.

Nesta próxima etapa do processo, descrevemos a solução do estado-alvo. Ele descreve em alto nível como o padrão aborda a declaração do problema e dá razão por trás das decisões de design tomadas mais tarde no padrão.

Esta seção do padrão será personalizada para seus próprios requisitos organizacionais de segurança. Ele procura construir o padrão no contexto dos princípios de segurança, arquiteturas ou estruturas relevantes para sua empresa.

A solução deve considerar quaisquer requisitos de segurança relevantes prescritos através de sua organização. Isso inclui arquitetura de segurança de referência corporativa, política de segurança ou padrões e requisitos regulatórios ou de conformidade aplicáveis.

Liste os requisitos de design e suas implicações para a solução

Em nosso passo inicial 1, identificamos quaisquer considerações ou requisitos relevantes para o espaço problemático.

Especificamente

  • Requisitos regulatórios e de conformidade
  • Requisitos de arquitetura de referência corporativa.
  • Design De suposições ou restrições

Para cada um desses requisitos ou considerações, agora você deve procurar descrever as implicações que isso tem na solução e design do estado-alvo.

Dentro desta seção, você procurará incorporar quaisquer orientações ou requisitos relevantes para a solução conforme prescrito dentro dos requisitos externos de regulação e conformidade. Por exemplo, seus requisitos talvez regulamentares em relação à soberania dos dados relevantes para a localização de ativos específicos.

Considere quaisquer princípios de segurança que devem ser incorporados aos requisitos de design. Por exemplo, princípios que descrevem como esses ativos são segmentados e os limites relacionados à segurança entre eles para separação entre ambientes, criticidade dos sistemas ou sensibilidade dos dados.

Isso também deve capturar qualquer exigência descrita sob a política e as normas organizacionais internas. Por exemplo, declarações generalizadas que descrevem como esses ativos específicos são gerenciados e administrados.

Exemplo:

Para efeitos deste exemplo, usaremos apenas alguns modelos de referência genéricos e princípios que estão disponíveis publicamente.

Nós mencionamos um conjunto generalizado de princípios de segurança descritos sob os Mandamentos do Fórum® de Jericó com o objetivo de construir uma arquitetura de segurança desmetralizada.

Esses requisitos são resumidos como os seguintes

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 how the assets exist within relevant trust boundaries and segregation models (IAM, Network)
  • Describe any variants or different use cases for utilisation of the assets based on locations or sequenced events.
  • Describe the needs to use, interact or operate the asset(s) in specific ways.
  • Describe how the asset(s) needs to handle information in a specific manner, due to its sensitivity, data sovereignty, legal or regulatory requirements
  • Describe any explicit requirement on specific controls as prescribed under regulatory and compliance
  • Describe any consideration to potential issues and or trade-offs in the usage of the pattern

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

  • Who benefits from this pattern (Regulatory bodies, Compliance Teams, Developers, Sys Admins, Database Admins)
  • Who is the intended consumer or audience for this pattern (Internal, Third Party Providers)
  • Who interacts within this pattern (Admins, Security, Compliance Teams, Fraud, Privacy)

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.

  • Q: Have all threats been analysed for the assets listed ?
  • Q: Do any commonality exist for same threats to multiple assets. Can those assets being logically grouped to gather to simplify the pattern ?
  • Q: Does the threat analysis and asset categorisation still reflect the initial scope and problem space. Can those initial problems be better defined or should this pattern be broken into separate patterns ?

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:

Vamos assumir o controle ‘SA-11: Teste e Avaliação do Desenvolvedor’.

A descrição NIST 800-53 fornece algumas instruções generalizadas para “Exigir o desenvolvedor do sistema, componente do sistema ou serviço do sistema, em todas as etapas pós-design do ciclo de vida de desenvolvimento do sistema”.

Isso não é particularmente útil quando se considera o gerenciamento de código fonte.

O que eu procuro personalizar essa descrição para representar (considerando os princípios de análise de ameaças e design da etapa anterior) é que o código-fonte é digitalizado durante os compromissos de código para identificar dados confidenciais, como chaves de API privadas ou credenciais.

Então, para este objetivo de controle, agora eu personalizo a descrição para representar o seguinte.

Incluindo um diagrama de padrão

Uma vez que você está confortável com a lista de controle, então eu recomendo incluir um diagrama geral.

Os diagramas incluídos nos padrões não são necessariamente importantes para os objetivos de controle, mas uma imagem pinta mil palavras. Uso esta seção apenas para resumir “de relance” os diferentes ativos e objetivos de controle que foram identificados.

Exemplo:

O diagrama a seguir é o modelo usado para descrever o padrão.

Revisão final

Como revisão final, a prova leia seu padrão. Espero que você tenha amadurecido sua análise ao analisar os diferentes controles necessários para cada ativo.

Isso, por sua vez, pode fazer com que você reavalie os controles que você identificou inicialmente no exercício de mapeamento anterior que agora você pode olhar e questionar se o controle é relevante ou sobreposto com outros controles listados.

É certo que é preciso um pouco de ida e volta para repensar alguns dos mapeamentos anteriores dos ativos aplicáveis a ameaças e controles aplicáveis para mitigar essas ameaças.

É fácil obter um pouco de fadiga em passar por planilhas, então eu costumo fazer um primeiro passe no mapeamento, depois voltar e refinar/reavaliar o trabalho anterior. Também vai forçá-lo a realmente pensar sobre como os ativos foram identificados e logicamente agrupados

Exemplo:

Em fornecer uma revisão final e retrospectiva para o padrão Código Fonte Mgmt, levou algum tempo para tentar desenhar a linha sobre quais ativos estavam em escopo ou não.

Ao determinar os ativos pela primeira vez no Passo 1, eu realmente separei diferentes ativos dependendo se o repositório de git era o site principal ou replicado/espelho para um site remoto ou parceiro.

Mais tarde, consolidei esses tipos de ativos, pois, em última análise, estava produzindo a mesma lista de controles necessários e separando-os estava apenas adicionando ao tempo/esforço necessário para completar o padrão.

Também descobri que eu costumo mapear os diferentes controles mitigadores no Passo 6. Na etapa 7, voltei à etapa anterior e removi qualquer um que não esteja agregando valor ou não pareça relevante.

Em última análise, o objetivo do padrão não é criar listas intermináveis de controles, mas garantir que você tenha completude em considerar os diferentes tipos de controles que podem mitigar as ameaças.

Step 8 - Conclusion

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

O primeiro conjunto de padrões que eu construí levou algum esforço para completar, então não se desanime se o primeiro padrão leva algum tempo para se desenvolver.

Meu primeiro conjunto de padrões construídos levou 2-3 semanas para ser concluído, mas agora que eu tenho trabalhado (e refinando este processo) eu descobri que eu posso construir um padrão de segurança um ritmo muito mais rápido e agitar um padrão mínimo em apenas alguns dias.

Algumas notas finais para este guia…

Não deixe o processo atrapalhar o bom julgamento. Se você vir uma ameaça, princípio ou controle que você acha que deve ser incluído, então não exclua-o apenas para manter o processo.

Por favor, continue lendo no passo a passo guie para Como Usar um Padrão de Segurança ou navegue pelo exemplo existente Padrões de segurança disponíveis, incluindo o padrão de segurança de gerenciamento de código fonte discutido neste guia.

Quem somos

O conteúdo sobre securitypatterns.io é fornecido como material aberto e gratuito sob licença creative commons para fins não commerical.

Por favor, forneça seu apoio postando comentários ou me seguindo no Twitter e no LinkedIn se você gostou de ler e quiser ficar atualizado.

Leitura suplementar