Gestão de Riscos

A crescente importância da TI para os processos de negócio de uma empresa trouxe em paralelo, também, um aumento de problemas de segurança em relação à informação. Assim, a necessidade das empresas em conhecer os riscos dos seus processos de negócio passou a constituir um fator estratégico para o seu sucesso. O papel de um processo de gestão de riscos em uma empresa é fundamental, pois protege os seus ativos de informação dos riscos relacionados à TI. Contudo, para que tal processo seja bem compreendido, alguns componentes devem ser esclarecidos, entre eles o que é risco.

Risco

Devido à amplitude da possibilidade da existência de riscos em uma empresa, defini-los tornou-se uma tarefa interessante, principalmente pela diversidade de definições existentes neste sentido. Entretanto algumas dessas definições podem ser consideradas como clássicas, pois suprem as necessidades de fundamentar este conceito. Acompanhemos, então, algumas delas.

Segundo a NIST Stoneburner, Goguen e Feringa (2002), risco é o impacto negativo da ação de uma vulnerabilidade, considerando tanto a probabilidade e o impacto da ocorrência, isto é, risco é a função que relaciona a probabilidade de uma determinada ameaça explorar uma vulnerabilidade em potencial e o impacto resultante desse evento adverso sobre a organização.

A ISO/IEC 27002 (2005) define risco como a possibilidade de um ativo estar sujeito a vulnerabilidades e incidentes (ameaças explorando essas vulnerabilidades), comprometendo a continuidade das atividades de uma organização (impacto).

Outra definição interessante é a apresentada por Coso (2004), onde ele relaciona eventos com riscos e oportunidades. Os eventos podem ter um impacto negativo, positivo, ou ambos. Eventos com um impacto negativo representam riscos que podem impedir a criação de valor ou reduzir o valor existente. Eventos com impacto positivo podem compensar os impactos negativos ou representar oportunidades. As oportunidades são as possibilidades de um evento ocorrer e afetar positivamente a realização dos objetivos, apoiar a criação de valor e de preservação.

A ISO/IEC 27005 (2008) define risco como o potencial de uma determinada ameaça explorar vulnerabilidades, proporcionando perdas ou danos a um ativo ou grupo, de forma direta ou indireta para a organização. Essa relação é apresentada na figura.

Riscos

Riscos

Por fim, Isaca (2009) considera que os eventos externos que podem incluir mudanças nas condições de mercado – novos concorrentes, a disponibilidade de novas tecnologias, por exemplo – representam um risco e/ou oportunidade para a empresa a que se referem.

Quando surgem oportunidades de mudanças na área de TI das empresas, o quadro do VAL IT, em IGTI, 2008, irá descrever melhor a forma de progresso, maximizando o retorno sobre o investimento (ROI). O resultado da avaliação da aplicação da TI, provavelmente, terá um impacto em alguns dos processos de TI e/ou sobre a contribuição para os processos de TI. Logo, os resultados dos processos de gestão de risco e gestão de valor serão considerados pela gestão de processos, conforme apresentado na figura.

Posicionamento entre COBIT, VAL IT e Risk IT

Posicionamento entre COBIT, VAL IT e Risk IT

Trabalhar com TI tem os seus riscos, isto porque as empresas agregam valor aos seus processos de negócio com a aplicação dos recursos da TI. Em Icasa (2009), o risco do negócio está associado ao uso, propriedade, operação, participação, os quais influenciam na adoção da TI em uma empresa. E

é assim, por se tratar de eventos relacionados à TI, os quais podem ter impacto no negócio, ocorrendo com frequência e magnitude incerta, criando desafios na busca pela empresa de suas metas e objetivos estratégicos.

Logo, os riscos de TI não estão limitados somente aos ativos de informação, mas também a atrasos na liberação de projetos, arquitetura obsoleta, problemas na liberação de serviços em TI, entre outros, conforme visualizado na figura (ICASA, 2009).

Categorias dos riscos de TI

Categorias dos riscos de TI

Conceitos de Gestão de Riscos

Segundo Stoneburner, Goguen e Feringa (2002), a gestão de riscos é o processo de identificação dos riscos, avaliação de risco e tomada de medidas (tratamento do risco) para reduzir o risco a um nível aceitável. O objetivo da gestão de risco é permitir que a organização consiga realizar as suas tarefas, isto é, manter ativos os seus processos de negócio, através de uma boa segurança para os sistemas de TI, responsáveis em armazenar, processar e transmitir as suas informações.

Logo, pode-se dizer que o processo de gestão de riscos permite que os gerentes de TI busquem equilíbrio entre os custos operacionais e econômicos das medidas de proteção contra os riscos, possibilitando assim maiores ganhos para a organização, dando um maior retorno sobre o investimento (ROI).

Sendo assim, esta unidade estará apresentando a metodologia desenvolvida por Stoneburner, Goguen e Feringa (2002) para realizar o processo de gestão de risco, isto é, o NIST 800-30. Outras metodologias serão apresentadas, inclusive o processo de gestão de risco no formato da ISO 27005:2008 e as diretrizes de sua implementação no formato da ISO 31000:2009.

Processos da Gestão de Riscos

Segundo Stoneburner, Goguen e Feringa (2002), a gestão dos riscos é composta basicamente por três processos:

1. avaliação dos riscos – este processo inclui a identificação e avaliação dos riscos, o impacto causado pelos riscos e as recomendações de medidas para a redução de riscos;

2. mitigação de riscos – este processo trata da priorização, implementação e manutenção das medidas adequadas de redução do risco, com base no processo de avaliação de risco;

3. manutenção da avaliação – é onde se discute o processo de avaliação contínua dos riscos com base em parâmetros necessários a sua execução.

Avaliação de Riscos

O processo de avaliação de riscos determina a extensão das ameaças em potencial e o risco associado ao sistema computacional da organização. Este processo ajuda a identificar os controles adequados para a redução ou eliminação dos riscos durante o processo de mitigar riscos.

Importante: Para determinar a probabilidade de ameaças ao sistema computacional, devem-se analisar também as vulnerabilidades e os controles existentes em relação a elas.

O impacto da efetivação dessas ameaças refere-se ao tamanho do problema que isso trará (ataque). Vale a pena ressaltar que o nível de impacto estará diretamente relacionado ao grau de criticidade dos processos de negócio, serviços de TI e ativos da empresa que sofrê-lo.

A NIST 800-30 divide a avaliação de riscos em nove etapas, conforme apresentado na figura.

Processo de avaliação de riscos

Processo de avaliação de riscos

Na sequência, encontra-se, portanto, a descrição de cada uma destas etapas.

1a Etapa: Caracterização do sistema

Esta etapa tem como objetivo definir o escopo de abrangência da avaliação de riscos, isto é, quais elementos do sistema computacional serão analisados durante o processo de avaliação de riscos. Neste momento, também são estabelecidos os limites de autorizações quanto à realização de operações no sistema, além de serem providas informações relacionadas ao sistema e necessárias à sua caracterização, por exemplo, os dispositivos de hardware, software, links, entre outros.

O sucesso desta etapa está baseado nas informações que são coletadas. A combinação de técnicas de coleta de informação é uma estratégia para se alcançar o objetivo final da etapa: ter a maior quantidade de informações necessárias sobre o sistema computacional, de forma que se assegure a real caracterização do mesmo. Algumas técnicas podem ser aplicadas para a realização adequada de tal coleta. São apresentadas na sequência.

a. Questionário

Esta técnica é talvez a mais utilizada pelo universo dos profissionais que trabalham com segurança da informação, principalmente na fase de implantação do processo de gestão de riscos. O questionário foca normalmente questões relativas aos controles operacionais e de gerenciamento. É aplicado tanto em pessoas que trabalham no nível operacional quanto em pessoas que trabalham no nível gerencial da empresa. O questionário pode ser distribuído pessoalmente ou realizado via site. Alguns exemplos de perguntas que podem fazer parte do mesmo:

  1. Quantos são os usuários válidos no seu sistema?
  2. Qual é o negócio ou linhas de negócio da sua organização?
  3. Qual é o propósito do seu sistema computacional em relação ao negócio da sua empresa?

b. Análise de documentos

Esta estratégia tem como objetivo analisar os documentos referentes ao sistema computacional, políticas (diretrizes, regimentos, etc.), documentos relacionados com a segurança da informação (relatórios de avaliação de risco, política de segurança, etc.).

c. Uso de ferramentas de varredura

São métodos proativos que podem ser usados na coleta de informações do sistema (topologia da rede, identificação de serviços executados na rede, etc.).

Encerradas todas as atividades desta etapa, espera-se ter um mapa detalhado das características do sistema computacional, bem como definido o escopo de abrangência do trabalho a ser realizado pela segurança da informação.

2a Etapa: Identificação das Ameaças

Antes de discutir esta etapa, deve-se definir o que vem a ser uma ameaça na área da informação. Alguns afirmam que ameaça é tudo aquilo que tem potencial para causar danos aos ativos de informação (ex: invasão, indisponibilidade de serviços, etc.). Contudo Stoneburner, Goguen e Feringa (2002) definem ameaça na NIST 800-30 como o potencial de uma “origem da ameaça” explorar, de forma intencional, ou não, uma vulnerabilidade, ou agir sobre ela. Aqui, nesta área, isto é definido como qualquer circunstância ou evento com potencial para causar danos a um sistema computacional.

Uma ameaça é considerada uma preocupação quando realmente puder ser concretizada (ataque), ou agir sobre uma vulnerabilidade (por exemplo, queda de energia).

Importante: Entretanto pode-se afirmar que a origem da ameaça não estará presente quando não existir vulnerabilidade que possa ser explorada. Com isso, para determinar a probabilidade de uma ameaça ocorrer, deve ser levada em consideração a origem da ameaça. Do mesmo modo, as vulnerabilidades em potencial e os controles existentes.

Identificação da origem da ameaça

O objetivo desta etapa é identificar as origens da ameaça em potencial e listar todas aquelas que se aplicam ao sistema computacional para uma avaliação. As origens das ameaças podem ser naturais (incêndio, enchente, tempestades elétricas, etc.), humanas (atos intencionais – ataques, negligência, erros, etc.) ou do ambiente (falhas de energia, poluição, etc.).

Entretanto não se pode esquecer que, durante a avaliação das origens das ameaças, independente do tipo de ameaça, deve sempre ser levado em consideração o potencial de danos que elas possam causar ao sistema computacional.

Motivação e ações das ameaças

A motivação e os recursos para a execução de um ataque tornam os humanos uma origem da ameaça em potencial. Mapeada a motivação, os tipos de ameaças e as ações por elas executadas, tem-se uma visão dos possíveis ataques que a organização poderá vir a sofrer de ações vindas de outros humanos e os danos que os mesmo irão causar. A tabela 1 apresenta um conjunto de informações coletadas durante a etapa de identificação das ameaças que tem origem no homem.

Tabela 1: Ameaças humanas

Ameaças humanas

Ao término desta etapa, deve-se ter composto um documento contendo a lista das origens das ameaças que poderão explorar as vulnerabilidades do sistema computacional.

3a Etapa: Identificação das vulnerabilidades

O objetivo desta etapa é desenvolver uma lista com todas as vulnerabilidades do sistema que possam ser exploradas pelas origens das ameaças. Os métodos recomendados para identificar as vulnerabilidades do sistema são o uso da origem da vulnerabilidade, executar testes de segurança no sistema computacional e desenvolver uma lista de verificação (checklist) com as necessidades de segurança.

Origem das vulnerabilidades

As vulnerabilidades relacionadas ao ambiente computacional podem ser identificadas através das técnicas de coleta de informações (entrevistas, ferramentas de varredura) a serem aplicadas aos técnicos da área de TI. Informações de fornecedores de produtos também são essenciais nessa tarefa, pois fornecem informações quanto a falhas, atualizações e outras medidas que possam minimizar as vulnerabilidades do sistema. Outras fontes de informação sobre vulnerabilidades podem ser utilizadas, como BID <www.securityfocus.com. br>, CAN/CEV <www.mitre.org>, entre outras.

Testando a segurança do sistema

Para atender esse item, são utilizados métodos proativos que realizam testes sobre a segurança do sistema. Veja na sequência quais são esses métodos.

Ferramenta de varredura – trata-se de ferramentas de varredura (nmap) aplicadas a máquinas (estações de trabalho, servidores, etc.) e/ou a rede de computadores, com o objetivo de verificar, por exemplo, os serviços que neles estão sendo executados.

Teste de segurança de Análise de Vulnerabilidades – é o procedimento para identificar potenciais vulnerabilidades, normalmente executadas a partir de ferramentas automatizadas (Nessus, Retina), correlacionando potenciais vulnerabilidades com registros de segurança – BID e CAN/CEV, por exemplo.

Teste de invasão (pen teste) – são testes de segurança que buscam ganhar acesso ao sistema (de forma pontual) ou processo que combina vários tipos de teste de segurança, como fingerprint, footprint, port scanner, varreduras de vulnerabilidades, etc. Logo, o teste de invasão (pen test) pode ser definido como o processo de identificar, enumerar e buscar explorar vulnerabilidades, utilizando um conjunto de variadas técnicas dentro de uma metodologia objetiva que simula, de forma controlada, a técnica operacional de um invasor.

Desenvolver uma lista de verificação (checklist)

A lista de verificação deverá conter os padrões básicos de segurança que podem ser usados para, de forma sistêmica, avaliar e identificar as vulnerabilidades dos ativos, procedimentos não automatizados, processos e informações transmitidas. Todos esses relacionados com o sistema computacional nas áreas de gerenciamento, operacional e técnico, conforme apresentado na tabela 2.

Tabela 2 – Critérios de segurança para o check list da verificação da segurança existente

Critérios de segurança para o check list da verificação da segurança existente

Ao fim desta etapa, será produzida uma lista de vulnerabilidades que possam ser exploradas pelas origens das ameaças, conforme apresentado na tabela 3.

Tabela 3: Vulnerabilidades

Vulnerabilidades

4a Etapa: Análise dos Controles

Esta etapa busca analisar os controles existentes (implementados) ou planejados para serem implantados. Tais controles têm como objetivo minimizar a probabilidade das ameaças explorarem as vulnerabilidades do sistema. Por exemplo, a probabilidade de uma vulnerabilidade ser explorada é baixa quando

a origem da sua ameaça possui pouco interesse naquela, pouca capacidade de explorá-la ou se os controles implantados para protegê-la são eficazes, isto é, podem eliminar ou reduzir a magnitude do dano.

Controles

Os controles de segurança podem fazer uso de aspectos técnicos, ou não. Os controles chamados técnicos (mecanismos de segurança – mecanismos de controle de acesso, mecanismos de identificação e autenticação, mecanismos de criptografia) são aplicados diretamente em hardware ou software. Já os controles que não são técnicos consistem na gestão e controles operacionais, tais como políticas de segurança, procedimentos operacionais e de pessoal, segurança física e segurança ambiental.

Os controles, sejam eles técnicos, ou não, também podem ser divididos em duas categorias:

prevenção – são controles que visam evitar as tentativas de violar a política de segurança. São controles focados no controle de acesso, criptografia e autenticação;

detecção – são controles que têm como objetivo informar quando ocorre alguma violação ou tentativa de violação da política de segurança. São controles focados na detecção de intrusos, auditorias, por exemplo.

Técnica de Análise de Controle

A lista de verificação de requisitos de segurança, citada anteriormente, é uma das referências para se verificar a aplicação das regras de segurança no sistema computacional.

O resultado desta etapa é uma lista de controles existentes ou previstos, bem como a sua eficiência quanto à redução da probabilidade de uma origem da ameaça ter sucesso na exploração das vulnerabilidades.

Etapa 5 – Determinação da probabilidade

Para determinar o nível da probabilidade de uma vulnerabilidade ser explorada, alguns fatores devem ser levados em consideração:

• a motivação e capacidade da fonte da ameaça; • a natureza da vulnerabilidade; e, • a existência e eficiência dos atuais controles.

A tabela 4 apresenta um exemplo de três níveis de probabilidade com as suas respectivas descrições, onde se pode determinar a probabilidade da ameaça ter, ou não, sucesso em explorar uma vulnerabilidade.

Tabela 4: Probabilidade

Probabilidade

Etapa 6: Análise de impacto

O objetivo desta etapa é determinar o impacto negativo resultante de um ataque bem-sucedido, isto é, o sucesso de uma ameaça explorando uma vulnerabilidade. Entretanto, para que a análise de impacto possa ser realizada, algumas informações são necessárias. São obtidas, em sua maioria, através de documentação existente, tal como o relatório de análise de impacto ou relatório da avaliação de criticidade dos ativos. Este apresenta:

• a tarefa a ser realizada pelo sistema (os processos realizados pelo sistema de TI);

• o nível de criticidade do sistema e dos dados (a importância para a organização);

• o nível de sensibilidade dos dados e do sistema a riscos.

Uma das tarefas da análise de impacto dos ataques aos ativos de informação de uma organização chama-se BIA (Business Impact Analysis). Trata-se de um método que prioriza os níveis de impacto associados ao comprometimento de ativos de informação da organização, com base em uma avaliação qualitativa ou quantitativa da sensibilidade e criticidade desses ativos.

Importante: A avaliação da criticidade de um ativo de informação irá identificar e priorizar os ativos (roteador de borda, sistema corporativo, etc.) que são sensíveis e críticos a riscos na execução das tarefas mais críticas da organização.

O método BIA é normalmente utilizado para a especificação de Planos de Continuidade de Negócios ou para proteger somente os sistemas e informações mais importantes da organização.

Vale a pena ressaltar que, independentemente do método utilizado para determinar o grau de sensibilidade de um sistema de TI e dos seus dados, os donos do sistema e das informações são os únicos responsáveis em esclarecer o nível de impacto dos ataques a seu sistema de informação. Por conseguinte, a abordagem mais adequada na realização da análise de impacto é a técnica de entrevista com o dono do sistema e das informações.

Sendo assim, o impacto negativo de um evento de segurança pode ser descrito em termos de perda ou degradação de qualquer uma das propriedades de segurança (confidencialidade, integridade e disponibilidade), ou então, pela combinação delas entre si.

Medindo o impacto

Quando se realiza uma análise de impacto, deve-se levar em consideração as vantagens e desvantagens de se aplicarem avaliações quantitativas ou qualitativas. Se for realizar uma comparação entre elas, a principal vantagem de se usar uma avaliação qualitativa é que ela prioriza os riscos e identifica áreas de melhoria imediata na resolução das vulnerabilidades. Porém a desvantagem é que ela não prevê medidas específicas quantificáveis da magnitude dos impactos, dificultando uma análise custo-benefício da aplicação de controles, ou não.

No caso de análise de impacto quantitativa, a vantagem está em fornecer uma medida da magnitude dos impactos, podendo ser utilizada na avaliação custo-benefício da aplicação de controles recomendados, ou não. Porém, a desvantagem está na dependência da utilização de intervalos numéricos para expressar a medida, o que pode não tornar bem claro o resultado da análise de impacto, forçando uma interpretação qualitativa. Outros fatores, muitas vezes, devem ser considerados para determinar a magnitude do impacto.

Sendo assim, pode-se dizer que alguns impactos, que são tangíveis, podem ser medidos de forma quantitativa, com valores de perda da receita, o custo da reparação de um sistema, ou o nível de esforço necessário para corrigir problemas causados por um ataque. Contudo impactos como perda de confiança, imagem ou credibilidade não podem ser medidos por meio de valores específicos. A avaliação qualitativa é aplicada, descrevendo o impacto como alto, médio e baixo, conforme apresentado na tabela 5.

Impacto

Etapa 7: Avaliar o risco

Esta etapa tem como objetivo avaliar o nível de risco existente para o sistema de TI. A avaliação de risco de uma determinada ameaça específica para cada uma das vulnerabilidades é calculada com base nos seguintes itens:

• a probabilidade de uma fonte de ameaça explorar uma vulnerabilidade;

• o tamanho do impacto, caso um ataque tenha sucesso; e

• a adequação dos controles de segurança existentes ou planejados para minimizar o risco.

Calcular o Risco

Para que o risco possa ser medido, deve-se criar uma matriz de risco, conforme apresentado na figura 5, com base em uma escala de risco. A função de cálculo do risco deve ser especificada pelo responsável. A NIST 800-30, Stoneburner, Goguen e Feringa (2002), apresenta um exemplo de função de cálculo de risco.

Exemplo: Multiplicam-se os valores atribuídos para a probabilidade de ameaças pelo valor do impacto ameaça.

F = Probabilidade X Impacto

A granularidade dos níveis de probabilidade e impacto pode variar em conformidade com a necessidade da organização. Os valores atribuídos para probabilidade e impacto são:

• a probabilidade atribuída para cada nível é de: 1,0 para a alto; de 0,5 para médio, 0,1 para baixo;

• o valor atribuído para cada nível de impacto é de: 100 para a alta, 50 para médio e 10 para baixa.

Acompanhe a ilustração deste exemplo na figura a seguir.

 

Matriz de risco

Matriz de risco

Calculado o risco, com os seus respectivos níveis, a seguir será apresentada uma tabela com a descrição de cada nível e as ações necessárias.

Tabela 6: Riscos

Tabela de Riscos

Tabela de Riscos

Etapa 8: Recomendações

Esta etapa tem como objetivo propiciar uma lista com os controles de segurança sugeridos para que se possam minimizar os riscos relacionados com a organização até um nível considerado aceitável por sua alta direção. Vale a pena lembrar que os controles sugeridos são os frutos do processo de avaliação de risco, os quais também levaram em consideração, durante a escolha, os seguintes fatores: eficácia dos controles, por exemplo, a compatibilidade com o sistema; legislação

e regulamentação; impacto operacional, por exemplo, o desempenho do sistema; segurança e confiabilidade; e, por fim, o custo, este que também é um fator bastante relevante, pois está relacionado com uma análise custo-benefício.

Etapa 9: Documentação

Esta etapa tem como objetivo gerar um relatório do processo de avaliação de riscos. Nele devem-se anotar as ameaças e vulnerabilidades, o cálculo do risco e as recomendações de controles de segurança a serem implementados.

O relatório da avaliação de riscos pode seguir este sumário a seguir.

1. Introdução

A introdução do documento poderá apresentar o propósito do trabalho, o escopo de sua abrangência, bem como descrever os componentes do sistema, usuários, entre outros detalhes necessários à realização da avaliação de riscos.

2. Abordagem da avaliação de riscos

Uma breve descrição de como foi realizada a avaliação de riscos, citando aspectos como os nomes dos membros da equipe, as técnicas usadas para a coleta de informações e o modo como foi realizada a análise de riscos e a descrição de cada risco.

3. Caracterização do sistema

Faça uma explanação das características do sistema (hardware, software, links, usuários, etc.). A topologia da rede e o fluxo de entrada e saída de dados são elementos necessários para delinear o esforço da avaliação de riscos.

4. Declaração de ameaças

Apresentação da relação com todas as potenciais origens das ameaças.

5. Resultados da avaliação de risco

Montar uma tabela com os ativos relacionados com suas ameaças e sua probabilidade, vulnerabilidades, impacto, cálculo do risco, controles sugeridos, etc.

6. Resumo

Faça um resumo com todas as observações pertinentes do trabalho realizado. Uma sugestão seria a utilização de gráficos relacionando os controles aplicados em relação aos diversos tipos de ameaça.

Minimizar (Mitigar) Riscos

O processo de mitigar riscos está relacionado à priorização, avaliação e implementação dos controles de segurança recomendados na avaliação de risco. Normalmente, a estratégia selecionada para minimizar riscos leva em consideração a seguinte premissa: o controle de segurança a ser implantado deverá ser o mais adequado para conseguir reduzir o risco ao nível aceitável, com o menor custo e proporcionando o menor impacto negativo aos recursos e funcionalidades da organização.

O processo de mitigação de riscos pode ser tratado de seis formas. Analise-as.

  1. Assunção do risco – aceita o risco e continua a operar o sistema ou a implementar controles para manter o risco dentro de um nível aceitável.
  2. Evitação do risco – o risco é evitado, eliminando a sua causa ou consequência (evitar a reinicialização do servidor, usando Ctrl Alt Del).
  3. Limitação do risco – é realizado, implementando controles que reduzam o impacto negativo do ataque (controles de detecção).
  4. Planejamento de Riscos – gerencia o risco através do desenvolvimento de um plano de mitigação de risco que priorize, implemente e mantenha os controles de segurança.
  5. Pesquisa e Reconhecimento – visa reduzir o risco de perda do reconhecimento da vulnerabilidade ou falha, e pesquisa controles de segurança para corrigir a vulnerabilidade.
  6. Transferência de risco – transfere o risco, usando outras opções com o objetivo de compensar a perda (ex: aquisição de seguro).

A escolha de uma dessas formas tem de levar em consideração os objetivos e as tarefas da organização. Outra questão a ser pensada para essa escolha é quais riscos serão tratados pela organização. Tratar todos eles é quase que inviável, mas um processo de avaliação, priorizando aqueles que trarão um maior impacto negativo sobre a organização seria uma estratégia interessante para determinar que riscos devem ser tratados pela mesma.

Importante: Contudo não se esqueça da premissa de que o ideal é o controle mais eficiente, mais barato e de menor impacto.

Definida a forma de tratamento, conhecidos os riscos e os controles recomendados, deve-se definir em quais circunstâncias ou quando serão implantados os controles de segurança.

A figura 6 apresenta uma sequência de atos que são usados durante o processo de decisão sobre se um risco é, ou não, aceitável. Os pontos do fluxograma que possuem a palavra sim são os pontos de acesso para a implementação dos controles.

Pontos de ação para mitigação de riscos

Pontos de ação para mitigação de riscos

De acordo com esta figura, percebemos que, quando o sistema de informação:

está vulnerável – deve-se implementar técnicas confiáveis para reduzir a probabilidade de uma vulnerabilidade ser explorada.

explora a vulnerabilidade – deve-se fazer defesa em profundidade, com várias barreiras e uso de controles administrativos para minimizar o risco ou preveni-lo.

E, ainda:

se o custo do atacante for maior que o ganho – fazer uso de controles para reduzir a motivação do atacante, aumentando o custo do atacante (usar controles do sistema para limitar acesso do usuário);

se a perda for maior que o limite – aplicar mecanismos que minimizem a extensão do ataque, reduzindo, assim, a perda.

Implementação de controles

Determinado quando os controles serão implementados, serão descritas a seguir as etapas necessárias para implantá-los, como pode ser visualizado na figura.

Atividades para implementar os controles

Atividades para implementar os controles

Conforme pode-se verificar na figura anterior, a implantação dos controles de segurança tem sete etapas para sua consumação. Na sequência, encontra-se a descrição de cada uma delas.

Etapa 1 – Priorizar ações

As ações são priorizadas com base nos riscos apontados pelo relatório de avaliação de risco. A saída é um novo relatório, este com as ações em ordem decrescente de prioridade a serem realizadas em relação a esses riscos.

Etapa 2 – Avaliar as opções de controle recomendadas

São verificadas a compatibilidade e a eficiência do controle sugerido. O objetivo é selecionar o melhor controle para a situação de risco que a empresa prioriza combater.

Etapa 3 – Análise da relação custo/benefício

O objetivo desta etapa é relacionar o custo de cada controle com o benefício ou falta de benefícios da sua implementação.

Etapa 4 – Seleção de Controle

Com base no resultado da etapa custo/benefício, devem ser escolhidos os controles que tragam maior benefício ao menor custo.

Etapa 5 – Atribuição de responsabilidade

O objetivo desta etapa é identificar as pessoas com competência para implantar o controle selecionado, gerando um relatório com as indicações das atribuições de cada uma das pessoas que farão parte desta etapa.

Etapa 6 – Desenvolvimento do plano de implementação

O plano de implementação deverá conter os riscos e seus respectivos níveis; controles recomendados; ações priorizadas; controles selecionados; recursos necessários para a implementação do controle; lista dos responsáveis; data de início da implementação e os requisitos de manutenção.

Etapa 7 – Implementar os controles selecionados

Os controles implementados deverão reduzir o risco, deixando apenas um risco residual.

Análise Custo/Benefício

A análise custo/benefício pode ser qualitativa ou quantitativa, tendo como objetivo demonstrar o custo de implementação dos controles, o qual pode ser justificado pela redução do nível de risco. Esta análise, quando propõe novos controles ou deseja reforçar os já existentes, engloba os seguintes fatores:

• o impacto da implementação do controle;

• o impacto da não implementação do controle;

• a estimativa dos custos de implementação: hardware, software, custo adicional de políticas e procedimentos; redução da capacidade operacional do sistema com a inclusão de mais segurança; treinamento, manutenção e contratação de pessoal extra para a implementação);

• avaliar os custos de implementação e os benefícios (impacto) com o objetivo de determinar a importância para a organização de implementação dos controles.

Exemplo de Análise Custo/Benefício

Suponha que um sistema crítico de uma empresa, o qual manipula informações sensíveis, entre outros pontos determinantes para o sucesso da empresa, não possua um módulo de auditoria.

Importante: A análise custo/benefício irá tentar provar que o módulo de auditoria é vital para o sistema.

A função de auditoria permitirá que o administrador do sistema monitore as atividades dos seus usuários. Entretanto o desempenho desses usuários sofrerá um impacto negativo, que reduzirá a produtividade dos mesmos. A sua implementação necessitará de recursos adicionais. Os benefícios adquiridos com a implementação desta auditoria não são tangíveis.

O impacto de não implementar o recurso de auditoria será o de que as atividades dos usuários do sistema e as prováveis violações não poderão ser monitoradas e controladas. A segurança não poderá ser maximizada para proteger os dados confidenciais da organização e da missão. Aqui, os prejuízos por não se implementar essa auditoria também não são tangíveis.

Exemplo: Cálculo que pode ser feito para estimar o custo estimado para implantar o módulo de auditoria:

a. custo de desenvolvimento – R$ XXXX;

b. custo de pessoal adicional para executar a auditoria e arquivá-la – R$ XXXX;

c. treinamento – R$ XXXX; d. gerar relatórios (uso de software) – R$ XXXX; e. manutenção dos dados da auditoria – R$ XXXX; f. custo de manutenção do módulo – R$ XXXX.

Total estimado – R$ XXXXXXX.

Com base no risco aceitável, o impacto do controle ser incluído ou não pode então ser avaliado do seguinte modo:

• se o controle reduz o risco mais que o necessário, veja se existe uma alternativa mais barata;

• se o controle irá custar mais que a redução do risco, busque outra opção;

• se o controle não irá reduzir o risco suficientemente, pesquise mais opções;

• se o controle oferece uma redução de risco adequada, a um custo adequado, faça uso do mesmo.

Logo, de posse de todas essas informações, a decisão de implementar, ou não, o controle fica a cargo da alta direção da organização.

Risco Residual

As organizações podem analisar o quanto o risco foi reduzido, após a implementação dos novos controles, levando em consideração os parâmetros de redução da probabilidade da ameaça ou da redução do impacto. Isso porque os controles implementados mitigam o risco pela eliminação de algumas vulnerabilidades do sistema, ou então, pela redução da capacidade e motivação da origem da ameaça (tornando o acesso mais difícil ao invasor), ou, ainda, pela redução da amplitude do impacto negativo para a organização. A figura deixa clara a relação entre a implementação de controles e o risco residual.

Controles implementados e risco residual

Controles implementados e risco residual

Referências

ISACA. The Risk IT Framework. Local: ? Ed. ISACA, 2009.

STONEBURNER, Gary; GOGUEN, Alice e FERINGA, Alexis. NIST SP 800-30 Risk management guide for information technology systems. Local: ? Ed.: NIST, 2002.

ISO/IEC 27002 (2005): Information technology – Security techniques – Code of practice for information security management – Redesignation of ISO/IEC 17799:2005

ISO/IEC 27005 (2008) Information technology – Security techniques – Information security risk management (draft).

COSO (2004). Enterprise Risk Management – Integrated Framework. Ed.: Committee of Sponsoring Organizations of the Treadway Commission.

Autor: Ms. Luiz Otávio Botelho Lento

Sou bacharel em Sistemas de Informação pela Estácio de Sá (Alagoas), especialista em Gestão Estratégica da Tecnologia da Informação pela Univ. Gama Filho (UGF) e pós-graduando em Gestão da Segurança da Informação pela Univ. do Sul de Santa Catarina (UNISUL). Certificações que possuo: EC-Council CEH, CompTIA (Security+, CySA+ e Pentest+), EXIN (EHF e ISO 27001), MCSO, MCRM, ITIL v3. Tenho interesse por todas as áreas da informática, mas em especial em Gestão e Governança de TI, Segurança da Informação e Ethical Hacking.

8 Responses to “Gestão de Riscos”

  1. paula tasca disse:

    Oi diego tudo bem ?

    preciso medir qual o valor da importancia de risco, do risco residual e a criticidade do risco residual para um nivel de mitigação preconizado em 85. voce consegye me ajudar?

    • Diego Macêdo disse:

      Você precisa saber quais são as métricas que você quer usar para calcular seu risco, o valor do seu controle sobre o risco e ver o quanto isso mitiga no risco. O que sobrar é seu risco residual.

  2. Francis Cristiano Sobrinho disse:

    Parabéns Diego, seu artigo está muito bem embasado e estruturado. Por acaso teria algum sobre VAL IT para compartilhar? Abraços.

  3. Victor dos santos disse:

    Gostei muito deste tema quero fazer um trabalho de gestão de risco em ti para empresa onde eu trabalho

  4. Edson Luiz disse:

    Esse site é muito completo, eu estou fazendo Sistema de Informação e pretendo seguir carreira em segurança da informação. abraços!!!

  5. Uendel Santos Batista disse:

    Muito bom o artigo, parabéns cara!

Deixe um comentário

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