I_Teorico - Perícia Forense Computacional

Prévia do material em texto

Inserir Título Aqui 
Inserir Título Aqui
Perícia Forense 
Computacional
Incidentes de Segurança e Violações
na Política de Segurança da Informação
Responsável pelo Conteúdo:
Prof. Me. Marcelo Carvalho
Revisão Textual:
Prof.ª Me. Sandra Regina Fonseca Moreira
Nesta unidade, trabalharemos os seguintes tópicos:
• Incidentes de Segurança da Informação;
• Investigação Forense Computacional.
Fonte: Getty Im
ages
Objetivos
• Compreender a relação entre incidentes de segurança da informação e a política de se-
gurança da informação corporativa;
• Conceituar a atividade do perito e contextualizar o “momento” de sua atuação, 
considerando os eventos que sucedem a identificação de um incidente e o início 
da investigação forense.
Caro Aluno(a)!
Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o úl-
timo momento o acesso ao estudo, o que implicará o não aprofundamento no material 
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.
Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você 
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns 
dias e determinar como o seu “momento do estudo”.
No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões 
de materiais complementares, elementos didáticos que ampliarão sua interpretação e 
auxiliarão o pleno entendimento dos temas abordados.
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de 
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de 
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de 
troca de ideias e aprendizagem.
Bons Estudos!
Incidentes de Segurança e Violações 
na Política de Segurança da Informação
UNIDADE 
Incidentes de Segurança e Violações
Contextualização 
Consiste na inserção do conteúdo em um contexto referente ao cotidiano do aluno 
ou da prática profissional futura, demonstrando e ressaltando a importância do estudo 
da unidade para a sua formação pessoal e profissional. A contextualização pode ser 
apresentada por meio de uma narrativa descritiva, uma situação-problema, um exemplo 
de aplicação, vídeos, reportagens, cases, entre outros. 
O trabalho de um perito forense computacional pode ser demandado em diferentes 
circunstâncias e com propósitos distintos. Nesta unidade, você irá compreender onde se 
inicia o trabalho do perito forense, em um cenário corporativo de administração de SI.
Neste sentido, é importante perceber que o trabalho do perito forense transcende 
o escopo visto nesta unidade, já que sua atuação pode ocorrer também em casos de 
investigação fora da rotina de trabalho do investigado, em suas atividades de cunho pes-
soal que tenham sido objeto de processos da esfera civil e/ou criminal. O entendimento 
do papel do perito, no escopo corporativo, está relacionado ao incidente de segurança, 
na medida que este é o evento que demanda a equipe de TI por uma solução para a 
infraestrutura atingida.
Dependendo da evolução e do tipo de incidente, o trabalho do perito forense pode 
ser requerido. Isto é, em parte dos incidentes de SI respondidos por uma equipe de TI 
e/ou SI corporativa, haverá a necessidade de se obter evidências computacionais que 
sustentem e corroborem com a investigação conduzida em razão de um incidente de se-
gurança da informação que tenha afetado um ou mais serviços da infraestrutura. Neste 
cenário, o papel do perito é de um especialista que colabora com o processo de resposta 
a incidentes.
6
7
Incidentes de Segurança da Informação
Quando falamos de incidentes, uma interpretação possível seria pensarmos em in-
tercorrências, ou situações fora do habitual. Em geral, no entanto, quando queremos 
nos referir ao tipo de incidente específico que caracteriza uma “quebra de segurança”, 
em especial em ambientes corporativos, normalmente vemos esse termo associado ao 
comprometimento de um ativo da organização. Como sabemos que a definição de ativo 
é ampla, e pode referir-se a diferentes componentes dessa organização, cabe aqui res-
gatarmos esse termo, na semântica conveniente para o entendimento de incidentes no 
contexto corporativo.
Um dos exemplos de ativos mais frequentemente atacados, mas que paradoxalmente 
não é percebido por leigos como um ativo corporativo, é a informação. Ainda que não 
saibamos a que tipo de informação se refere, em um primeiro momento, muitos não a 
veem como um alvo de incidente, possivelmente proveniente de um ataque cibernético. 
Isso porque nos acostumamos a visualizar ambientes de TI com a imagem de data-
-centers, cheios de racks lotados de servidores, com cabos, fibras ópticas conectando-os 
neste ambiente tecnológico e acabamos por esquecer que esse conjunto de equipamen-
tos só existe porque possui a tarefa de armazenar, processar ou transmitir os ativos de 
informação. Porém, esse é um ativo de valor, pois olhando pelo prisma de impactos 
gerados ao negócio em decorrência de um incidente de segurança da informação, po-
demos perceber impacto em geral maior quando o comparamos com os servidores e 
demais equipamentos do datacenter envolvido no episódio.
A informação contém valor, pois está integrada com os processos, pessoas e tecnolo-
gias na corporação. Essa dependência e interligação é o que torna esse ativo importante. 
A informação é um ativo que, por sua importância para o negócio, tem um valor para a 
organização e consequentemente necessita ser adequadamente protegida.
Nem toda informação, no entanto, é crucial ou essencial a ponto de merecer pro-
teções especiais. Por isso, mesmo analisando esse tipo de ativo importante, separada-
mente em relação aos seus subtipos, podemos também perceber diferentes escalas de 
impacto ao negócio, em razão de um incidente de segurança da informação envolvendo 
seu comprometimento.
Segundo Sêmola (2014), a Segurança da Informação (SI) é uma área de conhecimen-
to dedicada à proteção de ativos da informação contra acessos indevidos. Percebemos, 
assim, que ao analisarmos a ocorrência de um incidente, quando este ocorreu em ativos 
protegidos e monitorados, fica demonstrada a capacidade de detecção de intercorrências 
em ativos considerados de importância para a organização.
Veja outros exemplos de ativos neste ambiente corporativo:
• Ativos digitais (conteúdo textual, imagens e multimídia);
• Ativos de informação;
• Ativos de software/sistema;
7
UNIDADE 
Incidentes de Segurança e Violações
• Ativos físicos (equipamentos);
• Ativos de serviço (eletricidade, comunicação, refrigeração, entre outros);
• Ativos humanos (colaboradores, parceiros, entre outros);
• Ativos intangíveis (imagem e a reputação da empresa).
Perceba que diferentes atividades relacionadas ao tema de incidentes de segurança 
da informação fazem parte da gestão de ativos. Ao avaliarmos a atividade por meio 
das boas práticas de serviços de TI, descritas pelo ITIL V3 (Figura 1), pode-se obser-
var especial relevância nas tarefas de política e estratégia (onde se definem os ativos 
e proteções), análise de risco (onde se estabelecem níveis de risco para ativos e parâ-
metros para o “aceite” de riscos mapeados), e principalmente a tarefa de verificação e 
ações corretivas (onde ocorre o monitoramento e resposta a incidentes de segurança 
da informação). Perceba também que alguns dos ativos citados como exemplos corpo-
rativos sequer têm uma forma concreta e objetiva de representação na infraestrutura 
de TI para que sejam monitorados.
Por exemplo, como você faria para estabelecer uma política de gestão de ativos capaz 
de identificar incidentes que ocorrem com ativos intangíveis, como a marca da empresa?
Asset
Management
System
Management
Review
Checking &
Corrective
Action
Implementation
& Operation
Policy &
Strategy
AM Info, Risk
Assessment &
Planning
Figura 1 – Ilustração da atividade de gerenciamento de ativos, segundo o ITIL V3
Já as atividadesde implementação e revisão da gerência são as que se beneficiam do 
processo de resposta a incidentes em si, na medida em que a investigação do ocorrido 
permite a identificação do controle que falhou ou do que foi comprometido (por um 
atacante, por exemplo).
Aliás, você já deve ter percebido que o momento inicial de um incidente de segurança 
está intimamente ligado com essa quebra de controle de segurança. Conforme definição 
da ISO 27035 (2016), incidentes de segurança da informação ocorrem quando há uma 
violação da política de segurança da informação (PSI). A política, entre outras coisas, é 
8
9
responsável pela definição desses controles. Então, podemos inferir que não é possível 
pensarmos em responder a incidentes, e muito menos provermos uma investigação 
forense computacional, no curso da investigação de um incidente, sem que tenhamos 
esta base estabelecida numa organização. Dentre os principais objetivos e componentes 
textuais existentes em uma PSI, destacam-se (ISO/IEC 27001-1, 2013):
• Gerência de risco;
• Gerência de ativos;
• Gerência de recursos humanos;
• Segurança física;
• Comunicações e operações;
• Controle de acesso;
• Gerência de continuidade;
• Gerência de incidentes;
• Conformidades.
Observando os controles de segurança física, comunicações e controle de acesso, nor-
malmente associados ao momento inicial do incidente e que caracterizam a quebra da PSI, 
em especial, temos três tipos normalmente empregados (e respectivos exemplos):
• Controles técnicos lógicos
 » Acesso à rede;
 » Acesso remoto;
 » Acesso a sistemas;
 » Acesso à aplicação;
 » Controle de Malware;
 » Criptografia.
• Controles administrativos
 » Política de segurança;
 » Monitoramento e gerência de ativos;
 » Gerência de usuários;
 » Gerência de permissões.
• Controles físicos
 » Catracas;
 » Portas e gradis;
 » Sensores de presença;
 » Uniformes;
 » Paredes e divisões prediais.
9
UNIDADE 
Incidentes de Segurança e Violações
Neste cenário, conseguimos observar uma evolução nos passos e controles vistos até 
que tenhamos um incidente de segurança propriamente dito. Se considerarmos apenas 
a gestão de ativos e seu monitoramento, inicialmente temos o conceito de “evento de 
segurança da informação” com a indicação de possível quebra de controle de segurança 
da informação (ISO/IEC 27035-1, 2016) por meio de alertas e alarmes. Já quando se 
analisa o evento, sob a luz das diretrizes descritas na PSI, quanto ao comportamento 
aceitável da infraestrutura e seu uso, podemos classificar este evento como incidente de 
segurança da informação, na medida em que este tenha a característica de comprometer 
ou ameaçar a operação do negócio e a segurança da informação da organização descri-
ta na PSI (ISO/IEC 27035-1, 2016).
Entender essa diferença entre eventos de segurança e o incidente propriamen-
te dito também é importante para observar que muitos dos registros de alertas e 
alarmes poderão ser descartados pelo perito durante a investigação, por não serem 
considerados relevantes.
Resposta a Incidentes de Segurança da Informação
Agora que compreendemos o conceito de incidente, sua ligação com a PSI e eventos 
de segurança monitorados, é importante saber que TODOS os incidentes de segurança 
da informação devem ser respondidos. Note, no entanto, que o conceito de resposta 
pode mudar e que, a resposta em si, nem sempre é dada pela própria organização e 
seu time de resposta local. Vejamos como se dá essa relação entre o time de resposta 
a incidentes em um ambiente corporativo, considerando as fases genéricas de resposta 
a incidentes descritas pelo NIST (NIST SP-800-61, 2012) e os tipos de interações do 
time (Computer Security Incident Response Team – CSIRT). Considerando que todo 
o incidente deve ser respondido, a primeira observação a ser feita sobre o processo 
explica o tipo de resposta aplicável. Como aceita-se que um incidente está relacionado 
com um ativo, e este com um propósito ao negócio da organização, esta resposta se di-
ferencia, inicialmente, no aspecto de urgência dela. Para ativos impactados no incidente 
que refletem baixa nos níveis de acordo de serviço (SLA) ou representam a parada ou 
inacessibilidade de uma infraestrutura de TI, o tipo de resposta enquadra-se no que se 
convencionou chamar de “recuperação”, dada sua urgência. Neste tipo de resposta, 
o objetivo principal é retornar a operação aos seus níveis normais, habitualmente com 
foco em procedimentos de restauração de backup, imagens e snapshots de equipamen-
tos em seu estado funcional para o rápido retorno ao funcionamento dos serviços e sua 
conectividade com a infraestrutura. Com este foco, normalmente não há espaço para 
as atividades de investigação, normalmente atribuídas ao perito forense computacional.
Já o segundo tipo, conhecido como “erradicação”, tem o foco na identificação da 
causa raiz do incidente. Este, portanto, com essência no processo investigativo e de 
coleta de evidências, típicos da atuação do perito forense computacional. Nesta aborda-
gem, dedica-se mais tempo no “entendimento” do incidente. Dessa forma, pretende-se 
10
11
reunir informações suficientes não só para identificar a causa do incidente, mas suas 
características e sintomas percebidos na infraestrutura. Como principal vantagem, esta 
abordagem oferece a oportunidade para que se reveja os controles afetados e melhorias 
sejam implementadas. Com isso, nota-se uma tendência na diminuição daquele tipo de 
incidente, já que as correções foram implementadas no sentido de evitar a causa, e não 
somente na restauração do serviço, como na primeira abordagem. Normalmente, em 
empresas que podem segmentar suas equipes de CSIRT, observa-se o melhor das duas 
abordagens: tempo de retorno à normalidade dos serviços e tendência que incidentes do 
mesmo tipo não se repitam naquela infraestrutura.
Preparação Detecçãoe análise
Erradicação e
Recuperação
de Contenção
Atividade
pós-incidente
Figura 2 – Ilustração do fl uxo genérico de resposta a incidentes, segundo NIST
Fonte: Adaptado de NIST
Observando a Figura 2, é possível perceber que ambas as abordagens são depen-
dentes da fase de detecção e análise (percepção do evento de segurança e/ou incidente 
de segurança). As atividades de pós-incidente são majoritariamente relacionadas à 
abordagem de erradicação (ou mista), já que possibilita a investigação. Nesta abor-
dagem, fica evidente a possibilidade de “aprendizado” e realimentação do fluxo com 
contribuições e melhorias (ISO/IEC 27035-2, 2016). A fase de preparação, indicada 
como primeira no fluxo da figura, em verde, indica tanto a capacidade de resposta 
da equipe, dada sua característica de habilidades e competências de seus integrantes, 
quanto essa retroalimentação provida pela etapa de pós-incidente, ilustrada em azul. 
As duas fases centrais do fluxo genérico NIST, que caracterizam a resposta a incidente 
diretamente, podem ser vistas em três processos distintos: triagem, coordenação e 
resolução. Na etapa de triagem, é que ocorre, com base na documentação de escopo 
do time, o repasse para outro time de maior abrangência. Na etapa de comunicação, 
a notificação dos envolvidos. Na etapa de resolução, recupera-se o ativo ou erradica-se 
a causa do incidente. Atente para o fato de que nesse último processo é onde perde-se 
muito das evidências que seriam úteis ao perito forense computacional para sua inves-
tigação. Isso, porque ao recuperar um ativo, retornando-o a uma condição funcional, 
normalmente não são guardadas as informações de seu estado quando em falha.
11
UNIDADE 
Incidentes de Segurança e Violações
Tabela 1 – Processos de resposta a incidente
Triagem
Análise do reporte de 
incidente (relatório)
Interpretação do incidente, priorização e 
relacionamento com incidentes em curso.
Verificação Determinar se o incidente realmente ocorreu e se está incluído no escopo do CSIRT.
Coordenação
Categorização
Categorização da informação associada ao 
incidente e associação com a políticade acesso às 
informações.
Coordenação Notificação de envolvidos e feedback sobre ações tomadas.
Resolução
Erradicação Eliminação da causa do incidente de segurança da informação e seus efeitos nos ativos envolvidos.
Recuperação
Simples restauração dos ativos envolvidos à 
condição anterior ao incidente, recuperando seu 
estado funcional.
Fonte: NIST
Em uma visão de fases um pouco mais detalhada (ISO/IEC 27035-1, 2016), é possí-
vel observar uma subdivisão da primeira, segunda e terceira fases descritas pelo NIST, 
quando observados os processos descritos pela ISO 27035 (2016):
1. Preparação: preparação de documentação (política, escopo, procedimentos) e 
capacitação do time de respostas a incidentes;
2. Identificação: a notificação do incidente;
3. Avaliação: como responder ao incidente (equivalente ao tipo de resposta recu-
peração ou erradicação, ainda que não se utilizem esses termos na ISO);
4. Resposta: conter o incidente e proceder com a investigação e resolução;
5. Lições aprendidas: aprendizado gerado pela investigação.
Falando na capacidade do time de resposta e agora abordando um segundo aspecto 
no fluxo de respostas a incidentes, é importante perceber que, por vezes, o incidente 
não poderá ser respondido localmente devido ao desalinhamento do escopo do CSIRT 
e/ou capacitações de seus membros. Neste caso, como TODO incidente deve ser res-
pondido, ocorre o que chamamos de “repasse de incidente”.
Este repasse pode ocorrer, em um cenário corporativo, tanto internamente, com o 
envio do incidente para outro CSIRT com escopo mais abrangente (de uma filial para 
uma matriz ou de um CSIRT nacional para um internacional), como envolvendo outros 
atores externos no processo de resposta. Idealmente, esse repasse deve ocorrer por 
meio de mensagens padronizadas, facilitando a automação entre CSIRTs. Um exemplo 
12
13
prático, utilizando tags específicas para descrever incidentes no formato Extensible 
Markup Language-XML, é o IODEF (ENISA, 2014). Na Figura 4, abaixo, é possível 
observar as informações básicas de descrição do incidente nas tags da classe “Incident”. 
Outras, relacionadas à classificação do incidente e informações do processo de resposta, 
assim como anexos adicionais poderiam ser encaminhados também, respectivamente 
nas classes “Extended” e “Extended info”.
Incident
0.1
0.1
0.1
0.1
0.1
0..+
1..+
1..+
0..1
0..+
0..+
0..+
IncidentID
AlternativeID
RelatedActivity
DetectTime
StartTime
EndTime
ReportTime
Description
Assessment
Method
Contatc
EventData
History
AdditionalData
Figura 3 – Ilustração do formato de repasse/comunicação IODEF,
entre times de resposta a incidentes
Fonte: Adaptado de IETF
Um fluxo típico dessa comunicação e resposta envolvendo repasse e/ ou times mul-
tidisciplinares ocorre quando um fabricante toma parte. A Figura 5 mostra vários outros 
tipos de interação do CSIRT. Observando essas interações e segmentando os poten-
ciais envolvidos por tipo de envolvimento, podemos classificá-los da seguinte forma: 
a) agentes externos (empresas parceiras), outros CSIRTs ou pessoas de fora da organi-
zação; e b) agentes internos (o próprio CSIRT ou equipe multidisciplinar formada por 
seu comando). Já em relação ao envolvimento com o ativo, alvo do incidente, podemos 
separá-los em: a) donos da informação (owners); b) usuários (data-users) e c) custodiantes 
(data-custodiants). Os donos da informação normalmente são elencados em casos de 
incidente envolvendo um ativo de informação específico, cuja origem/produção pode 
ser rastreada para um usuário da rede. Os usuários são atores mais comuns, envolvidos 
de qualquer forma com o ativo alvo (inclusive clientes externos consumidores dos ativos 
afetados). Já os custodiantes são normalmente empresas parceiras externas, responsá-
veis temporárias pelo trânsito dos dados.
13
UNIDADE 
Incidentes de Segurança e Violações
Incident
Response
Team
Internet
Service
Providers
Other
Incident
Response
Customers,
Constituents,
& Media
Software & 
Support
Vendors
Law
Enforcement
Agencies
Incident
Reporters
Figura 4 – Representação da comunicação do CSIRT com
entidades externas para “repasse” do incidente
Fonte: Adaptado de NIST
Também é possível perceber que, em casos envolvendo investigação, não é raro que 
o time de resposta precise envolver especialistas de outras áreas ou empresas ligadas 
de alguma forma na composição do conjunto tecnológico que constitui o serviço de TI 
afetado. Nestes casos, embora não constitua um “repasse” do incidente, considera-se 
que não houve uma resposta direta pelo time que fez a descoberta do incidente.
O repasse de incidentes, quando realizado entre diferentes CSIRT, deve ser feito de modo a 
garantir propriedades de sigilo e garantia de autoria. É muito importante, ao receber uma 
mensagem proveniente de outro time de respostas a incidentes, ter a certeza de que ela 
partiu realmente dele e é idônea, pois irá gerar desdobramentos de trabalho no CSIRT de 
destino da mensagem. Já o aspecto de sigilo está relacionado ao processo de investigação 
propriamente dito, que por vezes envolve informações classificadas e não públicas. Um 
protocolo que sugere um formato de mensagens padronizado entre CSIRTs, muito utilizado 
na Europa e recomendado pela Agência Europeia para a Segurança das Redes e da Infor-
mação (ENISA), é o Incident Object Description Exchange Format (IODEF) descrito na (RFC 
5070) em sua versão original e (RFC 8274) em sua segunda versão. Mais detalhes sobre a 
estrutura de mensagem pode ser vista em: http://bit.ly/2WNEbKm e http://bit.ly/2WO7gW1.
Outro caso também ilustrado na imagem é a presença do time jurídico, muito impor-
tante em investigações que envolvam como objeto a ação de usuários de sistemas que 
precisem ser responsabilizados judicialmente em decorrência das ações e contravenções 
descobertas. Esta figura ainda ilustra a comunicação com colaboradores, como uma fonte 
manual de descoberta de incidentes. Este tipo de interação, mesmo que comum, com 
informações de aumento de latência (lentidão) ou de comportamento inesperado de siste-
mas e aplicações que ajudem a percepção de um incidente, não é a mais eficaz. Devido 
a inconsistências e imprecisão nos relatos e a incapacidade de localização específica do 
componente gerador da anomalia percebida pelos usuários, normalmente servem apenas 
como informação auxiliar, sendo a obtida automaticamente, dos próprios ativos monitora-
14
15
dos, a fonte principal para investigação (Ex. Logs de firewalls, proxies, IDSs, roteadores, 
switches, servidores, entre outros).
Aliás, logs de eventos são uma importante forma de obtenção de informação para 
investigação do incidente e evidência avaliada pelo perito forense computacional. 
Em sistemas de informação e redes de computadores, a consistência, sincronismo e, 
principalmente, a completude dessa fonte de informação é determinante para uma resposta 
a incidentes eficiente e eficaz (NIST SP-800-61, 2012). Perceba que em redes heterogêneas 
e complexas (diversos ativos), observar o comportamento de todos os elementos, além de 
tarefa exaustiva, é particularmente difícil se cada equipamento produzir seus alertas e 
avisos em um formato diferente. Ainda, se não houver uma fonte de sincronismo fixa e 
confiável, capaz de referenciar todos os logs ao mesmo instante de tempo. Pois dificulta a 
possibilidade do perito reconstituir os eventos em uma linha contínua do tempo, permitindo 
que a investigação consiga reconstruir os eventos que ocorreram imediatamente antes e 
depois do horário do incidente, propiciando o entendimento do ocorrido.
Neste sentido, uma boa prática de mercado é padronizar o conteúdo dos logs produ-
zidos pelos equipamentos da rede (Ex. Syslog), centralizar o envio para um repositório 
único, facilitando a análise, além de sincronizar todos os equipamentos (Ex. Usando fonte 
de Network Time Protocol – NTP externa no sincronismo dos relógios de todos os ativos 
de rede).
Facility Severity
(0-7)
MnemonicMessage TextTimestamp
%SYS-5-CONFIG_I: Con�gured from Console by Console00:30:39
%SYS 5 CONFIG_I:
Figura 5 – Protocolo Syslog. Exemplo de envio de evento de confi guração de um switch na rede 
Fonte: Adaptado de Cisco press
O protocolo Syslog, definido pela IETF na RFC5424, com sua última atualização em 2009, 
descreve um formato de comunicação para envio de notificações e eventos por dispositi-
vos de rede para um repositório centralizado. Seu header (cabeçalho) possui 7 informações 
principais que identificam o ativo e evento. Mais detalhes sobre a estrutura de mensagem 
podem ser vista em: http://bit.ly/2WRVN7I.
Investigação Forense Computacional
A investigação forense computacional difere da investigação forense geral em razão 
das mídias onde as evidências de investigação se encontram. Enquanto um perito foren-
se criminal visita cenas de crimes, por exemplo, para obter suas evidências na investiga-
ção, um perito forense computacional obtêm suas evidências na investigação em redes 
15
UNIDADE 
Incidentes de Segurança e Violações
de computadores ou sistemas computacionais isolados. Segundo a ISO 21043-1 (2018), 
o processo forense de investigação inclui um conjunto de atividades, métodos e proces-
sos usados para obtenção de conclusões e opiniões por meio de investigação, podendo 
ser requerido por processos legais.
Você percebeu, a partir da caracterização na introdução desta unidade, que esse tra-
balho e, eventualmente, a solicitação para suplementação de processos legais, se inicia 
no meio do processo de resposta a incidentes, em um tipo de resposta que envolve a 
investigação. Esta conceituação foi feita para fins de ilustração e também por ser o fluxo 
comum de acionamento do perito. Porém, não há um impeditivo conceitual que limite 
a ação do perito somente atrelada a um incidente. Mais especificamente, este tipo de 
profissional é requerido quando há necessidade de produção de provas que sustentarão 
um processo judicial que pode ter como ator executor um funcionário, um parceiro, ou 
mesmo um desconhecido (atacante). O benefício ou objetivo desta atividade, portanto, 
é a coleta de evidências computacionais, por meio de técnicas especializadas. A impor-
tância da atuação do perito forense computacional está também no estabelecimento de 
uma ponte entre o profissional de direito e o profissional de TI, que domina o ambiente 
computacional sob investigação, no que tange o aspecto técnico. Como interlocutor, 
desempenha um papel relevante na rede interorganizacional de segurança pública e 
justiça criminal, onde suas habilidades técnicas são um diferencial e servem para facilitar 
a interpretação e entendimento das provas.
Essas técnicas, assim como a necessidade de conhecer tecnologias legadas e contem-
porâneas, a diversidade de aplicativos e a heterogenia de sistemas operacionais (SOs) 
em redes e sistemas investigados fazem desse profissional um recurso de difícil acesso, 
já que não existem muitos, e existe potencial para sua rápida desatualização e desquali-
ficação para as tarefas. Considerando que este profissional atua tanto em investigações 
corporativas quanto no âmbito privado, sua ação de investigação pode ocorrer tanto em 
auditorias externas contratadas (quando este não fizer parte do quadro funcional) como 
em investigações internas.
Observando a limitação imposta pela quantidade de profissionais disponíveis no mer-
cado, dada a demanda por qualificação em sua atividade, de maneira geral, o mais co-
mum é a contratação do perito de forma externa. Seja quando a parte interessada deseja 
produzir provas para subsídios de decisão judicial em casos envolvendo incidentes de 
segurança da informação, seja quando o juiz ao observar os elementos do caso, nomeia 
um perito para que apresente evidências de sustentação ou refutação ao caso.
No segundo caso, o juiz pode recorrer a bancos de informação que listam profissio-
nais disponíveis no mercado, normalmente concentrados nos próprios fóruns ou em 
associações de classe (Ex.: APEJESP http://bit.ly/2WRVVUK), escolher um perito que 
julgue adequado e estabelecer prazo para apresentação do laudo produzido por ele. 
Para qualificação e ingresso na lista, demonstra-se a capacidade técnico-científica do 
perito, seja por meio de certificações com acreditação nacional ou comprovações de 
educação formal, seja por demonstração de capacidade técnica em casos similares.
Essa segunda forma de demonstração de capacidade pode ser observada por meios 
diversos, exemplos comuns são publicações técnicas de autoria do perito, ou pela com-
16
17
provação de histórico de investigações durante a resposta a incidentes corporativos que 
demonstre a capacidade do perito em realizar laudos conclusivos, explicativos aos leigos 
e bem fundamentados tecnicamente.
Como visto na Figura 7, sua contribuição ocorre entre as fases de instrução e jul-
gamento do caso. Mais especificamente, na produção de provas materiais (TOLEDO; 
RODRIGUES, 2017). Os artefatos, como são chamados os componentes das provas 
materiais, no caso da perícia forense computacional, são quase sempre arquivos conti-
dos nos computadores ou servidores analisados, assim como sua representação, quando 
existentes apenas em memória RAM nestes ativos. Também são comumente anexadas 
evidências de comunicação de rede, como logs de servidores, proxies, firewalls e ro-
teadores, além de rastreamentos de endereços Internet Protocol (IP) em suas versões 
4 e 6, que podem ser solicitadas às operadoras de telecomunicações ou provedores de 
Internet, envolvidos no processo de comunicação. Desta forma, os artefatos colhidos 
e examinados pelo perito podem auxiliar tanto na localização dos envolvidos (inclusi-
ve geoespacial), como na definição do fluxo da informação sob análise. É importante 
lembrar, no entanto, que esse rastreamento precisa ser atrelado a alguma forma de 
ligação mais direta com o usuário responsável pela ação. Cruzamentos de informações, 
considerando várias evidências, são necessários para este fim, em especial tratando-se 
de investigações que usam a Internet como meio de comunicação. Isto, porque, como 
sabemos, o uso dessa rede ocorre de forma anônima.
Já na fase de julgamento, o perito pode atuar novamente prestando esclarecimentos 
técnicos acerca de seus relatórios e laudo, assim como na interpretação das evidências.
Perícia Criminal
1. Examina cena
do crime
2. Exames 
laboratoriais e/ou
especializados
3. Laudo pericial
Evento:
Infração penal
que deixa
vestígio
Polícia Militar: ou
Rodoviária:
1. Atende o local
2. Isola o local
3. Aciona a Polícia Civil
4. Elabora um BO
Ministério Público
de posse do IP:
Arquiva ou
pede novas diligências
ou denuncia
Perícia
criminal
4. Esclare-
cimentos
em juízo
Setença
do
Juiz
Recursos Setença
Final
Instrução processual
Acusação (promotor)
x
Defesa (advogado ou
defensor público) provas do IP
são refeitas, exceto algumas, 
entre elas a perícia
do local de crime
Polícia
Civil
1. Preserva
o local
2. Requisita 
a perícia
Ciclo policial
Ciclo judicial
Ciclo policial e judicial
Polícia
Civil
3. Investiga
4. Produz o
inquérito
policial
Laudo pericial dá suporte à investigação policial, à denúncia do
promotor de justiça, à instrução processual e à sentença do juiz.
Figura 6 – Representação da contribuição do perito forense computacional,
em um fl uxo genérico de obtenção de provas em um processo jurídico 
Fonte: Adaptado de Toledo; Rodrigues, 2017
17
UNIDADE 
Incidentes de Segurança e Violações
Segundo a determinação contida atualmente no Código de Processo Civil (CPC), 
para contribuir com a isenção e diminuição de viés, um juiz deve selecionar diferentes 
profissionais em suas solicitações. Isto acaba contribuindo para uma certa “rotatividade” 
dos profissionais atuantes e, também, abre portas para que novos peritos se inscrevam 
nesses bancos para ofertarem seus serviços.
O trabalho do perito é, normalmente, realizado de forma individual, ainda que seja 
comum que um notário, com fépública, acompanhe os trabalhos de coleta e exame de 
evidências, de forma a demonstrar a lisura no procedimento realizado. Contudo, não há 
nenhum impedimento textual no CPC que impeça a condução da perícia por mais de 
um perito forense computacional.
Certificações de mercado, com acreditação internacional, para os profissionais de pe-
rícia forense computacional, são emitidas considerando comprovação de experiência do 
técnico e/ou com a prestação de exame de conhecimentos. Como vimos, elas servem 
de comprovação da capacidade do perito. Alguns exemplos das certificações podem ser 
vistas na Tabela 1:
Tabela 1 – Lista de certifi cações internacionais que atestam
capacidade técnica do perito forense computacional
Certificação Emissor
Global Information Assurance
Certification Forensic Examiner (GCFE)
SANS – sans.org
Global Information Assurance
Certification Forensic Analyst (GCFA)
GIAC Network Forensic Analyst (GNFA)
GIAC Advanced Smartphone
Forensics (GASF)
Certified Information
Systems Auditor ISACA – isaca.org
Certified Forensic Computer
Examiner (CFCE) IACIS - iacis.com
EnCase Certified Engineer (EnCE) OpenText – opentext.com
AccessData Certified Examiner (ACE) AccessData – accessdata.com
Na tabela acima, as duas últimas certificações citadas são ofertadas por fabricantes 
dos produtos/ferramentas usadas durante a perícia forense computacional. São, por-
tanto, consideradas certificações “não neutras”. As certificações não neutras, como são 
específicas de um determinado produto, atestam a capacidade de operá-lo e não, neces-
sariamente, do domínio das capacidades técnico-científicas exigidas para o perito.
Principais atividades e habilidades
Nas certificações e comprovações de habilidades para a atuação como perito, os 
profissionais demonstram capacidade de:
• Localizar e examinar dados em memória;
• Localizar e examinar dados em sistemas de arquivo diversos;
18
19
• Localizar e examinar dados em mensagens de protocolos diversos transmitidos em 
redes e links;
• Engenharia reversa e exame de códigos executáveis.
Observando o caráter comportamental e integridade exigidas desse profissional, cabe 
também ressaltar a necessidade de um perfil ético, dada sua responsabilidade e confiança 
depositada na isenção e objetividade de seu trabalho. Ainda que não haja, no presente mo-
mento, um código de ética específico para peritos forenses computacionais, a maioria das 
certificações profissionais citadas, quando caracterizando seu perfil técnico, já contemplam 
um código de conduta. Além disso, de forma mais geral e observando que grande parte de 
sua atuação se dá em função de demandas criminais, há um código de ética descrito pela 
ASSOCIAÇÃO BRASILEIRA DE CRIMINALÍSTICA que cabe também a este profissional:
• A formação de uma consciência profissional no ambiente de trabalho e fora dele;
• A responsabilidade pelos atos praticados na esfera administrativa, assim como 
na Judicial;
• O resguardo do sigilo profissional;
• A colaboração com as autoridades constituídas, dentro dos limites de suas atribui-
ções e competência do órgão onde trabalha;
• O zelo pela dignidade da função, pela defesa dos postulados da criminalística e 
pelos objetivos das Associações de classe a que pertença ou não;
• A liberdade de convicção para formalizar suas conclusões técnico-científicas em 
torna da análise do(s) fato(s), objeto das perícias, sem contudo infringir os precei-
tos de ordem moral e legal, de modo a ser obrigado a desprezar tais conclusões.
Caracterizando a atuação em auditorias, a exemplo das auditorias convencionais de 
TI e SI, temos três tipos de participação do perito:
• Interna: quando o perito é um colaborador da organização e possui as qualifica-
ções técnicas para a coleta e exame de evidências.
• Externa: quando o perito é contratado externamente, de um banco.
• Combinada: quando a perícia é efetuada por um perito externo com o acompa-
nhamento de um técnico da parte interessada.
Desde a coleta até a apresentação das evidências, em forma de laudo técnico e con-
clusões (texto para leigos), o perito executa uma série de atividades durante a auditoria:
• Identificação: Incidente que demanda investigação;
• Preservação: Passos para manter a integridade da evidência;
• Coleta: Processos e mídias usados para coletar dados relacionados à investigação;
• Examinação: Uso de ferramentas para examinar os dados relacionados com a 
investigação. Uma subtarefa comum neste ponto é a reconstrução dos passos do 
atacante, por exemplo;
• Análise: Conclusões baseadas na investigação;
• Apresentação: Relatórios e laudo com apresentações formais resultantes do pro-
cesso de investigação.
19
UNIDADE 
Incidentes de Segurança e Violações
Note que o processo de preservação é elencado antes da coleta. Detalharemos mais 
o processo na próxima unidade, mas, por hora, note que esse processo merece es-
pecial atenção. Encontra-se antes mesmo da coleta a ser realizada, pois demanda um 
processo de preparação e planejamento anterior, para garantir que a evidência não 
seja comprometida e/ou questionada, quando esta fizer parte de um processo em juízo. 
Comprometida, pois existem vários fatores técnicos que podem interferir com sua “fide-
lidade” ao representar o objeto observado. Questionada, pois caso o processo não seja 
suficientemente documentado e provido de garantias de integridade, essa informação 
será questionada pela contraparte ou pelo próprio juiz, invalidando-a como suplemento 
do processo. Na próxima unidade, veremos um processo chamado “cadeia de custódia”, 
relacionado a essa garantia de preservação da evidência. Na ISO 21043 (2018), que dita 
procedimentos para coleta e análise da evidência nos diversos documentos da série, os 
três processos iniciais têm atenção especial a essa garantia de preservação: controle do 
ambiente sob investigação, exame e coleta de evidências, e armazenamento e transpor-
te de evidências. Já os processos seguintes, de análise da evidência, interpretação dos 
achados e produção de relatório e laudo, são relacionados a capacidade de extração de 
significado dos artefatos coletados. Na análise da evidência, é comum o uso de ferra-
mentas específicas com o papel de decodificação e/ou renderização do conteúdo, que 
por vezes não é inteligível. Na fase de interpretação, o conteúdo é colocado no contexto 
dos eventos relacionados ao incidente, com o objetivo de tentar “reconstruir” o histórico 
de ações/intercorrências geradas nos ativos de rede envolvidos.
Controle de cena
Re
qu
isi
to
s g
er
ai
s /
 p
rin
cíp
io
s
IS
O 
21
04
3-
1
IS
O 
21
04
3-
2:
 Cl
áu
su
la
 5
ISO 21043-2:
Cláusula 6
ISO 21043-2:
Cláusulas 7 e 8
ISO 21043-2:
Cláusula 9
ISO 21043-2:
Cláusulas 7 e 8
ISO 21043-2:
Cláusula 10
ISO 21043-3:
em desenvolvimento
ISO 21043-4:
em desenvolvimento
ISO 21043-5:
em desenvolvimento
Exame de cena e gravação
Coleta de itens e transporte
Análise
Interpretação
Relatórios
Figura 7 – Referências de cláusulas e normas relacionadas às atividades realizadas em auditoria
Fonte: Adaptado de ISO 21043
20
21
Além da capacitação técnica do profissional, a atuação forense computacional de-
pende de recursos laboratoriais e ferramental adequado para a execução da atividade 
de forma confiável e sem dar margem a questionamentos. No Brasil, ainda não, mas na 
Inglaterra e Alemanha, já há requisitos para a atuação profissional em perícias, solici-
tando a apresentação de atestado de calibração e condições técnicas do ferramental e/
ou laboratório (quando aplicável) usado na coleta e análise de evidências (ISO 17025, 
2017). Ao contrário das certificações profissionais, citadas anteriormente, esta certifica 
o ambiente de trabalho e ferramental do perito.
Nesta unidade, falamos sobre incidentes de segurança da informação como uma ponte 
para entendermos o início da atividade do perito forense, no contexto corporativo. Nesta 
abordagem, diferenciamos alertas e eventos de segurança do incidente propriamente dito 
e estudamosos tipos de respostas provenientes das duas abordagens básicas de um CSIRT, 
baseada em recuperação ou erradicação. Observamos características de comportamento 
e perfil técnico necessários para a atividade do perito forense computacional, assim como 
exemplos típicos de sua atuação. Concluímos com essa unidade uma visão do papel do 
perito, com uma introdução de elementos de investigação importantes que devem ser con-
siderados durante a coleta e análise de evidências computacionais.
Esperamos que tenha gostado e adquirido esses novos conhecimentos.
21
UNIDADE 
Incidentes de Segurança e Violações
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Livros
Perícia Forense aplicada à Informática
FREITAS, AR. Perícia Forense aplicada à Informática. 1 ed. São Paulo: Brasport, 2006. 
Resposta a Incidentes de Segurança em Computadores: Planos para Proteção de Informação 
em Risco
McCARTHY, NK. Resposta a Incidentes de Segurança em Computadores: Planos 
para Proteção de Informação em Risco. 1 ed. Porto Alegre: Bookman Editora, 2014. 
 Vídeos
How to Conduct Efficient Examinations with EnCase Forensic 8 06
https://youtu.be/dz6-QI5ActQ
Computação Forense e a Carreira de Perito - Gilberto Sudré
https://youtu.be/Q2mfTZs0LKk
22
23
Referências
ENISA. Detect, SHARE, Protect. Solutions for Improving Threat Data Exchange 
among CERTs. 1 ed. European Union Agency for Network and Information Security 
(ENISA), 2013. 
ENISA. Standards and tools for exchange and processing of actionable informa-
tion. 1 ed. European Union Agency for Network and Information Security (ENISA), 2014. 
ISO/IEC 17025:2017. General requirements for the competence of testing and 
calibration laboratories. 3 ed. ISO/IEC, 2017. 
ISO/IEC 21043-1:2018. Forensic sciences -- Part 1: Terms and definitions. 1 ed. 
ISO/IEC, 2018. 
ISO/IEC 27001-1:2013. Information technology – Security techniques - Informa-
tion security management systems - Requirements. 2 ed. ISO/IEC, 2013. 
ISO/IEC 27035-1:2016. Information technology — Security techniques — Infor-
mation security incident management – Principles of security incident manage-
ment. 1 ed. ISO/IEC, 2016. 
ISO/IEC 27035-2:2016. Information technology — Security techniques — Infor-
mation security incident management - Guidelines to plan and prepare for inci-
dent response. 1 ed. ISO/IEC, 2016. 
NIST SP-800-61. Computer Security Incident Handling Guide. Recommendations of 
the National Institute of Standards and Technology. 2 ed. U.S. Department of 
Commerce, 2012. 
SÊMOLA, M. Gestão da segurança da informação: uma visão executiva. 2 ed. Rio 
de Janeiro: Elsevier, 2014. 
TOLEDO JC, RODRIGUES CV. A value based method for measuring performance 
on Forensic Science service. Gest. Prod., São Carlos, v. 24, n. 3, p. 538-556, 2017.
23