sistema de gestiÓn de incidentes de seguridad …
TRANSCRIPT
1
SISTEMA DE GESTIÓN DE INCIDENTES DE SEGURIDAD INFORMÁTICA
PARA CORBETA
LYDA DURLEY MONA CARDONA
ANDRES ESTEBAN URIBE SERNA
Proyecto presentado para optar al título de Especialista en Seguridad Informática
Asesor
Juan Esteban Velásquez Múnera. Consultor de Negocios y Tecnología
ISO 27001 Auditor
UNIVERSIDAD DE SAN BUENAVENTURA SECCIONAL MEDELLÍN
FACULTAD DE INGENIERÍAS
ESPECIALIZACIÓN EN SEGURIDAD INFORMÁTICA
MEDELLÍN
2015
2
ÍNDICE
1 JUSTIFICACIÓN ________________________________________________________ 4
2 PLANTEAMIENTO DEL PROBLEMA ________________________________________ 5
3 OBJETIVO GENERAL ____________________________________________________ 6
3.1 OBJETIVOS ESPECÍFICOS __________________________________________________ 6
4 MARCO REFERENCIAL __________________________________________________ 7
5 DISEÑO METODOLÓGICO PRELIMINAR ___________________________________ 10
5.1 ANÁLISIS GAP _________________________________________________________ 11
5.2 CLASIFICACIÓN DE LOS INCIDENTES DE SEGURIDAD. __________________________ 11
5.3 RECOLECCIÓN DE DATOS_________________________________________________ 12
5.4 HERRAMIENTA DE GESTIÓN DE INCIDENTES DE SEGURIDAD ____________________ 12
5.5 CICLO DE VIDA DE UN INCIDENTE __________________________________________ 13
6 CRONOGRAMA ______________________________________________________ 15
7 QUÉ ES UN SISTEMA DE GESTIÓN DE INCIDENTES DE SEGURIDAD SEGÚN ISO 27035
16
7.1 QUÉ ES UN ISIRT EQUIPO DE RESPUESTA A INCIDENTES DE SEGURIDAD DE LA
INFORMACIÓN. ______________________________________________________________ 17
7.2 QUÉ ES UN INCIDENTE DE SEGURIDAD ______________________________________ 18
7.3 PARA QUÉ UN SISTEMA DE GESTIÓN DE INCIDENTES DE SEGURIDAD. ____________ 19
8 SISTEMA DE GESTIÓN DE INCIDENTES DE SEGURIDAD DE LA INFORMACIÓN PARA
CORBETA _______________________________________________________________ 21
8.1 POLÍTICA PROPUESTA QUE APOYARA EL SISTEMA DE GESTIÓN DE INCIDENTES DE
SEGURIDAD _________________________________________________________________ 25
8.2 POSIBLES INCIDENTES DE SEGURIDAD QUE PODRÍAN AFECTAR LA ORGANIZACIÓN. _ 28
8.2.1 Plan de tratamiento, controles propuestos. ________________________________________ 38
8.3 CLASIFICACIÓN Y EVALUACIÓN DE LOS TIPOS DE INCIDENTES DE SEGURIDAD QUE SE
PRESENTAN EN LA EMPRESA. ___________________________________________________ 39
8.3.1 Clasificación de los incidentes de seguridad: _______________________________________ 39
8.3.2 Evaluación de los incidentes de seguridad: ________________________________________ 41
3
8.3.3 Identificar si un evento de seguridad de la información es un incidente. _________________ 43
8.4 HERRAMIENTAS DE GESTIÓN DE INCIDENTES DE SEGURIDAD ___________________ 46
8.4.1 Mesa de servicios en Corbeta ___________________________________________________ 46
8.4.2 Evaluación de herramientas basadas en ITIL. _______________________________________ 47
8.5 ACCIONES CORRECTIVAS Y PREVENTIVAS ANTE INCIDENTES CONOCIDOS. _________ 58
8.6 PLAN DE MEJORAMIENTO CONTINUO ANTE LOS INCIDENTES DE SEGURIDAD. _____ 61
9 CONCLUSIONES ______________________________________________________ 63
10 REFERENCIAS BIBLIOGRÁFICAS ________________________________________ 65
LISTA DE TABLAS _________________________________________________________ 68
LISTA DE FIGURAS ________________________________________________________ 69
GLOSARIO ______________________________________________________________ 70
4
1 JUSTIFICACIÓN
La información en las organizaciones es el activo más preciado, estas invierten
grandes cantidades en dinero, tiempo y recursos para proteger sus activos tanto
de amenazas externas como internas, hace unos años las organizaciones
manejaban toda la información en un solo lugar, eran dueños de la infraestructura,
los equipos de cómputo, la red informática, pero el aumento de servicios en la
nube, el uso de dispositivos móviles, las redes sociales, genero un aumento del
riesgo de fuga de información. Poder detectar, gestionar, clasificar, atender, medir
y solucionar los distintos incidentes que pueden suceder en la empresa, es de
gran importancia pues los sucesos fortuitos acarrean pérdidas económicas que
ninguna organización está dispuesta a pagar.
“Las organizaciones deben darse cuenta que nadie es inmune a una violación de
seguridad. El tiempo que una organización tarda en identificar una intrusión es un
factor que agrava este problema, ya que puede tomar semanas o meses identificar
un sistema comprometido, cuando atacar a una organización puede tomar minutos
o incluso horas”. (Worth, 2014)
5
2 PLANTEAMIENTO DEL PROBLEMA
En la actualidad las amenazas a la información en las empresas son latentes tanto
dentro como fuera de estas, llegando a tener casos que ponen en riesgo toda la
infraestructura tecnológica y en muchos de estos teniendo como consecuencias
perdidas de información y/o perdidas económicas. Es por esto que se vuelve
importante proteger la información que se convierte en el activo más importante de
la organización.
Según la norma ISO 27035, “Un incidente de seguridad de la información es
indicado por un único o una serie de eventos indeseados o inesperados de
seguridad de la información que tienen una probabilidad significativa de
comprometer las operaciones de negocio y de amenazar la seguridad de la
información”. (GUÍA TÉCNICA COLOMBIANA GTC-ISO/IEC 27035, 2012, pág. 3)
“Cualquier evento que no forma parte de la operación estándar de un servicio y
que causa, o puede causar, una interrupción o una reducción de calidad del
mismo”. (Gestión de Incidentes, s.f.)
Según lo anterior, se pretende analizar una solución en la que se puedan
gestionar los incidentes de seguridad informática ocurridos dentro de Corbeta,
para así poder implementar acciones correctivas y preventivas oportunas en los
casos que se puedan seguir presentando.
6
3 OBJETIVO GENERAL
Proponer una solución de gestión de incidentes de seguridad informática, que
permita el registro, clasificación, notificación, escalamiento y respuesta oportuna a
los sucesos ocurridos en Corbeta.
3.1 OBJETIVOS ESPECÍFICOS
Verificar las políticas que apoyaran el sistema de gestión.
Identificar los distintos incidentes de seguridad que pueden afectar la
organización.
Clasificar y evaluar según su criticidad los diferentes tipos de incidentes de
seguridad que se presentan actualmente en la empresa.
Analizar una posible herramienta de gestión de incidentes de seguridad.
Plantear acciones correctivas y preventivas ante incidentes conocidos.
Presentar un plan de mejoramiento continuo ante los incidentes de
seguridad.
7
4 MARCO REFERENCIAL
El marco teórico sobre el que se sustentará el proyecto se basa en las normas
ISO/IEC 27035, ISO/IEC 27001, estándares internacionales como CSIRT, ITIL
Que ofrecen las mejores prácticas para lograr el mejoramiento continuo de la
seguridad de la información en la empresa.
ISO, es el organismo encargado de promover el desarrollo de normas
internacionales de fabricación (tanto de productos como de servicios), comercio y
comunicación para todas las ramas industriales. Su función principal es la de
buscar la estandarización de normas de productos y seguridad para las empresas
u organizaciones (públicas o privadas) a nivel internacional. (Organización
Internacional de Normalización, 2015)
ICONTEC. El Instituto Colombiano de Normas Técnicas y Certificación
(ICONTEC), es el Organismo Nacional de Normalización de Colombia. Entre sus
labores se destaca la creación de normas técnicas y la certificación de normas de
calidad para empresas y actividades profesionales. ICONTEC es el representante
de la Organización Internacional para la Estandarización (ISO), en Colombia.
(Instituto Colombiano de Normas Técnicas y Certificación, 2015)
ITIL. La Biblioteca de Infraestructura de Tecnologías de Información,
frecuentemente abreviada ITIL (del inglés Information Technology Infrastructure
Library), es un conjunto de conceptos y buenas prácticas para la gestión de
servicios de tecnologías de la información, el desarrollo de tecnologías de la
información y las operaciones relacionadas con la misma en general. ITIL da
descripciones detalladas de un extenso conjunto de procedimientos de gestión
ideados para ayudar a las organizaciones a lograr calidad y eficiencia en las
operaciones de TI. Estos procedimientos son independientes del proveedor y han
sido desarrollados para servir como guía que abarque toda infraestructura,
8
desarrollo y operaciones de TI. (Information Technology Infrastructure Library,
2015)
Norma ISO 27000. ISO/IEC 27000 es un conjunto de estándares desarrollados -o
en fase de desarrollo por ISO (International Organization for Standardization) e
IEC (International Electrotechnical Commission), que proporcionan un marco de
gestión de la seguridad de la información utilizable por cualquier tipo de
organización, pública o privada, grande o pequeña. (ISO27000, pág. 2)
NORMA ISO 27001. Es un estándar ISO que proporciona un modelo para
establecer, implementar, utilizar, monitorizar, revisar, mantener y mejorar un
Sistema de Gestión de Seguridad de la Información (SGSI). Se basa en el ciclo de
vida PDCA (Planear-Hacer-Verificar-Actuar; o ciclo de Deming) de mejora
continua, al igual que otras normas de sistemas de gestión.
Este estándar es certificable, es decir, cualquier organización que tenga
implantado un SGSI según este modelo, puede solicitar una auditoria externa por
parte de una entidad acreditada y, tras superar con éxito la misma, recibir la
certificación en ISO 27001. (ISO27000, 2005)
ISO/IEC 27035 establece un enfoque estructurado y planificado para:
Detectar, informar y evaluar los incidentes de seguridad de información;
Responder a incidentes y gestionar incidentes de seguridad de la
información;
Detectar, evaluar y gestionar las vulnerabilidades de seguridad de la
información,
Mejorar continuamente la seguridad de la información y la gestión de
incidentes, como resultado de la gestión de incidentes de seguridad de la
información y las vulnerabilidades. (GUÍA TÉCNICA COLOMBIANA GTC-
ISO/IEC 27035, 2012, pág. 1)
9
CSIRT. Computer Security Incident Response Team`
“Equipo de Respuesta a Incidentes de Seguridad Informática". Para los propósitos
de este documento, un CSIRT es un equipo que ejecuta, coordina y apoya la
respuesta a incidentes de seguridad que involucran a los sitios dentro de una
comunidad definida. Cualquier grupo que se autodenomina un CSIRT debe
reaccionar a incidentes de seguridad reportados así como a las amenazas
informáticas de “su” comunidad”. (GESTIÓN DE INCIDENTES DE SEGURIDAD
INFORMÁTICA, 2009, pág. 15)
10
5 DISEÑO METODOLÓGICO PRELIMINAR
El proyecto tiene como base la investigación aplicada, donde se pretende evaluar,
según las normas, estándares y mejores prácticas, una serie de procedimientos y
políticas que minimicen los incidentes de seguridad de la información, poniendo en
práctica de una manera sistemática y cíclica la mejora continua en los procesos
involucrados.
“Partiendo de que, las políticas o controles de seguridad de la información por sí
solas no garantizan la protección total de la información, de los sistemas de
información, o de los servicios o redes. Después de que los controles se han
implementado, es posible que queden vulnerabilidades residuales que pueden
hacer ineficaz la seguridad de la información y, en consecuencia, hacer posibles
incidentes de seguridad de la información. Potencialmente, esto puede tener
impactos adversos directos e indirectos sobre las operaciones de los negocios de
una organización, que pueden conducir inevitablemente a que ocurran nuevos
casos de amenazas no identificadas previamente. Una preparación insuficiente de
una organización para abordar este tipo de incidentes hará que cualquier
respuesta sea menos eficaz, y que se incremente el grado de impacto adverso
potencial en el negocio. Por tanto, es esencial que cualquier organización con
interés auténtico en la seguridad de la información, tenga un enfoque estructurado
y planificado” (GUÍA TÉCNICA COLOMBIANA GTC-ISO/IEC 27035, 2012, pág. 1)
11
5.1 ANÁLISIS GAP
GAP (del inglés, análisis de brecha) se realizara un análisis GAP en el que se
contraste la situación actual de los controles y las políticas de seguridad contra la
norma verificando cual sería el estado esperado o ideal. Entendiendo que las
diferencias entre ambas situaciones son las brechas que se desean eliminar o el
horizonte al que se pretende llegar. Con un análisis GAP se aspira analizar el
estado actual para determinar planes de acción y mejoras indagando que tan lejos
se está de los estándares, normas y prácticas más usados en la industria (ISO,
ITIL, COBIT…) mencionadas en el marco referencial.
El resultado del análisis y el estado actual lleva a la identificación de los posibles
riesgos a los que está expuesta la organización y que pueden convertirse en
posibles incidentes que se clasifican según la criticidad y el impacto que pueden
generar.
5.2 CLASIFICACIÓN DE LOS INCIDENTES DE SEGURIDAD.
Los incidentes de seguridad tienen su origen en las distintas amenazas y
vulnerabilidades que son inherentes a los sistemas informáticos, estos se pueden
dividir según su impacto, criticidad, dependiendo del activo o información
comprometida. Un activo debe tener una clasificación según su importancia dentro
de la organización, igualmente los incidentes se pueden clasificar calculando los
efectos negativos producidos por el incidente, más la criticidad de los activos
afectados teniendo como resultado la criticidad el incidente.
12
5.3 RECOLECCIÓN DE DATOS
Para verificar el estado actual de la infraestructura tecnológica se realizará
recolección de datos, encuestas a algunas de las personas involucradas con los
sistemas TIC para analizar los riesgos y vulnerabilidades que se presentan en la
gestión de incidentes y así detectarlos, analizarlos, clasificarlos y poder analizar
las políticas que apoyaran el sistema de gestión de incidentes. Es importante
también en la recolección de datos verificar el estado de los equipos de cómputo,
servidores, dispositivos de red, haciendo un rastreo de los registros de eventos, de
las aplicaciones y procesos que se ejecutan en las maquinas, conexiones de red
establecidas, puertos abiertos permitidos y aplicaciones que usan dichos puertos,
esto con el fin de comprender el funcionamiento normal de la infraestructura y
poder detectar cualquier cambio sutil anormal que pueda manifestarse como
inseguro o riesgoso, para proceder así a analizar su naturaleza.
5.4 HERRAMIENTA DE GESTIÓN DE INCIDENTES DE SEGURIDAD
Analizar qué tipo de herramienta se ajusta a las necesidades de la empresa en la
gestión de incidente de seguridad informática, para así poder tomar acciones
correctivas y preventivas en busca de una mejora continua y que este no origine
sucesos de seguridad repetitivos en la empresa. Poder detectar mediante
auditorias, informes y log de seguridad cualquier eventualidad de seguridad
informática que perjudiquen, dañen o ponga en indisponibilidad los activos
informáticos o la información de la empresa y ser resueltos en el menor tiempo
posible. Para poder llevar un control de lo anterior se debe pensar en una
herramienta de gestión de incidentes que sea capaz de registrar y clasificar los
incidentes, clasificándolos según su criticidad para proceder a tomar acciones
correctivas y mitigar los riesgos que traen consigo los incidentes.
13
5.5 CICLO DE VIDA DE UN INCIDENTE
Un incidente de seguridad de la información se define como un acceso,
intento de acceso, uso, divulgación, modificación o destrucción no autorizada
de información, un impedimento en la operación normal de las redes,
sistemas o recursos informáticos, o una violación de la política de seguridad.
El ciclo de vida de un incidente se divide en diferentes fases:
- Fase inicial (preparación y prevención, y detección y pre análisis).
- Contención, erradicación y recuperación (notificación, análisis, contención y
erradicación).
- Recuperación del incidente (recuperación).
- Actividad después del incidente (reflexión y documentación).
“La información generada por los diferentes incidentes permite responder de forma
sistemática, minimizar su ocurrencia y facilitar una recuperación rápida y eficiente
de las actividades.
También ayuda a minimizar la pérdida de información y la interrupción de los
servicios, a mejorar continuamente la seguridad y el proceso de tratamiento de
incidentes, y a gestionar correctamente los aspectos legales que puedan surgir
durante este proceso”. (Ciclo de vida de un incidente, s.f.)
14
Figura 1 Ciclo de vida de un incidente
La entrega corresponderá a la propuesta de Gestión de incidentes informáticos,
Tratamiento, análisis y solución de Incidentes de Seguridad, la cual se hará de
manera escrita a manera de propuesta y a su vez, se dejará esta guía en formato
digital, con la finalidad de enriquecer la base de datos del conocimiento y lograr
que se encuentre disponible y sea de acceso para todo el personal.
15
6 CRONOGRAMA
Figura 2 Cronograma
16
7 QUÉ ES UN SISTEMA DE GESTIÓN DE INCIDENTES DE
SEGURIDAD SEGÚN ISO 27035
“Un sistema de gestión de incidentes de seguridad de la información es un
procedimiento con un enfoque estructurado y planificado que sirve para detectar,
contener, eliminar, analizar, reportar, evaluar y hacer seguimiento a incidentes de
seguridad de la información, para mejorar continuamente la seguridad y la gestión
de incidentes”. (GUÍA TÉCNICA COLOMBIANA GTC-ISO/IEC 27035, 2012, pág.
5)
“Con un sistema de gestión de incidentes de seguridad de la información se
pretende evitar o contener el impacto de los incidentes y las vulnerabilidades de
seguridad de la información y reducir los costos directos e indirectos que se
puedan ocasionar.” (GUÍA TÉCNICA COLOMBIANA GTC-ISO/IEC 27035, 2012)
Algunos de los beneficios que trae la implementación de un sistema de gestión de
incidentes de seguridad de la información son:
- Mejora de la seguridad global de la información
- Reducción de impactos adversos para el negocio
- Fortalecimiento del enfoque en prevención de incidentes
- Fortalecimiento de la priorización
- Fortalecimiento de la evidencia
- Contribución a las justificaciones de presupuesto y de recursos
- Mejora de actualizaciones a los resultados de la evaluación y a
gestión de riesgos de SI
17
- Mejora en la conciencia en seguridad de la información y el material
del programa de entrenamiento
- Suministro de entradas para las revisiones de la política de seguridad
de la información
7.1 QUÉ ES UN ISIRT EQUIPO DE RESPUESTA A INCIDENTES DE
SEGURIDAD DE LA INFORMACIÓN.
“Equipo conformado por miembros confiables de la organización, que cuentan con
las habilidades y competencias para tratar los incidentes de seguridad de la
información, durante el ciclo de vida de estos” (GUÍA TÉCNICA COLOMBIANA
GTC-ISO/IEC 27035, 2012, pág. 2)
Son quienes se encargaran de definir los procedimientos de atención de
incidentes, manejar relaciones con entes internos y externos, definir su
clasificación, detectar el incidente, atención del incidente, recolección y análisis de
evidencia (digital), informar y hacer anuncios de seguridad (correo, intranet, web),
auditorias de seguridad, certificación de productos, configuración y administración
de dispositivos de seguridad, realizar búsquedas constantes de nuevas
herramientas o desarrollos de protección para combatir brechas de seguridad.
Este equipo de respuesta a incidentes debe actuar como una herramienta de
experiencia en el establecimiento de recomendaciones para el aseguramiento de
los sistemas de información y está enfocado principalmente en atender los
incidentes de seguridad que se presenten sobre los activos soportados por la
plataforma tecnológica de la empresa.
18
7.2 QUÉ ES UN INCIDENTE DE SEGURIDAD
Según la norma ISO 27035, “Un incidente de seguridad de la información es
indicado por un único o una serie de eventos indeseados o inesperados de
seguridad de la información que tienen una probabilidad significativa de
comprometer las operaciones de negocio y de amenazar la seguridad de la
información, o que indican una posible violación de la política de seguridad de la
información”. (GUÍA TÉCNICA COLOMBIANA GTC-ISO/IEC 27035, 2012, pág. 3)
Se puede definir como un acceso, intento de acceso, divulgación, uso,
modificación, o destrucción no autorizada de información; un impedimento en la
operación normal de las redes, sistemas o recursos informáticos; o simplemente
una violación a las políticas de seguridad de la información de la empresa, este
evento que en ocasiones puede ser intencional o no intencional por falta de
conocimiento el usuario y que cause daños o cree indisponibilidad en el modelo de
negocio de la empresa, pueda ser solucionado y tratado lo más pronto posible por
el equipo de respuesta de incidentes, donde el objetivo es restaurar el
funcionamiento normal del servicio lo antes posible y minimizar los riesgos para
las operaciones de la empresa, con el fin de mantener los mejores niveles posible
de calidad y disponibilidad de servicio dentro de los (SLA).
Fases de la Gestión de Incidentes
Preparación y Planificación para la gestión del incidente.
Detección y Reporte para su clasificación.
Evaluación y decisión para el tratamiento.
Respuestas oportunas para la corrección, tratamiento y prevención del incidente.
Actividades Post-incidente, donde estos episodios quedan registrados para
cuando se presenten a futuro.
19
Figura 3 PHVA Incidentes de seguridad
7.3 PARA QUÉ UN SISTEMA DE GESTIÓN DE INCIDENTES DE SEGURIDAD.
Para garantizar la inexistencia o control total sobre los incidentes de seguridad es
una tarea difícil, así se tenga un alto presupuesto. Por esto un sistema de gestión
de incidentes de seguridad de la información ayudaría a mitigar los riesgos de que
un evento de seguridad se convierta en un incidente y así poder cumplir con la
confidencialidad, integridad y disponibilidad de la información.
Se pretende realizar seguimiento a los diferentes incidentes de seguridad, tratarlos
y resolverlos es la finalidad de poder tener un sistema de gestión de incidentes de
seguridad de la información con todas las pautas que regula la norma.
Con un sistema de gestión de incidentes de seguridad se busca el control y la
protección de la información estratégica y sensible de la organización, apoyándose
en las políticas y procedimientos establecidos para minimizar los riesgos actuales
20
y futuros, persiguiendo un mejoramiento continuo en el manejo de incidentes de
forma sistemática, de manera que los riesgos inherentes a la información puedan
ser minimizados, controlados y en el mejor de los casos eliminados obteniendo de
este procedimiento el mejor aprendizaje y experiencia para evitar que los
incidentes se repitan y consiguiendo la mejor manera de tratarlos.
Los controles que actualmente se usan en la empresa, la mayoría de las veces
buscan mantener al margen ataques externos, dejando a un lado las amenazas
internas que se pueden materializar fácilmente debido al incremento en el uso de
las tecnologías de la información, por eso se vuelve fundamental realizar una
identificación de los distintos riesgos existentes, para poder encontrar con mayor
facilidad la causa que los origina, procurando eliminar o controlar el agente
generador y así evitar que los riesgos sean explotados y se conviertan en un
incidente.
Definir y estructurar un sistema de gestión de incidentes de seguridad de la
información ayudara a responder rápida y correctamente ante un evento
catalogado previamente como incidente de seguridad, para así poder destinar la
cantidad de recursos necesarios que conlleven a la mitigación o eliminación del
impacto que se pudiera causar de una manera más rápida y eficiente evitando
interrupciones del servicio que comprometan la confidencialidad, integridad y
disponibilidad de la información. Como resultado de lo anterior se espera cada día
Estar más preparados para dar respuesta oportuna y aprender de la experiencia
para actuar con mayor velocidad y evitar que se presenten casos repetitivos,
obteniendo una base de datos de conocimiento y registro de los eventos e
incidentes que en su momento afectaron la organización con su respectiva
solución.
21
8 SISTEMA DE GESTIÓN DE INCIDENTES DE SEGURIDAD DE LA
INFORMACIÓN PARA CORBETA
Para el desarrollo del proyecto es necesario primero establecer la situación actual
de Corbeta en aspectos de políticas, procesos, recursos humanos y tecnología, es
decir cómo se encuentra en relación a la norma ISO 27035. Y que se tiene
actualmente: en Corbeta se tiene establecidas unas políticas de seguridad y se
aplican controles de acceso para el mejoramiento de los procesos pero se hace
necesario establecer un modelo de Gestión de incidentes de seguridad que
permita identificarlos para así realizar el respectivo seguimiento y tratamiento para
su respectiva solución o mejora.
POLÍTICAS: La empresa cuenta con unas políticas de seguridad de la información
orientadas a proteger la Confidencialidad, Integridad y Disponibilidad de la
información. Pero no cuenta con un sistema ni con la herramienta de gestión de
incidentes de seguridad.
- Política de gestión de incidentes de seguridad de la información.
Actualmente el manual de políticas de seguridad de la información no define
políticas sobre la gestión de eventos, incidentes y vulnerabilidades, donde se
describa la necesidad de gestionar los incidentes de seguridad de la información, y
de la identificación de los beneficios para la organización entera y para sus áreas.
- “Partes involucradas. Una organización debería asegurar que su
política de gestión de incidentes de seguridad de la información sea
aprobada por un alto directivo de la organización, con el compromiso y
el aval documentados de toda la alta dirección”. (GUÍA TÉCNICA
COLOMBIANA GTC-ISO/IEC 27035, 2012, pág. 14)
22
Actualmente el manual de políticas de seguridad de la información tiene la
aprobación de la gerencia y sus directivos, más el manual no contiene políticas
referentes a la gestión de eventos.
- “Una visión general sobre la detección de eventos de seguridad de la
información, reporte y recolección de la información pertinente, y como
se debería usar esta información para determinar los incidentes de
seguridad de la información”. (GUÍA TÉCNICA COLOMBIANA GTC-
ISO/IEC 27035, 2012, pág. 14)
- Esta visión general debería incluir un resumen de los tipos posibles de
eventos de seguridad de la información, como reportarlos, que
reportar, en donde y a quien, y cómo manejar los nuevos tipos de
eventos de seguridad de la información. También debería incluir un
resumen de reportes y manejo de vulnerabilidades de seguridad de la
información. (GUÍA TÉCNICA COLOMBIANA GTC-ISO/IEC 27035, 2012,
pág. 14)
Actualmente el manual de políticas de seguridad de la información no contiene
una visión general que hable sobre los eventos de seguridad de la información
- “Una visión general de la evaluación de incidentes de seguridad de la
información, que incluya un resumen de quien es el responsable, que
se debe hacer, notificación y escalamiento”. (GUÍA TÉCNICA
COLOMBIANA GTC-ISO/IEC 27035, 2012, pág. 14)
Actualmente el manual de políticas de seguridad de la información no tiene
definido un responsable ni los pasos a seguir para el tratamiento de los incidentes
de seguridad de la información, pero es de anotar que se tiene un grupo que
conforma el comité de seguridad de la información, y que está conformado por
representantes de las siguientes áreas estratégicas de la compañía: Dirección
General, Contraloría, Auditoría Interna, Seguridad Física, Área Jurídica, Recursos
23
Humanos, Dirección de Tecnología, Dirección de Desarrollo Organizacional y
Riesgos y el área de Seguridad Informática.
- Una visión general del ISIRT (equipo de respuesta a incidentes de
seguridad de la información.) (GUÍA TÉCNICA COLOMBIANA GTC-
ISO/IEC 27035, 2012, pág. 15)
Actualmente el manual de políticas de seguridad de la información no cuenta con
una definición del ISIRT, y las funciones que este debe desempeñar dentro de
Corbeta. Se cuenta con un oficial de seguridad informática y un grupo de personas
que pertenecen a esta área y con un grupo que conforma el comité de seguridad
de la información, pero no está claramente definidas las funciones y roles del
ISIRT.
- “Una visión general del programa de formación y toma de conciencia
sobre la gestión de incidentes de seguridad de la información”. (GUÍA
TÉCNICA COLOMBIANA GTC-ISO/IEC 27035, 2012, pág. 15)
Actualmente el manual de políticas de seguridad de la información cuenta con una
política que habla del derecho a que los usuarios sean notificados y capacitados
sobre las Políticas de Seguridad de la Información vigentes, más no se tiene una
política y visión sobre los incidentes de seguridad de la información.
- “Un resumen de los aspectos legales y reglamentarios que se deben
tener en cuenta”. (GUÍA TÉCNICA COLOMBIANA GTC-ISO/IEC 27035,
2012, pág. 15)
El manual de políticas de seguridad de la información hace referencia a aspectos
básicos del área legal y de reglamento, como las sanciones que puede acarrear el
no cumplimiento de este, menciona que los usuarios tienen derecho a recibir
ayuda y asesoría por parte del personal de Seguridad Informática cuando se
24
presenten incidentes de seguridad, mas no está definida la gestión de incidentes
de seguridad como se debe tratar.
PROCESOS: Hoy la compañía no tiene un proceso para realizar gestión de
incidentes de seguridad de la información.
PERSONAS: El recurso humano de la empresa en su mayoría profesional del
área TI, tiene el conocimiento y la experiencia individual suficiente para la
implementación de los procesos, más aún falta definir roles y funciones que
ayuden a interactuar con el sistema de gestión de incidentes de seguridad de la
información. Falta incluir el resumen de quien es el responsable, falta conformar el
ISIRT.
TECNOLOGÍA: La empresa cuenta con la infraestructura y el acceso a las
herramientas necesarias para la automatización de los procesos que se vayan a
implementar en el presente proyecto de gestión de incidentes de seguridad de la
información.
25
8.1 POLÍTICA PROPUESTA QUE APOYARA EL SISTEMA DE GESTIÓN DE
INCIDENTES DE SEGURIDAD
El objetivo es crear una Política donde se gestione incidentes de seguridad de la
información en CORBETA y que permita definir el procedimiento de reporte,
clasificación y solución de los incidentes.
Un incidente de seguridad está definido por todo evento que va en contra o viola
las políticas de seguridad de la información.
Las políticas actualmente desarrolladas no van enfocadas a la gestión de
incidentes de seguridad de la información, por esto se propone la siguiente
política:
La organización consiente de los posibles incidentes de seguridad de la
información que se pueden presentar, decidió establecer las políticas y controles
que permitan minimizar los riesgos y realizar una correcta gestión a los incidentes
en el caso que ocurran, con el fin de reducir al máximo su posible impacto.
La política de gestión de incidentes de seguridad de la información va dirigida a
todo el personal que tenga acceso legítimo a los sistemas de información y
recursos informáticos, con el fin de proteger la integridad, confidencialidad y
disponibilidad de la información. La política aplica a empleados, contratistas,
consultores, proveedores y toda persona que tengan contacto con la
infraestructura tecnológica de forma física, lógica, remota. Estas políticas aplican
para dispositivos propios o alquilados que tiene la empresa y a los equipos
propiedad de terceros que sean conectados a las redes de la empresa.
La política se encuentra avalada por la gerencia y el comité de seguridad de la
información, que está conformado por: Dirección General, Contraloría, Auditoría
Interna, Seguridad Física, Área Jurídica, Recursos Humanos, Dirección de
Desarrollo Organizacional y Riesgos, Dirección de Tecnología y el área de
26
Seguridad Informática. El manual de políticas se encuentra actualmente disponible
para todos los empleados en la Intranet de la empresa.
El oficial de seguridad es la persona encargada de tomar las decisiones que
afecten el sistema de seguridad de la información, debe estar en permanente
contacto con los directivos, informándoles de los incidentes que tengan alto
impacto dentro de la empresa. Es la persona encargada de delegar o realizar
acciones legales, penales, disciplinarias, forenses, procedimentales, que lleven al
mejoramiento de la seguridad de la información.
La política de seguridad, el contrato de trabajo y los documentos que se le
relacionen son de estricto cumplimiento para todos los empleados, contratistas,
consultores, proveedores. Estos deben de responsabilizarse y cumplir con los
procedimientos establecidos y estar conscientes que cualquier incumplimiento
conlleva a sanciones administrativas, disciplinarias y/o penales.
Es obligación de todo contratista, consultor, proveedor reportar los eventos o
incidentes de seguridad que se puedan presentar ante la mesa de servicios, quien
escalara el caso al grupo de respuesta inmediata a incidentes de seguridad de la
información para clasificar y evaluar.
El grupo de respuesta inmediata a incidentes de seguridad de la información debe
estar conformado por los representantes de las áreas principales de tecnología,
quienes atenderán los incidentes escalados por la mesa de servicios. Se debe
contar como mínimo con un una persona del área de seguridad informática, un
representante del área de infraestructura, un representante del área de redes de
comunicación, un representante de desarrollo de aplicaciones.
Dicho grupo se encargara de gestionar los incidentes o eventos que se puedan
presentar, dando una respuesta ante estos a la organización e informando a la alta
gerencia sobre todos los eventos e incidentes que puedan comprometer la
organización. A su vez de este grupo se desprende el comité urgente que está
27
conformado por el oficial de seguridad, el administrador de la red y un miembro del
equipo de seguridad quienes serán los encargados de definir y atender una
urgencia en el momento que ocurra una situación por fuera de lo normal.
Se contará con una herramienta de gestión de incidentes para todas las
actividades referentes a la gestión de incidentes de seguridad, con el objetivo de
poder analizar, registrar, documentar todos los procedimientos y acciones
generadas alrededor de la gestión de incidentes. La herramienta de seguridad
debe estar certificada en ITIL.
La empresa tendrá una política de comunicación de los incidentes de seguridad
para definir que incidente puede ser comunicado a los medios y cual no.
Se define como apoyo externo a los terceros que manejan y soportan el software
antivirus, las bases de datos de vulnerabilidades registradas en bases CVE
(Common Vulnerabilities and Exposures), los foros de seguridad de la información,
los equipos de Respuesta ante incidentes de seguridad CSIRT locales o
internacionales, que puedan aportar en la solución , prevención ante incidentes.
28
8.2 POSIBLES INCIDENTES DE SEGURIDAD QUE PODRÍAN AFECTAR LA
ORGANIZACIÓN.
Se procede a desarrollar un análisis de riesgos en el que se pretende analizar las
amenazas sobre los activos y que pueden generar un impacto alto en la
información. Este se desarrollara hasta el plan de tratamiento, donde se proponen
los controles que se deben implementar para minimizar los riesgos.
Estos riesgos altos se consideran generadores de incidentes que pueden ocurrir
dentro de la organización, por lo que se deben detectar anticipadamente para
contener y/o eliminar detectando su posible impacto, facilitando la gestión antes
que se convierta en un incidente de seguridad de la información y si no es posible
poder tratarlo de la mejor manera.
A continuación se realiza el levantamiento de los activos existentes en la
compañía, diferenciando de activos tangibles e intangibles. Para luego identificar
los posibles riesgos que pueden afectar dichos activos.
Tabla 1
Clasificación de activos
Tabla 1: Clasificación de activos
Servidores (Web, Bases de datos, Aplicaciones…)
Recurso Humano
Computadores, Portatiles, Celulares
Aire Acondicionado
Centro de equipos de computo
Infraestructura de Redes y Seguridad
Medios magneticos
Sistemas Operativos
Bases de Datos
Datos
ACTIVOS /RECURSOS
TANGIBLES
INTANGIBLES
29
Las amenazas se consideran la agrupación de eventos o situaciones que pueden
afectar los activos de la organización, estas proceden de fuentes internas o
externas y pueden ser voluntarias o accidentales. A continuación definimos las
posibles amenazas que pueden afectar los activos de la información.
Tabla 2
Clasificación de amenazas
AMENAZAS TIC AMENAZAS NATURALES AMENAZAS HUMANAS/SOCIALES
Interceptación Inundaciones Ingeniería Social
Hackers Tormentas eléctricas
Acceso no autorizado al
sitio/edificio/sala
Daños, fallas Robo
Software malicioso
Suplantación
Acceso no autorizado a red
Eliminación no autorizada
Cross Site Scripting - XSS
SQL Injection
Tabla 2: Clasificación de amenazas
Se define a continuación las tablas de probabilidad e impacto, las cuales ayudan a
medir la posibilidad y/o periodicidad de que un riesgo o amenaza impacte sobre
los activos. Luego se hace una evaluación de los riesgos, se debe de elegir por
cada escenario de riesgo su probabilidad de ocurrencia (Tabla 3) y su impacto
(Tabla 4) y de ahí se obtendrá el nivel de riesgo, siendo el nivel de riesgo el
resultado de multiplicar la probabilidad por el impacto
30
Tabla 3
Tablas de probabilidad/frecuencia
Nivel Rangos Ejemplo detallado de la descripción
1 Raro Puede ocurrir solo bajo circunstancias excepcionales
Ocurre al menos una vez al año
2 Improbable Podría ocurrir algunas veces
Ocurre al menos tres veces al año
3 Posible Puede ocurrir en algún momento
Ocurre al menos seis veces al año
4 Probable La expectativa de ocurrencia se da forma periódica
Ocurre al menos doce veces al año
5 Casi seguro La expectativa de ocurrencia se da en la mayoría de circunstancias
Ocurre al menos veinte y cuatro veces al año o más.
Tabla 4: Tabla de probabilidad-frecuencia
Tabla 4
Tabla de Impacto
Nivel Rangos Ejemplo detallado de la descripción-disponibilidad
1 Insignificante La información no está disponible por menos de 5 min.
2 Menor La información no está disponible 5 y 15 min
3 Medio La información no está disponible 15 y 45 min
4 Mayor La información no está disponible entre 45 min y 2 horas
5 Superior La información no está disponible por más de 2 horas
Tabla 5: Tabla de Impacto
La siguiente tabla contiene la calificación de controles, donde se obtiene como
resultado el nivel de riesgo que es el la consecuencia de multiplicar la probabilidad
por el impacto y se obtienen los resultados para generar el mapa de riesgos final.
31
Tabla 5
Calificación de controles
Tabla 6: Tabla de Calificación de controles
Para la aceptabilidad del riesgo, se ha definido la siguiente tabla,
Tabla 6
Aceptabilidad del riesgo
Nivel Descripción
Bajo - B Nivel aceptable de riesgo, es susceptible a acciones de mejora
Moderado – M Nivel aceptable de riesgo, es susceptible a acciones de mejora
Alto – A Riesgos que deben tratados a corto plazo
Extremo - E Nivel de riesgo que debe ser tratados con urgencia
Tabla 7: Aceptabilidad del riesgo
ESCENARIO
Riesgo
P*Impacto Interceptacion -- Servidores (Web, Bases de datos, Aplicaciones…) Posible 3 Mayor 4 12
Interceptacion -- Infraestructura de Redes y Seguridad Ocasional 2 Medio 3 6
Hackers -- Servidores (Web, Bases de datos, Aplicaciones…) Posible 3 Medio 3 9
Hackers -- Infraestructura de Redes y Seguridad Ocasional 2 Menor 2 4
Hackers -- Sistemas Operativos Posible 3 Insignificante 1 3
Hackers -- Bases de Datos Ocasional 2 Menor 2 4
Daños, fallas -- Servidores (Web, Bases de datos, Aplicaciones…) Ocasional 2 Menor 2 4
Daños, fallas -- Infraestructura de Redes y Seguridad Ocasional 2 Insignificante 1 2
Daños, fallas -- Sistemas Operativos Casi seguro 4 Menor 2 8
Software malicioso -- Servidores (Web, Bases de datos, Aplicaciones…) Posible 3 Mayor 5 15
Software malicioso -- Computadores, Portatiles, Celulares Casi seguro 4 Medio 3 12
Software malicioso -- Sistemas Operativos Ocasional 2 Menor 2 4
Software malicioso -- Bases de Datos Muy ocasional 1 Menor 2 2
Suplantacion -- Servidores (Web, Bases de datos, Aplicaciones…) Ocasional 2 Medio 3 6
Suplantacion -- Recurso Humano Casi seguro 4 Mayor 5 20
Acceso no autorizado a red -- Infraestructura de Redes y Seguridad Ocasional 2 Mayor 5 10
Eliminación no autorizada -- Medios magneticos Posible 3 Mayor 4 12
Eliminación no autorizada -- Datos Muy seguro 5 Mayor 4 20
Cross Site Scripting - XSS -- Servidores (Web, Bases de datos, Aplicaciones…) Muy seguro 5 Medio 3 15
SQL Injection -- Servidores (Web, Bases de datos, Aplicaciones…) Casi seguro 4 Mayor 4 16
SQL Injection -- Bases de Datos Posible 3 Mayor 4 12
Inundaciones -- Aire Acondicionado Muy ocasional 1 Medio 3 3
Inundaciones -- Centro de equipos de computo Muy ocasional 1 Medio 3 3
Tormentas electricas -- Servidores (Web, Bases de datos, Aplicaciones…) Ocasional 2 Medio 3 6
Tormentas electricas -- Aire Acondicionado Muy ocasional 1 Insignificante 1 1
Tormentas electricas -- Centro de equipos de computo Ocasional 2 Menor 2 4
Ingenieria Social -- Recurso Humano Casi seguro 4 Mayor 4 16
Acceso no autorizado al sitio/edificio/sala -- Centro de equipos de computo Ocasional 2 Mayor 5 10
Robo -- Computadores, Portatiles, Celulares Posible 3 Menor 2 6
Robo -- Medios magneticos Ocasional 2 Mayor 5 10
Robo -- Datos Muy seguro 5 Mayor 5 25
PROBABILIDADIMPACTO INFORMACION
32
El mapa de riesgos quedaría de la siguiente manera:
Tabla 7
Mapa de aceptabilidad.
Tabla 8: Mapa de aceptabilidad.
Para finalizar se genera el mapa de riesgos donde se puede evidenciar los riesgos
más altos marcados como (A) o extremos como (E), que en realidad son los que
necesitarían un plan de tratamiento y los demás estarían aceptados acorde a la
definición de la tabla 6 de aceptabilidad del riesgo.
1 2 3 4 5
Casi seguro 5 A A E E E
Probable 4 M A A E E
Posible 3 B M A E E
Improbable 2 B B M A E
Raro 1 B B M A A
Impacto Probabilidad valor
33
Tabla 8
Mapa del riesgo
Probabilidad
valor
1 2 3 4 5
Casi seguro
5
Cross Site
Scripting - XSS
-- Servidores
(Web, Bases de
datos,
Aplicaciones…)
||
Eliminación no
autorizada --
Datos || Robo -- Datos ||
Probable
4
Daños, fallas --
Sistemas
Operativos ||
Software
malicioso --
Computadores,
Portátiles,
Celulares ||
SQL Injection -
- Servidores
(Web, Bases de
datos,
Aplicaciones…)
|| Ingenieria
Social --
Recurso
Humano ||
Suplantacion --
Recurso
Humano ||
Posible
3
Hackers --
Sistemas
Operativos ||
Robo --
Computadores,
Portátiles,
Celulares ||
Hackers --
Servidores
(Web, Bases de
datos,
Aplicaciones…)
||
Interceptacion
-- Servidores
(Web, Bases de
datos,
Aplicaciones…)
|| Eliminación
no autorizada -
- Medios
magneticos ||
SQL Injection -
- Bases de
Datos ||
Software
malicioso --
Servidores
(Web, Bases de
datos,
Aplicaciones…)
||
34
Tabla 9: Mapa del riesgo
Tratamiento del riesgo:
o Minimizar la probabilidad:
Se debe elegir métodos que lleven a reducir la probabilidad de ocurrencia,
la generación de un sistema de gestión de incidentes de seguridad de la
información va enfocado a atacar los posibles incidentes amenazas y
riesgos que se puedan presentar.
Improbable
2
Daños, fallas -
-
Infraestructura
de Redes y
Seguridad ||
Hackers --
Infraestructura
de Redes y
Seguridad ||
Hackers --
Bases de Datos
|| Daños, fallas
-- Servidores
(Web, Bases de
datos,
Aplicaciones…)
|| Software
malicioso --
Sistemas
Operativos ||
Tormentas
eléctricas --
Centro de
equipos de
cómputo ||
Interceptación
--
Infraestructura
de Redes y
Seguridad ||
Suplantación --
Servidores
(Web, Bases de
datos,
Aplicaciones…)
|| Tormentas
eléctricas --
Servidores
(Web, Bases de
datos,
Aplicaciones…)
||
Acceso no
autorizado a red
--
Infraestructura
de Redes y
Seguridad ||
Acceso no
autorizado al
sitio/edificio/sala
-- Centro de
equipos de
cómputo || Robo
-- Medios
magneticos ||
Raro
1
Tormentas
eléctricas --
Aire
Acondicionado
||
Software
malicioso --
Bases de Datos
||
Inundaciones -
- Aire
Acondicionado
|| Inundaciones
-- Centro de
equipos de
cómputo ||
35
o Reducir el impacto
Para la reducción del impacto es posible desarrollar planes de contingencia
y continuidad del negocio con un mejoramiento continuo, que se administre
desde un sistema de gestión de incidentes de seguridad de la información.
o Transferir total o parcialmente
La transferencia del riesgo se realiza por medio de contratos o pactos con
terceros, y se puede dar con pólizas, seguros y tratados de cumplimiento,
para este análisis es importante que el grupo de respuesta a incidentes de
seguridad de la información evalué el aval de que riesgos transferir.
o Evitar
Es el resultado de finalizar con las actividades que pueden generar el
riesgo, cambiar la estrategia o eliminar la tarea que normalmente se viene
haciendo.
o Asumir
En este tipo de tratamiento es importante que el grupo de respuesta a
incidentes de seguridad de la información defina y asuma los riesgos y los
catalogue para que se puedan convertir en posibles incidentes conocidos y
se puedan plantear las acciones correctivas y preventivas pertinentes.
Mapa de riesgos, aceptabilidad del riesgo
El siguiente mapa representa la distribución en porcentaje del riesgo evaluado,
donde se pueden evidenciar los riesgos con niveles aceptables y niveles urgentes
los cuales deben ser atendidos por el grupo de respuesta a incidentes de
seguridad de la información que evaluará y clasificará el nivel de impacto y/o
urgencia de los riesgos generados para lograr reducir el nivel de exposición.
36
Podemos verificar que el 41.9% de los riesgos son extremos, y el 9.6% son altos.
Aceptabilidad del riesgo
Figura 4 Aceptabilidad del riesgo
Distribución porcentual del riesgo
Tabla 9
Distribución porcentual del riesgo
Tabla 10: Distribución porcentual del riesgo
ZONA % Total riesgos
Bajo 29,03225806 9
Medio 19,35483871 6
Medio-Alto 9,677419355 3
Altos 41,93548387 13
DISTRIBUCIÒN PORCENTUAL
37
Dentro de los riesgos clasificados como extremos y altos tenemos los siguientes:
Tabla 10:
Riesgos extremos.
RIESGOS ALTOS – POSIBLES INCIDENTES
Robo -- Datos
Eliminación no autorizada -- Datos
Cross Site Scripting - XSS -- Servidores (Web, Bases de datos, Aplicaciones…)
Suplantación -- Recurso Humano
Software malicioso -- Servidores (Web, Bases de datos, Aplicaciones…)
Acceso no autorizado a red -- Infraestructura de Redes y Seguridad || Acceso no
autorizado al sitio/edificio/sala -- Centro de equipos de cómputo || Robo --
Medios magnéticos
SQL Injection -- Servidores (Web, Bases de datos, Aplicaciones…) || Ingeniería
Social -- Recurso Humano
Interceptación -- Servidores (Web, Bases de datos, Aplicaciones…) ||
Eliminación no autorizada -- Medios magnéticos || SQL Injection -- Bases de
Datos
Daños, fallas -- Sistemas Operativos
Software malicioso -- Computadores, Portátiles, Celulares
Hackers -- Servidores (Web, Bases de datos, Aplicaciones…)
Tabla 11: Riesgos extremos.
38
8.2.1 Plan de tratamiento, controles propuestos.
Los controles propuestos después de realizar el mapa de riesgos son los
siguientes:
Proponer un sistema de gestión de incidentes de seguridad de la información que
minimice el impacto que pueden ocasionar los riesgos informáticos sobre la
activos de la organización y que permitan realizar un mejoramiento continuo sobre
los procedimientos y procesos creados para la atención de incidentes, velando por
evitar y contener los posibles perjuicios que puedan generar las vulnerabilidades o
residuos existentes de los controles. Así mismo promover y concientizar a todo el
personal de la importancia que tiene registrar los incidentes y eventos con la mesa
de servicios o el grupo de atención de incidentes de seguridad de la información,
para que así se le dé el tratamiento adecuado y se puedan emprender acciones
correctivas o preventivas. El sistema propuesto debe tener controles y políticas
que lleven a la conservación de la confidencialidad, integridad y disponibilidad de
la información.
Establecer políticas que apunten a la protección de la seguridad de la información,
con estrategias legales aprobadas por la organización, que permitan el manejo de
incidentes y la mitigación de los riesgos en pérdidas de información.
Implementar medidas de seguridad en la infraestructura que permitan proteger la
organización reduciendo la probabilidad y el impacto, aplicando controles sobre los
agentes generadores.
Realizar seguimiento periódico a las herramientas de monitoreo, Logs, registros,
aplicaciones que controlan los accesos, dispositivos, software, programas antivirus
para identificar y evitar que los riesgos se conviertan en amenazas, y luego
clasificar los posibles incidentes que puedan aparecer y tratar de contenerlos u o
establecer acciones, procedimientos o métodos que ayuden con la solución y
eliminación del incidente generado, aplicando un plan de mejoramiento continuo.
39
8.3 CLASIFICACIÓN Y EVALUACIÓN DE LOS TIPOS DE INCIDENTES DE
SEGURIDAD QUE SE PRESENTAN EN LA EMPRESA.
8.3.1 Clasificación de los incidentes de seguridad:
A continuación se plantea la propuesta de clasificación de incidentes de seguridad.
Cuando ocurra un incidente de seguridad de la información, este debe ser
reportado al grupo de respuesta de incidentes de seguridad de la información
quien se encargara de analizar y clasificar dicho evento o incidente, el grupo de
respuesta a incidentes debe determinar si el incidente corresponde a un incidente
de seguridad de la información o está relacionado con requerimientos propios de
la infraestructura tecnológica, para que así la próxima vez que se presente un
incidente similar se tenga una manera fácil de identificarlo y/o clasificarlo para
darle su respectivo tratamiento o solución.
Es importante que el grupo de respuesta a incidentes de seguridad de la
información cuente con personal capacitado y entrenado, para así poder realizar
una clasificación adecuada y un correcto escalamiento de los incidentes en caso
de ser necesario. Esta persona(s) debe contar con capacitación en seguridad de la
información y debe conocer muy bien la clasificación de incidentes.
Los incidentes se deben clasificar de la siguiente manera
Según su tipo o naturaleza:
Técnico
Humano
Procedimental
Y según su fuente:
Interno
40
Externo
Tabla 11
Clasificación de incidentes
CLASIFICACIÓN DE INCIDENTES
Tipo o naturaleza Fuente
Técnico Interno
Humano Externo
Procedimental
Tabla 12: Clasificación de incidentes
Por tipo o naturaleza de un incidente se debe entender los aspectos funcionales
de un incidente, su comportamiento y manera de interactuar con los sistemas de
información, existen incidentes deliberados o accidentales los cuales son muy
importantes diferenciar, pues las consecuencias pueden ser muy distintas, sus
acciones posteriores deben identificarse y actuar teniendo en cuenta que estos
pueden o no en muchas veces ocasionar medidas disciplinarias, legales o
penales.
El grupo de respuesta a incidentes de seguridad de la información, debe realizar
una clasificación de los incidentes según el servicio que se esté afectando y
teniendo en cuenta la tabla de clasificación de incidentes, cada uno de los
incidentes mínimamente deberá determinarse por su tipo o su fuente, esto debe
quedar documentado en una base de conocimiento, para así cuando un incidente
se vuelva reiterativo, este se convierta en un incidente conocido y sea más fácil
atacarlo o eliminarlo para reducirle el impacto que pueda generar.
41
Los incidentes se deben diferenciar, según su fuente, es importante identificar si
provienen de un origen interno o externo de la organización.
8.3.2 Evaluación de los incidentes de seguridad:
La evaluación de los incidentes de seguridad se debe realizar según su prioridad
dentro de la organización, entendiendo como prioridad la multiplicación de impacto
o criticidad por urgencia.
El nivel de prioridad se basa esencialmente en dos parámetros:
Impacto: “determina la importancia del incidente dependiendo de cómo éste afecta
a los procesos de negocio y/o del número de usuarios afectados”. (Gestión de
Incidencias, 2015)
Urgencia: “depende del tiempo máximo de demora que acepte la organización
para la resolución del incidente y/o el nivel de servicio acordado en el SLA”.
(Gestión de Incidencias, 2015)
La urgencia debe ser definida por el grupo de respuesta a incidentes de seguridad,
después de haber clasificado el incidente, se debe dar una calificación en una
escala para determinar la urgencia del incidente. Es importante tener en cuenta
factores externos como los recursos necesarios y tiempo para dar una solución.
El impacto o criticidad va definido por los servicios afectados, el grupo de
respuesta a incidentes de seguridad de la información debe definir cuales servicios
son más críticos que otros según una escala, para así poder dar una solución
oportuna. Todos los servicios deben de ir listados e identificados de manera que
cuando se presente un incidente se pueda reconocer si el servicio es poco crítico,
crítico o altamente crítico.
42
Según lo anterior se propone el siguiente método para evaluar los incidentes de
seguridad de la información:
El método para evaluar la prioridad de los incidentes de seguridad, consiste en
una matriz tres por tres donde interaccionan impacto por urgencia.
Donde el eje X de impacto está definido por los siguientes estados: Poco crítico
(1), crítico (2), altamente crítico (3).
Y el eje Y de urgencia está definido por los siguientes estados: No urgente (1),
urgente (2), muy urgente (3)
Tabla 12
Prioridad de los incidentes
Tabla 13: Prioridad de los incidentes
La multiplicación de los estados de urgencia por los estados de impacto dará la
prioridad con que se deban tratar los incidentes de seguridad, siendo uno la
prioridad más baja y nueve la más alta, es decir los incidentes con prioridad nueve
se deberán atender con mayor prelación. La prioridad va ligada a la concurrencia
de las incidencias presentadas y los incidentes “conocidos” se tramitarán cuanto
antes.
UR
GEN
CIA
IMPACTO
1 2 3
1 1 2 3
2 2 4 6
3 3 6 9
43
8.3.3 Identificar si un evento de seguridad de la información es un incidente.
- Inicialmente se recibe un reporte por los medios estipulados a la mesa de
servicios, teléfono, correo electrónico, herramienta de registro web o se rastrea por
medio de logs, registros, funcionamientos anormales, dispositivos de monitoreo,
fallas en servicios, alertas de sistemas de seguridad (antivirus, IDS, IPS…),
reportes de incidentes de fuentes confiables (foros, proveedores…), daño o robo
de activos de información o se compromete la política de seguridad de la
información.
- Luego la mesa de servicios realiza la clasificación, y evalúa si se trata de un
incidente de seguridad u otro tipo de evento. Para que la mesa de servicios pueda
determinar si se trata de un incidente de seguridad de la información necesita
previamente tener establecido una línea base del funcionamiento de la
infraestructura tecnológica, donde se pueda de manera fácil y rápida analizar y así
poder determinar si se trata de un incidente o no. Determinar esto en muchos
casos puede ser una tarea difícil para la mesa de servicios, por lo que se hace
necesario en muchos casos el escalamiento del evento a personas especializadas
pertenecientes al grupo de respuesta de incidentes de seguridad de la
información, en el caso que se tenga indicios de que el evento posiblemente es un
incidente de seguridad para tratar de darle respuesta en el menor tiempo posible.
- Luego de identificar que el evento efectivamente si es un incidente
verdadero y no un falso positivo, se procede a verificar en las distintas fuentes,
fabricantes, foros, proveedores, listas de CVE (Common Vulnerabilities and
Exposures) y demás procedimientos establecidos para tratar de eliminar o mitigar
los posibles impactos y a la vez se debe hacer el respectivo análisis del incidente
44
de seguridad para darle respuesta en el menor tiempo posible y restablecer o
poner en marcha planes de continuidad en caso de ser necesarios.
- Es necesario evaluar en el menor tiempo posible los sistemas afectados, la
información comprometida, la criticidad de los activos de información y la
infraestructura afectada, para dar paso a contener y/o eliminar los posibles efectos
que se estén teniendo o puedan suscitar con el incidente a tratar. En este punto
puede ser necesario aislar los sistemas afectados, bloquear conexiones externas,
para detener de raíz la posible causa u origen del incidente.
- Adicionalmente se pueden realizar procedimientos de análisis forense,
manejo de custodia, tratar correctamente los aspectos legales que pudieran surgir
durante este proceso, restaurar el sistema, tener copias de seguridad y planes de
contingencia.
- Es importante documentar todo el proceso de gestión de incidentes y
vulnerabilidades encontradas, creando una base de datos de conocimientos que
contenga eventos, incidentes y vulnerabilidades de seguridad de la información
gestionados por el grupo de respuesta a incidentes de seguridad y generar una
retroalimentación para facilitar y evitar que se vuelvan a presentar en un futuro
aplicando una metodología de mejoramiento continuo (PHVA) que permita
optimizar consecutivamente el proceso.
45
Cuadro para identificar un Incidente de seguridad.
Figura 5 Identificación de un evento de seguridad
REPORTE EVENTO(REGISTRO)
Telefono Correo electronico Herramienta de registro
Web Dispositivos de monitoreo Fallas
CLASIFICACIÓN, CATEGORIZACION
Si es un incidente de seguridad?
Realizar procedimiento de idetificacion de incidentes de seguridad.
Aislar sistemas comprometidos
Bloquear conexiones
NO
Tratar el evento y darle solucion.
Realizar analisis forenses Manjear aspectos legales
Restaurar Sistema comprometido.
Copias de seguridad Planes de contingencia
Cierre y documentacion del incidente
Mejoramiento continuo, en el proceso de gestion de incidentes de seguridad de la informacion
46
8.4 HERRAMIENTAS DE GESTIÓN DE INCIDENTES DE SEGURIDAD
8.4.1 Mesa de servicios en Corbeta
Actualmente Corbeta cuenta con una mesa de servicios virtual, esta es el único
punto de contacto con que cuentan los usuarios cuando necesitan ayuda en las
tecnologías de la información, tanto para incidentes que pueden afectar el curso
normal de su trabajo, como para requerimientos que necesiten solicitar. El
principal objetivo de la mesa de servicios es ofrecer una primera ayuda de soporte
técnico que permita resolver en el menor tiempo las incidencias presentadas.
Por medio de la mesa de servicios se reportan todos los eventos, se les realiza
trazabilidad desde que se registran hasta que se les da una solución.
Los usuarios pueden contactar a la mesa de servicios telefónicamente, por correo
o generar directamente la solicitud en la página web destinada para tal fin algunas
de las ventajas que se obtienen con el uso de la mesa de servicios son:
Una base de datos de todos los eventos reportados, que a su vez se convierten en
base de datos del conocimiento, pues siempre está disponible para ser consultada
y solucionar futuros incidentes que se puedan presentar de una manera más fácil.
Dentro de la herramienta de gestión de casos, se realiza una categorización con
unos ANS (niveles de atención del servicio) tiempos establecidos para dar
solución a los casos.
Si en el primer contacto con la mesa de servicios no se puede dar solución, se
realiza un escalamiento a personal de niveles especializados, los cuales se
encargan de atender y brindar una solución.
El software de gestión de casos permite sacar estadísticas para evaluar el
cumplimiento y número de casos registrados, solucionados o pendientes en un
periodo de tiempo determinado.
47
La mesa de servicios está desarrollada en las instalaciones de un tercero (Call
Center), que se encarga de proveer personal, equipos y la tecnología necesaria
para atender remotamente los usuarios de Corbeta.
8.4.2 Evaluación de herramientas basadas en ITIL.
De acuerdo a ITIL el objetivo del manejo de incidentes a través de la mesa de
ayuda es:
“Proveer continuidad a los negocios al restaurar el servicio a usuarios tan rápido y
eficientemente como sea posible”. (Remedy Service Desk de BMC, 2015). Por eso
se recomienda usar una herramienta de las que a continuación vamos a
mencionar ya que todo el tiempo hablamos de las ISO (20000, 27035) por eso
debe ser una herramienta de Service Desk enfocada y certificada en ITIL.
CA SERVICE DESK: Software Service Desk de CA Technologies ofrece una
amplia gama de herramientas automatizadas para el Help Desk que permiten
resolver problemas y lograr una mayor calidad de servicio al cliente al mismo
tiempo que reduce los costos del negocio.
“Tiene capacidad para prestar servicios TI consistentes y de alta calidad con la
herramienta Service Desk Manager. Se obtiene gran capacidad para automatizar
fácilmente los incidentes, problemas, gestión del conocimiento, el soporte
interactivo, el autoservicio y el análisis avanzado de las causas. Se garantiza un
mejor soporte al usuario final y se optimiza el servicio TI, con cambios
simplificados y una efectiva administración de la configuración”. (CA Service Desk
Manager, 2015)
Beneficios
Se obtiene una mayor calidad de servicio TI al usuario final.
48
Reduce los costos
Garantiza que los servicios estén alineados con los requisitos del negocio.
Mejora la productividad y automatiza los servicios de TI.
“Los cambios frecuentes en la infraestructura de TI incrementan la complejidad y,
si no son administrados de forma efectiva, pueden amenazar la continuidad del
servicio.
CA Service Management están diseñadas para ayudar a garantizar la calidad del
servicio y la utilización de recursos en entornos físicos, virtuales y de nube. Integra
todas las funcionalidades básicas con otras nuevas, innovadoras y avanzadas
funcionalidades como” (CASOS DE ÉXITO, 2015):
sistema de ticket,
análisis
procesos
base del conocimiento
administración SLA
aprobaciones
seguimiento de tiempos
feedback de clientes
soporte multi-departamento
ITIL
integración con email
Las consolas y reportes de negocio mejoran la visibilidad de la administración de
los servicios de TI, lo que mejora la calidad en el servicio, limita los riesgos y
alinea las inversiones de TI para lograr los objetivos de productividad del negocio.
Existe una comunidad mundial en línea de 3.000 miembros, quienes comparten
las experiencias de software de la mesa de servicio y las mejores prácticas, así
como contenido para realizar rápidamente actividades de valor (Quick Value) y
49
programas de aceleración de clientes. Este software de mesa de ayuda permite
aumentar el valor y la madurez de la implementación de CA Service Management,
y aumentar la productividad de TI y del negocio.
BMC REMEDY SERVICE DESK: “Es una aplicación que facilita, de extremo a
extremo, la gestión de los procesos de soporte a servicios. Independientemente
de si una solicitud de servicio se inicia a través de la Web, Correo Electrónico,
Teléfono, Cliente Ligero, o por un evento generado por una herramienta de
monitoreo de infraestructura, esta interfaz multicanal de peticiones de clientes
consolida y se encarga de la asignación y seguimiento de solicitudes para la
resolución final. Ayuda a llevar a cabo las mejores prácticas de gestión de
incidentes y problemas, se encuentra instalado en miles de clientes ayudándoles
a librar los obstáculos que limitan la capacidad de responder rápida y
eficientemente a las condiciones que afectan los servicios críticos de TI de los
negocios” (Remedy Service Desk de BMC, 2015).
BMC Remedy Service Desk actúa como un único punto de contacto para todos
los usuarios, permite acelerar el restablecimiento de la normalidad de servicio y
ayuda a prevenir futuros eventos de negocio que impactan negativamente en los
servicios, al tiempo que se contribuye a mejorar la eficacia del personal de TI.
Automatiza el incidente y la gestión de problemas de flujo de trabajo para reducir
el número de incidentes manejados, mejorar los tiempos de resolución, y prevenir
futuros incidentes. Sobre la base de las mejores prácticas de ITIL. Integrar todas
las funciones de apoyo de servicios de TI.
Y como lo establece ITIL, la mesa de ayuda Remedy Service Desk cumple con:
Ser accesible a usuarios sin importar la separación organizacional o
geográfica
Automatizar los procesos de soporte de TI.
Un módulo de autoservicio para el usuario
50
Ofrece a los usuarios la capacidad de buscar y aplicar soluciones para
resolver incidentes por ellos mismos
Con Remedy Service Desk (mesa de servicio), se puede:
Consolidar requerimientos de múltiples fuentes: Web, email, y teléfono
Proveer una mejor cara al usuario, más profesional, mejor servicio y
flexibilidad
Utilizar tanto la interfaz Web o el cliente Windows los cuales tienen un
mismo aspecto
Abrir su uso a todos los usuarios, sin entrenamiento especial y así puedan
interactuar con el Service Desk de forma directa.
Crear una base de datos de conocimiento, los usuarios buscan soluciones a
sus incidentes y resuelven sus propios casos.
Menores llamadas y casos por atender, eficiencia para más actividades de
valor.
Mostrar un “pizarrón de avisos” al filtrar circulares, memos y direccionarlos
a usuarios, localidades o departamentos específicos.
Menores llamadas al Service Desk y disminución de duplicidad de casos al
notificar proactivamente de interrupciones en servicios.
Recibir casos automáticamente disparados por productos de red y sistemas
administrativos como BMC Software’s PATROL, HP’s OpenView, Microsoft
MOM, etc.
51
Abrir y cerrar casos proactivamente e iniciar la resolución para prevenir la
afectación de usuarios o servicios críticos.
Figura 6 BMC REMEDY SERVICE DESK
“BMC Remedy Service Desk es parte de la suite de aplicaciones BMC Remedy
IT Service Management la cual se encuentra integrada entre sí, une de manera
natural los procesos de gestión de incidentes y problemas a los procesos de
gestión de activos y configuraciones, cambios y niveles de servicio. La
aplicación integra los procesos de la Mesa de Servicio y la gestión de la
infraestructura a través de BMC Atrium® CMDB”. (BMC Remedy Service Desk,
2015) Este repositorio inteligente comparte un modelo común del entorno de TI
con otros productos de BMC y productos de terceros para unificar los servicios
de TI y procesos de dirección con gestión de la infraestructura.
Aranda SERVICE DESK: “Es la solución de gestión de procesos y servicios de
soporte, que permite implementar las mejores prácticas de gestión TI. Se
encuentra certificada por la empresa canadiense Pink Elephant, en la categoría de
servicio de soporte mejorado, Aranda Software brinda la posibilidad de gestionar el
área de servicio de soporte con los siguientes cinco procesos explicados
brevemente a continuación” (Aranda SERVICE DESK EXPRESS, 2015):
52
♦ EXPRESS Incident Management
♦ Problem Management
♦ Change Management
♦ Configuration EXPRESS Management
♦ Service Level Management EXPRESS
Gestión de Incidentes (Incident Management) :”Diariamente se presentan gran
cantidad de incidentes en las organizaciones que deben quedar debidamente
documentados con información sobre el usuario final, el técnico de servicio y las
aplicaciones involucradas, entre muchos detalles que se deben tener en cuenta,
para hacer un buen manejo de los incidentes”. (Aranda SERVICE DESK, 2015)
Aranda SERVICE DESK cuenta con la capacidad de hacer escalamiento y
asignación de incidentes de forma integrada con la base de datos de conocimiento
y las reglas del negocio para su manejo, con el objetivo de resolver rápidamente
cada incidente.
Gestión de Problemas (Problem Management): El objetivo es resolver los
problemas de raíz, de manera que queden definitivamente superados. Algunos
incidentes pueden relacionarse con problemas después de analizar sus causas
fundamentales, otros problemas se constituyen por sí solos. Una vez inicie el
problema ha sido registrado, sus causas identificadas y la solución encontrada y
aplicada y el problema puede ser cerrado. En muchos casos la solución de un
problema requiere hacer una solicitud de cambio por lo que es fundamental la
integración con el módulo de gestión de cambios.
Gestión de Cambios (Change Management): La gestión de cambios le permite a
la organización modelar y definir los procesos de cambio que se requieren, de
modo que se automatice el proceso y sus aprobaciones.
53
Acuerdos de Nivel de Servicio (Service Level Management) : Teniendo en
cuenta la dependencia de las empresas con los servicios de TI, la degradación o
caída de éstos puede causar graves problemas a las organizaciones o incluso
llegar a ser catastróficos; por esta razón es indispensable contar con una
herramienta que le permita definir acuerdos de niveles de servicio basados en
requerimientos específicos del negocio de modo tal que se garantice que los
asuntos críticos de la empresa sean manejados con la prioridad adecuada, en los
tiempos acordados y con el monitoreo necesario.
“Con Aranda SERVICE DESK se puede tener toda la información que se requiere
para determinar el cumplimiento de los acuerdos y analizar los indicadores de
desempeño, esto con el fin de modificar o adecuar continuamente los servicios
para que cumplan y excedan las expectativas de la empresa.
Integración con Aranda CMDB (Configuration Management): Aranda
SERVICE DESK se integra con Aranda CMDB (solución de base de datos de
gestión de la configuración), que los casos que se registren, (incidentes,
problemas, cambios) puedan ser asociados a los elementos de configuración (CIs)
de su empresa, es decir, de cualquier objeto (inventariado) que haga parte de la
infraestructura de la empresa como, computadores personales, servidores,
impresoras, teclados, teléfonos, entre otros.
Con esta herramienta es posible tener la información centralizada y debidamente
relacionada a los procesos de soporte y procedimientos de la organización de
forma rápida y confiable.
Multiproyecto: Es posible gestionar los procedimientos de soporte de una o
varias organizaciones y/o proyectos desde un único punto, visualizando toda la
información asociada en la misma consola de forma centralizada”. (Aranda
SERVICE DESK EXPRESS, 2015)
54
BENEFICIOS
Gestión y control sobre las solicitudes de soporte
Organización y control en el soporte
Información completa por cada caso
Monitoreo continuo de casos y de los activos asociados
Fácil integración con otras herramientas
Acceso a consola web para seguimiento de los casos
Implementación Mejores Prácticas ITIL
Solución efectiva a los problemas
Mayor Productividad
Asistencia permanente especializada
Mayores niveles de servicio y soporte a clientes internos
Reducción instantánea de costos de soporte
Reducción de asistencia técnica y costos del servicio
Protege y aprovecha al máximo la inversión en infraestructura tecnológica
generando alta rentabilidad
Disminución en tiempos de respuesta a usuarios
Certificación PinkVERIFY, en nueve procesos ITIL V.3
ALTIRIS: “Symantec Service Desk es una poderosa herramienta de incidentes,
problemas, cambios, lanzamiento y gestión del conocimiento basada en ITIL, que
mejora la disponibilidad y niveles de servicio.
Service Desk está diseñado para una rápida implementación, fácil integración,
personalización de arrastrar y soltar y la optimización de los procesos de TI para
entregar beneficios inmediatos. Anteriormente conocido como Altiris HelpDesk 6.
Una solución automatizada de respuesta a incidentes y resolución de problemas
para una rápida rehabilitación y eficaz de los incidentes de los usuarios finales, los
problemas sistémicos y los cambios esenciales administrados.
55
ServiceDesk ofrece una rápida instalación y la configuración a través de una
interfaz de usuario basada en asistente y se integra directamente con TI
Management Suite para reducir las interrupciones del servicio, acelerar las
restauraciones de servicios, las cuestiones sistémicas correctas y reducir el tiempo
de inactividad - ahorro de valiosos recursos de TI y gastos”. (Symantec
ServiceDesk, s.f.)
Características principales
ITIL y mejores procesos de Service Desk basado en la práctica
Arrastrar y soltar Diseñador de flujo de trabajo
Autoservicio y procesos automatizados
Integración avanzada con Symantec y productos de 3 ª parte
En consonancia, rápida y fácil de aprender la interfaz de gestión intuitiva
Fácil configuración permite ServiceDesk para ser adaptado y personalizado
para los clientes y de las necesidades de organización
Autoservicio y automatización de procesos permite el cierre rápido de
entradas con menos intervención del personal, mayor satisfacción del
usuario final y la reducción de costos
Fácil de usar con la integración fuera de la caja con otras soluciones de
Symantec (por ejemplo, IT Management Suite.)
Beneficios clave
Reducir los costes y los errores humanos
Agiliza TI y los procesos y procedimientos de negocio
Proporciona un único punto de contacto para identificar y resolver
incidentes usuario final y los problemas sistémicos y cambios de gestión
esenciales
Reduce las interrupciones del servicio, acelera las restauraciones de
servicios, corrige problemas sistémicos y reduce el tiempo de inactividad.
56
Impulsar la innovación mediante la automatización de procesos de TI
comunes y la adopción de nuevas tecnologías sin la adición de nuevas
herramientas, el personal o metodologías.
Para la toma de la decisión de que herramienta utilizar se analizaron los siguientes
parámetros:
o Número de clientes
o Clientes conocidos
o “base del conocimiento”
o “Escalamiento a grupos de seguridad o especialistas específicos”
o “Trabajo colaborativo.”
o “Preparación”
o “Detección y Análisis”
o “Contención, erradicación y Recuperación”
o “Actividad posterior al Incidente”
La calificación será: 1.No lo tiene 2. Lo hace a medias 3. Lo hace muy bien
Ilustración 7 Parametrización de herramientas Service Desk
En el análisis del cuadro anterior se pudo concluir que las cuatro herramientas
analizadas están certificadas en ITIL y cumplen con los requerimientos necesarios
para implementar un sistema de gestión de incidentes de seguridad de la
57
información. Sin embargo como Corbeta ya cuenta con la implementación de
Aranda Service Desk, se recomienda realizar la parametrización necesaria, que
permita crear y atender incidentes de seguridad de la información, con su
respectivo grupo de respuesta.
58
8.5 ACCIONES CORRECTIVAS Y PREVENTIVAS ANTE INCIDENTES
CONOCIDOS.
Para llevar acciones preventivas y correctivas ante los incidentes de seguridad de
la información, se definió el siguiente procedimiento, donde un incidente no
conocido pasa por una serie de pasos con el fin de darle una solución,
documentándolo para que la próxima vez que se presente, se tengan las
herramientas para contenerlo o eliminarlo con mayor rapidez y reduciendo el
impacto que pueda generar.
Figura 7 Incidentes Conocidos
Se definirán dos comités encargados de analizar los incidentes de seguridad y de
tomar las decisiones que apoyen el mejoramiento de los procesos para tomar las
respectivas acciones correctivas y preventivas. Los comités son el comité de
incidentes urgentes y el comité de incidentes normales.
Es importante llevar acciones preventivas y correctivas que permitan atacar los
incidentes catalogados como conocidos, es decir aquellos incidentes de los que ya
se tiene conocimiento, que en algún momento se han presentado u ocurrido y que
INCIDENTE
REGISTRO
INCIDENTE CONOCIDO
INCIDENTE NO CONOCIDO
COMITÉ DE INCIDENTES NORMALES
COMITÉ DE INCIDENTES URGENTES
SOLUCIÓN
BASE DE DATOS DEL CONOCIMIENTO
NOSI
ACCIONES PREDETERMINADAS
DOCUMENTADAS
59
a su vez han pasado y se han revisado en el comité de incidentes normales, el
que a su vez ha determinado unas acciones predeterminadas para dar solución y
mejora. Antes de determinar la finalización de la revisión del incidente se debe
realizar pruebas que avalen que la solución planteada es la más efectiva, de lo
contrario el comité debe evaluar otras posibles soluciones para atacar los eventos
e incidentes de raíz.
Un incidente conocido es aquel incidente que ya ha ocurrido y que ha pasado por
el comité de incidentes normales y tiene una acción predeterminada que se definió
en el comité y está documentado en una base de datos de incidentes conocidos.
Ejemplo de incidente conocido: Computador con virus. ¿Ha ocurrido? si, ¿paso
por el comité? si, ¿que definió el comité que se hacía?, se formatea computador.
Por otro lado se tienen los incidentes no conocidos, son aquellos incidentes de los
que no se tiene conocimiento, que no se han presentado en ningún momento.
Cualquier incidente que amenace la seguridad de la información y que pueda
generar un alto impacto, ya sea por el número de usuarios afectados o porque se
han visto incluidos sistemas o servicios críticos para la organización, se debe de
proponer una respuesta urgente, analizada por el comité de incidentes urgentes.
Estos incidentes urgentes se vuelven conocidos cuando son detectados por el
sistema de gestión de incidentes y se les aplica el proceso para convertirlos en
incidentes conocidos. Cuando se presentan los incidentes no conocidos estos
deben pasar por el comité de incidentes urgentes para contener el impacto que
pueda ocasionar de la manera más rápida, la solución que se determine debe ser
documentada y registrada, para que así el comité de incidentes normales lo
analice y catalogue como un incidente conocido, registrando el procedimiento de
solución en la base de datos del conocimiento y permitiendo aplicar la solución a
los incidentes igualmente clasificados o catalogados. El procedimiento planteado
permite de igual forma realizar un mejoramiento en la base de datos del
60
conocimiento cada vez que se requiera o cada vez que el incidente presente
variaciones.
Al registrar el incidente y compararlo con la base de datos de incidentes
conocidos, un incidente puede plantearse por sí mismo o como combinación de
uno o más incidentes. Una vez se registra el incidente, los comités verificarán si se
tienen información del mismo y si existe ya una solución temporal o definitiva
conocida.
Si el incidente comunicado tiene una solución temporal o definitiva, es un incidente
conocido. El grupo de respuesta a incidentes de seguridad puede ponerse en
contacto con el usuario para ofrecerle dicha solución.
Incidente normal: Estos incidentes también tienen un procedimiento establecido
pero requieren de valoración y autorización del comité. A su vez, los incidentes de
esta categoría se pueden dividir en menores, significativos y mayores. Es el
principal.
Incidentes Estándar: Son incidentes ya establecidos, pre-autorizados por el comité
y para los cuales ya existe un procedimiento definido. Por ejemplo el movimiento
del PC de un usuario los incidentes con aprobación previa se implantan y permite
restablecer rápidamente el servicio.
La base de datos del conocimiento de errores conocidos se genera y se alimenta
cuando ocurre un caso y pasa por un comité, el comité lo analiza y define una
única solución estándar para ese tipo de caso, el caso se almacena y el equipo de
respuesta inmediata ejecutara lo que dice allí.
Las acciones correctivas y preventivas van a basarse en lo que diga la
documentación.
61
8.6 PLAN DE MEJORAMIENTO CONTINUO ANTE LOS INCIDENTES DE
SEGURIDAD.
Basados en ITIL se propone que el plan de mejoramiento continuo de los
incidentes tenga los siguientes procesos, se define de la siguiente manera:
Evaluación de incidentes:
Evaluar la gestión de incidentes de seguridad de la información regularmente. Esto
incluye la identificación de áreas o servicios en que no se cumplen los niveles de
seguridad propuestos, y las conversaciones regulares con las áreas del negocio
para asegurar que los niveles de seguridad propuestos sean cónsonos con sus
incidentes.
Evaluación de Procesos:
Evaluar los procesos de gestión de incidentes de seguridad de la información
regularmente. Esto implica identificación de áreas o servicios en que no se cumple
con las metas de KPI propuestas, así como comparativas, auditorías,
evaluaciones de madurez y revisiones de procesos. Se debe evaluar
constantemente las políticas, la gestión de incidentes, la clasificación de incidentes
y todos los procesos que van ligados.
Definición de Iniciativas del proceso de mejoramiento continuo:
Definir iniciativas específicas con el fin de mejorar la seguridad de la información y
los procesos involucrados, partiendo de los resultados de evaluaciones de la
seguridad de la información y lo procesos. Las iniciativas resultantes son internas
y propiciadas por el grupo de respuesta a incidentes de seguridad de la
información, o iniciativas que requieren la cooperación de las demás áreas o
62
terceros expertos en el tema. Se deben proponer planes, proyectos, soluciones
que ayuden a mejorar los procesos apuntando al mejoramiento continuo de la
gestión de incidentes y la organización en general, buscando proteger los activos
de la información.
Monitoreo del plan de mejoramiento continuo:
“Verificar si las iniciativas de mejora se implementan de acuerdo con lo planificado,
e introducir medidas correctivas, de ser necesario. Verificar si los objetivos
propuestos con el sistema de gestión de incidentes de seguridad de la información
se están cumpliendo”. (ITIL Perfeccionamiento Continuo del Servicio - CSI, 2015)
Evaluación de
incidentes
Evaluación de
procesos
Definición de
Iniciativas del proceso
de mejoramiento
continuo
Monitoreo del plan de
mejoramiento
continuo
Figura 8 Mejoramiento continuo de los incidentes de seguridad.
63
9 CONCLUSIONES
En el trabajo desarrollado se realizó una propuesta para la gestión de
incidentes de seguridad de la información para el registro, clasificación,
notificación, escalamiento y respuesta oportuna a los sucesos o incidentes
ocurridos en Corbeta.
Se realizó un análisis de las políticas de Corbeta, y se encontró que no tenían
las políticas completas para poder desarrollar un proceso de seguridad de
gestión de incidentes de la información. Se definieron unas políticas que
apoyaran el sistema de gestión de incidentes de seguridad de la información.
Se realizó un análisis de riesgos donde se pudo identificar las posibles
amenazas que afectan los activos y que podrían convertirse en incidentes de
seguridad de la información, así mismo se evidencio que Corbeta necesita un
sistema de gestión de incidentes de seguridad de la información para mitigar
los riesgos, entre otros controles que minimicen la probabilidad de que una
amenaza se convierta fácilmente en un incidente de seguridad de la
información.
Se propuso un método para clasificar y evaluar los incidentes de seguridad de
la información que actualmente se presentan o los que se pueden presentar,
partiendo de un método estándar conocido.
Se analizaron cuatro herramientas que permitirán al usuario ver y gestionar sus
incidentes de seguridad en todo momento y hacer un seguimiento continuo
siempre bajo normas certificadas en las mejores prácticas ITIL, así se tendrá
64
toda la trazabilidad del incidente desde el momento en el que se recibe hasta
que se resuelve y todo esto desde una interfaz sencilla y fácil de usar.
Después de analizar las herramientas de gestión de incidentes de seguridad de
la información certificadas en ITIL se concluyó que todas cumplen con los
requerimientos necesarios para implementar un sistema de gestión de
incidentes de seguridad de la información. Y como Corbeta ya cuenta con la
implementación de Aranda Service Desk, se recomienda realizar la
parametrización necesaria, que permita crear y atender incidentes de
seguridad de la información, con su respectivo grupo de respuesta.
Se propone conformar dos comités de atención a los incidentes de seguridad
de la información, uno de incidentes normales y el comité de incidentes
urgentes para el análisis y aprobación de las soluciones únicas y que se
establezcan como acciones predeterminadas para alimentar la base de datos
del conocimiento y tomar las respectivas acciones correctivas y preventivas.
Las acciones correctivas y preventivas a los incidentes conocidos, deberán
pasar por un comité de seguridad muy parecido a cómo funciona el proceso de
gestión de cambio de ITIL, pues así se facilita que los incidentes conocidos
puedan contenerse o eliminarse de la manera más rápida y apropiada.
Se presentó un modelo de mejoramiento continuo de la gestión de los
incidentes de seguridad basado en ITIL. los procesos que se definieron son los
siguientes: Evaluación de incidentes, evaluación de procesos, definición de
iniciativas del proceso de mejoramiento continuo, Monitoreo del plan de
mejoramiento continuo.
65
10 REFERENCIAS BIBLIOGRÁFICAS
Aranda SERVICE DESK. (27 de 8 de 2015). Obtenido de arandasoft: http://www.arandasoft.com/manuales/Aranda%20SERVICE%20DESK%207.2%20esp/asdkweb7.2_mui_es_la_2.0.pdf
Aranda SERVICE DESK EXPRESS. (s.f.). Recuperado el 1 de Agosto de 2015, de arandasoft: http://www.arandasoft.com/downloads/datasheets/es/v8/asdk_ex8.pdf
Aranda SERVICE DESK EXPRESS. (17 de 8 de 2015). Obtenido de arandasoft: http://arandasoft.com/aranda-service-desk-express/
BMC Remedy Service Desk. (15 de 8 de 2015). Obtenido de goit: http://goit.com.mx/sitio/servicios-y-soluciones/diagrama_bsm/bmc-request-and-support/bmc-remedy-service-desk.html
CA Service Desk Manager. (12 de 8 de 2015). Obtenido de adrpanama: http://adrpanama.com/index.php/infraestructura-tecnologica-ti/121-ca-service-desk-manager
CASOS DE ÉXITO. (13 de 8 de 2015). Obtenido de Ca: http://www.ca.com/co/success.aspx
Ciclo de vida de un incidente. (s.f.). Recuperado el 20 de Agosto de 2015, de Csuc: http://www.csuc.cat/es/comunicaciones/seguridad/equipo-de-respuesta-a-incidentes/ciclo-de-vida-de-un-incidente
Common Vulnerabilities and Exposures. (9 de Abril de 2013). Recuperado el 1 de Julio de 2015, de Wikipedia, La enciclopedia libre: https://es.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures
Cross-site scripting. (4 de Septiembre de 2015). Recuperado el 15 de Septiembre de 2015, de Wikipedia, La enciclopedia libre: https://es.wikipedia.org/wiki/Cross-site_scripting
Equipo de Respuesta ante Emergencias Informáticas. (27 de Abril de 2015). Recuperado el 20 de Agosto de 2015, de Wikipedia, La enciclopedia libre: https://es.wikipedia.org/wiki/Equipo_de_Respuesta_ante_Emergencias_Inform%C3%A1ticas
Gestión de Incidencias. (10 de 8 de 2015). Obtenido de Osiatis: http://itilv3.osiatis.es/operacion_servicios_TI/gestion_incidencias/conceptos_basicos.php
Gestión de Incidentes. (s.f.). Recuperado el 20 de Agosto de 2015, de ITIL®-Gestión de Servicios TI: http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/gestion_de_incidentes/introduccion_objetivos_gestion_de_incidentes/introduccion_objetivos_gestion_de_incidentes.php
GESTIÓN DE INCIDENTES DE SEGURIDAD INFORMÁTICA. (16 de 9 de 2009). Obtenido de Proyecto AMPARO: www.proyectoamparo.net/documentos/manual/manual-capitulo1.pdf
Glosario SERVICE DESK. (9 de Abril de 2012). Recuperado el 5 de Agosto de 2015, de Aranda Wiki: http://arandatraining.com/wiki/index.php?title=Glosario_SERVICE_DESK
GUÍA TÉCNICA COLOMBIANA GTC-ISO/IEC 27035. (2012). TECNOLOGÍA DE LA INFORMACIÓN.TÉCNICAS DE SEGURIDAD. GESTIÓN DE INCIDENTES DE SEGURIDAD DE LA INFORMACIÓN, 96.
66
Hacker (seguridad informática). (1 de Septiembre de 2015). Recuperado el 20 de Septiembre de 2015, de Wikipedia, La enciclopedia libre: https://es.wikipedia.org/wiki/Hacker_(seguridad_inform%C3%A1tica)
Information Technology Infrastructure Library. (24 de Septiembre de 2015). Recuperado el 24 de Septiembre de 2015, de Wikipedia, La enciclopedia libre: https://es.wikipedia.org/wiki/Information_Technology_Infrastructure_Library
Information Technology Infrastructure Library. (11 de Agosto de 2015). Recuperado el 25 de Agosto de 2015, de Wikipedia, La enciclopedia libre: https://es.wikipedia.org/wiki/Information_Technology_Infrastructure_Library
Ingeniería social (seguridad informática). (22 de Septiembre de 2015). Recuperado el 23 de Septiembre de 2015, de Wikipedia, La enciclopedia libre: https://es.wikipedia.org/wiki/Ingenier%C3%ADa_social_(seguridad_inform%C3%A1tica)
Instituto Colombiano de Normas Técnicas y Certificación. (31 de Julio de 2015). Recuperado el 20 de Agosto de 2015, de Wikipedia, La enciclopedia libre: https://es.wikipedia.org/wiki/Instituto_Colombiano_de_Normas_T%C3%A9cnicas_y_Certificaci%C3%B3n
Inyección SQL. (21 de Septiembre de 2015). Recuperado el 22 de Septiembre de 2015, de Wikipedia, La enciclopedia libre: https://es.wikipedia.org/wiki/Inyecci%C3%B3n_SQL
ISO27000. (s.f.). Recuperado el 15 de Agosto de 2015, de iso27000: http://www.iso27000.es/download/doc_iso27000_all.pdf
ISO27000. (2005). Recuperado el 14 de Agosto de 2015, de El portal de ISO 27001 en Español: http://www.iso27000.es/faqs.html
ITIL Perfeccionamiento Continuo del Servicio - CSI. (3 de Agosto de 2015). Recuperado el 5 de Agosto de 2015, de wiki.es: http://wiki.es.it-processmaps.com/index.php/ITIL_Perfeccionamiento_Continuo_del_Servicio_-_CSI
Malware. (21 de Septiembre de 2015). Recuperado el 25 de Septiembre de 2015, de Wikipedia, La enciclopedia libre: https://es.wikipedia.org/wiki/Malware
Organización Internacional de Normalización. (11 de 9 de 2015). Recuperado el 15 de 9 de 2015, de Wikipedia, La enciclopedia libre: https://es.wikipedia.org/wiki/Organizaci%C3%B3n_Internacional_de_Normalizaci%C3%B3n
Organización Internacional de Normalización. (11 de Septiembre de 2015). Recuperado el 20 de Septiembre de 2015, de Wikipedia, La enciclopedia libre: https://es.wikipedia.org/wiki/Organizaci%C3%B3n_Internacional_de_Normalizaci%C3%B3n
Realimentación. (8 de Septiembre de 2015). Recuperado el 15 de Septiembre de 2015, de Wikipedia, La enciclopedia libre: https://es.wikipedia.org/wiki/Realimentaci%C3%B3n
Remedy Service Desk de BMC. (11 de 8 de 2015). Obtenido de grupoarion: http://www.grupoarion.com.mx/bmc-remedy-service-desk/
Symantec ServiceDesk. (s.f.). Recuperado el 20 de Julio de 2015, de Symantec: http://www.symantec.com/service-desk/
67
Worth, D. (22 de Abril de 2014). Nine basic cyber attacks cause 92 percent of all security incidents, Verizon finds. Recuperado el 20 de Agosto de 2015, de V3: http://www.v3.co.uk/v3-uk/news/2340840/nine-basic-cyber-attacks-cause-92-percent-of-all-security-incidents-verizon-finds
68
LISTA DE TABLAS
Tabla 1: Clasificación de activos ............................................................................ 28
Tabla 2: Clasificación de amenazas ...................................................................... 29
Tabla 3: TABLAS DE PROBABILIDAD/FRECUENCIA .......................................... 30
Tabla 3: Tabla de probabilidad-frecuencia ............................................................. 30
Tabla 4: Tabla de Impacto ..................................................................................... 30
Tabla 5: Tabla de Calificación de controles ........................................................... 31
Tabla 6: Aceptabilidad del riesgo ........................................................................... 31
Tabla 7: Mapa de aceptabilidad. ............................................................................ 32
Tabla 8: Mapa del riesgo ....................................................................................... 34
Tabla 9: Distribución porcentual del riesgo ............................................................ 36
Tabla 10: Riesgos extremos. ................................................................................. 37
Tabla 11: Clasificación de incidentes ..................................................................... 40
Tabla 12: Prioridad de los incidentes ..................................................................... 42
69
LISTA DE FIGURAS
Figura 1 Ciclo de vida de un incidente ................................................................... 14
Figura 2 Cronograma ............................................................................................. 15
Figura 3 PHVA Incidentes de seguridad ................................................................ 19
Figura 4 Aceptabilidad del riesgo ........................................................................... 36
Figura 5 Identificación de un evento de seguridad................................................. 45
Figura 6 BMC REMEDY SERVICE DESK ............................................................. 51
Figura 7 Incidentes Conocidos............................................................................... 58
Figura 8 Mejoramiento continuo de los incidentes de seguridad. .......................... 62
70
GLOSARIO
ITIL: “La Biblioteca de Infraestructura de Tecnologías de Información,
frecuentemente abreviada ITIL (del inglés Information Technology Infrastructure
Library), es un conjunto de conceptos y buenas prácticas para la gestión de
servicios de tecnologías de la información, el desarrollo de tecnologías de la
información y las operaciones relacionadas con la misma en general. ITIL da
descripciones detalladas de un extenso conjunto de procedimientos de gestión
ideados para ayudar a las organizaciones a lograr calidad y eficiencia en las
operaciones de TI. Estos procedimientos son independientes del proveedor y han
sido desarrollados para servir como guía que abarque toda infraestructura,
desarrollo y operaciones de TI”. (Information Technology Infrastructure Library,
2015)
KPI: Indicador clave de desempeño
SLA: Acuerdo de nivel de servicio
CVE: “Common Vulnerabilities and Exposures, siglas CVE, es una lista de
información registrada sobre conocidas vulnerabilidades de seguridad, donde cada
referencia tiene un número de identificación único.1 De esta forma provee una
nomenclatura común para el conocimiento público de este tipo de problemas y así
facilitar la compartición de datos sobre dichas vulnerabilidades”. (Common
Vulnerabilities and Exposures, 2013)
Csirt: “Un Equipo de Respuesta ante Emergencias Informáticas (CERT, del inglés
Computer Emergency Response Team) es un centro de respuesta a incidentes de
seguridad en tecnologías de la información. Se trata de un grupo de expertos
responsable del desarrollo de medidas preventivas y reactivas ante incidencias de
seguridad en los sistemas de información. Un CERT estudia el estado de
71
seguridad global de redes y ordenadores y proporciona servicios de respuesta
ante incidentes a víctimas de ataques en la red, publica alertas relativas a
amenazas y vulnerabilidades y ofrece información que ayude a mejorar la
seguridad de estos sistemas”. (Equipo de Respuesta ante Emergencias
Informáticas, 2015)
ISO: “La Organización Internacional de Normalización o ISO (del griego ἴσος,
«isos», que significa «igual»), nacida tras la Segunda Guerra Mundial (23 de
febrero de 1947), es el organismo encargado de promover el desarrollo de normas
internacionales de fabricación (tanto de productos como de servicios), comercio y
comunicación para todas las ramas industriales. Su función principal es la de
buscar la estandarización de normas de productos y seguridad para las empresas
u organizaciones (públicas o privadas) a nivel internacional”. (Organización
Internacional de Normalización, 2015)
Hacker: “es alguien que descubre las debilidades de un computador o de una red
informática, aunque el término puede aplicarse también a alguien con un
conocimiento avanzado de computadoras y de redes informáticas. Los hackers
pueden estar motivados por una multitud de razones, incluyendo fines de lucro,
protesta o por el desafío”. (Hacker (seguridad informática), 2015)
Gestión de Cambios: “Es el proceso por el cual se controlan los cambios a la
infraestructura o a alguna particularidad de los servicios de forma controlada,
ejecutando los cambios aprobados, con el mínimo de interrupción”. (Glosario
SERVICE DESK, 2012)|
Urgencia: “Es el tiempo de demora aceptable para el usuario o el proceso del
negocio sin el servicio”. (Glosario SERVICE DESK, 2012)
72
Feedback: “La realimentación también referida de forma común como
retroalimentación es un mecanismo por el cual una cierta proporción de la salida
de un sistema se redirige a la entrada, con objeto de controlar su comportamiento.
La realimentación se produce cuando las salidas del sistema o la influencia de las
salidas del sistemas en el contexto, vuelven a ingresar al sistema como recursos o
información. La realimentación permite el control de un sistema y que el mismo
tome medidas de corrección con base en la información realimentada”.
(Realimentación, 2015)
Software malicioso: “El malware (del inglés "malicious software"), también
llamado badware, código maligno, software malicioso o software malintencionado,
es un tipo de software que tiene como objetivo infiltrarse o dañar una computadora
o sistema de información sin el consentimiento de su propietario. El término
malware es muy utilizado por profesionales de la informática para referirse a una
variedad de software hostil, intrusivo o molesto. El término virus informático suele
aplicarse de forma incorrecta para referirse a todos los tipos de malware, incluidos
los virus verdaderos”. (Malware, 2015)
Cross Site Scripting – XSS: “es un tipo de inseguridad informática o agujero de
seguridad típico de las aplicaciones Web, que permite a una tercera persona
inyectar en páginas web visitadas por el usuario código JavaScript o en otro
lenguaje similar (ej: VBScript), evitando medidas de control como la Política del
mismo origen. Este tipo de vulnerabilidad se conoce en español con el nombre de
Secuencias de órdenes en sitios cruzados”. (Cross-site scripting, 2015)
SQL Injection: “es un método de infiltración de código intruso que se vale de una
vulnerabilidad informática presente en una aplicación en el nivel de validación de
las entradas para realizar operaciones sobre una base de datos. El origen de la
vulnerabilidad radica en el incorrecto chequeo y/o filtrado de las variables
utilizadas en un programa que contiene, o bien genera, código SQL. Es, de hecho,
73
un error de una clase más general de vulnerabilidades que puede ocurrir en
cualquier lenguaje de programación o script que esté embebido dentro de otro”.
(Inyección SQL, 2015).
Ingeniería Social: “es la práctica de obtener información confidencial a través de
la manipulación de usuarios legítimos. Es una técnica que pueden usar ciertas
personas, tales como investigadores privados, criminales, o delincuentes
informáticos, para obtener información, acceso o privilegios en sistemas de
información que les permitan realizar algún acto que perjudique o exponga la
persona u organismo comprometido a riesgo o abusos”. (Ingeniería social
(seguridad informática), 2015)