Escrevendo um modelo de ameaça

Olá a todos, continuamos nossa série de artigos sobre "segurança do papel". Hoje falaremos sobre o desenvolvimento de um modelo de ameaça. Se o objetivo da leitura deste artigo é adquirir habilidades práticas, é melhor fazer o download imediato de nossos modelos de documentos , que também contêm um modelo de modelo de ameaça. Mas mesmo sem um modelo em mãos, o artigo também pode ser encontrado para fins educacionais.

Por que precisamos de um modelo de ameaça?

A necessidade de desenvolver um modelo de ameaça é regulada por vários documentos regulatórios. Aqui estão alguns deles.

Parte 2 do Artigo 19 da Lei nº 152-FZ “Sobre Dados Pessoais”:

2. A segurança dos dados pessoais é alcançada, em especial:

1) a determinação de ameaças à segurança de dados pessoais durante o processamento em sistemas de informação de dados pessoais;

Composição e conteúdo de medidas organizacionais e técnicas para garantir a segurança dos dados pessoais durante o processamento em sistemas de informação de dados pessoais (aprovado por despacho do FSTEC da Rússia de 18 de fevereiro de 2013 no 21):

4. As medidas para garantir a segurança dos dados pessoais são implementadas, entre outras coisas, por meio do uso de ferramentas de proteção de informações no sistema de informações que passaram no procedimento de avaliação da conformidade da maneira prescrita, nos casos em que o uso de tais ferramentas é necessário para neutralizar as ameaças atuais à segurança dos dados pessoais.

Requisitos para a proteção de informações que não constituam segredos de estado contidos em sistemas de informações estatais (aprovado pelo FSTEC da Rússia em 11 de fevereiro de 2013, nº 17)

Formação de requisitos de segurança da informação ... incluindo:
...
identificação de ameaças à segurança da informação , cuja implementação pode levar a uma violação da segurança da informação no sistema de informações e o desenvolvimento com base em um modelo de ameaças à segurança da informação;
...

Requisitos para proteção de informações em sistemas de controle automatizado para processos tecnológicos e de produção em instalações críticas, instalações potencialmente perigosas, bem como instalações que representam um perigo aumentado para a vida humana, a saúde e o meio ambiente (aprovado por ordem do FSTEC da Rússia de 14 de março de 2014) 31):

A formação de requisitos para segurança da informação em um sistema de controle automatizado ... incluindo:
...
identificação de ameaças à segurança da informação, cuja implementação pode levar a uma violação do funcionamento normal do sistema de controle automatizado e o desenvolvimento de um modelo de ameaças à segurança da informação com base;

Requisitos para garantir a segurança de objetos significativos da infraestrutura de informações críticas da Federação Russa (aprovado por despacho do FSTEC da Rússia de 25 de dezembro de 2017, nº 239):

11. O desenvolvimento de medidas organizacionais e técnicas para garantir a segurança de um objeto significativo é realizado pelo sujeito da infraestrutura de informações críticas ... e deve incluir:

a) análise de ameaças à segurança da informação e desenvolvimento de um modelo de ameaças à segurança da informação ou seu refinamento (se houver);

Portanto, a conclusão é simples: para qualquer sistema de informação que, de alguma forma, seja protegido de acordo com a lei, é necessário desenvolver um modelo de ameaça.

Conteúdo do modelo de ameaças

Descobrimos a necessidade de criar um documento, vamos ver o que a legislação prescreve para seu conteúdo. Aqui, curiosamente, tudo é bastante escasso.

Como exemplo didático de descrição do conteúdo de um modelo de ameaça, podemos citar 17 ordens do FSTEC:

O modelo de ameaças à segurança da informação deve conter uma descrição do sistema de informações e suas características estruturais e funcionais, bem como uma descrição das ameaças à segurança da informação, incluindo uma descrição dos recursos dos violadores (modelo do violador), possíveis vulnerabilidades do sistema de informações, maneiras de implementar ameaças à segurança da informação e as consequências da violação das propriedades de segurança da informação.

Você não acredita, mas é tudo. Mas, por outro lado, embora não haja muito texto, é bastante informativo. Vamos reler e anotar o que deve estar no nosso modelo de ameaça:

• descrição do sistema de informação;
• características estruturais e funcionais;
• Descrição de ameaças à segurança
• modelo de intruso;
• possíveis vulnerabilidades;
• maneiras de implementar ameaças;
• consequências da violação das propriedades de segurança da informação.

Isso está de acordo com a lei, que exige o FSTEC. Existem também requisitos adicionais do FSB (sobre eles um pouco mais tarde) e alguns requisitos e desejos não oficiais do FSTEC que encontramos no processo de concordar com os modelos de ameaças dos sistemas de informações estatais.

Parte introdutória do modelo de ameaça

Bem, vamos ao conteúdo do documento.

Penso na página de rosto, uma lista de abreviações, termos e definições, tudo está claro. Embora, talvez, valha a pena elaborar ... de repente a página de título.

No modelo, é assinado pelo chefe do proprietário do sistema de informação. Não é só isso.

Decreto do Governo da Federação Russa de 11 de maio de 2017 No. 555:

4. Os termos de referência para a criação do sistema e o modelo de ameaças à segurança da informação são aprovados pelo funcionário da autoridade executiva, que é investida da autoridade relevante.

Naturalmente, se o sistema de informações não for de propriedade do Estado e o operador do sistema não for uma autoridade executiva, qualquer pessoa poderá assinar um modelo de ameaça. É só que nos deparamos repetidamente quando, sujeito às condições acima (sistema de informações estatais da autoridade executiva), o cliente nos pediu para alterar a página de rosto para que apenas os representantes da empresa licenciada (nossa) assinassem lá. Eu tive que explicar por que o FSTEC retornaria esse modelo de ameaças para revisão.

Seção "Suporte normativo e metodológico"

Aqui, eu gostaria de lembrar que o modelo de ameaça pode ser desenvolvido para sistemas muito diferentes - do ISDN ao KII. Portanto, a lista de documentos regulamentares pode variar. Por exemplo, se estamos desenvolvendo um modelo de ameaça para sistemas automatizados de controle de processos, 21 e 17 ordens do FSTEC devem ser removidas do modelo e a 31ª deve ser adicionada.

Os documentos marcados com a abreviação "SKZI" são documentos regulamentares do FSB que regem o manuseio de ferramentas de criptografia. Se as criptomoedas não forem usadas no sistema de informações (agora é uma raridade, mas ainda assim), esses documentos regulatórios deverão ser removidos da lista.

Um erro comum aqui é a adição de vários GOSTs e outros documentos regulatórios (eles gostam muito de inserir o STR-K aqui), que nada têm a ver com a modelagem de ameaças. Ou documentos cancelados. Por exemplo, geralmente em modelos de ameaças, é possível encontrar na lista de documentos regulatórios as chamadas FSB "Recomendações Metodológicas ..." e "Requisitos Típicos ...", que não são relevantes há muito tempo.

Disposições Gerais

Aqui, o modelo apresenta a água padrão - por que precisamos de um modelo de ameaça etc. O que precisamos focar aqui é um comentário sobre o tipo de informação em consideração. Por padrão, a opção mais comum é apresentada no modelo - dados pessoais (PD). Mas o sistema pode não ter dados pessoais, mas pode haver outras informações confidenciais (IC), e as informações podem não ser confidenciais, mas protegidas (IC) de acordo com outras características - integridade e disponibilidade.

Descrição do Sistema de Informação

Aqui você pode encontrar informações gerais sobre o sistema de informações - onde ele está localizado, como é chamado, quais dados e qual classe (nível de segurança, categoria) é processada. Aqui, é claro, muitos estão interessados ​​em quão detalhadamente é necessário descrever o sistema de informação.

No processo de várias aprovações de modelos de ameaças para sistemas de informações estaduais, desenvolvemos uma solução para isso - deve haver um meio termo. Não deve ser uma pasta de cópia do passaporte técnico indicando os números de série do equipamento técnico. Mas, por outro lado, uma pessoa que não está familiarizada com o sistema, que lê sua descrição no modelo de ameaça, deve entender mais ou menos como esse sistema funciona.

Um exemplo:

A parte do servidor do sistema de informações da Nipel é um cluster de servidores físicos no qual o hipervisor ESXi 6.x está implementado. A parte do servidor dos principais serviços do sistema de informação é fornecida por servidores virtuais (nomes de servidores) sob o controle de sistemas operacionais (lista de SO). O principal software que implementa os processos de processamento é (nome do software). O software aplicativo é um aplicativo cliente-servidor. A parte do cliente funciona como um cliente espesso nas estações de trabalho do usuário executando sistemas operacionais (lista de SO). Os usuários obtêm acesso ao sistema de informações, tanto da rede local quanto da Internet, usando canais de comunicação seguros. Em geral, o sistema de informação funciona como mostrado no diagrama.

O esquema funcional (não topológico!) Do sistema de informação é aplicado.

É assim que geralmente se parece. Estilo e outros detalhes, é claro, podem ser muito diferentes, o principal é a informação que pode ser extraída da descrição.

Há também uma seção "Segurança de instalações". Aqui, descrevemos como as instalações são protegidas durante o horário de trabalho e fora do horário comercial - videovigilância, ACS, segurança, vigia, alarme e tudo.

As seções do FSB “Determinando a relevância do uso da proteção de informações criptográficas para garantir a segurança dos dados pessoais” e “Objetos adicionais de proteção” também estão incluídas no modelo de modelo de ameaça. Se a criptografia não for usada, essas seções serão simplesmente removidas, se usadas, não haverá nada especial a ser alterado, em geral, e você não precisará digitar o nome do sistema de informações.

A seção "Princípios do modelo de ameaça" também não pode ser alterada. Observe que existe uma opção para casos em que criptomoedas são usadas no sistema e quando não. Escolha o que você precisa e siga em frente.

Intruder Model

Aqui você pode dividir esta parte em clássica e nova. Clássico é aquele em que os potenciais violadores das categorias 1, 2 e além são descritos. De fato, essa parte do modelo de invasor é deixada no modelo apenas porque os reguladores gostam quando é. O valor prático é representado pela seção “Violadores de acordo com o banco de dados das ameaças do FSTEC da Rússia”.

Esta seção é de valor prático porque as próprias ameaças do banco de dados de ameaças FSTEC (doravante denominado BDU) estão vinculadas a violadores com baixo, médio e alto potencial. A seção em si é uma cópia e pasta de descrições das características dos violadores com baixo, médio e alto potencial. A seguir, é apresentada a nossa maneira "especialista" favorita - qual ofensor é relevante para nós. Na verdade, o compilador seleciona o invasor “a olho”, porque simplesmente não existem métodos para escolher o agressor.
Não forneceremos essas descrições na íntegra aqui, tentaremos formular brevemente como os potenciais violadores diferem. Além de diferenciar em potencial, os infratores ainda são externos e internos.

O hacker mais talentoso do mundo que usa perfeitamente as ferramentas existentes e pode criar suas próprias ferramentas é de repente um intruso com baixo potencial. Um invasor com os mesmos recursos, mas ter algumas informações privilegiadas sobre o sistema já é um potencial médio. A frase principal que distingue o potencial médio do baixo: "Eles têm acesso a informações sobre as características e características estruturais e funcionais do funcionamento do sistema de informação". Aqui você precisa pensar cuidadosamente sobre a probabilidade de vazamento dessas informações. Os criminosos de alto potencial, em suma, são principalmente agências de inteligência. Aqui temos a oportunidade de atrair organizações científicas especializadas e obter informações de campos físicos, e isso é tudo.

Em situações realistas, o potencial do invasor é baixo ou médio.

Seções "FSB"

A seguir, estão as seções "Recursos generalizados das fontes de ataque" e "Implementação de ameaças à segurança da informação identificadas pelos recursos das fontes de ataque". Essas seções não são necessárias se não forem usadas criptomoedas. Se, no entanto, forem utilizados, os dados iniciais e, geralmente, as tabelas para essas seções não precisam ser inventadas, elas são retiradas do documento normativo do FSB “Recomendações metodológicas sobre o desenvolvimento de atos legais regulatórios que definem ameaças à segurança de dados pessoais relevantes para o processamento de dados pessoais em informações. sistemas de dados pessoais operados no curso das respectivas atividades ”(aprovado pela gerência do 8º Centro do Serviço Federal de Segurança da Rússia em 31 de março de 2015, nº 149/7/2 / 6-432).

Nossa verdade no modelo, o resultado é um pouco diferente do padrão, fornecido no documento FSB acima mencionado.

O objetivo final dessas seções é estabelecer uma classe de meios de proteção de informações criptográficas (CPSI), que podem ser usados ​​no sistema em questão. Essa classe depende diretamente dos recursos do violador e é definida de acordo com a ordem 378 do FSB (para dados pessoais, mas para outros tipos de informações simplesmente não existem tais requisitos).

Na maioria das vezes, a classe aplicável de criptomoedas é KC3. Agora vamos lhe dizer o porquê.

Em geral, no documento "Composição e conteúdo de medidas organizacionais e técnicas para garantir a segurança dos dados pessoais quando são processados ​​em sistemas de informações de dados pessoais usando proteção de informações criptográficas, os meios necessários para atender aos requisitos de proteção de dados pessoais estabelecidos pelo Governo da Federação Russa para cada nível de segurança" ( aprovada por despacho do Serviço Federal de Segurança da Rússia de 10 de julho de 2014 nº 378) a classe de proteção de informações criptográficas para o sistema em questão é estabelecida, primeiramente, com base em e ameaças, e em segundo lugar, com base em possíveis infratores.

Não vamos nos deter nos tipos de ameaças em detalhes; há muita informação na Internet. Vamos nos concentrar no fato de que existem três tipos de ameaças e por gancho ou por bandido, se você planeja usar criptografia, precisa executar o terceiro tipo de ameaça (ameaças irrelevantes associadas a recursos não declarados em aplicativos e software em todo o sistema). Porque

Como a ordem 378 FSB:

• Classe CPS KA nos casos em que ameaças do tipo 1 são relevantes para o sistema de informação;
• CIPF da classe KV e superior nos casos em que ameaças do tipo 2 são relevantes para o sistema de informação;
• CIPF da classe KS1 e superior nos casos em que ameaças do tipo 3 são relevantes para o sistema de informação.

Parece claro, mas qual é o problema? O problema é que você não pode comprar CPS das classes KA1, KV1 e KV2 exatamente assim, mesmo se você tiver muito dinheiro que elas custam.

Faremos uma pequena "investigação". Faça o download do novo registro de ferramentas de proteção de informações criptográficas . Estamos procurando a classe de proteção de informações criptográficas KA1. A primeira pesquisa encontrou "Codificador de hardware e software M-543K". Vamos ao Google, escrevemos "Compre o codificador de hardware e software M-543K" - uma falha. Tentando "comprar" a próxima criptomoeda - novamente, falha. Simplesmente dirigimos “a criptomoeda KA1 para comprar” - uma falha. Nós obtemos apenas links para outras classes de criptografia KS1-KC3 ou para fóruns onde a criptografia é discutida. Mas o fato é que, como já mencionado, você não pode comprar classes SCZI de espaçonaves e espaçonaves, apenas através de unidades militares especializadas. Por que essas criptomoedas geralmente foram mencionadas no documento sobre dados pessoais ainda não está claro. Portanto, na ISDN comum, é apenas o terceiro tipo de ameaça.

Com KA e KV descobri, mas por que KC3, e não KS2 e KS1? Aqui a segunda condição já é culpada - o ofensor.

378 pedido do FSB:

12. A classe de proteção de informações criptográficas KS3 é usada para neutralizar ataques, ao criar métodos, preparar e conduzir que usam os recursos do número listado nos parágrafos 10 e 11 deste documento e pelo menos um dos seguintes recursos adicionais:

a) acesso físico à TCC, no qual o CIPF e o SF são implementados ;
b) a capacidade de localizar os componentes de hardware do sistema de proteção de informações criptográficas e do SF, limitado por medidas implementadas no sistema de informações em que o sistema de proteção de informações criptográficas é usado e com o objetivo de prevenir e suprimir ações não autorizadas.

Aqui a lógica é esta:

• ferramentas comuns de proteção de informações criptográficas, como, por exemplo, o ViPNet Client ou o CryptoPRO CSP, são implementadas nas estações de trabalho dos usuários;
• os usuários são potenciais violadores;
• um invasor em potencial tem acesso físico a instalações de computadores nas quais sua proteção de informações criptográficas e seu ambiente operacional são implementados.

Assim, é possível justificar uma classe mais baixa de sistemas de proteção de informações criptográficas justificando que nossos usuários não sejam violadores em potencial (difíceis), ou usar apenas gateways de criptografia localizados em salas de servidores, que, por sua vez, são acessíveis apenas a usuários privilegiados, a quem excluímos da lista de possíveis violadores.

Vulnerabilidades

Como lembramos, o modelo de vulnerabilidade deve ser indicado no modelo de ameaça. O modelo para download do modelo de ameaça ainda não possui esta seção, portanto descreveremos brevemente como lidar com isso.

O compilador do modelo de ameaça deve fazer imediatamente uma pergunta: o que uma lista direta de vulnerabilidades identificadas pelo scanner precisa ser aplicada ao documento? A pergunta é boa e a resposta não é única. Conhecemos colegas que fazem exatamente isso, mas achamos que essa abordagem está errada e é por isso.

Primeiro, o modelo de ameaças à segurança da informação é um documento, embora sujeito a alterações, mas ainda mais ou menos estático. Desenvolvido uma vez e esqueceu-se de alterações significativas na infraestrutura do sistema.

A lista de vulnerabilidades geradas pelos scanners é uma informação muito dinâmica. Hoje identificamos vulnerabilidades, amanhã elas foram corrigidas e verificadas novamente - recebemos um novo relatório. Depois de amanhã, novas assinaturas apareceram, o scanner foi atualizado e encontrou novas vulnerabilidades, e assim por diante em um círculo. Qual é o sentido de aplicar um relatório de scanner de vulnerabilidades feito no momento em que o modelo de ameaça foi desenvolvido? Nada.

Em segundo lugar, um modelo de ameaça pode ser criado para um sistema de informações fisicamente inexistente (projetado, mas não construído). Nesse caso, não podemos nem digitalizar nada.

A saída desta situação é simples. Especifique no modelo de ameaça não vulnerabilidades específicas com o identificador CVE e a classificação CVSS, mas liste as possíveis classes de vulnerabilidade para um sistema de informações específico. E, para dar solidez a esta lista, tomaremos essa lista não da cabeça, mas de GOST R 56546-2015 “Proteção de informações. Vulnerabilidades em sistemas de informação. Classificação de vulnerabilidades em sistemas de informação. " Lista sob o spoiler. Pegamos e removemos itens desnecessários que não são compatíveis com as características estruturais e funcionais do nosso sistema. A seção está pronta!

Modelo de ameaça de segurança privada

E somente aqui prosseguimos diretamente para a identificação das ameaças atuais.
A metodologia para determinar as ameaças atuais do FSTEC em 2008 é um pouco impressionante, e já escrevemos sobre isso aqui . Mas não há nada a ser feito, como observado no mesmo artigo - com o que estamos trabalhando. Vamos ver o que exatamente precisamos fazer para obter uma lista das ameaças atuais.

Novos documentos do FSTEC prescrevem o uso de um NDU como fonte de ameaças à segurança da informação. Agora existem 213 ameaças e a lista pode ser reabastecida.

Aqui, eu gostaria imediatamente de falar sobre os prós e contras do BDU. Uma vantagem definitiva é que agora não há necessidade de criar e formular ameaças por conta própria, embora adicionar um modelo de ameaça a suas ameaças também não proíba nada. Outra vantagem é o potencial registrado do infrator e certas características de segurança das informações violadas para cada ameaça - você não precisa inventar nada.

Contras O primeiro ponto negativo é a capacidade terrivelmente escassa de classificar ameaças. Quando você começa a criar um modelo de ameaça usando um NLD, o desejo natural é eliminar ameaças que podem não ser relevantes em seu sistema, de acordo com as características estruturais e funcionais. Por exemplo, remova ameaças para contêineres virtuais e hipervisores, porque o sistema não usa virtualização ou seleciona ameaças para BIOS / UEFI por algum motivo, mas não existe essa possibilidade. Sem mencionar o fato de que o BDU possui várias ameaças exóticas associadas, por exemplo, a supercomputadores ou sistemas de grade.

Como nós, como organização licenciada, estamos desenvolvendo muitos modelos de ameaças para sistemas diferentes, tivemos que agrupar manualmente 213 ameaças; caso contrário, o trabalho é muito difícil, especialmente considerando que as ameaças nem sequer são agrupadas de forma alguma.

O segundo menos é uma descrição das próprias ameaças. Não, em algum lugar tudo é claro e compreensível. Às vezes, porém, é formulada uma ameaça, de modo que você precisa esmagar sua cabeça para descobrir o que se trata.

Voltemos à definição da lista de ameaças reais.

Nível de segurança inicial

A primeira coisa a determinar é um parâmetro global - o nível de segurança inicial. É global porque é determinado uma vez e não muda de ameaça para ameaça.

Para determinar o nível de segurança inicial (é o fator de segurança inicial Y1), é necessário selecionar um dos valores mais adequados para o seu sistema para sete indicadores.

Lista de recursos no spoiler.



Cada valor corresponde a um nível alto, médio ou baixo de segurança. Consideramos a porcentagem que obtivemos para indicadores com valores diferentes. Sobre o alto nível de segurança inicial - esqueça que isso não acontece. Se “alto” e “médio” obtiveram 70% ou mais, determinamos o nível médio de segurança inicial (Y1 = 5); caso contrário, baixo (Y1 = 10).

Perigo de ameaças

Esta seção do modelo é denominada "Determinando as consequências da violação das propriedades de segurança da informação (perigo de ameaças)". Eles chamaram exatamente isso porque, em essência, por definição de perigo de ameaças, essa é uma definição de consequências, mas, ao aprovar um modelo de ameaça, os inspetores podem não traçar esse paralelo e, como a "definição de conseqüências" deve estar no modelo de ameaça, eles escrevem um comentário.

Portanto, o perigo de ameaças pode ser baixo, médio ou alto, dependendo se pequenas conseqüências negativas, apenas negativas ou significativas ocorrem quando a ameaça é realizada, respectivamente.

Especialistas aqui discutem frequentemente se o perigo de ameaças deve ser determinado uma vez e ser constante para todas as ameaças - ou não. Isso não é especificado pela metodologia, portanto é possível e assim por diante. Nossa abordagem é intermediária - determinamos o perigo de ameaças, dependendo da violação da confidencialidade, integridade ou disponibilidade ao implementar uma ameaça específica.

De acordo com nossa lógica, as consequências negativas não dependem do método de violação da confidencialidade, integridade e acessibilidade. Por exemplo, se seus dados pessoais fluírem para algum tipo de banco de dados, provavelmente não importará para você como aconteceu - com a ajuda da injeção de SQL ou com o acesso físico do invasor ao servidor (o interesse profissional do agente de segurança não conta!). Portanto, definimos três "ameaças de perigo", por assim dizer, por violar confidencialidade, integridade e acessibilidade. Geralmente eles podem coincidir, mas é melhor analisar separadamente no modelo de ameaça. Felizmente, no NOS para cada ameaça, as características violadas também são registradas.

Eliminação de ameaças "desnecessárias"

Além disso, para eliminar imediatamente as ameaças desnecessárias, criamos um prato com uma lista de ameaças excluídas e uma justificativa - por que as jogamos fora.

O modelo mostra como um exemplo:

• eliminação de ameaças associadas a sistemas de grade, supercomputadores e big data;
• eliminação de ameaças relacionadas à virtualização;
• eliminação de ameaças associadas ao uso de redes de comunicação sem fio;
• eliminação de ameaças associadas ao uso de serviços em nuvem;
• eliminação de ameaças ao ICS;
• eliminação de ameaças associadas ao uso de dispositivos móveis;
• eliminação de ameaças cuja implementação é possível apenas por um invasor com alto potencial.

No último ponto, você precisa esclarecer alguns pontos:

• se você identificou um invasor com baixo potencial, as ameaças que podem ser executadas por infratores com potencial médio e alto são excluídas aqui;
• , ;
• , .

A seguir, é apresentada uma tabela que descreve ameaças que não foram excluídas. Sim, aqui você só precisa copiar e colar o texto do BDU, porque o modelo de ameaça deve ter uma "descrição das ameaças", não funcionará com identificadores. Vamos ver o que temos nesta tabela.

O número em ordem e o identificador de ameaça do BDU - tudo está claro aqui. As colunas "descrição da ameaça" e "método de implementação da ameaça" são um bloco de texto do NOS. Na primeira coluna, inserimos o texto antes das palavras "A realização da ameaça é possível ...". No segundo - tudo o resto. A separação está novamente conectada ao requisito dos documentos regulatórios de que os “Métodos de implementação de ameaças” sejam descritos no modelo de ameaça. Quando acordado, isso ajudará a evitar perguntas desnecessárias.



As colunas da tabela a seguir são os potenciais invasores internos e externos. Para tornar a tabela mais compacta e dar mais espaço aos blocos de texto, mapeamos anteriormente os potenciais alto, médio e baixo para os números 1, 2 e 3. Se o potencial não for especificado no BDU, faça um traço.

Coluna “Impactos” - também coletamos dados da unidade de controle.

A coluna “Propriedades perturbadas” - K, C e D, confidencialidade, integridade e acessibilidade - foi substituída por letras com a mesma finalidade que no caso dos infratores.

E as últimas colunas são "Pré-requisitos" e "Justificação para a ausência de pré-requisitos". O primeiro é o começo da determinação do coeficiente Y2, é também a probabilidade da ameaça, que por sua vez é determinada pela presença de pré-requisitos para a realização da ameaça e pela adoção de medidas para neutralizá-la.



É importante dizer aqui que a última coluna é puramente nossa iniciativa e não está prevista em lei. Portanto, você pode removê-lo com segurança. Porém, consideramos importante que, se um especialista elimina ainda mais as ameaças, porque não existem pré-requisitos para sua implementação, é importante que ele descreva por que decidiu isso.

Também relacionado a esse ponto está o fato de estarmos aqui, de certo modo, nos afastando da técnica de modelagem de ameaças. De acordo com a metodologia para ameaças que não têm pré-requisitos, é necessário calcular ainda mais sua relevância. E, em alguns casos, ameaças que não têm pré-requisitos podem se tornar relevantes. Consideramos isso um defeito na legislação e, da mesa final, excluímos ameaças que não têm pré-requisitos.

Lista de ameaças atuais

Mais precisamente, a última tabela é uma lista de ameaças atuais e irrelevantes e um conjunto de parâmetros restantes para determinar sua relevância. Já não existem ameaças para as quais não existem pré-requisitos, mas, das ameaças restantes, com base no cálculo dos coeficientes, algumas ameaças podem ser consideradas irrelevantes.

Na última tabela, deliberadamente não incluímos alguns parâmetros:

• Y1 - esse parâmetro é global, portanto, lembre-se;
• pré-requisitos - na mesa final, temos apenas ameaças que têm pré-requisitos, portanto, não faz sentido nesta coluna.

Vamos percorrer as colunas brevemente. O número em ordem e a ameaça são apenas na forma de um identificador - tudo está claro aqui.

“Medidas tomadas” - por “especialista” significa que determinamos se foram tomadas medidas para neutralizar essa ameaça (a propósito, mais um truque do método é que, se as medidas forem “tomadas”, a ameaça ainda poderá permanecer relevante). Pode haver três opções: aceito; aceito, mas insuficiente; não aceito (+, + -, - respectivamente).

Com base nas medidas tomadas e levando em consideração que existem pré-requisitos para a ameaça, o coeficiente de probabilidade (Y2) é determinado, como determinar se é mais alto no spoiler.

A próxima coluna é o coeficiente de realização de ameaça Y. É calculado usando a fórmula simples Y = (Y1 + Y2) / 20.

A possibilidade de implementação é um análogo verbal do coeficiente Y. É determinado dependendo do valor numérico da seguinte maneira:



Perigo - acima, determinamos o perigo de uma ameaça com base na propriedade de segurança violada. Aqui já inserimos o valor necessário do perigo com base nos recursos de segurança que essa ameaça específica viola.

Bem e por último - a relevância da ameaça. É determinado pela tabela:



Viva! Nosso modelo de ameaças está pronto.