Nota 02

Modelo de ameaça para a segurança corporativa

Um modelo de ameaça ajuda a decidir onde investir em segurança. O ponto de partida é a operação: quais informações e sistemas sustentam o negócio, como poderiam ser comprometidos e quais seriam as consequências. Esse mapa orienta controles, prioridades e responsabilidades.

Modelo físico de um sistema com limites e diferentes caminhos de acesso.

Tailored Coding

O rascunho inicial do NIST SP 800-154 descreve o modelo de ameaça centrado em dados como uma forma de avaliação de risco voltada aos lados de ataque e defesa de dados selecionados. A metodologia caracteriza sistema e dados, seleciona vetores de ataque, identifica controles e analisa o modelo. Como a publicação ainda não é definitiva e cobre uma modalidade específica, ela serve aqui como referência metodológica, não como definição universal ou norma concluída.

A mudança de perspectiva importa porque nem todo incidente começa com a escolha individual de uma vítima. A CISA alerta que configurações inadequadas, credenciais padrão e software desatualizado podem deixar sistemas publicamente expostos e fáceis de explorar. A inferência prática é delimitada: em parte dos ataques, a exposição pode ser encontrada antes que alguém saiba quem está por trás dela. Isso não significa que todas as pessoas ou empresas enfrentem o mesmo risco.

O valor que um terceiro pode enxergar

Ao construir o modelo, não limite o interesse possível à fama ou ao patrimônio visível. Uma conta pode abrir acesso a outras contas. Um documento interno pode revelar clientes, fornecedores, preços ou decisões. Uma agenda pode mostrar relações e rotinas. Metadados podem indicar quem se comunica com quem, quando, de onde e com que frequência.

O dado também pode ter valor como instrumento. Credenciais comprometidas podem viabilizar acesso, conforme os demais controles; informações pessoais podem sustentar fraude ou engenharia social; arquivos operacionais podem apoiar extorsão; acesso a contatos pode ampliar o alcance de uma tentativa de golpe.

Essas possibilidades não provam que um ataque acontecerá. Elas ajudam a identificar por que determinada informação, conta ou relação merece proteção mesmo quando seu responsável não se considera um alvo.

Acesso legítimo também entra no modelo

Um modelo de ameaça não deve mapear apenas criminosos. É preciso registrar as entidades que possuem acesso autorizado: administradores internos, fornecedores de nuvem, operadores de suporte, subcontratados, serviços de identidade, integrações e ferramentas que analisam conteúdo ou telemetria.

Segurança e privacidade se sobrepõem. Ambas tratam riscos de acesso indevido; segurança também protege integridade e disponibilidade e considera erro, abuso de privilégio e comprometimento. Privacidade acrescenta outra pergunta: o tratamento, mesmo funcionando como projetado, possui finalidade, base legal, necessidade, transparência e proteção dos direitos aplicáveis? O NIST Privacy Framework 1.0 explicita essa sobreposição; no Brasil, os critérios jurídicos dependem da LGPD e do caso concreto.

Conteúdo e metadados devem aparecer separadamente. Um serviço pode proteger o arquivo e ainda registrar nome, tamanho, horário, endereço IP, dispositivo, participantes ou histórico de atividade. Essas informações podem ser pessoais quando identificam ou podem ser associadas a uma pessoa, especialmente quando combinadas.

Cinco perguntas para construir o primeiro modelo

  1. Quais dados, metadados, contas e relações precisam ser protegidos, em repouso, trânsito e uso, e que dano resultaria de exposição, alteração, indisponibilidade ou uso fora da finalidade?
  2. Quais são as fronteiras do sistema, os fluxos, as entradas, as saídas e as premissas de confiança entre pessoas, dispositivos, serviços e fornecedores?
  3. Quais entidades têm acesso hoje ao conteúdo ou aos metadados, com quais responsabilidades, e onde abuso de privilégio, erro ou integrações podem ampliar a exposição?
  4. Por quais vetores o acesso ou o dano poderia ocorrer, e quais controles previnem, detectam, limitam e permitem recuperar cada cenário?
  5. Quem aceita o risco residual, quais trocas entre proteção, custo, usabilidade e desempenho foram aceitas e como dados, chaves e acessos são retirados quando a relação termina?

As respostas devem priorizar cenários plausíveis pelo impacto e pela exposição, não pelo medo. O reúso de senha e a ausência de autenticação resistente a phishing no caminho de acesso são duas condições que podem exigir ação antes de um cenário sofisticado dependente de várias condições improváveis.

O primeiro resultado é uma triagem, não uma garantia

O primeiro ciclo deve produzir um mapa curto: fronteiras, dados e metadados relevantes, entidades com acesso, vetores, controles existentes, lacunas, premissas de confiança, responsáveis e riscos residuais. Também deve separar o que foi observado, o que é promessa contratual e o que permanece desconhecido.

Esse mapa orienta prioridade. Ele não substitui teste técnico, avaliação jurídica, resposta a incidente ou revisão contínua. O modelo precisa ser atualizado quando mudam as ferramentas, os fornecedores, os dados, os fluxos ou as pessoas autorizadas.

Como fazemos

Começamos pelos dados, metadados, fluxos e relações que sustentam a operação. Mapeamos entidades com acesso legítimo, caminhos de exposição e premissas de confiança; testamos controles e evidências; e distinguimos acesso observado, autoridade contratual e possibilidade ainda desconhecida. A entrega é um modelo priorizado, com cenários, controles, risco residual, responsáveis e decisões de redução, aceitação ou investigação adicional.

Quais exposições poderiam interromper sua operação ou comprometer informações de clientes? A resposta ajuda a priorizar investimentos em segurança com base no impacto para o negócio.

Conheça também a metodologia da nossa avaliação de ameaças e riscos.