CMMC Kill Chain - Criando um plano de projeto para sua avaliação CMMC

O conceito de criar uma “CMMC **Kill Chain” era criar uma prova de conceito para uma maneira eficiente de planejar um roteiro para passar com sucesso em uma avaliação CMMC. O resultado final é uma abordagem viável para qualquer um usar, a fim de criar um plano de projeto priorizado para as atividades de pré-avaliação do CMMC.**

Por que “CMMC Kill Chain” você pergunta? O conceito de uma cadeia de morte é simplesmente que é mais fácil parar e evitar mais danos se essas atividades maliciosas forem descobertas mais cedo, em vez de mais tarde. Quando você olha para a tolerância zero do CMMC para deficiências, se você tiver uma única deficiência em um processo ou prática, você falhará em sua avaliação do CMMC. Dada essa realidade com o CMMC, a intenção de usar o CMMC Kill Chain éque, se você aplicar uma abordagem priorizada e em fases para atividades de pré-avaliação relacionadas ao CMMC, é possível evitar retrabalho e falhas em cascata abordando dependências no início do processo. A linha inferior é que este modelo divide o CMMC em 24 etapas principais, que podem ser traduzidas em um plano de projeto.

Este projeto foi abordado a partir da perspectiva de: “Se eu fosse contratado em uma empresa, qual seria o meu plano para começar do nada para levar uma empresa para onde ela poderia passar por uma avaliação?” Todas as práticas e processos do CMMC são abordados dentro da CMMC Kill Chain, mas é claro que a priorização e o “bucketing” das práticas em fases é um esforço subjetivo e nem todos podem concordar com essa abordagem. Basta entender que cada organização é diferente e você invariavelmente precisará modificar a abordagem para atender às suas necessidades específicas.

Aplicando o modelo Kill Chain ao CMMC

Você pode estar se perguntando como um modelo de cadeia de morte se aplica ao CMMC. A questão raiz diz respeito à situação enfrentada por muitos profissionais de TI e segurança cibernética que estão olhando para 2021 com medo: esses profissionais de TI / segurança cibernética da linha de frente atualmente não sabem por onde começar, muito menos que caminho precisam seguir para passar por uma avaliação do CMMC. Há uma infinidade de orientações “O que é CMMC?” no LinkedIn, webinars e na Internet em geral, mas há uma falta de orientação prática de COMO você deve realmente “fazer CMMC” em termos realistas. O CMMC Kill Chain foi projetado para fornecer um roteiro que seria utilizável para (1) qualquer pessoa que esteja começando ou (2) qualquer pessoa que queira verificar sua abordagem. Este modelo também será adicionado ao site doCMMC Center of Awesomenessse você estiver procurando por ele no futuro. Você também pode baixá-lo clicando na imagem abaixo para obter uma versão em PDF do gráfico e da descrição.

Ferramenta de Planejamento de Projetos CMMC

A premissa do CMMC Kill Chain é construir um plano de projeto viável a partir da perspectiva de uma lista priorizada de tarefas, a fim de se preparar com sucesso e passar por uma avaliação do CMMC. Erros ou aventuras equivocadas com pessoas, processos e tecnologia no início das atividades de prática/implementação de processos do CMMC terão efeitos em cascata, de modo que a Kill Chain do CMMC destina-se a fornecer um modelo para priorizar as atividades de pré-avaliação relacionadas ao CMMC. O CMMC Kill Chain divide o CMMC em 24 etapas principais, que podem ser traduzidas em um plano de projeto.

Fases do CMMC Kill Chain

Aqui estão as informações sobre as 24 fases da CMMC Kill Chain (estas correspondem ao diagrama de imagem):

Defina o que é CUI para o seu caso de negócios específico. Isso deve ser autoexplicativo e é baseado em seu(s) contrato(s).
Estabeleça o escopo do limite de avaliação do CMMC. Isso tem quatro etapas de subcomponente: (1) Criar um DFD (Diagrama de Fluxo de Dados) que mostre como o CUI flui do DoD até os subcontratados; (2) Criar um inventário detalhado de ativos para todos os sistemas, aplicativos e serviços para ativos dentro e fora do escopo; (3) Criar um diagrama de rede detalhado que inclua onde o CUI é armazenado, transmitido e/ou processado; e (4) Inventário de Provedores de Serviços de Terceiros (TSP) para determinar o acesso do TSP a sistemas, aplicativos e/ou serviços CUI e/ou no escopo.
Documente o Meio Ambiente. Isso tem duas etapas de subcomponente: (1) Comece a preencher o Plano de Segurança do Sistema (SSP); e (2) Criar um Plano de Ação e Marco (POA&M) para rastrear e corrigir deficiências.
Defina a arquitetura de rede. Isso envolve a implementação de uma arquitetura de rede que garanta que ela seja construída com base em princípios de engenharia seguros e enclaves para proteger informações confidenciais (por exemplo, FCI/CUI). Deficiências de POA&M e procedimentos de documentos.
Planeje, identifique lacunas e priorize recursos. Isso tem seis etapas de subcomponentes: (1) Definir obrigações estatutárias, regulatórias e contratuais aplicáveis (incluindo DFARS, FAR, NIST 800-171 e CMMC); (2) Realizar uma avaliação de lacunas a partir das obrigações estatutárias, regulamentares e contratuais aplicáveis; (3) Desenvolver e implementar políticas e normas para abordar as obrigações estatutárias, regulamentares e contratuais aplicáveis; (4) Identificar as Pessoas, Processos e Tecnologia (PPT) necessárias e adequadamente dimensionadas; (5) Desenvolver e implementar um plano de recursos (por exemplo, plano de negócios, orçamento, roteiro, etc.) para cumprir as obrigações de conformidade; e (6) Priorizar os objetivos do plano de recursos para os requisitos de PPT. POA&M quaisquer deficiências desta fase.
Desenvolver Procedimentos. Isso tem duas etapas de subcomponentes: (1) Desenvolver e implementar procedimentos para implementar políticas e padrões; e (2) Definir processos para lidar com segurança com CUI. POA&M quaisquer deficiências desta fase.
Gestão de Riscos. Desenvolver e implementar um Programa de Gerenciamento de Riscos (PGR) para identificar, avaliar e remediar riscos. Deficiências de POA&M e procedimentos de documentos.
Controle de Alterações. Desenvolver e implementar processos de controle de mudanças, incluindo um Conselho de Controle de Mudanças (CCB). Deficiências de POA&M e procedimentos de documentos.
Resposta a incidentes. Desenvolver e implementar capacidades de resposta a incidentes para detectar, responder e recuperar de incidentes. Deficiências de POA&M e procedimentos de documentos.
Consciência Situacional. Desenvolver e implementar recursos de consciência situacional por meio da coleta e análise de logs (por exemplo, SIEM). Deficiências de POA&M e procedimentos de documentos.
Endurecimento do sistema. Identifique, construa e implemente configurações de linha de base seguras (por exemplo, padrões de proteção) para todas as plataformas de tecnologia. Deficiências de POA&M e procedimentos de documentos.
Gestão Centralizada. Criar e implementar GPOs (Objetos de Diretiva de Grupo) para o Microsoft Active Directory (AD). Deficiências de POA&M e procedimentos de documentos.
Gerenciamento de Identidade e Acesso. Desenvolver e implementar o Gerenciamento de Identidade e Acesso (IAM) para abordar o “privilégio mínimo” e o Controle de Acesso Baseado em Função (RBAC). Deficiências de POA&M e procedimentos de documentos.
Manutenção. Desenvolver e implementar práticas de manutenção proativas. Deficiências de POA&M e procedimentos de documentos.
Gerenciamento de Superfície de Ataque / Gerenciamento de Vulnerabilidades. Desenvolver e implementar práticas de Gerenciamento de Superfície de Ataque (ASM). Deficiências de POA&M e procedimentos de documentos.
Gestão de Ativos. Desenvolver e implementar práticas de gerenciamento de ativos de tecnologia. Deficiências de POA&M e procedimentos de documentos.
Segurança de Pessoal. Trabalhe com Recursos Humanos (RH) para garantir que os requisitos de segurança de pessoal sejam integrados às operações de RH. Deficiências de POA&M e procedimentos de documentos.
Segurança de Rede. Desenvolver e implementar práticas de segurança de rede. Deficiências de POA&M e procedimentos de documentos.
Continuidade de Negócios. Desenvolver e implementar recursos de continuidade de negócios. Deficiências de POA&M e procedimentos de documentos.
Criptografia. Desenvolver e implementar recursos de gerenciamento de chaves criptográficas e criptografia de dados. Deficiências de POA&M e procedimentos de documentos.
Segurança Física. Desenvolver e implementar práticas de segurança física. Deficiências de POA&M e procedimentos de documentos.
Inteligência de Ameaças. Desenvolver e implementar uma capacidade de inteligência de ameaças. Deficiências de POA&M e procedimentos de documentos.
Treinamento de conscientização de segurança. Construa e mantenha uma força de trabalho voltada para a segurança por meio de treinamento e conscientização. Deficiências de POA&M e procedimentos de documentos.
Auditoria Interna. Crie e mantenha uma capacidade de “auditoria interna” ou Garantia da Informação (IA) para governar os controles. Deficiências de POA&M e procedimentos de documentos.

Plano de fundo sobre a lógica usada neste modelo

Aqui está uma rápida explicação sobre alguns dos raciocínios usados para este modelo:

Você não pode avaliar legitimamente mudanças, vulnerabilidades, ameaças, etc. sem primeiro ter um controle sobre o gerenciamento de riscos e um limite de risco definido. O gerenciamento de riscos é o principal alicerce do qual outras práticas dependem.
Depois de ter práticas sólidas de gerenciamento de riscos, o controle de mudanças é a segunda fase mais importante a ser abordada, uma vez que isso é necessário para alterar legitimamente outras práticas e você precisa ser capaz de documentar suas alterações e rastrear problemas abertos em um POA & M (por exemplo, evidência do devido cuidado).
A partir daí, a suposição é que você descobrirá problemas, portanto, a capacidade de resposta a incidentes precisa existir (observe - os requisitos de relatório de incidentes do DFARS já se aplicam se você atualmente armazenar, processar e/ou transmitir CUI como parte de um contrato do DoD).
O log de eventos/SIEM é o próximo e precisa existir antes das configurações seguras, já que os logs precisam ser enviados para algum lugar. Você precisa ter essa infraestrutura de log em vigor antes de entrar em configurações seguras.
Configurações seguras e gerenciamento centralizado (por exemplo, GPOs) quase andam de mãos dadas, mas antes que você possa gerenciar centralmente as configurações, elas precisam ser definidas e padronizadas.
Em seguida, o gerenciamento de identidade e acesso precisa ser bloqueado para garantir que os aspectos de privilégios mínimos e RBAC sejam implementados. A razão pela qual o IAM vem após configurações seguras é devido à solução de problemas - se você tiver compilações seguras “padrão ouro” para trabalhar, é mais fácil atribuir permissões/RBAC que funcionarão com essas compilações. A alternativa é que suas novas configurações quebrem seu IAM/RBAC, o que é ruim. Evite isso.
Realisticamente, você não pode fazer o gerenciamento de vulnerabilidades sem primeiro ter recursos sólidos de manutenção, portanto, a manutenção precisa ser formalizada com integrações de controle de alterações. A manutenção precisa estar ligada ao gerenciamento de mudanças, que tem um componente de gerenciamento de riscos.
O conceito de gerenciamento de vulnerabilidades é amplo e é melhor resumido pelo termo “gerenciamento de superfície de ataque”, onde você está fazendo o que pode para minimizar as maneiras pelas quais um adversário pode atacar. Isso depende de práticas de manutenção e gerenciamento de mudanças estarem em vigor e operando.
A partir daí, as fases restantes são relativamente subjetivas - realmente é. No entanto, a função de “auditoria interna” realisticamente precisa vir por último, onde o teste de validação de controle avalia o quão bem os controles são implementados. Isso pode ajudar a servir como uma função de pré-auditoria.

Documentação do NIST 800-171 e CMMC feita corretamente - soluções escaláveis que são acessíveis, abrangentes e eficientes

Aproveitamos a Estrutura Hierárquica de Governança de Segurança Cibernéticapara desenvolver os componentes de documentação necessários que são fundamentais para demonstrar evidências de devida diligência e devido cuidado para nossos clientes. Essa metodologia para a documentação reconhece a interconectividade que existe entre políticas, objetivos de controle, padrões, diretrizes, controles, riscos, procedimentos e métricas. Este modelo de documentação funciona bem com ISO 27002, NIST CSF,NIST 800-171, NIST 800-53, FedRAMP, CIS CSC Top 20, PCI DSS, Secure Controls Framework (SCF) e outras estruturas de controle.

Essencialmente, o ComplianceForge simplificou o conceito da natureza hierárquica da documentação de segurança cibernética e privacidade que você pode ver no diagrama para download mostrado abaixo. Isso ajuda a demonstrar a natureza exclusiva desses componentes, bem como as dependências existentes. Você pode baixar o exemplo para entender melhor como escrevemos nossa documentação que vincula as políticas até as métricas. Essa é uma ótima solução para qualquer organização que atualmente use ou migre para uma plataforma de Governança, Risco e Conformidade (GRC) ou Gerenciamento Integrado de Riscos (IRM) para ajudar a automatizar suas práticas de governança.

O NIST 800-171 destina-se a forçar os empreiteiros a aderir aos requisitos de segurança razoavelmente esperados que estão em uso pelo governo dos EUA há anos. O NIST 800-171 estabelece um conjunto básico de expectativas e mapeia esses requisitos para o NIST 800-53, que é o padrão de fato para os controles de segurança cibernética do governo dos EUA. De certa forma, isso é uma coisa boa, já que o governo dos EUA não está reinventando a roda com novos requisitos. Em vez disso, o DoD selecionou controles de nível moderado de um conjunto existente de melhores práticas reconhecidas, comumente usadas em todo o DoD e agências federais. A longo prazo, isso ajudará o governo dos EUA e as empresas privadas a falar a mesma linguagem para a segurança cibernética.

A linha inferior é que o NIST 800-171 cria um conjunto padronizado e uniforme de requisitos para todas as necessidades de segurançade Informações Não Classificadas Controladas (CUI). Destina-se a colmatar deficiências comuns na gestão e proteção de informações não classificadas que estão a ser armazenadas, transmitidas ou processadas por empresas privadas.

Artigo Original