Modelo de Gerenciamento de Riscos de Segurança e Privacidade (SP-RMM)

O conceito de criação doSP-RMMfoi criar uma metodologia eficiente para identificar, avaliar, reportar e mitigar riscos. Este projeto foi abordado a partir da perspectiva de fazer a pergunta: “Como devo gerenciar o risco?” e foi uma colaboração entre o ComplianceForge e oSecure Controls Framework (SCF). O SP-RMM adota uma abordagem holística para controles, riscos e ameaças como forma de reduzir ou eliminar o tradicional Medo, Incerteza e Dúvida (FUD) que torna muitas avaliações de risco sem sentido. O SP-RMM é livre para uso e está licenciado sob o modelo de licenciamento Creative Commons.

Todas as organizações têm a necessidade de gerenciar riscos. A maioria das organizações é obrigada a gerenciar riscos e esses requisitos vêm de uma ampla gama de origens estatutárias, regulatórias e contratuais. Independentemente do seu setor, existem requisitos para gerenciar o risco de segurança cibernética e a falha no gerenciamento do risco pode deixar sua organização exposta a responsabilidades por não conformidade:

NIST 800-171 e CMMC. Protegendo a CUI em Sistemas de Informação e Organizações Não Federais – Várias seções do NIST SP 800-171 e CMMC exigem que o risco seja avaliado periodicamente (consulte o Apêndice A para obter mais informações sobre isso).
Lei da Federal Trade Commission (FTC). 15 O Código dos EUA § 45 considera ilegais atos ou práticas desleais ou enganosas no comércio ou que afetem o comércio - as más práticas de segurança são abrangidas por este requisito e a não gestão do risco de cibersegurança é uma indicação de más práticas de segurança.
Padrão de Segurança de Dados da Indústria de Cartões de Pagamento (PCI DSS). A Seção #12.2 exige que as empresas realizem uma avaliação formal de risco.
Lei de Portabilidade e Responsabilidade de Seguros de Saúde (HIPAA). A Regra de Segurança (Seção 45 C.F.R. §§ 164.302 – 318) exige que as empresas realizem uma avaliação precisa e completa dos riscos potenciais.
Lei Gramm-Leach-Bliley (GLBA). A Regra de Salvaguarda exige que a empresa identifique e avalie os riscos para as informações do cliente.
Massachusetts MA 201 CMR 17,00. A Seção # 17.03 (2) (b) exige que as empresas “identifiquem e avaliem” riscos internos e externos razoavelmente previsíveis.
Lei de Proteção contra Roubo de Identidade do Oregon. A Seção 646A.622(2)(d)(B)(ii) exige que as empresas avaliem os riscos no processamento, transmissão e armazenamento de informações.

Na gestão de riscos, o velho ditado de “o caminho para o inferno é pavimentado com boas intenções” é muito aplicável. A razão para isso é que, com muita frequência, o pessoal de gerenciamento de riscos é encarregado de gerar avaliações de risco e criar as perguntas a serem feitas nessas avaliações sem ter um conjunto centralizado de controles de segurança cibernética e privacidade em toda a organização para trabalhar. Isso geralmente leva as equipes de risco a assumir riscos e fazer perguntas que não são suportadas pelas políticas e padrões da organização. Por exemplo, uma organização é uma “loja ISO” que opera um Sistema de Gerenciamento de Segurança da Informação (SGSI) baseado na ISO 27002 para governar suas políticas e padrões, mas sua equipe de risco está fazendo perguntas sobre os controles NIST SP 800-53 ou 800-171 que não são aplicáveis à organização. Esse cenário de “compensar riscos” aponta para alguns problemas de governança do programa de segurança:

Se a necessidade de controles adicionais para cobrir riscos for legítima, a organização terá um escopo inadequado e não terá os controles de segurança cibernética e privacidade apropriados para lidar com suas práticas estatutárias, regulatórias, contratuais ou esperadas pelo setor.
Se a organização tiver um escopo adequado, a equipe de risco estará essencialmente criando requisitos que não são suportados pelas políticas e padrões da organização.

SP-RMM: Etapas de Gerenciamento de Riscos

O SP-RMM foi projetado para ter uma abordagem “do início ao fim” para o gerenciamento de riscos, onde o gerenciamento de riscos é dividido em 16 etapas (elas correspondem aoinfográficomostrado acima - clique no gráfico para ver uma versão maior).

1. IDENTIFICAR PRINCÍPIOS
DE GESTÃO DE RISCOS É necessário identificar um ou mais princípios de gestão de riscos que formarão a base de como a entidade aborda seus processos de gerenciamento de riscos. O alinhamento com os princípios de gerenciamento de riscos deve apoiar as políticas e padrões da entidade para os objetivos de gerenciamento de riscos.

As estruturas de risco comuns incluem:

NIST SP 800-37
Norma ISO 31010
COSO 2019
OMB A-123

2. IDENTIFICAR, IMPLEMENTAR E DOCUMENTAR DEPENDÊNCIAS CRÍTICAS.
Este é um processo de várias etapas que envolve identificar, implementar e documentar as dependências críticas necessárias para identificar, avaliar e gerenciar legitimamente o risco:

2A. DEPENDÊNCIAS
DA GESTÃO DOS RISCOS É de importância vital estabelecer as dependências fundamentais da gestão dos riscos. Estes precisam ser padronizados em toda a entidade ou a entidade será prejudicada por definições e expectativas conflitantes:

Defina o limite de “risco aceitável” para sua entidade.
Defina as probabilidades de ocorrência de risco.
Definir os efeitos do impacto do risco.
Defina os níveis de risco.
Defina os vários níveis de gerenciamento de entidades que podem “aprovar” os níveis de risco.
Estabeleça um Plano de Ação e Marcos (POA & M), registro de riscos ou algum outro método para rastrear riscos desde a identificação até a correção.

2B. DEPENDÊNCIAS TECNOLÓGICAS Para apoiar os
processos de gestão de riscos, é necessário estabelecer as dependências tecnológicas que afetam as decisões de gestão de riscos:

Mantenha inventários de hardware e software precisos e atuais.
Mantenha diagramas de rede precisos e atuais.
Manter Diagramas de Fluxo de Dados (DFD) precisos e atuais.
Documente as dependências de tecnologia que afetam as operações (por exemplo, sistemas de suporte, aplicativos e serviços).
Aplicação consistente de controles de segurança e privacidade em toda a entidade.
Consciência situacional da tecnologia relacionada em toda a entidade (por exemplo, níveis de verificação de vulnerabilidades e gerenciamento de patches).

2C. DEPENDÊNCIAS DE NEGÓCIOS Para apoiar os
processos de gerenciamento de riscos, é necessário estabelecer as dependências de negócios que afetam as decisões de gerenciamento de riscos:

É necessário que exista um esquema de classificação de dados que seja consistente em toda a entidade, incluindo uma compreensão do que constitui as “joias da coroa” que exigem requisitos aprimorados de proteção de dados.
A liderança empresarial precisa ditar o suporte tecnológico necessário para que as operações de negócios funcionem corretamente. Isso permite que a liderança em tecnologia e segurança defina “como é o direito” a partir de um nível de maturidade necessário para controles de segurança e privacidade.
Um esforço multidisciplinar precisa estabelecer e manter um programa de Gerenciamento de Risco da Cadeia de Suprimentos (SCRM) que governe a cadeia de suprimentos da entidade. Isso requer envolvimento legal, de compras, de segurança, privacidade e de linha de negócios (LOB).
Políticas e padrões devem ser uniformemente aplicados em toda a entidade.
O gerenciamento de LOB precisa garantir que suas equipes de projeto documentem adequadamente as práticas de negócios e forneçam essas informações ao pessoal de tecnologia, segurança e privacidade, a fim de garantir que exista uma compreensão compartilhada das práticas e requisitos de negócios. Essas informações são necessárias para criar um Plano de Segurança e Privacidade do Sistema (SSPP).
Como “a empresa” possui decisões de gerenciamento de riscos, a entidade precisa garantir que os indivíduos em funções que tomam decisões de gerenciamento de riscos sejam competentes e adequadamente treinados para tomar decisões relacionadas ao risco.

3. FORMALIZAR PRÁTICAS
DE GERENCIAMENTO DE RISCOS Documentar um Programa formal de Gerenciamento de Riscos (PGR) que suporte as políticas e padrões da entidade. O PGR destina-se a documentar a orientação em nível de programa que define “quem, o que, por que, quando e como” sobre as práticas específicas de gerenciamento de riscos da entidade.

4. ESTABELECER UM CATÁLOGO DE RISCOS
É necessário desenvolver um catálogo de riscos que identifique os possíveis riscos que afetam a entidade. No contexto do SP-RMM, “risco” é definido como:

substantivo Uma situação em que alguém ou algo valorizado está exposto a perigo, dano ou perda.
verbo Expor alguém ou algo valorizado a perigo, dano ou perda.

No contexto desta definição de risco, é importante definir as componentes subjacentes desta definição de risco:

Perigo: estado de possivelmente sofrer dano ou lesão
Dano: dano material / físico
Perda: destruição, privação ou incapacidade de usar

Com essa compreensão do que é risco, o Secure Controls Framework (SCF) contém um catálogo de terceiros dois (32) riscos que são mapeados diretamente para cada um dos controles do SCF.

5. ESTABELEÇA UM CATÁLOGO
DE AMEAÇAS É necessário desenvolver um catálogo de ameaças que identifique possíveis ameaças naturais e provocadas pelo homem que afetam os controles de segurança e privacidade da entidade. No contexto do SP-RMM, “ameaça” é definida como:

substantivo Uma pessoa ou coisa susceptível de causar danos ou perigo.
verbo Para indicar danos ou perigos iminentes.

Este catálogo de ameaças é classificado por ameaças naturais e provocadas pelo homem:

6. ESTABELECER UM CATÁLOGO
DE CONTROLES É necessário desenvolver um catálogo de controles de segurança e privacidade que atenda às obrigações estatutárias, regulatórias e contratuais aplicáveis da entidade. Os riscos devem ser mapeados para os controles de segurança e privacidade da entidade. Idealmente, os controles são ponderados, uma vez que nem todos os controles de segurança e privacidade são iguais.

Nota: O SCF tem valores de ponderação de controlo incorporados [1-10], um modelo de maturidade e os controlos SCF escritos em formato de pergunta.

7. DEFINIR METAS
DO MODELO DE MATURIDADE DE CAPACIDADE (CMM) É necessário que uma entidade defina “como é o direito” para o nível de maturidade que espera para os controles de segurança e privacidade implantados. Isso geralmente é definido pelo alinhamento com um Modelo de Maturidade de Capacidade (CMM). Embora existam vários para escolher, o Modelo de Maturidade da Capacidade de Segurança e Privacidade (SP-CMM) do SCF contém critérios de nível de controle para cada um dos níveis do modelo de maturidade.

Os critérios do modelo de maturidade devem ser usados pela organização como referência para avaliar os controles de segurança e privacidade.

8. REALIZAR AVALIAÇÕES
DE RISCO Com as etapas anteriores abordadas, um avaliador aproveitará essas entregas (por exemplo, Programa de Gerenciamento de Riscos (PGR), catálogo de ameaças, catálogo de riscos, catálogos de controles, etc.) para implementar uma capacidade funcional de avaliar o risco em toda a entidade. Que os critérios de avaliação documentados das etapas anteriores existem para orientar o avaliador ao realizar avaliações de risco.

A avaliação de riscos no contexto do SP-RMM aplica-se a vários cenários de avaliação:

Avaliação de Riscos de Segurança Cibernética
Avaliação de Riscos de Terceiros
Avaliação de Impacto sobre a Proteção de Dados (DPIA)
Avaliação de Impacto nas Empresas (BIA)
Avaliação de Impacto na Privacidade (PIA)

9. ESTABELEÇA O CONTEXTO PARA AVALIAR RISCOS
Agora que existe uma metodologia para avaliar o risco, é necessário que o avaliador estabeleça o contexto do Ambiente de Risco de Segurança e Privacidade (SPRE). O SPRE é o ambiente operacional geral que está no escopo da avaliação de riscos. É aqui que as ameaças, riscos e vulnerabilidades afetam as medidas de proteção da entidade.

Um avaliador geralmente pode encontrar essas informações em um Plano de Segurança e Privacidade do Sistema (SSPP) bem documentado. Se o escopo estiver incorreto, o contexto provavelmente também estará incorreto, o que pode levar a uma avaliação de risco equivocada e imprecisa.

10. CONTROLA A AVALIAÇÃO
DE LACUNAS Com base nas obrigações estatutárias, regulatórias e contratuais aplicáveis que impactam o SPRE, espera-se que a entidade tenha um conjunto aplicável de controles para cobrir essas necessidades. Esse conjunto de controles identifica os requisitos no escopo que devem ser avaliados para determinar qual risco existe. Isto é geralmente considerado uma “avaliação de lacunas” quando o avaliador:

Avalia esses controles com base no CATÁLOGO DE AMEAÇAS da entidade para identificar deficiências de controle atuais ou potenciais; e
Utilize o CATÁLOGO DE RISCOS para identificar os riscos aplicáveis, com base nas deficiências de controle identificadas.

11. AVALIE OS RISCOS
Quando as deficiências de controle são identificadas, o avaliador deve utilizar um método aceito pela entidade para avaliar o risco no método mais objetivo possível. Os métodos de avaliação de um controlo de deficiências são geralmente definidos como:

Qualitativo;
Semi-Qualitativo; ou
Quantitativo

Na maioria dos casos, não é viável ter uma avaliação inteiramente quantitativa, pelo que se deve esperar que as avaliações incluam aspetos semiqualitativos ou qualitativos.

Existem vários métodos para realmente avaliar e calcular o risco. O SP-RMM aproveita o trabalho realizado nessa área peloPrograma de Gerenciamento de Riscos (PGR) da ComplianceForge para simplificar as práticas de gerenciamento de riscos.

12. DETERMINE RISCO
No final do dia, o risco precisa ser compreensível. Geralmente, é por isso que o risco é agrupado em um conjunto de categorias predefinidas. O SP-RMM aproveita as seguintes categorias de risco, com base no ComplianceForge RMP:

Baixo
Moderado
Alto
Grave
Extremo

Antes de um relatório de risco poder ser documentado, é muito importante esclarecer se os resultados da avaliação são “risco inerente” ou “risco residual”, uma vez que estes têm significados e implicações totalmente diferentes. Algumas pessoas querem ver o risco inerente e residual, enquanto algumas pessoas só querem ser apresentadas ao risco residual. É por isso que é importante entender que história os escores de risco contam:

RISCO INERENTE: A Probabilidade de Ocorrência (OL), em combinação com o Efeito de Impacto (IE), fornecerá a pontuação de “risco inerente”. Isso é considerado uma pontuação de risco bruta ou não mitigada. É importante notar que o risco inerente não leva em conta qualquer ponderação de controle, a maturidade dos controles implementados ou quaisquer outros fatores atenuantes.
RISCO RESIDUAL: Para entender o “risco residual” que leva em conta a ponderação de controle, a maturidade dos controles implementados e outros fatores atenuantes, é necessário expandir os cálculos de risco inerentes. Para identificar o escore de risco residual, a Probabilidade de Ocorrência (OL) é calculada pelo Efeito de Impacto de Risco (IE), Ponderação de Controle (CW), Nível de Maturidade (ML) e Fatores Atenuantes (MF).

Você pode ler mais sobre as diferenças no cálculo do risco inerente e residual na seção CALCULANDO O RISCO: RISCO INERENTE VS RISCO RESIDUAL deste documento.

13. PRIORIZAR E DOCUMENTAR RISCOS
Uma vez identificado o risco, é necessário priorizar e documentar o(s) risco(s) identificado(s). Geralmente, o risco é priorizado por um dos seguintes:

Emergência;
Elevado; ou
Padrão

Cada entidade é diferente na forma como documenta o risco. As seguintes metodologias são comumente usadas:

Relatório de Avaliação de Riscos;
Plano de Ação e Marcos (POA&M);
Registro de Riscos; e/ou
Plano de Segurança e Privacidade do Sistema (SSPP)

14. IDENTIFIQUE O PÚBLICO
DE GESTÃO APROPRIADO É um problema infeliz e comum dentro da gestão de riscos se deparar com indivíduos que são diretamente impactados pelo risco e simplesmente dizer: “Eu aceito o risco” com a intenção de “desejar” afastar os riscos para que o projeto / iniciativa possa prosseguir sem ter que primeiro abordar deficiências. É por isso que é extremamente importante que, como parte do programa de uma entidade para gerenciar riscos, vários níveis de gerenciamento sejam identificados com autoridade variável, cada um com uma capacidade pré-descrita de tomar decisões de gerenciamento de riscos. Isso ajuda a evitar que os gerentes de baixo nível aceitem imprudentemente o risco que deveria ser reservado para a gerência mais sênior.

Uma estrutura hierárquica comum para decisões de gerenciamento de riscos inclui:

Gerenciamento de Linha
Alta Administração
Gestão Executiva
Conselho de Administração

15. GESTÃO DETERMINA TRATAMENTO DE RISCOS A
gestão de riscos é uma decisão de gestão:

A segurança cibernética e a TI geralmente não “possuem” o risco identificado.
A responsabilidade final está na estrutura de gerenciamento da equipe / departamento / linha de negócios que “possui” o processo de negócios ou a tecnologia que está em uso.

As opções comuns de tratamento de risco incluem:

Reduzir o risco a um nível aceitável
Evite o risco
Transferir o risco para outra parte
Aceite o risco

Certo ou errado, a gerência é, em última análise, capaz de decidir como o risco deve ser tratado. Onde isso beneficia o pessoal de segurança, tecnologia e privacidade é a documentação “sair da prisão” que as avaliações de risco de qualidade e o gerenciamento de riscos podem fornecer. Em vez de a liderança executiva colocar a culpa no CIO ou CISO, a documentação de gerenciamento de riscos de qualidade pode provar que medidas razoáveis foram tomadas para identificar, avaliar, relatar e mitigar o risco, o que coloca firmemente a responsabilidade de volta na equipe de gerenciamento da equipe / departamento / linha de negócios que “possui” o risco.

16. IMPLEMENTAR E DOCUMENTAR O TRATAMENTO
DE RISCOS Ao gerenciar o risco, ele deve ser mantido o mais simples possível. Realisticamente, o tratamento de riscos é “aberto” ou “fechado”, mas às vezes pode ser útil fornecer mais granularidade em itens abertos para ajudar na elaboração de relatórios sobre atividades de gerenciamento de riscos:

Aberto (risco inaceitável)
Aberto (risco aceitável)
Closed

Calculating Risk: Inherent Risk vs Residual Risk

It is possible to use a straightforward method to calculate risk using SP-RMM. Both Inherent Risk & Residual Risk map into the SP-RMM Risk Matrix (graphic shown below.

For Inherent Risk, find the cell where Occurrence Likelihood (OL) intersects Impact Effect (IE) to determine the risk level.
For Residual Risk, utilize the calculated Residual Risk values (see chart above) to determine the corresponding risk level.

STEP 1: CALCULATE THE INHERENT RISK
To determine the inherent risk, calculate the Occurrent Likelihood (OL) by the Impact Effect (IE).

STEP 2: ACCOUNT FOR CONTROL WEIGHTING
Not all security and privacy controls are equal, so it is important to apply weighting to the importance of controls. The SCF contains pre-defined control weightings that can be edited for an entity’s unique requirements. This Control Weighting (CW) is multiplied by the inherent risk score from Step 1.

STEP 3: ACCOUNT FOR MATURITY LEVEL TARGETS
The next step is meant to determine a weighted maturity score that takes control maturity into account. The more mature a control is, the greater the risk should be reduced. Maturity Level (ML) is multiplied by the value determined in Step 2.

ETAPA 4: CONTABILIZAR OS FATORES ATENUANTES PARA DETERMINAR O RISCO
RESIDUAL A etapa final é levar em conta os Fatores Atenuantes (MF), que podem ser controles compensadores ou outras considerações de processo/tecnologia que atenuam o risco, específicas para as ameaças identificadas.

O cálculo final para determinar o risco residual é: OL * IE * CW * ML * MF

Aproveitando a estrutura do Programa de Gerenciamento de Riscos (RMP) da ComplianceForge, é simples traduzir o valor calculado da pontuação de risco residual em uma categoria de risco fácil de usar:

SP-RMM: Aplicabilidade ao NIST 800-171 & CMMC

Uma necessidade imediata para muitas organizações é a conformidade com o NIST SP 800-171 e a Certificação de Modelo de Maturidade em Segurança Cibernética (CMMC). O Modelo de Gerenciamento de Riscos de Segurança e Privacidade (SP-RMM) é uma ferramenta que pode ser usada para atender aos seguintes requisitos:

PROCESSOS E PRÁTICAS DE CMMC

Esses processos e práticas do CMMC são diretamente impactados pelo SP-RMM:

PRÁTICAS DO “CMMC 2.0” (NÍVEIS 1 e 2)

AT.2.056. Assegurar que os gestores, administradores de sistemas e utilizadores de sistemas organizacionais sejam informados dos riscos de segurança associados às suas atividades e das políticas, normas e procedimentos aplicáveis relacionados com a segurança desses sistemas.
RM.2.141. Avaliar periodicamente o risco para as operações organizacionais (incluindo missão, funções, imagem ou reputação), ativos organizacionais e indivíduos, resultante da operação de sistemas organizacionais e do processamento, armazenamento ou transmissão de CUI associados.
RM.2.143. Corrigir vulnerabilidades de acordo com as avaliações de risco.
CA.2.159. Desenvolver e implementar planos de ação (por exemplo, POA&M) projetados para corrigir deficiências e reduzir ou eliminar vulnerabilidades nos sistemas organizacionais.
CA.3.161. Monitorar os controles de segurança em uma base contínua para garantir a eficácia contínua dos controles.

CONTROLES DO NIST SP 800-171

Esses controles NIST SP 800-171 são diretamente afetados pelo SP-RMM:

3.11.1. Avaliar periodicamente o risco para as operações organizacionais (incluindo missão, funções, imagem ou reputação), ativos organizacionais e indivíduos, resultante da operação de sistemas organizacionais e do processamento, armazenamento ou transmissão associados de CUI.
3.11.2. Procurar vulnerabilidades em sistemas e aplicações organizacionais periodicamente e quando forem identificadas novas vulnerabilidades que afetem esses sistemas e aplicações.
3.11.3. Corrigir vulnerabilidades de acordo com as avaliações de risco.
3.12.1. Avaliar periodicamente os controles de segurança em sistemas organizacionais para determinar se os controles são eficazes em sua aplicação.
3.12.2. Desenvolver e implementar planos de ação destinados a corrigir deficiências e reduzir ou eliminar vulnerabilidades nos sistemas organizacionais.
3.12.3. Monitorizar os controlos de segurança numa base contínua, a fim de garantir a eficácia contínua dos controlos.

Artigo Origin al