Segurança Auditoria de Sistemas

Prévia do material em texto

ISBN 978-65-5821-129-7
9 786558 211297
Código Logístico
I000600
Segurança e auditoria 
de sistemas 
Wagner Mendes Voltz
IESDE BRASIL
2022
Todos os direitos reservados.
IESDE BRASIL S/A. 
Al. Dr. Carlos de Carvalho, 1.482. CEP: 80730-200 
Batel – Curitiba – PR 
0800 708 88 88 – www.iesde.com.br
© 2022 – IESDE BRASIL S/A. 
É proibida a reprodução, mesmo parcial, por qualquer processo, sem autorização por escrito do autor e do 
detentor dos direitos autorais.
Projeto de capa: IESDE BRASIL S/A. Imagem da capa: geen graphy/Shutterstock
 Blue Andy / shutterstock 
CIP-BRASIL. CATALOGAÇÃO NA PUBLICAÇÃO 
SINDICATO NACIONAL DOS EDITORES DE LIVROS, RJ
V899s
Voltz, Wagner Mendes
Segurança e auditoria de sistemas / Wagner Mendes Voltz. - 1. ed. - 
Curitiba [PR] : IESDE, 2022.
104 p. : il.
Inclui bibliografia
ISBN 978-65-5821-129-7
1. Computadores - Medidas de segurança. 2. Proteção de dados. 3. 
Centros de processamento de dados - Auditoria. 4. Centros de processa-
mento de dados - Medidas de segurança. I. Título.
22-76762 CDD: 005.8
CDU: 004.056
Wagner Mendes Voltz Especialista em Administração com ênfase em 
Gestão da Tecnologia da Informação pela Faculdade 
de Administração e Economia (FAE). Graduado em 
Tecnologia em Informática pela Universidade Federal 
do Paraná (UFPR). Atua como professor desde 
2012 e como analista de sistemas desde 2005. Tem 
experiência na área de ciência da computação com 
ênfase em metodologia e técnicas de computação. 
Ministra as disciplinas de Programação Orientada 
a Objetos, Desenvolvimento em Java com Testes 
Unitários, Desenvolvimento em Java Web, Padrões de 
Projeto, Desenvolvimento em Android, Qualidade de 
Código-Fonte, Metodologias Ágeis, Gestão da Qualidade 
em Projetos e Sistemas Operacionais.
Agora é possível acessar os vídeos do livro por 
meio de QR codes (códigos de barras) presentes 
no início de cada seção de capítulo.
Acesse os vídeos automaticamente, direcionando 
a câmera fotográ�ca de seu smartphone ou tablet 
para o QR code.
Em alguns dispositivos é necessário ter instalado 
um leitor de QR code, que pode ser adquirido 
gratuitamente em lojas de aplicativos.
Vídeos
em QR code!
SUMÁRIO
1 Auditoria de sistemas da informação 9
1.1 Fundamentos da auditoria de sistemas da informação 10
1.2 Técnicas para auditoria de sistemas 18
1.3 Plano de contingência e de recuperação de desastres 22
2 Execução de auditorias 31
2.1 Auditoria de controles 31
2.2 Auditoria de sistema 36
2.3 Auditoria de hardware 45
2.4 Auditoria de controle de acesso 53
3 Segurança de sistemas da informação 58
3.1 Conceitos e princípios fundamentais da segurança 59
3.2 Risco, ameaça e vulnerabilidade 67
3.3 Família de normas ISO 27000 73
4 Modelos de maturidade para segurança da informação 79
4.1 SSDLC e modelo SAMM 80
4.2 Área de negócio: governança 88
4.3 Área de negócio: design 91
4.4 Área de negócio: implementação 94
4.5 Áreas de negócio: verificação e operação 96
 Resolução das atividades 102
Agora é possível acessar os vídeos do livro por 
meio de QR codes (códigos de barras) presentes 
no início de cada seção de capítulo.
Acesse os vídeos automaticamente, direcionando 
a câmera fotográ�ca de seu smartphone ou tablet 
para o QR code.
Em alguns dispositivos é necessário ter instalado 
um leitor de QR code, que pode ser adquirido 
gratuitamente em lojas de aplicativos.
Vídeos
em QR code!
Você já parou para pensar como é o mundo atual? 
Será que uma decisão de um país asiático pode influenciar 
a sua vida no Brasil? Será que uma nevasca nos EUA pode 
afetar o seu dia a dia? E como você consegue ter acesso a 
todas essas informações? Pois é, boa parte do mundo está 
conectada a uma grande rede de troca de informações 
(internet) e utilizamos computadores e aparelhos móveis, 
como smartphones e tablets, para ficarmos conectados a ela. 
São milhões de dispositivos acessando à internet ao 
mesmo tempo e cada um deles utiliza um conjunto de 
hardware e software para realizar o acesso. Mas será que esses 
dispositivos são seguros? O hardware e o software deles estão 
sem vulnerabilidades? Quanto às informações que as pessoas 
estão acessando, será que elas são íntegras, confidenciais e 
estão disponíveis? Como garantir que tudo esteja seguro? 
As respostas para essas perguntas serão respondidas neste 
livro, por meio do estudo de como é realizada uma auditoria 
de sistemas e de como são aplicados conceitos de segurança 
em ambientes computacionais.
Esta obra foi preparada para proporcionar uma experiência 
teórica e prática, ou seja, se você trabalha em uma empresa 
de tecnologia da informação, poderá aplicar, no seu dia a dia, 
os questionários e conteúdos propostos.
Nesta jornada, apresentaremos os conceitos de auditoria 
e como aplicá-los na área de sistemas da informação. Você 
aprenderá que o trabalho de um auditor de sistemas da 
informação envolve conhecer diversas normativas regulatórias, 
assim como áreas computacionais, como hardware, software 
e controles de acessos. Esses temas serão apresentados 
nos Capítulos 1 e 2. A partir dos Capítulos 3 e 4, o foco será 
em como desenvolver um sistema de gestão e segurança 
da informação (SGSI) orientado a normas internacionais ISO 
27000 e a SAMM. 
APRESENTAÇÃOVídeo
8 Segurança e auditoria de sistemas
Esperamos que, após a leitura, você seja capaz de aplicar uma auditoria 
em sistemas da informação e consiga iniciar a implantação de um SGSI em um 
time que trabalha com software. E aí, animado para esta aventura?
Bons estudos!
Auditoria de sistemas da informação 9
1
Auditoria de sistemas 
da informação
Em nosso dia a dia, as pessoas se relacionam com diversos outros 
indivíduos e interagem com vários aparelhos tecnológicos. Ao reali-
zar uma compra no comércio, é criado um relacionamento chamado 
cliente – fornecedor. Ainda, ao pagar um boleto, cria-se outro relaciona-
mento, denominado sacado – sacador. Esse conjunto de interações entre 
uma pessoa e os demais elementos é chamado de sistema e, quando esse 
sistema (ou parte dele) está em um meio digital, como computadores e 
smartphones, ele é intitulado sistema de informação.
Todo sistema deve seguir um processo, a fim de torná-lo produtivo e 
eficiente. Alguns deles têm as suas normas estabelecidas pelo governo 
em forma de lei, enquanto outros dispõem de normas estabelecidas 
por órgãos competentes no tema. A ação de verificar se os processos 
estão em conformidade é intitulada auditoria e, quando esse processo 
está focado na análise de conformidade de hardware, software e redes, é 
chamado de auditoria de sistemas de informação.
Neste capítulo, traremos os fundamentos que compõem o tema 
auditoria de sistemas de informação, bem como as técnicas para aplicar 
essa auditoria. Por fim, abordaremos os meios de elaboração de um plano 
que garanta a manutenção dos sistemas de informação, caso aconteça 
um desastre, como o ataque hacker. 
Com o estudo deste capítulo, você será capaz de:
 • conhecer as bases que alicerçam o tema auditoria de sistemas;
 • descrever as principais técnicas para executar o processo de au-
ditoria de sistemas;
 • detalhar o que é um plano de contingência e de recuperação de 
desastres e entender como criá-lo.
Objetivos de aprendizagem
10 Segurança e auditoria de sistemas
1.1 Fundamentos da auditoria de 
sistemas da informação Vídeo
Um sistema é composto de um conjunto de elementos que se 
inter-relacionam. Em alguns casos, ele possui diversos subsistemas, 
como é o caso do corpo humano, com os sistemas circulatório, respi-
ratório, urinário, entre outros. Logo, um sistema pode ser facilmente 
compreendido quando é constituído por poucos elementos de rela-
cionamento. Quando existe um novo elemento querendo se relacionar 
com o sistema, este pode vir a ser um novo subsistema, tornando o 
primeiro mais complexo e confuso de se entender.
Uma empresa, por exemplo, pode ser considerada um sistema, pois 
fazem partedela as pessoas que atuam como colaboradoras, os pró-
prios sistemas digitais (softwares), os aparelhos (hardware) utilizados 
para acessar os softwares e os processos de trabalhos. Todos esses ele-
mentos se relacionam, a fim de entregar valor ao cliente. Além disso, a 
empresa cria relações com outras empresas, mediante a terceirização 
de serviços, não nos esquecendo do relacionamento entre a empresa 
e os seus clientes. 
Nesse sentido, toda empresa que utiliza computadores e softwares 
pode ser um potencial consumidor dos serviços de auditoria de siste-
mas de informação; já quando é a produtora de softwares, o trabalho 
de auditoria é ampliado, para atender às especificações de como se 
criar um software.
Para Imoniana (2013, p. 17), “a filosofia de auditoria em tecnolo-
gia de informação está calcada em confiança e em controles internos. 
Estes visam confirmar se os controles internos foram implementados e 
se existem; caso afirmativo, se são efetivos”.
Como mencionado, o trabalho de auditoria serve para validar se os 
processos estão sendo executados conforme o definido e, caso não 
estejam, a pessoa auditora precisa recomendar quais ações devem ser 
executadas para normalizar o processo. 
Se, em algum ponto da auditoria, for identificada a inexistência de 
um processo para determinada situação, cabe ao auditor recomendar 
tanto a definição quanto a implantação de um dado processo que possa 
ser auditável e seguro. Por exemplo, um auditor identificou que não 
Auditoria de sistemas da informação 11
existe controle de acesso à sala dos servidores da empresa. Sem esse 
controle, as informações da empresa podem ser roubadas, bem como 
os sistemas de rede e servidores danificados, tudo sem a identifica-
ção de quem praticou as ações. O auditor deve descrever essa situação 
como de risco e sugerir a adoção de um controle eletrônico de acesso 
ao servidor, que evidencie a hora de ingresso e quem entrou na sala. 
A adoção de um sistema de acesso por meio da biometria já transforma 
essa não conformidade em um processo definido e rastreável.
No exemplo citado, percebe-se que a empresa corre um grande risco, 
pois, em uma sala de servidores, há diversos computadores que custam 
milhares de reais, além de dados sigilosos que podem ficar vulneráveis. 
Caso essas informações sejam modificadas ou até sequestradas, o dano 
gerado pode ser incalculável para a imagem da empresa.
O processo de auditoria tem por objetivo gerar a segurança no uso 
dos computadores e dos softwares utilizados por uma organização. 
Além disso, visa elevar a qualidade dos processos da empresa e, assim, 
maximizar a performance das operações, promovendo a melhora do 
custo-benefício relativo aos altos investimentos comuns às áreas de TI.
A auditoria de sistemas de informação não se trata de uma ativida-
de recente, pois teve início em meados de 1960, quando as empresas 
começaram a ter computadores e softwares próprios.
As primeiras auditorias seguiam os modelos e processos existentes 
na época e, com o passar do tempo, houve a necessidade de 
especializá-las segundo as diversas áreas da TI. No quadro a seguir, 
está um resumo das especializações pelas quais a auditoria de siste-
mas passou ao longo dos anos.
Quadro 1
Histórico da auditoria de sistemas de informação
Intervalo de ano Foco da auditoria Áreas auditadas
1998-2001 Operações da área de TI
 • Microinformática.
 • Segurança física.
 • Segurança lógica.
 • Redes locais.
2002-2003 Sistemas de informação
 • Sistemas informatizados de 
departamentos.
 • Administração do centro de servi-
ço de informática.
(Continua)
12 Segurança e auditoria de sistemas
Intervalo de ano Foco da auditoria Áreas auditadas
2004-2005 Gestão de TI
 • Administração da infraestrutura 
de TI.
 • Gerência e desenvolvimento orga-
nizacional de TI.
 • Administração de banco de dados.
 • Administração de sites.
2006-2008
Auditoria baseada nas 
áreas de conhecimento 
de TI.
 • Administração de redes.
 • Administração de dados.
 • Gestão do ciclo de vida de siste-
mas de informação.
 • Gerência de mudanças.
2009-2011
Baseada em processos, 
conforme normas 
internacionais.
 • Processos definidos no Cobit.
 • Governança de TI.
 • Garantia da segurança de sistemas.
 • Gestão de investimentos em TI.
2011 - atualmente
Adição de auditoria em 
ambientes distribuídos, 
como nuvem (cloud).
 • Gestão de ambientes distribuídos, 
em especial nuvem.
Fonte: Elaborado pelo autor.
Conforme o Quadro 1, pode-se perceber que, com o passar dos anos, 
novas áreas da tecnologia foram sendo auditadas. Isso aconteceu em 
razão dos diversos avanços da tecnologia. Com relação aos processos 
de auditoria, raramente eles são descartados; a abordagem é sempre 
a de adotar novos temas, sem se esquecer dos anteriores, sendo que 
as demais abordagens passam a ser tratadas como camadas. Com a 
continuidade das auditorias, a empresa vai avançando nessas camadas 
e desenvolvendo processos de TI mais maduros. 
Para realizar o trabalho de auditoria de sistemas de informação, é preciso co-
nhecer os seus princípios. São eles:
• a auditoria não deve ser baseada em opiniões ou avaliações pessoais;
• a auditoria deve apresentar imparcialidade e ser pragmática;
• todo elemento em um sistema pode ser auditável e estar conforme ou 
não conforme uma situação ideal; 
• o auditor deve se basear em evidências (fatos e registros) que possam ser 
consultadas ao longo do tempo.
Quando a auditoria é feita em sistemas computacionais, à medida 
que é executada, muitos processos podem ser automatizados. Ao se 
Auditoria de sistemas da informação 13
finalizar a automatização de um item, a empresa passa a ter um novo 
patamar de segurança, aumentando a governança na TI. Um exemplo 
de automação é a adoção da prática intitulada DevOps. 
DevOps é o nome dado ao trabalho de automatizar a entrega de um 
software. Ele é constituído por um conjunto de técnicas e ferramentas 
que envolve desde o versionamento do código-fonte do software até a 
sua disponibilização para os clientes utilizarem. Em alguns lugares, esse 
trabalho é manual e sem rastreabilidade. Quando o DevOps é adotado, 
é possível entregar versões de software de modo rastreável, repetiti-
vo, sem falhas e auditáveis. Segundo Humble e Kim (2018), empresas 
que adotam o DevOps apresentam menores taxas de bugs em seus 
produtos e conseguem entregar diversas versões por dia, tratando-se 
de um diferencial competitivo na prestação de serviço. Logo, conforme 
é reduzido o time-to-market, ou seja, o tempo gasto no processo de 
desenvolvimento de algo até chegar ao cliente, é possível vender mais 
e gerar maior satisfação para o cliente.
Planejar
La
nç
ar
 ve
rs
ão
Disponibilizar
Op
er
aç
ãoMonitoramento
Testa
r
Construir
Pro
gra
ma
r
Ph
ak
aw
an
 W
on
gp
et
an
an
/S
hu
tte
rs
to
ck
Figura 1
Ciclo DevOps de trabalho 
O trabalho de auditoria pode ser realizado por uma ou mais pessoas 
e o número necessário vai depender do tamanho da organização. 
Esses profissionais podem ser colaboradores da própria empresa ou 
mesmo funcionários terceirizados que prestarão o serviço. Em ambos 
os cenários, é importante que a pessoa auditora tenha as seguintes 
competências e valores:
14 Segurança e auditoria de sistemas
 • Ética: a conduta do profissional de auditoria deve ser íntegra e de 
aderência ao código de ética profissional definido pelas associa-
ções de auditores de tecnologia da informação. 
 • Sigilo, privacidade e confidencialidade: o profissional de audi-
toria lida com informações que podem ser estratégicas para uma 
organização e cabe a ele mantê-las sob sigilo e confidencialidade.
 • Independência profissional: o auditor de tecnologia da informa-
ção deve ser independente, deixando transparecer tal postura 
nas suas atitudes e no seu comportamento. 
 • Planejamento: o auditor deve saber planejar as suas atividades 
para atingir o seu objetivo.
 • Pragmático e observador: o auditor deve ser prático e com 
abordagem baseada em evidências.• Criação de apresentações coerentes: as conclusões devem ser 
baseadas em fatos e os relatórios devem ser precisos.
 • Bom relacionamento (diplomacia): o auditor deve ter um bom 
relacionamento em todas as esferas da organização e evitar 
atritos pessoais.
 • Domínio sobre o tema: a auditoria pode ser realizada por meio 
de diversas técnicas e métodos e o auditor deve dominá-los. 
A constante atualização de conhecimento, referente aos modelos 
de auditoria, e a vivência das técnicas fazem com que o profissional de 
auditoria se desenvolva e atenda às expectativas das empresas. Com 
base nessas informações, pergunta-se: como o auditor faz o seu traba-
lho? A resposta para essa dúvida é dividida em quatro pontos:
 • entender o contexto e delimitar o escopo de trabalho;
 • definir um ou mais tipos de auditorias que serão realizadas;
 • estabelecer uma ou mais abordagens de auditoria;
 • definir a organização do trabalho.
Para que a auditoria alcance o resultado esperado, é necessário 
entender o contexto do cliente e deixar claro quais são os limites do 
trabalho. Ao delimitar o escopo de atuação, as expectativas ficam ali-
nhadas e o cliente recebe o serviço contratado. 
Para exemplificar a importância desse ponto, vamos imaginar que 
um auditor externo tenha sido contratado para auditar o sistema de fo-
lha de pagamento desenvolvido pela empresa. Ao receber essa deman-
Auditoria de sistemas da informação 15
da, o profissional não delimitou o escopo de atuação e foi direto para as 
validações dos itens previstos. Ao finalizar o trabalho, o auditor entrega 
o relatório final à diretoria, que questiona o documento por não ha-
ver evidências de auditoria sobre o controle de acesso aos servidores 
cloud. Essa informação é importantíssima, pois o software de folha de 
pagamento tem informações sigilosas e se encontra disponível na web.
Conclui-se, então, que o auditor não realizou a validação sobre o 
controle de acesso aos servidores cloud porque imaginou que o tra-
balho era somente referente aos processos de programação e de 
versionamento do código-fonte. Ao entregar a auditoria incompleta, 
a diretoria solicitou que o documento fosse refeito, não efetuando o 
pagamento por esse retrabalho, uma vez que o erro foi do consultor. 
Esse pequeno cenário demonstra como pode ser grave a entrega 
de um trabalho que não está alinhado com o cliente, podendo gerar a 
insatisfação e o prejuízo para ambas as partes. 
Após delimitar o escopo, é importante definir quais tipos de audito-
ria serão realizados, podendo ser selecionados um ou mais tipos. 
O quadro a seguir traz uma lista de auditorias.
Quadro 2
Tipos de auditoria
Tipo de auditoria Objetivo
Auditoria durante o desenvolvimento de 
sistemas.
Auditar todo o ciclo de construção do 
software, desde a sua concepção até a 
disponibilização em produção.
Auditoria de sistemas em produção.
Auditar todo o ambiente de produ-
ção e como o software se comporta 
nesse ambiente.
Auditoria no ambiente tecnológico.
Auditar a infraestrutura, as redes, os 
acessos e a governança de TI.
Auditoria em eventos específicos.
Auditar uma situação específica, como 
um ataque hacker.
Fonte: Elaborado pelo autor.
Os tipos de auditoria mencionados no Quadro 2 podem ser execu-
tados internamente, por uma empresa especializada ou por um órgão 
certificador, e cada atividade tem um nome em específico, conforme o 
quadro a seguir.
16 Segurança e auditoria de sistemas
Quadro 3
Responsáveis pela auditoria
Tipo de auditoria Responsáveis
Auditoria de primeira parte
É a auditoria realizada por uma equipe 
interna da organização.
Auditoria de segunda parte
É a auditoria realizada por uma equipe 
externa, a fim de certificar a integrida-
de. Por exemplo, um cliente quer vali-
dar se o fornecedor está aderente a um 
processo específico.
Auditoria de terceira parte
É a auditoria realizada por um órgão 
certificador oficial, por exemplo: órgão 
certificador ISO 27001.
Fonte: Elaborado pelo autor.
Na sequência, o auditor precisa definir a abordagem de trabalho 
a ser aplicada, para gerar o relatório final de auditoria. O profissional 
pode usar uma ou mais abordagens, sendo que a mais efetiva é aque-
la cujo auditor entende o contexto do cliente e consegue selecionar a 
opção que traz mais benefícios. As abordagens são:
 • Comparação do cenário atual com os critérios de auditoria: 
é analisada uma lista de itens, comparando com o cenário atual 
da empresa. Cada item é marcado como “em conformidade”, 
mediante evidências. Já os itens não aderentes devem ser 
marcados pela auditoria como “não conformes” e conter o deta-
lhamento dos motivos para a não conformidade.
 • Baseado em critérios oficiais: acontece a auditoria com base 
em alguma documentação oficial, como a ISO 27001 ou o Cobit. 
 • Ao redor do computador: não existe o envolvimento de 
muita tecnologia. O foco maior é em processos e tudo o que 
está em volta do parque tecnológico. Então, “essa abordagem 
envolve custos baixos” (IMONIANA, 2013, p. 19).
 • Por meio do computador: “envolve mais do que a mera 
confrontação de documentos-fonte”, de acordo com Imoniana 
(2013, p. 20). Aqui, são utilizados dados de testes para simu-
lação, e o auditor precisa de maior conhecimento acerca do 
processo de desenvolvimento e entrega de software.
 • Com o computador: é realizada a auditoria do sistema de 
informação pelo auditor, segundo os processos automatiza-
dos, garantindo maior cobertura de itens auditados, já que 
em processos manuais algum item pode ficar esquecido. 
Auditoria de sistemas da informação 17
Chegamos, então, ao último passo, que é a organização do tra-
balho de auditoria. Já houve a delimitação do escopo de trabalho 
e a definição dos tipos de auditoria e de quais abordagens serão 
utilizadas. Agora, é necessário organizar o trabalho para que nada 
seja esquecido. Para isso, é preciso cumprir as seguintes atividades:
 • planejar;
 • escolher a equipe;
 • programar a equipe;
 • executar os trabalhos e supervisionar;
 • validar o relatório final.
Na atividade de planejamento, desenha-se a matriz de risco. 
Essa matriz é atualizada gradativamente, à medida que a auditoria 
é executada. Nessa lista ficam evidentes quais são os itens em não 
conformidade e que estão colocando a empresa em risco. Além 
dessa matriz, a atividade de planejamento prevê o mapeamento da 
sequência de atividades a ser realizada. Essa sequência servirá de 
insumo para determinar o cronograma de trabalho e a quantidade 
de horas investida para gerar um relatório final. 
Com o total de horas definido, é possível dimensionar a equipe 
de trabalho necessária para realizar a auditoria em tempo aceitá-
vel. A escolha da equipe é a segunda atividade da organização do 
trabalho, devendo-se comparar o tamanho do desafio com a expe-
riência de cada auditor. 
A terceira atividade é a programação da equipe. O líder desse 
time de auditores irá, diariamente, validar a programação de ati-
vidades e distribuir novas tarefas, de acordo com as atividades 
correntes finalizadas. O acompanhamento da execução de traba-
lho é considerado a quarta atividade da organização; conforme os 
itens são finalizados, os relatórios são produzidos e a matriz de 
risco é preenchida. Com a conclusão de todas as atividades, o time 
de auditoria deve validar o relatório final e apresentá-lo à empresa. 
A reunião de apresentação costuma envolver pessoas de 
influência, para que os itens em não conformidade sejam prioriza-
dos. A decisão sobre qual item terá prioridade deve ser tomada por 
essas pessoas, bem como a definição de um prazo para a conclu-
são do item não conforme. Para finalizar a reunião, é estipulada 
uma nova data de auditoria e o processo é realizado.
No vídeo Fundamentos 
de auditoria de sistemas, 
disponível no canal 
Sidney Verginio da Silva, 
o professor apresenta os 
pilares de fundamento à 
auditoria de sistemas de 
informação. 
Disponível: https://www.youtube.
com/watch?v=U9q8Fk7sEjs&ab_
channel=SidneyVerginiodaSilva.Acesso em: 3 jan. 2022.
Vídeo
18 Segurança e auditoria de sistemas
Vale dizer que seguir os fundamentos da auditoria garante que 
os benefícios dessa prática sejam alcançados, tornando a empresa 
envolvida mais madura ao entregar os softwares.
1.2 Técnicas para auditoria de sistemas 
Vídeo
O processo de auditoria de sistemas de informação pode ser reali-
zado por meio de técnicas variadas. Segundo Imoniana (2013, p. 54), as 
técnicas têm por objetivo auxiliar o profissional a auditar 100% de de-
terminado tema e podem ser executadas utilizando a voz, as imagens, 
os documentos ou até os processos automatizados.
Ao aplicar, pelo menos, uma técnica de auditoria, o processo se torna 
mais produtivo e com custo operacional reduzido, gerado pelo retraba-
lho. Além disso, quando se aplica uma técnica, a qualidade é assegurada 
e o valor agregado é garantido. Assim, Imoniana (2013, p. 54) descreve 
em quais tarefas as técnicas de auditoria podem ser aplicadas:
 • Testes de controle gerais: um exemplo é validar se as versões 
aprovadas realmente estão em ambiente de produção. 
 • Testes de detalhes de transações: um exemplo é o recálculo de 
saldos após um conjunto de transações. Essa tarefa visa garantir 
a repetição de cenários, baseando-se em cenários específicos.
 • Analítico e substantivo: essa tarefa serve para identificar 
inconsistências ou anormalidades nos registros. 
 • Amostragem: essa tarefa gera insumos para serem inseridos no 
software de auditoria.
A técnica mais tradicional é composta de entrevistas e questioná-
rios. Os questionários podem ser feitos em papel ou com um re-
curso digital e trazem perguntas para validar a conformidade de um 
processo, o acesso a determinado recurso de hardware ou o acesso a 
um software propriamente. 
A aplicação desses questionários se dá por meio de entrevistas com 
pessoas cruciais na empresa, geralmente indicadas pela diretoria. Even-
tualmente, pode-se utilizar a prática de amostragem, para evitar a repe-
tição das pessoas que respondem ao questionário de auditoria. Nessa 
amostragem, é feito um sorteio de nomes e o número de pessoas sele-
cionadas é baseado na quantidade de papéis presente na empresa, por 
Auditoria de sistemas da informação 19
exemplo: se uma empresa possui 40 funcionários e a maioria deles é 
desenvolvedora de software, esse grupo deverá compor a maior parte 
da amostra de selecionados para responder ao questionário.
Figura 2
Técnica de entrevista
Na
dy
a_
Ar
t/
Sh
ut
te
rs
to
ck
Ao fim das entrevistas, os questionários ficarão armazenados e, na 
próxima auditoria, será realizada uma nova rodada de questionários, 
bem como serão comparados os resultados entre essa auditoria e a 
anterior. Essa prática é fácil e barata para ser viabilizada, mas pode ser 
muito demorada devido ao processo de entrevistas e à quantidade de 
pessoas que responde às questões.
Contudo, a técnica de questionários é muito eficiente para a valida-
ção de conformidade de processos. Quando existe a necessidade de 
auditar os dados de um software ou mesmo saber se ele está realizando 
a operação prevista, são necessárias outras técnicas; entre elas estão:
 • dados de testes;
 • rastreamento e mapeamento;
 • análise da lógica de programação;
 • simulação paralela.
Cada uma dessas técnicas apresenta uma finalidade, por exemplo, 
quando é preciso confirmar a efetividade do algoritmo programado, 
utiliza-se a técnica de análise da lógica de programação. Essa técnica 
pode ser realizada manualmente ou com softwares específicos que 
validam os algoritmos escritos em formato de código-fonte. O auditor 
20 Segurança e auditoria de sistemas
deve conhecer a documentação do sistema e validar se o software está 
operando em conformidade com o definido nos documentos.
Quando se deseja acompanhar determinado processamento de 
transações, é possível utilizar a técnica anterior, podendo ser amplia-
da com a adoção de itens de rastreabilidade e o mapeamento de exe-
cução. Essa prática também é chamada de accountability e pode ser 
implementada por meio do uso de frameworks que gerenciam os logs 
de operações durante a execução do software. Com esses gerenciado-
res de log, há como saber qual usuário executou uma operação e o 
horário em que se deu a transação.
Para automatizar a técnica de análise da lógica de programação, 
utiliza-se a técnica de dados de teste, que é comumente aplicada com o 
objetivo de testar os controles programados. Para que essa técnica seja 
efetiva, é necessário incluir vários cenários de testes. Automatizando os 
testes e os dados de entrada, é possível repeti-los por diversas vezes ou 
pelo menos uma vez antes da liberação de uma nova versão. 
Por fim, há a técnica de simulação paralela, que envolve o uso de 
um programa específico para fazer a mesma operação do software. Por 
meio dessa técnica, o auditor busca confrontar os resultados de ambos 
os softwares, na expectativa de que os resultados sejam semelhantes. 
Um exemplo de aplicação dessa técnica é quando há necessidade de 
auditar um software que emita nota fiscal eletrônica. A simulação pa-
ralela pode ser feita pelo auditor, usando um software disponibilizado 
pela Receita Federal para simular a criação de notas fiscais. O resulta-
do esperado é que tanto a nota fiscal em PDF quanto o arquivo XML 
tenham os dados semelhantes. Caso haja divergência, o auditor deve 
evidenciar quais informações estão distorcidas.
A aplicação das técnicas mencionadas é conhecida como técnicas de 
auditoria assistidas por computador (TAAC). Imoniana (2013, p. 63) de-
talha os passos que devem ser observados na realização de um TAAC:
 • estabelecer os objetivos da aplicação de TAAC;
 • determinar quais são os dados a serem utilizados para as técnicas;
 • determinar a forma de acesso aos dados;
 • identificar os arquivos e bancos de dados a serem testados;
 • entender as entidades de relacionamentos das tabelas de dados 
onde a base de dados é examinada;
Auditoria de sistemas da informação 21
 • definir os testes e procedimentos de testes, inclusive as 
transações, as contas e os grupos de contas afetados;
 • definir os relatórios esperados;
 • programar, junto ao cliente e à sua área de informática, as cópias 
de arquivos ou base de dados que devem ser geradas em um 
período predefinido;
 • identificar o auditor que processará a aplicação de TAAC;
 • estimar os custos de TAAC;
 • certificar-se de que os processos de TAAC foram adequadamente 
executados e os papéis de trabalho documentados;
 • avaliar os resultados.
Um cuidado que o auditor deve ter é o de aplicar a técnica corre-
ta, segundo um processo definido. Alguns exemplos desses processos 
são: ISO 27001, ISO 12207, ISO 9126 e Cobit.
A ISO 27001 é aplicada para avaliar e auditar os processos de segu-
rança da informação de uma empresa. Quando o foco são os processos 
de engenharia de software e o seu ciclo de vida, a abordagem proposta 
pela ISO 12207 pode ser tomada por base. Já quando há necessidade 
de se auditar os processos de qualidade, a abordagem da ISO 9126 é 
a adequada. Toda ISO é considerada uma norma internacional que re-
sulta de diversos processos e cada uma tem a sua abordagem distinta. 
Logo, caso uma empresa esteja aderente a determinada norma, passa 
a ter o direito de usar o selo de certificação. 
Outro modelo de certificação é o Cobit, acrônimo para Control 
Objectives for Information and Related Technologies. Cobit é considerado 
um framework de boas práticas para a governança da tecnologia da 
informação e é representado por componentes que se inter-relacionam.
Go
od
_S
to
ck
/S
hu
tte
rs
to
ck
Figura 3
Cobit
22 Segurança e auditoria de sistemas
Ao aplicar uma técnica de auditoria com base no Cobit, serão analisa-
dos os requisitos de negócio, os recursos de TI e os processos de TI. Nos 
requisitos de negócio serão observados os aspectos de efetividade, efi-
ciência, confidencialidade, integridade, disponibilidade, conformidade e 
confiabilidade. Já no item recursosde TI serão analisados os aspectos de 
aplicações (softwares) utilizados, infraestrutura, informações e pessoas. 
Por fim, serão explorados os processos de TI, segundo os aspectos de 
domínio, processos e atividades. A figura a seguir é conhecida como 
cubo do Cobit e sintetiza os pontos a serem auditados.
Figura 4
Cubo do Cobit
Pr
oc
es
so
s 
de
 T
I
Requisitos de negócios
Efe
tiv
ida
de
Efi
ciê
nc
ia
Co
nfi
de
nc
ial
ida
de
Int
eg
rid
ad
e
Dis
po
nib
ilid
ad
e
Co
nfo
rm
ida
de
Co
nfi
ab
ilid
ad
e
Domínios
Processos
Atividades
Ap
lic
aç
õe
s
In
fr
ae
st
ru
tu
ra
In
fo
rm
aç
ão Pe
ss
oa
s
Re
cu
rso
s d
e T
I
Fonte: Adaptada de Souza; Ferreira, 2013.
Como visto, as técnicas para serem utilizadas durante o processo 
de auditoria de sistemas de informação têm suas particularidades, as 
quais geram resultados específicos; nesse sentido, mesclá-las ajuda o 
auditor a obter êxito em seu trabalho. Além do uso das técnicas, o audi-
tor deve aplicá-las com base em algum modelo, como a ISO ou o Cobit.
1.3 Plano de contingência e de 
recuperação de desastres Vídeo
Um dos itens a ser avaliado em auditoria de sistemas de informação 
é se há um plano de contingência e recuperação de desastres. Situações 
como ataques, indisponibilidade de servidores e roubo de informações 
são exemplos de desastres em um sistema de informação. 
No vídeo Técnicas para 
auditoria de sistemas infor-
matizados, publicado pelo 
canal Tribunal Regional do 
Trabalho da 2ª Região, Hi-
talo Fernandes Miné Diniz 
apresenta o case de boas 
práticas e técnicas de 
auditoria em sistemas in-
formatizados aplicados ao 
setor judiciário do Tribunal 
Regional do Trabalho (TRT) 
de Minas Gerais. 
Disponível em: https://www.
youtube.com/watch?v=epCYKx-
mjiEE&ab_channel=TribunalRegio-
naldoTrabalhoda2%C2%AARegi%-
C3%A3o. Acesso em: 3 jan. 2022.
Vídeo
Auditoria de sistemas da informação 23
Imagine a seguinte situação: uma empresa possui diversos portais 
de vendas na web. Um deles foi atualizado recentemente, pois no-
vas funcionalidades foram desenvolvidas pelos programadores e 
elas permitirão reduzir o tempo de espera para o pagamento de uma 
compra. Mas algo passou despercebido nessa atualização: uma re-
gra de acesso ao banco de dados foi deixada no código-fonte, o que 
permite a entrada de qualquer usuário. Com isso, um hacker conseguiu 
acessar a base de dados e apagou informações referentes a endereços 
de entrega; sem isso, os pedidos não podem ser enviados aos clientes. 
Além dessa alteração não autorizada de dados, o hacker conseguiu 
criptografar os dados de produção e exige um valor em dólares para 
devolver o acesso à base de dados. A empresa está parada. E agora? 
O que fazer?
O exemplo trazido mostra claramente uma situação de desastre, de 
modo que é preciso um “plano B” para retomar a operação de vendas 
de maneira segura. Esse plano é chamado de contingência, para que os 
negócios da empresa continuem em funcionamento. Um processo de 
contingência deve estar mapeado em um documento chamado plano 
de contingência e de recuperação de desastres. Esse documento também 
é conhecido como DR (do inglês disaster recovery). Para Imoniana (2013, 
p. 167), “esse plano detalha as medidas operacionais necessárias e do-
cumentadas que devem ser seguidas em casos de indisponibilidade de 
algum recurso de informática, evitando que o tempo no qual os equipa-
mentos permaneçam parados, acarrete perdas materiais aos negócios 
da empresa”. A inexistência desse documento pode comprometer os 
contratos e a vida da empresa, caso sofra algum desastre.
Além da existência desse documento, a sua aplicação em situações 
controladas é indispensável, pois, então, será possível ter a certeza de 
que o plano é efetivo e atende às necessidades de contingenciar os 
negócios da organização.
Cada ação de contingência presente no material deve trazer um 
responsável designado. Sugere-se, assim, que as pessoas selecionadas 
sejam diferentes daquelas que executam as funções operacionais dia-
riamente, para evitar conflitos de responsabilidades. 
Esses responsáveis designados formarão um grupo ou uma equipe 
de contingência. Eles precisam contar com um meio de comunicação 
rápido na troca de mensagens, que esteja sempre disponível, permi-
tindo o envio de documentos, áudios, vídeos e textos. Os aplicativos 
24 Segurança e auditoria de sistemas
de mensagens instantâneas, como Telegram ou WhatsApp, são boas 
sugestões para a comunicação da equipe de contingência.
O auditor deve se certificar de que as perguntas a seguir apresentam 
respostas afirmativas; com isso, tem-se um plano de contingência efeti-
vo. Esta lista é baseada nas afirmações de Imoniana (2013, p. 168):
• Há planos de contingência desenvolvidos que contemplam todas as 
necessidades de contingência da organização?
• Os planos abrangem os aspectos físico, lógico, de redes, de proprie-
dade intelectual, de pessoas e de transações nos softwares?
• Existe uma equipe de contingência definida?
• A equipe de contingência está preparada para as eventualidades?
• A equipe de contingência tem um meio efetivo e ininterrupto 
de comunicação?
• Os planos de contingência foram testados nos últimos dois meses?
• Os backups estão atualizados com dados do dia anterior?
• Os backups podem ser recuperados com pouca ou 
nenhuma dificuldade?
• Existem relatórios gerenciais que facilitam o acompanhamento de 
tentativas de ataques que podem ocasionar desastres?
• Se existem, esses relatórios são confiáveis?
• As políticas de acesso às ferramentas foram revisadas nos últimos 
três meses?
• Existem servidores com atualizações críticas pendentes?
• Existem sistemas operacionais com atualizações críticas pendentes?
• Existem softwares piratas ou sem licença no ecossistema de informá-
tica da empresa?
• Existem softwares com atualizações críticas pendentes?
• As bibliotecas e os frameworks utilizados no desenvolvimento de 
software possuem atualizações críticas pendentes?
M
on
ki
k/
Sh
ut
te
rs
to
ck
Auditoria de sistemas da informação 25
Caso alguma dessas perguntas não tenha uma resposta afirma-
tiva, o auditor deve atribuir uma classificação de risco para ela. Essa 
classificação vai de alto risco e risco intermediário até baixo risco. Além 
disso, o auditor deve detalhar qual foi a evidência que comprometeu a 
resposta afirmativa da pergunta analisada.
A seguir, vamos conhecer um exemplo de plano de contingência, 
mais focado nos recursos de redes.
NOME DO DOCUMENTO: plano de contingência para redes.
DATA CRIAÇÃO: 20/01/2020.
DATA ÚLTIMA ATUALIZAÇÃO: 22/12/2020.
Escopo do plano 
Este plano aborda somente os casos com níveis de risco alto e/ou interme-
diário no ambiente de redes da empresa XPTO. 
Classificação de softwares críticos que dependem essencialmente 
de redes
• Portal e-Commerce XPTO.
• Software de folha de pagamento.
Análise de riscos potenciais
Os riscos potenciais no ambiente de redes são:
Riscos de tecnologia da informação Alto Médio Baixo
Switch – equipamento responsável pelo 
gerenciamento de informações na rede
X
Hub – equipamento responsável por re-
transmitir sinal na rede
X
Fibra ótica – fornecedor A X
Fibra ótica – fornecedor B X
Malwares na rede local X
Contingência em relação aos recursos com riscos
a) Switch: caso o principal switch pare de funcionar, todas as rotas de 
comunicação da empresa devem ser alteradas automaticamente 
para o switch secundário que está em outro grupo de IP. O segundo 
switch deve conter os dados do switch principal, com diferença de 
dados de, no máximo, um dia.
M
on
ki
k/
Sh
ut
te
rs
to
ck
(Continua)
26 Segurança e auditoria de sistemas
b) Hub: não há contingência para esse aparelho, pois ele apresenta risco 
baixo. Caso algum pare de funcionar, deve ser substituído por um 
novo ou, então, os funcionários deverão utilizar o Wi-Fi da organiza-
ção em vez da rede cabeada via hub.
c) Fibra ótica – fornecedor A: se a comunicação com a internet por meio 
dessa fibrafalhar, automaticamente o sistema de redundância deve 
entrar em operação, utilizando o fornecedor de fibra ótica B.
d) Fibra ótica – fornecedor B: se a comunicação com o fornecedor 
B estiver indisponível, independentemente da disponibilidade do 
fornecedor A, deve-se enviar um alerta automático para o grupo de 
contingência para o eventual uso de comunicação via dados móveis, 
de preferência 4G ou superior. 
e) Malwares na rede local: bloquear automaticamente as máquinas 
identificadas com o malware e adicionar o IP desses computadores a 
uma lista de computadores sem acesso à rede local de dados.
Matriz de responsabilidades
Nome Responsabilidade Telefone de contato
Wagner 
Mendes Voltz
Disponibilidade de acesso 
à internet via fibra ótica 
ou redes móveis.
(12) 3456-7890
Cleber Molina
Gerenciamento e dispo-
nibilidade contínua dos 
switches.
(09) 8765-4321
Micheli Acrabri
Bloquear a propagação 
de malwares na rede local.
(99) 9876-6542
Airton Senna
Bloquear a propagação 
de malwares na rede local.
(88) 1111-2222
M
on
ki
k/
Sh
ut
te
rs
to
ck
No exemplo apresentado, temos um plano de contingência para re-
des. Esse não pode ser o único plano de contingência de uma empresa, 
pois diversos outros pontos precisam ser observados quando se tra-
ta de tecnologia da informação. Esse documento deve ser verificado a 
Auditoria de sistemas da informação 27
cada três meses e uma simulação de desastre deve ser feita a cada dois 
meses, para validar se o documento está aderente. 
A soma dos vários planos de contingência deve compor o business 
continuity planning (BCP), que é o planejamento da empresa para 
enfrentar incidentes nos processos operacionais que possam pôr em 
risco as missões empresariais e, sobretudo, a saúde financeira. Se-
gundo Imoniana (2013), com o BCP, são assegurados a continuidade 
do desenvolvimento de produtos ou serviços e o apoio aos consumido-
res, de modo ininterrupto, bem como a viabilidade corporativa, mesmo 
após a exposição a um desastre.
O BCP é composto dos seguintes itens: 
 • Plano de reinicialização de negócios ou, em inglês, business 
resumption planning (BRP), no qual são mapeados os processos 
essenciais e críticos para que o negócio continue operando em con-
formidade com os níveis planejados, mantendo o nível esperado 
de perdas, sem surpresa. Esse documento não pode ser apenas de 
TI; as áreas de marketing e relacionamento com o cliente precisam 
estar em sinergia com esse plano, de modo que o cliente não se 
sinta prejudicado pela eventual interrupção dos serviços prestados.
 • Gestão de crises, ou crisis management (CM), que é um comitê que 
busca respostas às crises pontualmente e em tempo hábil, a fim de 
minimizar os efeitos sobre a lucratividade e a imagem corporativa. 
 • Planos de contingência e de recuperação de desastres de todas as 
áreas envolvidas com a continuidade de negócio da organização. 
 • Testes de emergência e de recuperação ou, em inglês, emergency 
preparedness (EP), que são os testes periódicos para validar se 
os planos de contingência estão aderentes ao que foi definido 
e, também, para validar o funcionamento do comitê de crise e a 
reinicialização dos negócios (BRP). Esses testes devem ser plane-
jados e controlados; caso algum ponto falhe, o comitê de crise 
deve solicitar a priorização do problema encontrado junto à dire-
toria, para que a correção seja feita o mais rápido possível. 
Auditar frequentemente o BCP garante um fluxo definido e repeti-
tivo de retomada de negócios em meio a situações inesperadas, redu-
zindo o risco de descontinuidade das operações. Além disso, a auditoria 
28 Segurança e auditoria de sistemas
no BCP garante que a alta direção perceba maturidade e confiança na 
retomada de operações, uma vez que eles receberão os relatórios que 
atestam a integridade do BCP. Ao realizar o processo de auditoria do 
BCP, são mantidas as responsabilidades pelas atualizações dos pro-
cessos com os seus respectivos promotores. Imoniana (2013, p. 195) 
sugere o seguinte quadro para checar a integridade do BCP: 
Quadro 4
Validação do BCP 
Controles/Procedimentos de testes
Sim / Não 
/ Não 
avaliado
Respostas 
e observa-
ções
Gestão de crise
As funções de gestão de crises de continuidades são 
delineadas?
Existe alguma pessoa a que se deve recorrer quanto às 
questões de continuidade?
Quem é essa pessoa? Cite o nome e o papel que ela 
exerce.
Descreva, sucintamente, a atribuição dessa pessoa e 
como ela atua na gestão de crises.
Os funcionários são conscientizados a respeito da im-
portância estratégica de BCP? 
Reuniões periódicas são realizadas para transmitir 
questões de continuidade para os funcionários?
Existem evidências, em agendas, de que as reuniões do 
BCP estão ocorrendo?
Teste de validade
Com qual prazo se pode obter informações e orienta-
ções sobre a continuidade das operações? 
Qual é o prazo para obter dados sobre continuidade? 
24h? 1 semana? 10 dias? 30 dias? Outro?
Somente as pessoas autorizadas possuem acesso a es-
sas informações?
Teste de integridade
A empresa possui um banco de dados onde todas as 
orientações quanto aos possíveis problemas de conti-
nuidades são contempladas e as respostas apontadas?
As informações que explicam o BCP são genéricas?
As informações que explicam as estratégias e os compo-
nentes dessas estratégias são detalhadas?
Quando foi realizado o último teste do BCP?
(Continua)
Auditoria de sistemas da informação 29
Controles/Procedimentos de testes
Sim / Não 
/ Não 
avaliado
Respostas 
e observa-
ções
Treinamentos para a equipe do BCP são feitos periodi-
camente?
Quem promove esses treinamentos?
Quando será o próximo teste do BCP?
Existem controles que garantem a comunicação entre o 
sistema de gestão de risco da empresa e o BCP?
Quando foi realizada a última atualização do BCP?
Você considera que falta algum ponto a ser coberto pelo 
BCP?
Existe procedimento que propicie melhoria contínua 
por meio de benchmarking?
Fonte: Imoniana, 2013, p. 195.
Em tempos de transformação digital, em que as empresas estão 
aderindo cada vez mais à digitalização de serviços, ter um plano realista 
e eficiente para a contingência dos negócios é vital para evitar perdas 
financeiras. Quando esse plano vai além da TI, torna-se o BCP, e todas 
as áreas passam a ser envolvidas. Manter a atualização e a efetivida-
de desse plano é de responsabilidade do comitê de crise, e o auditor 
será um parceiro na validação da efetividade do BCP e dos planos de 
contingência.
No vídeo Backup X Disaster 
Recovery, disponível no 
canal ADDEE, Rodrigo 
Gonzala fala sobre as 
semelhanças e diferenças 
existentes entre esses 
dois temas. 
Disponível em: https://www.
youtube.com/watch?v=IIy4Gtan-
XxI&ab_channel=ADDEE. Acesso 
em: 3 jan. 2022.
Vídeo
CONSIDERAÇÕES FINAIS 
Neste capítulo foram apresentados os fundamentos que alicerçam a 
auditoria de sistemas de informação. Esse trabalho é realizado por um au-
ditor competente e com domínio sobre as diversas abordagens e técnicas 
existentes. O seu papel e o resultado entregue após as auditorias reali-
zadas fazem com que a empresa tenha a continuidade dos seus negó-
cios. O auditor não deve ser visto como carrasco ou “dedo duro” (que só 
aponta as falhas dos outros), mas sim como um parceiro, que garante 
a efetividade nos processos, a identificação de riscos nos negócios e as 
oportunidades de melhorias. 
30 Segurança e auditoria de sistemas
ATIVIDADES
Atividade 1
O processo de auditoria pode ser realizado de diversas maneiras 
e cada abordagem tem um nome. Diferencie as abordagens de 
auditoria de segunda parte e de terceira parte.
Atividade 2
Ao realizar uma auditoria, o auditor deve utilizar mais de uma 
técnica. Explique o porquê.
Atividade 3
Você é um auditor e percebeu que a equipe de contingência está 
utilizando e-mails para a comunicação. Você considera essa prática 
aderente ao plano de contingência da organização? Justifique a 
sua resposta.
REFERÊNCIAS
HUMBLE, J.; KIM, G. Accelerate:the science of lean software and devops – building and 
scaling high performing technology organizations. IT Revolution, 2018. 
IMONIANA, J. O. Auditoria de sistemas de informação. 2. ed. São Paulo: Atlas, 2013.
SOUZA, J.; FERREIRA, A. N. Metamodelo do framework COBIT de governança de 
TI. JISTEM – Journal of Information Systems and Technology Management, v. 10, p. 529, 2013.
Execução de auditorias 31
2
Execução de auditorias
A rotina de um profissional auditor é composta de muitos detalhes, e para 
a execução das auditorias, diversos itens devem ser analisados. Quando elas 
se referem ao ambiente de tecnologia da informação (TI), algumas perguntas 
importantes a se fazer são:
 • Existem controles para reduzir os riscos de fraudes?
 • Como é realizada a aquisição, o desenvolvimento e a manutenção de 
softwares?
 • Como é a gestão de aquisição e uso dos diversos hardwares da empresa?
 • Existe controle no acesso a informações lógicas?
 • Todos esses itens podem ser auditados de alguma maneira?
Ao responder a essas perguntas, o auditor consegue obter insumos para 
demonstrar a importância da sua atuação na organização. Neste capítulo, deta-
lharemos como deve ser a execução da auditoria em cada um dos itens observa-
dos. Ao final do estudo, esperamos que você consiga aplicar as várias auditorias 
em uma empresa que tenha um setor de tecnologia da informação. Vamos en-
tender como elas são executadas?
Com o estudo deste capítulo, você será capaz de:
 • compreender como executar a auditoria de sistemas operacionais e 
organizacionais;
 • entender como executar a auditoria em softwares que sofrem alterações;
 • compreender como executar a auditoria em ativos computacionais de uma 
organização;
 • entender como executar a auditoria dos privilégios de acesso dentro de 
sistemas.
Objetivos de aprendizagem
2.1 Auditoria de controles 
Vídeo
Todos os processos de auditoria devem ser iniciados com o escopo de tra-
balho estabelecido e a clareza sobre qual objetivo deve ser alcançado. Todos os 
itens de auditoria precisam ser respondidos com evidências que comprovem a 
resposta dada pelo entrevistado.
32 Segurança e auditoria de sistemas
Em uma empresa de tecnologia da informação, é necessário audi-
tar os controles, visando dificultar as fraudes nos processos manuais e 
tecnológicos que possam existir. Imoniana (2013, p. 89) explica que “o 
principal objetivo de auditoria dos controles organizacionais da área de 
informática é testar a grande essência de controle interno, promover a 
eficiência das operações e fomentar a maior adesão às políticas pres-
critas pela gerência com maior foco na responsabilidade”.
O controle interno de uma empresa pode ser dividido em duas cate-
gorias: organizacional e operacional. Enquanto o primeiro olha o todo da 
organização, o segunda visa manter a operação funcionando com eficiên-
cia. Por meio deles, a empresa busca alcançar os objetivos de negócios, 
reduzir os riscos de fraudes e as perdas financeiras, bem como minimizar 
a saída de colaboradores (turnover). Entre as atividades que são de respon-
sabilidade do controle organizacional, podemos citar as seguintes:
• Definição das responsabilidades operacionais dos colaboradores.
• Coordenação do orçamento para a informática.
• Desenvolvimento e implementação das políticas globais de 
informática.
• Definição dos modelos de contrato dos colaboradores.
• Intermediação de contratos de prestação de serviços com terceiros 
que trabalham com tecnologia da informação.
• Criação e desenvolvimento de políticas salariais e plano de carreira.
• Desenvolvimento de plano de capacitação.
• Definição de política para prêmios e bonificações.
Quando os controles organizacionais estão ou não definidos, mas 
não são efetivos, os gerentes passam a lidar com os colaboradores de 
pouca iniciativa, pois estes não sabem como serão avaliados, nem como 
poderão evoluir em suas carreiras. Isso gera desmotivação, que pode 
se misturar ao sentimento de injustiça, caso não haja clareza sobre a 
forma de a empresa realizar promoções e bonificações. Um exemplo 
de bonificação que costuma gerar insatisfação quando não é bem de-
finida é a divisão dos lucros (PLR), pois alguns colaboradores podem 
receber consideráveis valores e outros uma quantia insignificante.
Outro sintoma que identifica problemas nos controles organiza-
cionais é a desorganização no trabalho. A falta de objetividade sobre 
quais são as responsabilidades de cada papel desempenhado faz com 
Execução de auditorias 33
que o trabalho fique desordenado e pouco produtivo. Dessa forma, os 
gerentes não têm certeza se os colaboradores estão burlando algum 
processo ou se alguém está deixando de fazer um trabalho essencial 
(como pagar um imposto ou realizar o apontamento de horas tra-
balhadas na execução de um serviço, para que o gestor tenha uma 
noção do valor investido no trabalho).
Para resolver esses problemas, a empresa deve identificar as res-
ponsabilidades de cada tarefa desempenhada. Isso deve compor a 
descrição dos cargos, na qual devem estar claras quais são as tare-
fas de cada pessoa e quais funções se conectam. As atividades com 
responsabilidades compartilhadas são chamadas de zona cinzenta. 
Ela pode tornar o trabalho menos eficaz, porque mais de um respon-
sável por algo causa a lentidão do sistema produtivo, já que serão 
duas pessoas para tomar uma decisão e, talvez, nenhuma delas de-
seje se responsabilizar.
O exemplo a seguir é uma proposta para a descrição de políticas 
de responsabilidades e descrição de cargos que pode ser aplicada pelo 
auditor na execução do trabalho:
Descrição de cargos
Cargo: desenvolvedor de software
O cargo contempla as seguintes funções:
 • Transformar em código-fonte as necessidades do usuário, conforme a prio-
rização do gerente de produto.
 • Criar código-fonte com testes unitários.
 • Apontar corretamente as horas investidas em cada trabalho.
Zona cinzenta para esse cargo:
Função Zona cinzenta ligada a qual outro cargo?
Atualização de sistemas em 
produção
Administrador dos servidores
Testes de negócio Testadores
M
on
ki
k/
Sh
ut
te
rs
to
ck
(Continua)
O ditado popular que 
diz “cachorro com dois 
donos morre de fome” 
pode ser comparado à 
chamada zona cinzenta, 
pois ela faz com que uma 
tarefa seja negligenciada 
justamente por ter mais 
de um responsável.
Curiosidade
34 Segurança e auditoria de sistemas
Cargo: testador
O cargo contempla as seguintes funções:
 • Criar testes de aceitação no momento de definição do trabalho a ser 
desenvolvido.
 • Validar se todos os cenários estão corretos para gerar a versão do software.
 • Apontar corretamente as horas investidas em cada trabalho.
Zona cinzenta para esse cargo:
Função Zona cinzenta ligada a qual outro cargo?
Definir testes de aceitação Gerente do produto
Testes de negócio Testadores
M
on
ki
k/
Sh
ut
te
rs
to
ck
Uma boa prática é realizar a criação dessas descrições em peque-
nos grupos, contendo uma pessoa do RH (recursos humanos), um ou 
mais gerentes e alguns colaboradores que atuam nesses cargos, pois 
nada melhor que ouvir as pessoas que estão no dia a dia do trabalho 
apresentarem as suas funções. A disseminação do conteúdo definido é 
de responsabilidade de cada gerente junto aos seus liderados.
Com esse descritivo, é possível aperfeiçoar os controles e definir as 
políticas organizacionais, como as políticas para evolução na carreira e 
que geram reajustes salariais. Outra política fácil de definir com a des-
crição de cargos é o controle de acesso a dados da empresa. Quando 
não há entendimento dos cargos, a gestão do acesso às ferramentas e 
aos dados fica comprometida.
O auditor, ao se deparar com a situação de ausência desses contro-
les, deve elaborar um relatório detalhado, evidenciando os pontos de me-
lhoria, e atribuir criticidade alta para a solução desse problema. Quando há 
esses controles, também precisa utilizar algum documento para eviden-
ciar o que foi auditado. O quadro a seguir trazuma sugestão de perguntas 
propostas para a execução da auditoria de controles organizacionais.
Execução de auditorias 35
Quadro 1
Perguntas de auditoria para controles organizacionais e operacionais
Cliente: Data:
Auditoria realizada por:
Sim / Não / 
Não avaliado
Respostas e 
observações
Segregação de responsabilidades da área de informática
Existe a separação de atividades consideran-
do a descrição de cargos? Evidencie.
Existem regras de acesso aos dados confor-
me os descritivos de cargos?
Explique, com as suas palavras, qual é a descri-
ção do seu cargo. A explicação dada atende ao 
que está no documento oficial da organização?
Quais são as zonas cinzentas do seu cargo?
A implementação de normas administrativas visa, constantemente, deli-
mitar as responsabilidades de cada um.
Quando foi a última vez que o seu gestor ex-
plicou as responsabilidades do seu cargo? Foi 
a menos de 5 meses?
Políticas salariais e plano de carreiras
A empresa possui um plano de cargos e sa-
lários?
Quando foi a última revisão desse plano?
Treinamento do pessoal
Existem planos de treinamento para todos do 
seu cargo?
Você percebe que há planos de treinamento 
para outros cargos?
Prêmios e bonificações
Existem planos para premiar e bonificar não só 
por produtividade, mas também por excelência?
A política de premiação e bonificação é clara 
e pública?
Fonte: Adaptado de Imoniana, 2013, p. 90.
Por meio do Quadro 1, bem como do entendimento do objetivo dos 
controles, o auditor conseguirá validar o processo e garantir as evidên-
cias para sugerir melhorias ou atestar a excelência da área de TI.
No vídeo Auditoria e 
segurança da informação: 
controles organizacio-
nais, o professor Giulio 
Domenico Bordin apre-
senta um plano referente 
à definição dos controles 
organizacionais pela área 
de TI, com o apoio da 
gerência da área de RH.
Disponível em: https://
www.youtube.com/
watch?v=f4LkMD57dZM&t=71s . 
Acesso em: 6 jan. 2022.
Vídeo
36 Segurança e auditoria de sistemas
2.2 Auditoria de sistema 
Vídeo
O mundo está passando por uma transformação que foi acelerada 
pela Pandemia de Covid-19. Diversas empresas estão migrando a sua 
operação física para o digital, por meio do uso da internet e do desen-
volvimento de aplicativos que conectem o consumidor à empresa.
Dada essa necessidade, uma empresa pode optar por ter a sua pró-
pria equipe de tecnologia para o desenvolvimento de software ou ter-
ceirizar a uma especializada. Todo o processo de aquisição de software, 
desenvolvimento, manutenção e documentação de sistemas é o foco 
da auditoria de sistemas. Segundo Imoniana (2013, p. 96), a auditagem 
visa responder às perguntas:
 • Há procedimento de formalização sobre a real necessidade de 
um novo sistema?
 • As especificações são feitas de modo diligente, confrontando os 
conhecimentos dos usuários com os do analista de sistemas, vi-
sando dar suporte aos projetos?
 • O desenvolvimento de testes e a instalação na produção aconte-
cem sem traumas para os usuários?
 • Há informações apresentadas para que os usuários possam de-
cidir entre a aquisição e o desenvolvimento interno?
 • O desenvolvimento segue os padrões e utiliza todas as ferramen-
tas para alinhá-lo com os sistemas já existentes?
 • As questões básicas operacionais, de funcionalidade, tecnologia, 
pós-vendas, segurança e de análise de custos e benefícios, entre 
outras são esclarecidas quando da decisão de compras externas?
 • Os usuários são treinados para utilizar os sistemas com todos 
os potenciais que possuem?
 • As manutenções são feitas sem a interrupção das operações 
normais da empresa?
 • As documentações são consistentes e disponíveis para orientar 
os usuários?
O auditor precisa entender qual é o modelo de gestão de softwares 
adotado pela empresa para iniciar a auditoria. Na Figura 1, a seguir, te-
mos a representação dos fluxos possíveis. Tudo começa com a análise 
da necessidade e viabilidade de um software. Caso a empresa entenda 
que, realmente, deva existir esse novo software, dois caminhos podem 
ser seguidos: a aquisição de uma solução pronta ou o desenvolvimen-
to do software de modo personalizado. Na segunda opção, o auditor 
deverá observar as etapas de especificação, programação e testes do 
software e, na sequência, as etapas de testes de integração, implanta-
ção, documentação e controle de versão. Essas últimas etapas também 
fazem parte da auditoria em softwares que foram adquiridos.
Figura 1
Fluxo de auditoria de sistema
Análise da 
necessidade e 
viabilidade de um 
novo software
Auditar a 
especificação
Desenvolvimento personalizado
Auditar a 
programação
Auditar os 
testes no 
software
Aquisição de 
solução 
pronta
Auditar os 
testes de 
integração
Auditar a 
implantação
Auditar a 
documentação
Auditar o 
controle de 
versão
Fonte: Elaborada pelo autor.
Toda alteração em um software gera riscos à operação dos ne-
gócios, pois pode não ser implementada conforme o esperado, pro-
vocando, assim, os erros – também conhecidos como bugs –, que 
podem inviabilizar a sequência de um processo. Por exemplo, em 
diversas cidades brasileiras o transporte coletivo é realizado por 
ônibus que não possuem cobradores de passagem. O pagamento é 
feito via cartões aproximados a um aparelho que libera a catraca de 
acesso ao ônibus.
Figura 2
Forma eletrônica de pagamento do transporte coletivo
Execução de auditoriasExecução de auditorias 3737
Ro
ss
He
le
n/
Sh
ut
te
rs
to
ck
38 Segurança e auditoria de sistemas
Esse aparelho possui um software responsável pela leitura do car-
tão e validação da quantidade de créditos que o passageiro tem. Caso 
o software sofra uma atualização e apresente erros, muitas pessoas 
não poderão usar o transporte coletivo, pois o pagamento por apro-
ximação de cartão estará indisponível. Um erro como esse costuma 
gerar um impacto negativo na vida das pessoas, e a auditoria de siste-
mas objetiva reduzir esse risco.
Além da auditoria de sistemas, várias práticas são realizadas duran-
te o desenvolvimento e a implantação (ou atualização) de um software. 
Entre elas, podemos citar a codificação de software guiada por testes 
unitários, o uso das práticas de DevOps e a implantação de uma ge-
rência de configuração do software. As três geram rastreabilidade do 
fluxo de trabalho e das alterações executadas em um software, sendo 
possível fazer a auditoria de modo automatizado, bem como retornar 
a cenários anteriores do software. No exemplo anterior, se a empresa 
que fez a alteração no software tem DevOps e gerência de configura-
ção, rapidamente é feito um downgrade (retorno à versão anterior) e o 
sistema de pagamento do ônibus é normalizado.
Enquanto um programador está trabalhando na codificação de um 
software, ele precisa testar as alterações manualmente. Alguns desses 
testes são passíveis de esquecimento, dependendo da complexidade 
do software. Uma forma de automatizar esse procedimento é aplicar 
a prática de testes unitários, ou seja, frações de código-fonte que rea-
lizam testes automatizados nos códigos-fonte alterados pelo progra-
mador. Com isso, os testes podem ser repetidos quantas vezes forem 
necessárias pelo próprio computador.
Os testes unitários são essenciais para adotarmos a gerência de 
configuração e DevOps. As duas práticas estão interconectadas, e po-
demos afirmar que a gerência de configuração é o conceito, enquanto 
o DevOps são as diversas ferramentas que aplicam esse conceito.
O gerenciamento de configuração inclui os controles de mudanças 
que documentam os procedimentos de alterações e como serão im-
No vídeo Engenharia de 
software – aula 07: geren-
ciamento de configuração, a 
professora Juliana Saraiva 
apresenta o processo 
de gerenciamento de 
configuração, que é uma 
implementação auditável 
de mudanças em software.
Disponível: https://www.youtube.
com/watch?v=gMEm4BY_I6c. 
Acesso em: 6 jan. 2022.
Vídeo
https://www.youtube.com/watch?v=gMEm4BY_I6c
https://www.youtube.com/watch?v=gMEm4BY_I6c
Execuçãode auditorias 39
plementadas as solicitações de mudança que podem ser submetidas à 
aprovação por um comitê ou por pessoas com autoridade para aprovar 
ou recusar (HELDMAN, 2006). A prática de DevOps traz ferramentas 
como os versionadores de código-fonte e as de construção de versões 
de software, que implementam esses controles de mudança.
Ao realizar uma mudança em um software, o programador poderá 
incluir novos códigos, alterar um com erro ou melhorar um em funcio-
namento para torná-lo mais compreensível. A cada alteração, algumas 
regras devem ser seguidas pelos programadores, testadores e implan-
tadores de novas versões do software:
 • A documentação de sistemas deve ser atualizada, e a nova publi-
cação atualizada em produção.
 • As mudanças no programa devem ser testadas pelo desenvol-
vedor e testador e pelo solicitante da alteração (podendo ser al-
guém interno ou mesmo o usuário final).
 • A aprovação da mudança deve ser documentada e com base em 
evidências de testes manuais e automatizados.
 • As mudanças de programa sem autorização não podem ser im-
plementadas em ambiente de produção. Consequentemente, as 
modificações indevidas devem ser descobertas por meio de com-
paração de versões.
 • A versão documentada deve ser comparada àquela em uso e, 
periodicamente, a uma cópia controlada pelos auditores. Um 
software pode ser usado para executar esse procedimento.
A atualização dos documentos de um sistema costuma ser negli-
genciada por diversas equipes que desenvolvem o software. Por passar 
por atualizações de versão constantemente, é comum um documento 
ficar rapidamente desatualizado. Para evitar esse risco, a documenta-
ção deve ser enxuta e de fácil acesso.
A documentação de um sistema é composta de variados materiais 
escritos, diagramas, áudio e vídeo que auxiliam na explicação de como 
um software funciona. Os documentos são úteis tanto ao usuário final 
quanto a quem tem que fazer a manutenção no software.
40 Segurança e auditoria de sistemas
Figura 3
Diagrama para documentação de um software
nu
llp
lu
s/
Sh
ut
te
rs
to
ck
Na documentação não devem existir senhas ou descrição de como 
acessar os servidores de produção. Outras boas práticas são:
 • Os documentos devem ser armazenados em um local digital que 
conte com controle de acesso (IMONIANA, 2013).
 • Os documentos devem seguir um padrão de escrita e nomen-
clatura (convenção).
 • A escrita deve seguir narrativas.
 • Os diagramas são mais interpretativos do que os textos longos:
 ◦ Para documentos técnicos, usar os diagramas previstos no 
padrão UML (unified model language).
 ◦ Para documentação de processos, usar os diagramas previstos 
no padrão BPMN (business process model and notation).
 • Ao utilizar textos, dar preferência aos modelos usados 
mundialmente:
 ◦ Documentação de itens a serem alterados ou desenvolvidos, 
seguir o modelo de histórias do usuário (user story).
 ◦ Documentação de testes, seguir o modelo BDD (behavior 
driven development).
 • Todos do time podem alterar a documentação, mediante o con-
trole de acesso.
 • Pode haver revisores antes de ser aprovada a alteração.
Execução de auditorias 41
Quando a empresa não adota as boas práticas de documentação, 
tampouco de mudança de software, o papel do auditor deve ser o 
de reportar a baixa maturidade do modelo de trabalho e apontar a 
necessidade imediata de ações para melhorar esse fluxo.
A seguir trouxemos uma sequência de quadros que podem ser 
utilizados pelo auditor na avaliação dos itens previstos para a audi-
toria de sistemas.
Quadro 2
Análise da necessidade e viabilidade de um novo software
Objetivo: avaliar se as pessoas responsáveis foram envolvidas na análise e 
definição da aquisição ou do desenvolvimento de um software.
Cliente: Data:
Auditoria realizada por:
Análise da necessidade e viabilidade 
de um novo software
Sim / Não / 
Não avaliado
Respostas e 
observações
Existe um projeto apresentando a real ne-
cessidade de um novo software?
Esse projeto influencia algum indicador es-
tratégico da organização?
Os tomadores de decisão da organização 
foram envolvidos nessa análise?
A decisão sobre a viabilidade foi pautada 
em custo-benefício?
Fonte: Elaborado pelo autor.
Quadro 3
Aquisição de um novo software
Objetivo: avaliar se, durante o processo de aquisição de um software, foram 
seguidos os procedimentos previstos, evitando formas de favorecimento a 
fornecedores e gastos desnecessários.
Cliente: Data:
Auditoria realizada por:
Aquisição de sistemas Sim / Não / Não avaliado
Respostas e 
observações
Houve análise de mais de um orçamento para a 
aquisição de um sistema?
(Continua)
42 Segurança e auditoria de sistemas
Objetivo: avaliar se, durante o processo de aquisição de um software, foram 
seguidos os procedimentos previstos, evitando formas de favorecimento a 
fornecedores e gastos desnecessários.
Cliente: Data:
Auditoria realizada por:
Aquisição de sistemas Sim / Não / Não avaliado
Respostas e 
observações
Os tomadores de decisão da organização foram 
envolvidos nessa análise?
A decisão sobre a viabilidade foi pautada em 
custo-benefício?
Os critérios de manutenção do software foram 
analisados e definidos?
Os critérios de atualização em produção do 
software foram analisados e definidos?
Os critérios para acesso às novas versões do 
software foram analisados e definidos?
Fonte: Elaborado pelo autor.
Quadro 4
Especificação de sistemas
Objetivo: avaliar o trabalho de análise e definição de requisitos para mu-
danças no software.
Cliente: Data:
Auditoria realizada por:
Especificação de sistemas Sim / Não / Não avaliado
Respostas e 
observações
Os responsáveis pela análise das sugestões 
de mudanças são conhecidos? Quem são 
essas pessoas?
As solicitações de alteração no sistema estão 
sempre alinhadas com os responsáveis pelo 
processo?
Os documentos para descrever alterações se-
guem um padrão?
Os documentos para descrever alterações 
estão em um local acessível e com controle 
de acesso?
As mudanças são priorizadas de acordo com 
critérios claros de benefícios ao usuário?
Fonte: Elaborado pelo autor.
Execução de auditorias 43
Quadro 5
Programação
Objetivo: avaliar o trabalho do programador referente à escrita de 
código-fonte.
Cliente: Data:
Auditoria realizada por:
Programação Sim / Não / Não avaliado
Respostas e 
observações
As alterações de código-fonte são desenvolvi-
das seguindo a especificação?
As alterações são realizadas seguindo as boas 
práticas da linguagem de programação?
É possível rastrear o responsável pela altera-
ção no código-fonte?
Existe um processo de revisão de 
código-fonte? Ele é repetitivo?
Cada alteração no código-fonte gera um novo 
teste unitário?
Fonte: Elaborado pelo autor.
Quadro 6
Testes
Objetivo: avaliar o trabalho do testador referente à integridade das altera-
ções solicitadas pelo analista e implementadas pelo desenvolvedor.
Cliente: Data:
Auditoria realizada por:
Testes Sim / Não / Não avaliado
Respostas e 
observações
Os testes são realizados em todas as alterações 
do software?
Existem testes automatizados? A abrangência 
deles está crescendo durante o tempo de vida 
do software?
Existem rotinas de testes de interfaces?
Existem rotinas de testes de usabilidade?
Existem rotinas de testes de lógica de negócio?
Existem rotinas de testes de permissão de 
acesso a telas?
Fonte: Elaborado pelo autor.
44 Segurança e auditoria de sistemas
Quadro 7
Documentação
Objetivo: avaliar se os documentos foram atualizados e se estão disponíveis 
para consulta.
Cliente: Data:
Auditoria realizada por:
Documentação Sim / Não / Não avaliado
Respostas e 
observações
A documentação está atualizada?
A documentação está acessível?
São priorizados mais diagramas do que textos 
longos?
Existem mecanismos para a documentação ser 
acessada pelo usuário?
Existe distinção entre documentação para o 
usuário e documentação do time que desenvol-
ve o software?
Fonte: Elaborado pelo autor.
Quadro 8
ManutençãoObjetivo: avaliar o processo de gerência de configuração, evidenciando o 
controle das mudanças no software.
Cliente: Data:
Auditoria realizada por:
Manutenção Sim / Não / Não avaliado
Respostas e 
observações
É possível rastrear as alterações já realizadas em 
uma versão de software? Como?
É possível reverter uma versão de software rapi-
damente?
O processo de manutenção e atualização do 
software não causa impactos ao usuário?
As solicitações de mudança estão documentadas 
e foram aprovadas pelos responsáveis?
Fonte: Elaborado pelo autor.
Ao realizar o processo de auditoria de sistemas, muitos pontos de 
melhoria poderão ser identificados, pois o desenvolvimento de software 
Execução de auditorias 45
envolve diversos detalhes. Em empresas nas quais há essa atividade 
como atuação principal, a auditoria deve ser frequente (mensal), e à me-
dida que as melhorias são implementadas, a maturidade e o profissiona-
lismo na entrega de software serão percebidos pelos usuários.
2.3 Auditoria de hardware 
Vídeo Na seção anterior abordamos a auditoria de software, mas para que 
ela exista e seja acessada pelos usuários, é necessário à empresa diver-
sos aparelhos para esse fim. Eles podem ser computadores, notebooks, 
servidores, dispositivos de rede, mouse, teclado, entre outros, e todos 
fazem parte do conceito de hardware. Segundo Imoniana (2013, p. 102):
o controle de hardware objetiva implantar os procedimentos 
de segurança física sobre os equipamentos instalados em am-
biente de informática de uma organização. Aponta como os 
contatos físicos dos usuários aos variados recursos são con-
trolados, além de auxiliar no monitoramento de seu uso ade-
quado para agregar valor aos negócios empresariais.
Ao realizar a auditoria do hardware, o auditor deve ter algumas per-
guntas em mente:
• Se uma pessoa visitante entrar nessa organização, o que conseguirá 
fazer com o hardware?
• O que um colaborador consegue fazer com o hardware da empresa?
• O que um funcionário terceirizado consegue fazer com o hardware 
da empresa?
• O que os colaboradores que não trabalham na sede da empresa estão 
fazendo com o hardware cedido a eles?
• Quem é o responsável pela gestão do hardware?
• Existe o controle orçamentário, a gestão de estoque e do inventário de 
hardware da organização? Quais são esses controles?
• Existe inventário de software da organização? O que está instalado 
nos hardwares?
• Se acontecer um problema no hardware, a empresa continua a operar?
46 Segurança e auditoria de sistemas
Dependendo das respostas e evidências que o auditor encontrar, 
diversos riscos poderão ser identificados e muitos deles devem ser re-
portados imediatamente, para que alguma providência seja tomada 
pela organização. Os riscos que costumam ser constatados na audito-
ria de hardware são:
 • Ausência de um controle de acesso interno aos equipamentos, 
servidores e backups.
 • Instalação de softwares não homologados.
 • Substituição de peças por outras não homologadas e sem 
autorização.
 • Uso incorreto da rede de dados.
A restrição de acesso de pessoas ao ambiente de computador é 
chamada de segurança física. Ela pode ser feita por biometria ou leitura 
de um crachá de autorização. Essa restrição é muito comum em salas de 
servidores – nenhum desconhecido deve transitar pela empresa, por 
isso é tão importante a identificação por crachá, mesmo que seja a de 
visitante, pois assim é possível rastrear a entrada e saída de pessoas.
Figura 4
Mecanismo de restrição de acesso por crachá
Ol
ivi
er
 L
e 
M
oa
l/S
hu
tte
rs
to
ck
Essa restrição pode ser ampliada quando há políticas definidas so-
bre como deve ser a utilização do hardware, quais softwares podem 
ser instalados e qual é o processo a ser realizado quando é preciso de 
manutenção em um hardware. Essas políticas devem ser de conheci-
mento dos colaboradores e frequentemente atualizadas.
Execução de auditorias 47
Outro controle importante que a auditoria de hardware irá validar 
é a gestão de hardware e como está o inventário de peças e software. 
Essa análise é feita em todo o parque tecnológico da empresa e pode 
ser manual, mas essa abordagem costuma ser ineficiente, pois cons-
tantemente novos softwares são instalados por colaboradores e, em 
determinadas organizações, os profissionais trabalham de modo distri-
buído, em regime home office ou em outras sedes da empresa.
Para resolver esse problema, vários softwares podem ser utili-
zados para o inventário de hardware e software. Estes costumam 
ser instalados em cada computador, que envia para um servidor os 
dados referentes. Quando temos essa lista, é possível criar alertas 
que identificarão possíveis alterações feitas por algum colaborador. 
O software OCS Inventory Review é uma excelente opção para criar 
um inventário, pois, além de ter uma interface amigável, é gratuito e 
constantemente atualizado.
Os seguintes hardwares devem fazer parte do inventário e conter 
informações de fabricante, modelo e série:
 • processador;
 • memória;
 • unidade de armazenamento (disco rígido, fitas de armazenamen-
to e ssd);
 • monitores;
 • notebooks;
 • placas de vídeo, som e rede;
 • impressoras;
 • dispositivos de internet móvel (modem 3G ou superior);
 • celulares e smartphones;
 • thin client (computadores com poucos recursos instalados e que 
se conectam a servidores);
 • servidores presentes na empresa;
 • servidor de banco de dados;
 • servidores na nuvem (cloud).
Quanto ao inventário de software, ele deve conter informações so-
bre o fabricante, modelo e série de cada software instalado no compu-
tador, sem esquecer do sistema operacional. O software em uso para 
No vídeo OCS Inventory 
Review, você conhecerá 
os recursos de uma 
ferramenta gratuita e open 
source (código livre) para 
inventariar o hardware de 
uma empresa.
Disponível em: https://www.
youtube.com/watch?v=2_
ZZu2Doems. Acesso em: 6 jan. 2022.
Vídeo
https://www.youtube.com/watch?v=2_ZZu2Doems
https://www.youtube.com/watch?v=2_ZZu2Doems
https://www.youtube.com/watch?v=2_ZZu2Doems
48 Segurança e auditoria de sistemas
o inventário deve ser capaz de bloquear aqueles não autorizados pela 
empresa, evitando o uso de softwares piratas e suspeitos de conter 
brechas de segurança.
A rede de dados é um item que deve fazer parte do inventário, já 
que ela é composta de diversos hardwares, entre eles dispositivos de 
rede sem fio (wi-fi), roteadores, switches, hubs e firewall. A gestão do trá-
fego de dados nesses dispositivos é um item a ser observado, pois cada 
pessoa conectada a um hardware de rede deve ter privilégios restritos. 
Por exemplo, um visitante na empresa deve estar conectado a uma 
rede exclusiva e sem acesso aos demais computadores da corporação. 
Já um colaborador deve ter acesso aos recursos de rede referentes ao 
trabalho que desempenha.
Além desses aparelhos, é importante a gestão de outros apare-
lhos, como catracas de acesso e dispositivos de biometria. Também 
deve haver especial atenção à gestão das fitas de backup e de arma-
zenamento delas.
Figura 5
Exemplo de fita backup
Kj
et
il K
ol
bj
or
ns
ru
d/
Sh
ut
te
rs
to
ck
A auditoria de hardware deve acompanhar as necessidades do mun-
do atual, e uma dessas demandas é o correto descarte de aparelhos 
eletrônicos, sem contaminar o meio ambiente, pois o lixo eletrônico 
(e-lixo) é composto de baterias e outros materiais tóxicos que podem 
Execução de auditorias 49
contaminar o solo e a água. Por isso, é importante o auditor estar capa-
citado para saber quais são as políticas de descarte de computadores.
A seguir apresentamos uma sequência de quadros que podem ser 
utilizados pelo auditor para a avaliação dos itens previstos na auditoria 
de hardware.
Quadro 9
Controle de acesso físico ao ambiente de informática
Objetivo: avaliar se existem controles para o acesso físico aos computadores 
e servidores e se são efetivos.
Cliente: Data:
Auditoria realizada por:
Controle de acesso físico ao ambiente de 
informáticaSim / Não / 
Não avaliado
Respostas e 
observações
O acesso físico aos servidores é controlado? 
É possível identificar a hora e quem acessou?
Cada computador é utilizado apenas mediante a 
identificação do usuário?
Existe controle sobre quem acessa o cofre de 
backups?
Existe algum controle referente à expiração de 
acesso aos computadores?
Fonte: Elaborado pelo autor.
Quadro 10
Controle de acionamento e desligamento de máquinas
Objetivo: avaliar se existe controle nos processos tanto de ligar e desli-
gar computadores quanto de acesso a dados lógicos, caso um computa-
dor seja ligado.
Cliente: Data:
Auditoria realizada por:
Controle de acionamento e desligamento 
de máquinas
Sim / Não / 
Não avaliado
Respostas e 
observações
Todos os acessos lógicos aos servidores locais 
têm identificação? É possível identificar os per-
fis administradores por meio de seus respecti-
vos nomes?
(Continua)
50 Segurança e auditoria de sistemas
Objetivo: avaliar se existe controle nos processos tanto de ligar e desli-
gar computadores quanto de acesso a dados lógicos, caso um computa-
dor seja ligado.
Cliente: Data:
Auditoria realizada por:
Controle de acionamento e desligamento 
de máquinas
Sim / Não / 
Não avaliado
Respostas e 
observações
Todos os acessos lógicos aos servidores em nu-
vem (cloud) têm identificação? É possível identifi-
car os perfis administradores por meio de seus 
respectivos nomes?
Existem controles para o acesso remoto aos 
computadores?
Quando um colaborador é desligado, há proce-
dimentos específicos para eliminar senhas? Com 
isso é impossível ligar os computadores?
Fonte: Elaborado pelo autor.
Quadro 11
Controle de acesso físico ao equipamento de hardware e periféricos
Objetivo: avaliar os controles para a retirada de peças e gestão de 
inventário.
Cliente: Data:
Auditoria realizada por:
Controle de acesso físico ao equipamento 
de hardware e periféricos
Sim / Não / 
Não avaliado
Respostas e 
observações
Há um controle efetivo de entrada e saída de 
hardware?
É efetuado periodicamente o inventário com-
pleto de hardware?
É efetuado periodicamente o inventário com-
pleto de software?
Fonte: Elaborado pelo autor.
Execução de auditorias 51
Quadro 12
Localização e infraestrutura do centro de processamento de dados (CPD)
Objetivo: avaliar se a localização da sala de servidores é adequada e segura.
Cliente: Data:
Auditoria realizada por:
Localização e infraestrutura do CPD Sim / Não / Não avaliado
Respostas e 
observações
Existem controles físicos para o acesso ao 
CPD? Eles podem ser auditados?
O CPD está localizado em uma área distante 
de inundações?
O CPD está localizado em uma área distante 
de geradores de fogo, como tanque de com-
bustível, cozinhas e depósitos de tintas?
O sistema de ar-condicionado do CPD está 
em uma rede elétrica independente?
Os cabos e fios elétricos não ficam expostos 
e estão protegidos por um piso suspenso?
Existem equipamentos de combate a incên-
dios próximos ao CPD?
As pessoas com acesso a CPD têm treina-
mento para o combate a incêndio?
Fonte: Elaborado pelo autor.
Quadro 13
Controle de backup e off-site
Objetivo: avaliar se existe uma política para a gestão de backups.
Cliente: Data:
Auditoria realizada por:
Controle de backup e off-site Sim / Não / Não avaliado
Respostas e 
observações
Os backups são armazenados localmente em 
um cofre controlado por senha?
Existe um ambiente externo para armazena-
mento de backups?
O ambiente externo possui condições míni-
mas de segurança referentes a incêndio?
(Continua)
52 Segurança e auditoria de sistemas
Objetivo: avaliar se existe uma política para a gestão de backups.
Cliente: Data:
Auditoria realizada por:
Controle de backup e off-site Sim / Não / Não avaliado
Respostas e 
observações
O ambiente externo possui condições míni-
mas de segurança referentes a alagamentos?
O ambiente externo possui controle de acesso 
físico?
Fonte: Elaborado pelo autor.
Quadro 14
Controles sobre o ambiente e informações
Objetivo: avaliar se existe a gestão de hardware, software e sistemas opera-
cionais e se ela é efetiva.
Cliente: Data:
Auditoria realizada por:
Controles sobre o ambiente e informações 
relacionadas à definição da plataforma de 
hardware, software e sistema operacional.
Sim / Não / 
Não avaliado
Respostas e 
observações
É fácil ter a relação de todos os equipamentos 
instalados utilizados na empresa?
É fácil ter a relação de todos os softwares insta-
lados nos computadores da empresa?
É fácil ter a relação de todos os sistemas opera-
cionais utilizados na empresa?
Essas listas são atualizadas diariamente?
Fonte: Elaborada pelo autor.
Execução de auditorias 53
Quadro 15
Controles referentes à rede ao tráfego de dados
Objetivo: avaliar se os equipamentos de redes estão mapeados e se é efeti-
va a gestão do tráfego de dados neles.
Cliente: Data:
Auditoria realizada por:
Controles referentes à rede ao tráfego de 
dados
Sim / Não / 
Não avaliado
Respostas e 
observações
É fácil ter a relação de todos os equipamentos 
de rede utilizados na empresa?
O tráfego de dados na rede é possível de ser 
rastreado e, com isso, é possível identificar 
o equipamento e o usuário responsável por 
aquele dado?
Existe segregação da rede de dados?
Existe uma política definida para o acesso aos 
recursos de rede?
Fonte: Elaborado pelo autor.
Ao realizar o processo de auditoria de hardware, muitos pontos 
de melhoria poderão ser identificados, e aperfeiçoá-los evitará ris-
cos de invasão, sequestro de dados e má utilização dos recursos 
computacionais da empresa.
2.4 Auditoria de controle de acesso 
Vídeo
Durante a auditoria de hardware, estudamos os controles de 
acesso físico à sala de servidores e à própria empresa, mediante cra-
chá ou biometria. Pensando em validar se existem controles efetivos 
para o acesso aos dados, incluindo a possibilidade de processamento 
e transações de rotinas, foi definida uma auditoria específica para o 
acesso ao meio lógico. Assim, essa tarefa cabe ao administrador de 
segurança de informações, responsável por supervisionar e imple-
mentar todas as políticas de controle de acesso. Cada colaborador 
da empresa deve ter o seu próprio usuário e um conjunto específico 
de regras do que pode acessar. Essas definições devem ser descritas 
por um comitê, e o acesso deve estar alinhado às responsabilidades 
estabelecidas nos descritivos de cargos.
54 Segurança e auditoria de sistemas
Os controles de acesso devem ser feitos por login e senha corpo-
rativos e envolver critérios para o acesso, chamado de privilégio. Um 
usuário pode ter os seguintes privilégios para um arquivo ou processo:
 • Proprietário (pode todas as ações).
 • Somente leitura.
 • Somente escrita/inserção de dados.
 • Somente alteração.
 • Somente remoção.
 • Mesclar uma ou mais opções acima.
Uma vez que um colaborador é desligado da empresa, todos os 
seus privilégios devem ser revogados em todos os softwares. Isso 
pode ser um processo demorado, custoso e de difícil realização, pois 
em algumas empresas o login e as senhas não são integrados. Para 
facilitar a gestão de privilégios, seja para acrescentar, seja para remo-
ver, aconselhamos adotar a prática de single sign-on (SSO), que prevê 
um esquema de autenticação único para vários sistemas de software.
Figura 6
Single sign-on (SSO)
Pi
sc
in
e2
6/
Sh
ut
te
rs
to
ck
Execução de auditorias 55
Com o SSO, é possível rastrear quando um acesso foi feito e por 
meio de qual dispositivo, além de identificar qual foi a ação realizada 
(inclusão, alteração, leitura ou remoção) e em que sistema. Também, 
como o login está centralizado, há a possibilidade de implementar, 
com facilidade, uma política de troca de senhas após determinado 
tempo (trimestralmente, por exemplo), assim, é possível criar cri-
térios de complexidade para as senhas, evitando aquelas fáceis de 
serem descobertas.
A seguir trouxemos uma sequência de quadros que podem ser uti-
lizados pelo auditor na avaliaçãodos itens previstos na auditoria de 
controle de acesso.
Quadro 16
Programa de auditoria de segurança de acesso lógico
Objetivo: avaliar se existe uma política para acesso lógico de softwares.
Cliente: Data:
Auditoria realizada por:
Auditoria de segurança de acesso lógico Sim / Não / Não avaliado
Respostas e 
observações
Há políticas de segurança estabelecidas que 
forneçam as diretrizes de acesso lógico para 
cada cargo?
Essas políticas foram revisadas nos últimos 
seis meses?
Existe algum software que implementa o SSO?
É possível rastrear e identificar os autores de 
cada ação em um software?
Existem critérios definidos para o upgrade de 
privilégios?
Todos os upgrade de privilégios foram autoriza-
dos por algum gerente?
Fonte: Elaborado pelo autor.
No vídeo O que é single 
sign-on ou SSO?, você 
conhecerá o que é esse 
conceito e quais são 
os benefícios que os 
usuários têm ao utilizar 
um software com esse 
controle de acesso lógico.
Disponível em: https://www.
youtube.com/watch?v=35zB-
pqgeS0. Acesso em: 6 jan. 2022.
Vídeo
https://www.youtube.com/watch?v=35zB-pqgeS0
https://www.youtube.com/watch?v=35zB-pqgeS0
https://www.youtube.com/watch?v=35zB-pqgeS0
56 Segurança e auditoria de sistemas
Quadro 17
Programa de auditoria de políticas de segurança de acessos
Objetivo: avaliar se existem critérios claros para elevar a segurança de 
acessos.
Cliente: Data:
Auditoria realizada por:
Políticas de segurança de acessos Sim / Não / Não avaliado
Respostas e 
observações
Todos os softwares possuem senhas com crité-
rios de complexidade definidos?
Trimestralmente, o usuário precisa trocar a se-
nha de acesso?
Existem rotinas automatizadas para retirar pri-
vilégios de acesso de usuários sem atividade 
nos últimos cinco meses?
Existe a prática de bloqueio temporário de 
acesso caso haja tentativas inválidas?
Existem alertas para o gestor de segurança in-
formando atividades suspeitas de acesso?
Fonte: Elaborado pelo autor.
O processo de auditoria de controle de acesso é vital para que as 
informações de uma empresa não sejam violadas por colaboradores 
e ex-colaboradores. A gestão deve ser realizada pela equipe de SGSI, 
com insumos e orientações dadas pelo time de RH, dado que é o time 
de recursos humanos que sabe quais colabores estão ativos e quais 
cargos eles ocupam na organização.
CONSIDERAÇÕES FINAIS
Neste capítulo aprendemos a executar diversos tipos de auditorias 
em uma empresa que atua na área de tecnologia da informação. Essas 
auditorias são essenciais para mitigar riscos de fraudes em softwares, 
roubos de dados e hardwares e evitar a desorganização. Havendo 
processos auditáveis e que sigam as boas recomendações, a empresa 
torna-se mais eficiente em suas atividades.
Execução de auditorias 57
ATIVIDADES
Atividade 1
Quais são os benefícios para uma empresa ao possuir controles 
organizacionais bem definidos e que podem ser auditados? 
Justifique.
Atividade 2
Um auditor precisa analisar o processo de aquisição de um 
software. Quais pontos devem ser auditados?
Atividade 3
Você é um auditor e percebeu que a empresa não tem uma 
política de troca de senhas recorrente, tampouco utiliza critérios 
de complexidade para elas. Em qual tipo de auditoria costuma ser 
identificado esse problema?
REFERÊNCIAS
HELDMAN, K. Gerência de projetos: guia para o exame oficial do PMI. Brasil: Elsevier, 2006.
IMONIANA, J. O. Auditoria de sistemas de informação. 2. ed. São Paulo: Atlas, 2013.
58 Segurança e auditoria de sistemas
3
Segurança de sistemas 
da informação
Nas décadas de 1980 e 1990, houve a popularização dos microcompu-
tadores e da internet, a qual costumava ser por cabos, em especial os tele-
fônicos. Quem viveu nessa época vai lembrar de que para acessar a internet 
era necessário discar para os provedores usando aparelhos específicos 
(modens), sendo um tanto barulhentos ao realizar a conexão. Com o passar 
dos anos, a rede cabeada de alta velocidade começou a ser implementada, 
permitindo o uso de softwares e de streaming de vídeo na internet.
Nos anos 2000, os smartphones se popularizaram e trouxeram outro pa-
radigma: como se conectar à internet sem precisar de um cabo? Com isso, as 
redes de dados passaram a ser sem fio por meio de 2G, 3G, 4G e 5G. Com 
essas tecnologias, podemos estar conectados com o smartphone durante 
todo o dia e independentemente da localização. Além disso, nesse período, a 
rede cabeada foi substituída gradativamente pela fibra ótica, permitindo uma 
velocidade ainda maior na troca de dados pela internet.
Com toda essa conectividade disponível e com uma rede cada vez 
mais rápida, um problema surge para pessoas e empresas: a exposição 
ao trocar dados pela internet. A disciplina que estuda como manter um 
dado íntegro, confidencial e disponível se chama segurança de sistemas da 
informação, e esse é nosso objeto de estudo deste capítulo.
Com o estudo deste capítulo, você será capaz de:
 • conhecer as bases que alicerçam o tema segurança da informação;
 • diferenciar os conceitos de risco, ameaça e vulnerabilidade em sis-
temas de informação;
 • descrever o modelo de gestão da segurança da informação pro-
posto pela ISO 27000.
Objetivos de aprendizagem
Segurança de sistemas da informação 59
3.1 Conceitos e princípios 
fundamentais da segurançaVídeo
Imagine que você é um correntista do banco BomBank e tem uma 
quantia guardada em sua conta corrente, outra quantia na poupança e 
outro valor investido em fundos de renda fixa.
Até um tempo atrás, você estava acostumado a ir à agência do 
BomBank para realizar operações, como transferência de dinheiro e 
pagamento de boletos, mas com a criação de um aplicativo o seu tra-
balho ficou muito mais fácil. Agora todas as operações realizadas em 
caixa automático também podem ser feitas pelo seu smartphone.
O aplicativo foi uma inovação e você foi um dos primeiros corren-
tistas a aderir a ele. Essa inovação deu tão certo que o banco resolveu 
criar uma campanha massiva de divulgação, que também teve sucesso, 
fazendo com que muitas pessoas não correntistas passassem a usar 
o aplicativo, pois ele permitia a abertura de conta corrente de modo 
on-line. Mas além dessas pessoas, um grupo de hackers, denominado 
PirateBank, decidiu verificar se o aplicativo era realmente seguro.
Para isso, um integrante do grupo abriu uma conta corrente pelo 
aplicativo e, no momento de definir a senha, entendeu qual era o pa-
drão. O formato da senha era composto pelo código da agência bancá-
ria (on-line ou física) e a data de nascimento do cliente (dia, mês e ano, 
sendo este com quatro dígitos). Ficou evidente para o hacker que, para 
realizar uma invasão a uma conta bancária, era preciso saber o número 
de CPF do correntista, o código de uma agência e a data de nascimento.
Com essas informações, outro membro do grupo pesquisou em 
quais cidades do Brasil havia uma única agência do BomBank. Essa in-
formação estava disponível no site do banco, e ali mostrava o nome da 
cidade e os códigos das agências. Agora bastava filtrar as cidades com 
apenas uma agência.
Na sequência, o grupo hacker se dividiu; cada pessoa deveria 
acessar as redes sociais do BomBank, pesquisar pessoas que seguiam 
ou curtiam as páginas do banco e que moravam em uma das cidades 
onde havia só uma agência. Esses hackers criaram uma lista de nomes, 
e entre eles estava o seu.
Com essa lista, eles acessaram os perfis identificados e descobriram 
as datas de nascimento de cada pessoa, pois a informação estava no 
modo público em suas páginas. Com os nomes completos foram en-
contrados diversos números de CPF em pesquisa no Google.
60 Segurança e auditoria de sistemas
Os hackers, então, tinham uma lista com números de CPF, códigos 
de agências e datas de nascimento, ou seja, os dados precisos para 
acessar as contas indevidamente, e você estava nessa lista.
Em uma ação coordenada, foram acessadas mais de mil contas ban-
cárias e feitas transações para outras não rastreáveis fora do Brasil. 
O prejuízo para oBomBank foi gigantesco, e você acabou sendo assal-
tado digitalmente.
Essa pequena história pode acontecer em qualquer empresa que 
tenha um aplicativo ou software próprio – basta que haja um compu-
tador conectado ou não à internet – e que não dê a devida atenção 
ao tema segurança da informação. Esses ataques podem ocorrer de 
dentro da organização para fora ou vice-versa. Em alguns casos, são 
aproveitadas as vulnerabilidades de softwares ou hardwares. Em ou-
tros, em uma simples observação sobre o funcionamento do software, 
o hacker consegue realizar a invasão, como na história anterior. Esse 
tipo de ataque é chamado de engenharia social, utilizando informações 
que publicamos na internet.
No Brasil, o Centro dos Estudos, Respostas e Tratamento de Incidentes 
de Segurança no Brasil (CERT.br) agrupa dados estatísticos referentes a 
incidentes de segurança em redes. Os dados são enviados por empresas 
voluntariamente, ou seja, os números podem ser ainda maiores. 
Sa
be
ls
ka
ya
/S
hu
tte
rs
to
ck
Gráfico 1
Total de incidentes reportados ao CERT.BR por ano.
Ano Total
2020 665.079
2019 875.327
2018 676.514
2017 833.775
2016 647.112
2015 722.205
2014 1.047.031
2013 352.925
2012 466.029
2011 399.515
2010 142.844
2009 358.343
2008 222.528
2007 160.080
2006 197.892
2005 68.000
2004 75.722
2003 54.607
2002 25.032
2001 12.301
2000 5.997
1999 3.107
Incidentes
0 100k 200k 300k 400k 500k 600k 700k 800k 900k 1M 1.1M
Segurança de sistemas da informação 61
Fonte: CERT.br, 2021a.
No Gráfico 1 percebemos que, a partir do ano de 2014, o número de 
incidentes não ficou abaixo de 500 mil; isso ocorre por causa do núme-
ro de pessoas conectadas à internet, seja pelo dispositivo móvel ou pelo 
computador. Quanto maior a oferta de máquinas para serem invadidas e 
mais vulneráveis estiverem, maior é a quantidade desses incidentes.
Boa parte das ocorrências apresentadas no Gráfico 1 são do tipo 
scan, na qual o hacker faz varreduras em redes de computadores (como 
a internet), para identificar quais deles estão ativos e quais serviços eles 
disponibilizam. Essas varreduras acontecem por softwares criados pelo 
hacker, que enviam algum sinal de comunicação para o IP, número re-
cebido ao se conectar na internet (por exemplo, 200.15.20.88). 
O scan é amplamente utilizado por criminosos para identificar po-
tenciais alvos, pois permite associar possíveis fragilidades nos serviços 
habilitados em um computador. Ao identificá-las, o hacker poderá co-
meter outro crime, como fraude, enviar um vírus ou worm, bem como 
realizar um ataque DoS (Denial of Service), com o objetivo de tirar o site 
ou computador do ar. No Gráfico 2 está o percentual de tipos de inci-
dentes reportados ao CERT.br no ano de 2020.
Gráfico 2
Tipos de incidentes reportados ao CERT.br no ano de 2020
Tipos de ataque
Fraude (4,60%)Outros (0,97%)
DoS (10,25%)
Invasão (0,18%)
Web (3,99%)
Worm (20,15%)
Scan (59,85%)
Fonte: CERT.br, 2021b.
De acordo com o contexto apresentado, fica evidente a necessidade 
das empresas investirem recursos financeiros para implementar um 
62 Segurança e auditoria de sistemas
sistema de gestão da segurança da informação (SGSI) – ferramenta 
corporativa de auxílio na adoção de estratégias, políticas, controle e 
medidas para gerir a segurança da informação. Existem diversas imple-
mentações de SGSI, sendo a mais conhecida a ISO 27001.
Antes de detalhar o que um SGSI deve ter, precisamos entender o 
que é informação. Segundo a norma NBR ISO/IEC 27002:2005:
a informação é um ativo que, como qualquer outro ativo impor-
tante, é essencial para os negócios de uma organização e, con-
sequentemente, necessita ser adequadamente protegida. [...] 
A informação pode existir em diversas formas. Ela pode ser im-
pressa ou escrita em papel, armazenada eletronicamente, trans-
mitida pelo correio ou por meios eletrônicos, apresentada em 
filmes ou falada em conversas. Seja qual for a forma de apresen-
tação ou o meio através do qual a informação é compartilhada 
ou armazenada, é recomendado que ela seja sempre protegida 
adequadamente. (ABNT, 2005, p. X) 
Ao investir em SGSI e em uma área dedicada à segurança da in-
formação, a empresa protegerá a informação e reduzirá ao mínimo 
possível os riscos de uma eventual invasão. Com isso, garante a con-
tinuidade dos negócios no meio digital e potencializa os retornos de 
investimentos feitos no negócio.
Segundo Galvão (2015, p. 12), a informação pode ser colocada em 
risco por meio de diversos fatores:
 • comportamento indevido dos próprios usuários ou detentores 
da informação;
 • problemas no ambiente em que a informação está inserida;
 • falhas na infraestrutura da empresa;
 • indivíduos mal-intencionados que agem com o objetivo de alte-
rar, destruir ou danificar as informações.
Pensando nesses fatores e em como garantir a continuidade sus-
tentável dos negócios, todo SGSI é fundamentado no modelo CIA de 
informação. CIA é o acrônimo de confidentiality (confidencialidade), 
integrity (integridade) e avaliability (disponibilidade). Esse modelo é cha-
mado de triângulo CIA, sempre com a gestão da segurança ao centro, 
como mostra a Figura 1.
Segurança de sistemas da informação 63
Figura 1
Triângulo CIA
Bo
wr
an
n;
 N
ik
W
B;
 
St
an
da
rd
 S
tu
di
o/
Sh
ut
te
rs
to
ckConfidencialidade
DisponibilidadeIntegridade
3
Segurança 
da informação 2
1
Fonte: Elaborada pelo autor.
O princípio da integridade diz respeito à proteção de uma informação 
contra modificações indevidas. Informaç: ões com integridade devem ter 
exatidão e autenticidade, ou seja, elas são verdadeiras e não sofreram ne-
nhuma violação. Logo, para modificá-las deve haver autorização do pro-
prietário. No exemplo do BomBank, a informação foi violada quando os 
hackers transferiram dinheiro para outras contas. Se na instituição hou-
vesse um SGSI, o risco desse ataque ocorrer seria reduzido ao mínimo.
Outro exemplo é quando uma pessoa digita algo em um sistema 
e essa informação não é alterada. Os dados são salvos em uma base 
de dados conforme cadastrados pelo usuário. Além da entrada de da-
dos em um software, o conceito de integridade abrange a sua saída. 
Por isso, as informações devem chegar intactas ao seu destino e, ao 
ocorrer uma alteração não autorizada, entende-se que houve ali uma 
falha de integridade (GALVÃO, 2015).
Já o princípio da confidencialidade visa garantir restrições ao acesso 
e à divulgação de determinada informação, assegurando o distancia-
mento de usuários mal-intencionados. Para isso, são utilizados meios 
de proteção que determinarão o nível de privacidade da informação e 
quem tem a posse dela (propriedade intelectual).
Para entender melhor o princípio da confidencialidade pense em 
um diário: ele só pode ser aberto por seu dono ou dona. Quem abre 
um diário sem autorização, viola uma propriedade intelectual e fere a 
confidencialidade. Ao ser aberto, o sigilo das informações é violado.
Em um ambiente de tecnologia da informação, a confidencialidade 
se dá pelo acesso a documentos e a outras mídias digitais. Imagine 
64 Segurança e auditoria de sistemas
que em uma empresa, diversos arquivos são compartilhados pela rede 
interna. Cada departamento tem a sua pasta para as pessoas que ali 
trabalham. Se alguém do setor de compras consegue entrar na pasta 
do setor de RH, por exemplo, temos uma situação de ferir a confiden-
cialidade da informação.
Por fim, o princípio da disponibilidade refere-se a assegurar que 
a informação estará acessível em tempo útil. Só percebemos como é 
ruim não ter acesso a ela ou a um software ao estarem indisponíveis. 
Quando uma rede social ou um aplicativo de mensagem fica fora do ar, 
boa parte dos habitantes da Terra fica sem comunicação, e isso eviden-
cia uma violação da disponibilidade.
Esses três princípios precisam estar sincronizados, pois uma in-
formação pode estar disponível, mas não ser acessada por todos. Ela 
precisa ser confidencial, ou seja, ser acessada pelo dono ou por quem 
autoriza. E,ao acessá-la, ela deve ser válida, ou seja, íntegra.
Com o avanço dos estudos sobre a segurança da informação, novas 
propostas para SGSI foram definidas. Houve a inclusão de outros prin-
cípios, mas sem o abandono do conceito CIA. O modelo de hexagrama 
parkeriano (parkerian hexad) é um exemplo de evolução do modelo CIA.
O hexagrama parkeriano foi proposto por Donn B. Parker em 1998 
e seus atributos são:
Figura 2
Hexagrama parkeriano
Vo
lon
of
f/S
hu
tte
rst
oc
k
Confidencialidade
Integridade
Utilidade
Autenticidade
Segurança da 
informação
Disponibilidade
Posse
Fonte: Elaborada pelo autor.
Segurança de sistemas da informação 65
O princípio da utilidade é semelhante ao princípio da disponibilida-
de, mas o foco está no uso da informação. Por exemplo, um arquivo 
tem acesso disponível, mas para abri-lo é necessário preencher um 
código de chave criptografada. Tendo a chave, o arquivo é útil. Caso 
ele sofra diversas tentativas de descriptografia por força bruta, será 
corrompido e perderá a sua utilidade.
O princípio da posse é uma especialização da confidencialidade. 
Com a posse, fica claro quem guarda a informação e como é o seu con-
trole de acesso. Assim como o princípio da posse, o da autenticidade 
também é uma especialização, mas da integridade. Com a autenticida-
de, é possível validar se o documento é original ao checar informações, 
como chaves de autenticação ou chaves criptografadas, por exemplo, 
um hash code. Segundo Hintzbergen (2018, p. 33),
esses atributos da informação são atômicos, ou seja, não são di-
vididos em outras partes, eles não se sobrepõem, já que se re-
ferem a aspectos únicos da informação. Qualquer violação da 
segurança da informação pode ser descrita como aquilo que 
afeta um ou mais desses atributos fundamentais da informação. 
O hexagrama parkeriano é muito utilizado na implantação de pro-
cessos referentes à Lei Geral de Proteção de Dados brasileira (LGPD). 
Todo o conceito da lei está baseado no cuidado que as empresas de-
vem ter ao lidar com informações sensíveis de clientes, e os princípios 
do hexagrama ajudam a reduzir riscos de a empresa não estar aderen-
te à LGPD.
Até o momento foram apresentados os princípios que norteiam os 
SGSI, independentemente de serem itens para software ou hardware 
(infraestrutura). Alguns estudiosos da segurança da informação especi-
ficaram os princípios para um software seguro, sendo, segundo Viega e 
McGraw (2006, p. 93), dez:
 • Proteção dos pontos mais fracos: hackers procuram as fragili-
dades de um software, por isso fortaleça todos os pontos, espe-
cialmente os mais vulneráveis.
 • Defesa em profundidade: pense em segurança em todas as ca-
madas e os componentes de um software.
 • Falhas com segurança: se o software falhar, ele vai exibir todas 
as informações referentes a transações ou mostrar apenas o mí-
nimo possível?
No vídeo Saiba mais sobre 
a LGPD, desenvolvido 
pelo Sebrae Talks, vamos 
aprender mais sobre o 
que é a LGPD e os im-
pactos que ela gerou em 
nossa vida. 
Disponível em: https://
www.youtube.com/
watch?v=n6yb3D9aFpM. Acesso 
em:3 mar. 2022.
Vídeo
https://www.youtube.com/watch?v=n6yb3D9aFpM
https://www.youtube.com/watch?v=n6yb3D9aFpM
https://www.youtube.com/watch?v=n6yb3D9aFpM
66 Segurança e auditoria de sistemas
 • Mínimo privilégio: o software nunca deve ser executado com 
privilégios máximos. Usuários devem ter privilégios específicos.
 • Compartimentar acessos e áreas: existe limite e controle para 
acesso aos demais serviços de um software, como o banco de 
dados? O acesso deve ser restrito.
 • Manter a simplicidade: softwares com arquitetura e código-fonte 
complexos são mais propícios a falhas, incluindo as de segurança.
 • Promover a privacidade: as informações só podem ser acessa-
das por aqueles com acesso a elas.
 • Esconder segredos é difícil: revise sempre as políticas de segu-
rança implementadas em um software e valide constantemen-
te se há vulnerabilidades de bibliotecas, pois os hackers sempre 
aprendem novos meios de invasão.
 • Confiar desconfiando: confie no seu time de desenvolvimento, 
mas crie checagens automáticas de código-fonte para evitar pro-
blemas de segurança. Quanto mais pontos de checagem, mais 
confiantes nos tornamos.
 • Usar os recursos da comunidade: utilize bibliotecas pa-
drão de mercado. Elas já foram validadas pela comunidade de 
programadores.
Esses princípios estão presentes no modelo SGSI OpenSamm, espe-
cífico para o desenvolvimento seguro de software, podendo ser imple-
mentado durante todo esse ciclo. 
Para a checagem da segurança durante a sequência de desenvol-
vimento, McGraw (2005) definiu sete pontos de validação que podem 
ser aplicados. Ao usar essa técnica, é reduzida a quantidade de erros 
e falhas percebidas pelo usuário, aumentando assim a eficácia do pro-
cesso de produção de software. Os pontos são:
1. análise estática e revisão de código-fonte;
2. análise de risco para documentar tipos e padrões de ataques;
3. testes de penetração;
4. testes baseados em riscos de segurança;
5. construção de casos de abuso simulando mau uso do sistema;
6. especificação de requisitos de segurança;
7. monitorização de ambiente externo ao software.
Segurança de sistemas da informação 67
Na Figura 3, cada um desses pontos é detalhado na etapa do ciclo 
em que é aplicado:
Figura 3
Sete pontos de checagem de segurança
[5] Construir 
casos de 
abusos
Etapa de 
requisitos
Etapa de 
definições de 
arquitetura
Definição de 
planos de 
testes
Codificação Homologação
[6] Especificação 
de requisitos de 
segurança
[2] Análise de 
riscos
[2] Análise de 
riscos
[3] Teste de 
penetração
[4] Testes 
baseados em riscos 
de segurança
[7] Monitorar 
ambiente 
externo [1] Análise estática 
de código
Fonte: McGraw, 2005. 
Aplicar SGSI em uma empresa é um desafio, pois é necessário in-
fluenciar a cultura da organização para que os princípios do modelo 
CIA sejam seguidos. Na sequência, abordaremos as diferenças entre 
riscos, ameaças e vulnerabilidades e como é importante saber distin-
guir cada um deles.
3.2 Risco, ameaça e vulnerabilidade 
Vídeo Quando iniciamos os estudos a respeito da segurança da informação, 
uma série de termos surge, podendo ser facilmente confundidos. O mal 
entendimento pode comprometer a implantação de um SGSI, não ga-
rantindo a continuidade sustentável dos negócios de uma organização.
Os principais termos a serem elucidados são: risco, ameaça e vulne-
rabilidade. Na Figura 4 temos a explicação visual de como esses itens 
estão interligados.
Figura 4
Ameaça, vulnerabilidade e risco.
Ameaças Risco Vulnerabilidade
Fonte: Elaborada pelo autor.
68 Segurança e auditoria de sistemas
De acordo com a Figura 4, uma informação corre risco de segurança 
quando há uma intersecção entre uma ameaça e uma vulnerabilidade. 
Se fosse uma fórmula matemática, a equação seria: 
 RISCO = VULNERABILIDADE X AMEAÇA
Para Hintzbergen (2018, p. 21), ameaça é definida como “uma causa 
potencial de um incidente indesejado, a qual pode resultar no dano a 
um sistema ou organização”.
Uma ameaça é todo e qualquer fator capaz de causar um proble-
ma que prejudique uma organização de alguma forma. Esse problema 
refere-se à violação de alguns princípios do modelo CIA ou do hexa-
grama parkeriano. Ao haver a violação, a informação é comprometida 
e outros ativos da organização podem ficar inativos, como hardwares 
de infraestrutura.
As ameaças podem ser categorizadas como ativas ou passivas. As 
ativas são as que modificam as informações contidas em um softwa-
re ou banco de dados, já as passivas são aquelas que não alteram 
informações (GALVÃO, 2015, p.19). O padrão de senha definido pelo 
BomBank é um exemplo de ameaça passiva, pois na breve observação 
do hacker foi possível entender a formulação. À medida que o grupo 
PirateBank acessou as contas bancárias, violando o sigilo, a ameaça 
passou de passiva à ativa, pois houve quebra de confidencialidade e de 
integridade da informação.
SegundoHintzbergen (2018, p. 25), a vulnerabilidade é “fraqueza de 
um ativo ou controle que pode ser explorada por uma ou mais amea-
ças”. Um antivírus desatualizado ou um sistema operacional sem as 
atualizações de segurança instaladas são exemplos de vulnerabilida-
de. Em um software, as fragilidades podem ser identificadas pelo uso 
de bibliotecas obsoletas e com problemas de segurança. Em hardware 
também é possível existir vulnerabilidade Ao utilizarmos uma versão 
antiga de driver de uma placa podemos nos expor, o que poderá ser 
aproveitado pelo hacker, gerando assim uma ameaça. Se o hacker se 
aproveitar, temos um ataque em curso.
Quando um hardware ou um sistema operacional utiliza recursos 
que identificam quem faz o acesso, como o login e a senha individuali-
zados, a vulnerabilidade é mitigada.
Segurança de sistemas da informação 69
As vulnerabilidades podem existir também fora do meio digital, por 
exemplo, uma empresa que não controla o acesso das pessoas a de-
terminados locais cria o risco de comprometer alguma informação. 
O uso de crachá e de catraca é um meio de mitigar a vulnerabilidade 
e identificar quem entrou ou saiu do lugar. Há ainda locais de acesso 
restrito dentro da empresa, como a sala do cofre ou dos servidores. 
Nesses locais deve haver o controle de entrada, com o leitor biométrico 
ou o leitor de crachá.
Hintzbergen (2018, p. 24) define o risco como “a combinação da 
probabilidade de um evento e sua consequência”. Quando há vulne-
rabilidade e uma pessoa mal-intencionada (ameaça), temos um risco 
identificado. A incerteza sobre existir riscos e se eles foram mitigados 
é o combustível que move a SGSI, por isso, em todos os modelos de 
segurança da informação estão previstas boas práticas para o geren-
ciamento de risco.
Nesse sentido, Galvão (2015, p. 23) afirma que “a gestão dos riscos, 
portanto, é a função essencial da equipe de segurança da informação, 
para fazer que a estrutura da organização funcione da melhor forma 
possível, evitando que se concretize esse potencial de causar danos aos 
ativos da empresa”. 
Dois modelos de gerenciamento de risco são amplamente aplicados 
pelos SGSI. Um deles foi definido por Elaine Vaughan em seu livro Risk 
Management, de 1997. Ele é composto por seis atividades sincronizadas 
que formam um ciclo infinito de gerenciamento (Figura 5).
Figura 5
Gerenciamento de risco Elaine Vaughan
Definição dos 
objetivos
Avaliação e 
revisão dos 
riscos
Implementação 
do controle 
do risco
Planejamento 
do tratamento 
de risco
Análise dos 
riscos
Identificação 
dos riscos
Fonte: Elaborada pelo autor com base em Vaughan,1997.
 Outro modelo, adotado pelos SGSI, foi proposto no Guide for 
Conducting Risk Assessments – SP 800-30 ver.1 (GCRA-800-30). Esse do-
cumento é um guia de boas práticas da agência governamental nor-
te-americana, chamada National Institute of Standards and Technology 
(NIST). O modelo possui nove etapas, sempre com entradas e saídas 
definidas. Na Figura 6 é possível visualizá-las.
70 Segurança e auditoria de sistemas
Figura 6
Fluxo para o gerenciamento de risco
 • Hardware
 • Softwares
 • Dados
 • Pessoas
 • Propósito do sistema
 • Fronteiras dos sistemas
 • Funções essenciais de um sistema
 • Dados sensíveis
Passo 1 – Identificação do 
escopo de trabalho
Passo 2 – 
Identificação das ameaças
Passo 3 – 
Identificação de 
vulnerabilidades
Passo 4 – 
Análise do risco
Passo 5 – 
Determinação da 
probabilidade de 
acontecer o risco
Passo 6 – 
Análise do impacto 
do risco aos negócio
 • Histórico de ataques
 • Relatórios de órgãos oficiais que 
trabalham com segurança
 • Lista com possíveis ameaças
 • Ferramentas que identificam vul-
nerabilidades em hardware, soft-
ware e na rede.
 • Lista de potenciais 
vulnerabilidades
 • Controles de riscos já utilizados 
pela empresa.
 • Lista de controles de riscos 
atualizada
 • Informações de mercado refe-
rentes à probabilidade de aquela 
ameaça acontecer.
 • Ranking dos riscos que mais 
impactam a continuidade dos 
negócios
(Continua)
 • Matriz de impacto do risco para a 
continuidade dos negócios.
 • Ranking dos riscos por probabili-
dade de ocorrência
ENTRADA ETAPAS DO GERENCIAMENTO 
DO RISCO
SAÍDAS
Passo 7 – 
Determinação da criticidade 
do risco
Passo 8 – 
Recomendações para 
mitigar o risco
Passo 9 – 
Documentação e 
apresentação dos resultados
 • Ranking de probabilidade do risco
 • Ranking de impacto dos riscos
 • Ranking de riscos por probabili-
dade x impacto
 • Relatório de recomendações
 • Apresentação dos riscos e resul-
tados alcançados
Fonte: Adaptada de NIST, 2012, p. 9.
Nos passos 5, 6 e 7 da Figura 6 estão as atividades de análise de 
impacto do risco e a probabilidade de ocorrência. Aconselhamos uti-
Segurança de sistemas da informação 71
lizar uma escala com três níveis: alto, médio ou baixo – conforme o 
Quadro 1. Nesse quadro temos os eixos de impacto e de probabilidade. 
Os riscos com alto impacto e alta probabilidade devem ser priorizados, 
necessitando de uma ação imediata para mitigar a vulnerabilidade e 
reduzir as ameaças.
Quadro 1
Matriz para determinação do risco por probabilidade e impacto
Alta probabilidade x Baixo impacto Alta probabilidade x Médio impacto Alta probabilidade x Alto impacto
Média probabilidade x Baixo impacto Média probabilidade x Médio impacto Média probabilidade x Alto impacto
Baixa probabilidade x Baixo impacto Baixa probabilidade x Médio impacto Baixa probabilidade x Alto impacto
PR
O
BA
BI
LI
D
AD
E
IMPACTO
Fonte: Elaborado pelo autor.
Utilizar uma escala maior nessa matriz costuma complicar a tomada 
de decisão, pois mais cenários de determinação de riscos serão passí-
veis de definição. Imagine a seguinte escala: baixíssimo, baixo, médio, 
alto e altíssimo. A matriz passará de nove possibilidades para 25, con-
forme o Quadro 2.
Quadro 2
Matriz para determinação do risco por probabilidade e impacto com escala de cinco possibilidades
PR
O
BA
BI
LI
D
AD
E
IMPACTO
Altíssima probabi-
lidade x Baixíssimo 
impacto
Altíssima probabilida-
de x Baixo impacto
Altíssima probabilida-
de x Médio impacto
Altíssima probabilida-
de x Alto impacto
Altíssima probabi-
lidade x Altíssimo 
impacto
Alta probabilidade x 
Baixíssimo impacto
Alta probabilidade x 
Baixo impacto
Alta probabilidade x 
Médio impacto
Alta probabilidade x 
Alto impacto
Alta probabilidade x 
Altíssimo impacto
Média probabilidade 
x Baixíssimo impacto
Média probabilidade 
X Baixo impacto
Média probabilidade 
xMédio impacto
Média probabilidade 
x Alto impacto
Média probabilida-
de x Altíssimo im-
pacto
Baixa probabilidade x 
Baixíssimo impacto
Baixa probabilidade x 
Baixo impacto
Baixa probabilidade x 
Médio impacto
Baixa probabilidade x 
Alto impacto
Baixa probabilidade 
x Altíssimo impacto
Baixíssima probabi-
lidade x Baixíssimo 
impacto
Baixíssima probabili-
dade x Baixo impacto
Baixíssima probabilida-
de x Médio impacto
Baixíssima probabili-
dade x Alto impacto
Baixíssima proba-
bilidade x Altíssimo 
impacto
Fonte: Elaborado pelo autor.
O documento GCRA-800-30 também apresenta um modelo de qua-
dro para gerenciar os riscos de segurança da informação. Ela deverá 
ser preenchida a partir da etapa 2 (identificação de ameaças). Esse ma-
terial será o guia de mitigação de vulnerabilidades e de ameaças e de-
verá ser atualizado mensalmente.
72 Segurança e auditoria de sistemas
Quadro 3
Exemplo de quadro para o gerenciamento de riscos
Risco 
identificado 
(vulnerabilida-
de ou ameaça)
Nível 
de 
risco
Ações 
recomendáveis 
para mitigar 
risco
Priorida-
de para 
executar 
as ações
Recursos 
necessários
Responsá-
veis (time 
ou pessoa)
Data da 
identifica-
ção
Requisitos 
para 
manutenção 
do risco
Biblioteca Log4J 
desatualizada no 
software XPTO
Alto
Atualizar a bi-
blioteca Log4J da 
versão 1.2 para 
1.4.1 e atualizar 
o software em 
produção.
Alto
Time de 
desenvolvi-
mento de 
software
Cleberson 
(gerente de 
projetos do 
software 
XPTO)
20/12/2021
Utilizarum 
software para 
análise estática 
de código que 
identificará quais 
vulnerabilidades 
precisam ser 
tratadas.
Licenças de 
Windows 7 
vencidas
Médio
Contratar novas 
licenças do siste-
ma operacional 
Windows. Após a 
contratação, será 
necessário atua-
lizar as licenças 
das máquinas 
com licenças 
vencidas.
Médio
 Departa-
mento de 
compras e 
setor de TI
Osmar (com-
pras)
Ari (atuali-
zação das 
licenças)
10/01/2022
Criar uma lista de 
quantas licenças 
de Windows 
precisarão ser 
renovadas para o 
ano de 2022.
Fonte: Adaptado de NIST, 2012, p. C-1.
Além dos conceitos de risco, ameaça e vulnerabilidade, outros ter-
mos importantes devem ser elucidados. Como o chamado risco resi-
dual, o qual trata de um risco que continua existindo mesmo após o seu 
tratamento. Já o termo ataque se refere a uma tentativa bem-sucedida 
de ameaça, pois visa destruir, alterar ou roubar algum ativo.
Hintzbergen (2018, p. 21) define ativo como: “qualquer coisa que 
tenha valor para a organização. Esta é uma definição ampla, você pode 
pensar em instalações, informação, software, hardware, serviços im-
pressos (papéis), mas também em pessoas, habilidades, experiência e 
coisas intangíveis, como reputação e imagem”.
O termo exposição é utilizado para sinalizar que determinado ati-
vo não está devidamente protegido. A exposição costuma acontecer 
quando há alguma vulnerabilidade não solucionada, por exemplo: um 
conjunto de informações sensíveis (login e IP de servidores) foi coloca-
do em uma apresentação de slides para palestra em um grande evento 
de tecnologia, havendo a transmissão pela internet com o vídeo dis-
ponibilizado em plataforma on-line. Como não houve a preocupação 
de validar quais dados poderiam aparecer nos slides, todas as infor-
Para saber mais sobre a 
avaliação de riscos e seu 
gerenciamento, assista a 
aula do professor Samuel 
Martins, do Instituto Fede-
ral de Educação, Ciência e 
Tecnologia de São Paulo. 
Nessa aula, você revisará 
os conceitos de risco, 
ameaça e vulnerabilidade 
e como avaliar riscos.
Disponível em: https://
www.youtube.com/
watch?v=NokZAqWoyUU. Acesso 
em: 3 mar. 2022.
Vídeo
https://www.youtube.com/watch?v=NokZAqWoyUU
https://www.youtube.com/watch?v=NokZAqWoyUU
https://www.youtube.com/watch?v=NokZAqWoyUU
Segurança de sistemas da informação 73
mações foram expostas. Para mitigar esse dano, os IPs dos servidores 
precisarão ser alterados.
Já o termo grau de sigilo costuma ser usado para definir a categoria 
de um documento, e-mail ou informação. Para empresas privadas, o 
grau de sigilo costuma ser:
 Confidencial: pouquíssimas pessoas da organização acessam a 
informação.
 Privado: poucas pessoas da organização acessam a informação.
 Sigiloso: todas as pessoas da organização acessam a informação.
 Público: qualquer pessoa pode acessar a informação.
Em alguns órgãos públicos, o grau de sigilo confidencial costuma ser 
chamado de ultrassecreto e o grau privado é chamado de secreto.
Agora conhecemos o que são SGSI, seus princípios e o significado 
dos principais termos em segurança da informação. Na sequência, va-
mos abordar a ISO 27000, que abrange diversas boas práticas para a 
implementação de SGSI em organizações.
tri
ut
am
is
/S
hu
tte
rs
to
ck
Figura 7
Grau de sigilo da infor-
mação
St
ar
os
to
v/
Sh
ut
te
rs
to
ck
3.3 Família de normas ISO 27000 
Vídeo
A International Organization for Standardization (ISO) é uma entida-
de mundial que organiza, padroniza e normaliza temas em mais de 162 
países. Fundada em 1947, sua sede é em Genebra, Suíça. No Brasil, a ISO 
é representada pela Associação Brasileira de Normas Técnicas (ABNT).
Os padrões sugeridos pela ISO ajudam indústrias e prestadores de 
serviços na execução de seus trabalhos e na garantia da qualidade dos 
produtos, pois se uma empresa brasileira segue determinada ISO, todo 
o mundo confiará em seus padrões de boas práticas.
Figura 9
Logo da ISO
AS
AG
 S
tu
di
o/
 S
hu
tte
rs
to
ck
Figura 8
Selo da certificação ISO 
9001:2015
Dn
 B
r/
Sh
ut
te
rs
to
ck
74 Segurança e auditoria de sistemas
A ISO é composta por diversas normas, sendo as mais conhecidas a 
ISO 9000 (ligada à gestão da qualidade) e a ISO 14000 (focada na gestão 
de políticas sustentáveis para o meio ambiente). No Quadro 4 apresen-
tamos outras normas mantidas pela ISO e a respectiva descrição.
Quadro 4
Lista de normas mantidas pela ISO
Número da ISO Descrição
31 Normas que definem tamanhos e unidades.
216 Norma para definir formatos e dimensões de papéis.
269 Norma para definir formatos e dimensões de envelopes.
2108 Norma que define o ISBN (sistema internacional de identificação de livros).
3166 Norma que define os códigos dos países e suas subdivisões.
4217 Norma que define os códigos monetários.
8859 Norma que define a codificação de caracteres em um computador.
Família ISO 9000 Conjunto de normas que definem a gestão da qualidade de um sistema produtivo.
9126 Norma que define o processo de gestão da qualidade na engenharia de software.
12207 Norma que define os processos de engenharia de software.
Família ISO 14000 Conjunto de normas que define a gestão sustentável do meio ambiente por uma organização.
Família ISO 27000 Conjunto de normas que define a gestão da segurança da informação em empresas.
Fonte: Elaborado pelo autor.
Em alguns casos, o mesmo número da ISO é utilizado para repre-
sentar um subconjunto de normas menores, mas de conteúdos seme-
lhantes. É o caso das ISO 9000, 14000 e 27000.
Boa parte das ISOs possuem certificações que comprovam que a or-
ganização segue o padrão estabelecido pela norma. Esses certificados 
têm validade mundial e são emitidos por órgãos credenciados e espe-
cialistas em determinadas normas. O processo de certificação valida se 
cada item está sendo realizado e se há evidências organizacionais para 
comprovar o procedimento. A certificação é um processo semelhante 
ao modelo de auditoria de sistema, o qual busca evidências para com-
provar o uso de uma boa prática. A certificação ISO é dada por norma 
e não por família de normas. Por exemplo, uma empresa pode tirar a 
certificação ISO 9001 e não a ISO 9000, pois a última representa uma 
família de normas. Essa regra vale para a ISO 27000, uma família de 
normas (por exemplo, uma empresa pode se certificar com a ISO 27001 
e 27002, em momentos distintos).
Segurança de sistemas da informação 75
Os selos de certificação costumam ser emitidos com o número da 
ISO e a versão da norma utilizada, a qual costuma ser o ano da publica-
ção da norma atualizada. Na Figura 8, o selo é da ISO 9001, na versão 
2015 da norma.
Em 2005, o comitê responsável pela segurança da informação na 
ISO aprovou a criação de uma gama de normas referentes à gestão 
da segurança da informação. A publicação teve o nome da série 27000 
(GALVÃO, 2015) e as normas ISO 27001 e 27002 são passíveis de certifi-
cados. O objetivo da ISO 27000 é auxiliar as organizações na adoção de 
práticas de segurança da informação (SGSI), e que elas sejam padroni-
zadas em todo o mundo.
 No ano seguinte, a ABNT traduziu e publicou a ABNT NBR ISO/IEC 
27001:2006 Tecnologia da informação – Técnicas de Segurança – Siste-
mas de Gestão de Segurança da Informação – Requisitos. Trinta e seis 
normas fazem parte da ISO 27000.
Quadro 5
Lista de normas da família ISO 27000 
Número da ISO Descrição
27000:2014
Fornece uma visão geral/introdução às normas ISO 27000; um glossário para o vocabulário es-
pecializado.
27001:2013
É a norma para os requisitos do sistema de gerenciamento de segurança da informação (SGSI). É 
uma especificação formal para um SGSI.
27002:2013
É o código de prática para controles de segurança da informação, que descreve os controles e 
objetivos referentes às boas práticas de controle de segurança da informação.
27003:2010 Fornece orientações sobre a implementação da ISO 27001.
27004:2009 Abrange as medições da gestão de segurança da informação.
27005:2011 Abrange a gestão de riscos da segurança da informação.27006:2011
É um guia para o processo de certificação ou registro para organismos que são acreditados para 
certificação ou registro do SGSI.
27007:2011 É um guia para auditoria do SGSI.
TR 27008:2011 Diz respeito à auditoria de controles “técnicos” de segurança.
27009 Irá aconselhar os que produzem normas para aplicações setoriais da ISO 27000. 
27010:2012
Fornece orientação sobre o gerenciamento de segurança da informação para comunicações en-
tre setores e organizações.
27011:2008
É a diretriz de gerenciamento de segurança da informação para as organizações de telecomuni-
cações.
27013:2012
Fornece orientações sobre a implementação integrada da ISO 27001 (SGSI) e ISO 20000-1 
(gerenciamento de serviços de TI).
27014:2013 Oferece orientações sobre a governança da segurança da informação.
(Continua)
(Continua)
76 Segurança e auditoria de sistemas
Número da ISO Descrição
TR 27015:2012 Fornece diretrizes para o gerenciamento de segurança da informação para serviços financeiros.
TR 27016:2014 Cobre a economia da gestão da segurança da informação.
27017 Abrangerá os controles de segurança da informação para a computação em nuvem.
27018
Cobre informações de identificação pessoal (Personally Identifiable Information – PII) em nuvens 
públicas.
TR 27019:2013 Abrange a segurança da informação para o controle de processos no setor de energia.
27021
Propõe explicar competências e conhecimentos exigidos pelos profissionais de gestão da segu-
rança da informação.
TR 27023 Faz o mapeamento entre as versões de 2005 e 2013 da 27001 e da 27002.
27031:2011
É um padrão focado nas tecnologias da informação e comunicação (TIC) sobre continuidade dos 
negócios.
27032:2012 Cobre segurança cibernética.
27033:2009+ Está substituindo a norma sobre segurança de redes de TI ISO 18028.
27034:2014 Fornece diretrizes para segurança de aplicativos.
27035:2011 É sobre gestão de incidentes de segurança da informação.
27036:2013+
É uma diretriz de segurança para o relacionamento com fornecedores, incluindo os aspectos de 
gestão do relacionamento na computação em nuvem.
27037:2012 Cobre a identificação, coleta e preservação de evidências digitais.
27038:2014 É uma especificação para a edição digital.
27039 Incide sobre sistemas de detecção e prevenção de intrusões.
27040 Oferece orientações sobre segurança do armazenamento.
27041 Oferece orientações sobre a confiança dos métodos de investigação de provas digitais.
27042 Oferece orientações sobre a análise e a interpretação de evidências digitais.
27043 Oferece orientações sobre princípios e processos de investigação de evidências digitais.
27044 Oferece orientações sobre gerenciamento de incidentes e eventos de segurança.
27050
Oferece orientação sobre padrões forenses digitais com o propósito de contribuir para a captura 
de evidências digitais.
27799:2008
Fornece orientações específicas para a implementação de SGSI no setor de saúde, com base na 
ISO 27002:2005.
Fonte: Hintzbergen, 2018, p. 167.
Agora já sabemos quais são as normas da família 27000, então al-
guns cuidados devem ser tomados ao adotá-las em uma organização:
 • Não siga uma norma somente para tirar a certificação. Se esse for 
o objetivo da organização, em pouco tempo os processos estarão 
fora da norma.
 • Cuidado para não aplicar erroneamente uma norma. Aplique-a e, 
com frequência, valide se o item adotado ainda faz sentido.
 • Busque mais ter um ambiente de melhoria contínua do que cheio 
de regras que tendem a burocratizar o dia a dia.
No vídeo do canal Portal 
GSTI, Fernando Palma 
apresenta um resumo das 
normas ISO 27001, ISO 
27002, ISO 27003, ISO 
27004 e ISO 27005. 
Disponível em: https://www.
youtube.com/watch?v=oYu_
hseq6AM. Acesso em: 7 mar. 2022.
Vídeo
https://www.youtube.com/watch?v=oYu_hseq6AM
https://www.youtube.com/watch?v=oYu_hseq6AM
https://www.youtube.com/watch?v=oYu_hseq6AM
Segurança de sistemas da informação 77
Ao seguir esses cuidados você conseguirá usufruir dos benefícios da 
norma em sua totalidade.
CONSIDERAÇÕES FINAIS
Neste capítulo conhecemos os Sistemas de Gestão da Segurança da 
Informação (SGSI), modelos de boas práticas que ajudam na implantação 
efetiva da segurança da informação em organizações. Um SGSI costuma 
estar baseado no modelo CIA de informação ou no hexagrama parkeriano 
e possui diversas normas que ajudam na aplicação dos processos e das 
boas práticas. 
As normas mais conhecidas a respeito desse tema estão agrupadas na 
família ISO 27000. Conhecê-las e estudá-las a fundo maximizará o sucesso 
de um SGSI em uma organização. 
ATIVIDADES
Atividade 1
Um hacker conseguiu acessar um servidor e alterou as páginas 
web que estavam hospedadas nele. Quais princípios do modelo 
CIA foram violados nesse ataque?
Atividade 2
Diferencie uma ameaça ativa de uma ameaça passiva.
Atividade 3
Uma empresa de software contratou outra empresa que fornece 
ambientes na nuvem (cloud). Qual é a norma da família ISO 27000 
que cuida desse tema?
78 Segurança e auditoria de sistemas
REFERÊNCIAS
ABNT. NBR ISO/IEC 27002:2005: tecnologia da informação: técnicas de segurança – código 
de prática para a gestão da segurança da informação. Rio de Janeiro, 2005.
CERT.BR – Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança no 
Brasil. Estatísticas dos incidentes reportados ao CERT.br. CERT.br, 3 ago. 2021a. Disponível 
em: https://cert.br/stats/incidentes/index.html. Acesso em: 3 mar. 2022.
CERT.BR – Centro de Estudos, Resposta e Tratamento de Incidentes de Segurança no 
Brasil. Incidentes reportados ao CERT.br – Janeiro a Dezembro de 2020. CERT.br, 3 ago. 
2021b. Disponível em: https://cert.br/stats/incidentes/2020-jan-dec/tipos-ataque.html. 
Acesso em: 3 mar. 2022.
GALVÃO, M. C. Fundamentos em segurança da informação. Pearson, 2015.
HINTZBERGEN, J. et al. Fundamentos de Segurança da Informação: com base na ISO 27001 e 
na ISO 27002. Rio de Janeiro: Brasport, 2018.
MCGRAW, G. The 7 Touchpoints of Secure Software. Dr. Dobb’s, 1 set. 2005. Disponível em: 
http://www.drdobbs.com/the-7-touchpoints-of-secure-software/184415391. Acesso em: 3 
mar. 2022.
NIST. SP 800-30, Rev. 1: guide for conducting risk assessments. NIST Information Technology 
Laboratory, set. 2012. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-30/
rev-1/final. Acesso em: 3 mar. 2022.
VIEGA, J.; MCGRAW, G. Building Secure Software: how to avoid security problems the right 
way. Addison-Wesley, 2006.
VAUGHAN, E. Risk Management. New Baskerville: John Wiley & Sons, 1997.
https://www.drdobbs.com/the-7-touchpoints-of-secure-software/184415391
https://csrc.nist.gov/publications/detail/sp/800-30/rev-1/final
https://csrc.nist.gov/publications/detail/sp/800-30/rev-1/final
Modelos de maturidade para segurança da informação 79
4
Modelos de maturidade para 
segurança da informação
A segurança da informação é um tema atual e complexo, pois a tecnologia 
e o uso das informações nas organizações estão presentes no uso de hardwares e 
softwares, nos recursos de internet e no acesso a dados. O gestor da segurança da 
informação tem o grande desafio de estar atento às particularidades de cada tema 
mencionado, para ter um sistema de gestão da segurança da informação (SGSI) 
que reduza os riscos de invasão, o acesso indevido às informações e o seu roubo.
Em empresas que atuam na criação e manutenção de softwares, as singulari-
dades são muitas; pensando nisso, diversos modelos para gerir a segurança da 
informação em software foram criados.
Neste capítulo, conheceremos os conceitos referentes ao ciclo de desenvolvi-
mento de software seguro (SSDLC), bem como os seus níveis de maturidade para 
evoluir o ciclo de análise, codificação, testes e manutenção de software.
Com o estudo deste capítulo, você será capaz de:
• compreender o que é um SSDLC e conhecer o modelo SAMM e 
como realizar aferições de maturidade;
• descrever a área de negócio governança, prevista no modelo SAMM, 
e como realizar a aferição desse item;
• descrever a área de negóciodesign, prevista no modelo SAMM, e 
como realizar a aferição desse item;
• descrever a área de negócio implementação, prevista no modelo 
SAMM, e como realizar a aferição desse item;
• descrever as áreas de negócio verificação e operação, previstas no 
modelo SAMM, e como realizar a aferição desses itens.
Objetivos de aprendizagem
80 Segurança e auditoria de sistemas
4.1 SSDLC e modelo SAMM 
Vídeo Existem diversas formas de se construir um software, mas, existindo 
um processo definido e repetitivo, muitos benefícios são alcançados, 
como a possibilidade de medir a velocidade de trabalho e de ampliar 
a qualidade do software produzido, ao checar se o que está sendo de-
senvolvido é o que foi solicitado.
Esse processo de desenvolvimento é chamado de ciclo SDLC (software 
development life cycle). Nele estão as seguintes etapas sequenciadas: re-
quisitos, design, desenvolvimento, testes e geração de versões (Figura 1).
Definição de 
requisições Desenvolvimento
Desenho da 
solução (design) Testes
Geração de 
versão
Figura 1
Etapas do SDLC 
Fonte: Elaborada pelo autor.
Segundo Ferreira (2019, p. 25), o SDLC integra todo o trabalho de 
desenvolvimento de software, tendo por objetivo "obter soluções com 
a melhor qualidade a menor custo num menor espaço de tempo, vi-
sando à melhoria da qualidade, eficácia e eficiência". Com base nesse 
processo, é possível entregar um software de modo incremental, ou 
seja, com frequência mensal, semanal ou mesmo diversas vezes ao dia.
O ciclo SDLC foi definido antes de surgirem os modelos de SGSI. 
Com o seu advento de segurança da informação, o SDLC passou por 
uma evolução, passando a ser chamado de security software development 
life cycle (SSDLC). Nessa proposta, não há a inclusão de novas etapas de 
trabalho; o que muda é que, em cada etapa (Figura 1), devem ser exe-
cutadas atividades referentes à segurança da informação, para garantir 
ao software a aderência aos SGSIs e reduzir riscos que comprometam o 
negócio da organização. Na Figura 2, é apresentado o grupo de ativida-
des que devem ser realizadas em cada etapa do SSDLC. 
Aferição 
de riscos
Análise estática 
de código-fonte
Modelagem 
de ameaças e 
revisão de design
Testes de 
segurança e 
revisão de código
Identificação 
do nível de 
segurança
Figura 2
SSDLC
Fonte: Elaborada pelo autor.
Definição de 
requisições Desenvolvimento
Desenho da 
solução (design) Testes
Geração de 
versão
Modelos de maturidade para segurança da informação 81
De acordo com Ferreira (2019, p. 26), os benefícios de adotar SDLC são:
 • Software mais seguro e robusto, já que a segurança é uma preo-
cupação desde o início do processo;
 • Consciencialização dos stakeholders, sejam estes os utilizadores, 
desenvolvedores ou outra equipe de gestão, contribuindo para a 
transparência e segurança do processo;
 • Detecção precoce de vulnerabilidades no sistema, contribuindo 
para a qualidade;
 • Redução de custos devido a detecção e resolução de problemas;
 • Redução de riscos intrínsecos à organização.
Ao se adotar o SSDLC, uma empresa passa a realizar o mapeamento 
de riscos de segurança em tempo de análise de requisitos, simulações 
de ameaça, análise de código-fonte e testes de penetração (pentest). 
Essas atividades reduzem a possibilidade de um software com bre-
chas de segurança, porém não garantem 100% de segurança, pois as 
pessoas envolvidas na sua construção (analistas, desenvolvedores e 
testadores) podem negligenciar uma validação por omissão ou falta de 
controle automatizado de atividades.
Para implementar um SSDLC, podemos utilizar frameworks que 
apresentam o passo a passo de adoção de práticas de segurança em 
cada etapa do desenvolvimento de software. Modelos como Capability 
Maturity Model (CMM), Agile Methods e Correctness by Construction 
tratam, especificamente, de SDLC com algumas práticas de segurança. 
Esses frameworks são úteis, mas não orientados a SSDLC, por isso é 
aconselhável usar algum dos mencionados a seguir para abranger mais 
pontos de segurança da informação:
 • Microsoft Security Development Lifecycle (MSSDL);
 • Team Software Process for Secure Software Development (TSP); 
 • Common Criteria (CC);
 • Building Security In Maturity Model (BSIMM);
 • Software Assurance Maturity Model (SAMM).
Alguns desses nomes são proprietários e refletem o modelo de tra-
balho de uma organização, por exemplo, o framework MSSDL. Você não 
precisa pagar para utilizá-lo, mas pode ter dificuldade em encontrar 
material de referência para adotá-lo.
O modelo TSP é uma proposta acadêmica da Carnegie Mellon 
University e não é muito adotado pelas organizações que produzem 
82 Segurança e auditoria de sistemas
software. Já o modelo CC é um padrão internacional para segurança de 
computadores e é a base para a norma ISO 15408, porém também é 
pouco adotado pelas organizações, pois não apresenta tanta adaptabi-
lidade para os desafios da criação de software. Nesse mesmo cenário, 
podemos incluir o BSIMM, criado e mantido pela Synopsys.
Entre esses modelos, o que conta com mais adeptos é o SAMM, pois 
se trata de open source, permite maior colaboração e adaptabilidade e 
recebe atualização frequente. Esse modelo é mantido pela Open Web 
Application Security Project (OWASP), ou Projeto Aberto para Segurança 
de Aplicativos na Web, órgão sem fins lucrativos e que possui um comi-
tê com membros de organizações mundiais que produzem software.
O modelo SAMM não é o único material produzido e mantido pela 
OWASP. Há materiais referentes às principais formas de ataque na 
internet, às vulnerabilidades em sistemas web e às práticas para elevar 
a maturidade de um sistema de segurança da informação. Por prover 
todo esse material e contar com muitas empresas de TI envolvidas na 
manutenção dele, podemos considerar o conteúdo da OWASP como 
referência para o tema de segurança da informação em software. 
Figura 3
Open Web Application Security Project (OWASP) 
d3
ve
rro
/S
hu
tte
rs
to
ck
(Aberto) (Web) (Aplicações) (Segurança) (Projeto)
Referente ao modelo SAMM, diversas versões já foram publicadas, 
sendo que as primeiras não eram de responsabilidade da OWASP. 
Após o lançamento da versão 1.0, os criadores do SAMM transferiram a 
responsabilidade do framework para a OWASP. No Quadro 1, encontra-
mos uma referência cronológica das versões do framework.
Para saber mais sobre 
a OWASP, acesse o site 
clicando no link a seguir. 
Disponível em: https://owasp.org/. 
Acesso em: 3 mar. 2022.
Site
A OWASP é conhecida 
pelo relatório OWASP TOP 
10, que apresenta as dez 
principais formas de ata-
ques a softwares na web 
nos últimos anos. Para 
saber mais sobre esse 
relatório e quais são os 
tipos de ataque, assista ao 
vídeo Treinamento Starter 
- Aula 04 - O que é OWASP 
Top 10, do canal Conviso 
Application Security. 
Disponível em: https://
www.youtube.com/
watch?v=kORouZTKyWw. Acesso 
em: 15 fev. 2022.
Vídeo
https://owasp.org/
https://www.youtube.com/watch?v=kORouZTKyWw
https://www.youtube.com/watch?v=kORouZTKyWw
https://www.youtube.com/watch?v=kORouZTKyWw
Modelos de maturidade para segurança da informação 83
Quadro 1
Versões do framework SAMM
Versão Data de lançamento Responsável Mudanças
Beta 21/08/2008
Pravir Chandra, 
com suporte da 
empresa Fortify 
Software.
–
1.0 25/03/2009 Pravir Chandra
Mudança nas diversas nomenclaturas 
dos pilares do SAMM, realizadas com 
base no feedback dos leitores da ver-
são Beta.
1.1 16/03/2016 OWASP
Inclusão de um guia para início rápido 
e de um guia resumido de conceitos, 
bem como de referências dos temas 
com as ferramentas já desenvolvidas 
pela OWASP, como OWASP Zed Attack 
Proxy Project e OWASP Application 
Security Verification Standard.
1.5 13/04/2017 OWASP
Adaptação na forma de pontuação du-
rante a aferição da maturidade para 
cada tema do SAMM.
2.0 31/01/2020 OWASP
Inclusão de novas áreas de observa-
ção e de maturidade: implementação 
e gestão operacional. Atualização da 
etapa de verificação e remoção de prá-ticas obsoletas.
Fonte: Elaborada pelo autor.
Esse framework pode ser utilizado por qualquer empresa produtora 
de software, independentemente de seu porte, uma vez que ele não é di-
recionado a um tipo de software. SAMM não é orientado a determinada 
linguagem de programação ou a algum de banco de dados; ele fornece 
uma maneira eficaz e mensurável de analisar a segurança em software e 
promove a conscientização e a educação organizacional no tema SSDLC.
Ao implantar o SAMM, é possível medir a maturidade do ciclo de 
desenvolvimento e elaborar um mapa de trabalho para subida de ní-
vel de maturidade. Gestão e evolução do ciclo de desenvolvimento 
são itens avaliados na ISO 27001, por isso empresas que desejam essa 
certificação costumam investir fortemente na adoção do SAMM.
O SAMM é baseado em cinco áreas de negócios (business function) e, 
em cada uma delas, existem práticas de segurança (security practice). Para 
a versão 2.0, são 15 práticas distribuídas nas cinco áreas de negócios.
84 Segurança e auditoria de sistemas
Em cada prática, há um conjunto de atividades (streams) e cada uma 
destas possui um nível de maturidade, iniciando em 1 indo até o 3. As 
atividades em nível de maturidade mais baixo geralmente são de execu-
ção fácil e exigem menos formalização do que aquelas de nível mais alto. 
Na Figura 4, é possível entender essa estrutura em formato gráfico.
Figura 4
Estrutura do SAMM
Área de negócio
Práticas de 
segurança 
Atividade A
Atividade de nível 1 
Atividade de nível 2
Atividade de nível 3
Atividade B
Fonte: Elaborada pelo autor.
O Quadro 2 apresenta as cinco áreas de negócio e as suas respecti-
vas práticas de segurança e atividades a serem desenvolvidas. 
Quadro 2
Áreas de negócio e práticas de segurança do SAMM
Áreas de 
negócio Práticas de segurança Atividade
Governança
Estratégia e métricas
Criação e promoção.
Medição e melhorias.
Políticas e conformidade 
(compliance)
Políticas e padrões.
Gerenciamento da conformidade.
Educação e orientação
Treinamento e conscientização.
Organização e cultura.
Design
Avaliação de ameaças
Elaboração do perfil de risco.
Modelagem de ameaças.
Requisitos de segurança
Requisitos do software.
Segurança do fornecedor.
Arquitetura segura
Design de arquitetura.
Gerenciamento da tecnologia.
(Continua)
Modelos de maturidade para segurança da informação 85
Áreas de 
negócio Práticas de segurança Atividade
Implementação
Desenvolvimento seguro
Processo de compilação (build).
Gerenciamento de dependências. 
Implantação segura
Processo de implantação 
(deployment).
Gerenciamento de credenciais de 
software .
Gerenciamento de defeitos
Rastreamento do defeito.
Métricas e feedback.
Verificação
Avaliação da arquitetura
Validação da arquitetura.
Mitigação da arquitetura.
Testes orientados a requisitos
Verificação de controle.
Testes de uso indevido/abusivo.
Testes de segurança
Baseline escalável.
Compreensão profunda.
Operação
Gerenciamento de incidentes
Detecção de incidente.
Resposta a incidente.
Gerenciamento de ambiente
Proteção da configuração.
Correções e atualizações.
Gestão operacional
Proteção a dados.
Gerenciamento de legados.
Fonte: Elaborado pelo autor com base What..., 2020.
Sobre as áreas de negócio, Ferreira (2019, p. 25) ressalta que:
apesar de constituírem áreas distintas, não há de ser necessa-
riamente sequenciais, podem ser iterativas ou concorrenciais. 
Isto é, não é necessário terminar todas as tarefas de uma área 
nuclear para começar tarefas de outra ou, no caso de se verifi-
car que alguma coisa não está em conformidade, não se possa e 
deva rever e retificar tarefas relativas a outra área, mesmo que o 
projeto já esteja noutro estágio. 
Precisamos, ainda, entender como é feito o trabalho de avaliação e 
elevação da maturidade em cada item do framework. O SAMM sugere 
a seguinte sequência:
86 Segurança e auditoria de sistemas
Figura 5
Modelo de trabalho proposto pelo SAMM
Prepare
Entender o trabalho 
a ser realizado
Assess
Realizar a avaliação 
inicial
Set the target
Definir os objetivos de 
mudança
Define the plan
Criar um plano de trabalho
Implement
Executar
Roll-out
Avaliar e expandir
2
3
45
6
1
Fonte: Elaborada pelo autor com base em Deleersnyder; Win; Glas, 2017.
Perceba que esse modelo é cíclico e sem prazo definido para termi-
nar. O que deve ter prazo para término são as ações definidas na 
etapa 4. O SAMM não determina qual o problema ou a área que deve 
ser tratado primeiro. Essa informação deve vir da etapa 2, na qual é 
realizada uma avaliação da maturidade do ciclo de desenvolvimento. 
As áreas de negócio ou as práticas de segurança com menor nota de-
vem ser priorizadas para a etapa 3.
Para a avaliação (assessment), o framework SAMM definiu perguntas 
para cada prática de segurança. Essas perguntas são feitas ao gestor 
de segurança da informação ou ao comitê de responsáveis pelo ciclo de 
desenvolvimento de software. A escala de respostas pode ser a seguinte:
Modelos de maturidade para segurança da informação 87
Quadro 3
 Escala de respostas previstas no SAMM
Nota Resposta
0 Não temos ou não olhamos para esse item.
0,2 Temos poucas ou algumas ações e ferramentas para esse item.
0,5 Temos razoáveis ações e ferramentas para esse item.
1 Temos muitas ações e ferramentas para esse item.
Fonte: Elaborado pelo autor.
Como são diversas perguntas para uma prática de segurança, é ne-
cessário somar o valor das respostas para definir o nível de maturi-
dade daquela área de negócio. Esses níveis podem ir de 0 até 3 e, à 
medida que uma nota se aproxima do 0, deve ser priorizada para ser 
melhorada. No quadro a seguir, encontramos um exemplo da aferição 
para a área de negócio governança, focando a prática de segurança 
estratégia e as métricas.
Quadro 4
Avaliação do SAMM focada na prática de segurança estratégica e nas métricas.
Governança Situação atual
Atividade Nível Estratégia e métricas Resposta Nota
Criar e 
promover
1
Você entende os riscos organizacionais 
aceitos em suas aplicações?
Não temos ou não olhamos 
para esse item.
1,13
2
Você tem um plano estratégico de se-
gurança de aplicativos e o utiliza para 
tomar decisões?
Temos poucas ou algumas ações 
e ferramentas para esse item.
3
Você revisa e atualiza regularmente o pla-
no estratégico de segurança de aplicativos?
Temos poucas ou algumas ações 
e ferramentas para esse item.
Medir e 
melhorar
1
Você usa um conjunto de métricas para 
medir a eficácia e a eficiência do progra-
ma de segurança de aplicativos em todos 
os aplicativos?
Temos razoáveis ações e ferra-
mentas para esse item.
2
Você definiu os principais indicadores de 
desempenho (KPI) com base nas métricas 
de segurança de aplicativos disponíveis?
Temos poucas ou algumas ações 
e ferramentas para esse item.
3
Você atualiza a estratégia e o roteiro de 
segurança de aplicativos com base em mé-
tricas e KPIs de segurança de aplicativos?
Temos muitas ações e ferra-
mentas para esse item.
Fonte: Adaptado de Coblentz; Keary; Deleersnyder, 2020.
88 Segurança e auditoria de sistemas
Ao finalizar a avaliação das áreas, você saberá qual delas está 
mais ou menos madura, para direcionar os temas que precisam de 
atenção imediata.
Essa avaliação deve ser feita com regularidade e pode ser trimestral, 
quadrimestral ou semestral. Cabe, portanto, ao gestor de segurança da 
informação definir a periodicidade, respeitando o contexto e a veloci-
dade da empresa, visto que de nada adiantam avaliações trimestrais se a 
empresa não conseguir focar as atividades de segurança nesse período.
Após a terceira avaliação e com aumentos constantes de maturida-
de, aconselha-se realizar a aferição semestral ou anualmente, pois se 
entende que a empresa já incorporou a cultura de desenvolvimento 
seguro de software.
Depois da segunda verificação, você pode comparar os resultados 
atuais com a avaliação anterior e, então, gerar gráficos comparativos 
sobre a melhora ou não de áreas de negócio do SAMM. 
Ao aprendermossobre o que são SSDLC e entendermos a estrutura 
do framework SAMM, podemos agora conhecer cada área de negócio 
do SAMM, suas respectivas práticas de segurança e como realizar a afe-
rição de maturidade de cada tema.
4.2 Área de negócio: governança 
Vídeo
O conceito de governança em TI se refere aos mecanismos que uma 
organização utiliza para ter eficácia e eficiência no ciclo de desenvol-
vimento de software. Um grau elevado de maturidade nessa área de 
negócio é alcançado quando a organização possui estratégias, métricas 
e políticas definidas, bem como análise de conformidade para essas 
políticas. A governança é desenvolvida com o envolvimento de todos 
e com sessões de treinamento visando à cultura de desenvolvimento 
seguro de software.
Pensando nessas atividades de governança, o modelo SAMM dividiu 
três práticas: estratégia e métricas; políticas e conformidade; e, por fim, 
educação e orientação.
Para fazer o download do 
arquivo SAMM, acesse o 
link a seguir. 
Disponível em: https://github.com/
OWASP/samm/raw/c58b69e-
79f47db17c3ca8b51895903c-
f3291e03f/Supporting%20
Resources/v2.0/toolbox/SAMM_As-
sessment_Toolbox_v2.0.xlsx. 
Acesso em: 3 mar. 2022.
Dica
Existe uma versão 
on-line (em inglês) para 
assessment (avaliação). 
A opção é interessante 
para consultas rápidas e 
simulações. Para acessar 
essa calculadora, visite o 
site da Concord no link 
a seguir. 
Disponível em: https://concordusa.
com/SAMM/. Acesso em: 3 mar. 
2022. 
Site
https://github.com/OWASP/samm/raw/c58b69e79f47db17c3ca8b51895903cf3291e03f/Supporting%20Resources/v2.0/toolbox/SAMM_Assessment_Toolbox_v2.0.xlsx
https://github.com/OWASP/samm/raw/c58b69e79f47db17c3ca8b51895903cf3291e03f/Supporting%20Resources/v2.0/toolbox/SAMM_Assessment_Toolbox_v2.0.xlsx
https://github.com/OWASP/samm/raw/c58b69e79f47db17c3ca8b51895903cf3291e03f/Supporting%20Resources/v2.0/toolbox/SAMM_Assessment_Toolbox_v2.0.xlsx
https://github.com/OWASP/samm/raw/c58b69e79f47db17c3ca8b51895903cf3291e03f/Supporting%20Resources/v2.0/toolbox/SAMM_Assessment_Toolbox_v2.0.xlsx
https://github.com/OWASP/samm/raw/c58b69e79f47db17c3ca8b51895903cf3291e03f/Supporting%20Resources/v2.0/toolbox/SAMM_Assessment_Toolbox_v2.0.xlsx
https://github.com/OWASP/samm/raw/c58b69e79f47db17c3ca8b51895903cf3291e03f/Supporting%20Resources/v2.0/toolbox/SAMM_Assessment_Toolbox_v2.0.xlsx
https://concordusa.com/SAMM/
https://concordusa.com/SAMM/
Modelos de maturidade para segurança da informação 89
A governança só existe se houver um objetivo de segurança, e é 
por meio da estratégia que são definidas as formas de se conquistar 
um objetivo.
A estratégia deve estar pautada em métricas que determina-
rão se a organização está próxima ou não de concluir um objetivo. 
Essa estratégia é chamada de programa de segurança do software e, 
além das métricas, ela deve estar embasada em documentos que defi-
nem a forma de trabalho e de gestão. Esses documentos são denomi-
nados de políticas e padrões e estão previstos no SAMM – tanto o seu 
desenvolvimento quanto a revisão constante.
À medida que os documentos são criados, precisam integrar o dia 
a dia da empresa. Diversas abordagens podem ser realizadas para 
atingir as pessoas, por exemplo, treinamentos, palestras e campanhas 
de conscientização. Realizar essas atividades deve ser algo contínuo, 
até que a cultura de desenvolvimento seguro de software seja criada.
Todas essas práticas de segurança e as suas respectivas ativida-
des serão analisadas por meio de perguntas na avaliação de maturi-
dade do modelo SAMM. O gestor de segurança da informação deve 
respondê-las, ou mesmo um comitê, caso não exista um responsável. 
No próximo quadro, você encontrará perguntas para as atividades de: 
 • criação e promoção da estratégia (programa de segurança do 
software);
 • criação e promoção das métricas para orientar a estratégia;
 • medição e melhorias contínuas tanto com relação à estratégia 
quanto às métricas;
 • definição de padrões e estabelecimento de políticas para o pro-
grama de segurança de software;
 • gerenciamento de políticas e padrões por parte dos colaborado-
res, ou seja, saber se estão agindo com conformidade;
 • treinamento e conscientização continuamente dos colaborado-
res sobre a estratégia, as métricas utilizadas, os padrões e as po-
líticas organizacionais referentes à segurança da informação;
 • promoção da cultura de segurança por meio da formação de 
responsáveis departamentais (security champion). 
Medir é um dos itens 
avaliados como prática 
de segurança na área de 
governança. Mas o que 
podemos medir? Qual é a 
melhor métrica para segu-
rança? No vídeo Métricas 
na gestão de serviços e de 
segurança da informação, 
publicado pelo canal 
Prof. JC, é apresentado 
um processo para criar 
métricas, sendo avaliadas 
aquelas que podem ser 
utilizadas em um projeto 
de software.
Disponível em: https://www.you-
tube.com/watch?v=GHl8pbw3Y_I. 
Acesso em: 3 mar. 2022.
Vídeo
https://www.youtube.com/watch?v=GHl8pbw3Y_I
https://www.youtube.com/watch?v=GHl8pbw3Y_I
90 Segurança e auditoria de sistemas
Quadro 5
Avaliação do SAMM focada na área governança
Governança Situação atual
Atividade Nível Estratégia e métricas Resposta Nota
Criação e 
promoção
1
Você entende os riscos organizacionais aceitos em 
suas aplicações?
0
0,00
2
Você tem um plano estratégico de segurança de aplicativos 
e o utiliza para tomar decisões?
0
3
Você revisa e atualiza regularmente o plano estratégico de 
segurança de aplicativos?
0
 
Medição e 
melhorias
1
Você usa um conjunto de métricas para medir a eficácia e 
a eficiência do programa de segurança de aplicativos em 
todos os aplicativos?
0
2
Você definiu os principais indicadores de desempenho 
(KPI) com base nas métricas de segurança de aplicativos 
disponíveis?
0
3
Você atualiza a estratégia e o roteiro de segurança de aplicati-
vos com base em métricas e KPIs de segurança de aplicativos?
0
 
Atividade Nível Políticas e conformidade (compliance) Resposta Nota
Políticas e 
padrões
1
Você tem e aplica um conjunto comum de políticas e pa-
drões em toda a sua organização?
0
0,00
2
Você publica as políticas da organização em formato de fácil 
interpretação pelas equipes de desenvolvimento?
0
3
Você relata regularmente sobre a conformidade com po-
líticas e padrões e usa essas informações para orientar os 
esforços de melhoria da conformidade?
0
 
Gerenciamento 
da conformidade
1
Você tem uma visão completa de suas obrigações externas 
de conformidade?
0
2
Você tem um conjunto padrão de requisitos de segurança e 
procedimentos de verificação que aborda as obrigações de 
conformidade externa da organização?
0
3
Você relata regularmente sobre o cumprimento das obriga-
ções externas de conformidade e usa essas informações para 
orientar os esforços para fechar as lacunas de conformidade?
0
(Continua)
Modelos de maturidade para segurança da informação 91
Governança Situação atual
 
Atividade Nível Educação e orientação Resposta Nota
Treinamento e 
conscientização
1
Você exige que os funcionários envolvidos no desenvolvi-
mento de aplicativos façam o treinamento SSDLC?
0
0,00
2
O treinamento é personalizado para funções individuais, 
como desenvolvedores, testadores ou security champions?
0
3
Você implementou um sistema de gestão de aprendizagem 
ou equivalente para acompanhar os processos de treina-
mento e certificação de funcionários?
0
 
Organização e 
cultura
1
Você identificou um responsável de segurança (security 
champion) para cada equipe de desenvolvimento?
0
2
A organização possui um centro de excelência de software 
seguro (SSCE)?
0
3
Existe um portal centralizado em que desenvolvedores 
e profissionais de segurança de aplicativos de diferentes 
equipes e unidades de negócios possam se comunicar e 
compartilhar informações?
0
Fonte: Adaptado de Coblentz; Keary; Deleersnyder, 2020.
Em relação à área de negócio governança do framework SAMM, é 
possível perceber a importância de se ter uma estratégia para adotara segurança no ciclo de desenvolvimento. Esse trabalho não é rápi-
do nem fácil, uma vez que exige disciplina na criação de padrões, em 
atualizá-los e em divulgá-los a toda organização. Assim, não pode ser 
executado sem métricas. Na sequência, aprenderemos sobre a área de 
negócio design. 
4.3 Área de negócio: design 
Vídeo Todo desenvolvimento de um software passa pela etapa de aná-
lise, executada por analistas de sistemas, arquitetos e engenheiros 
de software. Eles podem ser da própria organização ou de empresas 
que fornecem a mão de obra especializada, ou seja, os terceirizados. 
A experiência e o conhecimento desses profissionais viabilizam o design 
tanto aderente ao que o cliente precisa quanto orientado à arquitetura 
e à tecnologia definidas pela organização.
A área design do SAMM acrescenta elementos de segurança, visando 
ao início do desenvolvimento do software, com as possíveis ameaças 
mapeadas e os seus respectivos graus de risco definidos.
92 Segurança e auditoria de sistemas
Além dessas atividades, o SAMM apresenta formas de garantir a 
conformidade de trabalho de terceirizados, pois, caso eles não sigam as 
políticas de desenvolvimento seguro da organização, criarão softwares 
com possíveis vulnerabilidades.
A maneira de saber se essas etapas estão sendo seguidas é por 
meio de perguntas respondidas pelo gestor de segurança da informa-
ção ou por um comitê, caso não exista uma pessoa com o papel. No 
Quadro 6, você encontrará os questionamentos apresentados a seguir.
 • Para cada item a ser desenvolvido no software, existe um perfil 
de risco mapeado?
 • Durante a análise do trabalho a ser desenvolvido, ocorreram prá-
ticas para identificar eventuais ameaças ao software e que po-
dem colocar em risco a organização?
 • Os requisitos possuem critérios de segurança? Há uma análise 
para cada demanda?
 • A arquitetura está olhando critérios de segurança?
 • Os colaboradores e terceiros estão comprometidos em desenhar 
uma solução segura de software?
 • Os colaboradores e terceiros estão seguindo a tecnologia de refe-
rência da organização? 
(Continua)
Quadro 6
Avaliação do SAMM focada na área design
Design Situação atual
Atividade Nível Avaliação de ameaças Resposta Nota
Elaboração do 
perfil de risco
1
Você classifica as aplicações de acordo com o risco do 
negócio, com base em um conjunto simples e prede-
finido de perguntas?
0
0,00
2
Você usa controles de risco centralizados e quantifica-
dos para avaliar o risco de negócios?
0
3
Você revisa e atualiza regularmente os perfis de risco 
para seus aplicativos?
0
Modelagem de 
ameaças
1
Você identifica e gerencia falhas de projeto de arquite-
tura com modelagem de ameaças?
0
2
Você usa uma metodologia padrão para modela-
gem de ameaças, alinhada aos níveis de risco de sua 
aplicação?
0
3
Você revisa e atualiza regularmente a metodologia de 
modelagem de ameaças para seus aplicativos?
0
Modelos de maturidade para segurança da informação 93
Design Situação atual
 
Atividade Nível Requisitos de segurança Resposta Nota
Requisitos do 
software
1
As equipes de projeto especificam os requisitos de se-
gurança durante o desenvolvimento?
0
0,00
2
Você define, estrutura e inclui priorização nos artefa-
tos do processo de coleta de requisitos de segurança?
0
3
Você usa uma estrutura de requisitos padrão para 
simplificar a elaboração de requisitos de segurança?
0
 
Segurança do 
fornecedor
1
As partes interessadas analisam as colaborações de for-
necedores para requisitos e metodologia de segurança?
0
2
Os fornecedores cumprem as responsabilidades de 
segurança e as medidas de qualidade dos acordos de 
nível de serviço definidos pela organização?
0
3
Os fornecedores estão alinhados com os controles de 
segurança padrão e as ferramentas e os processos de 
desenvolvimento de software que a organização utiliza?
0
 
Atividade Nível Arquitetura segura Resposta Nota
Design de 
arquitetura
1
As equipes usam princípios de segurança durante 
o projeto?
0
0,00
2
Você usa serviços de segurança compartilhados 
durante o projeto?
0
3
Você baseia seu projeto em arquiteturas de referência 
disponíveis?
0
 
Gerenciamento 
da tecnologia
1
Você avalia a qualidade da segurança das princi-
pais tecnologias utilizadas no desenvolvimento 
de software?
0
2
Você tem uma lista de tecnologias recomendadas 
para a organização?
0
3
Você impõe o uso de tecnologias recomendadas 
dentro da organização?
0
Fonte: Adaptado de Coblentz; Keary; Deleersnyder, 2020.
O design do framework SAMM deve abranger tanto a análise de re-
quisitos quanto a definição de arquitetura do software. Todos os en-
volvidos na elaboração de um desenho de solução devem seguir os 
critérios de segurança da organização, independentemente de serem 
colaboradores ou terceirizados. Na sequência, veremos a área de ne-
gócio implementação.
94 Segurança e auditoria de sistemas
4.4 Área de negócio: implementação 
Vídeo
Uma alteração em um software começa a ser desenvolvida após a 
etapa de análise e design e, para isso, ferramentas específicas para pro-
gramação e geração de um software executável serão utilizadas.
Para a programação, um engenheiro costuma utilizar um software 
do tipo IDE (interface de desenvolvimento); já para a construção de 
um software, são usadas ferramentas de DevOps, como versiona-
dores de código-fonte e softwares de testes automatizados e de 
integração contínua.
Essa construção é comumente chamada de fazer um build, mo-
mento em que o programador solicita a compilação do código-fonte, 
ou seja, transforma códigos digitados por ele em algo utilizável por 
uma outra pessoa. Após a compilação, o software precisa ser disponi-
bilizado ao usuário final, o que pode ser feito manualmente ou com o 
apoio de ferramentas.
Esse processo de criação de software e de implantação para o 
usuário envolve diversos conceitos e detalhes e apresenta riscos de 
eventuais falhas, caso seja executado manualmente. Pensando nisso, 
o modelo SAMM definiu uma área chamada implementação, na qual se 
analisa a construção, a implantação e a gestão de defeitos, focando o 
tema segurança.
A maneira de saber se essas atividades estão sendo seguidas é por 
meio de perguntas respondidas pelo gestor de segurança da informa-
ção ou por um comitê, se não existir uma pessoa com esse papel. No 
quadro a seguir, você encontrará os seguintes questionamentos:
 • A construção do software (build) segue um processo? Caso sim, 
o processo é manual ou automatizado? Esse processo é voltado 
aos itens de segurança?
 • As bibliotecas utilizadas na construção do software são próprias 
ou de terceiros? Existe a gestão dessas dependências? Alguma 
biblioteca de terceiro está vulnerável?
 • A implantação do software (deployment) segue um processo? Se 
sim, ele é manual ou automatizado? Esse processo é voltado aos 
itens de segurança?
A modelagem de ameaças 
é uma das atividades da 
área de design. No vídeo 
Aplicação contínua de 
segurança: a importância 
da modelagem de amea-
ças, publicado pelo canal 
Roadsec, Rafael Lachi 
apresenta os motivos 
para a relevância dessa 
atividade. A palestra foi 
gravada justamente no 
Roadsec, um dos prin-
cipais encontros sobre 
atividades hackers. 
Disponível em: https://www.you-
tube.com/watch?v=l6SR5-VZCJM. 
Acesso em: 3 mar. 2022.
Vídeo
É possível obter a constru-
ção de software de modo 
seguro? Quais instrumen-
tos se deve usar? A ferra-
menta chamada Horusec, 
uma open source mantida 
pela Zup, é focada em 
análise de código-fonte 
e busca vulnerabilidades 
das dependências usadas. 
Para entender mais, assis-
ta ao vídeo Porque e como 
fazer desenvolvimento segu-
ro com Horusec, publicado 
pelo canal ZUP. 
Disponível em: https://www.
youtube.com/watch?v=ta9LoNDg_
lc. Acesso em: 3 mar. 2022.
Vídeo
https://www.youtube.com/watch?v=l6SR5-VZCJM
https://www.youtube.com/watch?v=l6SR5-VZCJM
https://www.youtube.com/watch?v=ta9LoNDg_lc
https://www.youtube.com/watch?v=ta9LoNDg_lc
https://www.youtube.com/watch?v=ta9LoNDg_lcModelos de maturidade para segurança da informação 95
 • Qualquer pessoa da organização pode acessar as credenciais de 
produção? Existe gestão para isso?
 • O trabalho de construção e implantação está baseado em métricas?
 • Quando um defeito de segurança é identificado, ele é devida-
mente tratado? 
Quadro 7
Avaliação do SAMM focada na área implementação
Implementação Situação atual
Atividade Nível Desenvolvimento seguro Resposta Nota
Processo de 
compilação 
(build) 
1
Seu processo de construção completo está 
formalmente mapeado e descrito?
0
0,00
2 O processo de construção é totalmente automatizado? 0
3
Você aplica verificações de segurança automatizadas 
em seus processos de compilação?
0
Gerenciamento 
de dependências 
1
Você tem um conhecimento sólido sobre as de-
pendências nas quais está confiando?
0
2
Você lida com o risco de dependência de terceiros por 
um processo formal?
0
3
Você impede a compilação de software se ele for afe-
tado por vulnerabilidades em dependências?
0
Atividade Nível Implantação segura Resposta Nota
Processo de 
implantação 
(deployment)
1 Você usa processos de implantação repetíveis? 0
0,00
2
Os processos de implantação são automatizados e 
empregam verificações de segurança?
0
3
Você valida consistentemente a integridade dos arte-
fatos implantados?
0
Gerenciamento 
de credenciais 
de software
1
Você limita o acesso às credenciais de acordo com o 
princípio de privilégio mínimo?
0
2
Você injeta credenciais de produção em arquivos de 
configuração durante a implantação?
0
3
Você possui um ciclo de gerenciamento de credenciais 
de produção e prática com frequência?
0
(Continua)
96 Segurança e auditoria de sistemas
Implementação Situação atual
Atividade Nível Gerenciamento de defeitos Resposta Nota
Rastreamento 
do defeito
1
Você possui maneiras para rastrear todos os defeitos 
de segurança conhecidos? Essas maneiras estão 
acessíveis?
0
0,00
2
Você mantém uma visão geral do estado dos defeitos 
de segurança para toda a organização?
0
3 Você aplica SLAs para corrigir defeitos de segurança? 0
Métricas e 
feedback
1
Você usa métricas básicas sobre defeitos de segu-
rança registrados para realizar atividades de melhoria 
de ganho rápido?
0
2
Você melhora seu programa de garantia de segurança 
com base em métricas padronizadas?
0
3
Você avalia regularmente a eficácia de suas métricas 
de segurança para impulsionar a estratégia de segu-
rança da organização?
0
Fonte: Adaptado de Coblentz; Keary; Deleersnyder, 2020.
A área de negócio implementação do framework SAMM envolve 
diversos fatores. As organizações que utilizam as práticas de DevOps 
costumam ter alta maturidade nessa área, pois o DevOps define um 
processo de desenvolvimento, sendo ele rastreável e automatizado. 
4.5 Áreas de negócio: verificação e operação 
Vídeo
A verificação é uma área de negócio do SAMM e nela são realizadas 
as verificações e a testagem das alterações no software. Essa checagem 
abrange as mudanças arquiteturais, as modificações em regras de ne-
gócio e as melhorias na segurança do produto. 
Na quadro a seguir você encontrará os seguintes questionamentos:
 • A arquitetura é verificada com frequência? Existe um processo 
efetivo de verificação?
 • Existem ameaças à arquitetura do software? Como elas são 
mitigadas?
 • As verificações de testes ocorrem? Elas são superficiais (seguem 
um processo básico) ou profundas (envolvem testes de abuso e 
uso indevido)?
 • As verificações são manuais ou automatizadas?
 • Qual é a sua baseline de qualidade de software? 
Modelos de maturidade para segurança da informação 97
Quadro 8
Avaliação do SAMM focada na área verificação
Verificação Situação atual
Atividade Nível Avaliação da arquitetura Resposta Nota
Validação da arqui-
tetura
1
Você revisa a arquitetura do software para 
garantir a aderência aos riscos já conhecidos?
0
0,00
2
Você revisa regularmente os mecanismos de 
segurança de sua arquitetura?
0
3
Você revisa regularmente a eficácia dos 
controles de segurança?
0
Mitigação da arqui-
tetura
1
Você revisa a arquitetura do software para mi-
tigar as ameaças já conhecidas?
0
2
Você avalia regularmente as ameaças à sua 
arquitetura?
0
3
Você atualiza regularmente suas arquitetu-
ras de referência, com base nas descobertas 
encontradas e implementadas durante o de-
senvolvimento de soluções?
0
Atividade Nível Testes orientados a requisitos Resposta Nota
Verificação de 
controle
1
Você testa os aplicativos para o funciona-
mento correto dos controles de segurança 
padrão?
0
0,00
2
Você escreve e executa consistentemente 
scripts de teste para verificar a funcionalidade 
dos requisitos de segurança?
0
3
Você testa os aplicativos automaticamente 
com regressões de segurança?
0
Testes de uso 
indevido/abusivo
1
Você testa aplicativos usando técnicas de 
randomização ou fuzzing?
0
2
Você cria cenários possíveis de abuso de 
software, por meio de requisitos funcionais, 
e os usa para conduzir testes de segurança?
0
3
Você executa testes de negação de serviço 
(DDoS) e testes de estresse de segurança?
0
(Continua)
98 Segurança e auditoria de sistemas
Verificação Situação atual
Atividade Nível Testes de segurança Resposta Nota
Baseline escalável
1
Você verifica aplicativos com ferramentas 
automatizadas de teste de segurança?
0
0,00
2
Você personaliza as ferramentas de segu-
rança automatizadas para seus aplicativos e 
para suas tecnologias utilizadas?
0
3
Você integra testes de segurança auto-
matizados no processo de compilação e 
implantação?
0
Compreensão pro-
funda
1
Você revisa manualmente a qualidade de se-
gurança de componentes de alto risco sele-
cionados?
0
2
Você realiza testes de penetração (pentest) 
para seus aplicativos em intervalos regulares?
0
3
Você usa os resultados dos testes de se-
gurança para melhorar o ciclo de vida do 
desenvolvimento?
0
Fonte: Adaptado de Coblentz; Keary; Deleersnyder, 2020.
O ciclo de desenvolvimento de software não se encerra na finalização 
dos testes. Colocá-lo em produção é uma etapa prevista e precisa-se de 
gestão para que ele permaneça disponível. Pensando na importância 
desse tema e no quanto é estratégico dispor de um software sempre 
pronto para uso, o SAMM criou uma área chamada operação, composta 
de três práticas de segurança: gerenciamento de incidentes, gestão do 
ambiente e gestão operacional.
Além da disponibilidade de um software, a operação abrange a ava-
liação de se um software está aderente à confidencialidade e integridade 
da informação. Esses três pontos formam o conceito CIA (do inglês 
confidentiality, integrity e avaliability) da segurança da informação. A che-
cagem desses itens garante que uma versão do software sempre esteja 
disponível e possa ser acessada por usuários. Uma alta nota de maturi-
dade nessa área de negócio evidencia que a empresa dificilmente terá 
problemas de interrupções em suas operações e, caso uma situação 
anormal aconteça, ela rapidamente conseguirá retomar essas operações.
Para identificar a maturidade nessa área de negócios, as perguntas 
apresentadas a seguir deverão ser respondidas pelo gestor de segu-
rança da informação ou por um comitê, se não existir uma pessoa com 
esse papel. Veja os questionamentos:
Ricardo Giorgi é referência 
em arquitetura de segu-
rança e no vídeo A impor-
tância de uma arquitetura 
de segurança, publicado 
pelo canal Clube de Arqui-
tetos, ele fala sobre como 
validar uma arquitetura 
para torná-la segura. 
Disponível em: https://youtu.be/
x50PNY2hDCo?t=398. Acesso em: 
4 mar. 2022.
Vídeo
A área de negócio ope-
ração analisa atividades 
referentes à detecção e às 
respostas aos incidentes 
de segurança. No vídeo 
Tratamento de incidentes 
de segurança na internet, 
produzido pelo canal 
NICbrvideos, há informa-
ções sobre esse tema. 
Disponível em: https://www.you-
tube.com/watch?v=flu6JPRHW04. 
Acesso em: 4 mar. 2022.
Vídeo
https://www.youtube.com/watch?v=x50PNY2hDCo&t=398s
https://www.youtube.com/watch?v=x50PNY2hDCo&t=398shttps://www.youtube.com/watch?v=flu6JPRHW04
https://www.youtube.com/watch?v=flu6JPRHW04
Modelos de maturidade para segurança da informação 99
 • À medida que o software é produzido, é provável que ele enfrente 
incidentes de segurança. Como isso é gerenciado?
 • Os servidores de produção têm acesso restrito tanto física quan-
to logicamente?
 • Os softwares e sistemas operacionais utilizados em produção 
dispõem de correções e atualizações instaladas?
 • Os dados de produção têm acesso restrito e políticas que ga-
rantam sua confidencialidade?
 • Existe a preocupação com softwares legados? Existe plano de 
descontinuidade desses softwares? 
Quadro 9
Avaliação do SAMM focada na área operação
Operação Situação atual
Atividade Nível Gerenciamento de incidentes Resposta Nota
Detecção de 
incidente
1
Você analisa dados de log para incidentes de segurança 
periodicamente?
0
0,00
2
Você segue um processo documentado para detecção de 
incidentes?
0
3
Você revisa e atualiza o processo de detecção de incidentes 
regularmente?
0
Resposta a inci-
dente
1 Você responde aos incidentes detectados? 0
2
Você usa um processo repetível para tratamento de 
incidentes?
0
3
Você tem uma equipe dedicada à resposta a incidentes 
disponível?
0
Atividade Nível Gerenciamento de ambiente Resposta Nota
Proteção da 
configuração
1
Você protege as configurações de ambientes e das tecnolo-
gias utilizadas com as informações do dia a dia?
0
0,00
2
Você tem baselines rígidas que realizam a proteção da 
configuração do software?
0
3
Você monitora e reforça a conformidade com as baselines 
de proteção da configuração?
0
Correções e 
atualizações
1 Você identifica e corrige componentes vulneráveis? 0
2
Você segue um processo estabelecido para atualizar 
componentes dos ambientes?
0
3
Você avalia regularmente os componentes utilizados e revi-
sa o status das suas atualizações?
0
(Continua)
100 Segurança e auditoria de sistemas
Operação Situação atual
Atividade Nível Gestão operacional Resposta Nota
Proteção a dados
1
Você protege e trata as informações de acordo com os re-
quisitos de proteção dos dados armazenados e processa-
dos em cada aplicativo?
0
0,00
2
Você mantém um catálogo de dados, incluindo tipos, 
níveis de sensibilidade e locais de processamento e 
armazenamento?
0
3
Você revisa e atualiza regularmente o catálogo de dados e 
as suas políticas e os procedimentos de proteção de dados?
0
Gerenciamento 
de legados
1
Você identifica e remove sistemas, aplicativos, dependências 
de aplicativos ou serviços que não são mais usados, que 
chegaram ao fim da vida útil ou que não são mais de-
senvolvidos ou suportados ativamente?
0
2
Você segue um processo estabelecido para remover todos 
os recursos associados, como parte do descomissiona-
mento de sistemas, aplicativos, dependências de aplicativos 
ou serviços não utilizados?
0
3
Você avalia regularmente o estado do ciclo de vida e o 
status de suporte de cada ativo de software e componente 
de infraestrutura subjacente e estima seu fim de vida?
0
Fonte: Adaptado de Coblentz; Keary; Deleersnyder, 2020.
As áreas de negócio verificação e operação do framework SAMM ga-
rantem a confidencialidade, disponibilidade e integridade dos softwa-
res e dos respectivos dados utilizados por ele.
Importante ressaltar que essa área foi a última apresentada devido 
a uma questão de organização, e não porque é menos importante no 
SAMM. Lembre-se de que a empresa deve investir esforços para ele-
var a maturidade das áreas de negócios mais frágeis e, se essa for a 
situação da operação, o gestor de segurança da informação deve prio-
rizar dinheiro e tempo nesse tema.
CONSIDERAÇÕES FINAIS
O framework SAMM está em constante mudança e, a cada ano que 
passa, mais empresas o adotam como ferramenta oficial para implantar 
SSDLC ou, então, para obter a certificação ISO 27001. Por isso, entendê-lo 
e aplicá-lo faz de você um profissional diferenciado e preparado para os 
desafios atuais da área de TI. Mas fique atento, pois anualmente existem 
Modelos de maturidade para segurança da informação 101
atualizações do framework, trazendo sempre novas maneiras de gerenciar 
a segurança da informação e de mitigar riscos organizacionais na produ-
ção de software.
ATIVIDADES
Atividade 1
Todo SSDLC contém atividades de segurança no ciclo de de-
senvolvimento de software? Explique.
Atividade 2
É correto afirmar que a área de negócio design é composta so-
mente de analistas de sistemas? Justifique sua resposta.
Atividade 3
Quando um incidente de segurança ocorre e um grupo dedicado 
ao tema é acionado, podemos afirmar que a organização está em 
que nível de maturidade?
REFERÊNCIAS
COBLENTZ, N.; KEARY, E.; DELEERSNYDER, S. Interview: SAMM Assessment 
Interview. Owasp, 2020. Disponível em https://github.com/OWASP/samm/raw/
c58b69e79f47db17c3ca8b51895903cf3291e03f/Supporting%20Resources/v2.0/toolbox/
SAMM_Assessment_Toolbox_v2.0.xlsx. Acesso em: 3 mar. 2022.
DELEERSNYDER, S.; WIN, B. de.; GLAS, B. Software assurance maturity model: quick start 
guide. Owasp, 2017. Disponível em: https://github.com/OWASP/samm/raw/master/
Supporting%20Resources/v1.5/Final/SAMM_Quick_Start_V1-5_FINAL.pdf. Acesso em: 
3 mar. 2022. fev. 2022.
FERREIRA, D. A. T. G. Arquitetura segura no desenvolvimento de software: abordagem à 
plataforma digital U.OPENLAB. 2019. Dissertação (Mestrado em Segurança Informática) 
– Faculdade de Ciências, Universidade do Porto, Porto. Disponível em: https://repositorio-
aberto.up.pt/bitstream/10216/125656/2/378510.pdf. Acesso em: 3 mar. 2022.
WHAT is OWASP SAMM? Samm, 2020. Disponível em: https://owaspsamm.org/about/. 
Acesso em: 3 mar. 2022.
Resolução das atividades
1 Auditoria de sistemas da informação
1. O processo de auditoria pode ser realizado de diversas maneiras 
e cada abordagem tem um nome. Diferencie as abordagens de 
auditoria de segunda parte e de terceira parte.
O processo de auditoria de segunda parte é realizado por uma 
empresa terceirizada e especialista no assunto. Esse tipo de serviço 
é requisitado quando é preciso comprovar a integridade do serviço 
ofertado. Já o processo de auditoria de terceira parte é feito por 
uma empresa terceirizada, que tem o poder de certificar os serviços 
prestados pela empresa com base em órgãos oficiais, como a ISO. 
A grande diferença entre ambos é que a auditoria de terceira parte 
emite um certificado com validade mundial, segundo as normas e as 
boas práticas reconhecidas mundialmente. 
2. Ao realizar uma auditoria, o auditor deve utilizar mais de uma 
técnica. Explique o porquê.
Quando o auditor utiliza somente uma técnica no processo de 
auditoria, o trabalho se torna improdutivo e com aumento dos custos 
operacionais, pois serão necessárias mais horas de trabalho. Além 
disso, ao aplicar uma única técnica, alguns pontos importantes podem 
ser esquecidos, comprometendo a qualidade do relatório final.
3. Você é um auditor e percebeu que a equipe de contingência está 
utilizando e-mails para a comunicação. Você considera essa prática 
aderente ao plano de contingência da organização? Justifique a 
sua resposta.
Ao realizar a auditoria do plano de contingência, devemos sinalizar 
como “não conforme” o item comunicação da equipe de contingência, 
pois o e-mail não é uma ferramenta de comunicação eficaz, 
especialmente por não ser ágil na troca de mensagens. O e-mail 
permite o envio de documentos, imagens, vídeos e áudios, mas 
somente como anexo. A sugestão mais efetiva para essa equipe é 
utilizar algum aplicativo de mensagem instantânea, em que as opções 
de texto, vídeo e áudio estão a poucos cliques do usuário.
102 Segurança e auditoria de sistemas
2 Execução de auditorias
1. Quais são os benefícios para uma empresa ao possuir controles 
organizacionais bem definidos e que podem ser auditados? 
Justifique.
As empresas que possuem controles organizacionais bem definidos 
apresentam baixo risco de fraudes em seus processos, redução 
de perdas financeiras eminimização do turnover (desligamento de 
colaboradores).
2. Um auditor precisa analisar o processo de aquisição de um 
software. Quais pontos devem ser auditados?
O processo de auditoria para aquisição deve observar se mais de um 
orçamento foi analisado, se houve análise de custo-benefício e se os 
critérios para manutenção, atualização e uso de novas versões desse 
software estão definidos e acordados em contrato.
3. Você é um auditor e percebeu que a empresa não tem uma 
política de troca de senhas recorrente, tampouco utiliza critérios 
de complexidade para elas. Em qual tipo de auditoria costuma ser 
identificado esse problema?
Esse problema costuma ser identificado na auditoria de controles de 
acesso, por meio da análise de políticas de segurança para o acesso.
3 Segurança de sistemas da informação
1. Um hacker conseguiu acessar um servidor e alterou as páginas web 
que estavam hospedadas nele. Quais princípios do modelo CIA 
foram violados nesse ataque?
Com esse ataque, o hacker violou os princípios de disponibilidade e 
integridade da informação, pois ele mudou o conteúdo do site. Não 
foi violado o princípio da confidencialidade, pois não houve acesso a 
dados sensíveis, como a base de dados.
2. Diferencie uma ameaça ativa de uma ameaça passiva.
Uma ameaça ativa é aquela que o atacante realiza modificações de 
informações. Já na ameaça passiva, o atacante tem acesso a todas as 
informações, mas não altera nenhuma delas.
Resolução das atividades 103
3. Uma empresa de software contratou uma empresa que fornece 
ambientes na nuvem (cloud). Qual é a norma da família ISO 27000 
que cuida desse tema?
A norma que cuida do relatório com fornecedores, incluindo aspectos 
de gestão da computação na nuvem, é a ISO 27036:2013+.
4 Modelos de maturidade para segurança da informação
1. Todo SSDLC contém atividades de segurança no ciclo de 
desenvolvimento de software? Explique.
Sim. SSDLC é a sigla para security software development life cycle, ou seja, 
ciclo de desenvolvimento seguro de software. Toda implementação 
baseada em SSDLC trabalha com segurança. Podemos citar o 
framework SAMM e o modelo MSSDL como exemplos de SSDLC. 
Quando só há SDLC, não há atividades de segurança previstas.
2. É correto afirmar que a área de negócio design é composta somente 
de analistas de sistemas? Justifique sua resposta.
Não, está incorreto. Na área de design, há os analistas de sistemas e 
os arquitetos, tanto que existem atividades específicas de arquitetura, 
denominadas de design de arquitetura.
3. Quando um incidente de segurança ocorre e um grupo dedicado 
ao tema é acionado, podemos afirmar que a organização está em 
que nível de maturidade?
A organização estará no nível de maturidade 3, para a atividade de 
resposta a incidentes da prática de segurança de gerenciamento a 
incidentes, na área de negócio operações.
104 Segurança e auditoria de sistemas
ISBN 978-65-5821-129-7
9 786558 211297
Código Logístico
I000600
	Página em branco
	Página em branco