NIST Special Publications 800

Para quem trabalha com Infosec sabe a relevância das publicações que o NIST (National Institute of Standards and Technology) possui na área. Existem diversas publicações, guias e recomendações que são utilizados como referência na área e, por vezes, como fundamentação para legislações e normas.

NIST SP-800

O conjunto de publicações chamada de SP-800 (Special Publications) é uma série de publicações que trata o tema Segurança de Computadores para o governo norte-americano. É a referência normativa que utilizam para implantar segurança em ambientes computacionais, principalmente por agências e órgãos dos Estados Unidos. Pórem, por possuir alta qualidade na produção, os guias, guidelines e práticas são adotadas em outros ambientes.

Os documentos vão passando por atualizações, sendo que o NIST as identifica através de revisões. Sempre procure pela revisão mais atual referente a publicação.

Farei um breve resumo das principais publicações dessa série de forma a auxiliar na busca no diretório de documentos e citar as mais relevantes entre tantas.

SP 800-30 – Guia para Condução da Avaliação de Riscos

Guia para a condução de uma avaliação de risco específica em riscos à segurança da informação e tópicos relacionados diretamente, como documentação, segurança de pessoas, treinamento entre outras características. Não propõe-se cobrir de forma ampla os riscos a grandes corporações, não incluindo características como plano de sucessões, por exemplo. Ou seja, não possui foco no nível estratégico elevado da organização.

É composta pelas seguintes etapas:

  • Preparar a avaliação
  • Conduzir a avaliação
    • identificar a origem das ameaças e eventos
    • identificar vulnerabilidades e condições pré-dispostas
    • identificar a probabilidade de ocorrência
    • determinar magnetude do impacto
    • determinar o risco
  • Comunicar os resultados
  • Manter a avaliação constante

SP 800-34 – Guia para Planejamento de Contingência

Eventos catastróficos, pelo menos os reconhecidos como possíveis, devem ser previstos em um plano de contingência. NIST provê um conjunto de etapas para elaborar um plano de contingência para TI, especialmente para o governo norte-americano ou empresas que se relacionam com esse.

Para viabilizar o planejamento da contingência o NIST sugere:

  1. Desenvolver uma política para planejamento de continuidade: uma política que forneça uma orientação para o desenvolvimento do plano de continuidade do negócio. Com a orientação da política as demais normas e procedimentos poderão ser melhor orientados.
  2. Conduzir uma análise de impacto ao negócio: identificar funções e sistemas críticos permite com que a organização priorize o que realmente é mais importante e faça uso consciente dos recursos que possui. Identificar vulnerabilidades, ameaças e calcular o risco.
  3. Identificar controles preventivos: uma vez que as ameaças são conhecidas, identificar e implementar os controles necessários para reduzir o risco da organização.
  4. Criar estratégias de contingência: formular métodos para garantir com que sistemas críticos possam retornar as atividades em caso de contingência.
  5. Desenvolver um plano de contingência de sistemas de informação: escrever procedimentos e guias para orientar a organização como se manter funcional em caso de um estado crítico.
  6. Testar, treinar e exercitar os planos: testar os planos de contingência é a melhor forma de identificar melhorias e preparar as pessoas para situações catastróficas.
  7. Manutenção do plano: criar mecanismos para garantir com que o plano de continuidade de negócio seja atualizado regularmente.

Todas essas etapas podem ser resumidas na figura a seguir:

etapas bcp.png
Fonte: CISSP All-in-One Exam Guide 5ª Edition

No guia NIST 800-34 existem alguns modelos de documentos que podem ser livremente utilizados para apoiar na elaboração do plano de continuidade de negócios.

SP 800-39 – Gestão de Risco

Esse guia fornece uma forma de analisar o risco de forma mais abrangente dentro de uma organização. Geralmente o risco é analisado de forma mais pontual, como no caso de aplicações, dispositivos, malwares e ações de hackers. Porém o risco pontual deve ser analisado como peças de um quebra-cabeça maior. E esse guia propõe uma visão mais holística do risco.

Mais importante do que a análise do risco de ameaças pontuais é como calcular o risco ao negócio diante ameaças. O guia NIST SP 800-39 define os seguintes conjuntos de gestão de risco, do nível mais alto da organização ao nível mais operacional:

  • Organizacional: considera o risco para o negócio como um todo, definindo parâmetros para a tolerância do risco.
  • Processo de negócio: lida com o risco em grandes funções da organização através da identificação do que é crítico e como a informação percorre a organização, parceiros e clientes.
  • Sistemas de informação: perspectiva dos sistemas da informação e os riscos associados a sistemas específicos.

Analisar o risco e gerí-lo significa ter uma compreensão holística da organização, suas ameaças e as medidas necessárias para lidar com elas, além de constantemente monitorar para garantir com que esteja em níveis aceitáveis. Ou seja, o processo de gestão de riscos deve possuir, de acordo com a publicação, os seguintes componentes:

  • Contexto do risco: qual o contexto do risco? Quais as prioridades da organização? Qual a tolerância ao risco que a alta administração poderá assumir?
  • Avaliação do risco: antes de tomar qualquer ação para mitigar o risco devemos avaliar o risco de forma adequada.
  • Responder ao risco: nesse ponto já sabemos as prioridades e uma adequada avaliação do risco, então sabemos o que devemos e não devemos fazer. Responder o risco com controles adequados com uso racional de recursos.
  • Monitorar o risco: não importa o quão precavido sejamos, novas ameaças novas surgem, seja porque novos riscos são identificados em recursos já existentes ou porque novos sistemas com novas vulnerabilidades são adquiridos e implantados. Monitorar de forma contínua a efetividade da segurança é a única forma de estar um passo a frente.

SP-800-40 – Guia para Gestão de Patches

O NIST SP 800-40 é um guia que define o processo de identificar, adquirir, instalar e verificar patches para produtos e sistemas. Patches são atualizações de softwares com a intenção de remover uma vulnerabilidade ou defeito de um software ou prover novas funcionalidades a esse.

Para a gestão de patches existem algumas abordagens, cada qual com suas vantagens e desvantagens, conforme a seguir:

  • Patching não gerenciado ou descentralizado: nesse abordagem não há uma gestão centralizada de patches na organização. Cada software por si em cada dispositivo verifica por atualizações periodicamente e, se houver, as instala. Essa abordagem gera os seguintes riscos:
    • credenciais: a instalação de patches geralmente envolvem o uso de credenciais com maior nível de privilégio, o que vai contra o princípio de menor privilégio.
    • gestão de configuração: pode ser difícil, ou mesmo impossível, atestar o status de atualização do parque tecnológico da organização.
    • uso de banda: se cada aplicação ou serviço realizar sua atualização, de forma independente, e para tanto requerer descarregar dados, poderá resultar em maior consumo de banda.
    • disponibilidade de serviço: se um serviço ou aplicação for automaticamente atualizado poderá gerar indisponibilidades não agendadas e efeitos negativos para a organização.

Para uma organização a gestão de patches de forma descentralizada não traz nenhuma vantagem. No entanto, para determinados contextos pode fazer sentido ou seja a única forma, como no caso de trabalhadores que fazem uso de dispositivos pessoais para seu trabalho.

  • Patching gerenciado e centralizado: é o meio de gestão de patches mais recomendado do ponto de vista de operação de segurança. Existem algumas abordagens de como realizar conforme a seguir:
    • baseado em agente: nessa abordagem os clientes, sejam estações de trabalho ou servidores, possuem um agente instalado que possui a finalidade de levantar os softwares, patches e versões existentes e comparar com uma base de atualizações. Permite maior controle inclusive do processo de atualização se necessário.
    • sem agente: nesse abordagem um serviço centralizado realiza o acesso remoto nos clientes e utiliza de credenciais administrativas para realizar a verificação e atualização se necessário.
    • passivo: nessa abordagem a verificação é realizada de forma não intrusiva, ou seja, não envolvendo o acesso aos endpoints. Pode ser realizada através da análise da comunicação da rede, por exemplo.

Seja qual abordagem utilizada, as organizações em geral desejam aplicar as correções o quanto antes. Porém deve-se levar em consideração a confiabilidade dos fornecedores das atualizações, pois essas podem trazer impactos negativos quando não são devidamente testadas. Uma forma de resguardar as organizações é essas realizarem seus próprios testes antes da aplicação em ambientes críticos.

A aplicação dos patches em uma gestão de patches pode ser realizada de diferentes formas. Uma das formas pode ser realizar a aplicação dos patches de forma gradual no ambiente, de forma que em caso de indisponibilidade ou outros problemas relacionados ao patch esse não afete ao ambiente por um todo. Porém isso permite um período maior com que o ambiente se encontra vulnerável. Essa ponderação em uma análise de risco deve ser considerada.

Engenharia Reversa de Patches

Todos os softwares e aplicações são sucetíveis a vulnerabilidades do tipo zero-day. Porém o esforço necessário para encontrar essas falhas, ou o custo para aquisição dessas falhas no mercado negro, é muito alto. Uma forma mais simples para explorar vulnerabilidades é a engenharia reversa de patches de segurança. Potenciais atacantes podem reverter patches e encontrar as falhas que foram sanadas com os patches, conferindo ao atacante a possibilidade de explorar a falha em ambientes em que o patch ainda não tenha sido aplicado.

De forma a minimizar esse risco, alguns fornecedores começaram a lançar patches de segurança que realizam a obsfucação do que realmente é aplicado. Isso permite com que os ambientes em que não possuem o patch aplicado tenham mais tempo de ter a correção aplicada antes de atacantes conseguirem realizar a reversão.

SP 800-53 – Controles para Privacidade e Segurança em Sistemas de Informação em Organizações

Agências e órgãos do governo norte americano precisam estar em conformidade com a norma SP 800-53. Essa norma, junto com a SP 800-37 (Guia para Aplicar Framework de Gestão de Riscos para Sistemas da Informação Federal), apoiam com que as agências e órgãos estejam em conformidade com a FISMA (Federal Information Security Management Act of 2002).

No documento do NIST 800-53 os controles são agrupados nas seguintes categorias: gestão, operação e controles técnicos.

Identificação Família Classe
AC Controle de Acesso Técnico
AT Treinamento Operacional
AU Auditoria e Contabilização Técnico
CA Avaliação de Segurança e Autorização Gestão
CM Gestão de Configuração Operacional
CP Planejamento de Contingência Operacional
IA Identificação e Autenticação Técnico
IR Resposta à Incidentes Operacional
MA Manutenção Operacional
MP Proteção de Mídia Operacional
PE Proteção Física e de Ambiente Operacional
PL Planejamento Gestão
PM Gestão de Programas Gestão
PS Segurança Pessoal Operacional
RA Avaliação de Risco Gestão
SA Aquisição de Serviços e Sistemas Gestão
SC Proteção de Comunicações e Sistemas Técnico
SI Integridade de Informação e Sistemas Operacional

Da mesma forma que no COBIT (Control Objectives for Information and related Technology), o SP 800-53 provê uma lista de “checklists” que auditores utilizam para avaliar a conformidade da organização. Os controles COBIT e SP 800-53 possuem sobreposição já que em ambos os cenários (empresas privadas ou governo) os controles necessários serão parecidos.

SP 800-55 – Guia para Mensurar Performance da Segurança da Informação

O NIST SP 800-55 cobre a forma como mensurar a performance de segurança em uma organização. Para tanto propõe métricas para mensurar a implementação, efetivicidade/eficiência e impacto da segurança em uma organização.

A figura a seguir apresenta o relacionamento entre os indicadores propostos pelo guia para auxiliar a monitorar a segurança de uma empresa.

sp800-55.png
Fonte: CISSP All-in-One Exam Guide 8ª Edition

SP 800-61 – Guia para Manipulação de Incidentes de Segurança de Computadores

Trata-se de guia de como manipular dados que sejam objeto de um incidente de segurança. Sugere com que existem as seguintes informações sobre cada incidente:

  • Sumário do incidente
  • Indicadores relevantes
  • Incidentes relacionados
  • Ações tomadas
  • Cadeia de custódia de todas as evidências (se for possível e aplicável)
  • Avaliação do impacto
  • Identificação e comentários sobre a manipulação do incidente
  • Ações a serem tomadas

SP 800-82 – Recomendações de Segurança para ICS

Com a rápida convergência de diversas diferentes tecnologias utilizando de protocolos padrões, como TCP/IP, permitiu com que ambientes computacionais até então isolados, como os sistemas de controles industriais (ICS – Industrial Control Systems) sejam alvo para ataques e ameaças até então inexistentes. Com essa preocupação, o NIST publicou o SP 800-82 que fornece diversas recomentações para segurança e controle de ambientes ICS. Entre os principais controles cito:

  • Aplicar gestão de risco ao processo de ICS
  • Segmentação de rede e uso de IDS/IPS nas sub-redes de perímetro
  • Desabilitar portas necessárias e serviços sem uso de todos os dispositivos ICS
  • Implementar princípio de mínimo privilégio quando aplicável em dispositivos ICS
  • Utilizar de criptografia quando for possível
  • Garantir um processo de gestão de patches (NIST SP 800-40)
  • Monitorar trilhas de auditoria de forma regular.

SP 800-88 – Guideline para Sanitização de Mídias

SP 800-137 – Monitoração Contínua de Sistemas de Segurança para Organizações e Sistemas de Informações Federais

A publicação SP 800-137 propõe a elaboração de processos para monitoração e manutenção contínua sobre segurança de sistemas, vulnerabiliddes e ameaças em órgãos e agências do governo norte-americano, suportando o processo de gestão de risco da organização. Esse processo visa constantemente avaliar se os controles implantados são suficientes para a organização, se ainda são efetivos e, se não, por que não?

O armazenamento de dados se tornou algo barato ao longo dos anos, permitindo com que dados (logs) sejam armazenados em tal volume que possivelmente nunca serão lidos. No entanto, a monitoração desses dados já não é algo tão simples e automático, e geralmente necessita de atuação de um profissional para a extração dos dados de forma útil, como na elaboração de um relatório através da ferramenta de SIEM.

Esse processo determina o que deve ser monitorado, como será monitorado e o que será feito com a informação que for gerada a partir da monitoração. Com isso compreender quais controles ainda são efetivos, como é possível melhorá-los ou implementar novos para redução do risco para níveis aceitáveis. Com base nas informações do processo de monitoração contínua é possível tomar decisões negociais de forma mais assertiva. Quando bem implantado, é uma poderosa ferramenta para atuar de forma preventiva em segurança.

SP 800-161 – Práticas de Gestão de Risco na Cadeia de Fornecedores

A NIST SP 800-161 é um conjunto de boas práticas para realizar a gestão de risco na cadeira de fornecedores de determinada organização.

A cadeia de fornecedores é a sequência de fornecedores responsáveis e envolvidos na entrega de produtos e serviços necessários para a organização gerar seus bens para o mercado. Um fornecedor pode ser desde o provedor de softwares até a empresa responsável pelo sistema de climatização da organização.

De forma a permitir a realização da gestão de risco, é necessário a compreensão de quais são os fornecedores existentes na organização e como são relacionados para as atividades da organização.

Por fim…

A lista naturalmente não é exaustiva e existem outras diversas boas publicações que podem ser consideradas. Em caso de necessidade de outros documentos do NIST no início do artigo tem o link.

Se alguém quiser também sugerir outra publicação que não está descrita aqui, deixe um comentário.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *