NIST

1. IntroduçãoCada organização tem uma missão. Nesta era digital, como as organizações utilizam a tecnologia da informação automatizada (TI) para processar suas informações para um melhor suporte de suas missões, gerenciamento de risco desempenha um papel crítico na proteção dos ativos de informação da organização, e, portanto, sua missão, de TI relacionados risco.

Um processo de gestão de riscos é um componente importante de um programa de segurança de TI bem-sucedido. O principal objetivo de uma organização do processo de gerenciamento de risco deve ser o de proteger a organização e sua capacidade de desempenhar a sua missão, não apenas os seus ativos de TI. Portanto, o processo de gestão de risco não deve ser tratado principalmente como uma função técnica realizada pelos peritos de TI que atuam e gerir o sistema de TI, mas como uma função de gestão essencial para a organização.

1.1 não somos importantes

1.2 Propósito Risco é o impacto líquido negativo do exercício de uma vulnerabilidade, considerando tanto a probabilidade e o impacto de ocorrência. A gestão de riscos é o processo de identificação de riscos, avaliação de riscos, e tomar medidas para reduzir o risco a um nível aceitável. Este guia fornece uma base para o desenvolvimento de um programa eficaz de gestão de risco, contendo as definições e as orientações práticas necessárias para avaliar e mitigar riscos identificados dentro de sistemas de TI. O objetivo final é ajudar as organizações a gerenciar melhor os riscos relacionados a TI de missão.

Além disso, este guia fornece informações sobre a seleção de controles de custo eficazes de segurança. Esses controles podem ser utilizados para reduzir o risco para a melhor proteção de informações de missão crítica e os sistemas de TI que processam, armazenam e transportam essa informação.

As organizações podem optar por expandir ou abreviar os processos abrangentes e passos sugeridos neste guia e adequá-los ao seu meio ambiente na gestão de riscos relacionados a TI de missão.

1.3 ObjetivoO objetivo de realizar gerenciamento de risco é o de permitir a organização a cumprir sua missão (1) através de uma melhor segurança dos sistemas de TI que armazenam, processam ou transmitem informação organizacional; (2), permitindo que a administração faça bem informada gestão de risco decisões para justificar as despesas que fazem parte de um orçamento de TI, e (3), auxiliando a gestão em que autoriza (ou credenciadora) os sistemas de TI com base na documentação resultante do desempenho da gestão de risco.

1.4 não somos importantes1.5 não somos importantes

1.6 ESTRUTURAS GUIASAs demais seções deste guia de discutir o seguinte:• Seção 2 fornece uma visão geral da gestão de risco, como ele se encaixa no ciclo de vida do sistema de desenvolvimento (SDLC), e os papéis dos indivíduos que suportam e utilizar este processo.• Seção 3 descreve a metodologia de avaliação de risco e os nove principais passos na condução de uma avaliação de risco de um sistema de TI.

• Seção 4 descreve o processo de mitigação de risco, incluindo opções de mitigação de risco e estratégia, a abordagem para implementação de controle, categorias de controle, análise custo-benefício e risco residual.• A Seção 5 discute boas práticas e a necessidade de uma avaliação de risco em curso e a avaliação e os fatores que levarão a um programa bem sucedido de gestão de risco.

Este guia também contém seis apêndices. O Apêndice A fornece perguntas da entrevista da amostra. Apêndice B fornece um esboço de amostra para uso em documentar os resultados da avaliação de risco. O Apêndice C contém uma tabela de exemplo para o plano de implementação de salvaguarda. Apêndice D fornece uma lista de os acrônimos utilizados no presente documento. O Apêndice E contém um glossário de termos usados com frequência neste guia. Apêndice F lista de referências.

2. VISÃO GERAL DE GESTÃO DE RISCOS

Este guia descreve a metodologia de gerenciamento de risco, como ele se encaixa em cada fase do SDLC, e como o processo de gestão de risco está ligado ao processo de autorização do sistema (ou credibilidade).

2.1 A IMPORTÂNCIA DA GESTÃO DE RISCOSGestão de risco engloba três processos: avaliação dos riscos, mitigação de riscos, avaliação e avaliação. Seção 3 deste guia descreve o processo de avaliação de risco, que inclui a identificação e avaliação de riscos e impactos de risco, e recomendação de medidas de redução de risco. A Seção 4 descreve mitigação de riscos, que se refere à priorização, implementação e manutenção das adequadas medidas de redução de risco recomendados pelo processo de avaliação de risco. A Seção 5 discute o processo de avaliação contínua e chaves para a implementação de um programa de gerenciamento de risco bem-sucedido. O oficial autoriza a DAA ou sistema é responsável por determinar se o risco remanescente é em um nível aceitável ou se os controles de segurança adicionais devem ser implementadas para reduzir ainda mais ou eliminar o risco residual antes de autorizar (ou credenciadora) o sistema de TI para a operação.

A gestão de riscos é o processo que permite que gerentes de TI a equilibrar os custos operacionais e econômicos das medidas de proteção e obter ganhos de capacidade de missão por proteger os sistemas de TI e dados que suportam missões das suas organizações. Este processo não é exclusivo para o ambiente de TI; na verdade, permeia a tomada de decisões em todas as áreas de nossas vidas diárias. Tomemos o caso da segurança em casa, por exemplo. Muitas pessoas decidem ter sistemas de segurança home instalado e pagar uma taxa mensal a um prestador de serviços para que esses sistemas monitorados para melhor proteção dos seus bens. Presumivelmente, os proprietários ter pesado o custo de instalação do sistema e monitoramento contra o valor dos bens da sua casa e segurança da sua família, um fundamental "missão" a necessidade.

O chefe de uma unidade organizacional deve assegurar que a organização tem os recursos necessários para cumprir sua missão. Este proprietário de missão deve determinar as capacidades de segurança que seus sistemas de TI devem ter para proporcionar o nível desejado de apoio à missão em face das ameaças do mundo real. A maioria das organizações têm orçamentos apertados para segurança de TI, portanto, gastos com TI de segurança devem ser revisados tanto quanto outras decisões de gestão. A bem estruturada metodologia de gerenciamento de risco, quando utilizada de forma eficaz, pode ajudar a administração a identificar os

controles apropriados para fornecer capacidades de missão essenciais de segurança.

2.2 A Integração da Gestão de Risco no SDLCMinimizar o impacto negativo sobre a organização e necessidade de base sólida na tomada de decisão são as organizações fundamentais razões implementar um processo de gerenciamento de risco de seus sistemas de TI. Gestão eficaz dos riscos deve ser totalmente integrada ao SDLC. SDLC Um sistema informático tem cinco fases: desenvolvimento de iniciação, ou aquisição, implantação, operação ou manutenção, e disposição. Em alguns casos, um sistema informático pode ocupar várias destas fases ao mesmo tempo. No entanto, a metodologia de gerenciamento de risco é o mesmo, independentemente da fase SDLC para que a avaliação esteja sendo realizada. A gestão de riscos é um processo iterativo que pode ser realizada durante cada fase principal do SDLC. Tabela 2-1 descreve as características de cada fase SDLC e indica como gestão de risco pode ser realizada em suporte de cada fase.

Tabela 2.1 Integração de Gestão de Risco para o SDLC

Fases SDLC Características de fase Apoio de Gerenciamento de Riscos

Fase 1-Iniciação A necessidade de um sistema de TI é expressa e o propósito e o alcance do sistema de TI estão documentados

• riscos identificados são utilizados para apoiar o desenvolvimento dos requisitos do sistema, incluindo os requisitos de segurança, e um conceito de segurança de operações

(estratégia) ·.

Fase 2. Desenvolvimento ou Aquisição

O sistema de TI foi desenvolvido, comprado, programados, desenvolvidos ou não construído.

• Os riscos identificados durante esta fase pode ser usada para apoiar as análises de segurança do sistema de TI que podem levar a trocas de arquitetura e design durante o desenvolvimento do sistema

Fase 3-Implementação As características de segurança do sistema devem ser configuradas, habilitado, testado e verificado.

• O processo de gestão do risco sustenta a avaliação da implementação do sistema em relação aos requisitos e dentro de seu ambiente operacional modelado. As decisões sobre os riscos identificados devem ser feitas antes da operação do sistema

Fase 4-Operação ou Manutenção

O sistema executa suas funções. Normalmente, o sistema está sendo modificado em uma base contínua através da adição de hardware e software e por mudanças nos processos organizacionais,

• As atividades de gestão de risco são realizadas para re-autorização sistema periódico (ou recredenciamento) ou sempre que grandes mudanças são feitas para um sistema de TI no seu

políticas e procedimentos. ambiente de produção operacional, (por exemplo, interfaces novo sistema).

Fase 5-Eliminação Esta fase pode envolver a disposição de informação, hardware e software. As atividades podem incluir movimento, arquivamento, descarte, ou destruir informações e limpeza de hardware e software.

• As atividades de gestão de risco são realizadas para os componentes do sistema que serão eliminados ou substituídos para garantir que o hardware e software estão devidamente eliminados, que os dados residuais são devidamente tratados, e que a migração do sistema é realizada de uma maneira segura e sistemática.

2.3 Principais FunçõesA gestão de riscos é uma responsabilidade de gestão. Esta seção descreve as principais funções do pessoal que deve apoiar e participar no processo de gestão de risco.• Alta Administração: A gerência sênior, de acordo com o padrão de cuidados devidos e responsabilidade final para o cumprimento da missão, deve assegurar que os recursos necessários sejam efetivamente aplicados para desenvolver as capacidades necessárias para cumprir a missão. Eles também devem avaliar e incorporar os resultados da atividade de avaliação de risco no processo decisório. Um programa de gestão de riscos que avalia e reduz os riscos relacionados a TI de missão requer o apoio e envolvimento da alta gerência.• Chief Information Officer (CIO). O CIO é responsável pelo planejamento da agência de TI, orçamento e desempenho, incluindo os seus componentes de segurança da informação. As decisões tomadas nestas áreas devem ser baseadas em um programa eficaz de gestão de risco.• Os proprietários do Sistema e Informação: Os proprietários do sistema de informação são responsáveis por garantir que os controles apropriados estão no local para abordar a integridade, confidencialidade e disponibilidade dos sistemas de TI e dados que possuem. Normalmente, os proprietários de sistemas e informações são responsáveis por alterações em seus sistemas de TI. Assim, eles normalmente têm de aprovar e assinar sobre alterações em seus sistemas de TI (por exemplo, melhorias no sistema, grandes mudanças no software e hardware). Os proprietários do sistema e informações devem, portanto, compreender o seu papel no processo de gestão de risco e apoiar plenamente este processo.• Gerentes de Negócios e Funcionais: Os gerentes responsáveis por operações de negócios e de TI processo de aquisição deve ter um papel ativo no processo de gestão de risco. Esses gerentes são os indivíduos com a autoridade e responsabilidade para tomar as decisões trade off essenciais para o cumprimento da missão. O seu envolvimento no processo de gestão de risco permite a realização de segurança adequada para os sistemas de TI, que, se administradas corretamente, irá proporcionar a eficácia da missão com um gasto mínimo de recursos.• ISSO: gerentes de TI do programa de segurança e oficiais de segurança informática é responsável por programas de suas organizações de segurança, incluindo a gestão de risco. Portanto, eles desempenham um papel de liderança na introdução de uma metodologia apropriada estruturado para ajudar a identificar, avaliar e minimizar os riscos para os sistemas de TI que suportam as suas missões organizacionais. Nisso atuam como consultores principais de apoio da alta administração para assegurar que essa atividade ocorre em uma base contínua.

• Os profissionais de segurança de TI: profissionais de segurança de TI (por exemplo, redes, sistemas, aplicativos, administradores e especialistas em banco de dados; computador; analistas de segurança, consultores de segurança) são responsáveis pela aplicação adequada dos requisitos de segurança em seus sistemas de TI. Como as mudanças ocorrem no ambiente do sistema de TI existentes (por exemplo, a expansão da conectividade de rede, alterações na infraestrutura existente e as políticas organizacionais, a introdução de novas tecnologias), os profissionais de segurança de TI deve apoiar ou utilizar o processo de gestão de riscos para identificar e avaliar novas potencialidades riscos e implementar controles de segurança nova, conforme necessário para proteger seus sistemas de TI.• Conscientização de Segurança Trainers (Profissionais de segurança / Objeto): O pessoal da organização são os utilizadores dos sistemas de TI. O uso dos sistemas de TI e dados de acordo com as políticas de uma organização, diretrizes e regras de comportamento é fundamental para mitigar os riscos e proteger a organização de recursos de TI. Para minimizar os riscos para os sistemas de TI, é essencial que os usuários do sistema e aplicação seja fornecida com segurança treinamento de conscientização. Portanto, a segurança de TI ou de segurança formadores / profissionais no assunto deve entender o processo de gestão de risco, para que possam desenvolver materiais didáticos adequados e incorporar a avaliação de riscos em programas de treinamento para educar os usuários finais.

3. AVALIAÇÃO DE RISCO

A avaliação dos riscos é o primeiro processo na metodologia de gerenciamento de risco. Organizações utilizam avaliação do risco para determinar a extensão da ameaça potencial e o risco associado com um sistema de TI ao longo do seu SDLC. A saída deste processo ajuda a identificar os controles apropriados para reduzir ou eliminar o risco durante o processo de mitigação de risco, como discutido na Seção 4.

O risco é uma função da probabilidade de um dado. Ameaça de fonte está exercendo uma vulnerabilidade particular potencial, e o impacto resultante desse acontecimento adverso sobre a organização.

Para determinar a probabilidade de um evento futuro adverso, ameaças a um sistema de TI deve ser analisada em conjunto com as vulnerabilidades potenciais e os controles existentes para o sistema de TI. Refere-se a impacto a magnitude do dano que pode ser causado por uma ameaça de exercício de uma vulnerabilidade. O nível de impacto é governado pelos impactos de missão potenciais e, por sua vez produz um valor relativo para os ativos de TI e recursos afetados (por exemplo, a criticidade e sensibilidade dos componentes do sistema de TI e de dados). A metodologia de avaliação de risco abrange nove etapas principais, que são descritas nas secções 3.1 a 3,9.• Etapa 1 - Caracterização do sistema (Seção 3.1)• Passo 2 - Identificação de Ameaças (Seção 3.2)• Etapa 3 - Identificação de Vulnerabilidade (Seção 3.3)• Passo 4 - Análise de controle (Seção 3.4)• Passo 5 - Determinação de verossimilhança (Seção 3.5)• Passo 6 - Análise de Impacto (Seção 3.6)• Etapa 7 - Determinação de riscos (Seção 3.7)• Passo 8 - Recomendações de Controle (Seção 3.8)• Passo 9 - Documentação de Resultados (Seção 3.9).

Passos 2, 3, 4 e 6 pode ser conduzida em paralelo após o Passo 1 foi concluído. Figura 3-1 descreve estes passos e as entradas e saídas de cada etapa.

Entrada Atividades da Avaliação de Risco

Saída

• Hardware• Software• Interfaces do Sistema• Dados e informações• Pessoas• A missão do Sistema

Passo 1. Caracterização do Sistema

Limites do sistema:• Funções do Sistema• Criticidade do Sistema e Dados• Sensibilidade do Sistema e Dados

• História de ataque do sistema• Dados de agências de inteligência, NIPC, OIG, FedCIRC, meios de comunicação.

Passo 2. Identificação de ameaças.

Declaração de ameaça

• Relatórios de avaliações de risco anteriores• Quaisquer comentários auditoria• Requisitos de Segurança• Os resultados de testes de segurança

Passo 3. Identificação da vulnerabilidade

Lista de possíveis vulnerabilidades.

• Os controles atuais• Os controles planejados

Passo 4. Controle de Análise.

Lista dos controles atuais e planejados.

• Ameaça fonte de motivação.• Capacidade de ameaças.• Natureza da vulnerabilidade.• Os controles Dados atuais.·.

Passo 5. Determinação de probabilidade.

Classificação probabilidade.

• análise de impacto da Missão.• avaliação da criticidade de Ativos.• criticidade de dados• sensibilidade de Dados.

Passo 6. Análise do Impacto.• Perda de Integridade.• Perda de Disponibilidade.• Perda de Confidencialidade.

Avaliação do Impacto.

• Probabilidade de exploração ameaça.• Magnitude do impacto.• Adequação dos controles

Passo 7. Determinação do Risco

Riscos e níveis de risco associados.

Passo 8. Recomendações de controle

Controles recomendados

Passo 9. Documentação resultados.

Relatório de Avaliação do Risco

Figura 3-1. Fluxograma Metodologia de Avaliação do Risco

3.1 PASSO 1: caracterização do sistema.Ao avaliar os riscos para um sistema informático, o primeiro passo é a definir o âmbito do esforço. Nesta etapa, os limites do sistema de TI são identificados, juntamente com os recursos e as informações que compõem o sistema. Caracterizando um sistema de TI estabelece o escopo do esforço de avaliação de risco, delineia a autorização operacional (ou credibilidade) limites, e fornece informações (por exemplo, pessoal,

hardware, divisão de software, a conectividade do sistema, e responsável ou de apoio) essenciais para definir o risco.

Seção 3.1.1 descreve as informações relacionadas ao sistema usado para caracterizar um sistema de TI e seu ambiente operacional. Secção 3.1.2 sugere as técnicas de recolha de informações que podem ser usados para solicitar informação relevante para o ambiente de TI sistema de processamento.

A metodologia descrita no presente documento pode ser aplicada às avaliações de simples ou múltiplas, sistemas inter-relacionados. Neste último caso, é importante que o domínio de interesse e todas as interfaces e dependências de ser bem definido antes da aplicação da metodologia.

3.1.1 Informações relacionadas ao sistema.Identificação de risco para um sistema de TI requer um profundo conhecimento do ambiente de processamento do sistema. A pessoa ou pessoas que realizam a avaliação de risco deve primeira reunir informações relacionadas ao sistema, que geralmente é classificado como segue:• Hardware• Software• Interfaces de sistema (por exemplo, a conectividade interna e externa).• Dados e informações.• Pessoas que apoiam e usar o sistema de TI.• missão do sistema (por exemplo, os processos realizados pelo sistema IT).• criticidade sistema e os dados (por exemplo, o valor do sistema ou importância para uma organização).• Sistema de sensibilidade e de dados.

Informação adicional relacionado com o ambiente operacional do sistema informático e os seus dados incluem, mas não está limitado a, o seguinte:• Os requisitos funcionais do sistema de TI.• Os usuários do sistema (por exemplo, usuários do sistema que fornecem apoio técnico ao sistema de TI, os usuários de aplicativos que usam o sistema de TI para executar funções de negócios).• Sistema políticas de segurança que regem o sistema de TI (políticas organizacionais, requisitos federais, as leis, as práticas da indústria).• arquitetura de segurança do sistema.• topologia da rede atual. (por exemplo, um diagrama de rede).• Proteção armazenamento de informação que protege a disponibilidade do sistema e dados, integridade e confidencialidade.• Fluxo de informações relativas ao sistema de TI. (por exemplo, as interfaces do sistema, sistema de entrada e saída de fluxograma).• Controles de técnicas utilizadas para o sistema de TI. (por exemplo, built-in ou add-on produto de segurança que oferece suporte à identificação e autenticação, controle de acesso discricionário ou obrigatório, auditoria, proteção da informação residual, os métodos de criptografia).• Gestão controles usados para o sistema de TI. (por exemplo, regras de comportamento, a segurança planejamento).• Controles operacionais utilizados para o sistema de TI. (por exemplo, o pessoal de segurança, backup, contingência, e retomada e as operações de recuperação, manutenção do sistema; armazenamento off-site, criação de conta de usuário e os procedimentos de exclusão; controles de segregação de funções do usuário, tais como acesso de usuário privilegiado versus acesso de usuário padrão)• ambiente de segurança física do sistema de TI. (por exemplo, segurança das instalações, as políticas de centro de dados).• Segurança Ambiental, implementado para o ambiente de TI sistema de

processamento. (por exemplo, os controles de unidade, a água, a energia, a poluição, temperatura, e produtos químicos).

Para um sistema que está na fase de iniciação ou de design, a informação do sistema pode ser derivado a partir do documento de concepção ou requisitos. Para um sistema de TI em desenvolvimento, é necessário definir regras de segurança fundamentais e atributos planejados para o futuro sistema de TI. Documento de projeto de sistemas e do plano de segurança do sistema pode fornecer informações úteis sobre a segurança de um sistema de TI que está em desenvolvimento.

Para um sistema operacional de TI, os dados são coletados sobre o sistema de TI no seu ambiente de produção, incluindo dados sobre a configuração do sistema, conectividade e procedimentos documentados e não documentados e práticas. Portanto, a descrição do sistema pode ser baseada na segurança proporcionada pela infraestrutura subjacente ou em planos de segurança futuros para o sistema de TI.

3.1.2 Coleta de informações técnicas.Qualquer uma, ou uma combinação, das seguintes técnicas podem ser usadas na coleta de informações relevantes para o sistema de TI dentro de sua fronteira operacional:• Questionário: Para a coleta de informações relevantes, o pessoal de avaliação de risco pode desenvolver um questionário sobre os controles gerenciais e operacionais previstas ou usadas para o sistema de TI. Este questionário deverá ser distribuído aos aplicáveis a pessoal técnico e não técnicos que estão projetando ou apoiar o sistema de TI. O questionário também pode ser usado durante as visitas in loco e entrevistas.• No local entrevistas. Entrevistas com o suporte de TI e gestão de pessoal do sistema pode permitir que o pessoal de avaliação de risco para coletar informações úteis sobre o sistema de TI (por exemplo, como o sistema é operado e gerenciado). Visitas in loco também permitem que avaliação de risco pessoal para observar e coletar informações sobre a segurança física, ambiental e operacional do sistema de TI. O Apêndice A contém exemplos de perguntas feitas durante entrevista com o pessoal do site para obter uma melhor compreensão das características operacionais de uma organização. Para os sistemas ainda em fase de projeto, visita in loco seria cara a cara de coleta de dados exercícios e poderia proporcionar a oportunidade de avaliar o ambiente físico em que o sistema irá operar.• Revisão de Documentos. Documentos de política (por exemplo, a documentação legislativa, as diretivas), documentação do sistema (por exemplo, sistema de guia do usuário, manual do sistema administrativo, o projeto do sistema e documento de requisitos, documento de aquisição), e de segurança relacionadas com a documentação (por exemplo, relatório de auditoria anterior, relatório de avaliação de risco, resultados do sistema de teste, plano de sistema de segurança, políticas de segurança) pode fornecer boas informações sobre os controles de segurança utilizados por e planejadas para o sistema de TI. Análise de uma organização missão impacto ou avaliação importância dos ativos fornece informações a respeito do sistema e dados criticidade e sensibilidade.• Uso de ferramenta de verificação automática. Proativos métodos técnicos podem ser usados para coletar informações do sistema de forma eficiente. Por exemplo, uma ferramenta de mapeamento de rede pode identificar os serviços que são executados em um grande grupo de hosts e fornecer uma maneira rápida de criar perfis individuais do alvo sistemas de TI.

O recolhimento de informação pode ser realizado durante o processo de avaliação de risco, a partir do Passo 1 (Caracterização System) no Passo 9 (Documentação Resultados).

Saída da Etapa 1 - Caracterização do sistema de TI avaliada, uma boa imagem do

ambiente do sistema de TI, e delimitação de fronteira do sistema.

3.2 PASSO 2: identificação de ameaçasUma ameaça é o potencial para um determinado ameaça-source para exercer com sucesso uma vulnerabilidade particular. A vulnerabilidade é uma fraqueza que pode ser acionado acidentalmente ou intencionalmente explorado. Uma ameaça fonte não apresenta um risco quando não há vulnerabilidade que pode ser exercido. Para determinar a probabilidade de uma ameaça (Seção 3.5), deve-se considerar ameaça fontes, vulnerabilidades potenciais (seção 3.3), e controles existentes (Seção 3.4).

Ameaça: O potencial de uma fonte de ameaça ao exercício (gatilho acidentalmente ou intencionalmente explorar) uma vulnerabilidade específica.

3.2.1 Identificação da fonte de ameaçaO objetivo desta etapa é identificar as potenciais ameaças de fontes e compilar uma lista de ameaças declaração potenciais ameaças de fontes que são aplicáveis ao sistema de TI a ser avaliada.

Fonte de Ameaça: qualquer intenção ou método voltado para a exploração de uma vulnerabilidade que pode se acidentalmente ou ocasional.

Uma fonte de ameaça é definida como qualquer circunstância ou evento com potencial para causar danos a um sistema de TI. Uma fonte de ameaça comum pode ser natural, humana ou ambiental.

Na avaliação de fontes de ameaça, é importante considerar todo o potencial da fonte de ameaça que possam causar danos a um sistema de TI e seu ambiente de processamento. Por exemplo, embora a declaração de ameaça para um sistema de TI localizada em um deserto não possa incluir "inundação natural" por causa da baixa probabilidade de tal de ocorrência, ameaças ambientais, tais como ruptura de tubo que podendo rapidamente inundar uma sala de informática e causar danos uma organização de TI bens e recursos. Os seres humanos podem ser fontes de ameaça por meio de atos intencionais, como ataques deliberados por pessoas mal-intencionados ou funcionários descontentes, ou atos intencionais, como negligência e erros. Um ataque deliberado pode ser uma tentativa mal-intencionada para obter acesso não autorizado a um sistema de TI (por exemplo, através de adivinhação de senha), a fim de comprometer o sistema e integridade dos dados, a disponibilidade ou a confidencialidade ou do tipo benigno, mas ainda assim de propósito, tentativa de burlar a segurança do sistema. Um exemplo deste último tipo de ataque deliberado de escrita é um programador de um programa cavalo de Tróia para contornar a segurança do sistema, a fim de "fazer o trabalho”.

Fontes de ameaça Comum-ameaças de cheias naturais, terremotos, furacões, deslizamentos de terra, avalanches, tempestades elétricas, e outros eventos.-Ameaças de Eventos do Homem que, ou são ativados por, ou causados por seres humanos, tais como atos intencionais (entrada inadvertida de dados) ou ações deliberadas (ataques baseados na rede, software malicioso de upload, acesso não autorizado a informaçções confidenciais).-ameaças de longo prazo ambiental falta de energia, poluição, produtos químicos, vazamento de líquido.

3.2.2 Motivação e Ações de ameaças.Motivação e os recursos para a realização de um ataque fazer os seres humana potencialmente perigosa ameaça fontes. Tabela 3-1 apresenta uma visão geral de muitos dos atuais ameaças humanas comuns, suas possíveis motivações e os

métodos ou ações ameaça pelo qual eles poderiam realizar um ataque. Esta informação será útil para organizações que estudam os seus ambientes de ameaças humanas e personalizar as suas declarações de ameaças humanas. Além disso, revisões da história do sistema breakins, relatórios de violação de segurança, relatórios de incidentes; e entrevistas com os administradores de sistemas, help desk pessoal, e comunidade de usuários durante a coleta de informações vai ajudar a identificar humana ameaça de fontes que têm o potencial de causar danos de TI sistema e os seus dados e que pode ser uma preocupação onde existe uma vulnerabilidade.

Tabela 3-1 Ameaças Humana: Ameaça-Source, Motivação e Ações de ameaças.Origem da ameaça Motivação Ações da ameaçaHacker, cracker Desafio, Ego e Rebelião. • Hacking

• Engenharia Social• Sistema de intrusão, arrombamentos.• Acesso não autorizado ao sistema

Computador criminoso Destruição de informação, Divulgação de informações ilegais, Ganho monetário, Alteração não autorizada de dados··.

• O crime informático. (por exemplo, ciber perseguição).• ato fraudulento (por

exemplo, a repetição, a representação,

a intercepção).• Informação suborno• Spoofing• Sistema de intrusão.

Terrorismo Chantagem, Destruição, Exploração, Vingança.

• Bomba / Terrorismo• A guerra de informação• Sistema de ataque (por exemplo, negação de serviço distribuída).• Sistema de penetração• Sistema de adulteração

Espionagem industrial (empresas, governos estrangeiros, os interesses de outros governos).

Vantagem competitiva, A espionagem econômica.

• A exploração econômica.• O roubo de informações.• Invasão da privacidade pessoal.• Engenharia Social• Sistema de penetração• Acesso não autorizado ao sistema (acesso a informação classificada, de propriedade e / ou informação classificada, de propriedade e / ou tecnologia relacionada).

Insiders (mal treinados, descontente, malicioso, negligência, desonesto, ou funcionários demitidos).

Curiosidade, Ego, Inteligência, Ganho monetário, Vingança, Erros involuntários e omissões (por exemplo, os dados de entrada de erro, erro de programação) ·.

• Assalto a um empregado• Chantagem• Navegação de informações proprietárias• abuso do computador• Fraude e roubo• Informação suborno• Entrada de dados

falsificados, corrompidos.• Intercepção• Código malicioso. (por exemplo, vírus, bomba lógica cavalo de Tróia).• Venda de informações pessoais• Os erros do sistema• Sistema de intrusão• Sistema de sabotagem• Acesso não autorizado ao sistema

Uma estimativa da motivação, recursos e capacidades que podem ser necessárias para levar a cabo um ataque bem sucedido deve ser desenvolvida após o potencial de ameaça-fontes têm sido identificado, a fim de determinar a probabilidade de uma ameaça de exercer um sistema de vulnerabilidade, tal como descrito na seção 3.5.

A declaração de ameaça, ou a lista de potenciais ameaças de fontes, deve ser adaptada para a organização individual e seu ambiente de processamento (por exemplo, hábitos de computação do usuário final). Em geral, informação sobre as ameaças naturais (por exemplo, inundações, terremotos, tempestades) devem estar prontamente disponíveis. Ameaças conhecidas foram identificadas por muitos governos e organizações do setor privado. Ferramentas de detecção de intrusão também estão se tornando mais prevalente, e organizações governamentais e da indústria continuamente coletar dados sobre eventos de segurança, melhorando assim a capacidade de avaliar realisticamente ameaças. Fontes de informação incluem, mas não estão limitados a, o seguinte:• Agências de Inteligência (por exemplo, o Federal Bureau of Investigation Centro Nacional de Infraestrutura de Proteção).• Computer Incident Response Center Federal (FedCIRC)• Os meios de comunicação de massa, particularmente baseados na Web, recursos, tais como SecurityFocus.com, SecurityWatch.com, SecurityPortal.com e SANS.org.

Saída de Passo 2 - A declaração de ameaça com uma lista de ameaças de fontes que possam explorar as vulnerabilidades do sistema.

3.3 PASSO 3: identificação da vulnerabilidade.A análise da ameaça de um sistema de TI deve incluir uma análise das vulnerabilidades associadas com o ambiente do sistema. O objetivo deste passo é desenvolver uma lista de vulnerabilidades do sistema (falhas ou fraquezas) que poderiam ser exploradas pelos potenciais ameaças de fontes.

Vulnerabilidade: Uma falha ou fraqueza nos procedimentos de segurança do sistema, projeto, implementação ou controles internos que poderiam ser exercidas (acidentalmente ou intencionalmente provocado explorados) e resultar em uma violação de segurança ou uma violação da política de segurança do sistema.

Tabela 3-2 apresenta exemplos de pares de ameaças de vulnerabilidades.Vulnerabilidade Origem da ameaça Ações da ameaçaIdentificadores empregados encerrado do sistema (ID) não são removidos do sistema.

Funcionários demitidos. Discar para a rede da empresa e acessar os dados da empresa de propriedade

Firewall da empresa permite telnet de entrada,

Os usuários não autorizados (por exemplo,

Usando telnet ao servidor XYZ e navegar arquivos do

e ID de convidado está habilitada no servidor XYZ.

hackers, funcionários demitidos, criminosos da informática, terroristas).

sistema com a identificação do convidado

O fornecedor identificou falhas no design de segurança do sistema, no entanto, novos patches não tenham sido aplicados ao sistema.

Os usuários não autorizados (por exemplo, hackers, funcionários insatisfeitos, criminosos da informática, terroristas).

Obtenção de acesso não autorizado a arquivos confidenciais do sistema com base em vulnerabilidades do sistema conhecidos.

Data Center usa aspersão de água para suprimir o fogo; lonas para proteger hardware e equipamento de danos da água não estão no lugar.

Fogo, pessoas negligentes. Aspersão de água que está sendo ativado no centro de dados

Métodos recomendados para a identificação de vulnerabilidades do sistema são o uso de fontes de vulnerabilidade, o desempenho dos testes de segurança do sistema e o desenvolvimento de uma lista de verificação dos requisitos de segurança.

Deve notar-se que os tipos de vulnerabilidades que existirá, e a metodologia necessária para determinar se as vulnerabilidades estão presentes, normalmente irá variar dependendo da natureza do sistema de TI e a fase que se encontra, no SDLC:• Se o sistema ainda não tenha sido projetado, a busca de vulnerabilidades deve se concentrar em políticas de segurança da organização, procedimentos de segurança planejados, e definições de requisitos de sistema, e análises dos fornecedores ou desenvolvedores “de segurança do produto (por exemplo, White papers)”.• Se o sistema está sendo implementada, a identificação das vulnerabilidades deve ser expandido para incluir informações mais específicas, como a segurança planejada apresenta descrita na documentação do projeto de segurança e os resultados do teste de sistema de certificação e avaliação.• Se o sistema de TI é operacional, o processo de identificação de vulnerabilidades deve incluir uma análise das características do sistema de segurança de TI e os controles de segurança, técnicas e de procedimentos, utilizados para proteger o sistema.

3.3.1 Fontes de vulnerabilidadeAs vulnerabilidades técnicas e não técnicas associadas com o ambiente de um sistema informático de processamento podem ser identificadas através das técnicas de coleta de informações descritas na Seção 3.1.2. Uma revisão de outras fontes da indústria (por exemplo, páginas da Web do fornecedor que identificam erros e falhas do sistema) será útil na preparação para as entrevistas e no desenvolvimento de questionários eficazes para identificar as vulnerabilidades que podem ser aplicáveis a determinados sistemas de TI (por exemplo, uma versão específica do um sistema operacional específico). A Internet é outra fonte de informação sobre as vulnerabilidades do sistema conhecidos postados pelos fornecedores, juntamente com hot fixes, service packs, patches e outras medidas corretivas que podem ser aplicadas para eliminar ou reduzir as vulnerabilidades. Fontes de vulnerabilidade documentados que devem ser considerados em uma análise minuciosa de vulnerabilidade incluem, mas não estão limitados a, o seguinte:• documentação relativa à avaliação anterior do risco do sistema de TI avaliada.• Os relatórios do sistema de TI de auditoria, relatórios de anomalias do sistema, relatórios de análise de segurança e de teste do sistema e relatórios de avaliação.• As listas de vulnerabilidade, como a base de dados de vulnerabilidade NIST I-CAT. (Http://icat.nist.gov).• Os avisos de segurança, tais como FedCIRC e do Departamento de Informática da

Energia Incidente boletins Capacidade consultivos.• avisos de fornecedores.• Comercial de computador de incidentes / emergências equipes de resposta e as listas de correio. (por exemplo, mailings Securityfocus.com fórum).• Informações de Garantia de Alertas de Vulnerabilidade e boletins de sistemas militares.• análise do sistema de segurança de software.

3.3.2 Testes de segurança do sistemaMétodos pró-ativos, empregando o teste do sistema, pode ser usado para identificar as vulnerabilidades do sistema de forma eficiente, dependendo da criticidade do sistema de TI e recursos disponíveis (por exemplo, os fundos atribuídos, a tecnologia disponível, as pessoas com os conhecimentos necessários para realizar o teste). Os métodos de ensaio incluem:• A vulnerabilidade Automated ferramenta de varredura.• Teste de segurança e avaliação. (ST & E)• Os testes de penetração.

A ferramenta de verificação automatizada vulnerabilidade é utilizada para digitalizar um grupo de hosts ou uma rede de conhecidos serviços vulneráveis (por exemplo, o sistema permite transferência de arquivos anônimo Protocolo [FTP], afinação sendmail). No entanto, deve notar-se que alguns dos potenciais vulnerabilidades identificados pela ferramenta de verificação automatizada podem não representar reais vulnerabilidades no contexto do ambiente do sistema. Por exemplo, algumas dessas ferramentas de varredura de vulnerabilidades potenciais de taxa, sem considerar o ambiente do site e exigências. Algumas das “vulnerabilidades” sinalizadas pelo software de digitalização automática pode não ser realmente vulneráveis para um site particular, mas pode ser configurado dessa forma porque o ambiente exige. Assim, este método de teste pode produzir falsos positivos. ST&E é uma outra técnica que pode ser utilizado na identificação de TI vulnerabilidade do sistema durante o processo de avaliação do risco. Isso inclui o desenvolvimento e execução de um plano de teste (por exemplo, script de teste, procedimentos de teste, e os resultados dos testes esperados). A finalidade dos testes de segurança do sistema é testar a eficácia dos controles de segurança de um sistema de TI que tenham sido aplicadas em um ambiente operacional. O objetivo é garantir que os controles aplicados atender a especificação de segurança aprovado para o software e hardware e implementar a política de segurança da organização ou satisfazer os padrões da indústria.

Os testes de penetração podem ser usados para complementar à revisão de controles de segurança e garantir que as diferentes facetas do sistema de TI estão garantidas. Os testes de penetração, quando empregue no processo de avaliação do risco, podem ser usados para avaliar a capacidade de um sistema informático para resistir tentativas intencionais para contornar a segurança do sistema. Seu objetivo é testar o sistema de TI do ponto de vista de uma ameaça de fonte e identificar possíveis falhas nos sistemas de proteção do sistema de TI.

O resultado destes tipos de testes de segurança opcional ajudará a identificar algumas vulnerabilidades do sistema.

3.3.3 Desenvolvimento de Checklist de Requisitos de Segurança.Durante esta etapa, a equipe de avaliação de risco determinar se os requisitos de segurança previstos para o sistema de TI e coletadas durante a caracterização do sistema estão sendo atendidas pelos controles de segurança existentes ou previstas. Normalmente, os requisitos de segurança do sistema podem ser apresentados em forma de tabela, com cada exigência acompanhado de uma explicação de como o

design do sistema ou aplicação ou não satisfaz essa exigência de controle de segurança.

A lista de checagem de requisitos contém as normas básicas de segurança que podem ser usados para sistematicamente avaliar e identificar as vulnerabilidades dos ativos (pessoal, hardware, software, informação), procedimentos não automatizada, processos e transferência de informações associadas a um determinado sistema de TI nas seguintes áreas de segurança:• Gestão.• Operacional.• Técnico.

Tabela 3-3 Lista de critérios de segurança sugerido para uso na identificação de umas vulnerabilidades dos sistemas informáticos em cada área de segurança.

Tabela 3-3 Critérios de segurançaÁrea de Segurança Critérios de segurança.Segurança da Gestão • Atribuição de responsabilidades

• Continuidade de apoio• Capacidade de resposta a incidentes• Revisão periódica dos controles de segurança• A distância pessoal e investigações de fundo• A avaliação dos riscos• Segurança e treinamento técnico• Separação de funções• Sistema de autorização e reautorização• Sistema ou plano de segurança do aplicativo

Segurança Operacional • Controle de ar carregadas de contaminantes (fumaça, poeira, produtos químicos).• Controles para garantir a qualidade do fornecimento de energia elétrica• Dados de acesso ao meio e descarte• distribuição de dados externa e rotulagem• Facilidade de proteção. (por exemplo, sala de informática, data center, escritório).• controle de umidade• O controle da temperatura• Estações de trabalho, laptops e stand-alone computadores pessoais.

Segurança Técnica • Comunicações (por exemplo, dial-nos, a interligação do sistema, roteadores) ·.• Criptografia• Controle de Acesso Discricionário• Identificação e autenticação• Detecção de Intrusão• reutilização de objetos• Sistema de auditoria

O resultado deste processo é a lista de checagem de requisitos. Fontes que podem ser utilizados para a produção tal lista um incluem, mas não estão limitados a, o governo

seguinte regulamentar e diretivas de segurança e de fontes aplicáveis ao ambiente de processamento de sistema de TI:• CSA de 1987.• As normas federais de informação Publicações de Processamento.• OMB novembro 2000 Circular A-130.• Privacy Act de 1974.• plano de segurança do sistema do sistema de TI avaliado.• A organização de políticas de segurança, diretrizes e padrões.• As práticas da indústria.

O NIST SP 800-26 Guia de Segurança de Auto-Avaliação de Sistemas de Tecnologia da Informação, oferece um extenso questionário que contém objetivos de controle específicos contra a qual um sistema ou grupo de sistemas interconectados podem ser testados e avaliados. Os objetivos de controle são abstraídos diretamente de longa data requisitos contidos no estatuto, políticas e orientações sobre segurança e privacidade.

Os resultados da lista de verificação (ou questionário) podem ser usados como entrada para uma avaliação do cumprimento e descumprimento. Este processo identifica sistema, processo e fraquezas processuais que representam potenciais vulnerabilidades.

Saída a partir do Passo 3. Uma lista das vulnerabilidades do sistema (observações) que poderia ser exercida pelos potenciais ameaças de fontes.

3.4 PASSO 4: ANÁLISE DE CONTROLEO objetivo desta etapa é analisar os controles que foram implementados, ou estão previstas para a implementação, pela organização para minimizar ou eliminar a probabilidade (ou probabilidade) de uma ameaça do exercício de um sistema de vulnerabilidade.

Para obter uma classificação global de probabilidade que indica a probabilidade de que uma potencial vulnerabilidade pode ser exercida dentro da construção do ambiente de ameaças associadas (Passo 5 abaixo), a implementação de controles atuais ou previstos deve ser considerada. Por exemplo, uma vulnerabilidade (por exemplo, sistema ou fraqueza processual) não é susceptível de ser exercida ou a probabilidade é baixa, se houver um baixo nível de ameaça fonte de interesse ou capacidade, ou se existirem controles de segurança eficazes que podem eliminar ou reduzir a magnitude do dano.

Seções 3.4.1 através 3.4.3, respectivamente, discutir métodos de controle, categorias de controle, e a técnica de análise de controle.

3.4.1 Métodos de controle.Controles de segurança abrangem o uso de métodos técnicos e não técnicos. Os controles técnicos de salvaguardas que são incorporados hardware, software ou firmware (por exemplo, mecanismos de controle de acesso, identificação e mecanismos de autenticação, métodos de criptografia, software de detecção de intrusão). Controles não técnicos são controles gerenciais e operacionais, tais como políticas de segurança, procedimentos operacionais; e pessoal, física e de segurança ambiental.

3.4.2 Categorias de ControleAs categorias de controle para métodos de controle, tanto técnicos e não técnicos podem ainda ser classificados como preventivo ou detetive. Estas duas subcategorias são explicados como se segue:

• Controles preventivos inibir tentativas de violar a política de segurança e incluir controles tais como a aplicação de controle de acesso, criptografia e autenticação.• Avisar Controles de detecção de violações ou tentativas de violações da política de segurança e incluir controles, tais como trilhas de auditoria, métodos de detecção de intrusão, e checksums.

Seção 4.4 explica esses controles do ponto de vista de implementação. A implementação de tais controles durante o processo de mitigação de risco é o resultado direto da identificação de deficiências nos controles atuais ou previstas durante o processo de avaliação de risco (por exemplo, os controles não estão em vigor ou controles não são devidamente aplicadas).

3.4.3 Técnica de Análise de ControleConforme discutido na Seção 3.3.3, o desenvolvimento de uma lista de verificação dos requisitos de segurança ou uso de uma lista de verificação disponível será útil na análise de controles de forma eficiente e sistemática. A lista de checagem de requisitos pode ser usada para validar descumprimento de segurança, bem como o cumprimento. Portanto, é essencial para atualizar tais listas de verificação para refletir mudanças no ambiente de uma organização de controle (por exemplo, mudanças nas políticas de segurança, métodos e requisitos) para garantir a validade da lista de.

Saída a partir do Passo 4 - Lista de controles atual ou prevista utilizada para o sistema de TI para reduzir a probabilidade de a vulnerabilidade que está sendo exercido e reduzir o impacto de tal evento adverso.

3.5 PASSO 5: DETERMINAÇÃO PROBABILIDADEPara obter uma classificação global de probabilidade que indica a probabilidade de que uma potencial vulnerabilidade pode ser exercida dentro da construção do ambiente de risco associado, os seguintes fatores que regem devem ser considerados:• Ameaça de fonte de motivação e capacidade.• Natureza da vulnerabilidade.• Existência e efetividade dos controles atuais.

A probabilidade de que uma potencial vulnerabilidade poderia ser exercida por uma determinada fonte de ameaça, pode ser descrito como alto, médio ou baixo.

Tabela 3 - 4 abaixo descrevem esses três níveis de verossimilhança.

Tabela 3-4. Definições de probabilidadeNível de probabilidade Definição de probabilidadeAlto A ameaça de fonte é altamente motivado

e suficientemente capaz, e controles para evitar a vulnerabilidade de ser exercido são ineficazes.

Médio A ameaça de fonte é motivada e capaz, mas os controles estão no lugar que possa impedir o exercício bem sucedido da vulnerabilidade.

Baixo A ameaça de fonte carece de motivação ou capacidade, ou controles estão no local para evitar, ou pelo menos impedir significativamente, a vulnerabilidade de ser exercido.

Saída da Etapa 5 - Avaliação Probabilidade. (Alto, Médio, Baixo).

3.6 PASSO 6: ANÁLISE DO IMPACTOO próximo passo importante na medição do nível de risco é para determinar o impacto adverso resultante a partir de um exercício ameaça bem sucedida de uma vulnerabilidade. Antes de iniciar a análise de impacto, que é necessário para obter a informação seguinte necessário como discutido na Secção 3.1.1:• A missão do Sistema. (por exemplo, os processos realizados pelo sistema de IT).• Sistema de criticidade e de dados. (por exemplo, o valor do sistema ou importância para uma organização).• Sistema de sensibilidade e de dados.

Esta informação pode ser obtida a documentação existente organizacional, tais como o relatório de análise de impacto missão ou relatório de avaliação dos ativos da criticidade. A análise de impacto missão (também conhecida como análise de impacto nos negócios [BIA] para algumas organizações) prioriza os níveis de impacto associados com o comprometimento de ativos de informação da organização com base em uma avaliação qualitativa ou quantitativa da sensibilidade e criticidade desses ativos. Uma avaliação da criticidade ativo identifica e prioriza os ativos da organização sensíveis e críticos de informação (por exemplo, hardware, software, sistemas, serviços e ativos relacionados à tecnologia) que sustentam a organização missões críticas.

Se essa documentação não existe ou essas avaliações para a organização de ativos de TI não têm sido realizados, a sensibilidade do sistema e dos dados pode ser determinado com base no nível de proteção exigido para manter o sistema e disponibilidade dos dados, a integridade e confidencialidade.

Independentemente do método utilizado para determinar o quão sensível um sistema de TI e seus dados são, os proprietários de sistemas e informação são os responsáveis por determinar o nível de impacto para o seu próprio sistema e da informação. Consequentemente, na análise de impacto, a conduta adequada é entrevistar o sistema e proprietário da informação.

Portanto, o impacto adverso de um evento de segurança pode ser descrita em termos de perda ou a degradação de qualquer uma, ou uma combinação de qualquer uma, das seguintes três objetivos de segurança: integridade, disponibilidade e confidencialidade. A lista a seguir fornece uma breve descrição de cada meta de segurança e consequência (ou impacto) da sua não serem cumpridos:• Perda de Integridade. A integridade do sistema e os dados referem-se à exigência de que a informação ser protegido da modificação indevida. A integridade é perdida se as alterações não autorizadas são feitas para os dados ou sistema de TI, tanto por parte atos intencionais ou acidentais. Se a perda da integridade do sistema ou os dados não for corrigido, o uso continuado do sistema contaminado ou dados corrompidos pode resultar em inexatidão, fraude ou decisões erradas. Além disso, violação da integridade pode ser o primeiro passo de um ataque bem sucedido contra a disponibilidade do sistema ou confidencialidade. Por todas estas razões, a perda de integridade reduz a garantia de um sistema de TI.• Perda de Disponibilidade. Se um sistema de missão crítica de TI está indisponível para seus usuários finais, a missão da organização pode ser afetada. Perda de funcionalidade do sistema e eficácia operacional, por exemplo, pode resultar em perda de tempo produtivo, impedindo o desempenho dos usuários finais de suas funções no apoio à missão da organização.• Perda de Confidencialidade. Confidencialidade do sistema e de dados refere-se à proteção das informações contra divulgação não autorizada. O impacto da divulgação não autorizada de informações confidenciais pode variar desde o comprometimento da segurança nacional para a divulgação de dados da Lei de Privacidade. A divulgação não autorizada, imprevista, ou não intencional poderá resultar em perda da confiança

pública, embaraço ou ação legal contra a organização.

Alguns impactos tangíveis podem ser medidos quantitativamente em perda de receita, o custo da reparação do sistema, ou o nível de esforço necessário para corrigir problemas causados por uma ação bem sucedida ameaça. Outros impactos (por exemplo, perda de confiança do público, a perda de credibilidade, danos ao interesse de uma organização) não podem ser medidos em unidades específicas, mas pode ser qualificado ou descrita em termos de impactos alto, médio e baixo. Devido à natureza genérica da presente discussão, este guia designa e descreve apenas o impacto qualitativo categorias de alta, média e baixa (ver Tabela 3.5).

Tabela 3-5. Magnitude de definições de impactoMagnitude do Impacto Definições do ImpactoAlto Exercício da vulnerabilidade (1) pode

resultar na perda muito caro dos principais ativos tangíveis ou recursos; (2) pode significativamente violar, prejudicar ou impedir a missão de uma organização, a reputação, ou interesse, ou (3) pode resultar em morte humana ou ferimentos graves.

Médio Exercício da vulnerabilidade (1) pode resultar na perda de cara de ativos tangíveis ou recursos; (2) pode violar prejudicar ou impedir a missão de uma organização, a reputação, ou interesse, ou (3) pode resultar em ferimentos.

Baixo Exercício da vulnerabilidade (1) pode resultar na perda de alguns ativos tangíveis ou recursos ou (2) pode afetar perceptivelmente missão de uma organização, a reputação, ou interesse.

Avaliação Quantitativa versus qualitativa

Na realização da análise de impacto, devem-se considerar as vantagens e desvantagens de avaliações quantitativas versus qualitativa. A principal vantagem da análise de impacto qualitativa é que ela prioriza os riscos e identifica áreas de melhoria imediata na resolução das vulnerabilidades. A desvantagem da análise qualitativa é que ela não fornece medições específicas quantificáveis da magnitude dos impactos, portanto, fazer uma análise custo-benefício de qualquer controle recomendadas difíceis.

A principal vantagem de uma análise quantitativa de impacto é que ele fornece uma medida da magnitude dos impactos ', que pode ser usado na análise custo benefício dos controles recomendadas. A desvantagem é que, dependendo da gama numéricas usadas para expressar a medição, o significado da análise quantitativa de impacto pode não ser claro, exigindo que o resultado deva ser interpretado de forma qualitativa. Fatores adicionais muitas vezes devem ser considerados para determinar a magnitude do impacto. Estes podem incluir, mas não estão limitados a:• Uma estimativa da frequência do exercício a ameaça de fonte de a vulnerabilidade durante um período de tempo especificado. (por exemplo, 1 ano).• Um custo aproximado para cada ocorrência de exercício a ameaça de fonte de vulnerabilidade.• Um fator ponderado com base em uma análise subjetiva do impacto relativo de uma ameaça específica é exercer uma vulnerabilidade específica.

Saída do Passo 6 - Magnitude do impacto (Alto Médio ou Baixo)

3.7 PASSO 7: determinação do riscoO propósito deste passo é o de avaliar o nível de risco para o sistema de TI. A determinação do risco de um par ameaça / vulnerabilidade particular pode ser expressa como uma função de:• A probabilidade de uma dada ameaça de fonte está tentando exercer uma determinada vulnerabilidade.• A magnitude do impacto se uma ameaça fonte exercer com sucesso a vulnerabilidade.• A adequação dos controles de segurança já existente ou planejada para reduzir ou eliminar o risco.

Para medir o risco, uma escala de risco e uma matriz de nível de risco devem ser desenvolvidas. Seção 3.7.1 apresenta uma matriz de risco em nível de padrão;

Seção 3.7.2 descreve os níveis de risco resultantes.

3.7.1 Matriz de Nível de RiscoA determinação final da missão de risco é resultado da multiplicação dos ratings atribuídos pela probabilidade de ameaça (por exemplo, a probabilidade) e impacto ameaça. Tabela 3.6 abaixo mostra como as classificações globais de risco podem ser determinadas com base em contributos a probabilidade de ameaça e categorias de impacto de ameaças. A matriz abaixo é uma matriz 3 x 3 de probabilidade de ameaça (Alto, Médio e Baixo) e impacto ameaça (Alto Médio e Baixo). Dependendo dos requisitos do site e a granularidade da avaliação de risco desejado, alguns sites podem usar um 4 x 4 ou um 5 x 5 matriz. O último pode incluir uma ameaça probabilidade muito baixa / muito alta e um impacto ameaça Muito Baixo / Muito Alta para gerar um nível de risco muito baixa / muito alta. No nível de risco "Muito Elevado" pode exigir o desligamento do sistema ou a paragem do possível toda a integração do sistema de TI e os esforços de teste.

A matriz da amostra na Tabela 3-6 mostra como os níveis globais de risco de Alta, Média e Baixa são derivadas. A determinação dos níveis de risco ou avaliações pode ser subjetiva. A razão para esta justificação pode ser explicada em termos da probabilidade atribuído para cada nível de probabilidade ameaça e um valor atribuído para cada nível de impacto. Por exemplo,• A probabilidade atribuída para cada nível de probabilidade de ameaça é de 1,0 para alta, de 0,5 para Médio, 0,1 para Baixo.• O valor atribuído para cada nível de impacto é de 100 para alta, 50 para médio e 10 para baixo.

Tabela 3-6 Matriz de Nível de Risco

Probabilidade de ameaçasImpacto

Baixo(10)

Médio(50)

Alto(100)

Alta (1.0) Baixo

10x1. 0=10Médio

50x1. 0=50

Alto100x1. 0=100

Médio (0.5)Baixo

10x0. 5=5Médio

50x0. 5=25

Alto100x0. 5=50

Baixa (0.1)Baixo

10x0. 1=1Médio

50x0. 1=5

Alto100x0. 1=10

Escala de Risco: Alto (>50 até 100); Médio (>10 até 50); Baixo (1 até 10).

OBS: Se o nível indicado nos itens certos é tão baixo a ponto de ser considerada "desprezível", ou não significativa (o valor é <1 na escala de risco de 1 a 100), pode-se desejar mantê-las de lado em um balde separado em vez de encaminhamento para medidas de gestão. Isso fará com que eles não sejam esquecidos quando da avaliação de risco periódica seguinte. Também estabelece um registro completo de todos os riscos identificados na análise. Estes riscos podem mudar para um novo nível de risco em uma reavaliação devido a uma mudança na probabilidade de ameaça e / ou impacto e é por isso que é fundamental que não se perca a sua identificação no exercício.

3.7.2 Descrição do Nível de RiscoTabela 3-7 descreve os níveis de risco mostrados na matriz acima. Esta escala de risco, com suas classificações de Alta, Média e Baixa, representam o grau ou nível de risco a que um sistema de TI, instalação ou procedimento pode ser expostos se a vulnerabilidade em questão foram exercidas. A escala de risco também apresenta ações que a gerência sênior, os donos da missão, deve levar para cada nível de risco.

Tabela 3-7. Escala de risco e as ações necessáriasNível do Risco Descrição risco e as ações necessáriasAlto Se uma observação ou achado é avaliado

como um risco elevado, existe uma forte necessidade de medidas corretivas. Um sistema existente pode continuar a operar, mas um plano de ação corretiva deve ser colocado em prática o mais rápido possível.

Médio Se uma observação é classificada como de médio risco, ações corretivas são necessárias e um plano deve ser desenvolvido para incorporar essas ações dentro de um período razoável de tempo.

Baixo Se uma observação é descrita como de baixo risco, DAA do sistema deve determinar se as ações corretivas são ainda necessárias ou decidir a aceitar o risco.

Saída de Passo 7 - Nível de risco. (Alto, Médio, Baixo).

3.8 PASSO 8: RECOMENDAÇÕES DE CONTROLEDurante este passo do processo, os controles que podem mitigar ou eliminar os riscos identificados, tal como apropriada para as operações da organização, são fornecidos. O objetivo dos controles recomendados é o de reduzir o nível de risco para o sistema de TI e os seus dados para um nível aceitável. Os seguintes fatores devem ser considerados na recomendação de controles e soluções alternativas para minimizar ou eliminar os riscos identificados:• Eficácia das opções recomendadas. (por exemplo, a compatibilidade do sistema).• Legislação e regulamentação.• A política organizacional.• O impacto operacional.• Segurança e confiabilidade.

As recomendações de controle são os resultados do processo de avaliação de risco e contribuir para o processo de mitigação de risco, durante o qual os controles de

segurança recomendadas processuais e técnicas são avaliadas, priorizadas e implementadas.

Deve ser notado que nem todos os controles possíveis recomendadas pode ser implementado para reduzir a perda. Para determinar quais são necessários e adequados para uma organização específica, uma análise de custo-benefício, conforme discutido na Seção 4.6, devem ser conduzidos para os controles propostas recomendadas, para demonstrar que os custos de implementação dos controles pode ser justificada pela redução o nível de risco. Além disso, o impacto operacional (por exemplo, o efeito no desempenho do sistema) e viabilidade (por exemplo, requisitos técnicos, de aceitação do usuário) de introduzir a opção recomendada devem ser cuidadosamente avaliados durante o processo de mitigação de riscos.

Saída de Passo 8 - Recomendação de soluções de controle e alternativas para mitigar o risco.

3.9 PASSO 9: DOCUMENTAÇÃO DOS RESULTADOSUma vez que a avaliação de risco foi concluída (ameaças e vulnerabilidades de fontes identificadas, riscos avaliados, e os controles recomendados fornecidos), os resultados devem ser documentados em um relatório oficial ou briefing.

Um relatório de avaliação de risco é um relatório de gestão que ajuda a gerência sênior, os proprietários de missão, tomar decisões sobre o orçamento, política, processual, e sistema de mudanças operacionais e de gestão. Ao contrário de um relatório de auditoria ou investigação, que olha para o erro, um relatório de avaliação de risco não deve ser apresentado de forma acusatória, mas como uma abordagem sistemática e analítica para avaliar o risco para que o gerenciamento sênior vá compreender os riscos e alocar recursos para reduzir e corrigir potenciais perdas. Por esta razão, algumas pessoas preferem abordar os pares ameaça / vulnerabilidade como observações em vez de resultados no relatório de avaliação de risco. Apêndice B proporciona um esquema sugerido para o relatório de avaliação de risco.

Saída de Passo 9 - relatório de avaliação de riscos que descreve as ameaças e vulnerabilidades mede o risco, e fornece recomendações para implementação de controle.

4. REDUÇÃO DO RISCO

Redução de riscos, o segundo processo de gestão de risco, envolve priorizar, avaliar e implementar o apropriado de redução de risco controles recomendado a partir do processo de avaliação de risco.

Dado que a eliminação de todos os riscos é geralmente impraticável ou quase impossível, é de responsabilidade da administração sênior e os gerentes funcionais e de negócios a utilizar o método de menor custo e implementar os controles mais adequados para diminuir o risco da missão a um nível aceitável, com o mínimo impacto adverso sobre os recursos da organização e missão.

Esta seção descreve as opções de redução de risco (Seção 4.1), a estratégia de mitigação de risco (Seção 4.2), uma abordagem para implementação de controle (Seção 4.3), categorias de controle (Seção 4.4), a análise custo-benefício utilizado para justificar a implementação do recomendado controles (Seção 4.5), e o risco residual (seção 4.6).

4.1 Opções de redução de risco

Redução de riscos é uma metodologia sistemática usada pela gerência sênior para reduzir o risco da missão. Redução do risco pode ser conseguida através de qualquer das opções de mitigação de risco seguintes:• Assunção de Riscos. Para aceitar o risco potencial e continuar operando o sistema de TI ou para implementar controles para reduzir o risco a um nível aceitável.• Prevenção de riscos. Para evitar o risco, eliminando o risco de causa e / ou consequência. (por exemplo, abrir mão de certas funções do sistema ou desligar o sistema quando os riscos são identificados).• Limitação de Risco. Para limitar o risco através da implementação de controles que minimizem o impacto negativo de uma ameaça é exercer uma vulnerabilidade (por exemplo, o uso de apoio, prevenção controles, detetive).• Planejamento de Riscos. Para gerenciar o risco através do desenvolvimento de um plano de mitigação de risco que prioriza, implementa e mantém controles.• Pesquisa e Reconhecimento. Para diminuir o risco de perda do reconhecimento da vulnerabilidade ou falha e pesquisando controles para corrigir a vulnerabilidade.• Transferência de Risco. Para transferir o risco usando outras opções para compensar a perda, como a compra de seguros.

Os objetivos e missão de uma organização devem ser considerados na seleção qualquer uma dessas opções de mitigação de risco. Pode não ser prático para resolver todos os riscos identificados, por isso deve ser dada prioridade à ameaça e vulnerabilidade pares que têm o potencial de causar impacto significativo ou prejuízo missão. Além disso, na salvaguarda da missão de uma organização e seus sistemas de TI, devido ao ambiente único de cada organização e objetivos, a opção usada para mitigar o risco e os métodos utilizados para implementar controles podem variar. O "best of breed" abordagem é a utilização de tecnologias apropriadas, dentre os vários produtos de segurança do fornecedor, juntamente com a opção apropriada de mitigação de risco e não técnicos, medidas administrativas.

4.2 Estratégias redução de riscosA gerência sênior, os proprietários de missão, conhecendo os potenciais riscos e controles recomendados, pode perguntar, "Quando e em que circunstâncias devem agir? Quando devo implementar esses controles para mitigar o risco e proteger a nossa organização?”.

O gráfico de mitigação de riscos na Figura 4-1 aborda estas questões. Pontos apropriados para a implementação das ações de controle estão indicados nesta figura com a palavra SIM.

Figura 4-1. Redução de risco Pontos de Ação

Esta estratégia é ainda mais articulada nos seguintes regras de ouro, que fornecem orientações sobre ações para reduzir os riscos de ameaças intencionais humanos:• Quando vulnerabilidade (ou falha, fraqueza) existe ➞ implementar técnicas de garantia para reduzir a probabilidade de uma vulnerabilidade que está sendo exercido.• Quando uma vulnerabilidade pode ser exercida ➞ aplicar as salvaguardas em camadas, projetos de arquitetura e controles administrativos para minimizar o risco ou evitar esta ocorrência.• Quando o custo do atacante é menor que o ganho potencial ➞ aplicar as salvaguardas para diminuir a motivação de um invasor, aumentando o custo do atacante (por exemplo, o uso de controles do sistema, tais como limitar o que um usuário do sistema pode acessar e não pode reduzir significativamente o ganho de um atacante).• Quando a perda é muito grande ➞ aplicar os princípios de design, desenhos arquitetônicos e proteções técnicos e não técnicos para limitar a extensão do ataque, reduzindo o potencial de perda.

A estratégia delineada acima, com exceção do terceiro item da lista ("Quando o custo do atacante é menor que o ganho potencial"), também se aplica para a redução dos riscos resultantes da ambiental ou não intencionais ameaças humanas (por exemplo, sistema, ou erros do usuário). (Porque não há nenhum "intruso", sem motivação ou o ganho está envolvido.).

4.3 ABORDAGENS PARA A APLICAÇÃO DE CONTROLEQuando as ações de controle devem ser tomadas, a seguinte regra:

Abordar os maiores riscos e lutar pela mitigação de risco suficiente com o menor custo, com um impacto mínimo sobre as capacidades outra missão.

A metodologia de redução de risco a seguir descreve a abordagem para controlar a sua aplicação:• Etapa 1 - Priorizar açõesCom base nos níveis de risco apresentados no relatório de avaliação de risco, as ações de implementação são priorizados. Na alocação de recursos, a prioridade deve ser dada ao risco itens com rankings de risco inaceitavelmente elevada (por exemplo, o risco atribuído um nível de risco muito elevado ou alto). Estes pares de vulnerabilidade / ameaça exigirá ação corretiva imediata para proteger o interesse de uma organização e missão.

Saída da etapa 1 - Ações ranking de alto para baixo.

• Etapa 2 - Avaliar Opções de controle recomendadasOs controles recomendados no processo de avaliação de risco não podem ser as opções mais adequadas e viáveis para uma organização específica e sistema de TI. Durante este passo, a viabilidade (por exemplo, a compatibilidade de aceitação do usuário,) e eficácia (por exemplo, o grau de proteção e de nível de atenuação de risco) das opções de controlo recomendadas são analisadas. O objetivo é selecionar a opção de controle mais adequado para minimizar os riscos.

Saída da etapa 2 - Lista de controles possíveis

• Etapa 3 - Análise Custo-Benefício CondutaPara auxiliar a gestão na tomada de decisões e para identificar o custo-eficácia dos controles, uma análise custo-benefício é conduzida. Secção 4.5 detalha os objetivos e método de realização da análise custo-benefício.

Saída da etapa 3 - Análise custo-benefício descrever os custos e benefícios da implementação ou não implementação dos controles.

• Etapa 4 - controle de seleçãoCom base nos resultados da análise custo-benefício, gestão determina o controle mais custo-efetivo (s) para reduzir o risco para a missão da organização. Os controles selecionados devem combinar técnica, operacional e elementos de controlo de gestão para garantir a segurança adequada para o sistema de TI e da organização.

Saída a partir da etapa 4 - Seleção de controle

• Etapa 5 - Atribuir ResponsabilidadePessoas adequadas (in-house pessoal ou contratação de pessoal externo) que possuem o conhecimento adequado e conjuntos de capacidades para implementar o controle selecionado são identificados, e a responsabilidade é atribuída.

Saída de Etapa 5 - Lista das pessoas responsáveis.

• Etapa 6 - Desenvolver um Plano de Implementação de SalvaguardasDurante esta etapa, a implementação de salvaguarda pLAN9 (ou plano de ação) é desenvolvido. O plano deve, no mínimo, conter as seguintes informações:- Riscos (vulnerabilidade / ameaça pares) e níveis de risco associados (saída do relatório de avaliação de risco).- Controles recomendados. (saída do relatório de avaliação de risco)- Ações prioritárias. (com prioridade para itens com níveis de risco muito alto e alto)- Seleção de controles planejados. (determinado com base na viabilidade, eficácia e benefícios para a organização e custo).- Recursos necessários para a implementação dos controles selecionados planejados.- Listas de equipes responsáveis e funcionários.

- Data de início para a implementação.- Data de conclusão prevista para a implementação.- Os requisitos de manutenção.

O plano de implementação de salvaguarda prioriza as ações de implementação e projetos de início e datas de conclusão alvo. Este plano vai ajudar e agilizar o processo de mitigação de riscos. Apêndice C fornece uma tabela de resumo de exemplo para o plano de implementação de salvaguarda.

Saída de Passo 6 - Salvaguarda do plano de implementação

• Etapa 7 - Implementar controle selecionadoDependendo das situações individuais, os controles implementados podem diminuir o nível de risco, mas não eliminar o risco. O risco residual é discutido na Seção 4.6.

Saída de Passo 7 - risco residual.

Figura 4-2 descreve a metodologia recomendada para a redução de riscos.Entrada Atividades de redução de

riscoSaída

• Os níveis de risco a partir do relatório de avaliação de risco.

Passo 1 Priorizar ações Ações do ranking do decrescente

• Relatório de avaliação de riscos

Passo 2 Avaliar as opções de controle recomendadas• Viabilidade• Eficácia

Lista de possíveis controles

Passo 3 Realizar Análise Custo- Benefício• Impacto da execução.• Impacto da não execução.• Os custos associados.

Análise custo-benefício

Passo 4 Seleção de controle

Controles selecionados

Passo 5 Atribuir Responsabilidade

Lista das pessoas responsáveis

Passo 6 Desenvolver Plano de Implementação para Salvaguardar• Riscos e níveis de risco associados• As ações prioritárias• Controles Recomendados• Escolhidas controles planejados• As pessoas responsáveis• Data de Início• data de conclusão prevista• Exigências de manutenção

Salvaguardar do plano de implementação

Passo 7 Implementar os controles selecionados

Riscos Residuais

Figura 4-2. Fluxograma de risco metodologia de mitigação

4.4 CATEGORIAS DE CONTROLENa implementação de controles recomendados para mitigar o risco, uma organização deve considerar a gestão, técnicas, operacionais e controles de segurança, ou uma combinação de tais controles, para maximizar a eficácia dos controles para os seus sistemas de TI e da organização. Controles de segurança, quando utilizado adequadamente, podem evitar limitar ou impedir ameaça fonte de danos para a missão de uma organização.

O processo de recomendação de controle envolve escolher entre uma combinação de técnica, de gestão e controles operacionais para melhorar a postura de segurança da organização. O trade-offs que uma organização terá que considerar é ilustrado por ver as decisões envolvidas na aplicação de uso de senhas de usuários complexas para minimizar a adivinhação de senha e rachaduras. Neste caso, uma técnica que requeiram controla extra software de segurança pode ser mais complexa e dispendiosa do que um procedimento de controle, mas o controlo técnica é provável que seja mais eficaz porque a aplicação é automatizada pelo sistema. Por outro lado, um procedimento de controle pode ser implementado simplesmente por meio de um memorando a todos os indivíduos interessados e uma mudança das diretrizes de segurança para a organização, mas garantindo que os usuários sempre seguir o memorando e orientação serão difíceis e exigirá a conscientização da segurança treinamento e aceitação do usuário.

Esta seção fornece uma visão geral de alto nível de algumas das categorias de controle. Orientações mais detalhadas sobre a implementação e planejamento para os controles de TI pode ser encontrado em NIST SP 800-18, Guia para o Desenvolvimento de Planos de Segurança para Sistemas de Tecnologia da Informação, e NIST SP 800-12, An Introduction to Computer Security: The NIST Handbook.

Seções 4.4.1 através 4.4.3 fornecer uma visão geral técnica, gestão e controles operacionais, respectivamente.

4.4.1 Técnicas Controles de SegurançaControles técnicos de segurança para a mitigação do risco pode ser configurado para se proteger contra certos tipos de ameaças. Esses controles podem variar de simples a complexas medidas e geralmente envolvem arquiteturas de sistemas; disciplinas de engenharia e pacotes de segurança com uma combinação de hardware, software e firmware. Todas estas medidas devem trabalhar juntos para proteger dados críticos e sensíveis, informações e funções do sistema de TI. Os controles técnicos podem ser agrupados nas seguintes categorias principais, de acordo com a principal finalidade:• Suporte (Seção 4.4.1.1). Controles de apoio são genéricos e está subjacente a maioria dos recursos de segurança de TI. Esses controles devem estar no local, a fim de implementar outros controles.• Prevenir (Seção 4.4.1.2). Controles preventivos foca a prevenção de violações de segurança ocorra em primeiro lugar.• detectar e recuperar (Seção 4.4.1.3). Esses controles se concentrar em detectar e recuperar de uma quebra de segurança.

Figura 4-3 ilustra os controles principais técnicas e as relações entre eles.

Figura 4-3. CONTROLES TÉCNICOS DE SEGURANÇA

4.4.1.1 Controles Técnicos de ApoioControles de apoio são, pela sua própria natureza, penetrante e inter-relacionado com muitos outros controles. Os controles de apoio são como se segue:• Identificação. Esse controle fornece a capacidade de identificar os usuários, processos e recursos de informação. Para implementar controles de segurança (por exemplo, controle de acesso discricionário [DAC], controle de acesso obrigatório [MAC] prestação de contas), é essencial que ambos os sujeitos e objetos serem identificáveis.• Gestão de chave criptográfica. As chaves criptográficas devem ser gerenciadas com segurança quando as funções criptográficas são implementadas em vários outros controles. Gerenciamento de chaves de criptografia inclui geração de chaves, distribuição, armazenamento e manutenção.• Administração de Segurança. Os recursos de segurança de um sistema de TI devem ser configurados (por exemplo, ativado ou desativado) para atender as necessidades de uma instalação específica e ter em conta as mudanças no ambiente operacional. A segurança do sistema pode ser construída em segurança do sistema operacional ou o aplicativo. Comercial fora o suplemento prateleira de produtos de segurança estão

disponíveis.• Proteções do Sistema. Subjacente à capacidade de um sistema de segurança diversos sectores funcionais é uma base de confiança na execução técnica. Isto representa a qualidade da execução do ponto de vista tanto do desenho processos utilizados e da maneira em que a aplicação foi realizada. Alguns exemplos de proteções do sistema são a proteção das informações residual (também conhecida como a reutilização de objetos), pelo privilégio (ou "precisa saber"), a separação do processo, modularidade, camadas e minimização do que precisa ser confiável.

4.4.1.2 Controles Técnicos preventivosEstes controles, que pode inibir as tentativas de violação de segurança, incluem o seguinte:• Autenticação. O controle de autenticação fornece os meios de verificação da identidade de um sujeito para garantir que uma identidade é válida. Mecanismos de autenticação incluem senhas, números de identificação pessoal, ou PINs, e tecnologia de autenticação emergente que fornece autenticação forte (por exemplo, token, smart card, certificado digital, Kerberos).• Autorização. O controle de autorização permite que a especificação e posterior gestão das ações permitidas para um determinado sistema (por exemplo, o proprietário da informação ou o administrador do banco determina quem pode atualizar um arquivo compartilhado acessado por um grupo de usuários on-line).• Aplicação de Controle de Acesso. Integridade dos dados e a confidencialidade são impostas por controles de acesso. Quando o assunto solicitando o acesso foi autorizado a acessar determinados processos, é necessário para fazer cumprir a política de segurança definida (por exemplo, MAC ou DAC). Esses controles baseados em políticas são aplicados através de mecanismos de controle de acesso distribuídos por todo o sistema (por exemplo, rótulos de sensibilidade MAC, conjuntos de permissões de arquivos CAD, listas de controle de acesso, funções, perfis de usuário). A eficácia e a força de controlo de acesso dependem da exatidão das decisões de controlo de acesso (por exemplo, como as regras de segurança são configuradas) e a força de aplicação de controlo de acesso (por exemplo, o desenho de segurança de software ou hardware).• não repúdio. Responsabilidade do sistema depende da capacidade de garantir que o remetente não pode negar o envio de informações e que o receptor não se pode negar a sua recepção. Não repúdio abrange tanto a prevenção e detecção. Foi colocado na categoria prevenção neste guia, pois os mecanismos implementados evitar o repúdio de sucesso de uma ação (por exemplo, o certificado digital que contém a chave privada do proprietário é conhecido apenas para o proprietário). Como resultado, este controle é normalmente aplicado no ponto de transmissão ou recepção.• Protegido Comunicações. Em um sistema distribuído, a capacidade de realizar os objetivos de segurança é altamente dependente de comunicações confiáveis. O controle de comunicações protegida garante a integridade, disponibilidade e confidencialidade das informações sensíveis e críticos enquanto ele estiver em trânsito. Comunicações protegidas utilizar métodos de criptografia de dados (por exemplo, rede privada virtual, o Internet Protocol Security [IPSEC] Protocol), e implantação de tecnologias de criptografia (por exemplo, Data Encryption Standard [DES], Triple DES, RAS, MD4, MD5, Secure Hash Standard, e algoritmos de criptografia em caução, como Clipper) para minimizar as ameaças de rede, tais como repetição, a interceptação de pacotes, cheirando, grampos, ou de espionagem.• Privacidade de Transação. Tanto o governo e os sistemas do setor privado estão cada vez mais necessários para manter a privacidade dos indivíduos. Controles de transação privacidade (por exemplo, Secure Sockets Layer shell seguro) proteger contra a perda de privacidade com relação às transações realizadas por um indivíduo.

4.4.1.3 Detecção e Controles de recuperação técnicaControles de detecção de violações de avisar ou violações tentativas de política de

segurança e incluir controles, tais como trilhas de auditoria, métodos de detecção de intrusão, e checksums. Controle de recuperação pode ser usado para restaurar recursos computacionais perdidos. Eles são necessários como complemento às medidas de apoio e técnica preventiva, porque nenhuma das medidas nessas outras áreas é perfeita. Controles de detecção e de recuperação incluem:• Auditoria. A auditoria de segurança relevantes eventos e o monitoramento e rastreamento de anormalidades do sistema são elementos importantes para a detecção depois do fato de, e recuperação de falhas de segurança.• Detecção de Intrusão e de contenção. É essencial para detectar falhas de segurança (por exemplo, rede de arrombamento, atividades suspeitas) de modo que uma resposta pode ocorrer em tempo hábil. Também é de pouca utilidade para detectar uma violação de segurança se não houver resposta eficaz pode ser iniciado. A detecção de intrusão e controle de contenção fornece estas duas capacidades.• Comprovante de Totalidade. O controle de prova de integridade (por exemplo, a ferramenta de integridade do sistema) analisa a integridade do sistema e as irregularidades e identifica riscos e ameaças potenciais. Esse controle não impede violações da política de segurança, mas detecta violações e ajuda a determinar o tipo de ação corretiva necessária.• Restaurar estado seguro. Este serviço permite que um sistema para retornar a um estado que é conhecido por ser seguro, após uma falha de segurança ocorre.• Detecção de vírus e erradicação. Detecção de vírus e software erradicação instalado em servidores e estações de trabalho do usuário detecta, identifica e remove vírus de software para garantir a integridade do sistema e de dados.

4.4.2 Controles de Segurança da GestãoControles de gerenciamento de segurança, em conjunto com controles técnicos e operacionais, são implementadas para gerenciar e reduzir o risco de perda e para proteger a missão de uma organização. Gestão controla o foco sobre a estipulação da política de proteção de informações, as diretrizes e normas, que são realizadas através de procedimentos operacionais para cumprir as metas da organização e missões.

Controles de gestão de segurança preventiva, detecção e recuperação de que são implementadas para reduzir o risco são descritos nas secções 4.4.2.1 através 4.4.2.3.

4.4.2.1 Controles de Segurança Preventiva de GestãoEsses controles incluem o seguinte:• Atribuir a responsabilidade de segurança para garantir que a segurança é o adequado para as missões críticas sistemas de TI.• a segurança de o sistema desenvolver e manter planos para documentar controles atuais e controles endereço planejados para os sistemas de TI em apoio à missão da organização.• Implementar controles de pessoal de segurança, incluindo a separação de funções, pelo privilégio, e registro de usuário o acesso ao computador e terminação.• Realizar a conscientização da segurança e formação técnica para garantir que os usuários finais e usuários do sistema estão cientes das regras de comportamento e de suas responsabilidades na proteção a missão da organização.

4.4.2.2 Detecção de Controles de Segurança da GestãoControles de gestão de detecção são como se segue:• Implementar controles de pessoal de segurança, incluindo o pessoal de folga, as investigações de fundo, rotação de funções.• Realizar revisão periódica dos controles de segurança para garantir que os controles são eficazes.• Realizar auditorias de sistema periódico.• Realizar gestão de risco em andamento para avaliar e mitigar riscos.• Autorizar os sistemas de TI para enfrentar e aceitar o risco residual.

4.4.2.3 Recuperação de gestão de segurança controlesEsses controles incluem o seguinte:• Dar continuidade de apoio e desenvolver, testar, e manter a continuidade do plano de operações para fornecer para a retomada de negócios e assegurar a continuidade das operações durante emergências ou desastres.• Estabelecer uma capacidade de resposta a incidentes para se preparar para, reconhecer, relatar e responder ao incidente e retornar o sistema de TI para o estado operacional.

4.4.3 Controles de Segurança OperacionalPadrões de segurança da organização deve estabelecer um conjunto de controles e diretrizes para garantir que os procedimentos de segurança que regem o uso da organização ativos de TI e recursos sejam devidamente aplicadas e executadas em conformidade com os objetivos da organização e missão. Gestão desempenha um papel vital na supervisão da implementação de políticas e em assegurar o estabelecimento de adequados controles operacional.

Controles operacionais, implementadas de acordo com um conjunto de requisitos de base (por exemplo, controles técnicos) e boas práticas da indústria, são usados para corrigir deficiências operacionais que poderiam ser exercidas por potenciais ameaças de fontes. Para assegurar a coerência e uniformidade nas operações de segurança, passo-a-passo os procedimentos e métodos para a implementação de controles operacionais devem ser claramente definidos, documentados e mantidos. Esses controles operacionais incluem aqueles apresentados nas Seções 4.4.3.1 e 4.4.3.2 abaixo.

4.4.3.1 Controles preventivos OperacionaisControles operacionais preventivos são os seguintes:• Controle de acesso a dados de mídia e eliminação. (por exemplo, controle de acesso físico método, desmagnetização).• Limite de distribuição de dados externa. (por exemplo, o uso de rotulagem).• O software de controle de vírus.• Proteja instalação de computação. (por exemplo, guardam de segurança, procedimentos do site para os visitantes, sistema de identificação eletrônica, acesso biometria gestão, controla e distribuição de fechaduras e chaves, barreiras e cercas).• Proteger armários de cabeamento que hubs casa e cabos.• Fornecer capacidade de backup. (por exemplo, os procedimentos para regular de dados e backups do sistema, logs de arquivo que salvar todas as alterações de banco de dados para ser usado em vários cenários de recuperação).• Estabelecer procedimentos fora do local de armazenamento e segurança.• Proteja laptops, computadores pessoais (PC), estações de trabalho.• Proteger os ativos de TI de dano de fogo. (por exemplo, requisitos e procedimentos para o uso de extintores de incêndio, lonas, sistemas de sprinklers seca, sistema de supressão de fogo halon).• Fornecer fonte de energia de emergência. (por exemplo, os requisitos para breaks, geradores de energia on-site).• Controlar a umidade e a temperatura da instalação de computação. (por exemplo, a operação de condicionadores de ar, dispersão de calor).

4.4.3.2 Detecção de Controles OperacionaisControles de detecção operacionais incluem o seguinte:• Garantir a segurança física (por exemplo, o uso de detectores de movimento, circuito fechado de televisão, sensores de monitoramento e alarmes).• Garantir a segurança ambiental (por exemplo, o uso de detectores de fumaça e fogo, sensores e alarmes).

4.5 Análise Custo-BenefícioPara alocar os recursos e implementar controles custo-benefício, organizações, após a identificação de todos os controles possíveis e avaliar a sua viabilidade e eficácia, deverão realizar uma analise custo-benefício para cada controle proposto para determinar quais controles são necessários e adequados para as suas circunstâncias.

A análise custo-benefício pode ser qualitativa ou quantitativa. O seu objetivo é o de demonstrar que o custo de implementação dos controles pode ser justificado pela redução do nível de risco. Por exemplo, a organização não pode querer gastar US $ 1.000 em um controle para reduzir o risco de US $ 200.

Uma análise de custo-benefício para propostas de novos controles ou controles aprimorados abrange o seguinte:• Determinar o impacto da implementação dos controles novos ou aprimorados.• Determinar o impacto da não implementação dos controles novos ou aprimorados.• Estimar os custos da implementação. Estes podem incluir, mas não estão limitados a, o seguinte:- Aquisições de hardware e software.- Redução da eficácia operacional, se o desempenho do sistema ou a funcionalidade é reduzido para aumentar a segurança.- Custo da implementação de políticas e procedimentos adicionais.- Custo da contratação de pessoal adicional para implementar as políticas propostas, procedimentos ou serviços.- Custos de formação.- Os custos de manutenção.• Avaliar os custos de implementação e benefícios contra a criticidade do sistema e dados para determinar a importância para a organização de implementar os novos controles, dado os seus custos e impacto relativo.

A organização terá de avaliar os benefícios dos controles em termos de manter uma postura missão aceitáveis para a organização. Assim como existe um custo para implementar um controle necessário, há um custo para não implementá-lo. Ao relacionar o resultado da não implementação do controle da missão, as organizações podem determinar se é possível abrir mão de sua implementação.

Análise de Custo-Benefício Exemplo: sistema armazena e processa a informação X privacidade de missão crítica e sensível empregado, no entanto, a auditoria não foi habilitada para o sistema. Uma análise custo-benefício é conduzida para determinar se o recurso de auditoria deve ser habilitado para o Sistema X.

Itens (1) e (2) face ao impacto intangível (por exemplo, fatores de dissuasão) para a implementação ou não implementação do novo controle. Item (3) enumera os bens tangíveis (por exemplo, custo real).

(1) Impacto de permitir recurso de auditoria do sistema: A função de auditoria do sistema permite que o administrador de segurança do sistema para monitorar as atividades dos usuários do sistema, mas vai abrandar o desempenho do sistema e, portanto, afetam a produtividade do usuário. Também a implementação exigirá recursos adicionais, conforme descrito no Item 3.

(2) Impacto de não possibilitar recurso de auditoria do sistema: as atividades dos usuários do sistema e as violações não podem ser monitoradas e controladas, se a função de auditoria do sistema é desativada, e a segurança não pode ser maximizada para proteger os dados confidenciais da organização e missão.

(3) A estimativa de custos para habilitar o recurso de auditoria do sistema:

Custo para permitir auditoria do sistema característica sem custo, funcionalidade built-in.

$ 0

Pessoal adicional para realizar uma revisão de auditoria e arquivar, por ano.

$ XX,XXX

Formação. (por exemplo, sistema de configuração de auditoria geração de relatórios).

$ X,XXX

Add-on software de relatórios de auditoria. $ X,XXXAuditoria de manutenção de dados (por exemplo, o armazenamento, arquivamento), por ano.

$ X,XXX

Custos totais estimados. $ XX,XXX

Gestores da organização devem determinar o que constitui um nível aceitável de risco da missão. O impacto de um controle pode então ser avaliado, e o controle incluído ou excluído, após a organização determina uma série de níveis de risco viáveis. Este intervalo pode variar entre as organizações, no entanto, as seguintes regras para determinar o uso de novos controles:• Se o controle seria reduzir o risco mais do que o necessário, então, ver se uma alternativa menos dispendiosa existe. • Se o controle custaria mais do que a redução de risco disponível, em seguida, encontrar outra coisa. • Se o controle não reduz risco suficientemente, em seguida, procure mais controles ou um controle diferente. • Se o controle proporciona redução de riscos o suficiente e é custo-efetivo, em seguida, usá-lo.

Frequentemente, o custo de implementação de um controle é mais tangível do que o custo de não implementá-lo. Como resultado, a alta administração desempenha um papel fundamental nas decisões relativas à implementação de medidas de controle para proteger a missão organizacional.

4.6 RISCO RESIDUALAs organizações podem analisar a extensão da redução do risco gerado pelos controles novos ou aprimorados em termos de probabilidade de ameaça reduzida ou impacto, os dois parâmetros que definem o nível de risco mitigado com a missão organizacional.

Implementação de controles novos ou aperfeiçoados podem mitigar o risco:• A eliminação de algumas das vulnerabilidades do sistema (falhas e fraqueza), reduzindo assim o número de pares de fonte de ameaça/ possíveis vulnerabilidades. • Adição de um controle voltado para reduzir a capacidade e motivação de uma ameaça de fonte.

Por exemplo, um departamento determina que o custo para instalação e manutenção de complemento software de segurança para o PC autônomo que armazena seus arquivos sensíveis não é justificável, mas que os controles administrativos e físicos devem ser implementadas para SP Página 40 800-30 fazer acesso físico ao PC que mais difícil (por exemplo, armazenar o PC em uma sala trancada, com a chave mantida pelo gerente).

• reduzir a magnitude do impacto adverso (por exemplo, limitar a extensão de uma vulnerabilidade ou modificando a natureza da relação entre o sistema de TI e missão da organização).

A relação entre a execução e controle de risco residual é representada graficamente na Figura 4-4.

Figura 4-4. Implementação dos controles e riscos residuais.

O risco remanescente após a implementação de controles novos ou melhorados é o risco residual. Praticamente nenhum sistema está livre de riscos de TI, e nem todos os controles implementados pode eliminar o risco que se destinam a tratar ou reduzir o nível de risco a zero.

Como exigido pela OMB Circular A-130, a alta administração de uma organização ou a DAA, que é responsável por proteger ativos de TI da organização e da missão, deve autorizar (ou credenciar) o sistema de TI para começar ou continuar a funcionar. Esta autorização ou credenciamento deve ocorrer pelo menos a cada 3 anos ou sempre que grandes mudanças são feitas para o sistema de TI. A intenção deste processo é identificar os riscos que não são tratados completamente e para determinar se os controles adicionais são necessários para mitigar os riscos identificados no sistema de TI. Para as agências federais, depois que os controles adequados tenham sido postas em prática para os riscos identificados, o DAA vão assinar uma declaração aceitando qualquer risco residual e autoriza o funcionamento do novo sistema de TI ou a transformação contínua do sistema informático existente. Se o risco residual não tenha sido reduzido para um nível aceitável, o ciclo de gestão de risco deve ser repetido para identificar uma forma de reduzir o risco residual para um nível aceitável.

5. Análise e avaliação

Na maioria das organizações, a rede em si vai ser continuamente ampliada e atualizada, seus componentes alterados, e as suas aplicações de software substituído ou atualizado com as versões mais recentes. Além disso, mudança de pessoal ocorrerá e políticas de segurança tendem a mudar com o tempo. Estas mudanças significam que os riscos de novos superfície e riscos previamente mitigados pode açaí tornou uma preocupação. Assim, o processo de gestão de riscos está em curso e evolução.

Esta seção enfatiza as boas práticas e a necessidade de uma avaliação de risco em curso e a avaliação e os fatores que levarão a um programa bem sucedido de gestão de risco.

5.1 Boas práticas de segurança O processo de avaliação de risco é normalmente repetida pelo menos a cada três anospara as agências federais, como encomendados pela OMB Circular A-130. Contudo, a gestão de risco deve ser conduzido e integrado no SDLC para sistemas de TI, não porque é obrigado por lei ou regulamento, mas porque é uma boa prática e apoia os objectivos de negócio da organização ou missão.Deve haver um cronograma específico para a avaliação e mitigação de riscos da missão, mas o processo periodicamente realizada também deve ser suficientemente flexível para permitir alterações sempre que preciso, como grandes mudanças noambiente do sistema e processamento de TI devido a mudanças resultantes depolíticas e novas tecnologias.

5.2 Chaves para o sucessoUm programa de gerenciamento bem sucedido risco contará com compromisso (1) gestão de topo, (2) o apoio e participação da equipe de TI (ver Seção 2.3), (3) a competência da equipe de avaliação de risco, que deve ter a competência para aplicar a metodologia de avaliação de risco para um determinado site e do sistema, identificar os riscos da missão, e fornecer o custo-efetivo salvaguardas que atendem às necessidades da organização; (4) a sensibilização e a cooperação dos membros da comunidade de usuários, que devem seguir os procedimentos e cumprir com os controles implementados para garantir a missão da sua organização, e (5) uma avaliação contínua e avaliação dos riscos relacionados a TI de missão.

APENDICE A: PERGUNTAS DE AMOSTRA PARA ENTREVISTA

As perguntas da entrevista devem ser adaptadas com base em que o sistema de TI avaliada é no SDLC. Exemplos de perguntas a serem feitas durante as entrevistas com o pessoal do site para obter uma compreensão das características operacionais de uma organização podem incluir o seguinte:• Quem são os usuários válidos? • Qual é a missão da organização do usuário? • O que é o objetivo do sistema em relação à missão? • Qual a importância do sistema para a missão da organização do usuário? • Qual é o requisito do sistema disponibilidade? • Que informação (tanto de entrada e saída) é exigida pela organização? • Que informação é gerada por, consumido por processados em armazenada e recuperada pelo sistema? • Qual a importância da informação para a missão da organização do usuário? • Quais são os caminhos do fluxo de informações?• Que tipos de informação são processados e armazenados no sistema (por exemplo, financeira, pessoal, pesquisa e desenvolvimento, assistência médica, comando e controle)? • Qual é a sensibilidade (ou classificação) nível da informação? • Que informações tratadas por ou sobre o sistema não deve ser divulgado e para quem? • Onde, especificamente, é a informação processada e armazenada? • Quais são os tipos de armazenamento de informação? • Qual é o impacto potencial sobre a organização, se as informações são divulgadas a pessoas não autorizadas? • Quais são os requisitos para a disponibilidade de informações e integridade? • Qual é o efeito sobre a missão da organização, se o sistema ou as informações não é confiável? • Quanto tempo ocioso do sistema a organização pode tolerar? Como é que este tempo de inatividade comparar com o tempo de reparo / recuperação média? O outro tratamento ou comunicações opções podem acessar o usuário? • Será que um sistema de segurança ou mau funcionamento ou indisponibilidade

resultado em ferimento ou morte?

APENDICE B: ESBOÇO DA AMOSTRA DE RISCO RELATÓRIO DE AVALIAÇÃO

RESUMOI. Introdução • Objetivo. • Âmbito da avaliação de riscos.

Descrever os componentes do sistema, elementos, usuários, locais de campo (se houver), e quaisquer outros detalhes sobre o sistema a ser considerado na avaliação. Desfazer edições

II. Método de Avaliação de RiscoDescrever brevemente o método utilizado para realizar a avaliação de risco, tais como:• Os participantes. (por exemplo, os membros da equipe de avaliação de risco). • A técnica usada para coletar informações. (por exemplo, o uso de ferramentas, questionários). • O desenvolvimento e a descrição da escala de risco. (por exemplo, uma 3 x 3, 4 x 4, ou 5 x 5 matriz nível de risco). Desfazer edições

III. Caracterização do SistemaCaracterizar o sistema, incluindo hardware (servidor, roteador, switch), software (por exemplo, sistema de aplicação, operação protocolo), interfaces de sistema (por exemplo, link de comunicação), dados e usuários. Fornecer conectividade de entrada diagrama ou fluxograma de saída do sistema e para delinear o escopo deste esforço de avaliação de risco.

IV. Declaração de ameaçaCompilar e listar as potenciais ameaças de fontes e ações de ameaças associadas aplicáveis ao sistema de avaliação.

V. Resultados da Avaliação de Risco.Listar as observações (vulnerabilidade / ameaça par). Cada observação deve incluir:• Número de Observação e uma breve descrição de observação. (por exemplo, Observação 1: sistema de senhas de usuário pode ser adivinhado ou quebrado). • A discussão sobre a ameaça de fonte e um par de vulnerabilidades. • Identificação de controles de segurança existentes atenuantes. • Probabilidade de discussão e avaliação. (por exemplo, a probabilidade, Alto Médio ou Baixo). • discussão Análise de impacto e avaliação. (por exemplo, impacto, Alto Médio ou Baixo). • Classificação de Risco com base na matriz de risco de nível. (por exemplo, Médio, Alto ou nível de risco baixo). • Recomendado controles ou opções alternativas para reduzir o risco.

VI. RESUMOTotalizar o número de observações. Resumir as observações, os níveis de risco associados, as recomendações, e os comentários em um formato de tabela para facilitar a implementação de controles recomendados durante o processo de mitigação de riscos.

APENDICE C: TABELA

APENDICE D: SIGLAS

AES: padrão de criptografia avançado. CSA: segurança informática ato. DAA: designado aprovar autoridade. DAC: controle de acesso discricionário. DES: Data Encryption Standard. FedCIRC: federal computador do centro de resposta a incidentes. FTP: File Transfer Protocol. ID: identificador. IPSEC: protocolo de segurança da internet. ISSO: informação oficial de segurança do sistema. TI: tecnologia da informação. ITL: laboratório de tecnologia da informação MAC: controle de acesso obrigatório. NIPC: centro nacional de proteção de infraestrutura. NIST: Instituto Nacional de Padrões e Tecnologia. OIG: escritório do inspetor-geral. OMB: Escritório de Administração e Orçamento. PC: computador pessoal. SDLC: sistema de ciclo de vida do desenvolvimento. SP: publicação especial. ST & E: teste de segurança e avaliação.