CENTRO DE CIBERSEGURIDAD INDUSTRIAL

BUENAS PRÁCTICAS EN EL
ANÁLISIS FORENSE DE SISTEMAS
DE AUTOMATIZACIÓN Y CONTROL
INDUSTRIAL
Consejos
Alt+flecha izquierda para volver a la vista anterior después de ir a un hipervínculo
Haz click en nuestro icono y visita nuestra web
Patrocinadores del CCI
Platinum

Gold

Silver

Bronze
Primera edición: septiembre 2016
ISBN: 978-84-945412-1-6

Cualquier forma de reproducción, distribución, comunicación pública o transformación de esta obra queda
rigurosamente prohibida y estará sometida a las sanciones establecidas por la ley. Solamente el autor (Centro de
Ciberseguridad Industrial, www.cci-es.org), puede autorizar la fotocopia o el escaneado de algún fragmento a las
personas que estén interesadas en ello.
El Centro de Ciberseguridad Industrial (CCI) es una organización independiente, sin ánimo de lucro,
cuya misión es impulsar y contribuir a la mejora de la Ciberseguridad Industrial, en un contexto en el que las
organizaciones de sectores como el de fabricación o el energético juegan un papel crítico en la construcción de la
Sociedad actual, como puntales del estado del bienestar.
CCI afronta ese reto mediante el desarrollo de actividades de investigación y análisis, generación de opinión,
elaboración y publicación de estudios y herramientas, e intercambio de información y conocimiento, sobre la influencia,
tanto de las tecnologías, incluidos sus procesos y prácticas, como de los individuos, en lo relativo a los riesgos -y su
gestión- derivados de la integración de los procesos e infraestructuras industriales en el Ciberespacio.
CCI es, hoy, el ecosistema y el punto de encuentro de las entidades -privadas y públicas- y de los profesionales
afectados, preocupados u ocupados de la Ciberseguridad Industrial; y es, asimismo, la referencia hispanohablante
para el intercambio de experiencias y la dinamización de los sectores involucrados en este ámbito.

 Maiquez, 18 · 28009 MADRID

 +34 910 910 751
 info@CCI-es.org
 www.CCI-es.org
 blog.CCI-es.org
 @info_CCI
Tabla de
figuras
›› FIGURA 1. PIRÁMIDE DE AUTOMATIZACIÓN INDUSTRIAL 14
›› FIGURA 2. NIVEL DE PERSISTENCIA DE LOS DATOS 17
›› FIGURA 3. FASES DEL ANÁLISIS FORENSE DE RED 21
›› FIGURA 4. ZONA DESMILITARIZADA (DMZ) 22
›› FIGURA 5. DMZ TÍPICA 27
›› FIGURA 6. UBICACIÓN EN LA RED DE LA HERRAMIENTA DE GESTIÓN SIEM Y LOG DE EVENTOS 31
 Tabla de
contenidos
0 PRÓLOGO
8

1 12
CONCEPTOS FUNDAMENTALES

2 26
ANÁLISIS FORENSE EN TECNOLOGÍAS DE OPERACIÓN

3 56
EL INFORME PERICIAL TECNOLÓGICO

4 62
GLOSARIO

5 64
REFERENCIAS Y DIRECCIONES DE INTERÉS

6 68
AUTORES+COLABORADORES
0
Prólogo
Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 9
 Conviene recordar que el término “forense” tiene
su origen en el posesivo latino “forensis”, es decir,
“perteneciente al foro o a la plaza pública”, lugar
donde, en la época romana, se celebraban los juicios.
Unos juicios a los que, hoy, dedicamos unos nuevos
espacios, los palacios de justicia; pero en los que,
como entonces, tiene voz quien ha de asistir en
el marco de la actuación judicial por su pericia en
disciplinas como, tradicionalmente, la Medicina Legal;
o, en tiempos más recientes, la Informática. Se trata,
como ya habrá adivinado, de la función del “experto
pericial”, cuyo análisis de los hechos contribuirán a
determinar las causas que los han provocado.
En ese contexto, este documento tiene como objetivo
proporcionar una guía de buenas prácticas para el
análisis forense de la Informática Industrial, que sirva
de ayuda a presentes y futuros peritos. Se tratará, por
tanto, de un análisis forense centrado en los sistemas
de automatización y control industrial, tal y como
recoge su título.
Los orígenes del análisis forense informático se
remontan a 1984, cuando el FBI y otras agencias
de la administración estadounidense comenzaron
a desarrollar programas para analizar evidencias
digitales. Tuvieron que pasar más de 10 años, para que
en 1995 se constituyese la Organización Internacional
sobre Evidencias Informáticas (IOCE, International
Organization on Computer Evidence) que ha impulsado
el análisis forense informático hasta convertirlo en la
disciplina imprescindible que es hoy en día.
Aunque el análisis forense informático, o digital,
cuenta en la actualidad con profesionales cualificados
y reconocidos, se debe ser muy consciente de la
Prólogo

evolución y extensión de la tecnología, las cuales
dificultan la tarea del “experto pericial”, cuyos
conocimientos no pueden abarcar la diversidad
tecnológica actual. La tecnología incorporada a los
medios de transporte, a la distribución de servicios
como el agua, la electricidad o el gas, o la que
interviene en la automatización de una fábrica difiere
de la tecnología de los sistemas de información
corporativos e, incluso, de los sistemas que hoy
se alojan en la nube. Por esta razón se deberían
establecer especialidades en el análisis forense
informático. Como ya se ha apuntado, esta guía
está especializada en el análisis forense informático
industrial y ayudará a todo aquel profesional que
necesite investigar evidencias en las tecnologías de
operación de un entorno industrial, es decir, en los
sistemas que automatizan y controlan los procesos
físicos de una infraestructura industrial.
Puede afirmarse, sin temor a error, que la guía
“Recommended Practice: Creating Cyber Forensics
Plans for Control Systems”, escrita por Mark Fabro
y Eric Cornelius, y publicada por la National Cyber
Security Division del DHS estadounidense en 2008,
fue la primera que, de forma destacada, abordó el
análisis forense en sistemas de control industrial.
La guía Fabro-Cornelius se dirigía a profesionales
que necesitasen desarrollar un plan de gestión
de incidentes en sistemas de control industrial y,
como parte de aquel, hubiesen de contemplar el
análisis forense. Ocho años después, el Centro de
Ciberseguridad Industrial le acerca una nueva guía
con la intención de cubrir las necesidades, no sólo
de aquellos profesionales que tienen que gestionar
incidentes ocurridos en las tecnologías de operación
Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 11
de determinadas instalaciones industriales, sino,
también, las de quienes deben prestar su asistencia
en el marco de actuaciones judiciales concretas.
Para ello, se ha estructurado el documento en tres
bloques principales: el primero de ellos recoge los
conceptos fundamentales del análisis forense, como
son la tipología de delitos, las características de la
evidencia digital y la cadena de custodia, conceptos
imprescindibles del proceso judicial. El segundo bloque
es de naturaleza más técnica (tecnológica) y refleja
las dificultades, metodología y herramientas de uso
común para el análisis forense en el entorno industrial.
Finalmente, el tercero proporciona recomendaciones
sobre cómo elaborar y comunicar el informe pericial.
En la redacción de esta guía han participado ocho
miembros del Programa de Expertos del Centro de
Ciberseguridad Industrial, conformando un equipo
multidisciplinar, lo que ha permitido aprovechar
los conocimientos y experiencias de cada uno de
ellos, que han quedado recogidos en los diferentes
apartados del documento. Es, asimismo, imperativo
destacar, y agradecer, la desinteresada participación de
un notable número de profesionales de “El Ecosistema
CCI”, y otros expertos externos al Centro, en la revisión
del documento, y a cuyo reconocimiento está dedicada
la sección final “Autores+Colaboradores”.
A buen seguro, las contribuciones y críticas de todos
ellos, habrán hecho de esta guía una útil herramienta
que no hará sino afianzar los conocimientos
especializados en materia de sistemas de
automatización y control industrial de cuantos analistas
forenses decidan tenerla en sus manos.
Equipo directivo, CCI
 1
Conceptos
fundamentales
 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 13

CONTENIDOS

EL ANÁLISIS FORENSE
EL PERITO
TERMINOLOGÍA JURÍDICA BÁSICA
TIPOLOGÍA DE DELITOS TECNOLÓGICOS
LA EVIDENCIA ELECTRÓNICA Y SUS CARACTERÍSTICAS
LA CADENA DE CUSTODIA

PERITAJE DE TECNOLOGÍAS DE OPERACIÓN

ASPECTOS ESPECÍFICOS
Conceptos fundamentales
El análisis forense

EL ANÁLISIS FORENSE
El análisis forense informático es un conjunto de
técnicas y metodologías generalmente aceptadas
que tienen por objeto la obtención de evidencias con
valor probatorio. Las evidencias pueden acabar, como
medio de prueba, en un proceso judicial, ser usadas
internamente en las organizaciones para alimentar
su cuadro de mandos y ofrecer una imagen fiel de la
operación de los sistemas (proporcionando información
de valor para la conformidad, el control interno o la
auditoría) o pueden ser usadas en la investigación de
un incidente dentro de una compañía. ¿Qué ocurrió?,
¿Cómo ocurrió?, ¿Quiénes fueron los responsables?,
¿Cuándo ocurrió? son algunos de los interrogantes que
un profesional intentará responder.
El objetivo de este documento será ofrecer al lector
una herramienta que le permita evaluar la necesidad
de efectuar un análisis forense en ambientes
industriales y determinar los criterios que se deben
aplicar en el tratamiento de la evidencia electrónica
que se encuentra en sistemas críticos.
Es evidente que en infraestructuras industriales
críticas, como en otros entornos, el restablecimiento
de las operaciones es la máxima prioridad, pero
también, dentro de un ciclo de mejora continua, resulta
fundamental conocer lo ocurrido, aprender de los
errores y establecer medidas de mitigación para evitar
incidentes en el futuro. A tal fin, extraer, preservar y
analizar las evidencia electrónica permitirá realizar un
posterior análisis forense que ayude a comprender lo
ocurrido e identificar a los responsables.
Esta investigación, como se indica, está orientada
al establecimiento de la verdad material y puede
y debe realizarse pensando en la mejora continua
de los procesos de seguridad. Sin embargo, lo que
se considera en Derecho una fuente de prueba
(las evidencias electrónicas), en caso de querer
incorporarlo a un procedimiento judicial, ha de
realizarse en forma de medio de prueba admitido en
la ley procesal correspondiente. En este sentido y
para todos los órdenes jurisdiccionales, el "dictamen
pericial” no es el único, pero sí el más completo
medio de prueba en los conflictos que conllevan una
evidencia electrónica. Su utilización se justifica cuando
es necesario analizar aspectos técnicos relativos al
objeto del proceso que escapan a los conocimientos
exigibles al juzgador, teniendo en cuenta la disparidad
y complejidad de la actividad sometida a su
Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 15
enjuiciamiento en la sociedad de nuestra época y la
diversidad de las pretensiones que se deducen ante
los Tribunales.
El juez necesitaría de conocimientos enciclopédicos
y de un grado de experiencia que escapa de la
capacidad humana para la resolución de todos esos
conflictos. El deber cognoscitivo de éste, plasmado
en el aforismo "iura novit curia" (el juez conoce el
derecho), se centra en el ordenamiento jurídico,
pero no tiene porqué extenderse a dicha variedad
de conocimientos "científicos, artísticos, técnicos o
prácticos" (art. 335.1 de la Ley de Enjuiciamiento Civil,
LEC).
Por ello, la necesidad de suplir dichas lagunas
cognoscitivas hace de la pericial el medio de prueba
idóneo para el estudio de esos supuestos. Así lo
ha entendido la jurisprudencia que, respecto de
determinadas materias, ha llegado a afirmar su
carácter "esencial" para la resolución del proceso o su
"especial idoneidad" respecto de los distintos medios
de prueba, a los que complementa.
El análisis forense se configura como el proceso que
lleva a efecto el perito con la finalidad de averiguar lo
ocurrido. A tal fin, utiliza una metodología que aplica
sobre hechos, eventos o fuentes de prueba, que,
pasado por el tamiz del informe pericial, se convierten
en un medio de prueba presentable procesalmente.
Si bien las formalidades del informe pericial son
diferentes según su destino sea judicial o extrajudicial,
toda investigación ha de efectuarse como si su
finalidad última fuera ser presentado ante los
tribunales. Ello tiene especial trascendencia cuando
derechos fundamentales se encuentran afectados.
El análisis forense informático tradicional puede
dividirse, a grandes rasgos, en dos importantes grupos
de acción: La recolección de la evidencia electrónica y
el análisis propiamente dicho.
El primero de los grupos presupone un desafío
en entornos industriales, especialmente cuando
no es posible detener los equipos o procesos en
funcionamiento. Por esta razón en muchas situaciones
será necesario recolectar evidencia en vivo, es decir,
mientras el sistema se encuentra operando, aun
en condiciones provocadas por el incidente que
intentamos analizar.
Como se verá a lo largo de este documento, cuyo
16 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial
objetivo es ofrecer una guía de buenas prácticas en el
análisis forense en sistemas industriales, la calidad y
variedad de los incidentes que pueden producirse en
estos entornos es tan diversa que puede considerarse
que cada incidente es único, aun tratándose de la
misma infraestructura y equipamiento específico.
El perito
El profesional encargado de la recolección de evidencia
y su posterior análisis es el Analista Forense. Cuando
éste realiza su tarea en ámbitos judiciales su nombre
es perito Judicial.
Este perfil profesional tiene como objetivo principal
asesorar a la organización que ha sufrido un incidente
tecnológico (perito de parte), al juez, fiscal o abogados
respecto a temas relacionados con la informática, tras
analizar elementos (dispositivos, ficheros, datos) que
puedan constituir una prueba o indicio significativo
para la resolución de cualquier pleito para el que
el perito se haya requerido, aportando seguridad,
conocimientos y demostrando aquellos aspectos
tecnológicos que no están obligados a conocer
profesionales del ámbito empresarial, del derecho o
tribunales.
Para ejercer como perito judicial en algunos países
es indispensable disponer de una acreditación
otorgada por un organismo reconocido, asociación
y/o colegio profesional, que avale sus conocimientos
y su pericia. La acreditación, junto con la titulación
universitaria, le avalará como profesional experto con
amplios conocimientos en el ámbito informático y de
la legalidad, para avalar cualquier prueba o hecho que
pueda ser imputable como delito.
En la jurisprudencia, este perito tecnológico es un
profesional que nombra la autoridad del proceso, con
el fin de lograr que a través de sus conocimientos
técnicos y pericia pueda dictaminar de forma objetiva y
veraz sobre los hechos analizados.
La norma española UNE-EN 16775, define a los
Prestadores de Servicios Periciales (PSP) como aquel
“experto o grupo de expertos que proporcionan a sus
clientes servicios especializados basados en unos
conocimientos y cualificaciones apropiadas”. Indica
también esta norma que el PSP debe respetar la
independencia, imparcialidad, objetividad, integridad
y mantener la confidencialidad sobre los trabajos
periciales que le sean encomendados.
Terminología jurídica básica
Al interactuar judicialmente, el perito informático
deberá ser capaz de interpretar conceptos básicos del
Derecho, así como la terminología asociada al mismo
y los códigos de procedimiento que rigen la actividad
pericial en los distintos fueros y jurisdicciones. No es
suficiente con lograr un completo informe técnico,
sino que el mismo deberá ajustarse a las normas y
procedimientos legales.
A modo de ejemplo, en España, la Ley 1/2000, de 7
de enero, de Enjuiciamiento Civil (en adelante LEC)
define el dictamen de peritos en su art. 335.1 como
una actividad procesal mediante la cual una persona
o institución (art. 340.2) especialmente cualificada
suministra al juez argumentos o razones para la
formación de su convencimiento acerca de ciertos
datos controvertidos, cuya percepción o comprensión
escapa a las aptitudes comunes judiciales. Esta norma
establece las características de este medio de prueba
que, por lo general, será aportado por las partes
como documentos que acompañan a sus respectivos
escritos de demanda y contestación, o designado
por el Tribunal previa solicitud de parte, en los casos
previstos por la ley (art. 335.1). La LEC es subsidiaria
para otros órdenes judiciales como el laboral o, en lo
que respecta a la prueba pericial, también en el penal.
Este medio de prueba se regula en los arts. 335 a
352 LEC; si bien son, igualmente, de aplicación los
preceptos relativos a las normas comunes previstas
en los arts. 265 y ss., sobre la aportación de la
prueba documental; la abstención y recusación de
los peritos designados judicialmente (arts. 99, 100.2,
105 y 124-128); la comunicación con los peritos
(art. 159); la concurrencia del reconocimiento judicial
y el pericial (art. 356), testigo-perito (art. 370); los
relativos a la intervención de las partes respecto de
la pericial aportada o solicitada en la audiencia previa
del juicio ordinario (arts. 426.5, 427.2-4, 429.1 y 5);
el nombramiento y actuación del perito tasador para
la valoración de los bienes embargados (arts- 638 y
639); y el nombramiento del perito para el avalúo de
los bienes del caudal hereditario (arts. 783 y 784).
El estudio de su naturaleza jurídica dio lugar a un
amplio debate. Así, mientras que un sector de la
doctrina sostenía que se trataba de un auténtico medio
de prueba, otros entendían que era un medio ecléctico,
más próximo al juez pues tenía por misión fundamental
"auxiliarle" en los conocimientos específicos que

desconocía bajo las garantías de imparcialidad (pues el
perito se escogía por común acuerdo de las partes o al
azar -por insaculación-) y capacidad (en lo relativo a su
cualificación).
La LEC parte de la base de que las pericias realizadas
por los técnicos son, por lo general, aportadas al
proceso por las partes en la fase de alegaciones.
Resuelve, así, el anterior dilema acerca de su
naturaleza, y, muy especialmente, el aspecto de
la remuneración de los peritos, motivo que hacía
decaer el carácter "imparcial" del perito judicial. En la
actualidad, el dictamen pericial es un medio de prueba
más (art. 299.1 LEC) que habrá de ser detenidamente
valorado por el juzgador siendo el tribunal el único
competente para apreciar los dictámenes periciales
conforme a las reglas de la sana crítica, sin que esté
sometido a las conclusiones valorativas realizadas por
los técnicos. Del mismo modo, si duda acerca de la
verdad o falsedad del hecho jurídico controvertido y
apreciado por los peritos, debería resolver la incógnita
acudiendo a las normas de la carga material de la
prueba (art. 217.1 LEC) y no ordenando la práctica de
una prueba pericial judicial dirimente como diligencia
final, pues al hacerlo tiende a tergiversar el nuevo
sistema ya que parte de la errónea base de que el
perito judicialmente designado tiene un valor probatorio
superior al obtenido por las partes.
También la Ley de Enjuiciamiento Criminal (LECrim),
trata la figura del perito, sus actuaciones e informes,
por ejemplo, en los artículos 456 a 485, lo cuales
tratan sobre el informe pericial en el contexto de
la comprobación del delito y la averiguación del
delincuente.
Tipología de delitos tecnológicos
No hay una tipología específica de delitos tecnológicos,
considerándose en la mayoría de los casos el uso de
medios tecnológicos como el modo comisivo de delitos
preexistentes, habiendo algunos tipos o subtipos
agravados específicamente tecnológicos (como los
daños informáticos). Dicho esto, resulta igualmente
evidente que hoy hay delitos propios de este entorno
que no existían antes de que las tecnologías de la
información y las comunicaciones se encontraran
ampliamente extendidas.
Resulta oportuno, cuando se analiza un incidente
informático, valorar si el mismo pudiera ser constitutivo
de delito, para orientar de manera adecuada la
Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 17
investigación que se realice. Dicho esto, resulta
conveniente que toda investigación se efectúe desde
la asunción de que la misma va a ser sometida a la
crítica y la controversia de un proceso, usando los
más altos estándares éticos y las metodologías más
adecuadas para el caso en liza.
La ciberdelincuencia, por tanto, no designa a una
categoría concreta de conductas criminales sino que
nos sitúa ante una forma específica de llevar a cabo
el delito. Es un concepto de carácter transversal y que
afecta a múltiples bienes jurídicos.
La Criminalidad informática es un fenómeno en
expansión. La evolución tecnológica ha dado paso
a nuevos delitos y nuevas formas de ejecución de
los delitos, por lo que es necesario un ordenamiento
jurídico con capacidad de evolución que ofrezca
solución a las nuevas situaciones, así como un
esfuerzo de armonización con la legislación, pautas y
criterios asumidos internacionalmente dado el carácter
transnacional de estas conductas.
Dicho esto, cabe distinguir dos tipologías de delitos
genéricas:
››Nuevas formas de comisión de delitos tradicionales; y
››Delitos informáticos stricto sensu, como aquellos
relativos a la seguridad de los datos, programas y
sistemas.
Como ejemplo, en las últimas reformas del Código
Penal español se introducen nuevas figuras delictivas
o adecuación de los tipos penales ya existentes, para
ofrecer una respuesta más adecuada a las nuevas
formas de delincuencia. Por conducta delictiva, cabría
clasificar los delitos informáticos en los siguientes
grupos:
››Corrupción y pornografía de menores o
discapacitados. Childgrooming. (Art. 198 ter, 189)
››Conductas coactivas, intimidatorias o insultantes a
través de Internet. (Art. 169, 172 ter, 208)
››Delitos contra la intimidad: usurpación de identidad.
(Art. 197)
››Delitos contra la propiedad intelectual. (Art. 270)
››Allanamientos informáticos. (Art. 264)
››Ataques a datos y sistemas de información, en
concreto, los daños informáticos (Art. 264 y 264 bis
CP), el acceso ilegal a sistemas informáticos (Art.
197 bis. 1) y la interceptación de transmisiones no
públicas de datos (Art. 197 bis. 1).
18 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial
La evidencia electrónica y sus
características
En el caso de España, conforme a la norma UNE
71505-1-2013 Sistema de Gestión de Evidencias
Electrónicas (SGEE). Parte 1: Vocabulario y Principios
Generales, una evidencia electrónica es información en
forma electrónica de cualquier naturaleza, identificable
y susceptible de ser tratada de manera diferenciada,
y generada, tratada, gestionada y/o almacenada de
manera que se asegura su confiabilidad, completitud y
valor probatorio.
La norma distingue entre la evidencia y la evidencia
electrónica que define del siguiente modo:
››Evidencia: Es la demostración en un procedimiento
judicial de los hechos que fundamentan la aplicación
de requerimientos formales, procesales y/o legales.
››Evidencia electrónica: es aquella prueba electrónica
que cumple con los requerimientos formales,
procesales y/o legales que establezca, en cada caso,
el ordenamiento jurídico aplicable.
Una vez establecida la diferencia, y para todas las
evidencias, la Parte 2 de esta norma establece lo que
sigue en su Sección 3.1:
Una evidencia electrónica debería reflejar
correctamente lo que se hizo, comunicó o decidió
o la medida que se adoptó. Debería ser capaz de
satisfacer las necesidades de la organización a la
que está vinculada y poder ser utilizada para rendir
cuentas, con completa confiabilidad.
A tal fin, y además de su contenido, la evidencia
electrónica también debería incluir todos los datos
necesarios para documentar una determinada
operación tal y como se indica a continuación:
a) La estructura de una evidencia electrónica, es
decir, su formato y las relaciones existentes entre
los elementos que la integran, debería permanecer
intacta;
b) El contexto en el que la evidencia electrónica fue
creada, recibida y utilizada debería quedar patente
en la misma (incluido el proceso de negocio del
cual forma parte, la fecha y hora de realización, y
los participantes en la misma);
c) La vinculación existente entre evidencias, caso de
existir, debería permanecer siempre presente.
Una evidencia, dado su valor probatorio ha de ser
segura y confiable. La confiabilidad se basa en una
triple pareja de atributos, como se recogen en la
Sección 3.2 de la UNE 71505-2-2013:
Para conseguir que la información contenida en
los sistemas sea confiable, esto es, para alejar
la posibilidad de que se cuestione con éxito la
veracidad y la exactitud de lo custodiado, gestionado
y/o almacenado, es necesario basarse en sistemas,
procesos y procedimientos confiables, lo que implica
el cumplimiento de la siguiente triple pareja de
atributos:
a) Autenticidad e integridad;
b) Disponibilidad y completitud; y
c) Cumplimiento y gestión.
Autenticidad e integridad
La autenticidad e integridad de la información
custodiada garantiza la persistencia a lo largo
del tiempo de las características originales de la
información, el contexto, la estructura y el contenido.
Así se garantiza que la información no ha sufrido
alteración o modificación, así como que se genera
una certeza del autor o firmante de la información
y las circunstancias del contexto. En el caso de
provenir la información de una captura de otro
soporte o sistema, se debe garantizar la recogida
fidedigna de la información.
Las evidencias deben estar protegidas contra
modificaciones o añadidos no autorizados una vez
que se declaran en el Sistema de Gestión. Así,
las políticas y los procedimientos de gestión de
evidencias deben de especificar aspectos tales
como qué adiciones o anotaciones podrán realizarse
después de su incorporación, en qué circunstancias
podrán autorizarse y quién está autorizado para
llevarlas a cabo. Cualquier anotación, adición o
supresión autorizada que se realice debe indicarse
de forma explícita y dejar traza.
Una evidencia electrónica auténtica es aquélla de la
que se puede probar:
a) Que es lo que afirma ser;
b) Que ha sido creada o enviada por la persona de la
cual se afirma que la ha creado, almacenado y/o
enviado; y

c) Que ha sido creada, almacenada y/o enviada en el
momento en que se afirma.
Para garantizar la autenticidad de las evidencias
electrónicas, las organizaciones deberían definir,
diseñar, implantar, documentar, mantener y
gestionar las políticas, procedimientos, y el entorno
tecnológico, para el control de la creación, recepción,
transmisión, mantenimiento y eliminación de
evidencias electrónicas de manera que se asegure
que los creadores de los mismos estén autorizados e
identificados y que las evidencias electrónicas estén
protegidas frente a cualquier adición, supresión,
modificación, utilización u ocultación no autorizadas.
La integridad de una evidencia electrónica hace
referencia a su no alteración. Es necesario que
una evidencia electrónica esté protegida contra
modificaciones no autorizadas. Así pues, las
políticas y los procedimientos de gestión de
evidencias electrónicas deberán especificar qué
alteraciones o modificaciones pueden realizarse en
una evidencia electrónica después de su creación,
en qué circunstancias pueden autorizarse dichas
alteraciones o modificaciones y quién está autorizado
para llevarlas a cabo. Cualquier alteración,
modificación o supresión autorizada que se realice
en una evidencia electrónica debería indicarse de
forma explícita y dejar traza.
Disponibilidad y completitud
Una evidencia electrónica disponible es aquélla
que puede ser localizada, recuperada, presentada
e interpretada. Su presentación debería mostrar la
actividad u operación que lo produjo, en tiempo y
forma requerida.
La completitud de una evidencia electrónica es
aquella cualidad que responde a una representación
completa de las operaciones, las actividades o los
hechos de los que da testimonio y al que se puede
recurrir en el curso de posteriores operaciones o
actividades. Las evidencias electrónicas deberían
ser creadas en el momento, o poco después, en
que tiene lugar la operación o actividad que reflejan,
por individuos que dispongan de un conocimiento
directo de los hechos o automáticamente por los
sistemas que se usen habitualmente para realizar
las operaciones. Además, la propia evidencia deberá
de ponerse en contexto para un mayor y mejor
entendimiento de la misma.
Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 19
Las indicaciones sobre el contexto de las evidencias
electrónicas deberían contener la información
necesaria para la comprensión de las operaciones
que las crearon y usaron. Debería ser posible
identificar una evidencia electrónica en el contexto
amplio de las actividades y las funciones de la
organización. Con la finalidad de poner la evidencia
en contexto, se deberían mantener los vínculos
existentes entre las evidencias electrónicas que
reflejan una secuencia de actividades.
La disponibilidad y completitud proporcionan la
garantía de acceso y utilización, en los tiempos
requeridos y comprometidos, así como que aporta el
contexto total a la evidencia.
La disponibilidad individualmente considerada se
sustenta en la inteligibilidad y la recuperabilidad de
las evidencias. Ambas, por su parte, hacen referencia
a la recuperación de la evidencia y su reproducción
con las mismas características de cuando fue
registrada, estableciendo para ello las medidas
organizativas, tecnológicas y procedimentales que
fuesen necesarias. Así durante todo el tiempo que se
custodie la evidencia, para mantener la confiabilidad,
se deberá disponer del software, soportes, lectores,
y procedimientos correctos, teniendo especial celo
cuando por obsolescencia deban ser actualizados.
La disponibilidad se refiere a que las evidencias sean
accesibles, recuperables, representables y legibles.
Así por ejemplo, algunos documentos electrónicos,
que pueden ser usados como evidencias
electrónicas, son de conservación permanente y
por ello se debería garantizar un archivo de larga
duración.
Por otro lado, el contexto debe identificar los
procedimientos y controles aplicados a la evidencia
electrónica, en cada una de las etapas de su ciclo
de vida, así como las circunstancias que rodean las
acciones aportando información complementaria
para garantizar el valor de la evidencia.
Cumplimiento y gestión
Esta pareja proporciona la garantía de que la
evidencia obtenida es conforme a lo esperado al
haberse gestionado y utilizado los procedimientos
previamente planificados, siendo los mismos
exhaustivos, repetitivos, controlados, medibles y
auditables.
20 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial
La Organización debe poder ser capaz de demostrar
ante terceros que la evidencia electrónica, en todo
su ciclo de vida, ha sido generada y almacenada
conforme a lo descrito en sus políticas, normas y
procedimientos de actuación. Asimismo debería
garantizarse que el sistema sea auditable y que
las evidencias puedan ser analizadas por terceros
independientes. Por otro lado, el cumplimiento
también se refiere a la adecuación a la legislación
vigente y/ o normas sectoriales.
La Organización a través de un ciclo de mejora
continua, puede demostrar ante los grupos de
interés su grado de compromiso, a lo largo del
tiempo, con la veracidad y/o fehaciencia de la
evidencia.
Estos atributos sirven para cualquier evidencia con
independencia de la tecnología usada o del uso o
destino de la misma, y aseguran su autenticidad tanto
durante el ciclo de vida de la evidencia en los sistemas
como en el momento de su extracción.
El tratamiento de la evidencia (de cualquier tipo) debe
hacerse conservando la integridad de la misma y que
si por razones atendibles es necesario interactuar
con la misma, con el riesgo de producir efectos
irreversibles sobre la propia evidencia, se deberá
contar con la correspondiente autorización judicial y
además documentar claramente todos y cada uno de
los pasos ejecutados en el manejo y tratamiento de la
misma.
La cadena de custodia
Un aspecto clave en el transcurso de una investigación
relacionada con un incidente informático o tecnológico,
incluidos los sistemas industriales, es el de disponer
de evidencias electrónicas válidas. El perito deberá
garantizar la consistencia de tales evidencias durante
todo el proceso, desde el momento de la recopilación
de las pruebas hasta que finalice la investigación
forense o el proceso judicial. Así, al procedimiento de
control y documentación que garantiza la integridad de
las evidencias electrónicas se le denomina cadena de
custodia.
El objetivo de la cadena de custodia es el de garantizar
la indemnidad de la prueba, esto es, que permita el
análisis de la evidencia al mismo tiempo que impida la
alteración, sustitución, contaminación, degradación o
destrucción de la misma. En el marco de un proceso
judicial, cualquier indicio de que no se hubiere
respetado la cadena de custodia podría suponer
la invalidación de la prueba al no ofrecer ésta las
suficientes garantías de originalidad e integridad. A
diferencia de lo que sucede en otras especialidades del
peritaje, gracias al clonado de evidencias electrónicas
el analista forense informático puede evaluar las
pruebas trabajando sobre una copia idéntica del
original, lo que le permitirá realizar las labores
necesarias de investigación sin riesgo de alterar la
prueba original. Por supuesto, el proceso de clonado
formará parte de la cadena de custodia y no deberá
realizarse cuando pueda comprometer la integridad del
original.
Las recomendaciones de la RFC 3227 (Request for
Comments 3227) sobre “Recopilación y archivo de
evidencias” establecen unas actuaciones básicas para
la captura de evidencias, entre las cuales destacan las
de generar checksums (de tipo HASH, por ejemplo) y
firmar criptográficamente las pruebas con la finalidad
de preservar la cadena de custodia siempre, claro está,
que estas actuaciones no alteren la prueba.
La RFC 3227 dedica un breve apartado a la cadena
de custodia en el que se establece la necesidad de
documentar cualquier intervención realizada en torno a
la evidencia digital:
››Dónde, cuándo, por quién y cómo se han recopilado
las evidencias.
››Dónde, cuándo, por quién y cómo se han manipulado
o examinado las evidencias.
››Quién, durante cuánto tiempo y cómo se han
custodiado las evidencias.
››Cuándo, entre quiénes y cómo se han producido los
intercambios en la custodia de las evidencias.
Todas estas actuaciones permitirán acreditar ante
terceros (ya sean los órganos judiciales, la contraparte,
otros peritos, cuerpos policiales, etc.) que la prueba
no ha sido alterada en ningún momento, aunque más
importante, si cabe, es asegurar que la prueba objeto
de custodia es exactamente la misma que se incautó el
día de autos. En la reciente sentencia núm. 676/2016
del Tribunal Supremo español se señala, como ya
se había indicado en jurisprudencia anterior, que el
problema de la cadena de custodia es el de garantizar
que las pruebas presentadas a juicio son las mismas
que se recolectaron en su día, lo que en términos
jurídicos se denomina el principio de mismidad de
la prueba: «Se trata de garantizar que desde que se

recogen los vestigios relacionados con el delito hasta
que llegan a concretarse como pruebas en el momento
del juicio, aquello sobre lo que recaerá la contradicción
entre las partes y el juicio valorativo de los juzgadores,
es lo mismo que lo inicialmente incautado. Es a
través de la cadena de custodia como se satisface la
garantía de la "mismidad" de la prueba». Por ello el
perito deberá ser extremadamente prudente e iniciar
el procedimiento de cadena de custodia en el instante
previo a la recopilación de la evidencia.
En el apartado anterior ya se analizó la norma UNE
71505 “Sistema de gestión de Evidencias Electrónicas
(SGEE)” en cuanto a las buenas prácticas en la gestión
de evidencias electrónicas. Como complemento
a los procesos que conforman dicho sistema de
gestión la norma UNE 71506 “Metodología para
el análisis forense de las evidencias electrónicas”
tiene por objeto establecer una metodología para la
preservación, adquisición, documentación, análisis
y presentación de tales evidencias. En ella se define
la cadena de custodia como el “procedimiento de
trazabilidad controlado que se aplica a las evidencias,
desde su adquisición hasta su análisis y presentación
final, el cual tiene como fin no alterar la integridad y
autenticidad de las mismas, asegurando en todo este
proceso que los datos originales no son alterados”.
Aunque el proceso de cadena de custodia carece
de regulación legal en el ámbito procesal penal
español, la validez de la prueba se sustenta en las
buenas prácticas adoptadas por el perito y el resto
de intervinientes. En un proceso judicial, la obtención
ilegal de la prueba, la ruptura de la cadena de custodia
o cualquier indicio razonable de que la prueba ha sido
alterada, contaminada o manipulada puede dar lugar
a la impugnación de la prueba por la parte contraria.
Aun así, la exclusión de la prueba y, por extensión, del
informe pericial correspondiente, quedará supeditada
a la existencia de un sustento técnico que lo justifique,
como podría ser el examen de la prueba por parte de
otro perito o la elaboración de otro informe pericial por
la parte reclamante.
La cadena de custodia también es objeto de
tratamiento en la norma ISO/IEC 27037 “Directrices
para la identificación, recolección y/o adquisición y
preservación de evidencias digitales”. Según esta
norma la cadena de custodia debe permitir identificar
a todos aquellos que hubieran tenido acceso a
las pruebas en cualquier momento del proceso,
documentando fehacientemente nombre, fecha,
Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 21
hora, lugar y actuación realizada sobre la evidencia
custodiada.
La norma ISO/IEC 27037 establece dos tipos de
evidencias digitales: evidencias volátiles y evidencias
persistentes. Las evidencias volátiles son muy frágiles
y pueden desaparecer fácilmente, ya sea por una mala
praxis en la recolección de datos (por ejemplo, apagar
un equipo que está en marcha cuando las pruebas
están en la memoria temporal), así como por el simple
paso del tiempo, por ello es imprescindible definir un
orden de recolección de evidencias que respete el
orden de volatilidad de los datos. Entre las evidencias
volátiles a preservar se encuentran los procesos
en ejecución, los puertos y conexiones abiertas,
usuarios conectados, memoria caché, información
del portapapeles, etc. El perito encargado de recopilar
estas evidencias deberá poseer la capacidad técnica
suficiente para no alterar las pruebas durante el
proceso de recogida, manteniendo intacta la cadena
de custodia. Esta situación es especialmente relevante
en escenarios industriales donde existe gran variedad
de evidencias volátiles: el estado de una máquina, los
datos recogidos por sensores, señales enviadas a un
PLC o la captura de pantalla de un HMI entre otros.
Incorporar a la cadena de custodia información en
formato gráfico (fotografías, o incluso grabaciones en
video) será de gran apoyo para corroborar la validez del
proceso de obtención de la prueba.
Una preocupación subyacente en el proceso de
la cadena de custodia es el de no interferir en los
derechos fundamentales vinculados a la intimidad,
protección de datos o secreto de las comunicaciones
respecto a las evidencias tratadas. Si bien este
escenario es improbable en el análisis forense de
dispositivos industriales (dispositivos a nivel de red de
campo o de red de control) deberán tenerse en cuenta
tales circunstancias cuando se trate de dispositivos
de niveles superiores o pertenecientes al área de IT
(Tecnologías de la Información) como ordenadores
personales, estaciones de trabajo, smartphones,
tabletas, etc. En estos casos se requerirá el
consentimiento del titular o autorización judicial antes
de proceder con la recopilación de evidencias.
Conceptos fundamentales
Peritaje de Tecnologías de Operación
 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 23

PERITAJE DE TECNOLOGÍAS
DE OPERACIÓN
En este documento se establecen los criterios y
recomendaciones fundamentales en el peritaje OT NIVEL 4 Tecnologías de
(del inglés Operational Technology), tomando como de
Red ación
rm Información
Info (ERP)
base las del campo tecnológico más próximo de IT NIVEL 3
ación
per
(del inglés Information Technology), que ya tiene una NIVEL 2 Red
de O ES)
(M
n
Tecnologías de
Operación
isió
dilatada historia en peritajes tecnológicos en entornos NIVEL 1 d
erv
Sup MI)
de DA, H
Re (SCA
heterogéneos, y que en algunos casos pueden ser trol
NIVEL 0 Con
de aplicación al entorno de automatización y control de CS)
Red PLC, D
(
industrial. po
am ón)
e C aci
d d nt
Re trume
(Ins
En este documento se analizarán las particularidades
del peritaje OT, tanto por las limitaciones que nos
vamos a encontrar (p. ej, la dificultad o imposibilidad
de detener los sistemas de operación para realizar
las actuaciones periciales), como por las condiciones Figura 1: Pirámide de Automatización Industrial
especiales de los entornos de operación (p. ej,
limitación o incapacidad de almacenamiento de El peritaje tecnológico en sistemas de automatización
registros de operaciones “logs” en determinados y control industrial puede corresponderse con dos
equipos de campo), así como aquellas excepciones orientaciones:
que exijan un tratamiento especial frente a la
››Probatoria: Enfocada en demostrar la evidencia,
norma habitual del peritaje informático. Es por ello
por ello la captura y el tratamiento de la información
recomendable mantener siempre que sea posible
debe permitir documentar cada acción realizada
sistemas con redundancia de datos, permitiendo
con el objetivo de garantizar que lo observado
entregar uno de los sistemas de almacenamiento sin
pueda reproducirse evitando cualquier posible
afectar la operación del sistema completo.
contaminación y reduciendo así la posibilidad de
Las tecnologías empleadas en la automatización y repudio.
gestión de procesos productivos quedan representadas ››Investigativa: Enfocada exclusivamente en conocer
en la llamada ”Pirámide de Automatización", la cual los hechos ocurridos, su origen, la causa y su autoría,
recoge los cinco niveles tecnológicos que se pueden por consiguiente no se requieren precauciones para
encontrar en un entorno industrial. En el peritaje evitar la contaminación o el repudio. Un ejemplo
OT deberá contemplar también los sistemas de claro de esta orientación es la seguridad informática
información y comunicaciones de los niveles 3 y 4, centrada en el estudio de los sistemas informáticos
que se muestran en la figura, los cuales interactúan con el objetivo de proteger su confidencialidad,
con los niveles inferiores de la pirámide en un integridad y disponibilidad, para lo cual realizan
número importante de procesos industriales. Es actividades de diagnóstico de los sistemas con el
habitual encontrar, en los registros de estos sistemas, objetivo de conocer cual es su estado de salud e
evidencias que pueden permitir identificar aquellos identificar el origen, la causa y autoría de cualquier
sistemas OT de niveles inferiores que se han visto incidente.
afectados por el incidente objeto del análisis.
24 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial
El profesional de seguridad informática cuando por su
actividad se ve implicado en acciones de investigación
para demostrar hechos que pueden ser delictivos
podría estar “contaminado de necesidad” la evidencia
por su rol dentro de la organización. Este mismo hecho
si se produce en la auditoría de seguridad informática,
donde la habitual participación de auditores externos
constituye de facto una rasgo de independencia
actuando, por tanto, como garante de prueba.
El perfil del perito deberá contar con conocimientos
de los sistemas de información y de operación sobre
los que tenga que actuar, así como de las técnicas de
análisis forense. En aquellas situaciones en las cuales
el objetivo de su trabajo sea la presentación de hechos
en un litigio, tales conocimientos comprenderán la
legislación vigente en su jurisdicción, así como también
de la práctica procesal y sus reglas en cuanto a
formalidades en la presentación de su dictamen y los
plazos establecidos por los procedimientos legales.
Aspectos específicos
Es habitual, todavía hoy en día, que si un Sistemas
de Control Industrial (ICS, por sus siglas en inglés)
deja de funcionar correctamente, la prioridad del
ingeniero sea devolver el sistema a su estado de
funcionamiento habitual, y de la manera más rápida
posible para evitar mayores pérdidas económicas
para la empresa. Considerando la cantidad de
incidentes de seguridad intencionados a través de
malware, Amenazas Persistentes Avanzadas (APTs,
por sus siglas en inglés) o incluso en el marco de los
análisis de casos de ciberguerra y ciberterrorismo, las
consideraciones forenses en este entorno deberán
empezar a ser reconocidas en el corto plazo, con el
fin de entender si el ICS ha sido comprometido por
un fallo tecnológico u ocasionado por un actor hostil.
Asimismo, las empresas u organizaciones, como
también sus ingenieros deberán tener presentes los
conceptos de Due Care o Reasonable Care (que los
miembros de una empresa tomen todas las medidas
de protección razonables posibles) o el de Prudent
Man Rule (que los miembros de una organización
realicen aquellas acciones con diligencia y cuidado
como lo haría cualquier hombre prudente). El hecho
de poder detectar que se ha producido un incidente
de forma intencionada, ya sea aprovechando un
fallo tecnológico o un fallo de procedimiento (o hasta
incluso humano), permitirá en primer lugar identificar
y entender cómo se ha producido el compromiso, y en
segundo lugar, adoptar todas las medidas de control
directo o compensatorio para fortalecer el sistema de
control frente a posibles ataques similares en el futuro.
Existen determinadas limitaciones a la hora de realizar
un análisis forense en los entornos de operación, y
de las tecnologías que permiten su automatización.
Podemos destacar las siguientes:
››Funcionamiento continuo de determinados sistemas
que impide su parada limitando de esta forma las
actividades necesarias para la investigación.
››Falta de capacidad para registrar la actividad o
transacciones realizadas en los sistemas de control.
››Escasez de herramientas de análisis forense para
determinadas tecnologías de operación que se
ejecutan sobre sistemas propietarios o cerrados.
Estas y otras limitaciones son desarrolladas en los
siguientes apartados del documento.
Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 25
 2
Análisis forense
en Tecnologías
de Operación
 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 27

CONTENIDOS

EN SISTEMAS DE CONTROL INDUSTRIAL

ALCANCE
DIFICULTADES EN LA RECOPILACIÓN DE EVIDENCIAS
VULNERABILIDADES COMUNES EN SISTEMAS DEL NIVEL 1 (CONTROL)
VULNERABILIDADES COMUNES EN SISTEMAS DE NIVEL 2 (SUPERVISIÓN)
PASOS BÁSICOS DEL ANÁLISIS
TÉCNICAS Y HERRAMIENTAS
HERRAMIENTAS EN LA FASE DE ALCANCE
HERRAMIENTAS EN LAS FASES DE EXAMEN Y ANÁLISIS

EN REDES INDUSTRIALES
SISTEMAS DE ANÁLISIS FORENSE EN REDES
PASOS BÁSICOS DEL ANÁLISIS
ANÁLISIS FORENSE BÁSICO
ANÁLISIS FORENSE ESTRICTO
TÉCNICAS Y HERRAMIENTAS

EN LA INTEGRACIÓN CON LOS SISTEMAS CORPORATIVOS

ALCANCE
DISPOSITIVOS EN DMZ
PASOS BÁSICOS DEL ANÁLISIS
TÉCNICAS Y HERRAMIENTAS
Análisis forense en Tecnologías de Operación
En sistemas de control industrial

EN SISTEMAS DE CONTROL
INDUSTRIAL
Por definición, la ciencia de la informática forense,
como ya ha sido indicado, se ocupa de extraer toda la
evidencia posible de los dispositivos informáticos para
poder presentarlos en procesos judiciales, a través de
la aplicación de técnicas científicas y analíticas que
permitan identificar, preservar, analizar y finalmente
presentar datos válidos en un proceso legal. Cómo
en cualquier otro ambiente, en el análisis forense
de los ICS se llevará acabo la búsqueda detallada
de evidencias que permita reconstruir o entender a
través de todos los medios posibles, el registro de
acontecimientos que tuvieron lugar desde el momento
en el que el sistema estuvo en su último estado integro
conocido, hasta el momento posterior a un incidente,
en el cual haya sido alterado su estado normal de
funcionamiento.
En la investigación forense de un incidente tecnológico
es clave, para comprender la naturaleza y la gravedad
del incidente, tener acceso a todas las fuentes que sea
posible y a los registros de diferentes tipos, como los
relacionados con auditorías, autenticación, autorización
y actividades generales del sistema. La práctica de
recopilar todas las fuentes de datos y su correlación es
una estrategia común para los investigadores.
De igual modo, cabe destacar que en muchos países
se hace cada vez más frecuente la solicitud por parte
de los organismos reguladores de la presentación
de informes de incidentes, estadísticas, puntos de
contacto para operaciones conjuntas de control de
daños entre el Estado y las empresas, etc.
Este apartado tiene como objetivo presentar los pasos
básicos para realizar una investigación forense en
ICS, teniendo en cuenta las dificultades específicas
de este entorno y las vulnerabilidades principales de
estos sistemas, para terminar con la presentación de
herramientas de análisis forense adecuadas para los
mismos. Este apartado también permitirá preparar y
planificar la respuesta apropiada para evitar futuros
incidentes.
Buenas
Guía para
prácticas
la construcción
en el Análisis
de unForense
SGCI. de
Sistema
Sistemas
de Gestión
de Automatización
de la Ciberseguridad
y Control Industrial 29
Alcance
Este apartado contemplará el análisis forense para
los principales componentes de los ICS, que pueden
dividirse en sistemas correspondientes a los niveles 1
y 2 de la pirámide de automatización industrial que se
muestra en la figura 1.
Nivel 1. Control.
››En este nivel se encuentran los sistemas de control
individual de cada recurso.
››Estos sistemas pueden ser PLCs (Controladores
lógicos programables) y RTUs (Unidades de terminal
remotas) de gama baja y media, sistemas de control
numérico, transporte automatizado, etc.
››Dichos sistemas utilizarán los datos del proceso
proporcionados por los equipos del nivel 0
(instrumentación) y se darán las consignas a los
actuadores y máquinas de dicho nivel.
››También dentro de este nivel, involucrados
directamente en el proceso de control, podemos
encontrar algunos equipos que se ejecutan sobre un
sistema operativo común, tales como Windows, Unix
o Linux. Un ejemplo de este tipo de equipos son los
que soportan comunicaciones OPC, u otro tipo de
gateways de comunicaciones.
Nivel 2. Supervisión.
››En este nivel se encuentran los sistemas que
controlan la secuencia de fabricación y/o producción
(y que pueden dar las consignas al nivel de campo).
››En este nivel se emplean PLCs de gama media y alta,
PCs Industriales, HMI, SCADA, DCS y equipos, como
ordenadores portátiles, ordenadores de sobremesa,
estaciones de trabajo y servidores que ejecutan sus
aplicaciones en un sistema operativo común, como
Windows, Unix o Linux. Estos equipos a menudo son
empleados para proporcionar histórico de datos,
programación y/o funciones de supervisión…etc.
30 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial
Es importante señalar algunas de las características y
condiciones de operación de los ICS. A diferencia de
los sistemas de información, algunos ICS automatizan
determinados procesos que funcionan en tiempo real,
donde deben ser estrictamente controlados los tiempos
de respuesta y la latencia de red. Las ventanas de
tiempo de inactividad programada, en algunos casos
puede ser de meses dificultando las actualizaciones
de software. Los ICS trabajan en ambientes con
condiciones extremas de temperatura, humedad,
polvo o vibraciones, muy diferentes a las que están
sometidos los sistemas de un centro de datos.
Lo más frecuente es encontrarse que el análisis
forense para ICS se concentra en el nivel 2,
sistema SCADA, DCS, bases de datos…etc. La
principal razón es que normalmente estos sistemas
funcionan sobre sistemas operativos de propósito
general, como Windows, Unix o Linux, y por tanto
responden a incidentes que podemos investigar con
las herramientas forenses disponibles para estas
plataformas, y a su vez, los ataques más comunes
en los ICS ocurren a éste nivel (ataques de malware,
de explotación de vulnerabilidades sobre los HMI o el
software de los SCADA o DCS, etc.). Sin embargo,
es importante también analizar los sistemas del
nivel 1, aunque en este caso, las herramientas
disponibles para estas plataformas sean escasas.
Una alternativa para poder comprender el análisis
forense en ICS se basa en la diferenciación de las
posibles categorías de análisis:
››Fallos o ataques a través de la configuración de
sistemas de nivel 1 (sistemas embebidos de PLCs o
RTUs, gateways)
››Fallos o ataques a través de la configuración del
sistema operativo o de aplicaciones del nivel 2
(estación de trabajo de configuración, servidores
de bases de datos, aplicaciones de supervisión y/o
control)
››Fallos o ataques a través de redes Ethernet.
››Fallos o ataques no Ethernet (comunicaciones serie).
››Fallos o ataques a través de dispositivos (USB,
DVD,...) o aplicaciones de intercambio (correo
electrónico, transferencia de ficheros, disco remoto,
servidor web, ERP, etc.)
Cada uno de los incidentes analizados es único, por
lo tanto, el modo de actuar puede diferir. En algunas
ocasiones las tareas se limitarán a la colaboración con
los organismos responsables de Delitos Telemáticos,
proporcionándoles el equipo íntegro, siempre que
esta posibilidad exista, para que sea analizado en sus
instalaciones y por sus expertos en peritaje. En otras
ocasiones será necesario realizar una recolección
de información del ICS: analizar su registro, estudiar
el sistema de ficheros (FS) del ICS comprometido y
reconstruir la secuencia de eventos para tener una
imagen clara y global del incidente, lo cual no siempre
será posible.
El análisis terminará cuando se tenga conocimiento
de (1) cómo se produjo el compromiso, (2) bajo qué
circunstancias, (3) la identidad del posible atacante,
(4) su procedencia y origen, (5) las fechas del
compromiso, (6) los objetivos del atacante, (7) los
efectos del compromiso, así como, (8) cuándo ha sido
reconstruida completamente la secuencia temporal de
los eventos.
Dificultades en la recopilación de
evidencias
››Muchas tecnologías de operación del nivel 1, y
algunas del nivel 2 no proporcionan recogida de
datos (registros de logs) eficaz para poder analizar
posteriormente el incidente. Además gran parte de
aquellos sistemas que sí tienen dicha capacidad,
está normalmente desactivada. Por lo tanto, la
volatilidad de los datos del proceso y su estado
es tal, que se borran, eliminan o sobrescriben a
una velocidad que hace que la recolección sea
inviable en muchas oportunidades. Asimismo, es
muy común también encontrarse en los sistemas
del nivel 1 que las capacidades de procesamiento,
memoria y de almacenamiento están limitadas por
su funcionalidad específica dificultando no solo la
recopilación de evidencias, sino también la activación
de cualquier registro de auditoría porque afectaría
a su funcionamiento o incluso a su estabilidad en
algunos casos.

Cach
cia
Mez
en
dato cla de
Infor utamien ceso
is t
s BA
rs
JA
pe
e
Sin
tabla
Mez
cla d
e da
tos A
LTA
Figura 2: Nivel de persistencia de los datos
››Las arquitecturas en las que se despliegan
tecnologías de cortafuegos o sistemas de detección
de intrusos, normalmente sí permiten registrar la
actividad a través del tráfico de red, pero por lo
general a la hora de hacer una pericia forense,
detectamos que no pueden ser correlacionados de
manera efectiva con los datos de los dispositivos de
control, o su implementación no es la adecuada para
la investigación forense por cuestiones tan básicas
como la desincronización de los horarios entre los
dispositivos.
››El análisis posterior al incidente depende, a menudo,
de la participación de proveedores, debido a que
son sistemas propietarios y cerrados, dificultando
la comprobación de procesos esenciales como
la autenticación, las autorizaciones y/o las
modificaciones realizadas en los sistemas, todo ello
motivado por la falta de integridad comprobable.
››Los sistemas de los niveles 1 y 2, son sistemas
críticos que requieren un funcionamiento continuo
para garantizar la operación del proceso, lo cual
dificulta, o incluso en algunos casos impide su parada
para obtención de información que sería necesario
analizar.
Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 31
Vulnerabilidades comunes en
sistemas del Nivel 1 (Control)
e
En los sistemas del nivel 1, como ya se ha comentado,
Dis
mi
se encuentran principalmente controladores,
e
ión d
nu
mac to,
ció
nd
n r r o
s de
p
dependiendo del entorno automatizado, podemos
eu
nid
ad
de l
ma
Siste tempor
ro
a encontrar PLCs (Controladores Lógicos Programables),
fiche y disco
normalmente en instalaciones localizadas y asistidas, o
ny
ació to
itoriz
Mon tro rem
o RTUs (Unidades de Terminal Remoto) en localizaciones
regis
físic
a
ción rchivos
de difícil acceso, dispersión geográfica o instalaciones
figura a
Con ación de
Inform
desasistidas y con comunicaciones lentas.
Los PLCs son dispositivos diseñados para controlar
múltiples señales de entrada (sensores) y de salida
(actuadores), con capacidad para resistir temperaturas
extremas, ruido eléctrico, vibraciones e impactos.
La programación incorporada para el control de
funcionamiento suele almacenarse en baterías o
en memorias no volátiles. Un PLC es un ejemplo
de sistema de tiempo real, donde los resultados
de salida deben ser producidos en respuesta a las
condiciones de entrada dentro de un tiempo limitado,
de lo contrario no se logrará el resultado deseado.
Al ser sistemas específicos, las características
hardware (procesamiento, memoria y almacenamiento)
suelen diseñarse de forma muy ajustadas a las
funcionalidades y necesidades de control. Por ello, las
capacidades de autenticación, autorización y cifrado
suelen ser muy limitadas en los controladores.
Está demostrado que los PLCs, salvo excepciones, no
han incorporado requisitos de ciberseguridad en su
diseño, situación que mediante diferentes mecanismos
puede permitir a un atacante:
››El desbordamiento del buffer
››La ejecución de código arbitrario
››La obtención de privilegios
››El acceso a ficheros con información de entrada al
controlador
››Captura del tráfico de entrada/salida
Las acciones maliciosas (payload) más frecuentes:
››La denegación de servicio
››El escalado de privilegios
››El control remoto del sistema
››La alteración o acceso a la memoria
Esta tipología de vulnerabilidades y acciones maliciosas
se ha obtenido recopilando las más habituales que se
han recogido para diferentes modelos de controladores
32 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial
en el CVE (Common Vulnerabilities and Exposures)
https://cve.mitre.org/find/index.html. Actualmente son
docenas las vulnerabilidades que podemos encontrar
publicadas para cada modelo de controlador industrial.
Es cierto, que la capacidad funcional de estos
dispositivos es limitada, lo cual minimiza el tipo de
debilidades. Aunque, esto está cambiando, la mayoría
de los controladores actuales incorporan además
de las funciones propias de control, capacidades
de supervisión y gestión remota mediante sistemas
embebidos, basados normalmente en Linux, que
implementan servicios web, FTP, SNMP, e incluso
SMTP. Todos estos nuevos servicios, así como el
sistema embebido que los soporta constituyen cada
uno de ellos una fuente de acceso para el atacante.
Es destacable señalar algunas situaciones relevantes
relativas al uso de dispositivos embebidos, como las
siguientes:
1. Existencia de usuarios y sus contraseñas
incrustados en el código de los PLCs y/o RTUs, por
lo cual son usuarios normalmente no documentados
por el fabricante, pero existentes en todos los
dispositivos de una misma marca, con una clave
específica que no puede ser modificada. Es decir,
que cuando un investigador descubre un fallo de
diseño de este tipo, y se hace público, todos los
dispositivos implementados de dicha marca serán
vulnerables mientras no se haga una actualización
de su firmware.
2. Esta claro que para cuando se identifica
una debilidad específica, como podría ser
la anteriormente mencionada, y la forma de
solucionar dicha vulnerabilidad es por medio de la
actualización del firmware con toda la complejidad
que supone en cada instalación, sin embargo, ya
se han conocido casos en donde la actualización
del firmware no es posible por el propio diseño
del fabricante, normalmente debido a que el
dispositivo no dispone de espacio suficiente como
para almacenar la actualización que se requiere,
por lo cual, la única opción es adquirir un nuevo
dispositivo que elimine esta debilidad.
Vulnerabilidades comunes en
sistemas de Nivel 2 (Supervisión)
Los sistemas que se encuentran en el Nivel 2 permiten
supervisar el estado del proceso automatizado.
Agrupamos en el nivel 2 a todos aquellos sistemas
que adquieren los datos de los controladores para
representarlos en pantalla, para almacenarlos o
gestionarlos para, por ejemplo, poder actuar sobre el
proceso.
En el nivel 2, nos encontraremos principalmente
sistemas SCADA, DCS o con funciones equivalentes.
Debido a los avances tecnológicos cada vez más
sistemas SCADA han evolucionado para comunicarse
a través de redes IP públicas. Algunos sistemas
también están conectados a la intranet corporativa o
directamente a Internet, con la finalidad de facilitar
la integración de la información SCADA con la
información de los sistemas corporativos de gestión.
Un sistema SCADA está compuesto normalmente por
3 elementos, un servidor central (Master Unit Control,
MTU) que es el sistema que se comunica e interactúa
con los controladores del nivel 1. Una base de datos
que almacena las señales de los controladores con
los que interactúa el MTU y una o varias pantallas
HMI (Interfaz Hombre-Maquina) donde se visualiza el
estado del proceso que monitoriza el operador o los
operadores.
Una investigación forense en un escenario de un
sistema SCADA que ha sufrido un incidente, el cual ha
provocado que el sistema no funcione correctamente
puede ser una manera eficaz de dar respuesta a
preguntas tales como:
¿El sistema SCADA ha sido comprometido por un
software malicioso?
¿Fue a través del uso de un exploit? ¿tuvo éxito el
exploit?
¿Cómo ha sido afectado el sistema?
¿Cuándo se inició y de qué manera?
¿Fue necesaria acción imprudente o negligente de
personal interno?

Las vulnerabilidades más frecuentes en sistemas del
nivel de supervisión son:
››Autenticación débil o nula.
››Buffer Overflow
››Acceso a credenciales en comunicaciones no cifradas
››Inyección de código arbitrario
››Obtención y escalado de privilegios
››Acceso débil a ficheros con información de acceso
››Segregación de roles y perfiles ineficiente o
inexistente.
››Configuraciones por defecto.
Las acciones maliciosas (payload) más frecuentes:
››Denegación de servicio
››Escalado de privilegios
››Control remoto del sistema
››Alteración o acceso a la memoria
Esta tipología de vulnerabilidades se ha obtenido
recopilando las más comunes que se recogen para
diferentes modelos de sistemas SCADA en CVE
(Common Vulnerabilities and Exposures) https://cve.
mitre.org/find/index.html. Actualmente son docenas las
vulnerabilidades que podemos encontrar publicadas
para cada los diferentes sistemas SCADA.
Pasos básicos del análisis
Cuando un investigador forense empieza el análisis de
la situación nunca sabe con lo que va a enfrentarse.
Al principio puede ser que no encuentre a simple
vista ninguna huella, ni prueba de que los ICS han
sido vulnerados. Puede encontrar procesos extraños
ejecutándose y puertos abiertos, también puede
encontrar una saturación de tráfico de red desde un
“host” específico o un consumo elevado de la CPU, o
cambios en la codificación de los algoritmos de control.
Los pasos básicos para empezar la investigación de
un incidente en un ICS son diferentes en cada caso.
El investigador deberá tomar decisiones basándose en
su experiencia, pero en la mayoría de las ocasiones
podremos seguir los siguientes pasos:
1. Comprender el entorno. Será muy importante
para el éxito de la investigación conocer y
comprender el entorno de operación, sus servicios y
procesos automatizados, así como su arquitectura y
documentación.
Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 33
2. Identificar a los sospechosos. En esta fase
se identificará a los posibles sospechosos que
pueden haber provocado el incidente (competencia,
empleado descontento, proveedor descontento,
fallo tecnológico, posible atacante) que han podido
afectar a los ICS. La identificación de sospechosos
facilitará la siguiente fase.
3. Determinar el alcance. En esta fase se
identificará el alcance de la investigación del
incidente o incidentes, es decir, todos y cada
uno de los posibles sistemas objetivo de la
investigación. Identificar las posibles fuentes de
evidencia, incluyendo los sistemas, la red y los
dispositivos conectados. Identificar el tipo de
sistemas a ser investigado incluyendo sistema
operativo, fabricante, números de serie y modelo
de PLC, y el diseño e implementación de redes.
Evaluar la volatilidad de los recursos identificados
después de la identificación con el fin de definir las
prioridades en cuanto a conservación de evidencias
y su recolección. En esta fase se documentará
también el nivel de volatilidad y su impacto sobre
la posibilidad de reproducir los resultados de la
investigación, así como establecer los mecanismos
que permitan garantizar la integridad de los mismos.
Debido a la diversidad en las soluciones de
los proveedores, así como la personalización y
adaptación del propietario / operador, la singularidad
juega un papel clave en el análisis forense para
entornos de sistemas de control. Será fundamental
disponer de la siguiente información sobre los
componentes identificados dentro del alcance para
comprender el entorno:
››Ubicación física de los dispositivos de control
(nivel 1)
››Especificaciones del hardware y software de los
ICS (Nivel 1 y 2)
››Especificaciones del hardware y software de
dispositivos de red.
››Mapa de red (direccionamiento, configuración,
puertos, subredes,…)
››Especificaciones de parametrización y lógica de
control.
››Especificaciones de hardware y software de
sistemas de (Nivel 3 y 4)
››Flujogramas del proceso y características de uso
de los componentes.
34 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial
››Gestión de cambios (pruebas y cambios
realizados)
››Canales de acceso y niveles de autorización.
››Relaciones y acuerdos con terceros.
4. Examen forense. El examen forense de las
pruebas presentadas por el investigador es una
parte fundamental del proceso que tiene como
objetivo de dar respuestas a las preguntas
formuladas antes de la investigación. En un
entorno ICS este examen debe incluir también
la colaboración de representantes de ingeniería
familiarizados con el funcionamiento del sistema.
5. Análisis de evidencias. En esta fase se
analizarán las evidencias recogidas para cada uno
de los escenarios posibles identificados (Entorno,
sospechoso, sistema objetivo y punto de acceso).
La investigación no debería establecer límites
temporales en las búsquedas, puesto que la primera
prueba podría remontarse a un registro de varios
meses o incluso años antes de que el incidente
fuese detectado.
El análisis basado en escenarios a menudo permite
ilustrar la criticidad asociada de los recursos
tecnológicos y comprender las consecuencias,
es por lo general fundamental para identificar los
objetivos de un atacante, y por lo tanto el alcance.
6. Análisis de la información, depuración y
preservación de las evidencias. Será necesario
un análisis profundo de la información que se ha
recolectado durante el proceso de investigación,
siguiendo un ciclo que se repetirá hasta que
la información se va depurando hasta alcanzar
las evidencias que permitan dar respuesta a las
preguntas:
››[W]ho did it? - ¿Quién lo hizo?
››[W]hat happened? - ¿Qué pasó?
››[W]here did this occur? - ¿Dónde ocurrió?
››[W]hen did this occur? - ¿Cuándo ocurrió esto?
››[W]hy did this occur - ¿Por qué ocurrió esto?
La evidencia digital deberá ser preservada para
asegurar su integridad durante todo el proceso. Esto
incluye el embalaje, que en algunos casos tiene
requerimientos especiales.
7. Presentación y revisión. Las observaciones se
presentarán en un lenguaje comprensible para
la dirección de las organizaciones y personal del
área legal, proporcionando una explicación de
los diversos procedimientos utilizados que han
permitido alcanzar las conclusiones presentadas.
También deberá ser incluida la documentación
sistemática elaborada. Se interpretarán los datos
estadísticos que apoyen el informe y se realizará
una revisión exhaustiva de los incidentes y de
las medidas recomendables para prevenir y
contrarrestar consecuencias similares en el futuro.
Los resultados serán documentados facilitando así
posteriores investigaciones, y permitiendo mejorar
las medidas de seguridad.
Es importante que el investigador conozca y
comprenda las diferentes conexiones entre los socios
y proveedores. Para entender la singularidad asociada
a los ICS también debe tener en cuenta otras variables,
tales como:
››Las conexiones hacia y desde ubicaciones asociadas
o por pares.
››El acceso a los mecanismos utilizados por el
proveedor de soporte a la tecnología ICS.
››El acceso a los mecanismos utilizados por los
contratistas de soporte a los entornos de sistemas de
control.
››Las relaciones reales entre los recursos cibernéticos
y las operaciones del mundo real.
››La eficacia de las políticas de seguridad cibernética
que regulan las operaciones de los sistemas de
control.
››Mecanismos de intercambio de información dentro de
la cadena de suministro.
En aquellos casos en los que los pasos básicos no
han desvelado la situación, se deberá recurrir a llevar
a cabo un análisis profundo o de-compilación de las
aplicaciones identificadas durante la búsqueda. Estas
aplicaciones pueden estar escritas totalmente desde
cero y protegidas; pero en la mayoría de los casos
son aplicaciones basadas en librerías utilizadas de
forma común, que serán accesibles, estén o no estén
protegidas.

No debe perderse de vista que la evidencia en un
proceso pericial puede ser:
››Primaria (Inherente a la actividad pericial específica
dentro del campo de la informática)
››Secundaria (no tiene relación con el campo de la
informática)
y que la misma de por sí es frágil, por eso se
utilizan mecanismos de certificación de la prueba, tales
cómo las matemáticas (hashing por ejemplo). Desde
un primer momento el investigador debe considerar
siempre que la evidencia electrónica es a priori:
››Volatil
››Duplicable (o sea fácil de copiar sin dejar rastros)
››Alterable y modificable (Reemplazable)
››Eliminable con intención o sin ella.
A estas consideraciones habría que añadir el hecho
de que tales evidencias pueden poseer metadatos,
esto es, que además de la información específica
de la evidencia, existen otros elementos indirectos
que podrían ser de interés para el análisis forense
como por ejemplo: los nombres de archivos, fechas
asociadas, usuarios y permisos entre otros. Por ello
se deben tomar las precauciones necesarias en cada
caso para poder trabajar adecuadamente en el proceso
pericial asegurando que toda evidencia electrónica sea
siempre:
››Relevante: relacionada con el incidente bajo
investigación.
››Permitida Legalmente: fue obtenida de manera
legal.
››Confiable: no ha sido alterada o modificada.
››Identificada: ha sido claramente etiquetada.
››Preservada: no ha sido dañada o destruida.
Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 35
Es importante mencionar que hoy día existe el RFC
3227, que aunque no es específico para entornos
ICS, se encarga de establecer los Principios para la
Recolección de Evidencias y por lo tanto será una
buena guía de referencia. El RFC 3227 aborda los
siguientes aspectos:
››Orden de volatilidad
››Cosas a evitar
››Consideraciones relativas a la privacidad de los datos
››Consideraciones legales
››Procedimiento de recolección
››Transparencia
››Pasos de la recolección
››Cadena de custodia
››Como archivar una evidencia
››Herramientas necesarias y medios de
almacenamiento de éstas
La cadena de custodia, como ya se ha mencionado, es
una etapa esencial en procesos que puedan llegar a
judicializarse, y se refiere al registro de todos aquellos
eventos relacionados con la evidencia, acontecidos
desde su recolección hasta la presentación de
la misma, sin dar la posibilidad a que haya sido
modificada por nada ni por nadie en el medio del
proceso. Es por ello que muchas veces en este tipo de
procesos, se agrega la participación de un Notario cuya
función es documentar en un acta formal el proceso
llevado adelante, asegurar que todo se haya realizado
conforme a lo documentado, y es por lo general
a quien se le entrega en custodia las evidencias
originales o una copia de las mismas en caso de que
los originales no puedan ser quitados de la producción,
para que lo resguarden hasta el juicio correspondiente.
La preocupación por la cadena de custodia o la
presencia de un Notario tinen menor relevancia si el
caso no va a ser judicializado.
36 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial
Técnicas y herramientas
El número de herramientas de análisis forense para
ICS es muy reducido, debido principalmente a la
dificultad para realizar comprobaciones sobre el
entorno en producción que ha sufrido el incidente.
Durante una investigación forense digital un
investigador puede usar una variedad de herramientas
software disponibles como EnCase, Xways, FTK, etc.
y herramientas hardware, tales como Write blockers,
etc., a fin de seguir un procedimiento forense
tradicional basado en la recolección de evidencias
observando procesos ejecutándose, aplicaciones,
ficheros y datos almacenados. Este es un proceso
mucho más complicado para un entorno SCADA,
donde la adquisición de datos en tiempo real es una
prioridad y donde en muchas ocasiones no es posible
incorporar un sistema externo, fuera de línea, para
llevar a cabo una investigación forense. Muchas de las
herramientas disponibles para sistemas de información
en un ambiente corporativo, no son validas en un
ambiente industrial, por lo tanto, en muchos casos el
conjunto de herramientas forenses para un entorno
SCADA e ICS deberá ser desarrollado y preconfigurado
con el fin de responder a cualquier incidente reportado.
A medida que los sistemas contienen datos volátiles,
y en gran medida estos son entornos dinámicos,
se requiere una nueva adaptación de los procesos
forenses tradicionales, tal y como se ha presentado en
el apartado anterior.
Para establecer un conjunto de herramientas
forenses para una investigación ICS, es necesario
agrupar las herramientas necesarias en cada fase
de la metodología indicada. Las fases que requieren
herramientas de análisis forense son:
››Fase 3- Alcance
››Fase 4- Examen
››Fase 5- Análisis
Examinamos ahora estos pasos en más detalle y
proporcionaremos una descripción de las herramientas
que se requieren en cada una de las fases.
Herramientas en la fase de Alcance
En esta fase la preservación de evidencias es un
área clave para la investigación, puesto que las
fuentes de datos proporcionarán una mezcla de datos
estáticos y en tiempo real y estáticas vitales para
el descubrimiento del objetivo de la investigación.
Además muchos de los dispositivos afectados no
se podrán detener para la recolección de datos
"estáticos". A continuación se recogen herramientas
que podrían ser utilizadas en esta fase:
Herramientas hardware
Bloqueadores de escritura. Forma parte de un
sistema de copia y se usa para capturar datos
estáticos de los dispositivos mediante copia, sin
posibilidad de dañar accidentalmente el dispositivo
original, permitiendo capturar datos "estáticos" de los
dispositivos, concretamente permitirá capturar datos
de los sistemas de ingeniería, estaciones de trabajo,
ordenadores, servidores de bases de datos, HMIs
de operador, o cualquier otro dispositivo compatible
que puede haber sido conectado a la red SCADA. Es
importante destacar que permiten obtener imágenes
forenses físicas o lógicas asegurando la integridad de
la prueba al permitir el flujo de datos unidireccional
en el momento de la captura de los datos que se
realiza únicamente leyendo el contenido del elemento
informático.
Cámara HD. Muy útil para tomar fotos y documentar
el proceso de recolección de datos. Particularmente
útil cuando se capturan los datos volátiles con el fin de
documentar el diseño del monitor, diseño de escritorio,
cualquier cambio en el sistema.
Tarjeta PCI Firewire. Se usa para capturar datos de
memoria volátil, concretamente para los sistemas
de ingeniería, estaciones de trabajo, ordenadores,
servidores de bases de datos HMI (durante la
ejecución). Se debe tener precaución para evitar
efectos no deseados, puede causar accidentes sobre
sistema de control si no se usan adecuadamente.
Software de clonación de discos. Este software
permite copiar el contenido de un disco duro de un
dispositivo a otro disco o a un archivo imagen. A
menudo, los contenidos del primer disco se escriben
en un archivo imagen como paso intermedio y, en un
paso posterior, el disco de destino es cargado con el
contenido de la imagen. El procedimiento también es
útil para cambiar a un disco diferente o para restaurar
el disco a su estado anterior.
Herramientas software
Bespoke PLC flashing software. Este software es
específico para PLC / RTU de cada fabricante y es

utilizado para enviar comandos al controlador con
el objetivo de recolectar sus datos volátiles. Esta
práctica no será válida a efectos legales, pero puede
proporcionar una rápida respuesta ante incidentes.
CSET (Cyber Security Evaluation Tool https://cset.
inl.gov/SitePages/Home.aspx). Herramienta de
evaluación del DHS (Departament Homeland Security)
que proporciona a los propietarios y operadores
un mecanismo no intrusivo para entender mejor
el riesgo operacional en lo que respecta a la
seguridad cibernética de todos los componentes
dentro de arquitecturas de sistemas de control.
La herramienta, también permite a los usuarios
obtener más información acerca de las diversas
normas de seguridad cibernética asociados a los
sistemas de control, permite calcular los niveles
de garantía de seguridad que puede ser vinculada
a las consecuencias más comunes en las que las
organizaciones están familiarizados. Esto incluye el
daño físico, las lesiones corporales y la pérdida de la
vida, el impacto ambiental y otros aspectos cualitativos
o cuantitativos relacionados con un incidente que
afecta a controlar las operaciones de los sistemas.
Esta herramienta proporciona a los investigadores
forenses la funcionalidad para crear reproducciones
eficaces de la arquitectura de los sistemas de
control para distintos ambientes, y las relaciones de
seguridad entre en dispositivos operativos. El uso de
herramientas como esta proporcionan además de una
revisión proactiva muy necesaria de cómo un incidente
cibernético puede manifestarse en un dominio ICS,
información que puede ayudar al investigador forense
a un conocimiento de la casuística de incidentes en el
entorno donde se produjo el incidente.
Distribuciones forenses. Es software utilizado para
adquirir datos forenses, incluyendo datos dinámicos.
Estas herramientas no debe montar automáticamente
los medios de almacenamiento o montarlos en modo
solo de lectura. Incluyen normalmente herramientas
de captura y análisis. Típicamente se utilizan
distribuciones Linux con software bajo licencia GNU/
GPL. Este tipo de herramienta pueden ser utilizada
para capturar los datos volátiles de HMIs, estaciones
de trabajo de ingeniería, servidores OPC y servidores
de bases de datos. Algunos ejemplos de estas
distribuciones son CAINE (Computer Aide Investigation
Environment) o DEFT (Digital Evidence and Forensic
Toolkit).
Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 37
Editor de texto. Extremadamente útil para tomar notas
de evidencia y documentar el proceso forense. Puede
ser utilizado en todo momento de la investigación.
EnCase Imager. De manera similar a FTK Imager
este software es utilizado para adquirir datos
forenses desde un sistema operativo compatible. Esta
herramienta se utiliza para HMIs, estaciones de trabajo
de ingeniería, servidores OPC y servidores de base de
datos.
FTK Imager. Este software se utiliza para adquirir
datos forenses desde un sistema operativo compatible.
Esta herramienta se utiliza para HMIs, estaciones de
trabajo de ingeniería, servidores OPC y servidores
de base de datos. El software puede manejar datos
estáticos y dinámicos, pero requiere ser instalado en el
dispositivo.
Herramienta de hash. Una herramienta de hash es
utilizada para autenticar y comprobar la integridad de
los datos capturados. Las herramientas de adquisición
a menudo incorporan esta firma que permite garantizar
la integridad los datos.
NMAP. Herramienta para la detección de dispositivos
en la red.
NST (Network Security Toolkit). Compendio de
herramientas, o herramientas de recuperación de
archivos eliminados como "TestDisk" o "Autopsy".
TCPDump. Se utiliza en la red de control o supervisión
para capturar y volcar el tráfico de red. Permite realizar
un rastreo de un incidente a posteriori, puesto que
ciertos indicadores de un ataque pueden estar aún
presente. Como la exfiltración de datos, actividades
anómalas, etc. será útil para capturar cualquier
protocolo específico de comunicación con el sistema
SCADA, como por ejemplo Modbus o Profinet, así
como todos los datos asociados, tales como cargas de
datos o códigos de función para los dispositivos PLC.
38 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial
Herramientas en las fases de Examen y
análisis
Debido a la naturaleza, a menudo compleja, de los
sistemas ICS, las fases de examen y análisis se basan
principalmente en las notas de los investigadores y
su 'reconocimiento' del sistema / red durante la fases
previas de identificación y preparación. En las etapas
de examen y análisis habrá una cantidad significativa
de datos variados que deberán ser procesados
y examinados. Una comprensión detallada de la
propia red y la configuración de los dispositivos sería
extremadamente útil, como ya se ha mencionado.
Las herramientas incluidas en esta sección ayudarán
en el procesamiento, examen y análisis de los datos
recopilados:
Herramientas Hardware
Equipos de alta capacidad de procesamiento.
Sistemas capaces de procesar grandes cantidades de
datos de forma rápida y eficiente, con múltiples puntos
de conexión para acceder a los datos capturados en la
investigación forense.
Dispositivos de Almacenamiento. Sistemas de
almacenamiento con el fin de almacenar copias de
todos los datos capturados en la investigación forense.
Herramientas Software
AccessData FTK Toolkit. Herramienta que puede
utilizarse como alternativa de herramienta de análisis.
También puede utilizarse para procesar los datos del
sistema de archivos de los servidores HMI, estaciones
de trabajo de ingeniería, servidores OPC y base de
datos.
Autopsy. Herramienta libre que permite analizar
sistemas de ficheros. Asimismo, a partir de la versión
4.0 para Windows permite la integración de plugins
personalizados para la extracción y procesamiento de
datos específicos de sistemas SCADA.
CREED. Cisco Router Evidence Extraction Disk. Se trata
de un disco auto arrancable que ejecuta un script para
obtener información de routers Cisco.
E-Detective. Software que permite la reconstrucción
y reensamblado de tráfico a partir de los paquetes
capturados.
Encase Endopoint Investigator. Herramienta capaz
de procesar y analizar las imágenes que fueron
tomadas usando los bloqueadores de escritura.
Permite por ejemplo escribir secuencias de comandos
de procesamiento de datos a medida utilizando
Enscript. También puede utilizarse para procesar los
datos del sistema de archivos de los servidores HMI,
estaciones de trabajo de ingeniería, servidores OPC y
base de datos.
Hex viewer. Herramienta software que permite ver los
datos en bruto en formato hexadecimal. Por ejemplo,
permite ver los datos de la memoria flash de PLC /
RTU / RAM en hexadecimal. Esto sería particularmente
útil con el fin de ser capaz de buscar a través de los
datos en bruto para los ejemplos binarios de malware
conocidos. Esto también proporcionará todos los
detalles útiles relacionados con el funcionamiento
de un dispositivo de campo. P.ej. códigos de función,
cargas útiles de datos, estado de ejecución, tiempos,
etc.
Moki Linux. Distribución de Kali Linux que incluye
diversas herramientas para entornos ICS/SCADA.
NetworkMiner. Herramienta que permite el análisis
de tráfico en sistemas de control industrial pudiendo
recolectar información de importancia para la
realización de un análisis forense (Equipos dentro de la
red, credenciales encontradas, archivos, etc.). También
posee una opción de reconstrucción de paquetes que
puede ser interesante para analizar ciertos protocolos
industriales que han podido ser víctimas de una
reinyección de tramas.
Nipper. Es una herramienta que permite analizar la
configuración de diferentes dispositivos de red y que
soporta una gran variedad de fabricantes. Gracias a
esta herramienta es posible detectar vulnerabilidades
de las que han podido aprovecharse usuarios
maliciosos.
OllyDbg, Radare, IDA Pro y Cuckoo sandbox.
Herramientas para el análisis de malware que permiten
comprobar el comportamiento del mismo y analizarlo
a un nivel de detalle que permite comprender el
funcionamiento de estos códigos maliciosos.
P2 Commander. Suite comercial para el análisis
forense
Volatility Framework. Herramienta de extracción y
análisis de la memoria volatil (RAM).
Red Miner. Es una herramienta de análisis forense
de red con capacidad para analizar el tráfico de ICS
capturado. Esta herramienta de análisis es útil para
 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 39

identificar cualquier actividad anómala en la red.

También permite identificar el flujo de tráfico entre
dispositivos SCADA y para múltiples protocolos de
comunicaciones entre ICS. Permite identificar los
vectores de incidentes sobre la base de dicho tráfico.
SANS SIFT Workstation. Suite de herramientas
forenses pre-configuradas en una máquina Vmware
que puede ser de gran utilidad en aquellos casos que
se requiere automatizar determinadas tareas.
Xplico. Software bajo licencia GNU/GPL que permite
reconstruir la secuencia de paquetes a partir de una
trama de tráfico de red, separando e identificando el
tráfico por aplicación.
Winhex. Editor hexadecimal que permite la recolección
y análisis forense.
Wireshark. Herramienta que permite capturar y
analizar el tráfico de red.
Análisis forense en Tecnologías de Operación
En redes industriales

EN REDES INDUSTRIALES
Los sistemas de comunicaciones industriales han
evolucionado hacia estándares internacionales como
Ethernet Industrial; el cual ofrece mayor flexibilidad,
mejor diagnóstico y mayor fiabilidad para los sistemas
de automatización. Al mismo tiempo, sin embargo,
los procesos de producción, donde la seguridad no
ha sido un inconveniente, ni un aspecto valorado
en el pasado, son susceptibles de sufrir un acceso
no deseado tanto desde el exterior como desde el
interior de la instalación industrial. Sólo un enfoque
que integre mecanismos de seguridad con una
comprensión global de la automatización puede
ofrecer una protección fiable. Además, las plantas de
producción están continuamente expuestas a peligros,
equipos infectados, personal no autorizado, el acceso
ilegal a través de la red de comunicaciones e Internet,
por lo cual deberán adoptarse medidas contra estas
amenazas de seguridad.
El análisis forense de las redes de comunicación, es
una subdisciplina de la Informática Forense que se
ocupa de la captura, almacenamiento y análisis del
tráfico de las redes.
El análisis de los datos de una red es diferente del
análisis de datos encontrados en un disco duro debido
a la naturaleza temporal de la información en la red
(información en tránsito). Cuando un ordenador se
apaga, el contenido del disco duro permanece intacto
y estático. Sin embargo, en una red, todo está en
constante cambio. Cualquier análisis de una red,
captura una imagen instantánea de la actividad en
ese preciso momento. Mientras que ambas partes en
cada caso pueden examinar los mismos datos de la
instantánea, es imposible replicar el estado de la red
en un momento posterior.
Como ya se ha indicado un análisis forense se basa
en el uso científico de técnicas probadas para recoger,
fusionar, identificar, examinar, correlacionar, analizar
y documentar la evidencia electrónica, procesando
activamente y transmitiendo las fuentes digitales con
el fin de descubrir hechos relacionados con el intento
planificado, o medir el éxito de las actividades no
autorizadas encaminadas a alterar, corromper, y poner
en peligro los componentes de un sistema, así como
proporcionar información para ayudar en la respuesta
o en la recuperación de estas actividades.
Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 41
Un análisis forense de una red industrial implica,
por tanto, la monitorización del tráfico de red para
determinar si existe una anomalía en el tráfico
y comprobar si ésta supone alguna actividad no
autorizada que podría alterar o poner en riesgo a
los ICS. Si esto es así entonces el siguiente paso
nos llevaría a tratar de determinar la naturaleza
del incidente y como adoptar todas las medidas de
control directo o compensatorio para endurecer las
comunicaciones y los sistemas frente a posibles
incidentes similares en el futuro.
Sistemas de análisis forense en redes
Los sistemas forenses de red se pueden clasificar en
dos tipos:
››Sistemas "catch-it-as-you-can" (cáptalo-como-
puedas o capta-lo-que-puedas), en los que todo
el tráfico de datos pasa por un punto determinado
y todos los paquetes son capturados y registrados
en el sistema de almacenamiento de información.
Posteriormente, estos datos son analizados
por lotes. Este enfoque supone la obtención de
grandes volúmenes de datos, lo que requiere una
infraestructura de almacenamiento de información
adecuada.
››Sistemas "stop, look and listen" (detente, observa
y escucha), en el que cada paquete de información
transmitido (y, respectivamente, capturado) se
analiza de manera rudimentaria en memoria,
guardándose sólo cierta información para futuros
análisis. Este enfoque precisa menos capacidad de
almacenamiento; aunque, a diferencia del anterior,
puede requerir un procesador más rápido para
mantenerse al día del tráfico entrante.
Un problema clave, relacionado con el enfoque "catch-
it-as-you-can", es el de la salvaguarda de la intimidad:
mediante tal sistema se captura, indiscriminadamente,
toda la información de los paquetes en tránsito
(incluidos los datos de los usuarios). En este sentido,
los proveedores de servicios de Internet, tienen sujeto
su proceder a los dictados judiciales (habrá de ser un
juez quien emita una orden de “escucha” que habilite
una captura de información de esta naturaleza). Dos
de los ejemplos más conocidos, y polémicos, de
herramientas de interceptación de comunicaciones
electrónicas son ‘Echelon’, plataforma perteneciente
a la Agencia de Seguridad Nacional de los EEUU y
“Carnivore”, su equivalente para el FBI. En España, por
42 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial
ejemplo, tanto los servicios de inteligencia, como las
fuerzas del orden, tienen a su disposición el sistema de
origen danés “SITEL”.
Pasos básicos del análisis
Existen dos propósitos principales, como ya se ha
mencionado, para realizar un análisis forense: uno
es para mejorar la seguridad, en este caso de la
red, el otro es para obtener evidencias para poder
presentarlas en procesos judiciales. Por lo tanto, hay
dos tipos de análisis forenses, cada uno de los cuales
dispone de un número diferente de fases:
››Análisis forense básico. En algunas circunstancias,
el foco de análisis forense de red es sólo para la
mejora de la seguridad. El análisis de datos es para
descubrir algunas características en los ataques
de red y utilizarlas para conducir las estrategias y
gestión de cortafuegos o sistemas de detección de
intrusiones. Así, pueden ser capturados y obtenidos
en el proceso sin principios legales rígidos.
››Análisis forense estricto. Es la intersección entre
la informática y la ciencia forense. Tiene fines
estrictamente forenses y su resultado puede ser
utilizado como evidencia. Tiene criterios más rígidos
en el requisito de la validación legal que el análisis
forense básico. En los procesos de análisis forense
estrictos se incluyen muchos pasos que deben
cumplir los principios jurídicos.
Análisis forense básico
Según el NIST en su guía para integrar técnicas
forenses de respuesta a incidentes (SP800-86) se
definen las fases básicas de los procesos de análisis
forense como la "captura, examen, análisis e informe”
de eventos de red a fin de descubrir la fuente de los
ataques.
››Captura. La primera fase del proceso es identificar,
marcar, grabar y adquirir datos de las posibles
fuentes relevantes, siguiendo las directrices y
procedimientos que preservan la integridad de
los datos. La captura o recolección se realiza
generalmente de manera oportuna debido a la
posibilidad de perder datos dinámicos tales como
las conexiones de red actuales, así como la pérdida
de datos desde los dispositivos con baterías (por
ejemplo, los teléfonos móviles, PDAs, …).
››Examen. Los exámenes implican tareas de procesar
grandes cantidades de datos recogidos usando una
combinación de métodos automatizados y manuales
para evaluar y extraer datos de interés particular,
preservando su integridad.
››Análisis. La siguiente fase del proceso es analizar
los resultados de la fase anterior, utilizando métodos
legalmente justificables y técnicas, para obtener
información útil que responde a las preguntas que
motivaron llevar a cabo la recolección y examen.
››Presentación de informes. La fase final informa
o comunica los resultados de los análisis, a través
de un informe que puede incluir la descripción
de las acciones utilizadas, explicando cómo se
seleccionaron las herramientas y procedimientos,
y determinando acciones a realizar (por ejemplo,
examen forense adicional de fuentes de datos,
asegurando las vulnerabilidades identificadas,
mejorando los controles de seguridad existentes) y
proporcionando recomendaciones para la mejora
de las políticas, directrices, procedimientos,
herramientas y otros aspectos del proceso forense.
 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 43

Capacidades de registro
REGISTRO

››Rendimiento Extracción de
››Visibilidad paquete vía SPAN
››Redundancia
IDENTIFICACIÓN

Capacidades de
identificación Extracción según
filtro y periodo de
››Criterio de búsqueda tiempo
››Velocidad de búsqueda
ANÁLISIS

Capacidades de análisis
Análisis forense
››Facilidad de uso de red
››Profundidad de análisis

Figura 3: Fases del Análisis forense de red

44 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial
Análisis forense estricto
En un análisis forense estricto, se pueden identificar
las siguientes fases:
1. Preparación y autorización. El análisis forense
de red sólo se puede aplicar en entornos donde
existen herramientas de seguridad (sensores)
como sistemas de detección de intrusiones de red,
analizadores de paquetes, cortafuegos, software de
medición de flujo de tráfico y estos son desplegados
en varios puntos estratégicos de la red. El personal
que debe manejar estas herramientas debe ser
entrenado para conseguir las máximas evidencias
con el fin de facilitar el reconocimiento del delito.
Deben obtenerse también las autorizaciones
necesarias para monitorizar el tráfico de red, y se
debe definir una política de seguridad para no violar
la privacidad de los individuos y de la organización.
También podrán utilizarse honeynets para atraer
a los atacantes, estudiar su comportamiento y
aprender de su estrategia.
2. Detección de incidente/delito. En esta fase
se observarán las alertas generadas mediante
diversas herramientas de seguridad que indiquen
una violación de seguridad o de la política al
respecto. Se analizará cualquier anomalía y evento
no autorizado que se detecte. Se determinará la
presencia y la naturaleza del ataque dependiendo
de varios parámetros. Se realizará una validación
preliminar que permita evaluar y confirmar la
sospecha del ataque. Esto facilitará la toma de
decisión sobre si se desea continuar la investigación
u omitir la alerta por una falsa alarma. Deben
adoptarse las precauciones oportunas, a fin de
que la evidencia no sea alterada en el proceso. La
confirmación de un incidente desencadena, a su
vez, dos procesos que son la respuesta a incidentes
y la recogida de datos.
3. Respuesta a incidentes. Se inicia la respuesta
al delito o intrusión detectada basándose en la
información recolectada para validar y evaluar el
incidente. La respuesta iniciada dependerá del tipo
de ataque identificado y se regirá por el interés
del negocio, requisitos legales y la política de la
organización. Se iniciará un plan de acción para
contener futuros ataques y recuperarse de los
daños existentes. Al mismo tiempo, también se
tomará la decisión de si se decide dar continuidad
a la investigación y recopilar más información.
Esta fase sólo es aplicable en casos en los que se
inicia una investigación mientras el ataque aún está
en ejecución, y no después de la notificación del
mismo.
4. Recopilación de trazas de red. Durante esta
fase se guardará la información generada desde los
sensores destinados al registro del tráfico de datos
en la red. Dichos sensores deberán ser seguros,
tolerantes a fallos, tener acceso limitado y capaces
de evitar el compromiso. Se deberá implantar un
procedimiento bien definido usando herramientas
fiables, tanto hardware como software, con el fin de
reunir el máximo número de pruebas reduciendo
cualquier tipo de impacto.
La supervisión de la red habrá de permitir identificar
futuros ataques y deberá garantizar la integridad
de los datos y los eventos de red registrados. La
recopilación es la parte más difícil debido a que el
tráfico de datos por la red cambia a un ritmo muy
elevado, y no es posible generar la misma traza
en un momento posterior. También la cantidad
de datos registrados será muy alta, por lo que
resultará imprescindible disponer de un sistema con
espacio de almacenamiento suficiente para manejar
diferentes dimensiones de forma adecuada.

5. Protección y preservación. En esta fase se
almacenarán los datos originales obtenidos en
forma de trazas (logs) en un dispositivo de respaldo.
Se guardará un resumen (hash) de todas las trazas
de datos y se protegerán los mismos. Se utilizarán
procedimientos estándar para asegurar la integridad
y confiabilidad de los datos conservados. Una
cadena de custodia es estrictamente obligatoria
para garantizar que no hay ningún uso no autorizado
o manipulación. Una copia de los datos se empleará
para el análisis, y el tráfico recogido de la red se
conservará. Esto permitirá que la investigación
realizada pueda ser reproducida nuevamente
basándose en los datos originales, recogidos para
cumplir con los requisitos legales.
6. Examen. Las trazas obtenidas de varios sensores
de seguridad estarán integradas y fundidas para
formar una gran base de datos sobre la cual
se realizará el análisis. También se realizará
el mapeo y estampación de tiempo de estos
datos. Esto es necesario para que no se pierda
o no se mezcle información crucial. Se deberán
recuperar, en la medida de lo posible, los datos
ocultos o camuflados por el atacante. Los datos
recogidos serán clasificados en grupos de modo
que el volumen de datos puede ser reducido a
dimensiones manejables. Una vez dispongamos de
la información organizada, se eliminarán los datos
redundantes y no relacionados, para identificar los
atributos representativos que faciliten el análisis
forense.
7. Análisis. En esta fase se buscarán las evidencias
recogidas metódicamente para extraer indicadores
específicos del delito. Los indicadores se
clasificarán y serán correlacionados para deducir
observaciones importantes mediante los patrones
de ataque existentes. Se usarán en la búsqueda
aproximaciones basadas en estadística y métodos
de minería de datos, y se combinarán patrones de
ataque. Algunos de los parámetros importantes
estarán relacionados con el establecimiento de la
conexión de red, consultas DNS, fragmentación
de paquetes, tipo de protocolo, huellas de sistema
operativo, procesos maliciosos, software instalado
o rootkits. Los patrones de ataque se consolidarán
pudiéndose reconstruir y reproducir el ataque para
comprender la intención y metodología del atacante.
El resultado de esta fase es la validación de la
actividad sospechosa.
Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 45
8. Investigación y atribución. La información
obtenida de los rastros de evidencias se utiliza
para identificar quién, qué, dónde, cuándo,
cómo y el porqué de los hechos. Esto ayudará
a la identificación y atribución de la fuente y
reconstrucción del escenario del ataque.
La parte más difícil del análisis forense de red
es establecer la identidad del atacante. Existen
diversas, y sencillas, técnicas mediante las cuales
el atacante puede ver su identidad salvaguardada;
entre ellas, el “IP spoofing”, los ataques “stepping-
stone” o la utilización de la red TOR. Con respecto
a la primera, los investigadores han propuesto
muchos esquemas de rastreo de las direcciones
IP que conduzcan a la dirección del primer
ataque, pero esto sigue siendo un problema sin
resolver. Los “stepping-stone” son creados por
los atacantes usando sistemas comprometidos
para lanzar sus ataques. Pueden ser detectados
utilizando semejanza y anomalía basada en
enfoques aplicados a las estadísticas de paquetes.
Finalmente, TOR ofrece anonimato a nivel de red,
no desvelando las direcciones IP en los mensajes
intercambiados en el transcurso de la conexión,
manteniendo, al mismo tiempo, la integridad y el
secreto de la información intercambiada.
La orientación de la investigación dependerá del
tipo de ataque.
9. Presentación y revisión. Las observaciones se
presentarán en un lenguaje comprensible para
la dirección de las organizaciones y personal del
área legal, proporcionando una explicación de
los diversos procedimientos utilizados que han
permitido alcanzar las conclusiones presentadas.
También deberá ser incluida la documentación
sistemática elaborada. Se interpretarán los datos
estadísticos que apoyen el informe y se realizará
una revisión exhaustiva de los incidentes y de
las medidas recomendables para prevenir y
contrarrestar consecuencias similares en el futuro.
Los resultados serán documentados facilitando así
posteriores investigaciones, y permitiendo mejorar
las medidas de seguridad.
46 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial
Técnicas y herramientas
Las herramientas de análisis forense de red (NFATs
– Network Forensic Analisys Tools) permiten a los
administradores monitorizar las redes con el fin de
reunir toda la información sobre tráfico anómalo,
ayudar en la investigación del crimen de red y ayudar
a generar una adecuada respuesta a incidentes. Estas
herramientas también ayudan a analizar el robo de
información privilegiada y el mal uso de los recursos,
predicen ataques a objetivos en un futuro próximo,
permitiendo realizar evaluaciones del riesgo, pero
también del rendimiento de la red.
Las herramientas de análisis forense de red capturan
el tráfico total de la red, permitiendo a los usuarios
analizar dicho tráfico de red según sus necesidades y
descubrir características significativas sobre el tráfico.
Estas herramientas tienen una sinergia con IDSs y
cortafuegos y almacenan los registros del tráfico de
red durante un largo periodo de tiempo posibilitando
así análisis de las redes. Por tanto, mediante estas
herramientas pueden reproducirse tanto los ataques,
como los movimientos de los atacantes con intención
maliciosa para poder ser analizados posteriormente.
Finalmente, con las citadas capturas de datos, se
facilitará la identificación de conexiones entre las
diferentes direcciones IP de la red, permitiendo al
usuario analizar protocolos, contenido de paquetes,
retransmisiones de los datos y extraer patrones de
tráfico entre varias máquinas.
Existen gran multitud de herramientas que se utilizan
para realizar los análisis forenses de red, las cuales se
pueden organizar según tres conceptos: comerciales,
gratuitas y comandos. A continuación, se citan algunas
de las más conocidas según el criterio definido
anteriormente:
››NFATs comerciales disponibles en el mercado:
NetIntercept, NetDetector, NetFlow, SilentRunner,
EnCase y VisualRoute.
››NFATs gratuitas/opensource: Dump / Libpcap
/ WinDump, Wireshark, Snort, Nmap, P0f,
Tcpstat, Tcptrace, Tcpflow, Xplico, Tshark, scapy,
NetworkMiner (ésta, disponible, también, en versión
comercial, de pago).
››Comandos incorporados en muchos sistemas
operativos modernos y que son útiles para análisis
forenses – Nslookup, Traceroute, Netstat, Nbtstat,
Whois, Ping, Wget, cavar, curl, ifplugstatus, host, mtr.
Adicionalmente, también existen diversas herramientas
hardware que facilitan la captura del tráfico de red.
LAN Tap es un ejemplo de ellas. En el ámbito de las
redes WiFi, los dispositivos WiFi Pineapple permiten,
igualmente, supervisar y/o capturar este tipo de tráfico
inalámbrico.
Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 47
Análisis forense en Tecnologías de Operación
En la integración con los sistemas corporativos
 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 49

EN LA INTEGRACIÓN
CON LOS SISTEMAS
CORPORATIVOS
En apartados anteriores hemos cubierto el análisis
forense aplicado a los principales ICS, como SCADA
y DCS, controladores industriales y sobre la redes
industriales. En este apartado nos centraremos en el
análisis forense en la integración de esos sistemas,
dispositivos y redes (ambiente OT) con los sistemas
corporativos (ambiente IT).
Por análisis forense en la integración con los sistemas
corporativos entendemos el proceso de búsqueda
detallada para reconstruir a través de todos los medios
posibles el registro de acontecimientos que tuvieron
lugar desde el momento en el que los sistemas que
permiten la integración entre los ambientes OT e IT
estuvieron en su estado integro hasta el momento de
detección de una intrusión o ataque.

Alcance
El análisis forense de este apartado conlleva la
recogida de datos, examen y análisis de ficheros de
datos, datos de sistemas operativos y datos del tráfico
de red entre la zona corporativa (IT) y la zona de
operación y control (OT), incluyendo los dispositivos
y los datos de las aplicaciones ubicadas en la zona
desmilitarizada (DMZ, por sus siglas en inglés).

Zona
Zona
potencialmente Zona de confianza
desmilitarizada
hostil

Zona Corporativa Zona de Operación

y Control

Figura 4. Zona desmilitarizada (DMZ)

50 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial

Dispositivos en DMZ La red DMZ permite segregar los niveles 3 y 4. Los

En este apartado se desarrolla la descripción de una
DMZ típica, los dispositivos y tipos de aplicaciones
que se suelen disponer en esta, así como sus posibles
vulnerabilidades.
En la Fig. 5 se muestra una red basada en el concepto
de zonas del modelo de Purdue que permite separar
la red de la empresa (nivel 4 y 5) de la red de los
sistemas de control industrial (niveles 3, 2, 1 y 0)
por segregarla en segmentos lógicos que constan de
sistemas que realizan funciones similares o que tienen
requisitos similares.
sistemas y aplicaciones en el nivel 3 se comunican con
los sistemas en la zona de nivel 4. La comunicación
directa entre los sistemas en la zona fabricación y
zonas de empresas no se recomienda. Entre los niveles
4 y 5 se suele disponer de un cortafuegos y entre los
niveles 3 y 2 también se tiene otro cortafuegos.
Como se muestra en la Figura 5, se utilizan un par de
cortafuegos para crear una DMZ entre los entornos
corporativos (IT) y los de producción (OT). El primer
cortafuegos bloquea los ataques entrantes, destinados
a los dispositivos de la red OT e inspecciona el tráfico
de entrada y salida de la DMZ. El segundo cortafuegos

Level 4: Site Business Planning and Logistics

IDS E-Mail Print Servers Scheduling Inventory IT Services

Cortafuego

Systems Systems (DNS, DMCP,

etc)

Zona desmilitarizada
DMZ

IDS Shared FTP/SFTP Patch/AV Shared Remote

Cortafuego

Historian Servers Servers Application Access

Servers Servers

Level 3: Site Manufacturing Operations and Control

IDS Plant Production/ IT Services Engineering File Servers

Historian Scheduling (DNS, DMCP, Workstations
Systems LDAP, etc)

Figura 5. DMZ típica


controla el tráfico de entrada y salida del entorno de
control y contiene los potenciales ataques que se
puedan haber originado dentro de dicha red OT.
Una DMZ requiere que el cortafuegos ofrezca tres
o más interfaces, en lugar de las típicas interfaces
públicas y privadas. Una de las interfaces estará
conectada a la red corporativa, la segunda a la red
de control, y las restantes interfaces a los dispositivos
compartidos o que son más vulnerables, como por
ejemplo el servidor de datos históricos. Cada camino
tiene que terminar en la DMZ. La mayoría de los
cortafuegos pueden permitir múltiples DMZ, y pueden
especificar qué tipo de tráfico puede transmitirse entre
las zonas. Con conjuntos de reglas bien planificados,
se puede alcanzar una separación clara entre la red de
control y las otras redes, con ningún tráfico que pase
directamente entre las redes corporativas y de control.
La arquitectura de dos cortafuegos aumenta la
seguridad ya que esas capas adicionales deben ser
penetradas con el fin de comprometer los sistemas en
el entorno de las OT. La seguridad puede aumentarse
si los cortafuegos que se instalan son de diferentes
fabricantes. Estos dos cortafuegos tendrían diferentes
conjuntos de vulnerabilidades lo que complica que
un atacante pueda alterar ambos cortafuegos ya que
tendría que encontrar y explotar vulnerabilidades que
afecten a ambos dispositivos. Otro de los beneficios
de la aplicación de la arquitectura dual de cortafuegos
es que se pueden separar las responsabilidades de
gestión de los mismos, por lo que el cortafuegos que
conecta al nivel 4 es gestionado por el departamento
de IT, mientras que el cortafuegos que conecta al
nivel 3 puede ser responsabilidad del grupo de
automatización y control de procesos (OT).
Los dispositivos y aplicaciones que se suelen instalar
en la DMZ suelen ser el servidor de datos históricos,
servidor de datos, servidor de parches y antivirus, y
servidor de acceso remoto.
La vulnerabilidad de la DMZ se asocia a la mala
configuración de los cortafuegos debido a políticas
de seguridad no diseñadas correctamente o viciadas
por razones históricas. Las reglas del cortafuego
determinan qué paquetes de red se les permite entrar
y salir de una red. Los paquetes pueden ser filtrados
según la dirección IP, número de puerto, la dirección
y el contenido. Los defectos que son más comunes
incluyen que el cortafuego deje pasar paquetes de
red de Microsoft Windows, pasando servicios, o haber
Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 51
definido servidores de confianza en los niveles 4 o 5 de
la red IT, o la falta de restricciones de acceso entrantes
que crea rutas de acceso en redes críticas. Un
problema común que también se ha observado es que
no estén configuradas las reglas de datos de salida en
el cortafuego, esa falta de restricciones de acceso de
salida permite el acceso de los componentes internos
que pudieran haber sido comprometidos; por ejemplo,
ello puede permitir que un atacante que tenga acceso
al entorno de operaciones (OT) instale un código de
explotación en un dispositivo en la red de los ICS para
volver a llamar fuera de la red del sistema de control
desde la red de empresa o de Internet, pero si el filtro
de salida se aplica correctamente, el atacante no
recibirá la conexión de retorno y no podrá controlar
al dispositivo que ha quedado comprometido. Las
conexiones nunca deben ser iniciados a partir de redes
de menos de confianza.
Se recomienda instalar un Sistema de Detección de
Intrusos en cada uno de los segmentos de redes (en la
DMZ y los niveles 5, 4, 3, 2 y 1 de la red).
Los sistemas de detección de intrusos deben ser
desplegados convenientemente en toda la red y
configurados para detectar los ataques que tienen más
probabilidades de tener éxito contra los sistemas en
el entorno específico en que se trabaja. El sistema de
intrusión debe estar sintonizado para el tipo de tráfico
que se produce en la red con el objeto de minimizar
la generación de falsos positivos y alertas irrelevantes
que pueden llevar a que el sistema o las alertas que
se generen no sean consideradas por los analistas
de seguridad y que por consiguiente el sistema caiga
en desuso por la baja confianza que puedan llegar a
generar las alertas que produzca.
Pasos básicos del análisis
Las técnicas y procesos para recoger, examinar y
analizar datos expuestas en los apartados anteriores
son igualmente válidas para la integración con
sistemas corporativos por lo que solo se incluirá
en este apartado los pasos básicos de análisis que
pueden ser particulares de las aplicaciones que
se ubican en la DMZ, de los dispositivos utilizados
para interconectar la zona de confianza con la zona
potencialmente hostil, y de las transacciones y tráficos
de datos entre las distintas zonas.
La mayoría de los sistemas y aplicaciones generan
grandes volúmenes diarios de eventos por lo que es
52 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial

necesario disponer de mecanismos de recopilación de En la arquitectura de seguridad que se muestra en la

esos registros. El servidor de recopilación de registros
almacena datos críticos, como los intentos de acceso
fallidos y exitosos, re-inicializaciones del sistema y
escalado de privilegios que deben ser protegidos
contra el acceso no autorizado y su modificación.
Los mensajes de registro deben contener atributos
del sistema pertinente, como direcciones IP, puertos y
protocolos utilizados, día y hora, nombre de usuario,
el método de acceso tales como FTP, SSH o HTTP. Al
correlacionar los registros de eventos de diferentes
sistemas, los sellos de tiempo en que ocurren se
convierten en un factor importante. Por ello es
recomendable que los sistemas y aplicaciones que
generan registros de eventos deben utilizar la misma
hora fuente, como un protocolo corporativo de hora de
la red, de modo que dichos registros contengan sellos
de tiempo precisos.
Figura 6.2, el servidor de recopilación de registros y
la herramienta de información de seguridad y gestión
de eventos (SIEM, por sus siglas en inglés) se deben
situar en su propia zona. Hay dos zonas de vigilancia.
La primera es parte del Nivel 4, zona corporativa,
que recibe y analiza los eventos relacionados con la
seguridad de los sistemas y aplicaciones dentro de
la zona corporativa. El segundo es parte del Nivel 3,
zona de producción, que recibe y analiza los eventos
relacionados con la seguridad de los sistemas en
el entorno ICS. Ambas zonas de monitorización
están protegidas por cortafuegos. Solamente las
direcciones IP de origen autorizadas puedan acceder
a estas zonas. Además, como es razonable esperar, el
acceso al servidor de recopilación de registros y a la
herramienta SIEM requieren de autentificación para su
acceso mediante un nombre de usuario y contraseña
válidos.

Level 4: Site Business Planning and Logistics

IDS E-Mail Print Servers Scheduling Inventory IT Services

Systems Systems (DNS, DMCP,
etc) ISGE Log

Zona desmilitarizada
DMZ

IDS Shared FTP/SFTP Patch/AV Shared Remote

Historian Servers Servers Application Access
Servers Servers

Level 3: Site Manufacturing Operations and Control

IDS Plant Production/ IT Services Engineering File Servers

Historian Scheduling (DNS, DMCP, Workstations
Systems LDAP, etc) ISGE Log

Figura 6. Ubicación en la red de la herramienta de gestión SIEM y Log de eventos


Los eventos típicos que se registran son: acceso a
cortafuegos, accesos remotos, eventos detectados
por el sistema de intrusión, acceso y eventos en los
servidores, eventos en las aplicaciones.
Es importante observar que el servidor de recopilación
de registros debe estar correctamente dimensionado,
con el espacio suficiente para almacenar los registros
de sucesos de todos los sistemas y aplicaciones
críticas para un período de retención de datos
apropiado para cada caso. El período de retención
debe ser documentado en la política de ciberseguridad
y debe tener en cuenta las regulaciones que afecten al
sector industrial al que pertenece la organización.
Técnicas y herramientas
En esta sección se describirán las técnicas y
herramientas que se podrán utilizar en el análisis
forense en la integración IT y OT.
Los cortafuegos generalmente están configurados
para registrar información básica de los intentos de
conexión denegados y paquetes sin conexión; así como
información de registro de cada paquete. Los registros
suelen incluir la fecha y la hora a la que se procesa
el paquete, las direcciones IP de origen y destino, el
protocolo de capa de transporte (por ejemplo, TCP,
UDP, ICMP), y el protocolo básico de información (por
ejemplo, TCP o UDP, números de puerto, tipo y código
ICMP). El contenido de los paquetes por lo general no
se graba.
Los cortafuegos que realizan la traducción de
direcciones de red (NAT) pueden contener datos
adicionales que son valiosos para el análisis forense
en relación con el tráfico de red. El dispositivo NAT
normalmente registra cada dirección y el puerto de
asignación de NAT.
Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 53
Los sistemas de detección de intrusión de red realizan
el rastreo de paquetes y analizan el tráfico de red
para identificar actividades sospechosas, grabando
la información relevante para el análisis forense.
El software del sistema de intrusión por lo general
registra las mismas características de los eventos
básicos que son recabados por los cortafuegos, por
ejemplo, fecha y hora de origen, y de destino de las
direcciones IP, protocolo, características básicas del
protocolo, así como información específica de la
aplicación, por ejemplo, nombre de usuario, nombre
de archivo, comando, código de estado. El sistema
de intrusión también registra información que indica
el posible propósito de la actividad. Ejemplos de esto
sería el tipo de ataque (desbordamiento de memoria),
la vulnerabilidad específica, el aparente éxito o
fracaso del ataque, y enlaces a más información sobre
dicho ataque. Algunos sistemas de intrusión pueden
configurarse para capturar los paquetes relacionados
con la actividad sospechosa que puede ir desde grabar
solamente el paquete que desencadenó la alerta de
intrusión, para etiquetar la actividad sospechosa, hasta
grabar el resto de la sesión.
Las herramientas de información de seguridad y
gestión de eventos (SIEM) son capaces de importar
la información de diversos eventos de seguridad de
distintas fuentes de datos relacionados con el tráfico
de red, por ejemplo, ID de registros, eventos de
cortafuegos y correlación de eventos entre las distintas
fuentes. Un SIEM funciona en general, mediante la
recepción de copias de registros de varias fuentes
de datos a través de canales seguros, normalizando
los registros en un formato estándar. A continuación,
la identificación de eventos relacionados, haciendo
coincidir las direcciones IP, marcas de tiempo y otras
características. Los SIEM por lo general no generan
datos del evento original, en cambio, generan meta-
eventos sobre la base de datos de eventos importados.
Muchos de los sistemas comerciales disponibles
además de poder identificar actividades maliciosas,
tales como ataques de virus e infecciones, también
pueden detectar el mal uso o el uso inadecuado de los
sistemas y redes.
54 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial

Las herramientas de análisis forenses de la red (AFR)
suelen proporcionar la misma funcionalidad que los
rastreadores de paquetes, analizadores de protocolo,
y el software de SIEM en un solo producto. Mientras
que el software SIEM se concentra en la correlación
de eventos entre las fuentes de datos existentes,
que suelen incluir múltiples fuentes relacionadas
con el tráfico de red, el software de AFR se centra
principalmente en la recogida, examen y análisis
del tráfico de red. El software de AFR también
ofrece características adicionales que facilitan aún
más el análisis forense de red, con las siguientes
funcionalidades:
››La reconstrucción de eventos mediante la
reproducción de tráfico de la red dentro de la
herramienta, que van desde una sesión individual
(por ejemplo, mensajería instantánea entre dos
usuarios) a todas las sesiones durante un período de
tiempo determinado. La velocidad de la reproducción
típicamente se puede ajustar según sea necesario.
››Visualización de los flujos de tráfico y las relaciones
entre los servidores. Algunas herramientas pueden
incluso unir direcciones IP, nombres de dominio u
otros datos a ubicaciones físicas y producir un mapa
geográfico de la actividad.
››Construcción de perfiles de actividad típica y la
identificación de desviaciones significativas.
››Contenido de la aplicación de búsqueda de palabras
clave (por ejemplo, confidencial, de propiedad).
En la Tabla VI se lista como ejemplos de herramientas
una serie de utilidades y la URL en la que puede
obtener más información sobre las mismas.

Tipo de software URL*

http://www.honeypots.net/ids/
Sistema de detección de intrusión y prevención
products/

Herramientas de Análisis forense FORENSIX http://www.forensix.org/tools/

http://www.securitywizardry.com/
Herramientas de Análisis forense de redes index.php/products/forensic-
solutions/network-forensic-tools.html
http://searchsecurity.techtarget.com/
Log and SIEM feature/Comparing-the-best-SIEM-
systems-on-the-market
EnCase Cybersecurity.
Herramienta forense que ofrece las siguientes funcionalidades: https://www2.guidancesoftware.com/
›› Detección de Incidentes en red. Lang/Pages/es/EnCase-Cybersecurity.
›› Auditoria de datos. aspx
›› Identificación de comportamientos extraños mediante el análisis de patrones.
EnCase Analytics. https://www2.guidancesoftware.com/
Herramienta que permite la presentación grafica de cuadros de mando para la toma de Lang/Pages/es/EnCase-Analytics.
decisiones en tiempo real, basada en la detección de situaciones potencialmente anómalas. aspx
Security Onion.
Distribución de Linux con una gran variedad de herramientas preinstaladas cuya función no
es otra que analizar redes. En esta distribución encontramos herramientas IDS/IPS como
Snort o Suricata, herramientas para monitorización de eventos de forma gráfica como Squert https://securityonion.net/
o Sguil, herramientas específicas para análisis de tráfico y capturas PCAPs como Wireshark
o NetworkMiner y herramientas de análisis forense como Bro y Xplico. Otras herramientas de
interés y que se apoyan a veces en las ya mencionadas son ELSA, Snorby, etc.
Lookwise SIEM.
Herramienta dentro de la suite de Lookwise con función de SIEM para la recolección y https://www.s21sec.com/es/
procesado de logs. Es posible usar esta herramienta para establecer una cadena de custodia productos/lookwise
de evidencias digitales para su presentación en procesos legales.
Splunk.
http://www.splunk.com/es_es
Herramienta con función de SIEM que permite el análisis de logs de forma detallada.

GasPot.
https://github.com/sjhilt/GasPot
Honeypot que simula medidores de tanques habituales en la industria petrolera y de gas.
Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 55
 3
El informe pericial
tecnológico
 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 57

CONTENIDOS
ESTRUCTURA BÁSICA DEL INFORME FORENSE
OBJETO
ADQUISICIÓN DE PRUEBAS
OPERACIONES DE INVESTIGACIÓN REALIZADAS
CONCLUSIONES
SOBRE LA ROBUSTEZ DEL INFORME
COMUNICACIÓN DEL INFORME PERICIAL
El informe pericial tecnológico

Estructura básica del informe forense
Objeto
La labor forense llevada a cabo por analistas y/o
peritos no podrá considerarse completa sin la
consolidación de los datos obtenidos y los hallazgos
descubiertos durante la fase previa de análisis, en
un documento-resumen que, además, recoja las
principales conclusiones del forense (o forenses) que
hayan tomado parte en el estudio del caso particular.
Dicho escrito constituirá, a modo de informe
final, el verdadero medio de prueba presentable
procesalmente, en aquellos casos en los que la acción
forense tenga finalidad judicial. De igual modo, el
informe forense será fuente clave de las lecciones
aprendidas del caso en curso; unas lecciones que
habrán de servir para la futura superación exitosa de
coyunturas similares a las que haya de enfrentarse
la organización y, en definitiva, para la mejora
continua en la gestión de las acciones orientadas a la
ciberprotección del proceso industrial y de los sistemas
de control que lo sustentan.
En este sentido, y como elemento básico del
informe, su objeto habrá de especificar, al menos, las
motivaciones, antecedentes, actores y pretensiones del
encargo bajo el cual se han abordado las actuaciones
reflejadas en esta pieza documental que resumirá y
concluirá la actuación del perito.
Adquisición de pruebas
Uno de los elementos clave a incorporar en todo
informe de resultados tras un análisis forense sobre
los sistemas de control industrial será el relativo a las
pruebas obtenidas y los hallazgos detectados.
Entre las evidencias analizadas cabe citar números
de serie, información sobre los operarios a cargo del
proceso productivo objeto del análisis o sobre los
custodios de la información tratada, fotografías de
la instalación, etc. Asimismo, si resultase oportuno,
también podría plantearse una clasificación, por
categorías, de los elementos analizados, por ejemplo:
documentos de interés, software empleado que
merezca ser reseñado, actividad de la red (o la
realizada sobre Internet), dispositivos USB empleados,
etc.
Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 59
Operaciones de investigación realizadas
Las normas procesales civiles y penales no establecen
o imponen una metodología a los peritos en cuanto
a la manera en la que han de adquirir y analizar las
evidencias electrónicas, ni en relación a cómo efectuar
un análisis de los resultados de manera adecuada.
Ha de acudirse a buenas prácticas generalmente
aceptadas, así como a estándares locales, nacionales o
internacionales, para encontrar los elementos comunes
de las mejores metodologías.
En ese sentido, sirva como ejemplo el caso de la
norma UNE 197010, publicada en septiembre de
2015 por el organismo normalizador español, AENOR,
que indica que en el cuerpo del informe o dictamen
pericial, y dentro del apartado de análisis se deberán
“…describir las bases y datos de partida establecidos
por el solicitante y los que deriven de:
››La legislación, reglamentación y normativas
aplicables;
››La investigación realizada encaminada a la definición
de las conclusiones;
››Las referencias, documentos, muestras y
procedimientos de toma y conservación de las
mismas que puedan fundamentar las conclusiones
del informe o dictamen pericial.”
Dicha norma establece, asimismo, que deberán ser
identificados los laboratorios, empresas o entidades
que haya participado en la elaboración de cualquier
ensayo o prueba necesaria para la investigación.
Conclusiones
Como elemento final del informe deberán reflejarse,
a modo de conclusiones, los principales puntos que
resuman la opinión del especialista forense sobre lo
ocurrido y sus consecuencias, presentes o a futuro.
Se tratará, en suma, de destacar los aspectos más
relevantes del caso estudiado, tras el análisis realizado.
Esto, a menudo, se materializará en la forma de una
lista concisa de valoraciones y recomendaciones.
60 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial
Sobre la robustez del informe
Al objeto de reducir el riesgo de desacreditación del
propio informe, así como de la calidad del trabajo
realizado en su conjunto, el perito ha de cuidarse
mucho de introducir debilidades, tanto técnicas, cuanto
-particularmente- conceptuales, en su informe.
En ese sentido se ofrece, a continuación, una relación
de los aspectos que pueden resultar más relevantes
(respectivamente, amenazadores) para la robustez de
un informe pericial, desde la óptica de su defensa ante
las partes a quienes irá dirigido:
››La autoridad de quien realiza el encargo sobre el
alcance a considerar, así como la autorización,
otorgada por aquél, a quien lo haya de ejecutar
resultan fundamentales, como garantía de legitimidad
de las actuaciones a realizar en el transcurso del
análisis. Junto a ellas, deberá reflejarse -y, como
medida de prudencia, limitarse- cualquier situación
que pueda implicar la “manipulación” de cualesquiera
activos físicos, o de información, potestad de
terceros.
››El alcance de los trabajos encomendados ha de
quedar perfectamente entendido y reflejado. De
hecho, huelga decir que toda desambiguación que
tenga lugar en el momento mismo del encargo, irá
en interés de quien haya de realizarlo, por razones
obvias de practicidad y economía de esfuerzos.
Del mismo modo, la mayor nitidez en lo relativo al
perímetro, interdependencias y, muy especialmente,
expectativas sobre lo encargado, contribuirá
favorablemente a la receptividad de los destinatarios.
››Las evidencias recopiladas o adquiridas en
el transcurso del análisis constituyen la clave
fundamental de toda actuación forense, puesto
que, a partir de ellas, se alcanzarán las esperadas
conclusiones del análisis. Por tal motivo, las
evidencias han de conservar su estado de origen,
sin posibilidad de ser manipuladas o, de cualquier
otra manera, contaminadas o corrompidas. En caso
contrario, su hipotético deterioro podría llegar a
invalidar las respuestas o conclusiones obtenidas.
En este punto, por tanto, entra en juego el papel de
la cadena de custodia, como garante de la correcta
recopilación y preservación, incluidas su identificación
y registro, de las evidencias.
››La comprensibilidad del informe en lo relativo al
análisis realizado -ha de resultar inteligible para
aquella parte de la audiencia no especializada en
la materia técnica (letrados y jueces, por ejemplo)-,
deberá quedar garantizada como premisa de la
aprobación, por parte de quienes las reciben, de las
conclusiones finales del perito. Paralelamente, una
claridad y riqueza de detalles técnicos suficientes
harán del informe una pieza de fácil revisión,
valoración e, incluso, llegado el caso, reproducción,
por parte de terceros, también peritos conocedores
de la materia, que puedan ofrecer una opinión
independiente sobre el mismo.
››La reproducibilidad, en un momento posterior,
de los trabajos llevados a cabo in situ resulta de
interés, por cuanto puede facilitar la obtención de
información o evidencias adicionales a las obtenidas
en campo y que pudieron haber pasado inadvertidas
en el momento inicial. Cuando tal repetibilidad -en
igualdad de condiciones al campo- no es factible,
tales nuevas evidencias perderán su pretendida
validez. En todo caso, resulta imprescindible reflejar
en el informe pericial el proceso detallado llevado a
cabo (fases y tiempo empleado, medios utilizados,
actores involucrados -entrevistados, etc.-, …).
››La proporcionalidad, relativa a esfuerzos empleados
(tiempo, recursos, etc.), ha de regir la profundidad
con que se lleve a cabo el encargo sobre el alcance
definido. Ello podrá traducirse en una limitación
de la cantidad de evidencias obtenidas, siempre en
función de lo que dicte, también, el sentido común y
la relevancia de la evidencia para la conclusión que
se trata de alcanzar. Otro criterio puede derivar en un
informe excesivamente voluminoso, farragoso y difícil
de entender, lo que le restará valor y no contribuirá,
sino a minar las expectativas de sus destinatarios.
››La objetividad reflejada a lo largo de toda la
actuación del perito, y, particularmente, de su
informe, garantizará su equidistancia con los hechos
analizados y valorados en el transcurso del encargo
que ha recibido. Todo lo recogido en el informe
ha de poder contrastarse. De otro modo, podrían
llegar a tergiversarse o invalidarse las conclusiones
alcanzadas.
››Finalmente, la confidencialidad deberá, asimismo,
explicitarse en el informe pericial por tratarse de una
de las obligaciones del perito.
 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 61

Comunicación del informe pericial

El hito que, verdaderamente, ha de marcar el fin
de proceso forense es el de la comunicación de los
resultados y conclusiones. Un excelente trabajo de
campo, reflejado en un, no menos impecable, informe
pericial pueden, a pesar de las recomendaciones
recogidas en el epígrafe anterior, irse al traste, si no
van acompañados de una adecuada comunicación
a quienes constituyan su audiencia destinataria
(técnicos, mandos intermedios, directivos, abogados,
jueces, etc.).
Por tal motivo, a alguno de los aspectos clave
destacados anteriormente, como los relativos a
comprensibilidad, objetividad, proporcionalidad,
confidencialidad, que, sin duda, han de formar parte,
también, de la tarea de comunicación, han de sumarse
otros relacionados con las capacidades interpersonales
y de comunicación del perito.
Todos esos atributos, junto a un adecuado enfoque
que contemple, cuando presentar el informe, a quién
dirigirlo, qué tiempo emplear en su presentación, etc.,
jugarán, sin duda, a favor de la credibilidad del forense
y de sus conclusiones sobre los hechos estudiados.
62 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial

GLOSARIO
APT Advanced Persitent Threat (Amenazas Persistentes Avanzadas)

Buffer Overflow Desbordamiento de la memoria

CHECKSUM Suma de chequeo o verificación

CVE Common Vulnerabilities and Exposures (Vulnerabilidades y Exposiciones comunes)

DCS Distributed Control System (Sistema de Control Distribuido)

DMZ Demilitarized Zone (Zona desmilitarizada)

ERP Enterprise Resource Planinng (Planificación de Recursos Empresariales)

FTP File Transfer Protocol (Protocolo de transferencia de ficheros)

GNU/GPL General Public License (Licencia Pública General)

HASH Función computable mediante un algoritmo utilizado como representación resumen de

una cadena de entrada

HMI Human-Machine Interface (Interfaz hombre-máquina)

HTTP HyperText Transfer Protocol (Protocolo de tranferencia de hipertexto)

ICS Industrial Control System (Sistema de controliIndustrial)

IDS Intrusion Detection System (Sistema de detección de intrusiones)

IP Internet Protocol (Protocolo de internet)

IPS Intrusion Prevention System (Sistema de prevención de intrusiones)

IT Information Technology (Tecnologías de información)

LEC Ley de Enjuiciamiento Civil

LECrim Ley de Enjuiciamiento Criminal

MES Manufacturing Execution System (Sistema de ejecución de la fabricación)

 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 63

MODBUS TCP Protocolo de comunicaciones industriales muy extendido

MTU Master Unit Control (Unidad de control maestra)

NAT Network Address Translation (Traducción de direcciones de red)

NFATs Network Forensic Analisys Tools (Herramientas de Análisis forense de Red)

OPC OLE for Process Control (Control de Procesos mediante OLE)

OPC UA OLE for Process Control – Unified Architecture (Arquitectura unificada)

OT Operational Technology (Tecnologías de la Operación)

PLC Programmable Logic Controller (Contralador Lógico Programable)

PAYLOAD Datos transmitidos en una comunicación

PERICIAL Perteneciente o relativo al perito

PROFINET Estándar Ethernet Industrial basado en IEEE 802.xx.

RTU Remote Terminal Unit (Unidad terminal remota)

RFC Request for Comments (Solicitud de comentarios)

SCADA Supervisory Control And Data Acquisition (Supervisión, control y adquisición de datos)

SIEM Security Information and Event Management (Gestión de eventos e información de

seguridad)

SNMP Simple Network Management Protocol (Protocolo simple de gestión de red)

TI Tecnologías de la Información

UNE 197010 Norma de Criterios generales para elaboración de informes periciales

UNE 71505 Norma sobre el Sistema de Gestión de Evidencias Electrónicas

UNE-EN 16775 Norma sobre Requisitos generales para los servicios

64 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial

REFERENCIAS Y DIRECCIONES DE INTERÉS

AENOR. “UNE 71505-1:2013. Tecnologías de la Información (TI). Sistema de Gestión de Evidencias Electrónicas (SGEE). Parte 1:
Vocabulario y principios generals”. 3 de julio de 2013.
URL: http://www.aenor.es/aenor/normas/normas/fichanorma.asp?tipo=N&codigo=N0051411#.V9nh5piLRhE

AENOR. “UNE 71505-2:2013. Tecnologías de la Información (TI). Sistema de Gestión de Evidencias Electrónicas (SGEE). Parte 2:
Buenas prácticas en la gestión de las evidencias electrónicas”. 3 de julio de 2013.
URL: http://www.aenor.es/aenor/normas/normas/fichanorma.asp?tipo=N&codigo=N0051412#.V9niPJiLRhE

AENOR. “UNE 71505-3:2013. Tecnologías de la Información (TI). Sistema de Gestión de Evidencias Electrónicas (SGEE). Parte 3:
Formatos y mecanismos técnicos”. 3 de julio de 2013.
URL: http://www.aenor.es/aenor/normas/normas/fichanorma.asp?tipo=N&codigo=N0051413#.V9nitpiLRhE

AENOR. “UNE 71506:2013. Tecnologías de la Información (TI). Metodología para el análisis forense de las evidencias electrónicas”.
3 de julio de 2013.
URL: http://www.aenor.es/aenor/normas/normas/fichanorma.asp?tipo=N&codigo=N0051414#.V9ni-ZiLRhE

AENOR. “UNE 197001:2011 Criterios generales para la elaboración de informes y dictámenes periciales”. 23 de marzo de 2011.
URL: http://www.aenor.es/aenor/normas/normas/fichanorma.asp?tipo=N&codigo=N0046980#.V9nhHpiLRhE

Anguas Balsera, Joaquín. “El peritaje en informática en el marco de las disciplinas que le son afines. Puntos de contacto y perfil de
la actividad”.
URL: http://www.anguas.com/e1m6/Docs/LA_LEY_Cuadernos_de_Probatica_Posicion_del_Perito_en_Informatica.pdf

Asociación Nacional de Ciberseguridad y Pericia Tecnológica

URL: http://www.ancite.es

Asociación Nacional de Tasadores y Peritos Judiciales Informáticos (ANTPJI).

URL: http://www.antpji.com

Consejo de Europa. “Convenio sobre la Ciberdelincuencia”. Budapest, 23 de noviembre de 2001.

URL: https://rm.coe.int/CoERMPublicCommonSearchServices/DisplayDCTMContent?documentId=09000016802fa41c

Dittrich, David; y otros. “Análisis Forense de Sistemas”. GNU/Linux, UNIX. Contribución Congreso HISPALINUX
URL: http://www.it-docs.net/ddata/470.pdf

Fabro, Mark; y Eric Cornelius. “Recommended Practice: Creating Cyber Forensics Plans for Control Systems”. DHS (EEUU), agosto
de 2008.
URL: https://ics-cert.us-cert.gov/sites/default/files/recommended_practices/Forensics_RP.pdf

Folkerth, Lew. “Forensic Analysis of Industrial Control Systems”. SANS Institute. InfoSec Reading Room, 24 de septiembre de 2015.
URL: https://www.sans.org/reading-room/whitepapers/forensics/forensic-analysis-industrial-control-systems-36277

Garnett, Brad. “Intro to Report Writing for Digital Forensics”. SANS. Bitácora electrónica “Digital Forensics and Incident Response”,
25 de agosto de 2010.
URL: https://digital-forensics.sans.org/blog/2010/08/25/intro-report-writing-digital-forensics#
 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 65

Garrie, Daniel B. “How to Evaluate a Digital Forensic Report – Part 1”. Thomson Reuters. Bitácora electrónica “Legal Solutions”.
Sección “Practice of Law. Best practices and solutions for legal professionals”, 7 de enero de 2014.
URL: http://blog.legalsolutions.thomsonreuters.com/practice-of-law/evaluate-digital-forensic-report-part-1/

Garrie, Daniel B. “How to Evaluate a Digital Forensic Report – Part 2: Daubert”. Thomson Reuters. Bitácora electrónica “Legal
Solutions”. Sección “Practice of Law. Best practices and solutions for legal professionals”, 14 de enero de 2014.
URL: http://blog.legalsolutions.thomsonreuters.com/practice-of-law/evaluate-digital-forensic-report-part-2-daubert/

Garrie, Daniel B. “How to Evaluate a Digital Forensic Report – Part 3: Experts”. Thomson Reuters. Bitácora electrónica “Legal
Solutions”. Sección “Practice of Law. Best practices and solutions for legal professionals”, 21 de enero de 2014.
URL: http://blog.legalsolutions.thomsonreuters.com/practice-of-law/evaluate-digital-forensic-report-part-3-experts/

Garrie, Daniel B. “How to Evaluate a Digital Forensic Report – Part 4”. Thomson Reuters. Bitácora electrónica “Legal Solutions”.
Sección “Practice of Law. Best practices and solutions for legal professionals”, 28 de enero de 2014.
URL: http://blog.legalsolutions.thomsonreuters.com/practice-of-law/evaluate-digital-forensic-report-part-4/

Hernando, Sergio. “Mi primera conexión con Power Line Communications (PLC)”. Bitácora electronica “Sergio Hernando. Seguridad
de la Información, Análisis Forense y Auditoría de Sistemas”, 6 de junio de 2007.
URL: http://www.sahw.com/wp/archivos/2007/06/06/mi-primera-conexion-con-power-line-communications-plc/

International Organization for Standardization/International Electrotechnical Commission. “ISO/IEC 27037:2012. Information

Technology. Security Techniques. Guidelines for identification, collection, acquisition and preservation of digital evidence”. 15 de
octubre de 2012.
URL: http://www.iso.org/iso/catalogue_detail?csnumber=44381

International Organization for Standardization/International Electrotechnical Commission. “ISO/IEC 27038:2014. Information

Technology. Security Techniques. Specification for digital redaction”. 15 de marzo de 2014.
URL: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=44382

International Organization for Standardization/International Electrotechnical Commission. “ISO/IEC 27040:2015. Information

Technology. Security Techniques. Storage security”. 15 de enero de 2015.
URL: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=44404

International Organization for Standardization/International Electrotechnical Commission. “ISO/IEC 27041:2015. Information

Technology. Security Techniques. Guidance on assuring suitability and adequacy of investigation methods”. 15 de junio de 2015.
URL: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=44405

International Organization for Standardization/International Electrotechnical Commission. “ISO/IEC 27042:2015. Information

Technology. Security Techniques. Guidelines for analysis and interpretation of digital evidence”. 15 de junio de 2015.
URL: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=44406

International Organization for Standardization/International Electrotechnical Commission. “ISO/IEC 27043:2015. Information

Technology. Security Techniques. Incident investigation principles and processes”. 1 de marzo de 2015.
URL: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=44407

Kelley, Melia. “Report Writing Guidelines”. Digital Forensic Investigator News, 30 de mayo de 2012.
URL: http://www.forensicmag.com/articles/2012/05/report-writing-guidelines
66 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial

Kent, Karen; y otros. “Guide to integrating forensic techniques into incident response“. National Institute of Standards and
Technology (NIST) Special Publication 800-86. Agosto de 2006.
URL: http://csrc.nist.gov/publications/nistpubs/800-86/SP800-86.pdf

Kent, Karen; y Murugiah Souppaya. “Guide to computer Security Log Management”. National Institute of Standards and Technology
(NIST) Special Publication 800-92. Septiembre de 2006.
URL: http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-92.pdf

López Delgado, Miguel. “Análisis Forense Digital”. 2ª edición, junio de 2007.

URL: http://www.oas.org/juridico/spanish/cyb_analisis_foren.pdf

López Rivera, Rafael. “Las cuatro funciones de cobertura de un informe pericial”. Bitácora electrónica “Perito IT. Peritaje Informático
y Tecnológico”, 18 de abril de 2014.
URL: https://peritoit.com/2014/04/18/las-4-fcs-de-un-informe-pericial/

López Rivera, Rafael. “Siete debilidades del informe pericial”. Bitácora electrónica “Perito IT. Peritaje Informático y Tecnológico”, 18
de abril de 2016.
URL: https://peritoit.com/2016/04/18/7-debilidades-del-informe-pericial/

López Rivera, Rafael. “La cadena de custodia es una garantía formal, pero no es una prueba”. Bitácora electrónica “Perito IT.
Peritaje Informático y Tecnológico”, 9 de septiembre de 2014.
URL: https://peritoit.com/2014/09/09/la-cadena-de-custodia-es-una-garantia-formal-pero-no-es-una-prueba/

National Institute of Justice (USA). “Crime Scene Investigation: Guides for Law Enforcement. Glossary”.
URL: http://www.nij.gov/topics/law-enforcement/investigations/crime-scene/guides/pages/glossary.aspx

Páez, Rafael. “Análisis forense en sistemas Linux – Obteniendo información (Parte 1)”. S2Grupo. Bitácora electrónica “SECURITY
A(r)TWORK”, 29 de mayo de 2012.
URL: http://www.securityartwork.es/2012/05/29/analisis-forense-en-sistemas-linux-obteniendo-informacion-parte-1/

Reino de España. “Ley 1/2000, de 7 de enero, de Enjuiciamiento Civil”. Boletín Oficial del Estado de 28 de octubre de 2015.
URL: https://www.boe.es/buscar/pdf/2000/BOE-A-2000-323-consolidado.pdf

Reino de España. “Ley Orgánica 10/1995, de 23 de noviembre, del Código Penal”. Boletín Oficial del Estado de 28 de abril de
2015.
URL: https://www.boe.es/buscar/pdf/1995/BOE-A-1995-25444-consolidado.pdf

Reino de España. “Ley Orgánica 13/2015, de 5 de octubre, de modificación de la Ley de Enjuiciamiento Criminal para el
fortalecimiento de las garantías procesales y la regulación de las medidas de investigación tecnológica”.
URL: https://www.boe.es/boe/dias/2015/10/06/pdfs/BOE-A-2015-10725.pdf

Reino de España. “Real decreto de 14 de septiembre de 1882 por el que se aprueba la Ley de Enjuiciamiento Criminal”. Boletín
Oficial del Estado de 6 de octubre de 2015.
URL: https://www.boe.es/buscar/pdf/1882/BOE-A-1882-6036-consolidado.pdf
 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 67

Silverhack. “Introducción a la informática forense en entornos Windows 1ª parte”. ElHacker.net, 8 de agosto de 2006.
URL: https://www.elhacker.net/InfoForenseWindows.html

Stirland, Joe; y otros. “Developing Cyber Forensics for SCADA Industrial Control Systems”. 24 de mayo de 2016.
URL: https://www.researchgate.net/publication/266477470_Developing_Cyber_Forensics_for_SCADA_Industrial_Control_Systems

Vaishnavi, Vijay; y Bill Kuechler. “Design science research in information systems”. 24 de enero de 2004 (actualizado el 15 de
noviembre de 2015).
URL: http://desrist.org/desrist/content/design-science-research-in-information-systems.pdf
68 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial

AUTORES Y COLABORADORES
Nombre Compañía Autor Colaborador Revisor
Miguel García-Menéndez CCI
José Valiente CCI
Paloma Llaneza Experta CCI - Razona Legaltech
Joan Figueras Experto CCI - BROSA
Claudio Caracciolo Experto CCI - Eleven Paths
Gustavo Presman Experto CCI - Estudio de Informática Forense
Hector Puyosa Experto CCI - SABIC
Ignacio Álvarez Experto CCI - SIEMENS
Javier Calmuntia 3M
Covadonga Villacorta Accenture
David Pérez Accenture
Samuel Linares CCI /BAH
Ignacio Paredes CCI /BAH
Rafael Hernández Cepsa
Sergio Lozano Check Point
Eutimio Fernández Cisco
Jose Valdelvira CLH
Rafael Picazo CLH
Miguel Ángel Abad CNPIC
Jorge Cerqueiro COITVIGO
Arturo Trujillo DEKRA
Antonio Santana Enel
David Saez Enel
Ricardo Cañizares Eulen Seguridad
María Pilar Torres Everis
Jose Luis Laguna Fortinet
Pablo Barreiro Gas Natural Fenosa
Andreu Bravo Gas Natural Fenosa
Javier Zubieta GMV
Ricardo González Grupo TSK
Luis Aguiló Iberdrola
Eusebio García Iberdrola
Marcos Gómez Incibe
Carlos Asún Initec
Juana Higuera Initec
 Buenas prácticas en el Análisis Forense de Sistemas de Automatización y Control Industrial 69

Nombre Compañía Autor Colaborador Revisor

Susana Suárez Intermark
Raquel Mateos ISA España
Diego Zuluaga ISAGEN
Claudio Caracciolo ISSA Argentina
Iñaki Eguía ITS Security
Arkaitz Gamino ITS Security
José Ramón Concha ITS Security
Javier Dieguez Minsait
Manuel Escalante Minsait
Álvaro Sampedro Phoenix Contact
David Corral Repsol
Erik de Pablo Rutilus
Aaron Flecha S21Sec
Enrique Martín S21Sec
Andrés Núñez S2Grupo
José Rosell S2Grupo
Jesús Friginal SCASSI
Mariano del Rio SecureTech
Lorenzo Martínez Securizame
Elena Ortuondo Sener
Jose María Rivera Sener
David del Pozo Siemens
Juan Carlos Pozas Siemens
Jose Luis Donoso Siemens
Beatriz Martínez SIGEA
Jesús Mérida Técnicas Reunidas
David Marco Técnicas Reunidas
Juan Bautista López Tecnocom
Delia Boga Tecnocom
Manuel Muñiz Telefónica
Ignacio García Telefónica
Borja Lanseros Titanium Industrial Security
Daniel Herreras Titanium Industrial Security
David Domingos Titanium Industrial Security
Rodolfo Rodríguez Tragsa
C/ Maiquez, 18 · 28009 MADRID
Tel.: +34 910 910 751
e-mail: info@CCI-es.org
www.CCI-es.org
Blog: blog.CCI-es.org
Twitter: @info_CCI