Anda di halaman 1dari 34

NIST 1. Introduo Cada organizao tem uma misso.

Nesta era digital, como as organizaes utilizam a tecnologia da informao automatizada (TI) para processar suas informaes para um melhor suporte de suas misses, gerenciamento de risco desempenha um papel crtico na proteo dos ativos de informao da organizao, e, portanto, sua misso, de TI relacionados risco. Um processo de gesto de riscos um componente importante de um programa de segurana de TI bem-sucedido. O principal objetivo de uma organizao do processo de gerenciamento de risco deve ser o de proteger a organizao e sua capacidade de desempenhar a sua misso, no apenas os seus ativos de TI. Portanto, o processo de gesto de risco no deve ser tratado principalmente como uma funo tcnica realizada pelos peritos de TI que atuam e gerir o sistema de TI, mas como uma funo de gesto essencial para a organizao. 1.1 no somos importantes 1.2 Propsito Risco o impacto lquido negativo do exerccio de uma vulnerabilidade, considerando tanto a probabilidade e o impacto de ocorrncia. A gesto de riscos o processo de identificao de riscos, avaliao de riscos, e tomar medidas para reduzir o risco a um nvel aceitvel. Este guia fornece uma base para o desenvolvimento de um programa eficaz de gesto de risco, contendo as definies e as orientaes prticas necessrias para avaliar e mitigar riscos identificados dentro de sistemas de TI. O objetivo final ajudar as organizaes a gerenciar melhor os riscos relacionados a TI de misso. Alm disso, este guia fornece informaes sobre a seleo de controles de custo eficazes de segurana. Esses controles podem ser utilizados para reduzir o risco para a melhor proteo de informaes de misso crtica e os sistemas de TI que processam, armazenam e transportam essa informao. As organizaes podem optar por expandir ou abreviar os processos abrangentes e passos sugeridos neste guia e adequ-los ao seu meio ambiente na gesto de riscos relacionados a TI de misso. 1.3 Objetivo O objetivo de realizar gerenciamento de risco o de permitir a organizao a cumprir sua misso (1) atravs de uma melhor segurana dos sistemas de TI que armazenam, processam ou transmitem informao organizacional; (2), permitindo que a administrao faa bem informada gesto de risco decises para justificar as despesas que fazem parte de um oramento de TI, e (3), auxiliando a gesto em que autoriza (ou credenciadora) os sistemas de TI com base na documentao resultante do desempenho da gesto de risco. 1.4 no somos importantes 1.5 no somos importantes 1.6 ESTRUTURAS GUIAS As demais sees deste guia de discutir o seguinte: Seo 2 fornece uma viso geral da gesto de risco, como ele se encaixa no ciclo de vida do sistema de desenvolvimento (SDLC), e os papis dos indivduos que suportam e utilizar este processo. Seo 3 descreve a metodologia de avaliao de risco e os nove principais passos na conduo de uma avaliao de risco de um sistema de TI. Seo 4 descreve o processo de mitigao de risco, incluindo opes de mitigao de risco e

estratgia, a abordagem para implementao de controle, categorias de controle, anlise custobenefcio e risco residual. A Seo 5 discute boas prticas e a necessidade de uma avaliao de risco em curso e a avaliao e os fatores que levaro a um programa bem sucedido de gesto de risco. Este guia tambm contm seis apndices. O Apndice A fornece perguntas da entrevista da amostra. Apndice B fornece um esboo de amostra para uso em documentar os resultados da avaliao de risco. O Apndice C contm uma tabela de exemplo para o plano de implementao de salvaguarda. Apndice D fornece uma lista de os acrnimos utilizados no presente documento. O Apndice E contm um glossrio de termos usados com frequncia neste guia. Apndice F lista de referncias. 2. VISO GERAL DE GESTO 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 gesto de risco est ligado ao processo de autorizao do sistema (ou credibilidade). 2.1 A IMPORTNCIA DA GESTO DE RISCOS Gesto de risco engloba trs processos: avaliao dos riscos, mitigao de riscos, avaliao e avaliao. Seo 3 deste guia descreve o processo de avaliao de risco, que inclui a identificao e avaliao de riscos e impactos de risco, e recomendao de medidas de reduo de risco. A Seo 4 descreve mitigao de riscos, que se refere priorizao, implementao e manuteno das adequadas medidas de reduo de risco recomendados pelo processo de avaliao de risco. A Seo 5 discute o processo de avaliao contnua e chaves para a implementao de um programa de gerenciamento de risco bem-sucedido. O oficial autoriza a DAA ou sistema responsvel por determinar se o risco remanescente em um nvel aceitvel ou se os controles de segurana adicionais devem ser implementadas para reduzir ainda mais ou eliminar o risco residual antes de autorizar (ou credenciadora) o sistema de TI para a operao. A gesto de riscos o processo que permite que gerentes de TI a equilibrar os custos operacionais e econmicos das medidas de proteo e obter ganhos de capacidade de misso por proteger os sistemas de TI e dados que suportam misses das suas organizaes. Este processo no exclusivo para o ambiente de TI; na verdade, permeia a tomada de decises em todas as reas de nossas vidas dirias. Tomemos o caso da segurana em casa, por exemplo. Muitas pessoas decidem ter sistemas de segurana home instalado e pagar uma taxa mensal a um prestador de servios para que esses sistemas monitorados para melhor proteo dos seus bens. Presumivelmente, os proprietrios ter pesado o custo de instalao do sistema e monitoramento contra o valor dos bens da sua casa e segurana da sua famlia, um fundamental "misso" a necessidade. O chefe de uma unidade organizacional deve assegurar que a organizao tem os recursos necessrios para cumprir sua misso. Este proprietrio de misso deve determinar as capacidades de segurana que seus sistemas de TI devem ter para proporcionar o nvel desejado de apoio misso em face das ameaas do mundo real. A maioria das organizaes tm oramentos apertados para segurana de TI, portanto, gastos com TI de segurana devem ser revisados tanto quanto outras decises de gesto. A bem estruturada metodologia de gerenciamento de risco, quando utilizada de forma eficaz, pode ajudar a administrao a identificar os controles apropriados para fornecer capacidades de misso essenciais de segurana. 2.2 A Integrao da Gesto de Risco no SDLC Minimizar o impacto negativo sobre a organizao e necessidade de base slida na tomada de

deciso so as organizaes fundamentais razes implementar um processo de gerenciamento de risco de seus sistemas de TI. Gesto eficaz dos riscos deve ser totalmente integrada ao SDLC. SDLC Um sistema informtico tem cinco fases: desenvolvimento de iniciao, ou aquisio, implantao, operao ou manuteno, e disposio. Em alguns casos, um sistema informtico pode ocupar vrias destas fases ao mesmo tempo. No entanto, a metodologia de gerenciamento de risco o mesmo, independentemente da fase SDLC para que a avaliao esteja sendo realizada. A gesto de riscos um processo iterativo que pode ser realizada durante cada fase principal do SDLC. Tabela 2-1 descreve as caractersticas de cada fase SDLC e indica como gesto de risco pode ser realizada em suporte de cada fase. Tabela 2.1 Integrao de Gesto de Risco para o SDLC Fases SDLC Fase 1-Iniciao Caractersticas de fase A necessidade de um sistema de TI expressa e o propsito e o alcance do sistema de TI esto documentados Apoio de Gerenciamento de Riscos riscos identificados so utilizados para apoiar o desenvolvimento dos requisitos do sistema, incluindo os requisitos de segurana, e um conceito de segurana de operaes (estratgia) .

Fase 2. Desenvolvimento ou Aquisio

O sistema de TI foi Os riscos identificados desenvolvido, comprado, durante esta fase pode ser programados, desenvolvidos ou usada para apoiar as anlises no construdo. de segurana do sistema de TI que podem levar a trocas de arquitetura e design durante o desenvolvimento do sistema As caractersticas de segurana do sistema devem ser configuradas, habilitado, testado e verificado. O processo de gesto do risco sustenta a avaliao da implementao do sistema em relao aos requisitos e dentro de seu ambiente operacional modelado. As decises sobre os riscos identificados devem ser feitas antes da operao do sistema As atividades de gesto de risco so realizadas para reautorizao sistema peridico (ou recredenciamento) ou sempre que grandes mudanas so feitas para um sistema de TI no seu ambiente de produo operacional, (por exemplo, interfaces novo sistema). As atividades de gesto de risco so realizadas para os componentes do sistema que sero eliminados ou substitudos para garantir que o hardware e software esto

Fase 3-Implementao

Fase 4-Operao ou Manuteno

O sistema executa suas funes. Normalmente, o sistema est sendo modificado em uma base contnua atravs da adio de hardware e software e por mudanas nos processos organizacionais, polticas e procedimentos.

Fase 5-Eliminao

Esta fase pode envolver a disposio de informao, hardware e software. As atividades podem incluir movimento, arquivamento, descarte, ou destruir

informaes e limpeza de hardware e software.

devidamente eliminados, que os dados residuais so devidamente tratados, e que a migrao do sistema realizada de uma maneira segura e sistemtica.

2.3 Principais Funes A gesto de riscos uma responsabilidade de gesto. Esta seo descreve as principais funes do pessoal que deve apoiar e participar no processo de gesto de risco. Alta Administrao: A gerncia snior, de acordo com o padro de cuidados devidos e responsabilidade final para o cumprimento da misso, deve assegurar que os recursos necessrios sejam efetivamente aplicados para desenvolver as capacidades necessrias para cumprir a misso. Eles tambm devem avaliar e incorporar os resultados da atividade de avaliao de risco no processo decisrio. Um programa de gesto de riscos que avalia e reduz os riscos relacionados a TI de misso requer o apoio e envolvimento da alta gerncia. Chief Information Officer (CIO). O CIO responsvel pelo planejamento da agncia de TI, oramento e desempenho, incluindo os seus componentes de segurana da informao. As decises tomadas nestas reas devem ser baseadas em um programa eficaz de gesto de risco. Os proprietrios do Sistema e Informao: Os proprietrios do sistema de informao so responsveis por garantir que os controles apropriados esto no local para abordar a integridade, confidencialidade e disponibilidade dos sistemas de TI e dados que possuem. Normalmente, os proprietrios de sistemas e informaes so responsveis por alteraes em seus sistemas de TI. Assim, eles normalmente tm de aprovar e assinar sobre alteraes em seus sistemas de TI (por exemplo, melhorias no sistema, grandes mudanas no software e hardware). Os proprietrios do sistema e informaes devem, portanto, compreender o seu papel no processo de gesto de risco e apoiar plenamente este processo. Gerentes de Negcios e Funcionais: Os gerentes responsveis por operaes de negcios e de TI processo de aquisio deve ter um papel ativo no processo de gesto de risco. Esses gerentes so os indivduos com a autoridade e responsabilidade para tomar as decises trade off essenciais para o cumprimento da misso. O seu envolvimento no processo de gesto de risco permite a realizao de segurana adequada para os sistemas de TI, que, se administradas corretamente, ir proporcionar a eficcia da misso com um gasto mnimo de recursos. ISSO: gerentes de TI do programa de segurana e oficiais de segurana informtica responsvel por programas de suas organizaes de segurana, incluindo a gesto de risco. Portanto, eles desempenham um papel de liderana na introduo de uma metodologia apropriada estruturado para ajudar a identificar, avaliar e minimizar os riscos para os sistemas de TI que suportam as suas misses organizacionais. Nisso atuam como consultores principais de apoio da alta administrao para assegurar que essa atividade ocorre em uma base contnua. Os profissionais de segurana de TI: profissionais de segurana de TI (por exemplo, redes, sistemas, aplicativos, administradores e especialistas em banco de dados; computador; analistas de segurana, consultores de segurana) so responsveis pela aplicao adequada dos requisitos de segurana em seus sistemas de TI. Como as mudanas ocorrem no ambiente do sistema de TI existentes (por exemplo, a expanso da conectividade de rede, alteraes na infraestrutura existente e as polticas organizacionais, a introduo de novas tecnologias), os profissionais de segurana de TI deve apoiar ou utilizar o processo de gesto de riscos para identificar e avaliar novas potencialidades riscos e implementar controles de segurana nova, conforme necessrio para proteger seus sistemas de TI. Conscientizao de Segurana Trainers (Profissionais de segurana / Objeto): O pessoal da organizao so os utilizadores dos sistemas de TI. O uso dos sistemas de TI e dados de acordo com as polticas de uma organizao, diretrizes e regras de comportamento fundamental para mitigar os riscos e proteger a organizao de recursos de TI. Para minimizar os riscos para os sistemas de TI, essencial que os usurios do sistema e aplicao seja fornecida com segurana treinamento de conscientizao. Portanto, a segurana de TI ou de segurana formadores /

profissionais no assunto deve entender o processo de gesto de risco, para que possam desenvolver materiais didticos adequados e incorporar a avaliao de riscos em programas de treinamento para educar os usurios finais. 3. AVALIAO DE RISCO A avaliao dos riscos o primeiro processo na metodologia de gerenciamento de risco. Organizaes utilizam avaliao do risco para determinar a extenso da ameaa potencial e o risco associado com um sistema de TI ao longo do seu SDLC. A sada deste processo ajuda a identificar os controles apropriados para reduzir ou eliminar o risco durante o processo de mitigao de risco, como discutido na Seo 4. O risco uma funo da probabilidade de um dado. Ameaa de fonte est exercendo uma vulnerabilidade particular potencial, e o impacto resultante desse acontecimento adverso sobre a organizao. Para determinar a probabilidade de um evento futuro adverso, ameaas 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 ameaa de exerccio de uma vulnerabilidade. O nvel de impacto governado pelos impactos de misso 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 avaliao de risco abrange nove etapas principais, que so descritas nas seces 3.1 a 3,9. Etapa 1 - Caracterizao do sistema (Seo 3.1) Passo 2 - Identificao de Ameaas (Seo 3.2) Etapa 3 - Identificao de Vulnerabilidade (Seo 3.3) Passo 4 - Anlise de controle (Seo 3.4) Passo 5 - Determinao de verossimilhana (Seo 3.5) Passo 6 - Anlise de Impacto (Seo 3.6) Etapa 7 - Determinao de riscos (Seo 3.7) Passo 8 - Recomendaes de Controle (Seo 3.8) Passo 9 - Documentao de Resultados (Seo 3.9). Passos 2, 3, 4 e 6 pode ser conduzida em paralelo aps o Passo 1 foi concludo. Figura 3-1 descreve estes passos e as entradas e sadas de cada etapa. Entrada Hardware Software Interfaces do Sistema Dados e informaes Pessoas A misso do Sistema Atividades da Avaliao de Risco Passo 1. Caracterizao do Sistema Sada Limites do sistema: Funes do Sistema Criticidade do Sistema e Dados Sensibilidade do Sistema e Dados Declarao de ameaa

Histria de ataque do sistema Passo 2. Identificao de Dados de agncias de ameaas. inteligncia, NIPC, OIG, FedCIRC, meios de comunicao. Relatrios de avaliaes de risco anteriores Passo 3. Identificao da vulnerabilidade

Lista de possveis vulnerabilidades.

Quaisquer comentrios auditoria Requisitos de Segurana Os resultados de testes de segurana Os controles atuais Os controles planejados Ameaa fonte de motivao. Capacidade de ameaas. Natureza da vulnerabilidade. Os controles Dados atuais.. Passo 4. Controle de Anlise. Passo 5. Determinao de probabilidade. Lista dos controles atuais e planejados. Classificao probabilidade.

anlise de impacto da Misso. avaliao da criticidade de Ativos. criticidade de dados sensibilidade de Dados. Probabilidade de explorao ameaa. Magnitude do impacto. Adequao dos controles

Passo 6. Anlise do Impacto. Perda de Integridade. Perda de Disponibilidade. Perda de Confidencialidade. Passo 7. Determinao do Risco

Avaliao do Impacto.

Riscos e nveis de risco associados.

Passo 8. Recomendaes de controle Passo 9. Documentao resultados. Figura 3-1. Fluxograma Metodologia de Avaliao do Risco

Controles recomendados Relatrio de Avaliao do Risco

3.1 PASSO 1: caracterizao do sistema. Ao avaliar os riscos para um sistema informtico, o primeiro passo a definir o mbito do esforo. Nesta etapa, os limites do sistema de TI so identificados, juntamente com os recursos e as informaes que compem o sistema. Caracterizando um sistema de TI estabelece o escopo do esforo de avaliao de risco, delineia a autorizao operacional (ou credibilidade) limites, e fornece informaes (por exemplo, pessoal, hardware, diviso de software, a conectividade do sistema, e responsvel ou de apoio) essenciais para definir o risco. Seo 3.1.1 descreve as informaes relacionadas ao sistema usado para caracterizar um sistema de TI e seu ambiente operacional. Seco 3.1.2 sugere as tcnicas de recolha de informaes que podem ser usados para solicitar informao relevante para o ambiente de TI sistema de processamento. A metodologia descrita no presente documento pode ser aplicada s avaliaes de simples ou mltiplas, sistemas inter-relacionados. Neste ltimo caso, importante que o domnio de interesse e todas as interfaces e dependncias de ser bem definido antes da aplicao da metodologia. 3.1.1 Informaes relacionadas ao sistema. Identificao de risco para um sistema de TI requer um profundo conhecimento do ambiente de processamento do sistema. A pessoa ou pessoas que realizam a avaliao de risco deve primeira reunir informaes relacionadas ao sistema, que geralmente classificado como segue: Hardware Software Interfaces de sistema (por exemplo, a conectividade interna e externa). Dados e informaes.

Pessoas que apoiam e usar o sistema de TI. misso do sistema (por exemplo, os processos realizados pelo sistema IT). criticidade sistema e os dados (por exemplo, o valor do sistema ou importncia para uma organizao). Sistema de sensibilidade e de dados. Informao adicional relacionado com o ambiente operacional do sistema informtico e os seus dados incluem, mas no est limitado a, o seguinte: Os requisitos funcionais do sistema de TI. Os usurios do sistema (por exemplo, usurios do sistema que fornecem apoio tcnico ao sistema de TI, os usurios de aplicativos que usam o sistema de TI para executar funes de negcios). Sistema polticas de segurana que regem o sistema de TI (polticas organizacionais, requisitos federais, as leis, as prticas da indstria). arquitetura de segurana do sistema. topologia da rede atual. (por exemplo, um diagrama de rede). Proteo armazenamento de informao que protege a disponibilidade do sistema e dados, integridade e confidencialidade. Fluxo de informaes relativas ao sistema de TI. (por exemplo, as interfaces do sistema, sistema de entrada e sada de fluxograma). Controles de tcnicas utilizadas para o sistema de TI. (por exemplo, built-in ou add-on produto de segurana que oferece suporte identificao e autenticao, controle de acesso discricionrio ou obrigatrio, auditoria, proteo da informao residual, os mtodos de criptografia). Gesto controles usados para o sistema de TI. (por exemplo, regras de comportamento, a segurana planejamento). Controles operacionais utilizados para o sistema de TI. (por exemplo, o pessoal de segurana, backup, contingncia, e retomada e as operaes de recuperao, manuteno do sistema; armazenamento off-site, criao de conta de usurio e os procedimentos de excluso; controles de segregao de funes do usurio, tais como acesso de usurio privilegiado versus acesso de usurio padro) ambiente de segurana fsica do sistema de TI. (por exemplo, segurana das instalaes, as polticas de centro de dados). Segurana Ambiental, implementado para o ambiente de TI sistema de processamento. (por exemplo, os controles de unidade, a gua, a energia, a poluio, temperatura, e produtos qumicos). Para um sistema que est na fase de iniciao ou de design, a informao do sistema pode ser derivado a partir do documento de concepo ou requisitos. Para um sistema de TI em desenvolvimento, necessrio definir regras de segurana fundamentais e atributos planejados para o futuro sistema de TI. Documento de projeto de sistemas e do plano de segurana do sistema pode fornecer informaes teis sobre a segurana de um sistema de TI que est em desenvolvimento. Para um sistema operacional de TI, os dados so coletados sobre o sistema de TI no seu ambiente de produo, incluindo dados sobre a configurao do sistema, conectividade e procedimentos documentados e no documentados e prticas. Portanto, a descrio do sistema pode ser baseada na segurana proporcionada pela infraestrutura subjacente ou em planos de segurana futuros para o sistema de TI. 3.1.2 Coleta de informaes tcnicas. Qualquer uma, ou uma combinao, das seguintes tcnicas podem ser usadas na coleta de informaes relevantes para o sistema de TI dentro de sua fronteira operacional: Questionrio: Para a coleta de informaes relevantes, o pessoal de avaliao de risco pode desenvolver um questionrio sobre os controles gerenciais e operacionais previstas ou usadas para

o sistema de TI. Este questionrio dever ser distribudo aos aplicveis a pessoal tcnico e no tcnicos que esto projetando ou apoiar o sistema de TI. O questionrio tambm pode ser usado durante as visitas in loco e entrevistas. No local entrevistas. Entrevistas com o suporte de TI e gesto de pessoal do sistema pode permitir que o pessoal de avaliao de risco para coletar informaes teis sobre o sistema de TI (por exemplo, como o sistema operado e gerenciado). Visitas in loco tambm permitem que avaliao de risco pessoal para observar e coletar informaes sobre a segurana fsica, ambiental e operacional do sistema de TI. O Apndice A contm exemplos de perguntas feitas durante entrevista com o pessoal do site para obter uma melhor compreenso das caractersticas operacionais de uma organizao. Para os sistemas ainda em fase de projeto, visita in loco seria cara a cara de coleta de dados exerccios e poderia proporcionar a oportunidade de avaliar o ambiente fsico em que o sistema ir operar. Reviso de Documentos. Documentos de poltica (por exemplo, a documentao legislativa, as diretivas), documentao do sistema (por exemplo, sistema de guia do usurio, manual do sistema administrativo, o projeto do sistema e documento de requisitos, documento de aquisio), e de segurana relacionadas com a documentao (por exemplo, relatrio de auditoria anterior, relatrio de avaliao de risco, resultados do sistema de teste, plano de sistema de segurana, polticas de segurana) pode fornecer boas informaes sobre os controles de segurana utilizados por e planejadas para o sistema de TI. Anlise de uma organizao misso impacto ou avaliao importncia dos ativos fornece informaes a respeito do sistema e dados criticidade e sensibilidade. Uso de ferramenta de verificao automtica. Proativos mtodos tcnicos podem ser usados para coletar informaes do sistema de forma eficiente. Por exemplo, uma ferramenta de mapeamento de rede pode identificar os servios que so executados em um grande grupo de hosts e fornecer uma maneira rpida de criar perfis individuais do alvo sistemas de TI. O recolhimento de informao pode ser realizado durante o processo de avaliao de risco, a partir do Passo 1 (Caracterizao System) no Passo 9 (Documentao Resultados). Sada da Etapa 1 - Caracterizao do sistema de TI avaliada, uma boa imagem do ambiente do sistema de TI, e delimitao de fronteira do sistema. 3.2 PASSO 2: identificao de ameaas Uma ameaa o potencial para um determinado ameaa-source para exercer com sucesso uma vulnerabilidade particular. A vulnerabilidade uma fraqueza que pode ser acionado acidentalmente ou intencionalmente explorado. Uma ameaa fonte no apresenta um risco quando no h vulnerabilidade que pode ser exercido. Para determinar a probabilidade de uma ameaa (Seo 3.5), deve-se considerar ameaa fontes, vulnerabilidades potenciais (seo 3.3), e controles existentes (Seo 3.4). Ameaa: O potencial de uma fonte de ameaa ao exerccio (gatilho acidentalmente ou intencionalmente explorar) uma vulnerabilidade especfica. 3.2.1 Identificao da fonte de ameaa O objetivo desta etapa identificar as potenciais ameaas de fontes e compilar uma lista de ameaas declarao potenciais ameaas de fontes que so aplicveis ao sistema de TI a ser avaliada. Fonte de Ameaa: qualquer inteno ou mtodo voltado para a explorao de uma vulnerabilidade que pode se acidentalmente ou ocasional. Uma fonte de ameaa definida como qualquer circunstncia ou evento com potencial para causar danos a um sistema de TI. Uma fonte de ameaa comum pode ser natural, humana ou ambiental.

Na avaliao de fontes de ameaa, importante considerar todo o potencial da fonte de ameaa que possam causar danos a um sistema de TI e seu ambiente de processamento. Por exemplo, embora a declarao de ameaa para um sistema de TI localizada em um deserto no possa incluir "inundao natural" por causa da baixa probabilidade de tal de ocorrncia, ameaas ambientais, tais como ruptura de tubo que podendo rapidamente inundar uma sala de informtica e causar danos uma organizao de TI bens e recursos. Os seres humanos podem ser fontes de ameaa por meio de atos intencionais, como ataques deliberados por pessoas mal-intencionados ou funcionrios descontentes, ou atos intencionais, como negligncia e erros. Um ataque deliberado pode ser uma tentativa mal-intencionada para obter acesso no autorizado a um sistema de TI (por exemplo, atravs de adivinhao 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 propsito, tentativa de burlar a segurana do sistema. Um exemplo deste ltimo tipo de ataque deliberado de escrita um programador de um programa cavalo de Tria para contornar a segurana do sistema, a fim de "fazer o trabalho. Fontes de ameaa Comum -ameaas de cheias naturais, terremotos, furaces, deslizamentos de terra, avalanches, tempestades eltricas, e outros eventos. -Ameaas de Eventos do Homem que, ou so ativados por, ou causados por seres humanos, tais como atos intencionais (entrada inadvertida de dados) ou aes deliberadas (ataques baseados na rede, software malicioso de upload, acesso no autorizado a informaes confidenciais). -ameaas de longo prazo ambiental falta de energia, poluio, produtos qumicos, vazamento de lquido. 3.2.2 Motivao e Aes de ameaas. Motivao e os recursos para a realizao de um ataque fazer os seres humana potencialmente perigosa ameaa fontes. Tabela 3-1 apresenta uma viso geral de muitos dos atuais ameaas humanas comuns, suas possveis motivaes e os mtodos ou aes ameaa pelo qual eles poderiam realizar um ataque. Esta informao ser til para organizaes que estudam os seus ambientes de ameaas humanas e personalizar as suas declaraes de ameaas humanas. Alm disso, revises da histria do sistema breakins, relatrios de violao de segurana, relatrios de incidentes; e entrevistas com os administradores de sistemas, help desk pessoal, e comunidade de usurios durante a coleta de informaes vai ajudar a identificar humana ameaa de fontes que tm o potencial de causar danos de TI sistema e os seus dados e que pode ser uma preocupao onde existe uma vulnerabilidade. Tabela 3-1 Ameaas Humana: Ameaa-Source, Motivao e Aes de ameaas. Origem da ameaa Motivao Aes da ameaa Hacker, cracker Desafio, Ego e Rebelio. Hacking Engenharia Social Sistema de intruso, arrombamentos. Acesso no autorizado ao sistema Computador criminoso Destruio de informao, O crime informtico. (por Divulgao de informaes exemplo, ciber perseguio). ilegais, Ganho monetrio, ato fraudulento (por Alterao no autorizada de exemplo, a repetio, a dados. representao, a intercepo). Informao suborno Spoofing Sistema de intruso.

Terrorismo

Chantagem, Destruio, Explorao, Vingana.

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

Vantagem competitiva, A espionagem econmica.

Insiders (mal treinados, descontente, malicioso, negligncia, desonesto, ou funcionrios demitidos).

Curiosidade, Ego, Inteligncia, Ganho monetrio, Vingana, Erros involuntrios e omisses (por exemplo, os dados de entrada de erro, erro de programao) .

Bomba / Terrorismo A guerra de informao Sistema de ataque (por exemplo, negao de servio distribuda). Sistema de penetrao Sistema de adulterao A explorao econmica. O roubo de informaes. Invaso da privacidade pessoal. Engenharia Social Sistema de penetrao Acesso no autorizado ao sistema (acesso a informao classificada, de propriedade e / ou informao classificada, de propriedade e / ou tecnologia relacionada). Assalto a um empregado Chantagem Navegao de informaes proprietrias abuso do computador Fraude e roubo Informao suborno Entrada de dados falsificados, corrompidos. Intercepo Cdigo malicioso. (por exemplo, vrus, bomba lgica cavalo de Tria). Venda de informaes pessoais Os erros do sistema Sistema de intruso Sistema de sabotagem Acesso no autorizado ao sistema

Uma estimativa da motivao, recursos e capacidades que podem ser necessrias para levar a cabo um ataque bem sucedido deve ser desenvolvida aps o potencial de ameaa-fontes tm sido identificado, a fim de determinar a probabilidade de uma ameaa de exercer um sistema de vulnerabilidade, tal como descrito na seo 3.5. A declarao de ameaa, ou a lista de potenciais ameaas de fontes, deve ser adaptada para a organizao individual e seu ambiente de processamento (por exemplo, hbitos de computao do usurio final). Em geral, informao sobre as ameaas naturais (por exemplo, inundaes, terremotos, tempestades) devem estar prontamente disponveis. Ameaas conhecidas foram identificadas por muitos governos e organizaes do setor privado. Ferramentas de deteco de intruso tambm esto se tornando mais prevalente, e organizaes governamentais e da indstria continuamente coletar dados sobre eventos de segurana, melhorando assim a capacidade de avaliar realisticamente ameaas. Fontes de informao incluem, mas no esto limitados a, o seguinte:

Agncias de Inteligncia (por exemplo, o Federal Bureau of Investigation Centro Nacional de Infraestrutura de Proteo). Computer Incident Response Center Federal (FedCIRC) Os meios de comunicao de massa, particularmente baseados na Web, recursos, tais como SecurityFocus.com, SecurityWatch.com, SecurityPortal.com e SANS.org. Sada de Passo 2 - A declarao de ameaa com uma lista de ameaas de fontes que possam explorar as vulnerabilidades do sistema. 3.3 PASSO 3: identificao da vulnerabilidade. A anlise da ameaa de um sistema de TI deve incluir uma anlise 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 ameaas de fontes. Vulnerabilidade: Uma falha ou fraqueza nos procedimentos de segurana do sistema, projeto, implementao ou controles internos que poderiam ser exercidas (acidentalmente ou intencionalmente provocado explorados) e resultar em uma violao de segurana ou uma violao da poltica de segurana do sistema. Tabela 3-2 apresenta exemplos de pares de ameaas de vulnerabilidades. Vulnerabilidade Origem da ameaa Aes da ameaa Identificadores empregados Funcionrios demitidos. Discar para a rede da empresa encerrado do sistema (ID) no e acessar os dados da so removidos do sistema. empresa de propriedade Firewall da empresa permite Os usurios no autorizados Usando telnet ao servidor XYZ telnet de entrada, e ID de (por exemplo, hackers, e navegar arquivos do sistema convidado est habilitada no funcionrios demitidos, com a identificao do servidor XYZ. criminosos da informtica, convidado terroristas). O fornecedor identificou falhas Os usurios no autorizados Obteno de acesso no no design de segurana do (por exemplo, hackers, autorizado a arquivos sistema, no entanto, novos funcionrios insatisfeitos, confidenciais do sistema com patches no tenham sido criminosos da informtica, base em vulnerabilidades do aplicados ao sistema. terroristas). sistema conhecidos. Data Center usa asperso de Fogo, pessoas negligentes. Asperso de gua que est gua para suprimir o fogo; sendo ativado no centro de lonas para proteger hardware dados e equipamento de danos da gua no esto no lugar. Mtodos recomendados para a identificao de vulnerabilidades do sistema so o uso de fontes de vulnerabilidade, o desempenho dos testes de segurana do sistema e o desenvolvimento de uma lista de verificao dos requisitos de segurana. Deve notar-se que os tipos de vulnerabilidades que existir, e a metodologia necessria para determinar se as vulnerabilidades esto presentes, normalmente ir variar dependendo da natureza do sistema de TI e a fase que se encontra, no SDLC: Se o sistema ainda no tenha sido projetado, a busca de vulnerabilidades deve se concentrar em polticas de segurana da organizao, procedimentos de segurana planejados, e definies de requisitos de sistema, e anlises dos fornecedores ou desenvolvedores de segurana do produto (por exemplo, White papers). Se o sistema est sendo implementada, a identificao das vulnerabilidades deve ser expandido para incluir informaes mais especficas, como a segurana planejada apresenta descrita na documentao do projeto de segurana e os resultados do teste de sistema de certificao e

avaliao. Se o sistema de TI operacional, o processo de identificao de vulnerabilidades deve incluir uma anlise das caractersticas do sistema de segurana de TI e os controles de segurana, tcnicas e de procedimentos, utilizados para proteger o sistema. 3.3.1 Fontes de vulnerabilidade As vulnerabilidades tcnicas e no tcnicas associadas com o ambiente de um sistema informtico de processamento podem ser identificadas atravs das tcnicas de coleta de informaes descritas na Seo 3.1.2. Uma reviso de outras fontes da indstria (por exemplo, pginas da Web do fornecedor que identificam erros e falhas do sistema) ser til na preparao para as entrevistas e no desenvolvimento de questionrios eficazes para identificar as vulnerabilidades que podem ser aplicveis a determinados sistemas de TI (por exemplo, uma verso especfica do um sistema operacional especfico). A Internet outra fonte de informao 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 anlise minuciosa de vulnerabilidade incluem, mas no esto limitados a, o seguinte: documentao relativa avaliao anterior do risco do sistema de TI avaliada. Os relatrios do sistema de TI de auditoria, relatrios de anomalias do sistema, relatrios de anlise de segurana e de teste do sistema e relatrios de avaliao. As listas de vulnerabilidade, como a base de dados de vulnerabilidade NIST I-CAT. (Http://icat.nist.gov). Os avisos de segurana, tais como FedCIRC e do Departamento de Informtica da Energia Incidente boletins Capacidade consultivos. avisos de fornecedores. Comercial de computador de incidentes / emergncias equipes de resposta e as listas de correio. (por exemplo, mailings Securityfocus.com frum). Informaes de Garantia de Alertas de Vulnerabilidade e boletins de sistemas militares. anlise do sistema de segurana de software. 3.3.2 Testes de segurana do sistema Mtodos 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 disponveis (por exemplo, os fundos atribudos, a tecnologia disponvel, as pessoas com os conhecimentos necessrios para realizar o teste). Os mtodos de ensaio incluem: A vulnerabilidade Automated ferramenta de varredura. Teste de segurana e avaliao. (ST & E) Os testes de penetrao. A ferramenta de verificao automatizada vulnerabilidade utilizada para digitalizar um grupo de hosts ou uma rede de conhecidos servios vulnerveis (por exemplo, o sistema permite transferncia de arquivos annimo Protocolo [FTP], afinao sendmail). No entanto, deve notar-se que alguns dos potenciais vulnerabilidades identificados pela ferramenta de verificao automatizada podem no 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 exigncias. Algumas das vulnerabilidades sinalizadas pelo software de digitalizao automtica pode no ser realmente vulnerveis para um site particular, mas pode ser configurado dessa forma porque o ambiente exige. Assim, este mtodo de teste pode produzir falsos positivos. ST&E uma outra tcnica que pode ser utilizado na identificao de TI vulnerabilidade do sistema durante o processo de avaliao do risco. Isso inclui o desenvolvimento e execuo de um plano de teste (por exemplo, script de teste, procedimentos de teste, e os resultados dos testes esperados). A finalidade dos testes de segurana do sistema testar a eficcia dos controles de segurana de um sistema de TI que tenham sido aplicadas em um ambiente operacional. O objetivo garantir que os controles aplicados atender a especificao

de segurana aprovado para o software e hardware e implementar a poltica de segurana da organizao ou satisfazer os padres da indstria. Os testes de penetrao podem ser usados para complementar reviso de controles de segurana e garantir que as diferentes facetas do sistema de TI esto garantidas. Os testes de penetrao, quando empregue no processo de avaliao do risco, podem ser usados para avaliar a capacidade de um sistema informtico para resistir tentativas intencionais para contornar a segurana do sistema. Seu objetivo testar o sistema de TI do ponto de vista de uma ameaa de fonte e identificar possveis falhas nos sistemas de proteo do sistema de TI. O resultado destes tipos de testes de segurana opcional ajudar a identificar algumas vulnerabilidades do sistema. 3.3.3 Desenvolvimento de Checklist de Requisitos de Segurana. Durante esta etapa, a equipe de avaliao de risco determinar se os requisitos de segurana previstos para o sistema de TI e coletadas durante a caracterizao do sistema esto sendo atendidas pelos controles de segurana existentes ou previstas. Normalmente, os requisitos de segurana do sistema podem ser apresentados em forma de tabela, com cada exigncia acompanhado de uma explicao de como o design do sistema ou aplicao ou no satisfaz essa exigncia de controle de segurana. A lista de checagem de requisitos contm as normas bsicas de segurana que podem ser usados para sistematicamente avaliar e identificar as vulnerabilidades dos ativos (pessoal, hardware, software, informao), procedimentos no automatizada, processos e transferncia de informaes associadas a um determinado sistema de TI nas seguintes reas de segurana: Gesto. Operacional. Tcnico. Tabela 3-3 Lista de critrios de segurana sugerido para uso na identificao de umas vulnerabilidades dos sistemas informticos em cada rea de segurana. Tabela 3-3 Critrios de segurana rea de Segurana Segurana da Gesto Critrios de segurana. Atribuio de responsabilidades Continuidade de apoio Capacidade de resposta a incidentes Reviso peridica dos controles de segurana A distncia pessoal e investigaes de fundo A avaliao dos riscos Segurana e treinamento tcnico Separao de funes Sistema de autorizao e reautorizao Sistema ou plano de segurana do aplicativo Controle de ar carregadas de contaminantes (fumaa, poeira, produtos qumicos). Controles para garantir a qualidade do fornecimento de energia eltrica Dados de acesso ao meio e descarte distribuio de dados externa e rotulagem Facilidade de proteo. (por exemplo, sala de informtica, data center, escritrio). controle de umidade O controle da temperatura

Segurana Operacional

Segurana Tcnica

Estaes de trabalho, laptops e stand-alone computadores pessoais. Comunicaes (por exemplo, dial-nos, a interligao do sistema, roteadores) . Criptografia Controle de Acesso Discricionrio Identificao e autenticao Deteco de Intruso reutilizao de objetos Sistema de auditoria

O resultado deste processo a lista de checagem de requisitos. Fontes que podem ser utilizados para a produo tal lista um incluem, mas no esto limitados a, o governo seguinte regulamentar e diretivas de segurana e de fontes aplicveis ao ambiente de processamento de sistema de TI: CSA de 1987. As normas federais de informao Publicaes de Processamento. OMB novembro 2000 Circular A-130. Privacy Act de 1974. plano de segurana do sistema do sistema de TI avaliado. A organizao de polticas de segurana, diretrizes e padres. As prticas da indstria. O NIST SP 800-26 Guia de Segurana de Auto-Avaliao de Sistemas de Tecnologia da Informao, oferece um extenso questionrio que contm objetivos de controle especficos contra a qual um sistema ou grupo de sistemas interconectados podem ser testados e avaliados. Os objetivos de controle so abstrados diretamente de longa data requisitos contidos no estatuto, polticas e orientaes sobre segurana e privacidade. Os resultados da lista de verificao (ou questionrio) podem ser usados como entrada para uma avaliao do cumprimento e descumprimento. Este processo identifica sistema, processo e fraquezas processuais que representam potenciais vulnerabilidades. Sada a partir do Passo 3. Uma lista das vulnerabilidades do sistema (observaes) que poderia ser exercida pelos potenciais ameaas de fontes. 3.4 PASSO 4: ANLISE DE CONTROLE O objetivo desta etapa analisar os controles que foram implementados, ou esto previstas para a implementao, pela organizao para minimizar ou eliminar a probabilidade (ou probabilidade) de uma ameaa do exerccio de um sistema de vulnerabilidade. Para obter uma classificao global de probabilidade que indica a probabilidade de que uma potencial vulnerabilidade pode ser exercida dentro da construo do ambiente de ameaas associadas (Passo 5 abaixo), a implementao de controles atuais ou previstos deve ser considerada. Por exemplo, uma vulnerabilidade (por exemplo, sistema ou fraqueza processual) no susceptvel de ser exercida ou a probabilidade baixa, se houver um baixo nvel de ameaa fonte de interesse ou capacidade, ou se existirem controles de segurana eficazes que podem eliminar ou reduzir a magnitude do dano. Sees 3.4.1 atravs 3.4.3, respectivamente, discutir mtodos de controle, categorias de controle, e a tcnica de anlise de controle. 3.4.1 Mtodos de controle. Controles de segurana abrangem o uso de mtodos tcnicos e no tcnicos. Os controles tcnicos de salvaguardas que so incorporados hardware, software ou firmware (por exemplo, mecanismos

de controle de acesso, identificao e mecanismos de autenticao, mtodos de criptografia, software de deteco de intruso). Controles no tcnicos so controles gerenciais e operacionais, tais como polticas de segurana, procedimentos operacionais; e pessoal, fsica e de segurana ambiental. 3.4.2 Categorias de Controle As categorias de controle para mtodos de controle, tanto tcnicos e no tcnicos podem ainda ser classificados como preventivo ou detetive. Estas duas subcategorias so explicados como se segue: Controles preventivos inibir tentativas de violar a poltica de segurana e incluir controles tais como a aplicao de controle de acesso, criptografia e autenticao. Avisar Controles de deteco de violaes ou tentativas de violaes da poltica de segurana e incluir controles, tais como trilhas de auditoria, mtodos de deteco de intruso, e checksums. Seo 4.4 explica esses controles do ponto de vista de implementao. A implementao de tais controles durante o processo de mitigao de risco o resultado direto da identificao de deficincias nos controles atuais ou previstas durante o processo de avaliao de risco (por exemplo, os controles no esto em vigor ou controles no so devidamente aplicadas). 3.4.3 Tcnica de Anlise de Controle Conforme discutido na Seo 3.3.3, o desenvolvimento de uma lista de verificao dos requisitos de segurana ou uso de uma lista de verificao disponvel ser til na anlise de controles de forma eficiente e sistemtica. A lista de checagem de requisitos pode ser usada para validar descumprimento de segurana, bem como o cumprimento. Portanto, essencial para atualizar tais listas de verificao para refletir mudanas no ambiente de uma organizao de controle (por exemplo, mudanas nas polticas de segurana, mtodos e requisitos) para garantir a validade da lista de. Sada 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: DETERMINAO PROBABILIDADE Para obter uma classificao global de probabilidade que indica a probabilidade de que uma potencial vulnerabilidade pode ser exercida dentro da construo do ambiente de risco associado, os seguintes fatores que regem devem ser considerados: Ameaa de fonte de motivao e capacidade. Natureza da vulnerabilidade. Existncia e efetividade dos controles atuais. A probabilidade de que uma potencial vulnerabilidade poderia ser exercida por uma determinada fonte de ameaa, pode ser descrito como alto, mdio ou baixo. Tabela 3 - 4 abaixo descrevem esses trs nveis de verossimilhana. Tabela 3-4. Definies de probabilidade Nvel de probabilidade Alto Mdio Baixo Definio de probabilidade A ameaa de fonte altamente motivado e suficientemente capaz, e controles para evitar a vulnerabilidade de ser exercido so ineficazes. A ameaa de fonte motivada e capaz, mas os controles esto no lugar que possa impedir o exerccio bem sucedido da vulnerabilidade. A ameaa de fonte carece de motivao ou

capacidade, ou controles esto no local para evitar, ou pelo menos impedir significativamente, a vulnerabilidade de ser exercido. Sada da Etapa 5 - Avaliao Probabilidade. (Alto, Mdio, Baixo). 3.6 PASSO 6: ANLISE DO IMPACTO O prximo passo importante na medio do nvel de risco para determinar o impacto adverso resultante a partir de um exerccio ameaa bem sucedida de uma vulnerabilidade. Antes de iniciar a anlise de impacto, que necessrio para obter a informao seguinte necessrio como discutido na Seco 3.1.1: A misso do Sistema. (por exemplo, os processos realizados pelo sistema de IT). Sistema de criticidade e de dados. (por exemplo, o valor do sistema ou importncia para uma organizao). Sistema de sensibilidade e de dados. Esta informao pode ser obtida a documentao existente organizacional, tais como o relatrio de anlise de impacto misso ou relatrio de avaliao dos ativos da criticidade. A anlise de impacto misso (tambm conhecida como anlise de impacto nos negcios [BIA] para algumas organizaes) prioriza os nveis de impacto associados com o comprometimento de ativos de informao da organizao com base em uma avaliao qualitativa ou quantitativa da sensibilidade e criticidade desses ativos. Uma avaliao da criticidade ativo identifica e prioriza os ativos da organizao sensveis e crticos de informao (por exemplo, hardware, software, sistemas, servios e ativos relacionados tecnologia) que sustentam a organizao misses crticas. Se essa documentao no existe ou essas avaliaes para a organizao de ativos de TI no tm sido realizados, a sensibilidade do sistema e dos dados pode ser determinado com base no nvel de proteo exigido para manter o sistema e disponibilidade dos dados, a integridade e confidencialidade. Independentemente do mtodo utilizado para determinar o quo sensvel um sistema de TI e seus dados so, os proprietrios de sistemas e informao so os responsveis por determinar o nvel de impacto para o seu prprio sistema e da informao. Consequentemente, na anlise de impacto, a conduta adequada entrevistar o sistema e proprietrio da informao. Portanto, o impacto adverso de um evento de segurana pode ser descrita em termos de perda ou a degradao de qualquer uma, ou uma combinao de qualquer uma, das seguintes trs objetivos de segurana: integridade, disponibilidade e confidencialidade. A lista a seguir fornece uma breve descrio de cada meta de segurana e consequncia (ou impacto) da sua no serem cumpridos: Perda de Integridade. A integridade do sistema e os dados referem-se exigncia de que a informao ser protegido da modificao indevida. A integridade perdida se as alteraes no autorizadas so 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 no for corrigido, o uso continuado do sistema contaminado ou dados corrompidos pode resultar em inexatido, fraude ou decises erradas. Alm disso, violao da integridade pode ser o primeiro passo de um ataque bem sucedido contra a disponibilidade do sistema ou confidencialidade. Por todas estas razes, a perda de integridade reduz a garantia de um sistema de TI. Perda de Disponibilidade. Se um sistema de misso crtica de TI est indisponvel para seus usurios finais, a misso da organizao pode ser afetada. Perda de funcionalidade do sistema e eficcia operacional, por exemplo, pode resultar em perda de tempo produtivo, impedindo o desempenho dos usurios finais de suas funes no apoio misso da organizao. Perda de Confidencialidade. Confidencialidade do sistema e de dados refere-se proteo das

informaes contra divulgao no autorizada. O impacto da divulgao no autorizada de informaes confidenciais pode variar desde o comprometimento da segurana nacional para a divulgao de dados da Lei de Privacidade. A divulgao no autorizada, imprevista, ou no intencional poder resultar em perda da confiana pblica, embarao ou ao legal contra a organizao. Alguns impactos tangveis podem ser medidos quantitativamente em perda de receita, o custo da reparao do sistema, ou o nvel de esforo necessrio para corrigir problemas causados por uma ao bem sucedida ameaa. Outros impactos (por exemplo, perda de confiana do pblico, a perda de credibilidade, danos ao interesse de uma organizao) no podem ser medidos em unidades especficas, mas pode ser qualificado ou descrita em termos de impactos alto, mdio e baixo. Devido natureza genrica da presente discusso, este guia designa e descreve apenas o impacto qualitativo categorias de alta, mdia e baixa (ver Tabela 3.5). Tabela 3-5. Magnitude de definies de impacto Magnitude do Impacto Alto Definies do Impacto Exerccio da vulnerabilidade (1) pode resultar na perda muito caro dos principais ativos tangveis ou recursos; (2) pode significativamente violar, prejudicar ou impedir a misso de uma organizao, a reputao, ou interesse, ou (3) pode resultar em morte humana ou ferimentos graves. Exerccio da vulnerabilidade (1) pode resultar na perda de cara de ativos tangveis ou recursos; (2) pode violar prejudicar ou impedir a misso de uma organizao, a reputao, ou interesse, ou (3) pode resultar em ferimentos. Exerccio da vulnerabilidade (1) pode resultar na perda de alguns ativos tangveis ou recursos ou (2) pode afetar perceptivelmente misso de uma organizao, a reputao, ou interesse.

Mdio

Baixo

Avaliao Quantitativa versus qualitativa Na realizao da anlise de impacto, devem-se considerar as vantagens e desvantagens de avaliaes quantitativas versus qualitativa. A principal vantagem da anlise de impacto qualitativa que ela prioriza os riscos e identifica reas de melhoria imediata na resoluo das vulnerabilidades. A desvantagem da anlise qualitativa que ela no fornece medies especficas quantificveis da magnitude dos impactos, portanto, fazer uma anlise custo-benefcio de qualquer controle recomendadas difceis. A principal vantagem de uma anlise quantitativa de impacto que ele fornece uma medida da magnitude dos impactos ', que pode ser usado na anlise custo benefcio dos controles recomendadas. A desvantagem que, dependendo da gama numricas usadas para expressar a medio, o significado da anlise quantitativa de impacto pode no 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 no esto limitados a: Uma estimativa da frequncia do exerccio a ameaa de fonte de a vulnerabilidade durante um perodo de tempo especificado. (por exemplo, 1 ano). Um custo aproximado para cada ocorrncia de exerccio a ameaa de fonte de vulnerabilidade. Um fator ponderado com base em uma anlise subjetiva do impacto relativo de uma ameaa especfica exercer uma vulnerabilidade especfica.

Sada do Passo 6 - Magnitude do impacto (Alto Mdio ou Baixo) 3.7 PASSO 7: determinao do risco O propsito deste passo o de avaliar o nvel de risco para o sistema de TI. A determinao do risco de um par ameaa / vulnerabilidade particular pode ser expressa como uma funo de: A probabilidade de uma dada ameaa de fonte est tentando exercer uma determinada vulnerabilidade. A magnitude do impacto se uma ameaa fonte exercer com sucesso a vulnerabilidade. A adequao dos controles de segurana j existente ou planejada para reduzir ou eliminar o risco. Para medir o risco, uma escala de risco e uma matriz de nvel de risco devem ser desenvolvidas. Seo 3.7.1 apresenta uma matriz de risco em nvel de padro; Seo 3.7.2 descreve os nveis de risco resultantes. 3.7.1 Matriz de Nvel de Risco A determinao final da misso de risco resultado da multiplicao dos ratings atribudos pela probabilidade de ameaa (por exemplo, a probabilidade) e impacto ameaa. Tabela 3.6 abaixo mostra como as classificaes globais de risco podem ser determinadas com base em contributos a probabilidade de ameaa e categorias de impacto de ameaas. A matriz abaixo uma matriz 3 x 3 de probabilidade de ameaa (Alto, Mdio e Baixo) e impacto ameaa (Alto Mdio e Baixo). Dependendo dos requisitos do site e a granularidade da avaliao de risco desejado, alguns sites podem usar um 4 x 4 ou um 5 x 5 matriz. O ltimo pode incluir uma ameaa probabilidade muito baixa / muito alta e um impacto ameaa Muito Baixo / Muito Alta para gerar um nvel de risco muito baixa / muito alta. No nvel de risco "Muito Elevado" pode exigir o desligamento do sistema ou a paragem do possvel toda a integrao do sistema de TI e os esforos de teste. A matriz da amostra na Tabela 3-6 mostra como os nveis globais de risco de Alta, Mdia e Baixa so derivadas. A determinao dos nveis de risco ou avaliaes pode ser subjetiva. A razo para esta justificao pode ser explicada em termos da probabilidade atribudo para cada nvel de probabilidade ameaa e um valor atribudo para cada nvel de impacto. Por exemplo, A probabilidade atribuda para cada nvel de probabilidade de ameaa de 1,0 para alta, de 0,5 para Mdio, 0,1 para Baixo. O valor atribudo para cada nvel de impacto de 100 para alta, 50 para mdio e 10 para baixo. Tabela 3-6 Matriz de Nvel de Risco Impacto Baixo Mdio (10) (50) Baixo Mdio Alta (1.0) 10x1. 0=10 50x1. 0=50 Baixo Mdio Mdio (0.5) 10x0. 5=5 50x0. 5=25 Baixo Mdio Baixa (0.1) 10x0. 1=1 50x0. 1=5 Escala de Risco: Alto (>50 at 100); Mdio (>10 at 50); Baixo (1 at 10). Probabilidade de ameaas Alto (100) Alto 100x1. 0=100 Alto 100x0. 5=50 Alto 100x0. 1=10

OBS: Se o nvel indicado nos itens certos to baixo a ponto de ser considerada "desprezvel", ou no 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 gesto. Isso far com que eles no sejam esquecidos quando da avaliao de risco peridica seguinte. Tambm estabelece um registro completo de todos os riscos identificados na anlise. Estes riscos podem mudar para

um novo nvel de risco em uma reavaliao devido a uma mudana na probabilidade de ameaa e / ou impacto e por isso que fundamental que no se perca a sua identificao no exerccio. 3.7.2 Descrio do Nvel de Risco Tabela 3-7 descreve os nveis de risco mostrados na matriz acima. Esta escala de risco, com suas classificaes de Alta, Mdia e Baixa, representam o grau ou nvel de risco a que um sistema de TI, instalao ou procedimento pode ser expostos se a vulnerabilidade em questo foram exercidas. A escala de risco tambm apresenta aes que a gerncia snior, os donos da misso, deve levar para cada nvel de risco. Tabela 3-7. Escala de risco e as aes necessrias Nvel do Risco Descrio risco e as aes necessrias Alto Se uma observao 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 ao corretiva deve ser colocado em prtica o mais rpido possvel. Mdio Se uma observao classificada como de mdio risco, aes corretivas so necessrias e um plano deve ser desenvolvido para incorporar essas aes dentro de um perodo razovel de tempo. Baixo Se uma observao descrita como de baixo risco, DAA do sistema deve determinar se as aes corretivas so ainda necessrias ou decidir a aceitar o risco. Sada de Passo 7 - Nvel de risco. (Alto, Mdio, Baixo). 3.8 PASSO 8: RECOMENDAES DE CONTROLE Durante este passo do processo, os controles que podem mitigar ou eliminar os riscos identificados, tal como apropriada para as operaes da organizao, so fornecidos. O objetivo dos controles recomendados o de reduzir o nvel de risco para o sistema de TI e os seus dados para um nvel aceitvel. Os seguintes fatores devem ser considerados na recomendao de controles e solues alternativas para minimizar ou eliminar os riscos identificados: Eficcia das opes recomendadas. (por exemplo, a compatibilidade do sistema). Legislao e regulamentao. A poltica organizacional. O impacto operacional. Segurana e confiabilidade. As recomendaes de controle so os resultados do processo de avaliao de risco e contribuir para o processo de mitigao de risco, durante o qual os controles de segurana recomendadas processuais e tcnicas so avaliadas, priorizadas e implementadas. Deve ser notado que nem todos os controles possveis recomendadas pode ser implementado para reduzir a perda. Para determinar quais so necessrios e adequados para uma organizao especfica, uma anlise de custo-benefcio, conforme discutido na Seo 4.6, devem ser conduzidos para os controles propostas recomendadas, para demonstrar que os custos de implementao dos controles pode ser justificada pela reduo o nvel de risco. Alm disso, o impacto operacional (por exemplo, o efeito no desempenho do sistema) e viabilidade (por exemplo, requisitos tcnicos, de aceitao do usurio) de introduzir a opo recomendada devem ser cuidadosamente avaliados durante o processo de mitigao de riscos.

Sada de Passo 8 - Recomendao de solues de controle e alternativas para mitigar o risco. 3.9 PASSO 9: DOCUMENTAO DOS RESULTADOS Uma vez que a avaliao de risco foi concluda (ameaas e vulnerabilidades de fontes identificadas, riscos avaliados, e os controles recomendados fornecidos), os resultados devem ser documentados em um relatrio oficial ou briefing. Um relatrio de avaliao de risco um relatrio de gesto que ajuda a gerncia snior, os proprietrios de misso, tomar decises sobre o oramento, poltica, processual, e sistema de mudanas operacionais e de gesto. Ao contrrio de um relatrio de auditoria ou investigao, que olha para o erro, um relatrio de avaliao de risco no deve ser apresentado de forma acusatria, mas como uma abordagem sistemtica e analtica para avaliar o risco para que o gerenciamento snior v compreender os riscos e alocar recursos para reduzir e corrigir potenciais perdas. Por esta razo, algumas pessoas preferem abordar os pares ameaa / vulnerabilidade como observaes em vez de resultados no relatrio de avaliao de risco. Apndice B proporciona um esquema sugerido para o relatrio de avaliao de risco. Sada de Passo 9 - relatrio de avaliao de riscos que descreve as ameaas e vulnerabilidades mede o risco, e fornece recomendaes para implementao de controle. 4. REDUO DO RISCO Reduo de riscos, o segundo processo de gesto de risco, envolve priorizar, avaliar e implementar o apropriado de reduo de risco controles recomendado a partir do processo de avaliao de risco. Dado que a eliminao de todos os riscos geralmente impraticvel ou quase impossvel, de responsabilidade da administrao snior e os gerentes funcionais e de negcios a utilizar o mtodo de menor custo e implementar os controles mais adequados para diminuir o risco da misso a um nvel aceitvel, com o mnimo impacto adverso sobre os recursos da organizao e misso. Esta seo descreve as opes de reduo de risco (Seo 4.1), a estratgia de mitigao de risco (Seo 4.2), uma abordagem para implementao de controle (Seo 4.3), categorias de controle (Seo 4.4), a anlise custo-benefcio utilizado para justificar a implementao do recomendado controles (Seo 4.5), e o risco residual (seo 4.6). 4.1 Opes de reduo de risco Reduo de riscos uma metodologia sistemtica usada pela gerncia snior para reduzir o risco da misso. Reduo do risco pode ser conseguida atravs de qualquer das opes de mitigao de risco seguintes: Assuno de Riscos. Para aceitar o risco potencial e continuar operando o sistema de TI ou para implementar controles para reduzir o risco a um nvel aceitvel. Preveno de riscos. Para evitar o risco, eliminando o risco de causa e / ou consequncia. (por exemplo, abrir mo de certas funes do sistema ou desligar o sistema quando os riscos so identificados). Limitao de Risco. Para limitar o risco atravs da implementao de controles que minimizem o impacto negativo de uma ameaa exercer uma vulnerabilidade (por exemplo, o uso de apoio, preveno controles, detetive). Planejamento de Riscos. Para gerenciar o risco atravs do desenvolvimento de um plano de mitigao de risco que prioriza, implementa e mantm controles. Pesquisa e Reconhecimento. Para diminuir o risco de perda do reconhecimento da

vulnerabilidade ou falha e pesquisando controles para corrigir a vulnerabilidade. Transferncia de Risco. Para transferir o risco usando outras opes para compensar a perda, como a compra de seguros. Os objetivos e misso de uma organizao devem ser considerados na seleo qualquer uma dessas opes de mitigao de risco. Pode no ser prtico para resolver todos os riscos identificados, por isso deve ser dada prioridade ameaa e vulnerabilidade pares que tm o potencial de causar impacto significativo ou prejuzo misso. Alm disso, na salvaguarda da misso de uma organizao e seus sistemas de TI, devido ao ambiente nico de cada organizao e objetivos, a opo usada para mitigar o risco e os mtodos utilizados para implementar controles podem variar. O "best of breed" abordagem a utilizao de tecnologias apropriadas, dentre os vrios produtos de segurana do fornecedor, juntamente com a opo apropriada de mitigao de risco e no tcnicos, medidas administrativas. 4.2 Estratgias reduo de riscos A gerncia snior, os proprietrios de misso, conhecendo os potenciais riscos e controles recomendados, pode perguntar, "Quando e em que circunstncias devem agir? Quando devo implementar esses controles para mitigar o risco e proteger a nossa organizao?. O grfico de mitigao de riscos na Figura 4-1 aborda estas questes. Pontos apropriados para a implementao das aes de controle esto indicados nesta figura com a palavra SIM.

Figura 4-1. Reduo de risco Pontos de Ao Esta estratgia ainda mais articulada nos seguintes regras de ouro, que fornecem orientaes sobre aes para reduzir os riscos de ameaas intencionais humanos: Quando vulnerabilidade (ou falha, fraqueza) existe implementar tcnicas 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 ocorrncia. Quando o custo do atacante menor que o ganho potencial aplicar as salvaguardas para diminuir a motivao de um invasor, aumentando o custo do atacante (por exemplo, o uso de controles do sistema, tais como limitar o que um usurio do sistema pode acessar e no pode reduzir significativamente o ganho de um atacante). Quando a perda muito grande aplicar os princpios de design, desenhos arquitetnicos e protees tcnicos e no tcnicos para limitar a extenso do ataque, reduzindo o potencial de perda. A estratgia delineada acima, com exceo do terceiro item da lista ("Quando o custo do atacante menor que o ganho potencial"), tambm se aplica para a reduo dos riscos resultantes da ambiental ou no intencionais ameaas humanas (por exemplo, sistema, ou erros do usurio). (Porque no h nenhum "intruso", sem motivao ou o ganho est envolvido.). 4.3 ABORDAGENS PARA A APLICAO DE CONTROLE Quando as aes de controle devem ser tomadas, a seguinte regra: Abordar os maiores riscos e lutar pela mitigao de risco suficiente com o menor custo, com um impacto mnimo sobre as capacidades outra misso. A metodologia de reduo de risco a seguir descreve a abordagem para controlar a sua aplicao: Etapa 1 - Priorizar aes Com base nos nveis de risco apresentados no relatrio de avaliao de risco, as aes de implementao so priorizados. Na alocao de recursos, a prioridade deve ser dada ao risco itens com rankings de risco inaceitavelmente elevada (por exemplo, o risco atribudo um nvel de risco muito elevado ou alto). Estes pares de vulnerabilidade / ameaa exigir ao corretiva imediata para proteger o interesse de uma organizao e misso. Sada da etapa 1 - Aes ranking de alto para baixo. Etapa 2 - Avaliar Opes de controle recomendadas Os controles recomendados no processo de avaliao de risco no podem ser as opes mais adequadas e viveis para uma organizao especfica e sistema de TI. Durante este passo, a viabilidade (por exemplo, a compatibilidade de aceitao do usurio,) e eficcia (por exemplo, o grau de proteo e de nvel de atenuao de risco) das opes de controlo recomendadas so analisadas. O objetivo selecionar a opo de controle mais adequado para minimizar os riscos. Sada da etapa 2 - Lista de controles possveis Etapa 3 - Anlise Custo-Benefcio Conduta Para auxiliar a gesto na tomada de decises e para identificar o custo-eficcia dos controles, uma anlise custo-benefcio conduzida. Seco 4.5 detalha os objetivos e mtodo de realizao da anlise custo-benefcio. Sada da etapa 3 - Anlise custo-benefcio descrever os custos e benefcios da implementao ou no implementao dos controles. Etapa 4 - controle de seleo Com base nos resultados da anlise custo-benefcio, gesto determina o controle mais custoefetivo (s) para reduzir o risco para a misso da organizao. Os controles selecionados devem combinar tcnica, operacional e elementos de controlo de gesto para garantir a segurana adequada para o sistema de TI e da organizao. Sada a partir da etapa 4 - Seleo de controle

Etapa 5 - Atribuir Responsabilidade Pessoas adequadas (in-house pessoal ou contratao de pessoal externo) que possuem o conhecimento adequado e conjuntos de capacidades para implementar o controle selecionado so identificados, e a responsabilidade atribuda. Sada de Etapa 5 - Lista das pessoas responsveis. Etapa 6 - Desenvolver um Plano de Implementao de Salvaguardas Durante esta etapa, a implementao de salvaguarda pLAN9 (ou plano de ao) desenvolvido. O plano deve, no mnimo, conter as seguintes informaes: - Riscos (vulnerabilidade / ameaa pares) e nveis de risco associados (sada do relatrio de avaliao de risco). - Controles recomendados. (sada do relatrio de avaliao de risco) - Aes prioritrias. (com prioridade para itens com nveis de risco muito alto e alto) - Seleo de controles planejados. (determinado com base na viabilidade, eficcia e benefcios para a organizao e custo). - Recursos necessrios para a implementao dos controles selecionados planejados. - Listas de equipes responsveis e funcionrios. - Data de incio para a implementao. - Data de concluso prevista para a implementao. - Os requisitos de manuteno. O plano de implementao de salvaguarda prioriza as aes de implementao e projetos de incio e datas de concluso alvo. Este plano vai ajudar e agilizar o processo de mitigao de riscos. Apndice C fornece uma tabela de resumo de exemplo para o plano de implementao de salvaguarda. Sada de Passo 6 - Salvaguarda do plano de implementao Etapa 7 - Implementar controle selecionado Dependendo das situaes individuais, os controles implementados podem diminuir o nvel de risco, mas no eliminar o risco. O risco residual discutido na Seo 4.6. Sada de Passo 7 - risco residual. Figura 4-2 descreve a metodologia recomendada para a reduo de riscos. Entrada Atividades de reduo de risco Sada Os nveis de risco a partir do Passo 1 Priorizar aes Aes do ranking do relatrio de avaliao de risco. decrescente Relatrio de avaliao de Passo 2 Avaliar as opes de Lista de possveis controles riscos controle recomendadas Viabilidade Eficcia Passo 3 Realizar Anlise Custo- Anlise custo-benefcio Benefcio Impacto da execuo. Impacto da no execuo. Os custos associados. Passo 4 Seleo de controle Controles selecionados Passo 5 Atribuir Lista das pessoas responsveis Responsabilidade Passo 6 Desenvolver Plano de Salvaguardar do plano de Implementao para implementao Salvaguardar

Riscos e nveis de risco associados As aes prioritrias Controles Recomendados Escolhidas controles planejados As pessoas responsveis Data de Incio data de concluso prevista Exigncias de manuteno Passo 7 Implementar os controles selecionados Figura 4-2. Fluxograma de risco metodologia de mitigao

Riscos Residuais

4.4 CATEGORIAS DE CONTROLE Na implementao de controles recomendados para mitigar o risco, uma organizao deve considerar a gesto, tcnicas, operacionais e controles de segurana, ou uma combinao de tais controles, para maximizar a eficcia dos controles para os seus sistemas de TI e da organizao. Controles de segurana, quando utilizado adequadamente, podem evitar limitar ou impedir ameaa fonte de danos para a misso de uma organizao. O processo de recomendao de controle envolve escolher entre uma combinao de tcnica, de gesto e controles operacionais para melhorar a postura de segurana da organizao. O tradeoffs que uma organizao ter que considerar ilustrado por ver as decises envolvidas na aplicao de uso de senhas de usurios complexas para minimizar a adivinhao de senha e rachaduras. Neste caso, uma tcnica que requeiram controla extra software de segurana pode ser mais complexa e dispendiosa do que um procedimento de controle, mas o controlo tcnica provvel que seja mais eficaz porque a aplicao automatizada pelo sistema. Por outro lado, um procedimento de controle pode ser implementado simplesmente por meio de um memorando a todos os indivduos interessados e uma mudana das diretrizes de segurana para a organizao, mas garantindo que os usurios sempre seguir o memorando e orientao sero difceis e exigir a conscientizao da segurana treinamento e aceitao do usurio. Esta seo fornece uma viso geral de alto nvel de algumas das categorias de controle. Orientaes mais detalhadas sobre a implementao e planejamento para os controles de TI pode ser encontrado em NIST SP 800-18, Guia para o Desenvolvimento de Planos de Segurana para Sistemas de Tecnologia da Informao, e NIST SP 800-12, An Introduction to Computer Security: The NIST Handbook. Sees 4.4.1 atravs 4.4.3 fornecer uma viso geral tcnica, gesto e controles operacionais, respectivamente. 4.4.1 Tcnicas Controles de Segurana Controles tcnicos de segurana para a mitigao do risco pode ser configurado para se proteger contra certos tipos de ameaas. Esses controles podem variar de simples a complexas medidas e geralmente envolvem arquiteturas de sistemas; disciplinas de engenharia e pacotes de segurana com uma combinao de hardware, software e firmware. Todas estas medidas devem trabalhar juntos para proteger dados crticos e sensveis, informaes e funes do sistema de TI. Os controles tcnicos podem ser agrupados nas seguintes categorias principais, de acordo com a principal finalidade: Suporte (Seo 4.4.1.1). Controles de apoio so genricos e est subjacente a maioria dos recursos de segurana de TI. Esses controles devem estar no local, a fim de implementar outros controles.

Prevenir (Seo 4.4.1.2). Controles preventivos foca a preveno de violaes de segurana ocorra em primeiro lugar. detectar e recuperar (Seo 4.4.1.3). Esses controles se concentrar em detectar e recuperar de uma quebra de segurana.

Figura 4-3 ilustra os controles principais tcnicas e as relaes entre eles. Figura 4-3. CONTROLES TCNICOS DE SEGURANA 4.4.1.1 Controles Tcnicos de Apoio Controles de apoio so, pela sua prpria natureza, penetrante e inter-relacionado com muitos outros controles. Os controles de apoio so como se segue: Identificao. Esse controle fornece a capacidade de identificar os usurios, processos e recursos de informao. Para implementar controles de segurana (por exemplo, controle de acesso discricionrio [DAC], controle de acesso obrigatrio [MAC] prestao de contas), essencial que ambos os sujeitos e objetos serem identificveis. Gesto de chave criptogrfica. As chaves criptogrficas devem ser gerenciadas com segurana quando as funes criptogrficas so implementadas em vrios outros controles. Gerenciamento de chaves de criptografia inclui gerao de chaves, distribuio, armazenamento e manuteno. Administrao de Segurana. Os recursos de segurana de um sistema de TI devem ser

configurados (por exemplo, ativado ou desativado) para atender as necessidades de uma instalao especfica e ter em conta as mudanas no ambiente operacional. A segurana do sistema pode ser construda em segurana do sistema operacional ou o aplicativo. Comercial fora o suplemento prateleira de produtos de segurana esto disponveis. Protees do Sistema. Subjacente capacidade de um sistema de segurana diversos sectores funcionais uma base de confiana na execuo tcnica. Isto representa a qualidade da execuo do ponto de vista tanto do desenho processos utilizados e da maneira em que a aplicao foi realizada. Alguns exemplos de protees do sistema so a proteo das informaes residual (tambm conhecida como a reutilizao de objetos), pelo privilgio (ou "precisa saber"), a separao do processo, modularidade, camadas e minimizao do que precisa ser confivel. 4.4.1.2 Controles Tcnicos preventivos Estes controles, que pode inibir as tentativas de violao de segurana, incluem o seguinte: Autenticao. O controle de autenticao fornece os meios de verificao da identidade de um sujeito para garantir que uma identidade vlida. Mecanismos de autenticao incluem senhas, nmeros de identificao pessoal, ou PINs, e tecnologia de autenticao emergente que fornece autenticao forte (por exemplo, token, smart card, certificado digital, Kerberos). Autorizao. O controle de autorizao permite que a especificao e posterior gesto das aes permitidas para um determinado sistema (por exemplo, o proprietrio da informao ou o administrador do banco determina quem pode atualizar um arquivo compartilhado acessado por um grupo de usurios on-line). Aplicao de Controle de Acesso. Integridade dos dados e a confidencialidade so impostas por controles de acesso. Quando o assunto solicitando o acesso foi autorizado a acessar determinados processos, necessrio para fazer cumprir a poltica de segurana definida (por exemplo, MAC ou DAC). Esses controles baseados em polticas so aplicados atravs de mecanismos de controle de acesso distribudos por todo o sistema (por exemplo, rtulos de sensibilidade MAC, conjuntos de permisses de arquivos CAD, listas de controle de acesso, funes, perfis de usurio). A eficcia e a fora de controlo de acesso dependem da exatido das decises de controlo de acesso (por exemplo, como as regras de segurana so configuradas) e a fora de aplicao de controlo de acesso (por exemplo, o desenho de segurana de software ou hardware). no repdio. Responsabilidade do sistema depende da capacidade de garantir que o remetente no pode negar o envio de informaes e que o receptor no se pode negar a sua recepo. No repdio abrange tanto a preveno e deteco. Foi colocado na categoria preveno neste guia, pois os mecanismos implementados evitar o repdio de sucesso de uma ao (por exemplo, o certificado digital que contm a chave privada do proprietrio conhecido apenas para o proprietrio). Como resultado, este controle normalmente aplicado no ponto de transmisso ou recepo. Protegido Comunicaes. Em um sistema distribudo, a capacidade de realizar os objetivos de segurana altamente dependente de comunicaes confiveis. O controle de comunicaes protegida garante a integridade, disponibilidade e confidencialidade das informaes sensveis e crticos enquanto ele estiver em trnsito. Comunicaes protegidas utilizar mtodos de criptografia de dados (por exemplo, rede privada virtual, o Internet Protocol Security [IPSEC] Protocol), e implantao de tecnologias de criptografia (por exemplo, Data Encryption Standard [DES], Triple DES, RAS, MD4, MD5, Secure Hash Standard, e algoritmos de criptografia em cauo, como Clipper) para minimizar as ameaas de rede, tais como repetio, a interceptao de pacotes, cheirando, grampos, ou de espionagem. Privacidade de Transao. Tanto o governo e os sistemas do setor privado esto cada vez mais necessrios para manter a privacidade dos indivduos. Controles de transao privacidade (por exemplo, Secure Sockets Layer shell seguro) proteger contra a perda de privacidade com relao s transaes realizadas por um indivduo. 4.4.1.3 Deteco e Controles de recuperao tcnica Controles de deteco de violaes de avisar ou violaes tentativas de poltica de segurana e incluir controles, tais como trilhas de auditoria, mtodos de deteco de intruso, e checksums.

Controle de recuperao pode ser usado para restaurar recursos computacionais perdidos. Eles so necessrios como complemento s medidas de apoio e tcnica preventiva, porque nenhuma das medidas nessas outras reas perfeita. Controles de deteco e de recuperao incluem: Auditoria. A auditoria de segurana relevantes eventos e o monitoramento e rastreamento de anormalidades do sistema so elementos importantes para a deteco depois do fato de, e recuperao de falhas de segurana. Deteco de Intruso e de conteno. essencial para detectar falhas de segurana (por exemplo, rede de arrombamento, atividades suspeitas) de modo que uma resposta pode ocorrer em tempo hbil. Tambm de pouca utilidade para detectar uma violao de segurana se no houver resposta eficaz pode ser iniciado. A deteco de intruso e controle de conteno 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 ameaas potenciais. Esse controle no impede violaes da poltica de segurana, mas detecta violaes e ajuda a determinar o tipo de ao corretiva necessria. Restaurar estado seguro. Este servio permite que um sistema para retornar a um estado que conhecido por ser seguro, aps uma falha de segurana ocorre. Deteco de vrus e erradicao. Deteco de vrus e software erradicao instalado em servidores e estaes de trabalho do usurio detecta, identifica e remove vrus de software para garantir a integridade do sistema e de dados. 4.4.2 Controles de Segurana da Gesto Controles de gerenciamento de segurana, em conjunto com controles tcnicos e operacionais, so implementadas para gerenciar e reduzir o risco de perda e para proteger a misso de uma organizao. Gesto controla o foco sobre a estipulao da poltica de proteo de informaes, as diretrizes e normas, que so realizadas atravs de procedimentos operacionais para cumprir as metas da organizao e misses. Controles de gesto de segurana preventiva, deteco e recuperao de que so implementadas para reduzir o risco so descritos nas seces 4.4.2.1 atravs 4.4.2.3. 4.4.2.1 Controles de Segurana Preventiva de Gesto Esses controles incluem o seguinte: Atribuir a responsabilidade de segurana para garantir que a segurana o adequado para as misses crticas sistemas de TI. a segurana de o sistema desenvolver e manter planos para documentar controles atuais e controles endereo planejados para os sistemas de TI em apoio misso da organizao. Implementar controles de pessoal de segurana, incluindo a separao de funes, pelo privilgio, e registro de usurio o acesso ao computador e terminao. Realizar a conscientizao da segurana e formao tcnica para garantir que os usurios finais e usurios do sistema esto cientes das regras de comportamento e de suas responsabilidades na proteo a misso da organizao. 4.4.2.2 Deteco de Controles de Segurana da Gesto Controles de gesto de deteco so como se segue: Implementar controles de pessoal de segurana, incluindo o pessoal de folga, as investigaes de fundo, rotao de funes. Realizar reviso peridica dos controles de segurana para garantir que os controles so eficazes. Realizar auditorias de sistema peridico. Realizar gesto 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 Recuperao de gesto de segurana controles Esses controles incluem o seguinte:

Dar continuidade de apoio e desenvolver, testar, e manter a continuidade do plano de operaes para fornecer para a retomada de negcios e assegurar a continuidade das operaes durante emergncias 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 Segurana Operacional Padres de segurana da organizao deve estabelecer um conjunto de controles e diretrizes para garantir que os procedimentos de segurana que regem o uso da organizao ativos de TI e recursos sejam devidamente aplicadas e executadas em conformidade com os objetivos da organizao e misso. Gesto desempenha um papel vital na superviso da implementao de polticas e em assegurar o estabelecimento de adequados controles operacional. Controles operacionais, implementadas de acordo com um conjunto de requisitos de base (por exemplo, controles tcnicos) e boas prticas da indstria, so usados para corrigir deficincias operacionais que poderiam ser exercidas por potenciais ameaas de fontes. Para assegurar a coerncia e uniformidade nas operaes de segurana, passo-a-passo os procedimentos e mtodos para a implementao de controles operacionais devem ser claramente definidos, documentados e mantidos. Esses controles operacionais incluem aqueles apresentados nas Sees 4.4.3.1 e 4.4.3.2 abaixo. 4.4.3.1 Controles preventivos Operacionais Controles operacionais preventivos so os seguintes: Controle de acesso a dados de mdia e eliminao. (por exemplo, controle de acesso fsico mtodo, desmagnetizao). Limite de distribuio de dados externa. (por exemplo, o uso de rotulagem). O software de controle de vrus. Proteja instalao de computao. (por exemplo, guardam de segurana, procedimentos do site para os visitantes, sistema de identificao eletrnica, acesso biometria gesto, controla e distribuio de fechaduras e chaves, barreiras e cercas). Proteger armrios 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 alteraes de banco de dados para ser usado em vrios cenrios de recuperao). Estabelecer procedimentos fora do local de armazenamento e segurana. Proteja laptops, computadores pessoais (PC), estaes de trabalho. Proteger os ativos de TI de dano de fogo. (por exemplo, requisitos e procedimentos para o uso de extintores de incndio, lonas, sistemas de sprinklers seca, sistema de supresso de fogo halon). Fornecer fonte de energia de emergncia. (por exemplo, os requisitos para breaks, geradores de energia on-site). Controlar a umidade e a temperatura da instalao de computao. (por exemplo, a operao de condicionadores de ar, disperso de calor). 4.4.3.2 Deteco de Controles Operacionais Controles de deteco operacionais incluem o seguinte: Garantir a segurana fsica (por exemplo, o uso de detectores de movimento, circuito fechado de televiso, sensores de monitoramento e alarmes). Garantir a segurana ambiental (por exemplo, o uso de detectores de fumaa e fogo, sensores e alarmes). 4.5 Anlise Custo-Benefcio Para alocar os recursos e implementar controles custo-benefcio, organizaes, aps a identificao de todos os controles possveis e avaliar a sua viabilidade e eficcia, devero realizar uma analise custo-benefcio para cada controle proposto para determinar quais controles so necessrios e

adequados para as suas circunstncias. A anlise custo-benefcio pode ser qualitativa ou quantitativa. O seu objetivo o de demonstrar que o custo de implementao dos controles pode ser justificado pela reduo do nvel de risco. Por exemplo, a organizao no pode querer gastar US $ 1.000 em um controle para reduzir o risco de US $ 200. Uma anlise de custo-benefcio para propostas de novos controles ou controles aprimorados abrange o seguinte: Determinar o impacto da implementao dos controles novos ou aprimorados. Determinar o impacto da no implementao dos controles novos ou aprimorados. Estimar os custos da implementao. Estes podem incluir, mas no esto limitados a, o seguinte: - Aquisies de hardware e software. - Reduo da eficcia operacional, se o desempenho do sistema ou a funcionalidade reduzido para aumentar a segurana. - Custo da implementao de polticas e procedimentos adicionais. - Custo da contratao de pessoal adicional para implementar as polticas propostas, procedimentos ou servios. - Custos de formao. - Os custos de manuteno. Avaliar os custos de implementao e benefcios contra a criticidade do sistema e dados para determinar a importncia para a organizao de implementar os novos controles, dado os seus custos e impacto relativo. A organizao ter de avaliar os benefcios dos controles em termos de manter uma postura misso aceitveis para a organizao. Assim como existe um custo para implementar um controle necessrio, h um custo para no implement-lo. Ao relacionar o resultado da no implementao do controle da misso, as organizaes podem determinar se possvel abrir mo de sua implementao. Anlise de Custo-Benefcio Exemplo: sistema armazena e processa a informao X privacidade de misso crtica e sensvel empregado, no entanto, a auditoria no foi habilitada para o sistema. Uma anlise custo-benefcio conduzida para determinar se o recurso de auditoria deve ser habilitado para o Sistema X. Itens (1) e (2) face ao impacto intangvel (por exemplo, fatores de dissuaso) para a implementao ou no implementao do novo controle. Item (3) enumera os bens tangveis (por exemplo, custo real). (1) Impacto de permitir recurso de auditoria do sistema: A funo de auditoria do sistema permite que o administrador de segurana do sistema para monitorar as atividades dos usurios do sistema, mas vai abrandar o desempenho do sistema e, portanto, afetam a produtividade do usurio. Tambm a implementao exigir recursos adicionais, conforme descrito no Item 3. (2) Impacto de no possibilitar recurso de auditoria do sistema: as atividades dos usurios do sistema e as violaes no podem ser monitoradas e controladas, se a funo de auditoria do sistema desativada, e a segurana no pode ser maximizada para proteger os dados confidenciais da organizao e misso. (3) A estimativa de custos para habilitar o recurso de auditoria do sistema: Custo para permitir auditoria do sistema caracterstica sem custo, funcionalidade built-in. Pessoal adicional para realizar uma reviso de auditoria e arquivar, por ano. Formao. (por exemplo, sistema de configurao de auditoria gerao de relatrios). $0 $ XX,XXX $ X,XXX

Add-on software de relatrios de auditoria. Auditoria de manuteno de dados (por exemplo, o armazenamento, arquivamento), por ano. Custos totais estimados.

$ X,XXX $ X,XXX

$ XX,XXX

Gestores da organizao devem determinar o que constitui um nvel aceitvel de risco da misso. O impacto de um controle pode ento ser avaliado, e o controle includo ou excludo, aps a organizao determina uma srie de nveis de risco viveis. Este intervalo pode variar entre as organizaes, no entanto, as seguintes regras para determinar o uso de novos controles: Se o controle seria reduzir o risco mais do que o necessrio, ento, ver se uma alternativa menos dispendiosa existe. Se o controle custaria mais do que a reduo de risco disponvel, em seguida, encontrar outra coisa. Se o controle no reduz risco suficientemente, em seguida, procure mais controles ou um controle diferente. Se o controle proporciona reduo de riscos o suficiente e custo-efetivo, em seguida, us-lo. Frequentemente, o custo de implementao de um controle mais tangvel do que o custo de no implement-lo. Como resultado, a alta administrao desempenha um papel fundamental nas decises relativas implementao de medidas de controle para proteger a misso organizacional. 4.6 RISCO RESIDUAL As organizaes podem analisar a extenso da reduo do risco gerado pelos controles novos ou aprimorados em termos de probabilidade de ameaa reduzida ou impacto, os dois parmetros que definem o nvel de risco mitigado com a misso organizacional. Implementao de controles novos ou aperfeioados podem mitigar o risco: A eliminao de algumas das vulnerabilidades do sistema (falhas e fraqueza), reduzindo assim o nmero de pares de fonte de ameaa/ possveis vulnerabilidades. Adio de um controle voltado para reduzir a capacidade e motivao de uma ameaa de fonte. Por exemplo, um departamento determina que o custo para instalao e manuteno de complemento software de segurana para o PC autnomo que armazena seus arquivos sensveis no justificvel, mas que os controles administrativos e fsicos devem ser implementadas para SP Pgina 40 800-30 fazer acesso fsico ao PC que mais difcil (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 extenso de uma vulnerabilidade ou modificando a natureza da relao entre o sistema de TI e misso da organizao). A relao entre a execuo e controle de risco residual representada graficamente na Figura 4-4.

Figura 4-4. Implementao dos controles e riscos residuais. O risco remanescente aps a implementao 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 nvel de risco a zero. Como exigido pela OMB Circular A-130, a alta administrao de uma organizao ou a DAA, que responsvel por proteger ativos de TI da organizao e da misso, deve autorizar (ou credenciar) o sistema de TI para comear ou continuar a funcionar. Esta autorizao ou credenciamento deve ocorrer pelo menos a cada 3 anos ou sempre que grandes mudanas so feitas para o sistema de TI. A inteno deste processo identificar os riscos que no so tratados completamente e para determinar se os controles adicionais so necessrios para mitigar os riscos identificados no sistema de TI. Para as agncias federais, depois que os controles adequados tenham sido postas em prtica para os riscos identificados, o DAA vo assinar uma declarao aceitando qualquer risco residual e autoriza o funcionamento do novo sistema de TI ou a transformao contnua do sistema informtico existente. Se o risco residual no tenha sido reduzido para um nvel aceitvel, o ciclo de gesto de risco deve ser repetido para identificar uma forma de reduzir o risco residual para um nvel aceitvel. 5. Anlise e avaliao Na maioria das organizaes, a rede em si vai ser continuamente ampliada e atualizada, seus componentes alterados, e as suas aplicaes de software substitudo ou atualizado com as verses mais recentes. Alm disso, mudana de pessoal ocorrer e polticas de segurana tendem a mudar com o tempo. Estas mudanas significam que os riscos de novos superfcie e riscos previamente mitigados pode aa tornou uma preocupao. Assim, o processo de gesto de riscos est em curso e evoluo. Esta seo enfatiza as boas prticas e a necessidade de uma avaliao de risco em curso e a avaliao e os fatores que levaro a um programa bem sucedido de gesto de risco. 5.1 Boas prticas de segurana O processo de avaliao de risco normalmente repetida pelo menos a cada trs anospara as agncias federais, como encomendados pela OMB Circular A-130. Contudo, a gesto de risco deve ser conduzido e integrado no SDLC para sistemas de TI, no porque obrigado por lei ou regulamento, mas porque uma boa prtica e apoia os objectivos de negcio da organizao ou misso.

Deve haver um cronograma especfico para a avaliao e mitigao de riscos da misso, mas o processo periodicamente realizada tambm deve ser suficientemente flexvel para permitir alteraes sempre que preciso, como grandes mudanas noambiente do sistema e processamento de TI devido a mudanas resultantes depolticas e novas tecnologias. 5.2 Chaves para o sucesso Um programa de gerenciamento bem sucedido risco contar com compromisso (1) gesto de topo, (2) o apoio e participao da equipe de TI (ver Seo 2.3), (3) a competncia da equipe de avaliao de risco, que deve ter a competncia para aplicar a metodologia de avaliao de risco para um determinado site e do sistema, identificar os riscos da misso, e fornecer o custo-efetivo salvaguardas que atendem s necessidades da organizao; (4) a sensibilizao e a cooperao dos membros da comunidade de usurios, que devem seguir os procedimentos e cumprir com os controles implementados para garantir a misso da sua organizao, e (5) uma avaliao contnua e avaliao dos riscos relacionados a TI de misso. 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 compreenso das caractersticas operacionais de uma organizao podem incluir o seguinte: Quem so os usurios vlidos? Qual a misso da organizao do usurio? O que o objetivo do sistema em relao misso? Qual a importncia do sistema para a misso da organizao do usurio? Qual o requisito do sistema disponibilidade? Que informao (tanto de entrada e sada) exigida pela organizao? Que informao gerada por, consumido por processados em armazenada e recuperada pelo sistema? Qual a importncia da informao para a misso da organizao do usurio? Quais so os caminhos do fluxo de informaes? Que tipos de informao so processados e armazenados no sistema (por exemplo, financeira, pessoal, pesquisa e desenvolvimento, assistncia mdica, comando e controle)? Qual a sensibilidade (ou classificao) nvel da informao? Que informaes tratadas por ou sobre o sistema no deve ser divulgado e para quem? Onde, especificamente, a informao processada e armazenada? Quais so os tipos de armazenamento de informao? Qual o impacto potencial sobre a organizao, se as informaes so divulgadas a pessoas no autorizadas? Quais so os requisitos para a disponibilidade de informaes e integridade? Qual o efeito sobre a misso da organizao, se o sistema ou as informaes no confivel? Quanto tempo ocioso do sistema a organizao pode tolerar? Como que este tempo de inatividade comparar com o tempo de reparo / recuperao mdia? O outro tratamento ou comunicaes opes podem acessar o usurio? Ser que um sistema de segurana ou mau funcionamento ou indisponibilidade resultado em ferimento ou morte? APENDICE B: ESBOO DA AMOSTRA DE RISCO RELATRIO DE AVALIAO RESUMO I. Introduo Objetivo. mbito da avaliao de riscos.

Descrever os componentes do sistema, elementos, usurios, locais de campo (se houver), e quaisquer outros detalhes sobre o sistema a ser considerado na avaliao. Desfazer edies II. Mtodo de Avaliao de Risco Descrever brevemente o mtodo utilizado para realizar a avaliao de risco, tais como: Os participantes. (por exemplo, os membros da equipe de avaliao de risco). A tcnica usada para coletar informaes. (por exemplo, o uso de ferramentas, questionrios). O desenvolvimento e a descrio da escala de risco. (por exemplo, uma 3 x 3, 4 x 4, ou 5 x 5 matriz nvel de risco). Desfazer edies III. Caracterizao do Sistema Caracterizar o sistema, incluindo hardware (servidor, roteador, switch), software (por exemplo, sistema de aplicao, operao protocolo), interfaces de sistema (por exemplo, link de comunicao), dados e usurios. Fornecer conectividade de entrada diagrama ou fluxograma de sada do sistema e para delinear o escopo deste esforo de avaliao de risco. IV. Declarao de ameaa Compilar e listar as potenciais ameaas de fontes e aes de ameaas associadas aplicveis ao sistema de avaliao. V. Resultados da Avaliao de Risco. Listar as observaes (vulnerabilidade / ameaa par). Cada observao deve incluir: Nmero de Observao e uma breve descrio de observao. (por exemplo, Observao 1: sistema de senhas de usurio pode ser adivinhado ou quebrado). A discusso sobre a ameaa de fonte e um par de vulnerabilidades. Identificao de controles de segurana existentes atenuantes. Probabilidade de discusso e avaliao. (por exemplo, a probabilidade, Alto Mdio ou Baixo). discusso Anlise de impacto e avaliao. (por exemplo, impacto, Alto Mdio ou Baixo). Classificao de Risco com base na matriz de risco de nvel. (por exemplo, Mdio, Alto ou nvel de risco baixo). Recomendado controles ou opes alternativas para reduzir o risco. VI. RESUMO Totalizar o nmero de observaes. Resumir as observaes, os nveis de risco associados, as recomendaes, e os comentrios em um formato de tabela para facilitar a implementao de controles recomendados durante o processo de mitigao de riscos. APENDICE C: TABELA APENDICE D: SIGLAS AES: padro de criptografia avanado. CSA: segurana informtica ato. DAA: designado aprovar autoridade. DAC: controle de acesso discricionrio. DES: Data Encryption Standard. FedCIRC: federal computador do centro de resposta a incidentes. FTP: File Transfer Protocol. ID: identificador. IPSEC: protocolo de segurana da internet. ISSO: informao oficial de segurana do sistema. TI: tecnologia da informao. ITL: laboratrio de tecnologia da informao MAC: controle de acesso obrigatrio. NIPC: centro nacional de proteo de infraestrutura.

NIST: Instituto Nacional de Padres e Tecnologia. OIG: escritrio do inspetor-geral. OMB: Escritrio de Administrao e Oramento. PC: computador pessoal. SDLC: sistema de ciclo de vida do desenvolvimento. SP: publicao especial. ST & E: teste de segurana e avaliao.

Anda mungkin juga menyukai