Gestión de incidentes de seguridad

  • Miguel Colobran Huguet

    Miguel Colobran Huguet

    Licenciado en Informática por la Universidad Autónoma de Barcelona. Elaboró su trabajo de investigación en el Departamento de Ingeniería de la Información y de las Comunicaciones (DEIC) de la misma Universidad. Ha trabajado como profesor ayudante y asociado en el DEIC, y ha ejercido de consultor de varias asignaturas de la Universitat Oberta de Catalunya. Actualmente, trabaja como analista en informática forense.

PID_00174860
Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada, reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea éste eléctrico, químico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita de los titulares del copyright.

Introducción

La actividad diaria de una organización está fuertemente basada en los sistemas informáticos. Consecuentemente, el valor de los datos almacenados en estos sistemas es cada vez más importante, convirtiéndose en lo que se denominan "activos informáticos". El crecimiento de las redes en los sistemas informáticos, y la interconexión de éstas formando Internet, ha creado un nuevo reto para los administradores de sistemas: la prevención, el control y la respuesta a los incidentes de seguridad en las redes de las organizaciones.
Veremos cómo la correcta gestión de los incidentes de seguridad nos permite afrontarlos de forma eficaz, respondiendo en la medida adecuada. Además, es posible obtener la información necesaria para valorar la magnitud del incidente, así como tomar las medidas necesarias para evitar que se vuelva a producir.
Sin embargo, muchos de los incidentes son intencionados y provocan daños de muy distinta índole. Una gestión eficaz de los incidentes, así como de su resolución, nos permitirá un rápido regreso a la normalidad, a la par que una recolección de evidencias digitales con valor probatorio ante un tribunal. Sin una cadena de etapas correctamente elaborada, desde la prevención del incidente al informe pericial, pasando por el análisis forense de las evidencias digitales, y por lo tanto su valor como prueba, éstas no tendrían la debida admisibilidad.

Objetivos

Competencias
Con los materiales de este módulo didáctico, se pretende que aprendáis y desarrolléis los siguientes conocimientos y habilidades:

  1. Saber cómo organizar correctamente la gestión de incidentes en un sistema informático.

  2. Comprender cómo se articula un equipo de respuesta a incidentes.

  3. Saber cómo actuar ante un incidente informático.

  4. Comprender la preparación previa para responder adecuadamente a un incidente.

  5. Conocer la naturaleza de los incidentes de seguridad.

  6. Saber integrar el análisis forense dentro de la gestión de incidentes y como una consecuencia de ésta.

1.Introducción

Cualquier red conectada a Internet puede ser vulnerable a un ataque. De modo que el correcto tratamiento y gestión de los incidentes de seguridad en los sistemas informáticos y redes de las organizaciones es uno de los objetivos a cumplir por los administradores de los sistemas informáticos.

1.1.Estadíticas

Lo primero que cabe preguntarse es si la inversión en tiempo y recursos humanos (en dinero, en definitiva) tiene sentido para proteger el sistema informático. La mejor respuesta la podemos hallar por medio de las estadísticas, que nos permitirán hacernos una idea de la cantidad y gravedad de los incidentes, y, por lo tanto, si el conocido "a mí no me va a pasar" tiene algún fundamento.
Debemos partir de la base de que la recogida de información sobre delincuencia tecnológica es muy difícil, puesto que muchos incidentes nunca llegan a ser denunciados. Además, resulta complejo tipificarlos, de modo que las estadísticas difícilmente pueden reflejar la cantidad y tipología de los incidentes y son, por tanto, básicamente orientativas de lo que pueda estar sucediendo.
Porcentaje de ataques reportados
Por ejemplo, entre 1992 y 1995, DISA –Defense Infomation System Agency (https://www.disa.mil)– elaboró un estudio en el que realizó 38.000 ataques a varias organizaciones gubernamentales y militares. Resumiendo, sólo el 0,70% de éstos (267) fueron reportados.
A pesar de todo, es un hecho evidente que el registro de los ataques a los sistemas informáticos ha experimentado un notable aumento. Así lo refleja el estudio de Trendmicro, correspondiente a los ataques por virus, y por tanto de sistemas vulnerables en alguna medida, en el año 2008.
Países más infectados durante el 2008 (Fuente: Trendmicro)
Los países más infectados
1
Estados Unidos
373,689,902
2
Japón
96,787,968
3
Taiwán
73,517,376
4
China
30,256,433
5
Australia
17,692,567
6
España
8,621.550
7
Francia
8,364,656
8
Alemania
4,557,972
9
Canadá
3,598,830
10
Turquía
3,361,939
Ataques web en España
El estudio de RedIris (Red Académica y de Investigación Española) refleja que, durante el año 2007, se atendieron 2.949 incidentes reales, un 66,32% más que el año anterior. También destaca que, en la actualidad, la tendencia es que los ataques se produzcan vía web.
Incidentes reales reportados por RedIris
Incidentes reales reportados por RedIris
El CERT reporta un número de incidentes muy importante, así como una gran cantidad de vulnerabilidades.
Vulnerabilidades catalogadas: crecen en número cada año (Fuente: https://www.cert.org/stats/cert_stats.html)
Año
Total de vulnerabilidades catalogadas
1.er-3.er trimestres, 2008
6.058
2007
7.236
2006
8.064
2005
5.990
2004
3.780
2003
3.784
2002
4.129
2001
2.437
2002
1.090
1999
417
1998
262
1997
311
1996
345
1995
171
Incidentes reportados al CERT: crecen anualmente de forma vertiginosa (fuente: https://www.cert.org/stats/)
Año
Mensajes de correo procesados
Llamadas hotline recibidas
Reportes de incidentes recibidos
2003
542.754
934
137.529
2002
204.841
880
82.094
2001
118.907
1.417
52.658
2000
56.365
1.280
21.756
1999
34.612
2.099
9.859
1998
41.871
1.001
3.734
1997
39.626
1.058
2.134
1996
31.268
2.062
2.573
1995
32.084
3.428
2.412
1994
29.580
3.665
2.340
1993
21.267
2.282
1.334
Las pérdidas que ocasionan estos incidentes de seguridad son múltiples (por ejemplo, pérdida de datos, daños materiales, etc.) y ocasionan graves perjuicios económicos. Hay que tener presente que, en muchas ocasiones, existe pérdida de información que no puede ser recuperada, o cuya recuperación conlleva un elevado coste económico.
Incidentes que involucran pérdida de información (hasta marzo del 2009). (Fuente: https://datalossdb.org/statistics)
Incidentes que involucran pérdida de información (hasta marzo del 2009). (Fuente: https://datalossdb.org/statistics)
Los ataques en línea (el fraude, por ejemplo, tal y como muestra en la siguiente figura) también han experimentado un gran aumento.
Incremento de ataques en línea (fuente: s21sec)
Incremento de ataques en línea (fuente: s21sec)
Conclusión
La política más acertada no es prepararse ante un ataque, sino evitar que éstos ocurran, y en todo caso preveer la situación, por si alguno tiene éxito.

1.2.Clasificación de los ataques

Existen multitud de ataques distintos, y por ello resulta muy importante poder clasificarlos de alguna manera. Podemos agruparlos según el modo de actuar, así como en función de quien lo origina.
1.2.1.Según cómo actúa
Los ataques que puede sufrir el hardware, el software y, de una manera muy especial, los datos, se clasifican en cuatro grandes grupos:

  • Interrupción. Ataque contra la disponibilidad en el cual se destruye o queda no disponible un recurso del sistema.

Ataque de interrupción
Un ejemplo de ataque de interrupción es cortar una línea de comunicación o deshabilitar el sistema de ficheros del servidor. Otro ejemplo son los ataques de denegación de servicio.

  • Intercepción. Ataque contra la confidencialidad, en el cual un elemento no autorizado consigue el acceso a un recurso. En este tipo de ataque no nos referimos únicamente a posibles usuarios que actúen como espías en la comunicación entre emisor y receptor.

Ataque de intercepción
Por ejemplo, un proceso que se ejecuta subrepticiamente en un ordenador y que almacena en un fichero las teclas que pulsa el usuario que utiliza el terminal, constituiría un ataque de intercepción.

  • Modificación. Ataque contra la integridad en el que, además de conseguir el acceso no autorizado a un recurso, también se consigue modificarlo, borrarlo o alterarlo de cualquier manera. Los ataques hechos por los intrusos.

Ataques contra la integridad
Borrado de bases de datos, alteración de páginas web, etc., son ejemplos típicos de esta modalidad de ataque.

  • Fabricación. Ataque contra la integridad en el que un elemento consigue crear o insertar objetos falsificados en el sistema.

Ataque de fabricación
Un ejemplo de ataque de fabricación es añadir, de una manera no autorizada, un nuevo usuario y la contraseña correspondiente en el fichero de contraseñas.
Representación de los diferentes tipos de ataques que puede sufrir la comunicación entre emisor y receptor
Representación de los diferentes tipos de ataques que puede sufrir la comunicación entre emisor y receptor
1.2.2.Según quien lo origina
Pueden ser una o varias personas las que, con diferentes objetivos, originan un ataque a un sistema informático con el fin de intentar acceder a información confidencial, destruirla o simplemente conseguir el control absoluto del sistema atacado. Conocer los objetivos de los atacantes y sus motivaciones resulta, pues, esencial para prevenir y detectar las acciones.
Los ataques provenientes de personas se pueden clasificar en dos grandes grupos:

  • Ataques pasivos.

  • Ataques activos.

Ataques pasivos
El atacante no modifica ni destruye ningún recurso del sistema informático, simplemente lo observa, normalmente con la finalidad de obtener alguna información confidencial. A menudo, este ataque se produce sobre la información que circula por una red. El atacante no altera la comunicación, sino que sencillamente la escucha y obtiene la información que se transmite entre el emisor y el receptor. Como la información que se transmite no resulta alterada, la detección de este tipo de ataque no es una tarea sencilla, porque la escucha no tiene ningún efecto sobre la información circulante. Una solución muy eficaz, que permite resolver este tipo de problema, consiste en el uso de técnicas criptográficas para hacer que la información no se transmita en claro y no pueda ser comprensible para los espías.
Ataques activos
En una acción de este tipo, el atacante altera o destruye algún recurso del sistema.
Ejemplos de ataques activos
En el caso de un espía que monitoriza una red, se podrían dar problemas muy serios, como los que exponemos a continuación:

  • Suplantación de identidad. El espía puede suplantar la identidad de una persona y enviar mensajes en su nombre.

  • Reactuación. Uno o varios mensajes legítimos son interceptados y reenviados diferentes veces para producir un efecto no deseado (por ejemplo, intentar repetir distintas veces un ingreso en una cuenta bancaria).

  • Degradación fraudulenta del servicio. El espía evita el funcionamiento normal de los recursos del sistema informático. Por ejemplo, podría interceptar y eliminar todos los mensajes que se dirigen a un usuario determinado.

  • Modificación de mensajes. Se modifica una parte del mensaje interceptado y se reenvía a la persona a quien iba dirigido originalmente.

Como ya se ha indicado previamente, conocer las motivaciones que pueden tener las personas para atacar los sistemas informáticos puede ser vital a la hora de prevenir todo tipo de intrusiones. Hay que tener presente que un ataque puede provenir tanto desde el interior de la red (insiders) como desde el exterior (outsiders).
Representación esquemática de cómo se realizan los ataques por parte de los insiders y los outsiders
Representación esquemática de cómo se realizan los ataques por parte de los insiders y los outsiders
Veamos, pues, el perfil de los posibles atacantes de un sistema informático:

  • Antiguos trabajadores. Una parte muy importante de los ataques a sistemas informáticos son los realizados por antiguos trabajadores que, antes de dejar la organización, instalan todo tipo de software destructivo como, por ejemplo, virus o bombas lógicas que se activan en ausencia del trabajador que, despedido o descontento por las condiciones de trabajo, ha decidido cambiar de empleo. La presencia de este tipo de software no siempre es fácil de detectar, pero al menos sí que se pueden evitar los ataques que el antiguo trabajador pueda llevar a cabo desde fuera con el nombre de usuario y la contraseña de que disponía cuando todavía trabajaba en la organización. Por lo tanto, como norma general, hay que dar de baja todas las cuentas del ex trabajador y cambiar las contraseñas de acceso al sistema, cuanto más rápido mejor (1) .

Suceso
En la empresa Fannie Mae despidieron a un ingeniero. Éste, antes de abandonarla, dejó una bomba lógica (un script que estuvo a la espera durante tres meses) preparada para atacar los 4.000 servidores de la compañía. Gracias a otro ingeniero, que lo detectó cinco días más tarde (después de su activación), los daños sólo afectaron a varias decenas de servidores, aunque la empresa tuvo que mantenerse cerrada durante una semana. El ingeniero que elaboró la bomba lógica se enfrenta a una pena de diez años de prisión.

  • Personal de la misma organización. Aunque por defecto el personal interno disfruta de la confianza de la organización, hay que tener en cuenta que algunos ataques se pueden producir desde dentro mismo de la institución. A menudo, no hace falta que estos ataques sean intencionados (aunque, cuando lo son, son los más devastadores que se pueden producir); pueden ser accidentes provocados por el desconocimiento del personal (2) (por ejemplo, el formateo accidental de un disco duro).

El 70% (tal como se muestra en el gráfico) de los robos, sabotajes o accidentes relacionados con los sistemas informáticos son causados por el propio personal de la organización propietaria de dichos sistemas (inside factor).
Porcentaje y tipo de ataques en una organización. (Fuente https://www.cybsec.com)
Porcentaje y tipo de ataques en una organización. (Fuente https://www.cybsec.com)
Nota
Las técnicas básicas para minimizar los riesgos de ataques de este tipo son:

  • Limitar el número de gente con accesos administrativos.

  • Asegurarse de que la gente con permisos administrativos son de confianza.

  • Limitar la cantidad de permisos que una única persona posee.

  • Limitar la superposición de gente con permisos de confianza.

  • Buscar brechas en los permisos de confianza y castigar al culpable.

  • Hackers (intrusos informáticos). Estas personas llevarán a cabo normalmente ataques pasivos orientados a obtener información confidencial (por ejemplo, un examen de un curso universitario), o simplemente con la finalidad de ponerse a prueba para obtener el control del sistema atacado (3) . Además, si el atacante (4) es lo bastante hábil, incluso podría borrar las huellas de sus acciones en los ficheros que las registran (llamados genéricamente ficheros log). Como este tipo de acciones no producen ningún efecto "visible", no son fácilmente detectables. Los intrusos suelen aprovechar la vulnerabilidad conocida de sistemas operativos y software para conseguir el control de todo el sistema informático. Para llevar a cabo este tipo de acciones, basta con ejecutar diversos software que se pueden obtener en Internet y que automatizan los ataques a los sistemas informáticos sin que el intruso necesite disponer de muchos conocimientos técnicos.

Además de las herramientas que hemos mencionado, los intrusos disponen de otras técnicas más sencillas (al menos desde el punto de vista informático), pero igual de efectivas.
Ejemplo de técnica de ataque
Puede resultar muy productivo hacer una sencilla búsqueda de contraseñas escritas en papeles entre la basura contenida en una papelera (trashing); de una manera más ingeniosa, el intruso podría suplantar la identidad de otra persona para averiguar la contraseña (mascarada). Asimismo, un intruso que quisiera obtener una contraseña en un sistema determinado podría llamar por teléfono al administrador, hacerse pasar por otra persona y pedir la contraseña con la excusa de que la ha olvidado o perdido. En un exceso de buena fe, el administrador podría cambiar la contraseña y entregar la nueva al intruso en la misma comunicación telefónica. Las variantes de este tipo de ataques son múltiples y muchas se incluyen dentro de lo que se denomina ingeniería social, es decir, la manipulación de las personas a fin de que hagan determinadas acciones que en realidad no quieren hacer.

  • Intrusos remunerados. A pesar de no ser un tipo de ataque muy frecuente, también vale la pena tenerlo en cuenta. En este caso, los intrusos se encuentran perfectamente organizados (incluso pueden estar en diferentes localizaciones geográficas) y atacan de una manera conjunta el sistema de una organización determinada. Disponen de muchos medios técnicos y reciben remuneraciones muy elevadas de la organización rival que dirige el ataque, a menudo con el ánimo de acceder a información confidencial (un nuevo diseño, un nuevo software, etc.) o bien con la intención de provocar un daño importante en la imagen de la organización atacada.

Conclusión
En general, pensamos que la gran mayoría de los ataques provienen del exterior de la organización y que son escasos, pero las estadísticas demuestran todo lo contrario.
Podemos concluir que:

  • Los ataques externos son más numerosos que los internos (en cantidad).

  • El porcentaje de éxito en los ataques internos es más elevado.

  • El daño causado por ataques internos es mucho mayor que por ataques externos.

2.Gestión de incidentes de seguridad

Así pues, dado que existen gran cantidad de ataques y que pueden provenir del exterior de la propia organización, es necesario tomar medidas para evitarlo. Los incidentes van a ser un elemento con el que vamos a tener que convivir, y la respuesta apropiada a un incidente debe ser una parte esencial de la directiva de seguridad general y de la estrategia de mitigación de riesgos.
Poder responder a los incidentes de seguridad tiene claras ventajas. No obstante, también pueden existir ventajas financieras indirectas.
Puede que vuestra compañía de seguros os ofrezca descuentos si puede demostrar que la organización es capaz de controlar los ataques rápidamente y de manera rentable. O, si se trata de un proveedor de servicios, un plan formal de respuesta a incidentes puede ayudaros a aumentar su negocio, ya que muestra que se toma en serio el proceso de seguridad de la información.

2.1.Concepto de vulnerabilidad e incidente

Vamos a entender por incidente cualquier hecho anómalo que afecta al funcionamiento del sistema. Dado que los incidentes son imprevisibles, lo único que se puede hacer es gestionarlos del mejor modo posible, puesto que es imposible que no existan. Así pues, la gestión de un incidente informático incluirá la monitorización, detección y la respuesta ante el incidente, que en general puede considerarse un incidente de seguridad.
Definición de vulnerabilidad de un activo
La potencialidad o posibilidad de ocurrencia de la materialización de una amenaza sobre dicho activo. Se determina por dos medidas: frecuencia de ocurrencia y degradación causada.
Definición de incidente de seguridad informática
La violación o intento de violación de la política de seguridad
Así, se convierte en esencial la gestión de riesgos y la planificación. Partiendo del hecho que el incidente será inevitable, hay que asegurar que los planes de respuesta diseñados reducen el impacto del mismo en la organización. La planificación de respuesta de incidentes, globalmente, está muy relacionada con el conocimiento de procesos y con el desarrollo y aplicación de contramedidas proactivas de detección, prevención y reacción para cada fallo potencial.
Existe una confusión terminológica entre gestión de incidentes y gestión de incidentes de seguridad. La gestión de incidentes es un área de procesos perteneciente a la gestión de servicio TI. El primer objetivo de la gestión de incidentes es recuperar el nivel habitual de funcionamiento del servicio y minimizar, en todo lo posible, el impacto negativo en la organización de forma que la calidad del servicio y la disponibilidad se mantengan.
Los incidentes que no pueden ser resueltos rápidamente por el equipo de ayuda al usuario son asignados a un especialista del equipo de soporte técnico. La resolución del incidente debe ser ejecutada lo antes posible para restaurar el servicio rápidamente. El proceso habitual de gestión de incidentes es el siguiente:

  • Detección y registro del incidente.

  • Clasificación y soporte inicial.

  • Investigación y diagnóstico.

  • Resolución y recuperación.

  • Cierre del incidente.

  • Monitorización, seguimiento y comunicación del incidente.

Aunque se parecen en algunos aspectos, no debemos confundirlos.

2.2.Ciclo de vida del incidente

Bajo el punto de vista de la organización, la gestión del incidente debe integrarse dentro de la seguridad global del sistema informático. Éste, a su vez, depende del buen diseño de las medidas de prevención, detección y recuperación.
El ciclo de vida general de los incidentes de seguridad puede verse en la siguiente figura.
Esquema básico de la gestión de incidentes. Etapas
Esquema básico de la gestión de incidentes. Etapas
Cada una de estas etapas contiene un conjunto de acciones que deben llevarse a buen término para que el conjunto sea efectivo.
El incidente es el centro de un conjunto de fases que hay que tener en cuenta:
Esquema completo de la gestión de incidentes. Etapas y accionesExisten herramientas para la gestión de incidentes. RTIR (request tracker for incident response) es de las que gozan de más prestigio y gratuita. Disponible en: https://bestpractical.com/rtir/
Esquema completo de la gestión de incidentes. Etapas y acciones (5)
La seguridad global de un sistema informático depende, en gran medida, del diseño detallado de las siguientes etapas:

  • Prevención o protección o preparación. El objetivo consiste en intentar eliminar las causas que pueden ocasionar los incidentes. Por ello, se habla de análisis y gestión de riesgos. Esta etapa incluye tanto la prevención de los ataques como la preparación para responder correctamente ante uno. Para minimizar el daño potencial de un ataque se requiere estar preparado y seguir unas prácticas, como realizar copias de seguridad de los datos críticos de forma periódica, controlar y actualizar el software periódicamente, y tener implementada y documentada una política de seguridad. Las políticas de copia de seguridad hechas con regularidad minimizan la pérdida potencial de datos. El control con los proveedores, sitios web de seguridad y listas de distribución es una manera de estar al día sobre el estado del software y los parches de seguridad. Es necesario actualizar el software para corregir las vulnerabilidades que se van descubriendo. También es vital actualizar el software antivirus para mantener la protección del sistema actualizada.

  • Detección y análisis. Dado que el riesgo es imprevisible, existe una alta probabilidad de que tarde o temprano se materialice, de modo que el escenario más adecuado es la gestión de los incidentes. El primer paso en la gestión de incidentes es la identificación del mismo. Se deben identificar varias características de un ataque antes de que pueda ser contenido correctamente: determinar que está ocurriendo realmente un ataque, sus efectos sobre la red (local y remota si la hubiere), el posible daño a los sistemas y de dónde se origina.

  • Contención. Con el ataque identificado, deben considerarse los pasos necesarios para minimizar sus efectos. La contención permite proteger otros sistemas y redes del ataque y limitar el daño. En esta fase, se hacen los pasos necesarios para detener el ataque. Una vez contenido el ataque, la fase final es la recuperación.

  • Recuperación. Finalmente, cuando el incidente ha tenido lugar, hay que responder al suceso. De modo que hay que recuperar el sistema a un estado seguro, aplicar acciones correctivas y reunir las evidencias del incidente. Hay que valorar el daño, qué información se ha perdido. ¿Por qué ha sucedido? ¿Se ha controlado inmediatamente y correctamente? ¿Se podría haber controlado mejor? La fase de análisis permite a los administradores determinar la razón del ataque y las acciones correctivas para protegerse contra ataques futuros.

La seguridad puede verse como la gestión del riesgo.

3.Prevención del incidente

Bajo la óptica de la seguridad, el primer objetivo a plantearse en una organización es reducir la probabilidad de sufrir incidentes de seguridad. Siempre que exista un incidente de seguridad, la organización sufrirá un daño que, por pequeño que sea, tendrá un impacto económico.
En la mayoría de los ámbitos de la vida, es mejor prevenir que curar, y la seguridad no es una excepción. Siempre que sea posible, es deseable evitar que se produzcan incidentes de seguridad a tener que solucionarlos. La etapa de prevención pretende, por un lado, evitar que se produzcan incidentes, a sabiendas de que resulta imposible evitarlos todos, y por ello van a tomarse las medidas necesarias. Por otro lado, dicha etapa pretende prepararse por si ocurren.
El conjunto de acciones que llevaremos a cabo, en esta etapa, puede verse en la siguiente figura.
Etapa de prevención. Acciones a realizar
Etapa de prevención. Acciones a realizar
Además de este conjunto de acciones específicas, hay unas indicaciones que nos pueden ayudar a minimizar la repercusión de los incidentes de seguridad.

  • Establecer claramente y poner en práctica todas las directivas y procedimientos. Muchos incidentes de seguridad están provocados accidentalmente por el personal de TI, que no ha seguido o no ha entendido los procedimientos de administración de cambios, o bien no ha configurado correctamente los dispositivos de seguridad, como pueden ser los firewalls o los sistemas de autenticación. Las directivas y los procedimientos se deben probar exhaustivamente para garantizar que son prácticos y claros, y que ofrecen el nivel de seguridad apropiado.

  • Establecer programas de formación sobre la seguridad, tanto para el personal de TI como para los usuarios finales.

  • Desarrollar, implementar y poner en práctica una directiva que requiera contraseñas seguras.

  • Comprobar con regularidad todos los registros y mecanismos de registro, incluidos los registros de eventos del sistema operativo, los registros específicos de aplicación y los registros de sistema de detección de intrusiones.

3.1.Backup

Una buena política de copias de seguridad es la clave para tener segura la información de la organización.
Algunos de los motivos para hacer copias de seguridad son los siguientes:

  • Proteger la información contra un fallo del sistema o algún desastre natural.

  • Proteger la información de los usuarios (los ficheros) contra borrados accidentales.

  • Proteger la información de los usuarios y de la organización contra ataques por parte de terceros.

  • Duplicar la información de los usuarios por seguridad, ya que se pueden dar casos de usos incorrectos que la dejen inconsistente o la modifiquen incorrectamente.

  • Posibilitar un traspaso de la información cuando se actualiza o se reinstala el sistema.

3.1.1.Tipos de copias de seguridad
Podemos distinguir los siguientes tipos de copia de seguridad:

  • Copia de seguridad completa. También se conoce con el nombre de copia de seguridad total o copia full dump. Se hace una copia de toda la partición del disco en cinta. A menudo, la copia se hace considerando el formato del disco y sin tener en cuenta el sistema de ficheros, ya que sólo hay que conocer la tabla de particiones del disco y en qué parte está la partición para duplicarla en un dispositivo de cinta. En estos casos, la restauración no puede ser selectiva; se tiene que restaurar toda la partición y no se puede seleccionar sólo un fichero. Está también la copia de seguridad completa del sistema de ficheros, en la que sí que es posible una restauración selectiva.

  • Copia de seguridad incremental. En este caso, se guardan sólo los ficheros que se han modificado desde la última copia de seguridad que se ha hecho. Las copias de seguridad incrementales se utilizan, conjuntamente, con las copias de seguridad completas en lo que se llaman políticas de copias de seguridad.

  • Copia de seguridad selectiva. También es posible hacer una copia de sólo unos ficheros determinados. Normalmente, se lleva a cabo con ficheros de pedidos.

  • Copia de seguridad diferencial. Este nuevo tipo de copia realiza una copia de todos los ficheros que se han modificado desde la última copia total. Así pues, si realizamos una copia total cada sábado y diferencial el resto de los días, la copia del viernes contendrá todos los ficheros modificados desde el sábado.

Esquema de una copia de seguridad diferencial
Esquema de una copia de seguridad diferencial
La copia diferencial presenta varias ventajas con respecto a la copia total. La primera, como es natural, es que requiere menos espacio, y la segunda, asociada a la primera, es que reduce el tiempo o ventana de copia.
Con respecto a la copia incremental, aporta la ventaja de que, en el proceso de recuperación, sólo necesitaremos la última copia total y la última copia diferencial. Sin embargo, la copia diferencial, a partir del segundo día, requerirá más espacio y más tiempo o ventana de copia.
3.1.2.Políticas de copias de seguridad
La estrategia de cómo hacer las copias de seguridad es crítica para asegurar que se haga todo correctamente y que se pueda restaurar la información cuando haga falta.
La necesidad de crear estrategias de copias de seguridad proviene del hecho de que, actualmente, en los servidores los discos son de mucha capacidad y, por lo tanto, hay mucha información (tanto de usuarios como de sistema), y toda esta información no cabe en un solo dispositivo de salida (en una sola cinta, por ejemplo). Finalmente, la transferencia dura horas y, por lo tanto, se tienen que buscar soluciones para optimizar su uso.
Analicemos la variabilidad de la información. Con un simple vistazo, nos podemos dar cuenta de lo siguiente:

  • Hay información que varía diariamente.

  • Hay información que se modifica muy poco a lo largo del tiempo.

  • Hay información que no hay que guardar en copias de seguridad (los ficheros temporales, por ejemplo).

Así pues, una estrategia de copia que lo copie todo diariamente no parece muy acertada.
Sí parece claro que tenemos que hacer una copia diaria de la información que varía cada día (acostumbra a ser la información de la organización). Se puede encontrar en los servidores o distribuida por toda la organización. En cualquier caso, hace falta que hagamos una copia diaria de estos datos.
Con la información sobre la cantidad de datos que hay que copiar (el volumen), y sabiendo el dispositivo en el que queremos hacer la copia, tenemos una idea aproximada de las cintas que necesitamos. Una posible política de copias es la siguiente:
Política de copias de seguridad
Política de copias de seguridad
Guardaremos la primera copia total de cada mes. De esta manera, siempre es posible recuperar los datos de meses anteriores.
Las ventajas son:

  • La copia es rápida porque no hay copias totales diariamente, y las incrementales sólo copian los ficheros modificados durante el día, que son pocos.

  • Se ahorran cintas, ya que las copias incrementales ocupan poco en relación con las totales.

Los problemas son:

  • Recuperar un fichero requiere tiempo, porque se tiene que pasar por el juego de cintas desde la última copia total y todas las incrementales hasta llegar al fichero de la fecha que se quiere.

  • Si falla una cinta incremental, no se puede recuperar nada de los juegos de cintas incrementales posteriores.

Ejemplo sobre los problemas de una cinta incremental
Es viernes, y hay que recuperar un fichero del jueves. Una cinta del juego del miércoles ha fallado, y, por lo tanto, no es posible recuperar la copia incremental de este día. Como consecuencia de ello, no se puede recuperar la copia incremental del jueves, aunque el juego de cintas esté en perfecto estado.
Problemas con cinta incremental
Problemas con cinta incremental
Este problema de las cintas incrementales hace que muchas organizaciones no utilicen la opción de las copias incrementales por el riesgo que comporta y, por lo tanto, se decanten por opciones de copia diferencial o completa de los datos.
En el mismo ejemplo anterior, si cambiamos las copias incrementales por copias diferenciales, la copia del jueves contiene los datos de las copias anteriores hasta la total; por lo tanto, la pérdida de la copia del miércoles, en este caso, no sería un problema.
Ahora bien, ¿cuál podría ser una manera de ahorrar cintas? Una posible política de copias de seguridad es la siguiente:

  • Llamamos a los juegos de cintas A, B, C, D, E, etc.

  • Cada mes, guardaremos un juego de cintas, de manera que tendremos una copia de la información mensual.

Política de copias de seguridad
Juegos de cintas

  • El juego de cintas E del último viernes del mes lo guardaremos para no utilizarlo. Al final del año, tendremos doce juegos de cintas con la información de la organización. Tendremos que decidir si algunos de estos juegos los volvemos a utilizar o los continuamos guardando.

3.2.Motorizar la red

La monitorización de una red es un elemento clave para asegurar que no tenemos una incidencia de seguridad. Así, el control de red puede darnos las primeras indicaciones de actividades anómalas.
En consecuencia, debemos supervisar y analizar con regularidad el tráfico de red y el rendimiento del sistema informático, y comprobar con regularidad todos los sistemas y dispositivos de red para garantizar que tienen instaladas las revisiones más recientes.
Las siguientes indicaciones permiten monitorizar la red y pueden ayudar a detectar un incidente. Algunos de estos mecanismos pueden automatizarse con scripts y software (6) .

  • Documentar la actividad normal de un sistema o red. De este modo, se detectan anomalías con mayor facilidad.

  • Centralizar registros. Los registros de un sistema de detección de intrusos, de aplicaciones, de sistemas operativos y de dispositivos de monitorización facilitan el estudio de incidentes, y por lo tanto, su detección.

  • Correlacionar eventos, a partir de los registros, a poder ser, centralizados.

  • Utilizar sniffers para obtener datos que permitan detectar anomalías en el tráfico de red.

Ejemplo del uso de sniffers
Por ejemplo, un tráfico creciente de forma repentina contra un puerto puede indicar una nueva vulnerabilidad en un servicio, que puede estar siendo explotada.

  • Mantenerse al día en materia de seguridad. Por ejemplo, mediante suscripciones a listas de correo, visita regular a portales de seguridad, participación en foros, etc.

3.2.1.Herramientas
Algunas herramientas, de reconocido prestigio, que pueden ayudar en esta tarea, son:
MRTG (multi router traffic grapher)
Herramienta escrita por Tobias Oetiker y Dave Rand. Se utiliza para supervisar la carga de tráfico de interfaces de red. MTRG (7) genera un informe en HTML con gráficas, proporcionando una representación visual del tráfico en el tiempo. Para recoger la información de los dispositivos (routers en la mayoría de los casos), se utiliza SNMP (8) ; información que MRTG debe tratar para generar los gráficos.
MRTG
MRTG
Nagios
Es un sistema de monitorización de redes que goza de mucha popularidad, y se encarga de monitorizar los equipos (hardware) y servicios (software) que se hayan especificado, alertando cuando su comportamiento no sea el deseado. Con Nagios (9) podremos saber, en cada momento, qué máquinas y dispositivos están encendidos, cuáles están apagados, cuáles están fallando y cuáles funcionan correctamente, qué servicios operan correctamente y cuáles no, etc. En resumen, podemos ver el estado de una red en tiempo real, independientemente de su tamaño.
Puede monitorizar servicios de red (SMTP, POP3, HTTP, SNMP, etc.), recursos de sistemas hardware (carga del procesador, uso de los discos, memoria, estado de los puertos, etc.) y en general cualquier parámetro de interés de un sistema con independencia de sistemas operativos. Tiene la posibilidad de monitorización remota mediante túneles SSL, cifrados o SSH, y la posibilidad de programar plugins específicos para nuevos sistemas.
b0699_m2_015.gif
Capturas de pantalla de Nagios
Capturas de pantalla de Nagios

3.3.Creación de un equipo de respuesta de incidentes

El hecho de reunir un equipo antes de que se produzca cualquier incidente es muy importante para la organización, e influirá positivamente en la manera de tratar los incidentes. Un equipo de respuesta a incidentes (10) es crítico ante los incidentes de seguridad. Los miembros del equipo deben tener definidas claramente sus tareas para asegurar de que no quede ningún área de la respuesta sin cubrir. Deberán tener la formación y responsabilidad para acometer los incidentes que ocurran.
La pertenencia y estructura ideal del CSIRT depende del tipo de organización y de la estrategia de administración de riesgos. No obstante, como regla general, el CSIRT debe pertenecer en parte o totalmente al equipo de seguridad de la organización. El equipo principal está compuesto por profesionales responsables de coordinar una respuesta a cualquier incidente. El número de miembros del CSIRT dependerá del tamaño y la complejidad de la organización. No obstante, debe asegurarse de que cuenta con suficientes miembros para cubrir, adecuadamente, todas las tareas del equipo en cualquier momento.
El equipo realizará las siguientes tareas:

  • Supervisar los sistemas en busca de infracciones de seguridad.

  • Servir como punto central de comunicación, tanto para recibir los informes de incidentes de seguridad como para difundir información esencial sobre los incidentes a las entidades correspondientes.

  • Documentar y catalogar los incidentes de seguridad.

  • Aumentar el nivel de conciencia con respecto a la seguridad dentro de la compañía, para ayudar a evitar que se den incidentes en la organización.

  • Posibilitar la auditoría de sistemas y redes mediante procesos como la evaluación de vulnerabilidades y pruebas de penetración.

  • Obtener más información sobre las nuevas vulnerabilidades y estrategias de ataque empleadas por los atacantes.

  • Investigar acerca de nuevas revisiones de software.

  • Analizar y desarrollar nuevas tecnologías para minimizar los riesgos y vulnerabilidades de seguridad.

  • Ofrecer servicios de consultoría sobre seguridad.

  • Perfeccionar y actualizar continuamente los sistemas y procedimientos actuales.

3.3.1.Preparación del equipo
Al crear un CSIRT, debemos preparar al equipo para tratar con los incidentes. Para ello, debemos seguir estas pautas:

  • Formarlos en el uso adecuado y la ubicación de las herramientas de seguridad críticas. También hemos de estudiar el hecho de facilitarles equipos portátiles preconfigurados con estas herramientas para asegurar que no se malgasta tiempo en la instalación y configuración de las herramientas, de modo que puedan responder a los incidentes. Estos sistemas y las herramientas asociadas deben estar protegidos adecuadamente cuando no se usen.

  • Reunir toda la información de comunicación pertinente. Debemos asegurarnos de que contamos con los nombres y números de teléfono de contacto de las personas de la organización a las haya que avisar (incluidos los miembros del CSIRT, los responsables de mantener todos los sistemas y los encargados de las relaciones con los medios). También necesitamos los detalles del proveedor de servicios de Internet (PSI) y las autoridades locales y nacionales. Hay que hablar con la asesoría legal para contactar con las autoridades locales pertinentes antes de que se produzca un incidente. Esto nos ayudará a asegurarnos de que entendemos los procedimientos apropiados para comunicar los incidentes y reunir pruebas. Debemos informar a la asesoría legal de cualquier contacto con las autoridades.

  • Colocar toda la información del sistema de emergencia en una ubicación central y sin conexión, como una carpeta física o un equipo sin conexión. Esta información de emergencia incluye las contraseñas de los sistemas, las direcciones IP, la información sobre la configuración de los routers, las listas de conjuntos de reglas del firewall, copias de las claves de entidad emisora de certificados, los nombres y números de teléfono de contacto, los procedimientos de extensión, etc. Esta información debe estar disponible con facilidad y se debe mantener en un lugar seguro. Un método para proteger y hacer esta información fácilmente disponible consiste en cifrarla en un equipo portátil de seguridad dedicado, guardado en una caja fuerte con acceso limitado a ciertas personas, como el coordinador del CSIRT, o el director del departamento informático o tecnológico.

3.3.2.Miembros del equipo
Los roles del personal de un CSIRT incluyen:

  • Gerente o líder de equipo.

  • Personal de hotline o para priorización de acciones necesarias en una situación de crisis.

  • Personal para manejo de incidentes y vulnerabilidades.

  • Personal de análisis de equipos.

  • Administradores de la red o del sistema.

  • Relaciones con los medios.

  • Representantes legales.

3.4.Plan de contingencias

Planificar todos los pasos necesarios para permitir una recuperación ante un desastre o una situación de crisis es lo que se denomina plan de contingencia (en inglés, disaster recovery plan).
Los desastres son inevitables, en la mayoría de los casos impredecibles y varían de tipo y de magnitud. La mejor estrategia para las organizaciones es la confección de un plan de contingencia. Para una organización, un desastre significa una disfunción brusca de parte o de todas sus operaciones comerciales, que pueden provocar una pérdida irreparable o incluso el cierre.
Con el fin de minimizar las pérdidas provocadas por los desastres, es muy importante tener un buen plan de recuperación para cada organización, departamento y operación.
Para diseñar correctamente un plan de contingencias, necesitamos poseer una idea más precisa de lo que es la seguridad y de lo que es la información en términos informáticos, así como su valoración.
3.4.1.¿Qué es la seguridad informática?
definición de seguridad informática
Se define como seguridad informática al conjunto de técnicas y métodos que se utilizan para proteger tanto la información como los equipos informáticos en donde ésta se encuentra almacenada, ya sean estos individuales o conectados a una red, frente a posibles ataques premeditados y sucesos accidentales.
Aunque sea de forma intuitiva, todos entendemos que un sistema informático se considerará seguro si se encuentra libre de todo riesgo y daño. A pesar de que no resulta muy sencillo formalizar el concepto de seguridad informática, entenderemos como tal el conjunto constituido por las metodologías, documentos, software y hardware, que determinan que los accesos a los recursos de un sistema informático sean realizados exclusivamente por los elementos autorizados a hacerlo. Debido a que es completamente imposible garantizar la seguridad o inviolabilidad absoluta de un sistema informático, en lugar del inalcanzable concepto de seguridad, es preferible utilizar el término fiabilidad. Por lo tanto, no se podrá entender la seguridad informática como un concepto cerrado consecuencia de la aplicación mecánica de una serie de métodos, sino como un proceso que se puede ver comprometido en cualquier momento de la forma más insospechada posible.
En general, pues, diremos que un sistema informático es fiable cuando se satisfacen las tres propiedades siguientes:

  • Confidencialidad. Los recursos que integran el sistema sólo pueden ser accedidos por los elementos autorizados a hacerlo. Por recursos del sistema no sólo se entenderá la información, sino cualquier recurso en general: impresoras, procesador, etc.

  • Integridad. Los recursos del sistema sólo pueden ser modificados o alterados por los elementos autorizados a hacerlo. La modificación incluye diferentes operaciones, como el borrado y la creación, además de todas las posibles alteraciones que se puedan realizar sobre un objeto.

  • Disponibilidad. Los recursos del sistema deben permanecer accesibles a los elementos autorizados.

Como nos podemos imaginar, es muy difícil encontrar un sistema informático que maximice las tres propiedades. Normalmente, y dependiendo de la orientación del sistema, se priorizará alguna de les tres vertientes.
En un sistema que almacene datos de carácter personal, el elemento a priorizar es la confidencialidad de la información, a pesar de que también debemos tener muy presente la preservación (en la medida de lo posible) de la integridad y la disponibilidad. Observemos que no sirve de nada garantizar la confidencialidad mediante algún método criptográfico, si permitimos que un intruso pueda borrar fácilmente la información almacenada en el disco duro del servidor (ataque contra la integridad).
Definición de seguridad informática en el entorno laboral
Existe alguna otra definición, que sin ser tan formalmente técnica, puede sernos útil conocer. Esta definición observa la seguridad informática en el entorno de trabajo:
La seguridad informática es el conjunto de reglas, planes y acciones encaminadas a garantizar tres objetivos:

  • La capacidad de trabajo (disponibilidad), en cuanto a que el sistema esté operativo en todo momento, o haya mecanismos de contingencia que permitan un ritmo de trabajo aceptable mientras se soluciona el problema.

  • La integridad de la información (consistencia), de modo que la información puesta a disposición del usuario sea oportuna.

  • La confidencialidad de los datos (confidencialidad, control de acceso, autenticación), para que cada usuario tenga acceso sólo a la información que le corresponde.

3.4.2.Información
La protección de la información es una consecuencia de la aplicación de un conjunto de mecanismos o estrategias de seguridad. A grandes rasgos, estas estrategias deben considerar los siguientes elementos:

  • La seguridad debe ser un objetivo global.

  • Nuestra seguridad debe diseñarse como algo que forme parte de nuestra organización, considerando todos sus aspectos.

  • La legislación debe formar parte del diseño desde el principio como algo natural.

La gestión y planificación de toda la seguridad será un aspecto clave. Sin ella, nada de lo que se haga va a tener ningún objetivo final, y por lo tanto sólo mejorará parcialmente la seguridad. Además, la gestión no sólo es necesaria en la implantación de la seguridad, sino también en el control y mantenimiento de toda la seguridad que pongamos en marcha.
El valor de la información
Cuando diseñamos nuestro sistema de seguridad, descubrimos que no toda la información tiene el mismo valor. Así, debemos determinar qué información es valiosa y cuán valiosa es. No hay que caer en el error común de asumir, implícitamente, que toda la información debe ser protegida.
El valor de la información estará relacionado con alguno de los siguientes aspectos.

  • El valor intrínseco de la información.

  • La creación de la información.

  • El almacenaje de la información.

  • La retención y administración de la información.

Conociendo el valor de la información, podemos evaluar los esfuerzos necesarios para protegerla. La protección de la información requiere una inversión inicial y progresiva, tanto si la inversión es hardware, software, almacenamiento o personal (que, naturalmente, se puede traducir en costes económicos).
A continuación, enumeramos algunos parámetros que debemos valorar para evaluar el nivel de protección necesario para la información:

  • Si la información no tiene valor, no la protegeremos.

  • Si la pérdida (ya sea temporal o permanente), divulgación o modificación de la información no afecta al funcionamiento de la organización, entonces ¿para qué la protegemos o almacenamos? Mejor borrarla. Nos ahorra costes.

  • Si la pérdida de la información conlleva unos costes (económico o de funcionamiento de la organización) de creación de ésta menores que su protección, entonces no la protegeremos.

Pregunta clave
No toda la información es igual. ¿Por qué proteger toda la información al mismo nivel?
3.4.3.Plan de contingencia y análisis de riesgos
La ISO define el riesgo tecnológico como la probabilidad de que ocurra una amenaza usando vulnerabilidades existentes de un activo o activos generando pérdidas o daños. En base a esta definición, existen diferentes elementos en juego (amenazas, vulnerabilidades, activos, etc.), y por lo tanto hay muchas maneras de enfocar el riesgo. La seguridad es parte de un mecanismo global de tres componentes (11) :

  • Prevención. El objeto de interés en este componente radica en lo que se desea proteger. Es necesario averiguar qué nos interesa proteger y qué soluciones existen para proteger nuestro sistema.

  • Seguridad. En esta fase, tenemos que "implementar" la seguridad. Este es el plan de seguridad, es decir, cómo protegeremos.

  • Contingencia. Tenemos que tener presente que los sistemas pueden fallar, bien sea por ataques debidos a intrusos o por causas externas que no controlamos, como los desastres naturales. Por lo tanto, es necesario prever los protocolos de actuación ante una situación de estas características, es decir, qué hacer cuando falla la seguridad.

Análisis de riesgos
Es necesario asegurarse de que se tienen en cuenta todas las posibles causas de riesgos que pueden provocar problemas en el sistema. Se realiza un análisis de los riesgos, que se basa en calcular la posibilidad de que tengan lugar hechos problemáticos, se obtiene una valoración económica del impacto de estos éxitos negativos, y se contrasta el coste de la protección con el hecho de volver a crearla o comprarla.
Plan de contingencias
El plan de contingencias es, de hecho, una consecuencia del análisis de riesgos. Si sabemos qué queremos proteger, ahora tenemos que decidir qué hacemos ante un fallo del sistema o un resquicio de seguridad.
Un plan de contingencias no tendría sentido si pensáramos que nuestro plan de seguridad es perfecto. Desgraciadamente, los sistemas de seguridad no lo son nunca. Con el paso del tiempo aparecen agujeros no descubiertos antes, o errores de hardware en los equipos que pueden dejar el sistema informático vulnerable. O peor aún, una actualización del sistema (servidores, routers, estaciones de trabajo), que suponemos que mejora la seguridad pero que, en realidad, puede abrir nuevas grietas en nuestro sistema sin que nos demos cuenta. También podríamos hablar de contraseñas inseguras o débiles, rotación de personal dentro de la organización, etc., aspectos que tenemos que comprobar periódicamente para asegurar que nuestro sistema se mantiene seguro.
Así que tenemos que suponer que podemos sufrir un incidente de seguridad en cualquier momento y prepararnos para el caso "peor". Por lo tanto, es necesario prever las acciones y actuaciones a llevar a cabo en estas situaciones.
Con la condición de que, a pesar de todas las medidas que se puedan tomar, puede tener lugar un desastre, el plan de contingencias incluye un plan de recuperación de desastres, que tiene como objetivo restaurar el servicio informático lo antes posible y minimizar el coste y las pérdidas en la medida de lo posible.
Para que el diseño del plan de contingencias tenga sentido, se tiene que presuponer el peor caso de todos, el desastre total. De esta manera, el plan será el máximo de completo y podrá incluir toda la casuística.
El plan de contingencias deberá tener presente:

  • Si hay una pérdida, la asumimos (en coste y tiempo) y volvemos a empezar desde cero.

  • No podemos asumir la pérdida (por algún motivo, sea coste, tiempo, etc.) y por lo tanto necesitamos copia de seguridad. Esta información estará dentro del sistema de copias y, posiblemente, dentro del plan de recuperación de desastres.

  • También contemplaremos los incidentes, como por ejemplo fallos de hardware o software que pueden dejar inutilizado, total o parcialmente, el sistema informático, y confeccionaremos los protocolos a seguir ante este tipo de situaciones.

3.4.4.Sistemas de gestión de seguridad de la información (SGSI)
Debido a la complejidad de realizar un plan de seguridad, es necesaria una metodología. Por este motivo, aparecieron los sistemas de gestión de la seguridad de la información (SGSI).
En general, cualquier sistema de gestión de la seguridad tendrá que comprender la política, la estructura organizativa, los procedimientos, los procesos y los recursos necesarios para implantar la gestión de la seguridad de la información dentro de una organización. Básicamente, un sistema de gestión se caracteriza por:

  • Cubrir los aspectos organizativos, lógicos, físicos y legales.

  • Ser independiente de plataformas tecnológicas y mecanismos concretos.

  • Ser aplicable a todo tipo de organizaciones, independientemente del tamaño y actividad.

  • Tener, como todo sistema de gestión, un fuerte contenido documental.

En los SGSI, se define:

  • Activo. Recurso del sistema de información necesario –o relacionado con éste–, para que la organización funcione correctamente y alcance los objetivos propuestos por la dirección.

  • Amenaza. Acontecimiento que puede desencadenar un incidente en la organización, produciendo daños o pérdidas materiales o inmateriales en sus activos.

  • Riesgo. Posibilidad de que una amenaza se materialice.

  • Impacto. Consecuencia sobre un activo de la materialización de una amenaza.

  • Control. Práctica, procedimiento o mecanismo que reduce el nivel de riesgo.

En estas metodologías, la seguridad consiste en la realización de las tareas necesarias para garantizar los niveles de seguridad exigibles en una organización.
En consecuencia, la seguridad se tiene que entender como un proceso.
Los riesgos no se eliminan, se gestionan.
Existen diferentes metodologías para implementar un SGSI, básicamente MAGERIT y la metodología que incorpora el estándar ISO 27001:2005.

4.Detección y análisis

Etapa de detección y análisis. Acciones a realizar
Etapa de detección y análisis. Acciones a realizar
El proceso de detección de los incidentes de seguridad resulta fundamental, principalmente para minimizar su impacto en la organización.
El primer paso para la correcta detección de un incidente consiste en verificar que realmente ha sucedido y, en caso afirmativo, determinar su tipo y magnitud.
La correcta detección de un incidente de seguridad se realiza mediante diferentes fuentes. Algunas de ellas son:
 
 
Alarmas de un IDS
Sistema de detección de incidentes.
Alarmas de sistemas antivirus
Cuando detecta código malicioso, envía una alerta.
Alarmas de sistemas de monitorización
Control del rendimiento y tráfico de la red. Se usan herramientas como, por ejemplo, Nagios o MGRT.
Análisis de registros (logs)
Periódicamente, se deben revisar los logs de los sistemas operativos, de los dispositivos de red o de aplicaciones (como los gestores de bases de datos).
Intercambio de información
Debe realizase una comunicación fluida con otros equipos de respuesta.
Aviso de incidentes
Con miembros de la propia organización y de otras organizaciones.

4.1.Evaluación inicial

Es necesario tomar medidas a fin de saber si estamos tratando con un incidente verdadero o un falso positivo. Para ello, debemos hacernos una idea general del tipo y la gravedad del ataque, y reunir información para su identificación y tratamiento (contención y minimización del daño, si procediera).
Hay que ser precavido en la recepción de incidentes a partir del personal de la organización o de otras organizaciones.

  • Debería existir más de una vía de recepción para los incidentes (formularios electrónicos, teléfono, correo electrónico, etc.).

  • Deben existir criterios previamente acordados, como por ejemplo un formato de intercambio de información.

Para la correcta gestión de un incidente debemos registrar, al menos, los siguientes datos:

  • Fecha y hora en la que se ha detectado el incidente de seguridad.

  • Quién ha producido el incidente y cómo (si es el caso).

  • Naturaleza del incidente.

  • Cuándo ocurrió el incidente.

  • Hardware/software involucrado en el incidente.

Es posible que sea necesario realizar una evaluación de la información obtenida para determinar algunos puntos referentes al incidente, como su alcance o su naturaleza.

4.2.Identificación de la gravedad del ataque

Para poder recuperarse de forma eficaz de un ataque, se debe determinar la gravedad de la situación de peligro que han sufrido los sistemas.
Debemos determinar:

  • La naturaleza del ataque.

  • El punto de origen.

  • La intención del ataque. ¿Estaba el ataque dirigido específicamente a nuestra organización para conseguir información concreta o fue un ataque aleatorio?

  • Los sistemas puestos en peligro.

  • Los archivos a los que se ha tenido acceso.

Con esta información, podremos confeccionar una respuesta al incidente.
Además, como acciones adicionales, deberíamos tener presente lo siguiente:

  • Si se ha usado hardware no autorizado en la red.

  • Buscar entradas no autorizadas. En especial, en usuarios con privilegios (administrador, root o similares).

  • Buscar procesos o aplicaciones no autorizadas ejecutándose en el sistema.

  • Buscar errores (vacíos, ausencias) en ficheros y registros del sistema.

  • Revisar los registros de nuestro sistema de detección de intrusiones.

  • Examinar otros logs en busca de elementos inusuales.

  • Efectuar comprobaciones de integridad del sistema y archivos realizadas con anterioridad.

  • Comparar el rendimiento de los sistemas sospechosos con los niveles de rendimiento habituales. Se supone que se conocen los rendimientos y procesos habituales.

4.3.Clasificación

A priori, los incidentes de seguridad deben estar clasificados y priorizados, de forma que estén especificados los tiempos de respuesta para cada uno de los tipos de incidentes.
Ejemplo de clasificación
Un ejemplo de clasificación de los tipos de incidentes puede ser el siguiente:

  • Denegación de servicio. Incidente que deja inoperativo, de forma parcial o total, un sistema o una aplicación.

  • Código malicioso. Incidente que está relacionado con la infección de anfitriones, ya sea por virus, troyanos, gusanos, etc.

  • Acceso no autorizado. Consiste en que una persona no autorizada obtiene acceso, ya sea lógico o físico, a una red, a un sistema o a una aplicación. Se pueden incluir en esta categoría los accesos exitosos o no, robo, alteración o borrado de información y los intentos recurrentes de acceso.

  • Uso inapropiado de los recursos. Consiste en que un usuario hace un uso inadecuado de los recursos informáticos.

  • Múltiples componentes. Engloba los incidentes de seguridad que podrían tener cabida en más de una categoría.

4.4.Priorización

La priorización del incidente es una parte del proceso que no debe tomarse a la ligera. Nunca debería resolverse con una política tipo FIFO (el primero que llega es el que se atiende), y mucho menos si fuera el resultado de una escasez de recursos. La priorización debe seguir estos criterios:

  • Efecto potencial y real del incidente.

  • Criticidad de los recursos afectados.

De modo que se debería dar prioridad al incidente basándose en el impacto estimado por el incidente en la organización.

4.5.Notificación

La notificación es el paso de contactar con las partes necesarias para la resolución del incidente, cuando éste ya ha sido clasificado y priorizado.
Es preciso ponerse en contacto con el origen del aviso para solicitar información adicional y para comunicar el estado o resolución del incidente. Es necesario, por ejemplo, cuando el incidente ha sido notificado por otra organización que ha detectado intentos de ataque a sus sistemas desde nuestra red.
4.5.1.Otras notificaciones
El administrador de sistemas puede no ser la única persona que deba ser informada sobre el incidente. En algunos casos, también puede ser necesario notificar el incidente a los siguientes estamentos:

  • Otros equipos de respuesta a incidentes.

  • Departamento legal (12) .

  • Departamento de comunicación.

También corresponde al equipo de respuesta de incidentes tener identificados los medios que deberán utilizarse en cada situación para el proceso de notificación, por ejemplo el teléfono o el correo electrónico, y debe estar establecido cuándo ha de usarse cada medio.

5.Contención

Etapa de contención. Acciones a realizar
Etapa de contención. Acciones a realizar
La etapa de contención puede llegar a ser muy delicada. El objetivo es contener el incidente para evitar al máximo los posibles efectos dañinos que se puedan derivar.

5.1.Contención de daños y minimización de riesgos

El actuar rápidamente, para reducir los efectos reales y potenciales de un ataque, puede marcar la diferencia entre un ataque de menor o mayor importancia. La respuesta exacta dependerá de la organización y de la naturaleza del ataque al que nos enfrentemos.
5.1.1.Contención
Existen varias medidas que se pueden tomar para contener el daño y minimizar el riesgo en el entorno. Como mínimo, deberían llevarse a cabo las siguientes acciones:

  • Intentar evitar que los atacantes sepan que conocen nuestras actividades. Puede resultar difícil, porque algunas respuestas esenciales pueden alertar a los atacantes.

  • Evaluar la posibilidad, con los costes y consecuencias que conlleva, de dejar sin conexión los sistemas en peligro y los sistemas relacionados con el riesgo de continuar funcionando. En la inmensa mayoría de los casos, debemos desconectar el sistema de la red inmediatamente. No obstante, podríamos tener contratos de servicio en funcionamiento que requieran que los sistemas estén disponibles, incluso con la posibilidad de sufrir daños adicionales.

Daños adicionales
En algunos incidentes, por ejemplo, en una fuga de información confidencial, puede ser interesante retrasar la aplicación de medidas de contención para que la actividad se siga llevando a cabo de forma que sea posible determinar el origen de la fuga de información o para reunir pruebas adicionales durante un ataque en proceso.

  • Determinar los puntos de acceso usados por el atacante e implementar las medidas adecuadas para evitar futuros accesos.

Consejo
Una buena metodología, en el diseño de los planes de contingencia, consiste en separar en función de los tipos de incidentes. Algunos criterios durante el diseño de cada uno de los planes de contingencia, según incidentes, pueden ser:

  • El potencial daño a los recursos de la organización.

  • La posibilidad de fuga de datos de la organización.

  • Disponibilidad del servicio afectado.

  • Tiempos y recursos necesarios para aplicar el plan de contingencia.

  • Efectividad del plan de contingencia (contiene el incidente parcialmente, totalmente, etc.).

  • Duración de la solución (es un workaround, solución temporal, o una solución definitiva).

5.1.2.Minimización de riesgos
Dada la variada casuística de incidentes, esta es una propuesta de prioridades como punto de partida (13) :

  1. Proteger la vida humana y la seguridad de las personas. Por supuesto, esta debe ser siempre la máxima prioridad.

  2. Proteger la información secreta y confidencial. Como parte de nuestro plan de respuesta a incidentes, debemos definir claramente qué información es secreta o confidencial. Esto permitirá establecer prioridades para la protección de datos.

  3. Proteger otra información, como datos científicos, sobre propiedad o del ámbito directivo. Puede que otra información de nuestro entorno también sea valiosa. Debemos proteger, en primer lugar, los datos más valiosos antes de pasar a otros menos útiles.

  4. Proteger el hardware y software contra el ataque. Esto incluye protegerlos contra la pérdida o la modificación de los archivos de sistema y contra daños físicos al hardware. Los daños en los sistemas pueden tener como consecuencia un costoso tiempo de inactividad.

  5. Minimizar la interrupción de los recursos informáticos (incluidos los procesos). Aunque el tiempo de producción sea muy importante en la mayoría de los entornos, el hecho de mantener los sistemas en funcionamiento durante un ataque puede tener como consecuencia problemas más graves en el futuro. Por este motivo, la minimización de la interrupción de los recursos informáticos debe ser una prioridad relativamente baja.

5.2.Protección de las pruebas

En muchos casos, si detectamos que el sistema informático ha sido víctima de un ataque intencionado, probablemente deseemos denunciar o demandar a los autores. Para conservar estas opciones, deberemos reunir pruebas que se puedan usar contra ellos, incluso si al final decidimos no llevar a cabo tales acciones. Es muy importante hacer copias de seguridad de los sistemas en peligro tan pronto como sea posible. Es necesario realizar copias de seguridad de los sistemas antes de realizar cualquier acción que pueda afectar a la integridad de los datos en los medios originales.
En ocasiones, la ventaja de conservar los datos puede que no iguale a los costos de retrasar la respuesta y la recuperación del sistema. Los costos y las ventajas de conservar los datos se deben comparar con los de una recuperación más rápida para cada evento.
Para sistemas muy grandes, puede que no sea posible realizar copias completas de todos los sistemas en peligro. En lugar de esta operación, debemos realizar copias de seguridad de todos los registros y de las partes seleccionadas y violadas del sistema.
Si es posible, también se han de realizar copias de seguridad de los datos de estado del sistema. Pueden pasar meses o años hasta que se celebre un juicio, de modo que es importante tener archivados todos los detalles del incidente para su uso en el futuro.
A menudo, el aspecto legal más difícil de procesar en un crimen informático es reunir pruebas de forma que se adapten a las leyes de presentación de pruebas de la jurisdicción en cuestión. De ahí que el componente más importante del proceso forense sea la documentación detallada y completa sobre cómo se procedió con los sistemas, quién y cómo lo hizo, para aportar pruebas confiables.

5.3.Notificaciones a organismos externos

Después de contener el incidente y reunir los datos necesarios para un posible juicio, debemos plantearnos si es oportuno comunicarlo a los organismos externos adecuados. Toda comunicación externa se debe coordinar con el representante legal. Entre los organismos a los que podemos acudir se encuentran los siguientes: autoridades competentes locales y nacionales, organismos externos de seguridad y expertos en virus. Los organismos externos pueden ofrecer ayuda técnica, una resolución más rápida e información derivada de incidentes similares para ayudarnos a recuperarnos completamente del incidente y evitar que se vuelva a producir en el futuro.
En sectores y tipos de infracciones concretos, quizás tengamos que notificar la situación a los clientes y al público general, especialmente si los clientes pueden verse directamente afectados por el incidente.

6.Resolución del incidente

Etapa de recuperación. Acciones a realizar
Etapa de recuperación. Acciones a realizar
La recuperación es el proceso de:
a) Devolver los sistemas afectados por el incidente a su estado operativo. También contempla la eliminación de los componentes que han provocado el incidente.
b) Mejorar la seguridad para evitar futuros incidentes, al menos, del mismo tipo.

6.1.Recuperación de los sistemas

La forma de recuperar el sistema dependerá, generalmente, del alcance de la infracción de seguridad. Deberá determinar si puede restaurar el sistema existente dejando intacto todo lo posible, o si es necesario volver a crear completamente el sistema.
Para restaurar los datos se asume, por supuesto, que contamos con copias de seguridad limpias, realizadas antes de que ocurriera el incidente. El software de integridad de archivos puede ayudar a señalar el primer daño en aparecer. Si el software nos avisa sobre un archivo modificado, sabremos que la copia de seguridad que hicimos antes de la alerta es adecuada y que debemos conservarla para su uso si el sistema vuelve a estar comprometido (y no dispongamos de una copia de seguridad más reciente).
Un incidente podría dañar los datos almacenados varios meses antes de su descubrimiento. Por lo tanto, es muy importante que, como parte del proceso de respuesta a incidentes, determinemos la duración del incidente (el software de integridad del sistema y archivos, junto con los sistemas de detección de intrusiones, puede ayudarnos en esta tarea). En algunos casos, la última o incluso las últimas copias de seguridad pueden no ser adecuadas para recuperar un estado apropiado, de modo que debemos archivar con regularidad copias de seguridad de los datos en una ubicación externa.

6.2.Recopilación y organización de pruebas del incidente

El equipo de respuesta de incidentes debe documentar, minuciosamente, todos los procesos al tratar con un incidente. Se debe incluir una descripción de la infracción y detalles de cada acción tomada (quién llevó a cabo la acción, cuándo lo hizo y por qué motivos). Se debe avisar a todas las personas implicadas con acceso al sistema durante el proceso de respuesta.
Después, se debe organizar la documentación cronológicamente, comprobar que está completa, y firmarla y revisarla con la directiva y los representantes legales. Asimismo, deberemos proteger las pruebas recopiladas en la fase de protección de pruebas. Tenemos que plantearnos la presencia de dos personas durante todas las fases, que puedan aprobar cada paso. Esto ayudará a reducir la probabilidad de que las pruebas se consideren no admisibles y de que se modifiquen después.
Recordemos que el atacante puede ser un empleado, contratista, empleado temporal u otra persona de la organización. Sin documentación completa y detallada, la identificación de un atacante interno será muy difícil. Una documentación apropiada también nos proporciona la mejor oportunidad de procesar legalmente a los atacantes.

6.3.Valoración de los daños del incidente

Al determinar los daños que sufre la organización, debemos considerar tanto los costos directos como los indirectos. El daño y los costos del incidente constituirán una prueba importante y necesaria si decidimos emprender acciones legales. Entre ellos, se pueden contar los siguientes:

  • Costes debidos a la pérdida de la ventaja competitiva por la divulgación de información confidencial.

  • Costes legales.

  • Costes laborales por el análisis de las infracciones, la reinstalación del software y la recuperación de datos.

  • Costes relacionados con el tiempo de inactividad del sistema.

  • Costes relacionados con la reparación y actualización de las medidas de seguridad físicas.

  • Otros daños derivados (pérdida de la reputación o de la confianza del cliente, etc.).

6.4.Revisión de la respuesta y actualización de las directivas

Una vez que se hayan finalizado las fases de documentación y recuperación, debemos revisar el proceso minuciosamente, determinar qué pasos se siguieron correctamente y qué errores se cometieron. En casi todos los casos, descubriremos que debemos modificar algunos procesos para controlar mejor futuros incidentes.
Encontraremos debilidades en el plan de respuesta a incidentes. Este análisis posterior tiene como finalidad encontrar elementos y procedimientos para mejorar, que iniciarán un nuevo proceso de planificación de la respuesta a incidentes.

Resumen

Hemos visto la importancia de la prevención en todo sistema informático, y que a pesar de ello debemos contar con la existencia, de vez en cuando, de incidentes. Éstos pueden ser o no de índole dolosa (con intención de causar daño y constituir un hecho delictivo) y debemos por tanto estar preparados para ello.
Hemos estudiado los principales tipos de ataques, muchos de los cuales no provienen del exterior de la organización.
De modo que, ante un incidente de seguridad, tenemos que actuar identificándolo y conteniéndolo. Hemos de descubrir cómo ha ocurrido el incidente. La recuperación del sistema se llevará a cabo por medio de una parte del plan de seguridad (conocido como disaster recovery). La otra, muy compleja en sí misma, es la informática forense. No solamente hay que averiguar qué ha motivado el incidente, sino que hay que reunir las evidencias digitales de modo que puedan ser usadas en términos legales si procede.

Actividades

1. Intentad leer algún plan de prevención, de seguridad o de contingencia de alguna organización afín a vosotros. Os dará una visión muy práctica de cómo se estructuran y se organizan. Recordad que se considera información estratégica de la compañía, por lo que es información muy sensible y no debe ser difundida.
2. Buscad por la Red información adicional sobre:

Ejercicios de autoevaluación

1. El ciclo de vida del incidente...

2. Relacionad las acciones en las etapas correspondientes.
1. Copia de seguridad
a) Preparación y prevención
2. Restaurar sistema
b) Preparación y prevención
3. Monitorizar la red
c) Detección y análisis
4. Priorización
d) Detección y análisis
5. Análisis Inicial
e) Contención
6. Valorar daños y costes
f) Detección y análisis
7. Contención
g) Recuperación
8. Clasificación
h) Recuperación

3. ¿Cuáles de estas frases son ciertas y cuáles falsas?

Ejercicios de autoevaluación
1. d
2. 1. a
2. g
3. b
4. c
5. d
6. h
7. e
8. f
3.

  1. Cierto

  2. Falso

  3. Cierto

  4. Falso

  5. Falso



Glosario

activo m
Es cualquier "cosa" que tiene valor para la empresa. Un servidor es un activo, una licencia también lo es. Pero no sólo eso: las personas, los servicios, los procesos, la imagen de la empresa, la marca... todo son activos.
activo (informática) m
Recurso del sistema de información o relacionado con éste, necesario para que la organización funcione correctamente y alcance los objetivos propuestos.
ataque m
Evento, exitoso o no, que atenta sobre el buen funcionamiento del sistema. Consiste en aprovechar una vulnerabilidad de un sistema informático (sistema operativo, programa de software o sistema del usuario) con propósitos desconocidos por el operador del sistema y que, por lo general, causan un daño.
amenaza f
Es aquel elemento que puede provocar daños sobre el activo. Evento que pueden desencadenar un incidente en la organización, produciendo daños materiales o pérdidas inmateriales en sus activos.
entrada
controles o contramedidas m
Medidas dispuestas para rebajar el nivel de riesgo.
degradación f
Es un término que utilizan algunas metodologías para referirse al potencial que tiene la amenaza de dañar al activo.
desastre/contingencia m/f
Interrupción de la capacidad de acceso a información y procesamiento de la misma mediante computadoras necesarias para la operación normal de un negocio.
exposición f
Es la medida de la vulnerabilidad, lo desprotegido que está el sistema.
impacto m
Es un término con significados parcialmente distintos en función de la metodología que se utilice, pero que viene a hacer referencia al resultado de que se produzca el incidente.
incidente m
(1) La materialización efectiva de la amenaza, aprovechando la vulnerabilidad. (2) Cualquier hecho anómalo que afecta al funcionamiento del sistema.
incidente de seguridad informática m
La violación o intento de violación de la política de seguridad.
insiders n
Empleados o personas externas que pueden acceder al sistema informático desde dentro de la organización.
organización f
Cualquier entidad, institución o agrupación que necesite o utilice una infraestructura informática para llevar a cabo su objetivo.
outsiders n
Personas que acceden al sistema informático desde fuera de la organización (con un password válido, por ejemplo).
probabilidad de ocurrencia de la amenaza f
Es la probabilidad de que la amenaza se materialice.
riesgo/nivel de riesgo m
La probabilidad de que una amenaza aproveche la vulnerabilidad del activo para provocar un daño.
valor m
Es la importancia que tiene ese activo dentro de la empresa; no su valor económico. Pongamos un ejemplo sencillo. ¿Cuál es el valor del carnet de conducir? ¿Lo que ha costado conseguirlo (autoescuela, tasas, etc.)? Pues no, depende de la importancia de ese activo para la empresa. Para un autónomo que trabaja entregando paquetes a domicilio, tiene más valor que para otro que trabaja en casa como teleoperador.
vulnerabilidad de un activo f
La potencialidad o posibilidad de ocurrencia de la materialización de una amenaza sobre dicho activo. Se determina por dos medidas: frecuencia de ocurrencia y degradación causada.

Bibliografía

Ashcroft, J.; Daniels, D.; Hart, S. (2004). Forensic Examination of Digital Evidence: A Guide for Law Enforcement U.S. Department of Justice: National Institute of Justice.<https://www.ncjrs.gov/pdffiles1/nij/199408.pdf>
BH Consulting IT Ltd. (2005). Incident Response Best Practice Guide.<https://www.bhconsulting.ie/Incident%20Response%20White%20Paper.pdf>
Colobran Huguet, M.; Arques Soldevila, J.; Marco Galindo, E. (2008). Administració de sistemes operatius en xarxa. Barcelona: Editorial UOC.
Colobran Huguet, M.; Moron Lerma, E. (2004). Introducción a la seguridad informática. Barcelona: Planeta UOC S. L.
Grance, T.; Kent, K.; Kim, B. (2004). Computer Security Incident Handling Guide. U.S. Department of Commerce: Nist, National Institute of Standards and Technology.<https://csrc.nist.gov/publications/nistpubs/800-61/sp800-61.pdf>
IETF. (2002). Guidelines for Evidence Collection and Archiving. (RFC 3227). <https://www.ietf.org/rfc/rfc3227.txt>
Kennedy, G. (2008). Security Incident Handling in Small Organizations. SANS Institute. <https://www.sans.org/reading_room/whitepapers/incident/security_incident_handling_in_small_organizations_32979>
Kent, K.; Chevalier, S.; Grance, T.; Dang, H. (2006). Guideto Integrating Forensic Techniques into Incident Response. U.S. Department of Commerce: Nist, National Institute of Standards and Technology.<https://csrc.nist.gov/publications/nistpubs/800-86/SP800-86.pdf>
Microsoft Technet (2009). Respuesta a incidentes de seguridad de TI.<https://technet.microsoft.com/es-es/library/cc700825.aspx>
Ministerio de Administraciones Públicas (2006). MAGERIT versión 2 Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información. Madrid.<https://www.csi.map.es/csi/pdf/magerit_v2/metodo_v11_final.pdf>
Scientific Working Group on Digital Evidence (2006). Best Practices for Computer Forensics.<https://www.swgde.org/documents/swgde2006/Best_Practices_for_Computer_Forensics%20July06.pdf>
Shinder, D. (2002). Prevención y detección de delitos informáticos. Madrid: Anaya.
U. S. Department of Justice. Federal Bureu of Investigation. Laboratory Division (2007). Handbook of Forensic Services E.E.U.U<https://www.fbi.gov/hq/lab/handbook/forensics.pdf>
Valeri, L.; Somers, G.; Robinson, N.; Graux, H.; Dumortier, J (2006). Handbook of Legal Procedures of Computer and Network Misuse in EU Countries. Bruselas: European Commission.<https://www.rand.org/pubs/technical_reports/2006/RAND_TR337.pdf>
West-Brown, M.; Stikvoort, D.; Kossakowski, K.; Killcrece, G.; Ruefle, R.; Zajicek, M. (2003). Handbook for Computer Security Incident Response Teams (CSIRTs). U.S. Carnegie Mellon University.<https://www.cert.org/archive/pdf/csirt-handbook.pdf>