Proposta de implementação da Análise de Risco em um Projeto de implantação da Segurança da Informação

Prévia do material em texto

Proposta de implementação da Análise de Risco em um 
Projeto de implantação da Segurança da Informação 
Maria Cláudia Santiago Hampshire, Cláudio Tomohide Tomimura 
Centro Tecnológico da Marinha em São Paulo (CTMSP) – Av. Prof. Lineu Prestes, 
2468 – Cidade Universitária – São Paulo – SP - Brasil 
 
claudia@ctmsp.mar.mil.br , claudio@ctmsp.mar.mil.br 
Abstract. This paper presents aspects related in carrying out a Security 
Information Project in Organisations . Risk Analysis implememtation is also 
discussed, as a crucial tool in this process, to identify and handle the 
vulnerabilities found in the institution, helping this way, the project to be a 
foolproof project. 
Resumo. Este artigo apresenta aspectos da necessidade da implantação de um 
projeto de Gestão de Segurança da Informação nas Organizações. É também 
discutida a implantação da Análise de Risco como ferramenta importante 
neste processo para a identificação e tratamento das vulnerabilidades 
encontradas na organização, tornando o projeto eficaz. 
1. Introdução 
A informação é um ativo de valor que deve ser protegido. Este reconhecimento criou a 
necessidade de implantação de projetos de Gestão de Segurança da Informação nas 
organizações. Todo projeto gera uma mudança, seja ela um novo produto ou uma nova 
forma de produzir um produto existente, e neste caso, tem trazido conseqüências 
relevantes, sejam elas administrativas, técnicas ou financeiras. 
 Fatores críticos de sucesso para este projeto estão relacionados com a definição 
de uma política de segurança, objetivos e atividades, alinhados com os objetivos do 
negócio. A política de segurança necessita ser divulgada e entendida por todos na 
Organização. A cultura organizacional deve ser respeitada. O bom entendimento dos 
requisitos de segurança, a avaliação de risco e seu gerenciamento, além do envolvimento 
e comprometimento da direção da Organização, são imprescindíveis no estabelecimento 
de uma política de segurança adequada. 
 A necessidade de estabelecer a segurança das informações tem levado a 
aproximação do profissional de TI com o profissional ligado à atividade fim da 
Organização. Desta forma, o profissional de TI deixa de ter apenas perfil técnico e passa 
a ter um perfil mais abrangente obrigando-o a ser capaz de entender o negócio, analisar 
formas de demonstrar o retorno do investimento, viabilizar aplicações e reduzir o risco. 
Outra constatação, é a necessidade da ligação deste profissional com a direção, 
determinada pela característica do projeto, cujo produto, muitas vezes é a adoção de 
ações normativas além da política de segurança. A gestão de segurança como um 
fundamento de gestão de negócio, transcende os aspectos meramente tecnológicos. 
 
 
 
 De acordo com a NBR ISO/IEC 17799:2001, existem três fontes para se 
estabelecer os requisitos de segurança: a primeira, avaliação de riscos dos ativos da 
organização; a segunda, é a legislação vigente, os estatutos, a regulamentação e as 
cláusulas contratuais que a organização, seus parceiros, contratados e prestadores de 
serviços têm que atender; e a terceira, é o conjunto particular de princípios, objetivos e 
requisitos para o processamento da informação que a Organização tem que desenvolver 
para apoiar suas operações. 
2. Implantação do Projeto de Gestão de Segurança da Informação 
O ciclo de vida para se implantar um Projeto de Gestão de Segurança da Informação, 
como qualquer outro projeto, é composto por um conjunto de fases: iniciar, planejar, 
executar, controlar e encerrar. Cada uma destas fases é caracterizada por gerar um 
produto tangível e verificável. 
Primeira fase do ciclo de vida do projeto: Iniciação. 
Nesta etapa, é necessário determinar a especificação do produto, elaborar um plano 
estratégico, estabelecer critérios de seleção e levantar o histórico relativo a evoluções do 
negócio e vulnerabilidades técnicas e organizacionais. Para tal, é essencial um 
mapeamento da Segurança. Esta identificação das vulnerabilidades pode ser realizada 
utilizando-se como ferramenta o diagrama de causa e efeito (figura 1.). 
 
QUAIS OS
PRINCIPAIS
VULNERABILIDADES
ORGANIZACIONAIS?
Vulnerabilidades de
Recursos Humanos
Vulnerabilidades
Administrativas
Vulnerabilidades
Tecnológicas
Falta de Conhecimento
Falta de
Treinamento
Falta de
InteresseFalta dePreocupação
Medidas de controle individual de informações inadequadas
Backup
Inadequado
Controle inadequado
de material sigiloso
Uso indevido
de e-mails
Descarte Inadequado
de Informações Falta de Firewallpara PC-Individual
Ausência de
Protetores
de Tela
Controle de Senhas
Deficiente
Falta de atualização de
Ant-virus
Falta de atualização de
Sistema Operacional
Ausência de auditorias
Internas
Ausência de Plano Estratégico de
Informações
Ausência de Metas Claras quanto
à Segurança de Informações
Composição Inadequada do Conselho de
Segurança de Informações
Ausência de Gerenciamento de Riscos
Ausência de Métricas de Segurança
Ausência de Históricos de Tentativas
de Obtenção de Informações
Falta de Cultura de Segurança
Falta de Crônica de Recursos
Rede corporativa insegura
Hardware
Servidores
obsoletosFirewall
obsoletoDescontrole
de periféricos e
mídias
Pen-driver
Hand-held
Celular
CD, CD-RW
Gravador de CD
SoftwareSistemas
 operacionais,
Browsers e Programas de E-mail
Inúmeras
Versões
Falta de
Atualizações
Descontrole
de Senhas
Pirataria
Cabeamento,
Roteadores, Hubs e
Switchs
Ataques
Virus Worms
Ataques ostensivos
DNS
Espionagem
Cavalos de
Tróia Backdoors
Key-loggers
Sniffers
Hackers
Vulnerabilidades
Físicas
Redes Segregadas e Salas de Projeto
Pouco
uso de
criptografia
Pouco
uso de
criptografia
Controle de
acesso inadequado
Falta de
Segurança
Quanto à Incêndio
 
Figura 1. Diagrama causa e efeito: Identificação das Vulnerabilidades da Organização 
 
 
 
 Assim, é possível definir um plano de ação corporativo alinhado com os 
objetivos da direção, obtendo-se o cenário de grau de segurança desejado a alcançar. A 
identificação das vulnerabilidades, ameaças e riscos, ajuda a priorizar ações de 
segurança, podendo ajudar na confecção do WBS, definição dos produtos, e subsidiar a 
implantação de controles eficazes posteriormente. 
 Segunda fase do ciclo de vida do projeto: Planejamento. 
Nesta fase serão definidos o escopo, as atividades a serem realizadas, a elaboração de 
cronograma, planejamento de custos, de qualidade e de aquisições e a formação de 
equipe. Nesta fase também será realizado o planejamento do gerenciamento do risco, 
constituído da identificação de riscos, análise qualitativa e quantitativa e planejamento de 
respostas a riscos das Vulnerabilidades de Segurança da Informação identificadas na 
Organização e os riscos do gerenciamento do projeto propriamente dito. 
 Exemplos de ações desta fase: criação do comitê interdepartamental de 
segurança, início da capacitação em segurança de técnicos e executivos , criação da 
política de segurança, realização de ações corretivas imediatas a partir das 
vulnerabilidades identificadas e preparação da análise de risco. 
Terceira fase do ciclo de vida do projeto: Execução. 
Esta etapa tem como objetivo executar o plano de projeto e de qualidade, o 
desenvolvimento da equipe, as aquisições e administrar contratos. 
 Para o projeto de implantação da Segurança, temos como exemplos a divulgação 
da política de segurança na Organização, capacitação de todos os funcionários 
envolvendo-os no projeto, além do esforço de alcançar o comprometimento de cada um. 
Também faz parte desta etapa implementar os mecanismos de controle em todos os 
ambientes de acordo com a política de segurança e planos executivos. 
Quarta fase do ciclo de vidado projeto: Controle. 
O avanço do projeto deve ser medido e monitorado. Nesta fase são executadas ações de 
coordenação de alterações do escopo e do próprio projeto, formalizações de aceites de 
produtos e controles de orçamento. São acompanhados e monitorados os riscos 
identificados, os resultados específicos do projeto e os requisitos de qualidade. 
 Aqui é feita a administração da segurança, exercendo-se o monitoramento e 
medição dos controles implementados, além de se garantir a conformidade com normas, 
regras e legislações existentes. Os planos de contingência e recuperação de desastres são 
atualizados e mantidos. Também deve ser acompanhado o retorno dos investimentos 
(ROI). 
Quinta fase do ciclo de vida do projeto: Encerramento. 
O encerramento do projeto acontece após seus objetivos terem sido atingidos. O 
encerramento requer documentação dos resultados a fim de formalizar a aceitação do 
produto. No nosso caso, medidas deverão ter sido estabelecidas e incorporadas aos 
processos de negócio da Organização. 
 O encerramento do projeto requer a confirmação de que os produtos propostos 
foram atingidos. Isto poderá ser demonstrado a partir de medições e relatórios com os 
 
 
 
resultados alcançados e comparados com os propostos. Deverá ser preparado um 
arquivo do projeto, com toda documentação das fases anteriores. As lições aprendidas 
também deverão ser descritas. 
3. Política de Segurança 
Para que o gerenciamento de segurança seja efetivo e não dependa de talentos humanos, 
são necessárias a criação e a implementação de uma política de segurança, dirigida 
especialmente para a organização e integrada ao seu negócio. 
 A política de segurança tem como propósito criar critérios adequados para o 
tratamento seguro das informações. A informação está vulnerável durante o seu 
manuseio, armazenamento, transporte e descarte. Diretrizes, normas e procedimentos 
poderão orientar a criação ou atualização da política de segurança na organização nos 
níveis estratégico, tático e operacional. 
 
POLÍTICA DE SEGURANÇA DA INFORMAÇÃO 
 Diretrizes Estratégico 
 Normas Tático 
 Procedimentos Operacional 
INFORMAÇÃO: CRITÉRIOS ADEQUADOS DE MANUSEIO, 
ARMAZENAMENTO, TRANSPORTE E DESCARTE. 
Figura 2. Política de segurança: Seus pilares e alicerce. 
 A Política de Segurança da Informação na Organização objetiva a proteção dos 
seus ativos e assim, a manutenção do negócio. Uma vez identificadas as vulnerabilidades 
existentes a direção, embasada por esta política definida, terá condições mais adequadas 
para decidir qual deve ser o tratamento do risco, ou seja, eliminado, mitigado, aceito 
com plano de contingência ou simplesmente aceito. 
4. Análise de Risco das Vulnerabilidades identificadas na Organização 
A identificação das vulnerabilidades, ameaças e riscos, ajuda a priorizar ações de 
segurança, e subsidia a implantação de controles eficazes. Um importante produto 
gerado nesta análise é a relação dos ativos críticos, que serão identificados, alinhados 
com o objetivo da organização e analisados, determinando-se os riscos e 
vulnerabilidades associados. Será gerado um relatório de análise de riscos e 
vulnerabilidades que deverá conter as ações corretivas que se fizerem necessárias. 
 Este estudo traz como benefícios imediatos: o conhecimento da real situação da 
empresa, a identificação das medidas de segurança apropriadas, a melhor aplicação de 
recursos e a possibilidade de tomada de decisão baseada em fatos reais. 
 Em todos os projetos existem os patrocinadores, interessados em perceber o 
retorno de seus investimentos. No projeto de Implantação de Segurança em especial, a 
necessidade de se medir resultados é de extrema importância, pois seus produtos muitas 
vezes podem parecer intangíveis. Por isto, nesta análise estão sendo propostos critérios 
 
 
 
de medições claras para que além de evidenciar o retorno do projeto, permitam 
comparações entre etapas de implantação do projeto ou entre partes, setores ou filiais da 
organização em uma mesma fase do projeto. 
 O processo de planejamento e gestão de risco pode ser dividido em etapas para 
facilitar a sua implementação, bem como para estabelecer os resultados esperados em 
cada uma delas. 
 
 
 
 
 
 
 
 
 
Figura 3 . Etapas do planejamento e tratamento do risco. 
4.1. Etapa 1 – Identificação do Risco 
A identificação do Risco é a tentativa de especificar todos os riscos que podem afetar a 
segurança da informação em todo o seu ciclo de vida. Nesta etapa é feita uma 
identificação dos ativos importantes que serão analisados, determinando-se os riscos e 
vulnerabilidades associados. Para tal, podemos utilizar algumas ferramentas tais como 
brainstorming, entrevistas, checklists, análise de premissas, documentações de redes, 
equipamentos, softwares e modelo de negócio. 
 No nosso projeto, iniciamos a nossa identificação utilizando o diagrama de Causa 
e Efeito (Figura 1.), onde foram levantadas as vulnerabilidades da Organização, 
associadas aos seus requisitos específicos. Para cada organização existirão riscos 
particulares, portanto, a tabela abaixo é apenas um modelo. 
 
Tabela 1. Identificação dos Riscos Organizacionais. 
Áreas de 
Riscos 
Descrição 
Comitê de Segurança de Informações 
Política de Segurança de Informações 
Histórico de tentativas de obtenção de informações 
Controle de mídias e periféricos 
Administrativos 
Outros 
Instalações elétricas e os sistemas de alimentação 
Avaliação dos perímetros de segurança 
Controles dos acessos físicos aos locais onde estão as informações críticas 
Físicos 
Outros 
Identificação 
do Risco
Tratamento
do Risco
Planejar as
Contenções
Planejar as
Contingências
Plano de 
Contingências
Quantificar
os Riscos
 
 
 
Utilização de barreiras digitais de proteção entre a rede local e redes externas 
Sistema de gerenciamento do tráfego 
Uso de softwares oficiais 
Tecnológicos 
Outros 
Treinamento em Segurança 
Uso de firewall individual 
Uso de senhas individuais 
Humanos 
Outros 
4.2. Etapa 2 – Quantificação do Risco 
Quantificação do Risco consiste em mensurar a probabilidade e o impacto do risco. A 
probabilidade pode ser classificada na seguinte escala de ocorrência: Extremamente 
provável, Muito provável, Provável e Improvável. Por sua vez, a severidade, como 
Crítica, Moderada e desprezível. O produto destas duas classificações nos fornecerá a 
quantificação do risco , expresso como impacto. (Figura 3.) 
 
 
 
 
 
 
 
 
Figura 4. Severidade X Ocorrência: Quantificação de Risco 
4.3. Etapa 3 – Tratamento do Risco 
De acordo com o resultado obtido no gráfico Severidade x Ocorrência (Figura 4), o 
risco será tratado em uma das classificações a seguir: 
 Impacto Aceitável: Nenhum Plano de Contenção será criado para diminuir a 
probabilidade de ocorrência ou impacto, nem tão pouco qualquer Plano de Contingência 
caso ocorra o evento do risco. 
 Impacto Aceitável com Reação: Nenhum Plano de Contenção será elaborado, 
porém, um Plano de Contingência deverá ser feito caso ocorra o evento do risco. 
 Remanejar para Terceiros: Transferir os riscos e suas conseqüências para 
terceiros, porém, não visa diminuir, nem tão pouco eliminar a possibilidade de 
ocorrência. O terceiro poderá elaborar os Planos de Contenção / Contingência. 
 Mitigar: Reduzir a probabilidade de ocorrência e/ou impacto do risco através de 
criação de um Plano de Contenção do risco, que se transformará em atividades no 
cronograma, e Plano de Contingência. 
C 
M 
D 
 I P MP EP 
Se
ve
ri
da
de
 
Ocorrência 
Situação de alto risco associado Situação de baixo risco associado 
 
 
 
 Eliminar: Reduzir a probabilidade de ocorrência do risco em 0% (zero por 
cento)através de criação de um Plano de Contenção do risco, que se transformará em 
atividades no cronograma. 
 Para Situação de alto risco associado, o risco deverá ser tratado por uma das 
seguintes opções: Remanejar para terceiros, Mitigar ou Eliminar. 
4.4. Etapa 4 – Planejar as Contenções e Contingências 
Para o risco que foi enquadrado em Remanejar para terceiros, Mitigar ou Eliminar, 
deverá ser feito um planejamento de contenção cujo propósito é de diminuir ou eliminar 
a possibilidade de ocorrência do impacto do risco. Para o risco que foi enquadrado em 
Impacto Aceitável com Reação, Remanejar para Terceiros ou Mitigar, deverá ser feito 
um planejamento de contingência que poderá ser útil caso um evento de risco ocorra. 
Também neste caso poderão ser utilizadas as ferramentas citadas na etapa 1. 
4.5 Padronização da análise dos riscos na Organização 
Para se estabelecer qualquer comparação, seja entre etapas de implantação do projeto ou 
em uma mesma etapa, mas entre ambientes distintos, por exemplo, entre filiais, é 
necessário ter critérios não subjetivos e claros de classificação e medição. O objetivo é 
obter padronização nos resultados. 
 Esta proposta pode ser adaptada a qualquer organização de acordo com seu 
negócio e risco envolvido, no entanto, uma vez adaptada, é importante manter imutável 
do início ao fim para se garantir a consistência. 
 A primeira providência é estabelecer um critério de pontuação para medir os 
riscos. O CMU/SEI-93-TR-24(1993), descreve o conceito de maturidade do processo de 
software e os cinco níveis de maturidade. Os cinco níveis propostos podem ser 
adaptados em um conceito mais amplo para a nossa classificação dos riscos: 
 Inicial: O processo é caótico. Poucos processos são definidos e o sucesso 
depende de cada indivíduo. Considerado como inexistente; 
 Repetível: Processos básicos de gestão de projetos são estabelecidos para 
acompanhar custo, cronograma e funcionalidade. É possível repetir sucessos anteriores; 
 Definido: Processos documentados. Existe um padrão aprovado; 
 Gerenciado: Medidas detalhadas do processo e da qualidade do produto são 
realizados. O processo e os produtos são quantitativamente entendidos e controlados; e 
 Em otimização: A melhoria do processo é realimentada pelo retorno medido do 
processo, por melhorias tecnológicas e estudos inovadores; 
 A pontuação dos riscos (tabela 2.), foi baseada nos cinco níveis de maturidade 
propostos no CMU/SEI-93-TR-24, e na proposta da publicação da Marinha do Brasil, 
DGMM-0520 (2004) de possuir 10 níveis de graduação para cada risco. 
 
 
 
Tabela 2. Padrão de pontuação dos riscos 
Nota Descrição do critério originário da nota 
0 Não existe definido o requisito de segurança para o risco identificado 
1 Existe ou foi definido o requisito de segurança para o risco identificado. Não atende. 
2 Existe ou foi definido o requisito de segurança para o risco identificado. Atende 
parcialmente. 
3 Existe ou foi definido o requisito de segurança para o risco identificado. Atende. 
4 Existe ou foi definido o requisito de segurança para o risco identificado. Foi 
documentado. Atende parcialmente. 
5 Existe ou foi definido o requisito de segurança para o risco identificado. Foi 
documentado. Atende. 
6 Existe ou foi definido o requisito de segurança para o risco identificado. Foi 
documentado. Foi comunicado às áreas interessadas. Atende parcialmente. 
7 Existe ou foi definido. Foi documentado. Foi comunicado às áreas interessadas. 
Atende. 
8 Existe ou foi definido. Foi documentado. Foi comunicado às áreas interessadas. O 
processo ou equipamento é sempre atualizado quando necessário. 
9 Existe ou foi definido. Foi documentado. Foi comunicado às áreas interessadas. Existe 
Auditoria / Verificação. 
10 Existe ou foi definido. Foi documentado. Foi comunicado às áreas interessadas. O 
processo ou equipamento é sempre atualizado quando necessário. Existe Auditoria / 
Verificação documentada. 
 
 Todos os riscos, que na etapa 3 da análise de risco não foram classificados como 
Impacto Aceitável, devem ser mensurados e acompanhados na gestão de risco. Quando 
conveniente, o agrupamento deverá ser feito para facilitar a análise. Como dito 
anteriormente, uma vez estabelecidos os riscos a serem analisados, seja individualmente 
ou agrupados, é importante manter a classificação para manter a padronização. 
 A organização desta proposta pode ser evidenciada em uma tabela de Pontuação 
dos riscos identificados na Organização (tabela 3), onde serão descritos os riscos, a 
situação como eles estão sendo tratado na organização e a pontuação baseada na tabela 
2. O exemplo abaixo é meramente didático, uma vez que estes tipos de informação são 
sigilosos e muito específicos de cada organização. 
 
 
 
Tabela 3. Pontuação dos riscos identificados na Organização 
Item Descrição Situação Pontuação 
1 Comitê de Segurança de 
Informações 
O comitê foi designado oficialmente. Sua 
existência e objetivos foram comunicados 
a toda organização. Os trabalhos foram 
iniciados. 
7 
2 Política de Segurança de 
Informações 
A política de segurança está em execução. 1 
3 Histórico de tentativas de 
obtenção de informações 
Não existem formalmente descritos os 
incidentes. Existe alguma coisa 
documentada em áreas isoladas. É 
necessária a centralização e 
documentação do que for encontrado. 
0 
4 Instalações elétricas e os 
sistemas de alimentação 
As instalações seguem todas as normas de 
segurança. São sempre vistoriadas. 
Existem vistorias programadas e sempre 
são gerados relatórios e medidas 
corretivas são imediatamente aplicadas. 
10 
5 Avaliação dos Perímetros de 
Segurança 
Os perímetros estão demarcados e 
procedimentos de reação descritos. 
4 
Área 1:Existe rigoroso controle de acesso 
aos locais identificados com informações 
críticas. Existe monitoramento eletrônico 
e alarmes instalados e monitorados. 
Procedimentos documentados. 
7 
Área 2: Existe controle de acesso aos 
locais identificados com informações 
críticas. O procedimento é informal e é 
controlado pelo chefe da seção. 
1 
6 Controles dos acessos físicos 
aos locais onde estão as 
informações críticas 
Área 3: Existe controle de acesso aos 
locais identificados com informações 
críticas. O procedimento é formal e mas 
não está divulgado, além de estar 
desatualizado. 
4 
7 Utilização de barreiras 
digitais de proteção entre a 
rede local e redes externas 
Existe firewall entre a rede local e a 
externa. O equipamento é sempre 
atualizado. O procedimento de 
atualização é informal. 
3 
8 Uso de softwares oficiais A organização não permite softwares não 
oficiais. Existe procedimento interno 
divulgado. Sempre que necessário, são 
adquiridos atualizações e novos softwares. 
8 
9 Treinamento em Segurança Existem treinamentos em segurança. Não 
existe um plano de treinamento 
corporativo. Não existe controle de 
participantes. 
2 
10 Uso de firewall individual Não é utilizado. 0 
11 Uso de senhas individuais Existe procedimento interno formal e 
divulgado. As senhas corporativas seguem 
procedimentos de trocas obrigatórias. 
7 
 
 
 
.6 Métrica da Análise dos Riscos na Organização: Medidas e Metas 
A medição deverá ser feita no início do projeto e sempre que for desejada uma nova 
avaliação. É interessante na primeira medição, estabelecer a meta a final a ser atingida e 
na próxima fase, quando for o caso.(Figura 5.e Figura 6.). No nosso estudo, foram 
usados como exemplos os itens contidos na tabela 3., referentes às vulnerabilidades 
administrativas e físicas. 
 
Riscos organizacionais administrativos
Situação início do Projeto
0
1
2
3
4
5
6
7
8
9
10
C o mit ê d e Seg urança
Po lí t ica d e Seg urança
Hist ór ico de t ent at ivas de o b t enção de
inf o rmações
 
Riscos organizacionais administrativos
Meta a alcançar na fase 2 do projeto
0
1
2
3
4
5
6
7
8
9
10
Comitê de Segurança
Política de SegurançaHistórico de tentativas de obtenção deinformações
 
 
Figura 5. Situação Riscos Administrativos: Situação inicial e Meta na fase 2. 
 
 
 
 
Riscos organizacionais Físicos
Situação início do projeto
0
1
2
3
4
5
6
7
8
9
10
Inst alações elét ricas e o s sist emas d e
al iment ação
A valiação d o s Per ímet ros d e Seg ur
C ont ro le d e acesso - Área1
Á
C ont ro le d e acesso - Área3
U t i liz ação de b arrei ras d ig it ais de
pro t eção ent re a red e lo cal e red es
ext ernas
Riscos organizacionais Físicos
Mata a ser atingida fase 2 projeto
0
1
2
3
4
5
6
7
8
9
10
Instalações elétricas e os sistemas de alimentação
Avaliação dos Perímetros de Segurança
Controle de acesso - Área1Controle de acesso - Área3
Utilização de barreiras digitais de proteção entre a
rede local e redes externas
Figura 6. Situação Riscos Físicos: Situação inicial e Meta na fase 2. 
5. Considerações finais 
Os graus de tolerância aos riscos são diferentes entre organizações, por suas 
características de negócio ou mesmo por razões culturais. É essencial que o Comitê de 
Segurança valide com a Direção os critérios de definição dos limites de aceitação e as 
ações propostas para os riscos avaliados. Os riscos podem ser dinâmicos e, portanto, 
devem ser avaliados constantemente durante a execução do projeto. Além disso, a 
implementação de uma resposta a um risco pode mitigar um risco primário, mas criar as 
condições para o surgimento de um risco secundário ou residual. 
 
 
 
 A necessidade de se conseguir enxergar várias alternativas e um pouco de 
conservadorismo são características de uma boa gestão de riscos, e estes fatores, podem 
reduzir drasticamente os custos de um projeto. 
 Cabe ressaltar que o projeto de Implantação de Segurança de Informação deve 
ser classificado como Confidencial, e em certos casos, até mesmo como Secreto. A 
análise de Risco, em especial, expõe a Organização, explicitando todas as suas 
vulnerabilidades e possíveis Planos de Contingência. 
6. Conclusão 
A necessidade de implantação de projeto de Segurança da Informação é um fato 
reconhecido pela maioria das organizações. Este projeto envolve todos da organização e 
traz uma aproximação do profissional de TI com os profissionais de áreas ligadas à 
atividade fim, área financeira / administrativa e à direção. Desta forma é necessário que 
a linguagem utilizada deve ser comum e de fácil entendimento para todos. Além disto, é 
de conhecimento que na gestão empresarial, aquilo que não se pode medir, não se pode 
gerenciar. 
 O uso de metodologias e métricas é fundamental para a aproximação de áreas, 
propiciando uma melhor integração entre os setores.O objetivo de implantação da 
segurança na Organização, é facilitado quando se utilizam os conhecimentos distribuídos 
pela Organização além de da utilização de metodologia de gerenciamento de projeto. 
6. Referências 
ABNT, NBR ISO/IEC 17799 “Tecnologia da Informação-Código de Prática Para 
Gestão da Segurança da Informação” , 2001 
CMU/SEI-93-TR-24 Paulk, Mark C.; Curtis, Bill; Chrissis, Mary Beth Chrissis, and 
Weber, Charles, “Software Engineering Institute Capability Maturity Model for 
software,V1.1”, 1993. 
DIAS, C., “Segurança e Auditoria da Tecnologia da Informação”, Axcel Books,2000. 
DGMM-0520, “Normas para a Gestão de Segurança das Informações Digitais em 
Redes Locais”, Diretoria Geral do Material da Marinha, 2004. 
GLOMARK, “Quantifying IT Intangible Benefits White Paper”, Glomark Corp., 2004. 
PMI, “A Guide to the Project Management Body of Knowledge (PMBOK Guide)”, 
Project Management Institute, Newtown Square, Pennsylvania, USA, 2000 Edition. 
SEMOLA, M., “Gestão da Segurança da Informação: Uma Visão Executiva”, Editora 
Campus,2003.