Livro-texto - Unidade IV

Prévia do material em texto

133
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
Unidade IV
7 AUDITANDO SISTEMAS OPERACIONAIS E APLICATIVOS
Em auditoria, é vital a correta manutenção e o gerenciamento dos logs. Em muitas situações, as 
causas de determinados eventos, fraudes ou falhas podem ser elucidadas a partir da análise desses 
registros. Este tópico irá abordar a análise de logs a partir de uma ótica mais técnica, validada pela 
norma ABNT NBR ISO IEC 27002 (ABNT, 2013b). Também será discutido o gerenciamento de logs dos 
controles de segurança.
As particularidades da auditoria serão detalhadas em duas áreas proeminentes da administração 
tecnológica: a gestão de mudanças e a gestão de liberações.
7.1 Gerenciando logs de sistemas
É muito importante o armazenamento dos registros de atividades dos usuários e colaboradores 
externos por um determinado tempo. De acordo com a norma ABNT NBR ISO/IEC 27002 (ABNT, 2013b), 
entre os dados mais importantes que devem ser registrados, estão:
• A identificação precisa das atividades do sistema, como datas, horários, logins, logoffs, eventos 
chave, entre outros.
• A identificação dos usuários.
• A identificação e localização dos dispositivos ou terminais utilizados.
• A quantidade de sucessos ou falhas nos logins.
• A quantidade de sucessos ou falhas nas tentativas de acesso a outros recursos.
• As alterações nos sistemas.
• Quais são os privilégios em uso.
• Quais são os serviços sendo utilizados.
• Quais e quantos são os alertas e as notificações emitidas pelo sistema.
• A identificação precisa das ativações e desativações dos controles de segurança.
134
Unidade IV
• Quais foram as transações executadas nas aplicações pelos usuários.
• Quais foram os arquivos e diretórios acessados.
• Quais foram os endereços e atributos de rede utilizados.
Quando reunidos, os dados que compõem os registros devem prover dados pertinentes sobre o 
sistema – essa é a base para a escolha dessas informações. Contudo, é preciso atentar-se a dados críticos 
e confidenciais que requerem cuidados. Mesmo informações pessoais dos usuários, como trechos de 
mensagens, podem estar contidas nos logs, também chamados de registros ou trilhas de auditoria.
A integridade dos registros é um dos atributos mais importantes. Ataques e invasões podem passar 
despercebidos se um atacante apagar ou alterar os logs de um sistema. Verificações periódicas em 
trilhas de auditoria são imprescindíveis. Uma sugestão válida é o uso de gerenciadores de logs que 
permitem a criação de hashes para garantir a integridade. Outra solução é assegurar que as trilhas de 
auditoria geradas tenham atributos de “apenas leitura” para impedir alterações indevidas.
 Observação
Após um ataque de intrusão computacional, um atacante experiente 
procura apagar seus rastros (logs) para não ser detectado. Há programas 
específicos para esse fim.
A recomendação é que exista um espaço de armazenamento adequado, suficiente e centralizado 
para o armazenamento do histórico de logs. Ainda assim, é bastante comum que a gravação contínua 
de logs chegue a um limite predeterminado e seja interrompida ou regravada sobre os registros mais 
antigos. Nesses casos, o ideal é que seja criada de antemão uma política para backup e armazenamento 
dos logs em mídias externas. Existem ataques que geram propositalmente muitos logs a fim de estourar 
a capacidade de armazenamento dos registros e, depois, passar despercebidos em auditorias futuras.
7.2 Analisando logs de acesso indevido
A análise das trilhas de auditoria pode determinar a existência de tentativas (fracassadas ou não) 
de acesso indevido aos sistemas. Em geral, a análise de logs é uma tarefa complexa; sendo assim, 
buscar evidências sobre uma invasão é igualmente complicado. Um determinado registro pode ser uma 
consequência direta de diversos eventos e pode, por sua vez, gerar múltiplas consequências.
Além dessas particularidades, que dificultam o gerenciamento dos logs, uma análise pode 
simplesmente induzir um administrador ao erro. Especificamente no caso de logs relacionados à 
tentativa de invasão ou a eventos de segurança, em vez de simplesmente utilizar os registros do sistema, 
um administrador pode se servir das trilhas de registros dos controles de segurança.
135
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
 Lembrete
Controles de segurança são ferramentas físicas ou lógicas para proteção 
dos ativos. Podem ser usados para prevenção, detecção ou recuperação de 
ativos, sendo os de detecção os mais comuns.
Os controles de segurança são essenciais para que os sistemas e equipamentos consigam realizar 
suas funcionalidades de forma protegida e segura. Por serem elementos que buscam justamente a 
identificação de padrões anômalos, são ferramentas que podem ser extremamente úteis para a auditoria, 
já que registram eventos que ocorrem nos equipamentos e sistemas em tempo real.
Um dos problemas da análise de logs de controles de segurança é que os resultados podem não ser 
tão precisos – é difícil, mesmo para um controle de segurança bem configurado, detectar com precisão 
quando ocorre uma invasão. A partir da real natureza de uma ação e com a detecção dessa mesma ação, 
um registro pode ser classificado em Verdadeiro Positivo (VP), Falso Positivo (FP), Falso Negativo (FN) e 
Verdadeiro Negativo (VN), como mostra o quadro a seguir.
Quadro 13 – Classificação dos logs a partir da precisão da detecção
Ação
Positivo
Detectada pelo controle?
Negativo
Ameaça real?
Verdadeiro Verdadeiro Positivo (VP) Verdadeiro Negativo (VN)
Falso Falso Positivo (FP) Falso Negativo (FN)
Como pode ser visto no quadro anterior, a classificação a partir da precisão possui uma nomenclatura 
que se inicia com a definição de se a ameaça é real (Verdadeiro ou Falso) seguida da definição de se 
essa ameaça é detectada pelo controle de segurança (Positivo ou Negativo).
Um log que aponta um registro Verdadeiro Positivo (VP) indica que uma ameaça era real e foi 
detectada pelo controle de segurança. Em outras palavras, o controle cumpriu sua função de proteger 
ou mesmo registrar a ameaça. Um log Falso Negativo (FN) é aquele que o controle de segurança não 
registrou como ameaça, sendo que realmente não se trata de uma ameaça real. Ambos os registros 
VP e FN estão marcados em verde no quadro anterior justamente porque não significam perigo.
Um registro Falso Positivo (FP) diz respeito a um evento que não representa risco, mas está 
classificado como um problema (intrusão) real. Por exemplo: na figura a seguir, um pacote legítimo 
é bloqueado (ou registrado) como malicioso de forma errada. Não há maiores prejuízos em relação 
à segurança, já que o pacote não era uma ameaça e, mesmo assim, foi bloqueado. Contudo, há ônus 
para os administradores que precisam analisar logs sem necessidade e lidar com falsos alertas. Como 
incrementam a quantidade de informação, os logs FP podem levar a análise para uma direção errada, 
diminuindo a confiabilidade do controle de segurança. Além disso, se o pacote legítimo bloqueado era 
importante, pode fazer falta à vítima; por isso, está marcado em amarelo no quadro anterior.
136
Unidade IV
Falso positivo (FP)
Pacote legítimo bloqueado
Verdadeiro negativo (VN)
Pacote malicioso liberado
Atacante
Site legítimo
Vítima
Controle de 
segurança
Figura 79 – Esquema com bloqueio (ou registro) de pacotes FP e VN
Já um registro Verdadeiro Negativo (VN) ocorre quando o controle de segurança não detecta 
uma atividade maliciosa real e permite que ela cause danos. Trata-se do pior caso; afinal, o controle de 
segurança não cumpriu sua função. É o caso do exemplo ilustrado na figura anterior, em que um pacote 
malicioso consegue passar pelo controle de segurança e chegar até a vítima. Por esse motivo, o VN está 
em vermelho no quadro “Classificação dos logs a partir da precisão da detecção”.
7.3 Correlacionando logs
Dados ou eventos relacionados a um comportamento anômalo geralmente podem estar fora de ordem 
ou ter várias origens, dificultando a análise.Por exemplo: uma invasão de sistema pode deixar rastros 
em uma série de lugares, como computadores, sistemas, aplicativos ou equipamentos de comunicação. 
O ideal é que uma análise consiga estabelecer relações entre registros de fontes diferentes, como controles 
de segurança versus sistema operacional versus rede. Em geral, esse tipo de correlacionamento pode 
gerar mais informações sobre os acontecimentos ou dados investigados.
O mapeamento entre logs de diferentes fontes, como controles de segurança, equipamentos de rede e 
sistemas operacionais, é chamado de multicorrelacionamento. Geralmente, correlacionamentos desse tipo 
têm por base o timestamp das trilhas de auditoria – deve haver sincronia de horários. A grande vantagem é 
a identificação de evidências e eventos que podem passar despercebidos durante a análise de apenas uma 
fonte de logs. Contudo, a técnica tem como dificuldade as diferenças de conteúdo e de formato nos dados.
 Lembrete
Um evento é qualquer ação executada em sistemas ou equipamentos. 
Em geral, eventos deixam marcas que podem ser registradas nos logs. Um 
ataque computacional pode ser considerado um evento malicioso.
137
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
 Observação
O timestamp de um evento corresponde à data e hora exatas de um 
evento. Em geral, isso está presente nos logs.
Por incrível que pareça, sincronizar dois ou mais computadores pelo timestamp pode ser bastante 
complicado. O Network Time Protocol (NTP) é um protocolo muito usado para atualização de horários 
em sistemas operacionais a partir de servidores na internet. Vários administradores utilizam o NTP 
para sincronização de timestamps entre equipamentos e sistemas usados na multicorrelação. Além 
da verificação da periodicidade das atualizações do NTP, os administradores devem ter ciência de que 
diferenças mínimas entre máquinas sempre existirão.
Há duas técnicas de multicorrelacionamento: análise descendente e análise ascendente.
Na técnica descendente, analisa-se o comportamento de um ataque conhecido e verifica-se em outros 
logs (sistema operacional, por exemplo) onde há traços de sua atuação com base no timestamp. A técnica é 
útil para o rastreamento das estratégias do evento, mapeando o caminho realizado pelo ataque até sua fonte.
Na técnica ascendente, quando uma anomalia é detectada no log de um equipamento ou sistema, 
os outros registros são checados com base no timestamp. A técnica ascendente procura descobrir eventos 
maliciosos diretamente da análise de diversos logs. Apesar de mais custosa computacionalmente, essa 
técnica permite a detecção de ataques novos.
Uma técnica voltada para a auditoria e que sempre pode ser útil para o levantamento de evidências 
é tentar traçar uma linha de eventos que levaram a um ataque. Parte-se do princípio de que a maioria 
dos ataques não é um evento isolado, mas o resultado de uma série de ataques prévios e preparações. 
Por exemplo: um ataque DoS contra um servidor é precedido de uma varredura para reconhecimento 
da rede e de conexões prévias que testam as defesas do servidor. Em resumo, acontecimentos anteriores 
podem explicar muito sobre os ataques executados em uma rede e, consequentemente, podem também 
ser fonte de evidências aos profissionais forenses em uma investigação.
Dada a quantidade de dados disponíveis para coleta, apresentaremos no quadro a seguir um checklist 
com algumas informações coletadas de controles de segurança que podem realmente ser relevantes ou 
passíveis de correlação.
Quadro 14 – Informações relevantes que podem ser coletadas 
dos controles de segurança em uma rede ou um sistema
Medidas relevantes Descrição
Timestamp Data, horário, fuso, intervalo etc.
Usuário ID, login, informações do usuário etc.
Natureza do ataque Intrusão, vazamento de dados, indisponibilidade, acesso não autorizado, uso não autorizado etc.
Forma de contenção Prevenção, detecção ou recuperação
138
Unidade IV
Medidas relevantes Descrição
Recursos afetados Servidor, rede, arquivos etc.
Logs Sistema operacional, controles de segurança, aplicativos etc.
Forma de identificação do ataque Manual ou automática
Validação Forma de validação
Preservação Dados preservados, dados comprometidos, dados em falta etc.
Dados do ataque Tempo de ataque, limpeza de rastros, categoria etc.
Estatísticas Números do ataque, estatísticas, contagens etc.
Taxa de erros Dos controles de segurança, dos aplicativos, do tráfego de rede, percentual de alertas FP e VN etc.
Comunicação Forma de comunicação usada no ataque ou na defesa, efeitos colaterais na rede etc.
Informações de rede Nomes de domínio, IP, máscara de rede, procedência, endereços físicos etc.
Serviços Serviços executados e/ou afetados na rede (DNS, DHCP, e-mail etc.), versão de aplicativos etc.
Malwares Ameaças e vulnerabilidades detectadas
Atualizações Timestamp das atualizações, descrição das atualizações etc.
Controles de segurança Lista de controles de segurança, backups realizados etc.
Garantias físicas Local dos ativos, acesso físico aos ativos afetados etc.
 Observação
Há controles de segurança que complementam outras ferramentas 
organizando logs e realizando multicorrelacionamentos, como o Acid 
e o Netdetector.
Um dos problemas da multicorrelação é que seus resultados dependem, em grande parte, da 
qualidade dos alertas detectados. Portanto, o nível de precisão dos controles de segurança é um fator 
preponderante para que ocorram correlações válidas e, como consequência, um melhor entendimento 
dos ataques. Falhas na detecção ou altos índices na emissão de FP podem comprometer toda a análise.
A integração e o gerenciamento de logs de diversas fontes, seja para fins de multicorrelacionamento 
ou não, podem ser bastante complexos. Existem aplicativos que dependem ou precisam ler registros de 
sistemas e equipamentos diferentes para executar suas funções. Nesses casos, muitas vezes, é necessária 
a integração das trilhas de auditoria.
A rede social de viés corporativo LinkedIn passou por um processo desse tipo, relatado no artigo de 
Kreps (2014), que define log como um arquivo ou uma tabela que possui dados ordenados no tempo.
Como pode ser visto na figura a seguir, o principal problema do LinkedIn era a complexidade para 
gerenciar e integrar logs de fontes, formatos e procedências diferentes lidos por diversas aplicações.
139
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
Hadoop Buscas em 
logs
Banco de 
dados
Dados de 
rastreamento
Logs do sistema 
operacional Métricas
Operações internas
Data 
warehouse
Redes 
sociais
Motor de 
recursão
Buscas Segurança E-mailMonitoramento
Figura 80 – Logs descentralizados
Como observado na figura anterior, para cada integração, era preciso a construção de pelo menos 
dois fluxos que atendiam os aplicativos, um de entrada e outro de saída.
A solução foi a criação de um log unificado que pudesse ser acessado por todos os sistemas.
Hadoop Buscas em 
logs
Banco de 
dados
Dados de 
rastreamento
Logs do sistema 
operacional Métricas
Log unificado
Operações internas
Data 
warehouse
Redes 
sociais
Motor de 
recursão
Buscas SegurançaMonitoramento E-mail
Figura 81 – Log unificado
140
Unidade IV
Com a solução, os sistemas já não se comunicavam entre si para leitura e análise das trilhas de 
auditoria, mas gravavam esses registros em um banco de logs. A ideia é coerente, pois costuma ser mais 
fácil tratar a escalabilidade de arquivos de logs do que realizar esse tipo de operação em uma estrutura 
de dados mais complexa.
Entre as vantagens do esquema, estão a baixa latência para leitura e gravação de registros, a 
possibilidade de leitura simultânea de logs, o funcionamento individual dos aplicativos e o fato de o log 
unificado estar no centro da cadeia de processamento e fluxo de dados, facilitando a tomada de decisões.
Os cuidados com a segurança continuam importantes. O esquema ainda depende, por exemplo, de 
uma boa estrutura de armazenamento e backup do log unificado.
7.4 Auditandoa computação forense
Este tópico irá apresentar um processo de auditoria bastante específico, aquele voltado para a 
computação forense. Trata-se de um ramo da ciência investigativa voltado para a descoberta, identificação 
e elucidação de delitos a partir da investigação de evidências colhidas em meios tecnológicos/digitais.
Além da parte técnica, o tópico irá mostrar conceitos relacionados aos aspectos legais, como os 
requisitos necessários para a obtenção e o uso das evidências.
Tendo em vista que a análise forense muitas vezes envolve a condenação ou absolvição de um réu, 
trata-se de um ambiente em que a necessidade de processos de auditoria bem realizados é imprescindível.
7.4.1 Introdução à computação forense
A computação forense, também conhecida por análise forense ou forense computacional, é um 
ramo da criminalística voltado para a análise e o estudo de evidências cibernéticas, seus aspectos e 
consequências, preservando, dentro do possível, tanto os vestígios levantados quanto o objeto de estudo 
para fins de reprodutibilidade. Abrange a investigação computacional realizada em hardware e software 
com base no levantamento de evidências cibernéticas que ajudem na solução de crimes ou auditorias.
A razão de existir da computação forense é a própria evolução da tecnologia e, consequentemente, 
a necessidade de acompanhamento dessa evolução por parte da investigação.
Como está incluída em uma área multidisciplinar, a computação forense tem como guia principal 
a legislação constitucional brasileira. Adicionalmente, também se espelha em normas técnicas e 
regulamentações infraconstitucionais, como o Procedimento Operacional Padrão (POP), regido pelo 
SENASP/MJ, e a norma ABNT NBR ISO IEC 27037 (ABNT, 2013c). Espera-se que o profissional forense siga 
as recomendações exigidas nas normas, já que representam as melhores práticas testadas e homologadas 
sobre o assunto de estudo.
141
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
Os crimes cibernéticos podem ser enquadrados como delitos que utilizam computadores, redes 
ou outro hardware qualquer. Esses delitos têm aumentado principalmente devido à facilidade e 
disseminação tecnológica.
Seja como meio, seja como fim, a simples utilização de recursos computacionais para a execução 
de crimes digitais (ou, ainda, outra atividade qualquer) produz evidências (vestígios) cibernéticas 
físicas ou lógicas.
As evidências são informações geradas pela utilização de um sistema que podem servir para a 
apuração de fatos e o rastreamento de atividades, incluindo os elementos físicos usados para armazenar, 
transmitir ou dar algum tipo de suporte a essa atividade. Portanto, o tratamento e a análise das evidências 
geradas podem identificar os indivíduos que cometeram crimes digitais. Para isso, a atividade forense 
conta com cinco etapas primordiais:
• Identificação: a correta identificação da relação entre os contextos físico e lógico é importante 
para a identificação das evidências. É preciso conhecer bem o que se pretende investigar para que a 
identificação não seja baseada em dados escassos ou não seja saturada com evidências irrelevantes.
• Isolamento: a ideia de isolar as evidências é devido à necessidade de garantir a integridade 
dos vestígios – evitar alterações, inserções, destruições e limitações. Muitas vezes, esta etapa é 
executada em conjunto com a identificação.
• Registro: antes de coletar as evidências identificadas e isoladas, o ideal é registrá-las. É uma 
forma de resguardar a segurança das evidências, uma espécie de backup. Esta etapa é primordial 
para a execução de uma auditoria.
• Coleta: corresponde à extração das evidências identificadas, isoladas e registradas em um cenário 
de crime. Historicamente, essa prática é muito mais relacionada ao contexto físico; por isso, 
recomenda-se cuidado no manuseio de equipamentos e dispositivos sensíveis na cena do crime.
• Preservação: procura garantir que os dados ou objetos coletados estejam seguros e íntegros. Para 
equipamentos e dispositivos, envolve os cuidados com acondicionamento, transporte e manuseio. 
Para dados lógicos, recomenda-se a criação de backups. A preservação também busca garantir 
a integridade, com a criação de hashes e assinaturas digitais para que os dados se mantenham 
autênticos e íntegros. A aplicação de criptografia para garantir a confidencialidade também é 
bastante recomendável.
O trabalho de um perito de computação forense está relacionado à investigação de crimes 
cibernéticos. Portanto, a busca por evidências se estende para os âmbitos físicos e lógicos.
Na parte física, o perito deve lidar com equipamentos, mídias móveis de armazenamento (HD, pen 
drives, DVD, memórias), sensores, chips, cartões, placas e objetos que possam conter ou gerar evidências. 
Em relação à parte lógica, o perito deve analisar arquivos ocultos ou apagados, conteúdo encriptado, 
dados formatados ou escondidos, procurar mensagens não disponíveis, rastrear ligações e mensagens 
142
Unidade IV
trocadas e investigar eventos ocorridos em redes ou sistemas que possam conter vestígios valiosos 
para a investigação.
Nesse tipo de cenário, a auditoria dos processos, das metodologias, das técnicas e até do conteúdo 
recolhido é extremamente importante para a garantia da lisura do processo. O motivo da importância 
da auditoria é que, no ambiente forense, procura-se identificar os autores e as circunstâncias de 
um crime. Logo, a precisão na determinação de autores e fatos não deve ser descartada, já que pode 
implicar condenações injustas. É muito importante que as evidências e os fatos investigados sejam 
precisos e sirvam de prova definitiva para a elucidação dos delitos – daí a importância da auditoria em 
todo esse processo.
Provas são meios diretos ou indiretos para estabelecer a veracidade de um fato ou uma circunstância. 
Busca-se saber se a verdade relacionada com determinada prova existe. Dentro de um processo, isso 
acaba por consolidar e dar veracidade a uma série de fatos.
7.4.2 Auditoria dos métodos forenses
Um ponto importante que deve ser levado em conta durante uma investigação computacional forense 
é a reprodutibilidade. Como se trata de uma investigação que busca identificar autores e circunstâncias 
para uma eventual punição, os métodos usados devem ser precisos e estar em conformidade. É essencial 
que estejam dentro da legalidade jurídica e que sejam tecnicamente reproduzíveis, para que os métodos 
empregados na perícia não sejam alvo de processos e contestações.
O Código de Processo Civil (CPC) brasileiro, lei n. 13.105 (BRASIL, 2015), contém regras que regem 
as ações de um perito forense – art. 156 a 159 do CPC. A prova pericial está prevista nos art. 464 a 
480 do CPC. A Lei traz quatro efeitos práticos: simplificação da produção da prova técnica; requisito de 
apresentação de currículo do perito; perícia consensual; e requisitos do laudo oficial. Todos podem ser 
aplicados no processo de acordo com a necessidade. A perícia forense é um trabalho muito técnico e 
deve funcionar como um auxiliar do juiz na busca pela verdade.
 Saiba mais
Mais detalhes sobre o CPC podem ser encontrados em:
BRASIL. Lei n. 13.105, de 16 de março de 2015. Código de Processo 
Civil. Brasília, 2015. Disponível em: http://www.planalto.gov.br/ccivil_03/_
ato2015-2018/2015/lei/l13105.htm. Acesso em: 28 jul. 2020.
Uma das maiores controvérsias a respeito desse tema são os limites legais de uma investigação. 
Como no Brasil a intimidade e a vida das pessoas (brasileiros e estrangeiros) são direitos fundamentais 
garantidos pela Constituição Federal (BRASIL, 1988) e pelo Código Civil (BRASIL, 2002), o profissional 
forense sempre deve estar a par dos limites da privacidade e segurança coletiva.
143
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
O quadro a seguir mostra em quais leis estão descritos os principais indicadores de legitimidade para 
ações de investigação.
Quadro 15 – Leis que legitimam uma investigação
Lei Descrição
Art. 25 – Código PenalLegítima defesa
Art. 5°, inc. IV – Constituição Federal 1988 Vedação ao anonimato
Lei n. 12.965/2014 – Marco Civil da Internet Dever de guarda de provas
Decreto n. 8135/2013 Segurança nacional das informações e comunicações
Lei n. 12.846/2013 Combate à corrupção
Lei 105 MF, Art. 153, 154 – Código Penal Proteção de sigilo profissional
Instrução Comissão de Valores Imobiliários (CVM) 358 Proteção de fato relevante
Lei n. 12.850/2013 Direito de acesso às provas
Lei n. 12.735/2012 – Código Penal Combate ao crime de invasão informático
Lei n. 12.737/2012, Art. 154-A – Código Penal Combate ao crime de invasão informático
Decreto n. 7.845/2012 Tratamento de informação classificada
Lei n. 9.610/1998 Proteção de propriedade intelectual
Lei n. 9.609/1998 Proteção de código-fonte
Lei n. 9.279/1996 Proteção de marca e combate à concorrência desleal
ECA Art. 241 – A e B Combate à pornografia infantil
CPC Art. 932 Responsabilidade civil do empregador
Código Civil Art. 186, 187 e 927 Responsabilidade civil de terceiro
Adaptado de: Velho et al. (2016).
Durante a coleta de provas, deve-se sempre analisar se ela é lícita e legítima, sendo na esfera 
criminal ou não. Nesse contexto, a auditoria sobre os métodos que foram utilizados é essencial. Os 
peritos forenses devem documentar a metodologia usada para identificação, isolamento, registro, coleta 
e preservação de toda a investigação e levantamento de provas.
Auditorias e verificações documentais anteriores a eventuais processos de busca e apreensão são 
imprescindíveis, pois podem garantir que limites não sejam ultrapassados. Mesmo que não haja ordem 
judicial para a análise de um ambiente, o profissional de segurança pública sempre terá o direito especial, 
inerente a seu cargo, da preservação de provas até que a ordem judicial seja expedida. Isso garante a 
conservação de estado e memória dos dados, evitando perdas ou alterações. Contudo, o ideal é que 
a existência de mandatos, processos, autorizações de apreensão e outros elementos seja devidamente 
checada antes de uma ação mais enérgica dos peritos.
144
Unidade IV
 Observação
Uma auditoria sobre a conformidade de uma investigação deve levar 
em conta e documentar eventuais colaborações por parte dos investigados.
Toda a apresentação voluntária de aparelhos pela própria vítima ou pelo 
familiar deve constar nos autos ou na investigação como ato de exibição e 
autorização de acesso ao conteúdo do dispositivo, independentemente 
de autorização judicial. Nesses casos, a autorização expressa é inequívoca e 
exclui a necessidade de autorização judicial.
7.4.3 Auditoria do conteúdo forense
De certa forma, a exigência de reprodutibilidade dos métodos também se aplica ao conteúdo 
coletado do ambiente de investigação forense.
O POP, como vimos, tem por objetivo padronizar o trabalho, minimizando os riscos da execução das 
análises forenses e evitando falhas e erros do processo.
Publicado pelo Ministério da Justiça, um POP de destaque no Brasil é o “Procedimento Operacional 
Padrão: Perícia Criminal”. Esse documento traz alguns padrões sobre as perícias criminais:
• Exame pericial de mídia de armazenamento computacional: orienta o profissional de perícia 
forense na realização de exames em mídias de armazenamento, como discos rígidos, pen drives, 
cartões de memória, entre outros.
• Exame pericial de equipamento computacional portátil e de telefonia móvel: contém 
orientações sobre o tratamento que deve ser dado em exames executados em dispositivos 
portáteis, como notebooks, smartphones, tablets e dispositivos com sensores.
• Exame pericial de local de informática: orienta os profissionais sobre análises realizadas em 
um determinado ambiente. Perícias que são executadas no local (in loco) ou que buscam levantar 
detalhes do ambiente se enquadram nesta categoria de recomendações.
• Exame pericial de local de internet: orienta os profissionais na investigação de ocorrências e 
crimes ocorridos na internet.
A auditoria é uma ferramenta imprescindível para que os conteúdos coletados na perícia forense 
computacional estejam íntegros, seguros e disponíveis para a investigação. Contudo, a auditoria do 
conteúdo coletado em perícias forenses computacionais deve ser cercada de cuidados para que as 
evidências colhidas não sejam invalidadas por métodos de auditoria invasivos. É bastante comum que, 
145
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
assim como os peritos forenses, os auditores forenses computacionais sejam técnicos extremamente 
qualificados e com capacidade de avaliar até que ponto uma auditoria pode ser realizada sem prejudicar 
as evidências colhidas.
Entre as formas possíveis de auditoria em evidências, destacam-se:
• A recuperação e análise sobre sistemas de arquivos: o entendimento sobre como funcionam os 
principais sistemas de arquivos e como se dá a interação com os sistemas operacionais é de suma 
importância para que o profissional forense consiga identificar de forma correta as evidências. 
Auditorias e checagem nos conteúdos lógicos inspecionados durante uma investigação podem 
garantir a sobrevivida de evidências. Deve-se sempre lembrar que uma parte razoável do trabalho 
forense computacional é justamente recuperar dados apagados de mídias diversas. O quadro a 
seguir exibe os sistemas de arquivos dos principais sistemas operacionais.
Quadro 16 – Relação entre sistemas operacionais e sistemas de arquivos
Sistema operacional Sistema de arquivos
Microsoft Windows FAT, FAT16, FAT32, ExFAT, NTFS
Unix (Solaris, Linux, FreeBSD) UFS, Ext, Ext2, Ext3, Ext4, SWAP, Reiser, HPFS, JFS, XFS, ZFS
iOS HFS, HFS+
Android F2FS, Ext4
BigData – SAP/SAD HDFS, GDFS, LustreFS
• O exame de mídias físicas: esta é uma das principais maneiras pelas quais o profissional forense 
tem de levantar evidências relevantes para a elucidação de crimes cibernéticos. Cabe à auditoria 
garantir que o processo de registro foi bem efetuado com a gravação de dados em mídias externas 
(HD, pen drives, DVD) e que o manuseio desse conteúdo está sendo realizado de maneira correta. 
Em geral, imagens, assinaturas digitais e cópias do conteúdo gravado em mídia fazem parte do 
protocolo padrão de procedimentos dos profissionais forenses. Para que não aconteçam enganos, 
esses conteúdos devem ser auditados em locais próprios com ferramentas adequadas.
• O exame de eventos ocorridos por internet ou telefonia: o tracking ou rastreamento de 
eventos e atividades maliciosas executadas na internet é uma das funções executadas pelos 
peritos forenses computacionais. A checagem desse conjunto de dados é tarefa da auditoria. 
É um conteúdo amplo que deve ser validado e checado: contas bancárias, registros telefônicos, 
mensagens enviadas e recebidas, e-mails, arquivos abertos, conteúdos visualizados, contatos 
estabelecidos, arquivos recebidos e transmitidos, entre outros eventos, são passíveis de erros e 
precisam ser checados.
146
Unidade IV
• A análise de dados computacionais e de rede: dados oriundos de sniffers, sistemas de 
monitoramento ou redes sociais são campo fértil para o levantamento de evidências. Muitas 
vezes, uma análise superficial ou apressada pode trazer dois problemas: erros nas conclusões ou 
material que passou despercebido pela análise. Cabe à auditoria checar se os dados estão em 
conformidade com as conclusões alcançadas pelos peritos e verificar se algum tipo de evidência 
ficou para trás durante a análise forense.
• A investigação de imagens e vídeos: em geral, a análise de imagens segue o padrão 
normal forense: deve-se realizar uma análise do conteúdo da imagem ou do vídeo à procura 
de evidências que sirvam para elucidar um crime; e deve-se procurar identificar os autores 
do arquivo periciado. Entre as situações mais comuns que envolvem análise em imagens e 
vídeos, podem ser citadas: análise do conteúdo de uma cena, identificação facial de indivíduos, 
estimação de altura de suspeitos, manipulações maliciosas nas imagens, cenas de pornografia 
infantil, estimaçãode velocidade de veículos, investigação de detalhes como vestimentas e 
chapéus, identificação de equipamentos que produziram as imagens e fraudes em imagens. 
A auditoria, nesses casos, justifica-se pelo fato de esse tipo de exame ser extremamente 
técnico e realizado com a ajuda de software específico. Em muitos casos, durante a coleta 
e análise rápida de evidências, a perícia pode não perceber detalhes que são relevantes para 
a investigação. Nesse tipo de prova, a auditoria também serve para validar o exame pericial 
da imagem ou do vídeo, quando um réu recorre à justiça a respeito de uma evidência que 
considera inválida ou inconclusiva.
• A investigação em dispositivos móveis: a investigação de aparelhos móveis é bastante 
específica, mas abrange diversos aparelhos, celulares, smartphones, notebooks, tablets, entre 
outros. Deve-se buscar recolher e analisar evidências sobre quem está envolvido em um eventual 
crime cometido com aquele aparelho; o que houve e foi considerado crime; quando as ações 
investigadas aconteceram; como e em quais circunstâncias o delito foi cometido; e, finalmente, 
onde o crime foi consumado (aparelho, local etc.). Os resultados da investigação devem ser 
documentados, e todos os cuidados com a coleta, preservação e veracidade dos dados (físicos 
ou lógicos) continuam importantes nesse tipo de investigação. Boa parte do serviço de auditoria 
prestado reside em confirmar e verificar se todos esses cuidados foram tomados ao longo da 
investigação. Isso é muito importante, pois uma investigação forense mal feita pode fornecer 
subsídios para condenações ou absolvições indevidas.
Especificamente no caso de dispositivos móveis, há detalhes sobre o processo de coleta dos aparelhos 
e dos dados que devem ser observados em uma auditoria. A figura a seguir apresenta um fluxo para a 
extração de dados de aparelhos móveis apreendidos.
147
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
Desligar mobile
Remover cartões 
SIM e memória
Remover a 
bateria
Documentar data 
e hora (foto)
Modo avião
Desativar 4G, 
Wi-Fi, bluetooth 
e GPS
Mobile 
apreendido
Documentar e 
finalizar coleta
Encaminhar 
para exame
Desativar 
autobloqueio
Ativar USB 
debugging
Conectar 
carregadorDesligar mobile
Ligado?
Bateria 
removível?
Bloqeado 
por senha?
Senha 
configurada?
Não
Não Sim
Não
Sim
Não
Sim
Sim
Figura 82 – Fluxo de extração de dados de dispositivos móveis passível de auditoria
Pode-se perceber que a figura anterior apresenta três cenários de extração de dados nos quais pode 
ser necessária a realização de auditoria: mobile ligado e desbloqueado; mobile ligado e bloqueado; e 
mobile desligado.
Há muitos detalhes em auditorias de procedimentos executados em dispositivos móveis. A 
recomendação para aparelhos desligados é a retirada da bateria para evitar inicializações automáticas. 
A retirada dos cartões SIM também é importante, pois garante que, em caso de inicialização, não 
aconteçam reconexões à rede de telefonia. Cartões de memória também devem ser retirados. Caso a 
inicialização do aparelho seja inevitável, o ideal é impedir a propagação de sinais usando uma sacola de 
Faraday ou bloqueadores de sinais chamados radio jammers.
148
Unidade IV
A figura a seguir mostra um fluxo para a extração de dados de cartões SIM, bem mais simples que o 
mostrado na figura anterior.
Cartão SIM 
apreendido
Documentar 
extração
Solicitante do exame 
deve contatar a 
operadora
Documentar 
ICCID e operadora
Testar código 
padrão da operadora
Efetuar leitura direta 
SIM em ferramenta 
forense
Clonar SIM para 
uso no exame 
do aparelho (se 
presente)
Bloqueado 
PUK?
Mais 1 
tentativa?
Desblo-
-queado?
Bloqueado 
PIM?
Não
Não
Não
Não Sim
Sim
Sim
Figura 83 – Fluxo com a extração de dados em cartões SIM
Devido à proficiência de recursos, os dispositivos mobiles são considerados vetores para o cometimento 
de crimes. Há, portanto, um grande interesse em garantir a integridade das evidências desses aparelhos. 
Sendo assim, como todas as ações são voltadas para garantir a preservação e integridade dos dados 
contidos nos aparelhos, a auditoria também deve ter esse cuidado. Muitas vezes, é preferível uma 
auditoria que revise e valide os procedimentos adotados na coleta dos dispositivos a uma verificação 
mais invasiva que possa destruir ou invalidar evidências.
149
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
Via de regra, há ainda muitos cenários dentro do ambiente forense computacional que requerem o 
auxílio da auditoria. Os listados aqui foram apenas os principais.
8 AUDITANDO A GOVERNANÇA DE TI
Este tópico irá tratar um pouco sobre o papel de um processo de auditoria na governança de TI por 
meio do Control Objectives for Information and Related Technology (COBIT) e como esse modelo, focado 
principalmente em processos e métricas, pode ser importante para direcionar os rumos estratégicos 
de todo o negócio.
Requisitos expressam as necessidades e restrições de um negócio, seja um produto, um projeto, 
um software, um processo ou uma auditoria. Em relação a produtos, principalmente softwares, 
os requisitos funcionais estão mais ligados às necessidades e indicam como o produto deve ser. Já os 
requisitos não funcionais são atributos que estão mais próximos das restrições e definem como um 
produto deve ser comportar.
8.1 A auditoria com base no COBIT
A governança de TI corresponde a um conjunto de estruturas organizacionais, ferramentas e 
processos gerenciados de forma que a TI sustente e estenda as estratégias e os objetivos da organização.
O objetivo da governança de TI é alinhar e dar apoio aos requisitos de negócio, dar continuidade 
aos serviços e minimizar os riscos. Por isso, é uma função que precisa do respaldo da alta administração 
da empresa. Os principais motivadores para a implantação da governança de TI podem ser vistos na 
figura a seguir.
Governança de TI
Ambiente de 
negócios
Prestação de 
serviços
Integração 
tecnológica
Dependência 
do negócio
Segurança da 
informação
Marco de 
regulação
Figura 84 – Motivadores da governança de TI
150
Unidade IV
Há vários modelos e normas que podem ser usados para a implantação e manutenção da governança 
de TI em diversas áreas. Entre os principais, estão:
• Capability Maturity Model Integration (CMMI): desenvolvimento de produtos e projeto de 
sistemas e software.
• Information Technology Infrastructure Library (ITIL): serviços de TI, segurança da informação, 
gerenciamento da infraestrutura, gestão de ativos e aplicativos.
• Norma ABNT NBR ISO/IEC 38500: trata a governança corporativa da TI.
• Norma ABNT NBR ISO/IEC 27001: requisitos e códigos de práticas para a gestão da 
segurança da informação.
• Norma ABNT NBR ISO/IEC 27007: oferece diretrizes sobre o gerenciamento de um processo 
de auditoria em um Sistema de Gerenciamento de Segurança da Informação (SGSI). É um 
excelente complemento da norma ABNT NBR ISO/IEC 19011, já que funciona bem para auditorias 
internas e externas.
• Project Management Body of Knowledge (PMBOK): baseado em conhecimentos de 
gestão de projetos.
• Project in Controlled Enviroment (PRINCE2): metodologia de gerenciamento de projetos.
• Balanced Scorecard (BSC): metodologia de planejamento e gestão da estratégia.
• Control Objectives for Information and Related Technology (COBIT): modelo para governança 
e gerenciamento de TI no âmbito corporativo.
Neste tópico, a discussão se estende sobre o COBIT, justamente por suas características muito ligadas 
ao gerenciamento de processos e à medição dos resultados com métricas definidas, pontos bastante 
aderentes ao processo de auditoria.
O COBIT é um modelo de governança desenvolvido e mantido pela ISACA, que orienta a gestão e 
auditoria de uma área departamental de TI.
A versão 5 do COBIT tem como foco o uso corporativo e a importância da alta administração na 
tomada de decisões de TI. O COBIT contém cinco princípios, sete habilitadores e 37 processos, mostrados 
nas figuras e noquadro a seguir.
151
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
4. Permitir 
uma abordagem 
holística
5. Distinguir a 
governança da 
gestão
3. Aplicar um 
framework único 
e integrado
2. Cobrir 
totalmente a 
empresa
1. Atender às 
necessidades das 
partes 
interessadas
Princípios do 
COBIT 5
Figura 85 – Os cinco princípios da versão 5 do COBIT
COBIT 5:
Habilitador processos
COBIT 5
implementação
COBIT 5
para segurança da 
informação
COBIT 5
para garantia 
(Assurance)
COBIT 5
para risco
Outros guias 
profissionais
COBIT 5:
Habilitador informação
Outros guias de 
habilitadores
Guias profissionais do COBIT 5
Guias de habilitadores do COBIT 5
Ambiente colaborativo online do COBIT 5
Figura 86 – Os sete habilitadores da versão 5 do COBIT
Quadro 17 – Os 37 processos da versão 5 do COBIT
Domínios Processos
EDM
Avaliar
Dirigir
Monitorar
EDM01: Assegurar o Estabelecimento e Manutenção do Framework de Governança
EDM02: Assegurar a Entrega de Benefícios
EDM03: Assegurar a Otimização de Riscos
EDM04: Assegurar a Otimização de Recursos
EDM05: Assegurar a Transparência para as Partes Interessadas
152
Unidade IV
Domínios Processos
APO
Alinhar
Adquirir
Implementar
APO01: Gerenciar o Framework de Gestão de TI
APO02: Gerenciar a Estratégia
APO03: Gerenciar a Arquitetura Corporativa
APO04: Gerenciar a Inovação
APO05: Gerenciar o Portfólio
APO06: Gerenciar Orçamento e Custos
APO07: Gerenciar Recursos Humanos
APO08: Gerenciar as Relações
BAI
Construir
Adquirir
Implementar
BAI01: Gerenciar Programas e Projetos
BAI02: Gerenciar a Definição de Requisitos
BAI03: Gerenciar a Identificação e Construção de Soluções
BAI04: Gerenciar a Disponibilidade e Capacidade
BAI05: Gerenciar a Implementação de Mudança Organizacional
BAI06: Gerenciar Mudanças
BAI07: Gerenciar Aceite e Transição de Mudança
BAI08: Gerenciar o Conhecimento
BAI09: Gerenciar os Ativos
BAI10: Gerenciar a Configuração
DSS
Entregar
Reparar
Suportar
DSS01: Gerenciar as Operações
DSS02: Gerenciar Requisições de Serviço e Incidentes
DSS03: Gerenciar Problemas
DSS04: Gerenciar a Continuidade
DSS05: Gerenciar Serviços de Segurança
DSS06: Gerenciar os Controles de Processos de Negócio
MEA
Monitorar
Avaliar
Medir
MEA01: Monitorar, Avaliar e Medir o Desempenho e Conformidade
MEA02: Monitorar, Avaliar e Medir o Sistema de Controle Interno
MEA03: Monitorar, Avaliar e Medir a Conformidade com Requisitos Externos
Adaptado de: Nunes (2019, p. 56).
Planejar 
(APO)
Dirigir Monitorar
Avaliar
Entregar 
(DSS)
Construir 
(BAI)
Monitorar 
(MEA)
Demanda do negócio
Retorno da 
gestão
Governança
Gestão
Figura 87 – Os cinco domínios da versão 5 do COBIT
153
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
As atividades de avaliação, planejamento, implementação, suporte e avaliação/medição são ciclos de 
vida correspondentes dos processos mostrados no quadro “Os 37 processos da versão 5 do COBIT”. Esses 
processos estão ligados diretamente aos domínios ilustrados na figura anterior.
• Avaliar, Dirigir e Monitorar – Evaluate, Direct and Monitor (EDM): mostra como devem ser 
gerenciados os investimentos do negócio pela ótica do ciclo de vida dos sistemas.
 Lembrete
O ciclo de vida dos sistemas corresponde às atividades de projeto, 
desenvolvimento (ou compra), teste, operação e descarte.
• Alinhar, Planejar e Organizar – Align, Plan and Organizer (APO): diz respeito ao planejamento 
de aquisições, investimentos, gestão de riscos, projetos e qualidade.
• Construir, Adquirir e Implementar – Build, Acquire and Implement (BAI): gerencia a 
aquisição, o desenvolvimento e a implementação de tecnologias de TI.
• Entregar, Serviços e Suporte – Deliver, Service and Support (DSS): gerencia as atividades de 
entrega de serviços críticos ou fundamentais, a continuidade de negócios e os serviços de segurança.
• Monitorar, Avaliar e Analisar – Monitor, Evaluate and Assess (MEA): gerencia os controles 
internos para que as aquisições possam ser controladas adequadamente.
A função primordial do COBIT é melhorar os processos por meio do desenvolvimento de capacidades 
que estão associadas a ativos de pessoal, software, hardware, políticas e procedimentos. Tudo isso é 
monitorado por métricas predefinidas.
Já o processo de auditoria no modelo COBIT é composto de algumas etapas/atividades:
• Determinação dos requisitos de processo: nesta etapa, define-se o escopo das atividades, 
elencando processos, plataformas, papéis e responsabilidades.
• Seleção de áreas a serem auditadas: definição dos ambientes que devem passar pelo 
processo de auditoria.
• Avaliação e consideração sobre os controles: avaliação prévia sobre os controles existentes.
• Uso de documentação: verificação sobre como deve ser a documentação que servirá de referência 
durante o processo.
• Entendimento dos requisitos de negócios: consiste no entendimento do negócio em relação a 
sua indisponibilidade e consequentes impactos.
154
Unidade IV
• Avaliação e medição dos controles: atividades definidas a partir dos requisitos de negócio e 
consequentes impactos.
• Verificação de ineficiência dos controles: atividade realizada por meio de técnicas analíticas.
Por ser um modelo bastante utilizado, baseado principalmente na gestão dos processos e das métricas 
para avaliação, o COBIT é uma ferramenta poderosa para a auditoria. A própria abrangência do modelo 
corrobora essa afirmação, pois é possível utilizar o COBIT em muitas áreas/atividades diretamente 
ligadas à auditoria: integração estratégica, planejamento de TI, gerenciamento de controles internos e 
externos, gestão da segurança, conformidade, modelos de comparação, uso de guias e normas e adoção 
de modelos de maturidade.
8.2 Requisitos funcionais
Os processos de auditoria de sistemas tornam possível a verificação de sistemas que são utilizados, 
confirmando se estão registrando e tratando as transações rotineiras de um negócio de forma adequada.
De acordo com o COBIT, um processo de auditoria voltado para aplicativos (sistemas) deve 
abranger determinados objetivos: integridade, eficiência, efetividade, disponibilidade, conformidade, 
confiabilidade e confidencialidade. Cabe ao auditor executar sua tarefa por meio de observações, testes 
de controles programados, revisão de documentos e aplicação de técnicas de auditoria auxiliadas por 
computador, as CAAT.
Como dito, há duas formas usuais para a execução desse tipo de tarefa: verificar a estrutura dos 
sistemas e seus controles; e realizar testes diretos ou analíticos das transações executadas pelos sistemas.
É necessário entender o fluxo nos sistemas aplicativos, e, para isso, deve-se focar a avaliação no 
uso e nos resultados desses sistemas. Por exemplo: a capacidade de processar volumes de transações 
e examinar a integração com sistemas de um negócio é o que define se uma aplicação é de baixo, 
significativo ou alto desempenho no processamento.
Devem ser observados alguns pontos na execução da auditoria em aplicativos, principalmente 
durante a atividade de levantar documentação e informações referentes às estruturas do sistema:
• Devem ser identificados os sistemas-chave: é imprescindível que o auditor se concentre 
na avaliação dos sistemas mais importantes, que estão ligados de forma direta aos objetivos 
do negócio. A razão disso é que inconsistências nesses sistemas podem trazer prejuízos e 
consequências desastrosas para a organização.
• Deve haver uma descrição do sistema: é preciso identificar o propósito do sistema que atende 
a um processo crítico para os negócios da empresa. Esse processo tem o objetivo primário de 
diminuir os riscos ao negócio. Para isso, a identificação pode ser manual ou automática.
155
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
• Deve existir uma descrição do perfil do sistema: algumas informações precisam ser adquiridas, 
como a volumetria aproximada de transações em um período, quais programas estão em uso, 
se o programa utilizado é de desenvolvimento próprio ou de terceiros e de que forma ele 
foidesenvolvido.
• Deve haver uma documentação sobre o escopo geral de processamento: é importante 
analisar o fluxo de trabalho das principais funções durante o processamento de informações 
vitais e a frequência de execução dessas funções. Também é importante verificar se elas estão em 
conformidade com as regras de negócios previamente definidas pelos setores envolvidos.
• Devem ser criados documentos com restrição de riscos do sistema: para comprovar em 
qual ambiente (produção ou desenvolvimento) o sistema opera, são necessários documentos 
com informações sobre os responsáveis pelo sistema, qual a versão em uso, a existência de 
contingências, a data e os períodos dos testes.
Sobre a auditoria de aplicativos, os objetivos relacionados à avaliação de riscos que devem 
ser definidos são:
• Manutenibilidade: está relacionada ao fato de um sistema passar por manutenções sem 
apresentar problemas; se as políticas implementadas, os procedimentos operacionais, a 
documentação ou qualquer tipo de controle padronizados e previstos podem ser implementados 
em conformidade e sem riscos.
• Auditabilidade: deve haver documentação dos logs operacionais e cuidados extras com os logs 
de sistemas-chave, que devem ter seu mapeamento e sua rastreabilidade garantidos.
• Privacidade: deve-se garantir que os usuários vejam apenas informações que são 
relevantes a suas tarefas.
• Acuidade: deve-se garantir que as transações executadas sejam validadas de alguma forma.
• Disponibilidade: deve-se permitir que as informações ou os processos estejam disponíveis 
para uso e acesso.
• Confidencialidade: algumas informações devem estar restritas a um conjunto mínimo de pessoas.
• Versatilidade: deve-se garantir a adaptação e integração de um sistema com diferentes 
tecnologias. A versatilidade costuma trazer vantagens estratégicas ao negócio.
• Integridade: prover a integridade de um sistema traz confiança em todo o processo, gerando as 
bases para a tomada de decisões assertivas.
156
Unidade IV
De uma maneira geral, o resultado de uma auditoria de sistemas (aplicativos) deve garantir que todas 
as transações sejam armazenadas em conformidade com os princípios fundamentais das legislações 
vigentes. Todos esses princípios devem ser aplicados de maneira uniforme nos sistemas e subsistemas.
Caso sejam utilizados controles independentes, estes devem ser plenamente aplicados para que 
haja consistência e garantia de processos e relatórios fiéis ao resultado das transações de negócio. Os 
sistemas precisam possibilitar a integração com a contabilidade geral.
Com a evolução, os processos de auditoria passam por um considerável processo de automatização. 
Quando o foco é a informatização, é importante identificar aspectos que tenham relação direta com 
a organização. Perguntas sobre a cultura na qual o sistema está inserido, sua missão ou até mesmo 
quais são seus objetivos e programas de trabalho ajudam a identificar esses aspectos. Outros pontos 
relevantes são as características gerais dos serviços, quais produtos são gerados ou oferecidos, quais são 
os interesses e as necessidades de informações dos usuários, qual plataforma tecnológica existe, qual 
a capacidade de escalabilidade da plataforma tecnológica e se existem recursos humanos disponíveis.
Quando existe atenção a esses itens, benefícios são gerados à medida que os objetivos são 
especificados. Busca-se, com isso, o atendimento pleno das funções básicas da organização. Por 
exemplo: quando um processo de automação é acompanhado pela equipe de auditoria do início 
até a sua definição, torna-se importante uma boa integração de trabalho entre os auditores e os 
analistas de sistemas da empresa. Detalhes como a escolha do programa que será utilizado devem ser 
cooperativos e integrados entre os profissionais envolvidos
Com base nesse pensamento, estudos sobre a metodologia adotada para a seleção de pacotes de 
auditoria de sistemas devem ser realizados. Esse tipo de estudo deve contemplar aspectos como: análise 
de casos correlatos (com situações parecidas), visitas a usuários (ou fornecedores) de produtos selecionados, 
troca de informações com instituições semelhantes, análise da capacidade institucional, tecnológica e 
computacional do fornecedor e, por fim, verificação da idoneidade da instituição fornecedora.
Depois das avaliações citadas, o passo seguinte é reunir informações a respeito de produtos que estão 
disponíveis no mercado. Uma das maneiras é utilizar sistemas demonstrativos ou provas de conceito 
com sistemas que sejam aderentes aos objetivos do projeto. Como complemento, deve-se adotar um 
exame segundo as características funcionais e tecnológicas pertinentes ao processo de planejamento e 
emissão dos relatórios de auditoria.
Finalmente, na fase de avaliação dos aspectos funcionais, as características gerais e obrigatórias para 
o processo são direcionadas e identificadas pelos usuários. Alguns exemplos são: apoiar o planejamento 
da auditoria, apresentar o que for solicitado, extrair informações diretamente de um banco de dados, 
permitir aos auditores criar novos modelos de trabalho, permitir comentários do auditor e emitir os 
relatórios finais.
157
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
8.3 Requisitos não funcionais
Segundo a norma ABNT NBR ISO/IEC 25030, os requisitos não funcionais estão relacionados a 
atributos de qualidade:
• Portabilidade: é a capacidade de um programa mudar de um ambiente para outro. Por exemplo: 
quando um sistema se comunica com outros ou quando é multiplataforma (compatível com 
diversos sistemas operacionais).
• Eficiência: é a capacidade de um programa manter seu desempenho quando executado em um 
cenário com condições específicas. Por exemplo: um sistema que suporta até N transações em 
um determinado período ou que esteja disponível por X horas durante N dias da semana.
• Manutenibilidade: corresponde à capacidade de o programa ser manuseado ou funcionar 
de maneira compatível com aplicativos ou protocolos padronizados. Por exemplo: um sistema 
que possui suporte ao LDAP tem boa manutenibilidade, pois se trata de um protocolo padrão 
muito utilizado.
• Usabilidade: quando está relacionada a um programa, diz respeito ao fato de este ser atrativo, 
capaz de ser entendido, aprendido e usado em condições específicas.
• Confiabilidade: é a capacidade de um programa manter um nível específico de desempenho (ou 
outra característica qualquer) em cenários com condições específicas. Por exemplo: um sistema 
que garante a confiabilidade dos dados armazenados nele.
8.4 Auditando a segurança
Este tópico irá demonstrar como um processo de auditoria pode ser aplicado à segurança, 
apresentando, inicialmente, a visão a partir das normas da família ABNT NBR ISO/IEC 27000. O foco nas 
normas é bastante interessante, pois indica exatamente os pontos que devem ser verificados em um 
processo de auditoria.
Em seguida, o conteúdo se estende para cenários voltados para a gestão de incidentes, a garantia de 
continuidade dos negócios e os sistemas que tratam sobre o gerenciamento de segurança da informação.
Por fim, detalhes específicos sobre alguns dos principais controles de segurança utilizados serão 
discutidos, sempre pela ótica da auditoria.
8.4.1 A auditoria na gestão da segurança
A ABNT NBR ISO IEC 27001 (ABNT, 2013a) faz parte da família de normas de segurança 27000 da 
ABNT e trata sobre a gestão da segurança da informação.
158
Unidade IV
Quadro 18 – Principais focos das primeiras normas 
da família ABNT NBR ISO/IEC 27000
Norma Principal abordagem
Aderência com 
processos de 
auditoria
27000 Visão geral sobre a família de normas -
27001 Requisitos para um sistema de gestão da segurança da informação (SGSI) Alta
27002 Controles de segurança Média
27003 Diretrizes para implementação de um SGSI Alta
27004 Métricas para segurança da informação Alta
27005 Gestão de riscos Média
27006 Requisitos para auditopria dos sistemas de gestão de segurança Média
27007 Diretrizes paraauditoria dos sistemas de gestão de segurança Alta
27008 Diretrizes para auditoria dos sistemas de gestão de segurança Média
27009 Orientação à indústria Baixa
27010 Comunicação na gestão da segurança Média
27011 Telecomunicações Baixa
27012 Cancelada - abordava a gestão da segurança pública -
27013 Guia para implementação da norma 27001 Média
27014 Governança da segurança da informação Média
27015 Gestão da segurança para o setor financeiro Média
27016 Gestão da segurança para o setor econômico Média
27017 Nuvem Baixa
Uma das recomendações da norma ABNT NBR ISO/IEC 27001 é a identificação inicial dos controles 
atualmente implementados – a norma que trata diretamente sobre os controles de segurança é a ABNT 
NBR ISO/IEC 27002 (ABNT, 2013b). Com isso, é possível identificar vulnerabilidades e ameaças a que os 
controles estão sujeitos.
Muitas vezes, os controles de segurança apresentam falhas na cobertura. Como a evolução das 
ameaças cibernéticas é contínua, controles desatualizados passam a oferecer proteção insuficiente. 
Dentro do contexto da gestão da segurança da informação, a norma ABNT NBR ISO/IEC 27001 sugere a 
avaliação dos seguintes domínios:
• PSI: a PSI deve funcionar como um guia, ensinando os colaboradores, definindo os padrões de 
trabalho e garantindo a proteção de ativos e pessoas dentro da organização.
• Organização da segurança da informação: deve seguir uma estrutura que permita o 
gerenciamento completo da segurança da informação, com controle, implementação e 
operação dos processos e controles de segurança adotados.
159
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
• Segurança em recursos humanos: deve garantir que os colaboradores estejam alinhados com 
os papéis a eles designados, assim como assegurar que essas responsabilidades sejam entendidas, 
gerenciadas e cumpridas.
• Gestão de ativos: deve identificar quais são os ativos da empresa, qual a importância e criticidade 
de cada um deles. Também inclui a atribuição de responsabilidades na proteção dos ativos.
• Controle de acesso: políticas e ferramentas de acesso devem ser implementadas para diminuir 
as possibilidades de acesso indevido aos ativos da organização.
• Criptografia: sempre que viável, técnica e economicamente, a criptografia deve ser utilizada 
a fim de garantir a confidencialidade, a integridade, a autenticação e a irretratabilidade (não 
repudiação) dos ativos de informação.
• Segurança física e do ambiente: deve ser efetiva e abrangente, resguardando os ativos físicos e 
as pessoas dentro da organização.
• Segurança nas operações: devem ser estabelecidas regras para a operação segura das atividades 
realizadas diariamente na empresa.
• Segurança nas comunicações: as informações que trafegam pelas redes de comunicação devem 
ser protegidas por controles que garantam a CIDA.
• Aquisição, desenvolvimento e manutenção de sistemas: deve-se assegurar que a preocupação 
com a segurança siga todo o ciclo de vida de um sistema – planejamento, aquisição ou 
desenvolvimento, testes, operação e descarte. Em todos esses ciclos, a segurança deve ser pensada, 
implementada, revisada e aprimorada.
• Relacionamento na cadeia de suprimentos: deve ser assegurada a proteção dos ativos 
gerenciados por fornecedores. A implementação de segurança em processos que ainda não 
estão sendo executados na empresa garante mais confiabilidade aos produtos e serviços que 
serão entregues.
• Aspectos da segurança da informação na gestão da continuidade do negócio: deve haver 
políticas que incentivem a criação de Planos de Continuidade dos Negócios (PCN). Nesses planos, 
devem constar soluções para que os negócios não sejam interrompidos pela concretização 
de alguma ameaça.
• Gestão de incidentes de segurança da informação: deve existir um esforço constante para que 
os incidentes relacionados à segurança da informação sejam gerenciados adequadamente, com a 
implementação das medidas corretivas necessárias (previstas no PCN) e a efetiva comunicação e 
documentação dos resultados.
160
Unidade IV
• Conformidade: deve haver um direcionamento efetivo para que todos os controles e as medidas 
de proteção adotadas estejam de acordo com as leis, os contratos ou as regulamentações vigentes.
8.4.2 A auditoria no gerenciamento de incidentes e na continuidade dos negócios
A norma ABNT NBR ISO/IEC 27002 (ABNT, 2013b) também trata sobre incidente, um evento que, 
ao ocorrer, traz impactos negativos para a empresa. Processos voltados para a criação de planos ou de 
análise de incidentes estão entre as operações que mais precisam de auditoria. O motivo é simples: as 
ameaças e vulnerabilidades se renovam, e, por isso, mesmo processos proativos devem constantemente 
passar por atualização. Um processo de auditoria periódica, bem organizado, é uma ferramenta poderosa 
para que o gestor possa se antecipar a problemas e prejuízos. A norma ABNT NBR ISO/IEC 27002 sugere 
um processo constituído de quatro etapas para o gerenciamento de incidentes:
• Notificação: nesta etapa, investiga-se a veracidade do incidente, ou seja, se o evento ocorrido 
de fato é um incidente e, se for, qual a sua relevância e o seu efeito. A notificação inicial pode 
ser obtida por alarme, reclamação de um usuário, alerta de um fornecedor de segurança ou 
análise de histórico.
• Resposta: nesta etapa, a expectativa é que existam procedimentos com informações sobre como 
reagir perante o incidente. Contudo, são necessários cuidados com a análise de incidentes que 
resultem em alertas FP, que podem afetar diretamente a confiabilidade do sistema. Além disso, 
espera-se que o sistema tenha uma base de conhecimento bem planejada, para responder a um 
determinado incidente de forma adequada e servir de treinamento para o time responsável pelo 
gerenciamento de incidentes.
• Recuperação: nesta terceira etapa, a expectativa é a existência de um plano de resposta a 
incidentes, do inglês Disaster Recovery Plan (DRP), bem estruturado, processual e pré-aprovado 
que permita o início do processo de recuperação. Esse tipo de preparação antecipada facilita o 
gerenciamento do incidente frente a uma crise. Os impactos de um incidente podem ser amplos, 
e os prejuízos podem chegar a clientes e parceiros da organização. Por isso, é importante ressaltar 
que o plano deve levar em conta não somente a solução do problema, mas a causa raiz do incidente.
• Documentação: esta última etapa define como deve ser feita a documentação de incidentes para 
o histórico e enriquecimento da própria base de conhecimento. Isso é bastante útil para a adoção 
de medidas preventivas e proativas contra futuros incidentes.
 Lembrete
Um alerta Falso Positivo (FP) diz respeito a um evento que não representa 
risco, mas está classificado como um problema real.
Um DRP deve considerar três etapas: a provisão de um centro de operações de emergência, do inglês 
Emergency Operations Center (EOC), no qual é feita a gestão do DRP e do plano de continuidade de 
161
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
negócio (BCP); a nomeação de um gerente do EOC; e a definição da circunstância que leva o gerente do 
EOC a declarar desastre.
Além disso, o DRP ajuda a predeterminar tomadas de decisões sem que o ambiente esteja realmente 
em crise, ou seja, pode funcionar de forma simulada, por hipóteses. Em contrapartida, um DRP deve ser 
planejado cuidadosamente porque pode refletir um custo elevado.
O DRP deve estar alinhado com a unidade de negócios da organização, pois isso permite a 
identificação de sistemas vitais e de missão crítica, ordens de restauração de serviços e informações, além 
da estimativa de tempo de restauração de serviços. Com isso, é possível definir a ordem de importância 
dos resultados de uma recuperação de desastres:
• Garantir a segurança de indivíduos.
• Conter os danos.
• Avaliar os danos e iniciar a recuperação segundo o DRP e o BCP.
Apesar de estar na terceira posição, a restauração e retomada das operações da empresa para 
o estado pré-incidente sãomuito importantes – isso garante a continuidade dos processos. Muitas 
vezes, devem ser realizadas de forma gradativa. Inicialmente, a restauração pode ser efetivada em um 
local alternativo com desempenho inferior ao ambiente de origem. Posteriormente, pode acontecer 
o retorno ao local original, talvez de forma ainda adaptada, uma vez que os processos ainda poderão 
estar comprometidos.
Em processos desse tipo, há alguns pontos relevantes que devem ser considerados pela auditoria, 
como a suspensão de processos normais, o aumento da disponibilidade do suporte técnico para o 
usuário final, a continuidade do processo de backup mesmo no ambiente de restauração, entre outros. 
No caso de backups, deve-se considerar também a necessidade da atualização de sistemas operacionais, 
uma vez que esses dados podem estar desatualizados no backup, e a aplicação de regras de controle de 
acesso o mais breve possível.
O DRP deve prever questões de disponibilidade física e predial, do inglês facilities, tais como 
geradores, proteção do local danificado e previsão de retorno; questões de logística, como o retorno 
dos funcionários; e telecomunicações, para manter os pontos focais em comunicação.
Além da figura do gerente do EOC, existe a figura do coordenador de continuidade, que, nesse 
momento, deve considerar: local alternativo para processamento secundário, instalação alugada ou até 
mesmo móvel e acordos de instalação. Alguns fatores influenciam a escolha de um local alternativo, 
como o custo de um centro de processamento adicional, a necessidade de restauração dos dados, no 
caso de uso de uma estrutura intermediária, ou questões relacionadas ao transporte de ativos.
162
Unidade IV
8.4.3 A auditoria em sistemas de gerenciamento de segurança da informação (SGSI)
Quando se trata de gerenciar incidentes e garantir a continuidade dos negócios, é recomendável a 
criação de um Sistema de Gerenciamento de Segurança da Informação (SGSI). Um sistema desse tipo 
deve ser considerado uma solução de longo prazo e adaptável a mudanças organizacionais, uma vez que 
seu objetivo é a verificação e identificação de vulnerabilidades do negócio.
O processo de implementação de um SGSI deve considerar quatro fases:
• Identificação de vulnerabilidades em relação ao negócio.
• Mapeamento, por prioridade, de riscos e recomendações.
• Roadmap de aplicação das recomendações da fase anterior.
• Avaliação da justificativa dos controles e suas efetividades.
Sistemas de gerenciamento de melhoria contínua, tais como PDCA e 6-Sigma, podem ajudar na 
manutenção de um SGSI. Esses sistemas facilitam o entendimento de como um incidente pode impactar 
uma determinada parte do negócio.
Contudo, sabe-se que a segurança tecnológica depende mais da conscientização de pessoas do que 
propriamente de uma ferramenta. Sendo assim, em uma empresa, o sucesso da segurança depende de 
três fatores: o risco que a organização pode assumir; a funcionalidade dos sistemas; e o investimento 
em segurança que a organização pretende fazer. Com isso, entende-se que a segurança é uma 
característica de gestão, não apenas técnica, e, por consequência, deverá garantir, de forma equilibrada, 
o CIDA dos ativos.
Por todos esses fatores, a elaboração de um SGSI não é algo trivial. A organização precisará aprender 
com os incidentes, aplicar um processo de melhoria contínua, definir e manter revisado um BCP. Existe, 
de fato, a necessidade do entendimento de normas técnicas para a confecção do SGSI, principalmente 
as da família ABNT NBR ISO/IEC 27000.
8.4.4 A auditoria por meio de varredura e sniffer
Durante a implementação das políticas de segurança em um ambiente corporativo, é necessário 
levantar as vulnerabilidades presentes na rede. Para isso, há um conjunto de ferramentas de segurança 
bastante utilizado para o monitoramento dos pacotes que navegam na rede e a inspeção direta dos 
serviços de uma máquina ou um servidor.
Para fazer uma análise direta das vulnerabilidades que uma máquina ou um servidor mantém 
expostas na rede, a recomendação é o uso de varredura. A varredura é um processo iniciado a partir 
de um software que tem por objetivo descobrir, de forma remota, informações sobre máquinas, redes, 
serviços e até vulnerabilidades.
163
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
A varredura funciona a partir da análise da resposta de pacotes enviados para a rede ou para o 
destino analisado. Isso ocorre porque cada aplicação tende a responder de forma diferente de acordo 
com a sua versão ou com o sistema operacional no qual a aplicação está em execução. Ou seja, pacotes 
de dados característicos são gerados e trocados a cada aplicação/serviço. Dessa forma, é gerada uma 
resposta que ajuda a identificar falhas e vulnerabilidades presentes no ambiente.
Outra opção de aplicação muito utilizada no monitoramento de redes são os aplicativos sniffers, 
comumente usados para monitorar todo o tráfego que passa na infraestrutura de rede. Através de uma 
interface de conexão, a aplicação recebe os pacotes que são enviados dentro daquele segmento de 
rede. Isso permite a análise de tráfego à procura de pacotes inconsistentes ou informações maliciosas 
que estejam trafegando. Esses softwares permitem ainda a realização de análises para entender como 
ocorreram alguns ataques no ambiente de rede. Além disso, quando os resultados de um sniffer são 
combinados com outros controles de segurança, é possível realizar uma análise bem mais detalhada das 
vulnerabilidades do ambiente. Em alguns casos, até mesmo simulações são possíveis.
O Wireshark é um dos sniffers mais populares para a realização de análises no tráfego de rede.
Figura 88 – Captura de tráfego de consultas DNS com o sniffer Wireshark
A figura anterior mostra diversas consultas a um servidor DNS realizadas por um usuário que está 
tentando navegar pela internet. É bastante comum descobrir os domínios pelos quais um usuário 
navegou usando o utilitário Tshark, que funciona com comandos compatíveis do Wireshark.
Além de capturar os pacotes, o Wireshark permite organizar os pacotes por protocolos, interfaces e 
várias outras categorias de dados. Suas funções são parecidas com as do aplicativo TCPdump; porém, 
o Wireshark possui uma interface de usuário muito mais amigável e que permite a aplicação de 
diversos filtros.
164
Unidade IV
A tabela a seguir mostra os logs gerados pelo sniffer TCPdump.
Tabela 2 – Parte da captura do tráfego de acesso ao site 
unip.br com o TCPDump em 22 de fevereiro de 2020
bt ~ # tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
:
17:52:22.350598 IP 192.168.160.133.34531> gru14s07-in-f3.1e100.net.https:. ack 742 win 15561
17:52:22.379579 IP 192.168.160.133.40297> unip.br.https: P 2300:2657(357) ack 75816 win 62780
17:52:22.380370 IP unip.br.https> 192.168.160.133.40297:. ack 2657 win 64240
17:52:22.441420 IP unip.br.https> 192.168.160.133.40297:. 75816:77276(1460) ack 2657 win 64240
17:52:22.441422 IP unip.br.https> 192.168.160.133.40297: P 77276:77533(257) ack 2657 win 64240
17:52:22.441450 IP 192.168.160.133.40297> unip.br.https:. ack 77533 win 62780
17:52:22.593374 IP 192.168.160.1.mdns> 224.0.0.251.mdns: 0 AAAA (QM)? 0.local. (25)
17:52:22.595996 IP6 fe80::5db2:7d93:88af:990a.mdns> ff02::fb.mdns: 0 AAAA (QM)? 0.local. (25)
17:52:22.598452 IP 192.168.160.1.mdns> 224.0.0.251.mdns: 0 A (QM)? 0.local. (25)
17:52:22.600618 IP6 fe80::5db2:7d93:88af:990a.mdns> ff02::fb.mdns: 0 A (QM)? 0.local. (25)
17:52:22.647224 IP 192.168.160.1.54758> 239.255.255.250.1900: UDP, length 174
17:52:23.094477 IP 192.168.160.1.netbios-ns> 192.168.160.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
17:52:23.649109 IP 192.168.160.1.54758> 239.255.255.250.1900: UDP, length 174
17:52:24.653342 IP 192.168.160.1.netbios-ns> 192.168.160.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
17:52:24.653577 IP 192.168.160.1.54758> 239.255.255.250.1900:UDP, length 174
17:52:24.655367 IP 192.168.160.1.mdns> 224.0.0.251.mdns: 0 A (QM)? 0.local. (25)
17:52:24.657511 IP6 fe80::5db2:7d93:88af:990a.mdns> ff02::fb.mdns: 0 A (QM)? 0.local. (25)
17:52:24.660014 IP 192.168.160.1.mdns> 224.0.0.251.mdns: 0 AAAA (QM)? 0.local. (25)
17:52:24.661744 IP6 fe80::5db2:7d93:88af:990a.mdns> ff02::fb.mdns: 0 AAAA (QM)? 0.local. (25)
17:52:25.076452 IP6 fe80::5db2:7d93:88af:990a.59139> ff02::1:3.5355: UDP, length 19
17:52:25.076985 IP6 fe80::5db2:7d93:88af:990a.50460> ff02::1:3.5355: UDP, length 19
17:52:25.076987 IP 192.168.160.1.59139> 224.0.0.252.5355: UDP, length 19
17:52:25.079788 IP 192.168.160.1.50460> 224.0.0.252.5355: UDP, length 19
17:52:25.246801 IP 192.168.160.1.53515> 239.255.255.250.1900: UDP, length 275
17:52:25.406976 IP 192.168.160.1.netbios-ns> 192.168.160.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
17:52:25.657286 IP 192.168.160.1.mdns> 224.0.0.251.mdns: 0 A (QM)? 0.local. (25)
17:52:25.658369 IP 192.168.160.1.54758> 239.255.255.250.1900: UDP, length 174
17:52:25.659734 IP6 fe80::5db2:7d93:88af:990a.mdns> ff02::fb.mdns: 0 A (QM)? 0.local. (25)
17:52:25.662034 IP 192.168.160.1.mdns> 224.0.0.251.mdns: 0 AAAA (QM)? 0.local. (25)
17:52:25.663918 IP6 fe80::5db2:7d93:88af:990a.mdns> ff02::fb.mdns: 0 AAAA (QM)? 0.local. (25)
:
 packets captured
 packets received by filter
 packets dropped by kernel
165
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
Na tabela anterior, podem ser observados os logs de um acesso ao site da UNIP realizado com o 
comando TCPdump em um sistema operacional Linux. Os logs contam com timestamp, IP (versões 4 e 6) 
de origem e destino, protocolo, tamanho do payload, entre outras informações.
Sniffers e ferramentas de varredura mostram os cabeçalhos de rede dos dados que passaram pelas 
interfaces e permitem um monitoramento preciso dos pacotes, sendo bem úteis ao administrador de rede 
ou mesmo a um auditor de segurança. Contudo, é preciso ter certo cuidado, pois sniffers e varreduras 
também podem ser utilizados de forma maliciosa por atacantes.
8.4.5 A auditoria por meio de firewalls
O firewall é uma das principais soluções usadas como controles de segurança. Apesar de não ter a 
capacidade de solucionar todas as demandas sozinho, é comumente associado às técnicas de segurança 
que aumentam o controle da rede. Um firewall analisa pacotes de entrada e saída em um ponto da 
rede, tomando decisões a partir de um conjunto de regras criado previamente pelo administrador de 
segurança da rede.
IP
Análise do cabeçalho
TCP/IP
Análise do protocolo
de aplicação
Análise de conteúdo
do Payload
IPTCP
IP TCP
TCPhttp
http
httpPayload
Payload
Payload
Figura 89 – Análise dos campos e do conteúdo (payload) de um pacote TCP/IP por um firewall
Um firewall é capaz de realizar autenticação e gerar registros de acesso, funcionando como um 
ponto único de convergência para a rede privada. Além de filtrar os dados, um firewall concentra outras 
funcionalidades e serviços, como a segregação de sub-redes, a criação de grupos de trabalho ou a 
separação de redes em Virtual Local Area Networks (VLAN).
Já que permite a aplicação de políticas de segurança, possibilitando um gerenciamento mais restrito 
ou mais relaxado, também é comum que um firewall seja usado na definição de arquitetura de rede, no 
controle de acesso, na realização de Network Address Translation (NAT), no roteamento, na criação 
de caches e atuando como proxies (que serão vistos detalhadamente um pouco mais à frente).
166
Unidade IV
 Saiba mais
O NAT altera os endereços IP de uma rede interna quando esses pacotes 
são enviados para a internet, garantindo o isolamento da rede local. Mais 
detalhes podem ser encontrados em:
WETHERALL, J.; TANENBAUM, A. S. Redes de computadores. 5. ed. Rio de 
Janeiro: Campus, 2011.
Seja na forma de hardware ou software, os firewalls podem ser elementos importantes para a 
filtragem de dados em uma auditoria.
8.4.6 A auditoria por meio de sistemas de detecção e prevenção de intrusões (SDPI)
Apesar do conjunto de soluções e restrições que o firewall utiliza para aumentar a segurança do 
ambiente, por vezes, os atacantes ainda conseguem explorar vulnerabilidades na rede. Isso se dá pela 
exploração da conexão de portas válidas cujo firewall possui regras permissivas de uso.
A permissividade do uso desses serviços, muitas vezes, é necessária devido à prestação de serviços 
externos, como a publicação de páginas web através da porta 80. Dessa forma, por mais que sejam 
utilizadas normas restritivas dentro do ambiente, essa porta ainda precisaria permanecer aberta. 
Processos de auditoria de segurança, com a geração de logs, podem ser muito mais precisos e completos 
com o uso de sistemas de detecção e prevenção de intrusões (SDPI).
Os SDPI são sistemas que permitem identificar atividades suspeitas dentro do ambiente corporativo. 
Esse tipo de sistema atua de forma análoga às câmeras de segurança, gerando provas que ajudem a 
identificar a exploração de vulnerabilidades. Desse modo, um SDPI pode trabalhar em conjunto com o 
firewall, ajudando na detecção de diversos tipos de ataque que porventura estejam utilizando portas 
válidas do ambiente.
Os sistemas de detecção podem, no entanto, atuar de diversos modos dependendo de alguns 
fatores: host SDPI, quando o SDPI é ligado a uma única máquina; network SDPI, quando o SDPI exerce 
funções de segurança em toda a rede; por assinatura, quando o SDPI contém uma base com assinaturas 
de ameaças e vulnerabilidades; e por anomalias, quando o SDPI detecta anomalias a partir da 
análise de um comportamento considerado padrão.
167
AUDITORIA DE SISTEMAS (CONCEITO E APLICAÇÃO)
Mail 
Server
H-SDPI
H-SDPI
WWW 
Server
Internet
Firewall
N-SDPI N-SDPI
Console SDPI (gerenciamento)
Rede protegida
Topologia ou configuração de rede típica com SDPI
Tratamento de dados centralizado ou distribuído
Figura 90 – Atuação de um SDPI (host e network) em conjunto com um firewall em uma rede
Todos esses detalhes fazem do SDPI sistemas (software ou hardware) mais abrangentes que 
um firewall. Em geral, um SDPI analisa mais critérios e toma decisões com base em mais variáveis 
que um firewall.
A metodologia de detecção, o posicionamento dos sensores e a localização do SDPI na rede também 
são fatores que alteram o funcionamento e a precisão da atuação desse tipo de controle de segurança. 
Uma vez que ataques são detectados, alertas são disparados para os administradores de rede, relatando 
as ocorrências de possíveis ataques ou anomalias no comportamento da rede. Os relatórios de alerta 
permitem ainda que o SDPI forneça dados de alguns analistas para que estes revejam suas políticas de 
segurança, o que torna a análise dos cenários mais assertiva.
O Snort é um SDPI de código aberto que funciona por assinatura, alertando o administrador em caso 
de detecção de problemas.
Figura 91 – Logotipo e exemplo de assinatura de alerta típica do Snort
Basicamente, o Snort exerce três funções fundamentais:
• Sniffer: apesar de ser um SDPI, pode ser utilizado simplesmente como um sniffer, capturando 
pacotes para análise.
168
Unidade IV
• Log de pacotes: bastante útil para avaliar o tráfego da rede em uma auditoria.
• Network Intrusion Detection System (NIDS): sistema completo de detecção de intrusão com 
capacidade de detectar eventos suspeitos por meio de um sistema de assinatura programável, 
gerar eventos para ser enviados ao programa de logs do sistema operacional e gerar alarmes de 
vários tipos, comunicando em tempo real um ataque em andamento.
Um dos problemas desse modo de funcionamento baseado em alertas é que o SDPI acaba sendo 
um controle de segurança passivo, já que não toma medidas, apenas emite alertas. Isso gera alguns 
inconvenientes, pois, mesmo quando detecta tentativas de invasão, não está apto a intervir. Porém, 
também há alguns SDPI que atuam de forma mais proativa e tomam decisões, como o bloqueio 
de pacotes ou a paralisação de serviços. É bastante comum