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.).

Vulnerabilidades de
Recursos Humanos
Falta de Conhecimento

Vulnerabilidades
Físicas
Falta de Falta de Redes Segregadas e Salas de Projeto
Falta de
Interesse Treinamento
Preocupação
Medidas de controle individual de informações inadequadas
Pouco Falta de
Controle de
uso de acesso inadequado Segurança
criptografia Quanto à Incêndio

Ausência de Descarte Inadequado Controle inadequado Uso indevido Backup

Falta de Firewall
Protetores de Informações de material sigiloso de e-mails Inadequado
para PC-Individual
de Tela

Controle de Senhas Falta de atualização de Falta de atualização de

Pouco Deficiente Sistema Operacional Ant-virus
uso de
criptografia QUAIS OS
PRINCIPAIS
VULNERABILIDADES
Hardware ORGANIZACIONAIS?
Sistemas Software Cabeamento,
operacionais, Roteadores, Hubs e
Browsers e Programas de E-mail Switchs
Ausência de auditorias
Servidores Internas
Firewall obsoletos Ausência de Plano Estratégico de
Descontrole Falta de Inúmeras Descontrole obsoleto Informações
de Senhas Atualizações Versões de periféricos e
Ausência de Metas Claras quanto
mídias à Segurança de Informações
Pirataria
Composição Inadequada do Conselho de
Celular Pen-driver Segurança de Informações

Hand-held Ausência de Gerenciamento de Riscos

CD, CD-RW Ausência de Métricas de Segurança

Gravador de CD Ausência de Históricos de Tentativas
de Obtenção de Informações

Ataques ostensivos Rede corporativa insegura Falta de Cultura de Segurança

Cavalos de Falta de Crônica de Recursos

Sniffers
Tróia Backdoors
Virus Worms Hackers Vulnerabilidades Vulnerabilidades
DNS Key-loggers Tecnológicas Administrativas

Ataques Espionagem

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 vida do 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.

Planejar as
Contenções

Identificação Quantificar Tratamento

do Risco os Riscos do Risco

Planejar as Plano de
Contingências Contingências

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 Descrição
Riscos
Administrativos 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
Outros
Físicos 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
Outros
Tecnológicos 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
Outros
Humanos Treinamento em Segurança
Uso de firewall individual
Uso de senhas individuais
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.)

C
Severidade

M
D
I P MP EP

Ocorrência
Situação de alto risco associado Situação de baixo risco associado
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.
 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 O comitê foi designado oficialmente. Sua 7
Informações existência e objetivos foram comunicados
a toda organização. Os trabalhos foram
iniciados.
2 Política de Segurança de A política de segurança está em execução. 1
Informações
3 Histórico de tentativas de Não existem formalmente descritos os 0
obtenção de informações incidentes. Existe alguma coisa
documentada em áreas isoladas. É
necessária a centralização e
documentação do que for encontrado.
4 Instalações elétricas e os As instalações seguem todas as normas de 10
sistemas de alimentação segurança. São sempre vistoriadas.
Existem vistorias programadas e sempre
são gerados relatórios e medidas
corretivas são imediatamente aplicadas.
5 Avaliação dos Perímetros de Os perímetros estão demarcados e 4
Segurança procedimentos de reação descritos.
6 Controles dos acessos físicos Área 1:Existe rigoroso controle de acesso 7
aos locais onde estão as aos locais identificados com informações
informações críticas críticas. Existe monitoramento eletrônico
e alarmes instalados e monitorados.
Procedimentos documentados.

Área 2: Existe controle de acesso aos 1

locais identificados com informações
críticas. O procedimento é informal e é
controlado pelo chefe da seção.

Área 3: Existe controle de acesso aos 4

locais identificados com informações
críticas. O procedimento é formal e mas
não está divulgado, além de estar
desatualizado.
7 Utilização de barreiras Existe firewall entre a rede local e a 3
digitais de proteção entre a externa. O equipamento é sempre
rede local e redes externas atualizado. O procedimento de
atualização é informal.
8 Uso de softwares oficiais A organização não permite softwares não 8
oficiais. Existe procedimento interno
divulgado. Sempre que necessário, são
adquiridos atualizações e novos softwares.
9 Treinamento em Segurança Existem treinamentos em segurança. Não 2
existe um plano de treinamento
corporativo. Não existe controle de
participantes.
10 Uso de firewall individual Não é utilizado. 0
11 Uso de senhas individuais Existe procedimento interno formal e 7
divulgado. As senhas corporativas seguem
procedimentos de trocas obrigatórias.
.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
C o mi t ê d e Seg urança
10
9
8
7
6
5
4
3
2
1
0

Hist ór ico d e t ent at ivas d e o b t enção d e

Po lí t ica d e Seg urança
inf o r mações

Riscos organizacionais administrativos

Meta a alcançar na fase 2 do projeto
Comitê de Segurança
10
9
8
7
6
5
4
3
2
1
0

Histórico de tentativas de obtenção de

Política de Segurança
informaçõ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
I nst al ações elét ri cas e o s si st emas d e
al iment ação
10
9
8
7
U t i liz ação d e b arr ei ras d ig it ai s d e 6
p r o t eção ent re a r ed e lo cal e r ed es 5 A vali ação d o s Per ímet r o s d e Seg ur
ext er nas
4
3
2
1
0

C o nt ro le d e acesso - Área3 C o nt r o le d e acesso - Área1

Riscos organizacionais Físicos

Mata a ser atingida fase 2 projeto
Instalações elétricas e os sistemas de alimentação
10
9
8
7
6
Utilização de barreiras digitais de proteção entre a
5 Avaliação dos Perímetros de Segurança
rede local e redes externas
4
3
2
1
0

Controle de acesso - Área3 Controle de acesso - Área1

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.