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

Introdução

Este guia descreve como usar e aplicar padrões de segurança. Ele segue no guia anterior de Como Escrever um Padrão de Segurança.

Se você já leu através do guia anterior, você pode estar se perguntando agora;

  1. Como faço para iniciar o uso de padrões de segurança em um projeto?
  2. Como determino a prioridade para controles e quais implementar primeiro?
  3. Como faço para acompanhar todos esses controles de segurança em um projeto?

As seguintes seções dentro deste guia fornecerão uma caminhada sobre como lidar com essas tarefas.

Não está escrito tão estritamente quanto o guia passo-a-passo anterior para escrever padrões de segurança, pois há muitos tópicos para cobrir. Em vez disso, isso descreve considerações sobre a segurança na entrega de projetos e como os padrões de segurança podem ajudar durante as fases do projeto.

Este guia discute intencionalmente aspectos de segurança que vão além apenas do uso de padrões de segurança. Isso é importante para tentar explicar como esses aspectos se encaixam.

Da melhor forma possível, fornenciei uma lista de referências dentro deste documento e no final para leitura continuada. Também vou procurar continuar expandindo sobre vários tópicos em posts e artigos de blog.

Antes de começarmos a usar padrões de segurança, vamos olhar rapidamente para alguns conceitos fundamentais que precisamos cobrir.

Entrega Ágil

Este documento foca na inclusão de padrões de segurança dentro da metodologia ágil de entrega de projetos. Se você ama ou odeia, o Agile continua sendo uma metodologia comum para a implantação de produtos dentro da indústria.

É também onde tomar uma abordagem tradicional de cima para baixo para a arquitetura de segurança não se alinha.

Ágil é uma abordagem iterativa para implantação. O escopo da arquitetura de segurança é muitas vezes limitado a cobrir apenas o máximo necessário para implementar o próximo incremento do projeto.

Neste guia vamos ver como o uso de padrões de segurança é bem adaptado ao Agile. Faremos referência a muita terminologia ágil, especialmente para as fases e princípios. Se você não está familiarizado com Agile, então eu sugiro alguma pré-leitura. A Atlassian mantém uma ótima documentação fácil de ler se você quiser saber mais.

Notavelmente, existem várias variações diferentes em metodologias ágeis que existem hoje (por exemplo, Scrum, Lean, Kanban, Extreme Programming). Não cobrimos cada uma dessas metodologias, mas vamos procurar referenciar algumas delas para destacar como padrões de segurança podem ser usados.

O uso de padrões de segurança não é de forma alguma exclusivo do Agile. Se você está olhando para padrões de segurança, mas use uma abordagem híbrida ou de cima para baixo, então basta tratar padrões como qualquer outro artefato de design.

Referência

Boa Segurança é Pessoas, Processos e Tecnologia

Uma boa segurança precisa levar em conta as pessoas, o processo e a tecnologia. Ele forma a base de qualquer estrutura de segurança dentro de uma organização.

Os padrões de segurança são principalmente focados em ativos de tecnologia, mas isso não deve descartar a igual importância para lidar com a segurança das pessoas e o processo que os habilite.

Os padrões de segurança de exemplo fornecem algumas notas genéricas para as pessoas e processam, no entanto, ao desenvolver seus próprios padrões, certifique-se de fatorá-las, relevantes para sua organização.

Modelo de responsabilidade compartilhada dentro dos provedores de nuvem

À medida que a adoção da computação em nuvem aumenta para muitas organizações, é importante relacionar o uso de padrões de segurança com o modelo de Responsabilidade Compartilhada.

Ao analisar como os padrões de segurança são aplicados em diferentes modelos de serviço, particularmente para provedores de nuvem (ou seja, SaaS, PaaS, IaaS), a implementação de controles de segurança específicos precisa ser mapeada contra quem é responsável por essa pilha de tecnologia.

Se você não está familiarizado com este modelo, então eu sugiro alguma pré-leitura. A AWS e Azure mantêm uma ótima documentação se você quiser saber mais.

Referência

Garantia de controle

Discutimos a necessidade de “garantia” com frequência neste guia. Se você não está familiarizado com este termo, é o processo tomado para validar o design pretendido corresponde ao que foi implementado.

O NIST fornece a seguinte definição como parte das Definições de Controle NIST 800-53.

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.

Referência

Apetite por Risco

Por último, mas não menos importante, tenha consciência de que não existe tal coisa como “risco zero”. Tentar alcançá-lo para obter segurança requer compensar outros resultados. Em um mundo ideal haveria tempo e financiamento suficientes para trabalhar tudo o que fosse necessário para a segurança. Pragmaticamente, porém, há sempre restrições que devem ser contabilizadas.

O apetite ao risco é melhor descrito como “o nível de exposição que uma organização está disposta a tomar” para alcançar objetivos estratégicos.

Conhecer o apetite de risco para sua organização é importante entender, pois guiará a prioridade e o mínimo de benchmark dos controles necessários.

Referência

Estabelecendo padrões de segurança dentro de um projeto

A metodologia em torno do desenvolvimento de padrões de segurança está bem adaptada à natureza iterativa do Ágil. O uso de taxonomias padrão permite o planejamento incremental e a habilitação de controles dentro de sprints de projetos. Embora ainda haja investimento necessário na frente para desenvolver padrões de segurança, a estrutura dos padrões permite a implementação gradual da segurança através do desenvolvimento de produtos.

A atribuição de prioridade a controles específicos é feita usando uma abordagem baseada em riscos, mapeada contra as ameaças de segurança determinadas dentro do padrão.

Os padrões de segurança são “centrados em ativos”, que se adequa à metodologia Ágil que se concentra na entrega de um conjunto definido de produtos. Os padrões podem ser limitados em torno do escopo do produto para que o projeto, e em coordenação com o proprietário do produto.

Os padrões de segurança podem ser escopos usando uma visão de arquitetura corporativa de cima para baixo. No entanto, os padrões de segurança não dependem dele estar no lugar.

Se sua organização mantiver a arquitetura de segurança corporativa, incorpore-a ao padrão como requisitos de design (quando aplicável). Dito isto, tentar construir todos os padrões de segurança possíveis usando uma abordagem tradicional de cima para baixo seria demorado e não recomendado (como você provavelmente acabará ‘fervendo o oceano’).

A abordagem recomendada é iniciar o desenho de um padrão de segurança baseado em requisitos tangíveis e escopo associado ao projeto.

Planejamento para arquitetura dentro de ágil

A inclusão geral da arquitetura dependerá, em parte, do sabor do Ágil que sua organização está usando. Algumas estruturas ágeis terão fases bem definidas para a inclusão da arquitetura, enquanto outras podem deixá-la evoluir mais organicamente durante cada sprint.

Espera-se que os padrões de segurança sejam geralmente estabelecidos dentro da fase inicial do início do projeto. Os padrões devem procurar capturar e fatorar os requisitos de:

  • Visão das partes interessadas e roteiro
  • Temas estratégicos (tanto para a estratégia de produto quanto para segurança)
  • Normas regulatórias e de conformidade
  • Arquitetura corporativa de referência

Padrões de segurança também podem continuar a ser desenvolvidos enquanto o projeto continua através de sprints iterativos. Se olharmos para a estrutura Scaled Agile como um exemplo, ela mantém fases claras para ‘Architecture Runway’ para este fim. Usando esta estrutura como exemplo, o design ou atualização dos padrões de segurança poderia em paralelo aos ciclos de sprint.

Referência

Definindo o escopo para o padrão

O planejamento frontal dentro das fases inaception do projeto deve identificar a necessidade e o escopo dos padrões de segurança.

Os padrões de segurança começam com a definição de uma declaração de problema. Essa declaração de problema provavelmente será limitada em torno do escopo do projeto para o produto.

Envolva-se com proprietário de produtos, stakeholders e equipe de gerenciamento para avaliar os aspectos relevantes de segurança dos requisitos do negócio. Isso também deve servir para entender suas preocupações com os riscos que eles podem ter identificado.

As informações coletadas nesta etapa ajudarão a formar a base da ‘Visão geral’ e dos ‘Desafios Típicos’ dentro do Padrão de Segurança.

Tamanhos de camiseta para padrão de segurança

Um método popular no Agile está usando tamanhos de camiseta como técnica para estimar esforços para histórias e tarefas de usuários.

Princípios semelhantes podem ser aplicados à estimativa de esforço para construir padrões de segurança. Também podemos aumentar ou reduzir o esforço estimado modificando partes do modelo de padrão de segurança e profundidade de análise.

As estimativas reais de esforço serão diferentes para todos, com base na familiaridade com o espaço problemático, uso de padrões e complexidade. Portanto, por favor, leve as estimativas fornecidas puramente como um guia para consideração em vez de qualquer coisa prescritiva.

Dentro do guia ‘Como Escrever um Padrão de Segurança’, passamos pelo processo de construção de um padrão de segurança. Mais importante nesse processo, notamos os princípios fundamentais que compõem um padrão.

  1. Design centrado em ativos
  2. Análise das ameaças
  3. Rastreabilidade da modelagem de ameaças em controles de segurança
  4. Taxonomia padronizada

Abaixo é dividido em algumas variações para o modelo padrão de segurança, e como isso pode corresponder a estimativas via dimensionamento de camisetas. Mais uma vez, este é apenas um guia para consideração e suas estimativas reais podem diferir.

  Pequeno Média Grande
Uso esperado Artefato de design leve para implantações de pequenos produtos Processo padrão de padrão de segurança, como descrito no guia ‘Como escrever’. Grandes iniciativas empresariais ou sistemas críticos.
Modelagem de ameaças Aplique análise básica usando modelagem de ameaças STRIDE e mapa contra ameaças aplicáveis. Aplique modelagem e mapa de ameaças de ameaças de MASSA contra ameaças aplicáveis com descrições Realize análise completa de ameaças usando técnicas detalhadas de modelagem de ameaças, como ATT&CK CAPEC. Mapa contra ameaças aplicáveis com descrições.
Solução Estabelecer o projeto e os princípios da solução de estado-alvo Estabelecer o projeto e os princípios da solução de estado-alvo Estabelecer o projeto e os princípios da solução de estado-alvo. Mantenha a rastreabilidade de volta aos requisitos.
Controles de Segurança Mapa para controles genéricos NIST 800-53 Mapear controles NIST 800-53 e aplicar descrições personalizadas Mapeear NIST 800-53 Controles Aprimorados e aplicar descrições personalizadas
Prazo para desenvolver padrão 2-3 Dias 5-7 Dias Mais de 10 dias

Eu recomendei investir o esforço na frente para construir um padrão formal de segurança. O tamanho da camiseta ‘média’ é a abordagem documentada no guia Como Escrever e deve ser considerado a posição padrão.

Exemplo:

Vamos continuar com o mesmo exemplo de How-To-Write-Sec-Pattern e olhar para usar o padrão de segurança do Gerenciamento de Código Fonte.

Vamos considerar um cenário de exemplo de como a necessidade e o início do padrão podem ter ocorrido.

Uma organização pode ter várias instâncias diferentes de SCM em vigor em diferentes divisões. Isso diminui sua capacidade de colaboração efetiva e um projeto é iniciado para consolidar o código-fonte mgmt em uma única plataforma corporativa.

O proprietário do produto está procurando enfrentar desafios imediatos de permitir o acesso de parceiros terceirizados e contribuir com o código. Repositórios de código também estão sendo utilizados em diferentes plataformas de hospedagem para on-premise e cloud.

O engajamento com as partes interessadas do projeto também observa que há uma preocupação imediata em torno de desenvolvedores terceirizados que cometem segredos para codificar. Novas investigações com as equipes de operações de segurança observam que vários incidentes de segurança registrados relacionados à exposição de segredos.

Como tal, há uma necessidade estabelecida de escrever um padrão de segurança para esses desafios, limitado em torno do escopo da Gestão do Código Fonte.

Projetando para segurança incremental

Agora que nossos padrões de segurança estão estabelecidos, vamos ver como esses padrões podem ser quebrados em sprints iterativos como parte da entrega do produto.

O padrão define o conjunto de controles de estado-alvo necessários para a implementação. A natureza iterativa da ágil significa que esses controles precisam ser divididos em tarefas incrementais e posicionados em backlogs para implementação.

Isso permite que a postura de segurança do produto se desenvolva à medida que o sistema também amadurece.

O estabelecimento incremental de controles de segurança suporta a entrega precoce e frequente dos recursos de software necessários para o produto como parte do Agile.

O padrão de segurança continua sendo um benchmark de trabalho para a equipe scrum que encapsula os recursos de segurança do produto.

Determinando a prioridade para cada controle

Haverá muitos fatores que influenciarão a prioridade de controles a serem implementados. Determinar quais controles priorizar primeiro deve sempre centrado em torno da mitigação do risco. No entanto, outros fatores de influência podem incluir,

  • Impacto na funcionalidade do produto ou usabilidade.
  • Maturidade da tecnologia usada para implementá-la.
  • Complexidade do controle para construir e implementar.
  • Custo associado à implementação.

Não há fórmula mágica para trabalhar o equilíbrio certo (discutível).

Se você está preso em onde começar, então aqui estão algumas dicas para avançar. Como uma posição inicial padrão, eu recomendaria o seguinte

  1. Use NIST. Linhas de base de controle SP.800-53B - A NIST publica um documento complementar à lista de controle 800-53 que fornece prioridade recomendada para cada controle individual. As prioridades atribuídas são genéricas, mas é um ponto de partida para estabelecer uma linha de base.
  2. Validar contra riscos dentro do ambiente atual do Estado - Identifique riscos ou condições predispontuais no ambiente atual para sua organização que possam afetar a probabilidade e o impacto de ameaças identificadas. Para as ameaças identificadas no padrão, priorize o controle de segurança associado à mitigação delas.
  3. Realizar estimativas de pontos de quadro de histórias entre os controles propostos - Permitir a entrada da equipe scrum para dimensionar e estimar o esforço necessário para a implementação dos controles. Também agrupa controles ‘like’ para ajudar a construir histórias de segurança para a equipe estimar contra.

Inclusão dentro de roadmaps de produtos

Com a prioridade de controles agora estabelecida, ele precisa agora ser mapeado no roteiro do produto. Para aqueles controles que têm maior prioridade, atribua-se aos estágios iniciais para backlogs de produtos ou arquitetura (pendente de qual sabor do Ágil sua organização está usando).

Procure também por quaisquer recursos de produtos que possam se alinhar aos controles de segurança identificados. Ele não deve distrair da prioridade já atribuída aos controles, mas será muito mais fácil entregar esses controles quando estiver alinhado com as mesmas prioridades para o produto.

A segurança de refatorar é inerentemente difícil, por isso procure garantir que a implementação dos controles de segurança seja claramente identificada em roteiros de produtos e backlogs de produtos o mais cedo possível.

Exemplo:

Com base no engajamento inicial com as partes interessadas, discutimos posteriormente com operações de segurança e equipes de gerenciamento de riscos. Identificamos que segredos vazados do código fonte são um risco considerável para a organização.

Olhando para o padrão de segurança, notamos que a seguinte ameaça de segurança se relaciona especificamente com credenciais vazadas do código.

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

Para esta ameaça específica, notamos que os seguintes controles devem agora ser priorizados dentro do projeto.

O padrão de segurança também mapeia essa ameaça aos ativos afetados, por isso procuramos coordenar a implementação desses controles dentro de recursos semelhantes listados nos backlogs do produto.

Planejamento de Sprint

Engajamento com equipes scrum

É necessário que toda a equipe scrum entenda a abordagem e os princípios derivados dos padrões de segurança.

Os padrões permitem a transferência de conhecimento dos desafios típicos e ameaças de segurança associadas identificadas. Posteriormente, permite que cada equipe de scrum avalie as implicações dentro de seus sprints. Isso também pode ativá-los para considerar detalhes sobre o design do produto e refatorar suas tarefas de acordo.

É igualmente importante promover a conscientização para os controles de segurança necessários para mitigar essas ameaças. Dito isso, tentar comunicar todo o padrão para cada membro da equipe será um desafio.

Por essa razão, os ‘Princípios de Design’ dentro dos padrões de segurança são intencionalmente mantidos o mais simples possível para garantir que sejam facilmente comunicados a todos. No mínimo, fornece uma âncora para todos os membros da equipe trabalharem contra. O especialista dentro da equipe pode então mergulhar mais nos detalhes do padrão de segurança, conforme necessário.

Designers de segurança são frequentemente compartilhados entre as equipes e com tempo limitado. O padrão de segurança está estruturado com isso em mente para apoiar o compartilhamento de informações e a re-usabilidade em várias equipes scrum.

Estabeleça histórias de usuários focadas em segurança

Um método popular para estabelecer e validar tarefas de segurança dentro do Agile é construir histórias focadas em segurança como parte do planejamento de sprint.

Participar de sessões de story board entre sprints oferece a oportunidade de contribuir com histórias específicas de usuários de segurança que refletem a prioridade de controles dos padrões de segurança.

As equipes scrum devem trabalhar através dos controles de segurança para definir itens de backlog e atribuir tarefas associadas a ciclos de sprint específicos.

Se você quiser entender mais sobre este método, existem alguns exemplos de trabalho fornecidos pelo SafeCode.

Referência

Usando personas de segurança

Definir personas também é outro método popular em Ágil. Criar personas de segurança oferece a oportunidade para as equipes scrum quebrarem as ameaças à segurança no contexto de suas tarefas e ajudá-las a entender a intenção de princípios de design de segurança.

Por exemplo, definir personas como ‘invasor externo’, ‘desenvolvedor de malware’ ou ‘insider malicioso’ pode ajudar as equipes a entender o motivo e o incentivo por trás de ameaças à segurança que podem comprometer seus sistemas.

Referência

Delegação de tarefas de segurança dentro de equipes de produtos

Antes de entrarmos neste tópico, vamos discutir rapidamente a necessidade de delegação.

Os profissionais de segurança são frequentemente considerados um papel “especialista” e normalmente necessários para operar como um recurso compartilhado em várias equipes scrum. É uma declaração generalizada e cada organização vai operar com diferenças nas estruturas e competências da equipe. Mas dado que a necessidade da indústria de profissionais de segurança continua a superar os recursos de segurança disponíveis, espero que este seja o caso de muitas pessoas.

Tudo isso só impulsiona os seguintes resultados para profissionais de segurança que operam em ciclos de entrega acelerados.

  • Os recursos de segurança são forçados a avaliações leves de toque, a fim de manter o ritmo.
  • As equipes do Scrum devem diminuir os ciclos de entrega para permitir que os recursos de segurança acompanhem a demanda.
  • Os recursos de segurança são estendidos para trabalhar mais e mais para atender à demanda.

Alternativamente, uma abordagem melhor é olhar para como aproveitar as equipes para ajudar a fornecer resultados de segurança, a fim de reduzir a pressão sobre os recursos de segurança compartilhada.

Permitir que as equipes scrum entreguem também suporta o princípio dentro do Agile. Se olharmos para o sucesso do ‘Modelo Spotify’ como uma adaptação popular do Agile, um dos fundamentos fundamentais é fornecer o máximo de autonomia possível para seu povo, a fim de ajudá-los a girar rapidamente.

Delegar maior autonomia para as equipes scrum pode muitas vezes parecer em desacordo com a segurança. Especialmente quando se considera a ameaça de insiders rouge ou usuários privilegiados (geralmente uma preocupação fundamental para a segurança). É um equilíbrio difícil de alcançar, mas importante.

Para lidar com isso, utilizamos uma abordagem de “governança e guardrails” para delegar a implementação de diferentes controles entre diferentes equipes e, ao mesmo tempo, medir sua eficácia (discutida mais adiante na próxima seção).

Os padrões de segurança são bem adaptados para reutilização em várias equipes e gerenciando a delegação de controles específicos. Os princípios norteadores para a estrutura dos Padrões de Segurança são construídos com isso em mente. Como discutido anteriormente, padrões de segurança são

  1. Abstraindo a partir de implantação específica de fornecedores ou tecnologia - Permitindo à equipe scrum maior autonomia na seleção de produtos de ferramentas e fornecedores para implementar controles específicos.
  2. Padronize o uso de taxonomias para promover a reutilização - Permitindo que os recursos de segurança compartilhados entre várias equipes do Scrum reutilizem os mesmos padrões necessários.

Usando controle e guardrails

A expressão “governança e guardrails” é usada entre os provedores de nuvem como forma de descrever modelos que permitem às equipes utilizar serviços em nuvem à sua maneira. Os conceitos por trás desse modelo também são adaptáveis ao uso de padrões de segurança para permitir que as equipes operem com maior autonomia.

O foco na “governança” é garantir a supervisão dos controles delegados a cada equipe e como ter a garantia de que esses controles sejam implementados corretamente. Quaisquer controles delegados às equipes para projeto e implementação sempre terão o requisito de governança.

Como uma declaração ampla, controles que são bons candidatos para estabelecer como guardrails será

  1. Necessário para lidar com ameaças de ‘alto risco’
  2. Necessário para mitigar ‘Ameaças internas’

Todos os controles que não se enquadram nessas categorias são potenciais candidatos à delegação. Efetivamente, os controles necessários como guardrails são considerados de alta importância. Considere estabelecer esses controles como um serviço de segurança centralizado ou políticas que podem ser aplicadas de forma consistente a todas as equipes.

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

Então, o que acontece quando o controle não funciona

Você vai descobrir invejávelmente que, apesar de todos os seus esforços na concepção de controles, planejamento para implementação e engajamento entre as equipes que os controles não foram implementados ou não são tão eficazes quanto o planejado.

Há uma série de questões que levarão a isso, como

  • Imaturidade da tecnologia.
  • Complexidade na configuração ou tunning da política.
  • Inexperiência dentro das equipes para implementação correta.
  • Mudanças no design que não foram antecipadas.
  • Ou talvez o espelho que você quebrou anos atrás ainda esteja te assombrando.

Por mais que você queira pegar sua cadeira e jogá-la contra a parede, não vai ajudar a resolver o problema (sem mencionar a limitação da carreira).

Então vamos ver como lidamos com isso.

O ágil é construído em torno de falhas para aprender e melhorar sobre elas. Assim, igualmente, você precisa antecipar sucesso e falhas na implementação de controles de segurança.

Controles que não são eficazes podem ser compensados com controles adicionais para reduzir o impacto global das ameaças à segurança.

Esta é uma das razões pelas quais os Padrões de Segurança mantêm a rastreabilidade de volta às ameaças originais que eles estão mitigando. Quando um determinado controle é identificado como não sendo eficaz, então você é capaz de voltar ao padrão de segurança para identificar os controles compensadores associados a essas ameaças.

Se isso não ajudar, então o NIST SP 800-53 também fornece recomendações genéricas para controles alternativos sob “controles relacionados” que você pode utilizar.

Quando um sprint ou iteração não entregar o objetivo de controle, em seguida, coloque a implementação de controles compensadores de volta para o sprint ou backlog do produto.

Os controles incompletos são registrados e rastreados como ‘Dívida Técnica’ (ou potencialmente ‘Dívida de Segurança’) dentro do programa Ágil. Esses controles requerem replantio antes de serem colocados de volta em backlogs de produtos ou sprint.

É importante que a implementação incompleta ou ineficaz dos controles durante os sprints seja rastreada, pois também pode formar a base de avaliações de risco subsequentes.

Exemplo:

A equipe inicia prototipagem de diferentes opções para fornecedores de tecnologia e modelos de serviço para identificar o que funciona melhor. Como parte disso, os controles de segurança identificados como prioridade também são testados. A equipe também avalia a capacidade geral de cada opção de lidar com os controles necessários a partir do padrão de segurança.

A equipe seleciona o BitBucket implantado em instâncias AWS EC2 (IaaS) e continua a amadurecer a implantação atual em um ambiente de Desenvolvimento.

Em iterações sprint posteriores, a solução evolui e é implantada em um ambiente formal de não produção. Controles adicionais também são implementados durante essas iterações.

Para esses controles implementados, buscamos agora validar a eficácia do controle. Alguns controles são mais fáceis do que outros para testar.

Controle SC-08: A confidencialidade e integridade da transmissão é um desses exemplos, que podem ser facilmente validados através de varreduras de vulnerabilidade e análise de registros de fluxo.

Outros controles, no entanto, requerem uma avaliação mais manual.

Controle SC-32: O particionamento do sistema é um desses exemplos, que podem exigir avaliação de múltiplos artefatos, como

  1. Revisão de artefatos de design ou configurações associadas à implementação do controle.
  2. Entreviste desenvolvedores ou administradores na implementação dos controles.
  3. Realização de casos de teste guiados para interpretar os resultados a partir desses resultados.

Durante o teste, identificou-se que o Controle SI-03: A proteção de código malicioso não está configurada corretamente e desativada sprints anteriores.

Os requisitos delta para melhorar esse controle são colocados de volta no backlog e rastreados como dívida técnica no projeto.

Liberação do produto

Determinar a linha de base dos controles necessários para a liberação do produto e a ‘Definição de Feito’ fundamentalmente volta ao apetite de risco para sua organização.

Equilibrar risco versus recompensa não é ciência perfeita. Quando os riscos são identificados e requerem aceitação, então é uma decisão que precisa ser apresentada de volta aos stakeholders do programa.

O fim da revisão de sprint antes da liberação do produto deve realizar uma avaliação dos riscos pendentes. Para esses controles ainda não implementados ou ineficazes, então estes precisarão ser avaliados como parte da postura de segurança para o produto.

Calcular risco é uma metodologia em si e é algo que vou procurar cobrir em detalhes. A maioria das organizações terá seus próprios processos de gestão de riscos e benchmarks que determinarão o processo de avaliação.

Ao conduzir a avaliação, tenha em mente que os princípios da defesa em profundidade na segurança também significa que deve haver vários controles em vigor para mitigar qualquer ameaça particular.

Não ter um controle específico implementado não deve resultar imediatamente em alto risco, pois já deveria haver outros controles adicionais (como parte de uma abordagem em profundidade) para compensar e reduzir o risco.

O projeto Agile deve garantir que os empresários sejam informados da postura de risco para o produto e dos riscos conhecidos para lançamentos na Produção. No mínimo, certifique-se de que os riscos associados à segurança sejam formalmente documentados e registrados sob gerenciamento de riscos.

Exemplo:

Não estamos na fase final do projeto e nos preparando para lançar a solução na Produção para permitir que os desenvolvedores migrem.

O projeto só implementou 80% dos controles originalmente planejados dentro do padrão de segurança, com alguns desses controles considerados semi-eficazes para alcançar o resultado esperado.

Em um controle particular que nunca foi corretamente remediado foi SI-03: Proteção de código malicioso devido a algumas incompatibilidades para determinada versão. O Proprietário do Produto precisa continuar a liberar esta solução para atender aos prazos do projeto e você foi solicitado a avaliar os riscos residuais por não ter esses controles.

Para auxiliar na avaliação, remetemos ao padrão original para onde esse controle foi necessário. Identificamos os seguintes controles compensadores que auxiliam na mitigação dessa ameaça original.

Embora esses controles não removam o risco, ele ajuda a reduzir a probabilidade e o impacto. Artefatos adicionais para testes de segurança também fornecem confiança na postura de segurança da solução para reduzir o risco associado.

A avaliação resultante do risco residual é apresentada de volta às partes interessadas do programa para determinar uma decisão (em última análise, baseada no apetite por risco).

Conclusão

Discutimos muitas das considerações para usar padrões de segurança, com um foco especial no Agile. Como mencionado no início, o uso de padrões de segurança não é exclusivo do Agile, mas é onde eu acredito que eles mostram mais valor.

A nota final a fazer neste guia é entender que os Padrões de Segurança são uma referência para os controles necessários para proteger os ativos. As chances são de que você nunca vai realmente implementar todos eles. O objetivo dos padrões de segurança é fornecer um processo para aplicar gradualmente controles para mitigar ameaças à segurança (sabendo que você nunca as eliminará completamente).

Você precisará constantemente se reajustar, re-planejar e reor priorizar controles ao longo do tempo para lidar com mudanças no cenário de ameaças. Outros fatores, como o ritmo de mudança dentro dos provedores de nuvem, também significa que as organizações continuarão a girar para novas pilhas de tecnologia ou ofertas de serviços.

Os Padrões de Segurança destinam-se a fornecer esse benchmark comum ao longo do tempo. Os padrões precisam ser mantidos atualizados ao longo do tempo, mas requerem menos frequência na mudança.

Há um nível de esforço e investimento necessários para escrever padrões de segurança. Espero que este guia tenha demonstrado o valor desse investimento.

Navegue pelo exemplo existente Padrões de segurança disponíveis, incluindo o padrão de segurança do 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