Seguridad en Unix y Redes
Libro en Formato HTML y PDF de seguridad informática realizado por Antonio Villalon Huerta

Los contenidos pueden estar desactualizados con respecto al original

Este documento se encuentra disponible también en formato PDF

Gestión de la seguridad

next up previous contents
Siguiente: Apéndices Subir: Otros aspectos de la Anterior: Algunas herramientas de seguridad   Índice General

Subsecciones

Gestión de la seguridad

Introducción

La gestión de la seguridad de una organización puede ser - y en muchos casos es - algo infinitamente complejo, no tanto desde un punto de vista puramente técnico sino más bien desde un punto de vista organizativo; no tenemos más que pensar en una gran universidad o empresa con un número elevado de departamentos o áreas: si alguien que pertenece a uno de ellos abandona la organización, eliminar su acceso a un cierto sistema no implica ningún problema técnico (el administrador sólo ha de borrar o bloquear al usuario, algo inmediato), pero sí graves problemas organizativos: para empezar, >cómo se entera un administrador de sistemas que un cierto usuario, que no trabaja directamente junto a él, abandona la empresa? >quién decide si al usuario se le elimina directamente o se le permite el acceso a su correo durante un mes? >puede el personal del área de seguridad decidir bloquear el acceso a alguien de cierto `rango' en la organización, como un directivo o un director de departamento, nada más que este abandone la misma? >y si resulta que es amigo del director general o el rector, y luego este se enfada? Como vemos, desde un punto de vista técnico no existe ningún escollo insalvable, pero sí que existen desde un punto de vista de la gestión de la seguridad...

Hoy en día, una entidad que trabaje con cualquier tipo de entorno informático, desde pequeñas empresas con negocios no relacionados directamente con las nuevas tecnologías hasta grandes telcos de ámbito internacional, está - o debería estar - preocupada por su seguridad. Y no es para menos: el número de amenazas a los entornos informáticos y de comunicaciones crece casi exponencialmente año tras año, alcanzando cotas inimaginables hace apenas una década. Y con que el futuro de la interconexión de sistemas sea tan solo la mitad de prometedor de lo que nos tratan de hacer creer, es previsible que la preocupación por la seguridad vaya en aumento conforme nuestras vidas estén más y más `conectadas' a Internet.

Hasta hace poco esta preocupación de la que estamos hablando se centraba sobre todo en los aspectos más técnicos de la seguridad: alguien convencía a algún responsable técnico que con la implantación de un cortafuegos corporativo se acabarían todos los problemas de la organización, y por supuesto se elegía el más caro aunque después nadie supiera implantar en él una política correcta; poco después, y en vista de que el firewall no era la panacea, otro comercial avispado convencía a la dirección que lo que realmente estaba de moda son los sistemas de detección de intrusos, y por supuesto se `dejaba caer' un producto de este tipo en la red (se `dejaba caer', no se `implantaba'). En la actualidad, como las siglas están tan de moda, lo que se lleva son las PKIs, que aunque nadie sepa muy bien como calzarlas en el entorno de operaciones, quedan de maravilla sobre las slides23.1 de las presentaciones comerciales de turno.

Por fortuna, las cosas han empezado a cambiar (y digo `por fortuna' a pesar de ser una persona más técnica que organizativa); hoy en día la seguridad va más allá de lo que pueda ser un cortafuegos, un sistema de autenticación biométrico o una red de sensores de detección de intrusos: ya se contemplan aspectos que hasta hace poco se reservaban a entornos altamente cerrados, como bancos u organizaciones militares. Y es que nos hemos empezado a dar cuenta de que tan importante o más como un buen firewall es un plan de continuidad del negocio en caso de catástrofe - especial y desgraciadamente desde el pasado 11 de septiembre -, y que sin una política de seguridad correctamente implantada en nuestra organización no sirven de nada los controles de acceso (físicos y lógicos) a la misma. Se habla ahora de la gestión de la seguridad como algo crítico para cualquier organización, igual de importante dentro de la misma que los sistemas de calidad o las líneas de producto que desarrolla.

Algo que sin duda ha contribuido a todo esto es la aparición - más o menos reciente - de normativas y estándares de seguridad, de ámbito tanto nacional como internacional, y sobre todo su aplicación efectiva; no tenemos más que mirar la Ley Orgánica de Protección de Datos de Carácter Personal en España: desde que la Agencia de Protección de Datos impone sanciones millonarias a quienes incumplen sus exigencias, todo el mundo se preocupa de la correcta gestión de su seguridad. También han sido importantes la transformación del British Standard 7799 en una norma ISO (17799) a la que referirse a la hora de hablar de la definición de políticas dentro de una organización, y la definición del informe UNE 71501 IN como requisito para proteger y gestionar la seguridad de los sistemas de información dentro de las organizaciones.

Hasta tal punto se ha popularizado el mundo de la seguridad que surgen empresas `especializadas' hasta de debajo de las piedras, y por supuesto todas cuentan con los mejores expertos, consultores e ingenieros de seguridad (títulos que, al menos que yo sepa, no otorga ninguna universidad española); la paranoia se lleva al límite cuando se ofrecen certificaciones comerciales de seguridad del tipo `Certificado X en Seguridad' o `Ingeniero de Seguridad X'. Por supuesto, aunque en el mercado de la seguridad hay excelentes profesionales, la lógica nos debe llevar a desconfiar de este tipo de publicidad, pero sin llegar al extremo de descuidar nuestra seguridad por no confiar en nadie: como veremos, la seguridad gestionada es en muchas ocasiones una excelente solución.

En definitiva, en este capítulo vamos a intentar hablar de aspectos relacionados con la gestión de la seguridad corporativa - entendiendo por `corporativa' la aplicable a una determinada organización, bien sea una empresa bien sea una universidad -. Comentaremos desde aspectos relacionados con la definición de políticas o los análisis de riesgos hasta el papel del área de Seguridad de una organización, incluyendo aproximaciones a la seguridad gestionada. Como siempre, existe numerosa bibliografía sobre el tema que es imprescindible consultar si queremos definir y gestionar de forma adecuada la seguridad de nuestra organización; especialmente recomendables son [Sta00], [H$^+$02] y [GB97].

Políticas de seguridad

El término política de seguridad se suele definir como el conjunto de requisitos definidos por los responsables directos o indirectos de un sistema que indica en términos generales qué está y qué no está permitido en el área de seguridad durante la operación general de dicho sistema ([Org88]). Al tratarse de `términos generales', aplicables a situaciones o recursos muy diversos, suele ser necesario refinar los requisitos de la política para convertirlos en indicaciones precisas de qué es lo permitido y lo denegado en cierta parte de la operación del sistema, lo que se denomina política de aplicación específica ([MPS$^+$93]).

Una política de seguridad puede ser prohibitiva, si todo lo que no está expresamente permitido está denegado, o permisiva, si todo lo que no está expresamente prohibido está permitido. Evidentemente la primera aproximación es mucho mejor que la segunda de cara a mantener la seguridad de un sistema; en este caso la política contemplaría todas las actividades que se pueden realizar en los sistemas, y el resto - las no contempladas - serían consideradas ilegales.

Cualquier política ha de contemplar seis elementos claves en la seguridad de un sistema informático ([Par94]):
  • Disponibilidad
    Es necesario garantizar que los recursos del sistema se encontrarán disponibles cuando se necesitan, especialmente la información crítica.
  • Utilidad
    Los recursos del sistema y la información manejada en el mismo ha de ser útil para alguna función.
  • Integridad
    La información del sistema ha de estar disponible tal y como se almacenó por un agente autorizado.
  • Autenticidad
    El sistema ha de ser capaz de verificar la identidad de sus usuarios, y los usuarios la del sistema.
  • Confidencialidad
    La información sólo ha de estar disponible para agentes autorizados, especialmente su propietario.
  • Posesión
    Los propietarios de un sistema han de ser capaces de controlarlo en todo momento; perder este control en favor de un usuario malicioso compromete la seguridad del sistema hacia el resto de usuarios.
Para cubrir de forma adecuada los seis elementos anteriores, con el objetivo permanente de garantizar la seguridad corporativa, una política se suele dividir en puntos más concretos a veces llamados normativas (aunque las definiciones concretas de cada documento que conforma la infraestructura de nuestra política de seguridad - política, normativa, estándar, procedimiento operativo...- es algo en lo que ni los propios expertos se ponen de acuerdo). El estándar ISO 17799 ([Sta00]) define las siguientes líneas de actuación:
  • Seguridad organizacional.
    Aspectos relativos a la gestión de la seguridad dentro de la organización (cooperación con elementos externos, outsourcing, estructura del área de seguridad...).
  • Clasificación y control de activos.
    Inventario de activos y definición de sus mecanismos de control, así como etiquetado y clasificación de la información corporativa.
  • Seguridad del personal.
    Formación en materias de seguridad, clausulas de confidencialidad, reporte de incidentes, monitorización de personal...
  • Seguridad física y del entorno.
    Bajo este punto se engloban aspectos relativos a la seguridad física de los recintos donde se encuentran los diferentes recursos - incluyendo los humanos - de la organización y de los sistemas en sí, así como la definición de controles genéricos de seguridad.
  • Gestión de comunicaciones y operaciones.
    Este es uno de los puntos más interesantes desde un punto de vista estrictamente técnico, ya que engloba aspectos de la seguridad relativos a la operación de los sistemas y telecomunicaciones, como los controles de red, la protección frente a malware, la gestión de copias de seguridad o el intercambio de software dentro de la organización.
  • Controles de acceso.
    Definición y gestión de puntos de control de acceso a los recursos informáticos de la organización: contraseñas, seguridad perimetral, monitorización de accesos...
  • Desarrollo y mantenimiento de sistemas.
    Seguridad en el desarrollo y las aplicaciones, cifrado de datos, control de software...
  • Gestión de continuidad de negocio.
    Definición de planes de continuidad, análisis de impacto, simulacros de catástrofes...
  • Requisitos legales.
    Evidentemente, una política ha de cumplir con la normativa vigente en el país donde se aplica; si una organización se extiende a lo largo de diferentes paises, su política tiene que ser coherente con la normativa del más restrictivo de ellos. En este apartado de la políica se establecen las relaciones con cada ley: derechos de propiedad intelectual, tratamiento de datos de carácter personal, exportación de cifrado... junto a todos los aspectos relacionados con registros de eventos en los recursos (logs) y su mantenimiento.

Análisis de riesgos

En un entorno informático existen una serie de recursos (humanos, técnicos, de infraestructura...) que están expuestos a diferentes tipos de riesgos: los `normales', aquellos comunes a cualquier entorno, y los excepcionales, originados por situaciones concretas que afectan o pueden afectar a parte de una organización o a toda la misma, como la inestabilidad política en un país o una región sensible a terremotos ([Pla83]). Para tratar de minimizar los efectos de un problema de seguridad se realiza lo que denominamos un análisis de riesgos, término que hace referencia al proceso necesario para responder a tres cuestiones básicas sobre nuestra seguridad:
  • >qué queremos proteger?
  • >contra quién o qué lo queremos proteger?
  • >cómo lo queremos proteger?
En la práctica existen dos aproximaciones para responder a estas cuestiones, una cuantitativa y otra cualitativa. La primera de ellas es con diferencia la menos usada, ya que en muchos casos implica cálculos complejos o datos difíciles de estimar. Se basa en dos parámetros fundamentales: la probabilidad de que un suceso ocurra y una estimación del coste o las pérdidas en caso de que así sea; el producto de ambos términos es lo que se denomina coste anual estimado (EAC, Estimated Annual Cost), y aunque teóricamente es posible conocer el riesgo de cualquier evento (el EAC) y tomar decisiones en función de estos datos, en la práctica la inexactitud en la estimación o en el cálculo de parámetros hace difícil y poco realista esta aproximación.

El segundo método de análisis de riesgos es el cualitativo, de uso muy difundido en la actualidad especialmente entre las nuevas `consultoras' de seguridad (aquellas más especializadas en seguridad lógica, cortafuegos, tests de penetración y similares). Es mucho más sencillo e intuitivo que el anterior, ya que ahora no entran en juego probabilidades exactas sino simplemente una estimación de pérdidas potenciales. Para ello se interrelacionan cuatro elementos principales: las amenazas, por definición siempre presentes en cualquier sistema, las vulnerabilidades, que potencian el efecto de las amenazas, el impacto asociado a una amenaza, que indica los daños sobre un activo por la materialización de dicha amenaza, y los controles o salvaguardas, contramedidas para minimizar las vulnerabilidades (controles preventivos) o el impacto (controles curativos). Por ejemplo, una amenaza sería un pirata que queramos o no (no depende de nosotros) va a tratar de modificar nuestra página web principal, el impacto sería una medida del daño que causaría si lo lograra, una vulnerabilidad sería una configuración incorrecta del servidor que ofrece las páginas, y un control la reconfiguración de dicho servidor o el incremento de su nivel de parcheado. Con estos cuatro elementos podemos obtener un indicador cualitativo del nivel de riesgo asociado a un activo determinado dentro de la organización, visto como la probabilidad de que una amenaza se materialice sobre un activo y produzca un determinado impacto.

En España es interesante la metodología de análisis de riesgos desarrollada desde el Consejo Superior de Informática (Ministerio de Administraciones Públicas) y denominada MAGERIT (Metodología de Análisis y GEstión de Riesgos de los sistemas de Información de las AdminisTraciones públicas); se trata de un método formal para realizar un análisis de riesgos y recomendar los controles necesarios para su minimización. MAGERIT se basa en una aproximación cualitativa que intenta cubrir un amplio espectro de usuarios genéricos gracias a un enfoque orientado a la adaptación del mecanismo dentro de diferentes entornos, generalmente con necesidades de seguridad y nivel de sensibilidad también diferentes. En la página web del Consejo Superior de Informática23.2 podemos encontrar información más detallada acerca de esta metodología, así como algunos ejemplos de ejecución de la misma.

Tras obtener mediante cualquier mecanismo los indicadores de riesgo en nuestra organización llega la hora de evaluarlos para tomar decisiones organizativas acerca de la gestión de nuestra seguridad y sus prioridades. Tenemos por una parte el riesgo calculado, resultante de nuestro análisis, y este riesgo calculado se ha de comparar con un cierto umbral (umbral de riesgo) determinado por la política de seguridad de nuestra organización; el umbral de riesgo puede ser o bien un número o bien una etiqueta de riesgo (por ejemplo, nivel de amenaza alto, impacto alto, vulnerabilidad grave, etc.), y cualquier riesgo calculado superior al umbral ha de implicar una decisión de reducción de riesgo. Si por el contrario el calculado es menor que el umbral, se habla de riesgo residual, y el mismo se considera asumible (no hay porqué tomar medidas para reducirlo). El concepto de asumible es diferente al de riesgo asumido, que denota aquellos riesgos calculados superiores al umbral pero sobre los que por cualquier razón (política, económica...) se decide no tomar medidas de reducción; evidentemente, siempre hemos de huir de esta situación.

Una vez conocidos y evaluados de cualquier forma los riesgos a los que nos enfrentamos podremos definir las políticas e implementar las soluciones prácticas - los mecanismos - para minimizar sus efectos. Vamos a intentar de entrar con más detalle en cómo dar respuesta a cada una de las preguntas que nos hemos planteado al principio de este punto:

Identificación de recursos

Debemos identificar todos los recursos cuya integridad pueda ser amenazada de cualquier forma; por ejemplo, [C$^+$91] define básicamente los siguientes:
  • Hardware
    Procesadores, tarjetas, teclados, terminales, estaciones de trabajo, ordenadores personales, impresoras, unidades de disco, líneas de comunicación, servidores, routers...
  • Software
    Códigos fuente y objeto, utilidades, programas de diagnóstico, sistemas operativos, programas de comunicación...
  • Información
    En ejecución, almacenados en línea, almacenados fuera de línea, en comunicación, bases de datos...
  • Personas
    Usuarios, operadores...
  • Accesorios
    Papel, cintas, tóners...
Aparte del recurso en sí (algo tangible, como un router) hemos de considerar la visión intangible de cada uno de estos recursos (por ejemplo la capacidad para seguir trabajando sin ese router). Es difícil generar estos aspectos intangibles de los recursos, ya que es algo que va a depender de cada organización, su funcionamiento, sus seguros, sus normas...No obstante, siempre hemos de tener en cuenta algunos aspectos comunes: privacidad de los usuarios, imagen pública de la organización, reputación, satisfacción del personal y de los clientes - en el caso de una universidad, de los alumnos -, capacidad de procesamiento ante un fallo...

Con los recursos correctamente identificados se ha de generar una lista final, que ya incluirá todo lo que necesitamos proteger en nuestra organización.

Identificación de amenazas

Una vez conocemos los recursos que debemos proteger es la hora de identificar las vulnerabilidades y amenazas que se ciernen contra ellos. Una vulnerabilidad es cualquier situación que pueda desembocar en un problema de seguridad, y una amenaza es la acción específica que aprovecha una vulnerabilidad para crear un problema de seguridad; entre ambas existe una estrecha relación: sin vulnerabilidades no hay amenazas, y sin amenazas no hay vulnerabilidades.

Se suelen dividir las amenazas que existen sobre los sistemas informáticos en tres grandes grupos, en función del ámbito o la forma en que se pueden producir:
  • Desastres del entorno.
    Dentro de este grupo se incluyen todos los posibles problemas relacionados con la ubicación del entorno de trabajo informático o de la propia organización, así como con las personas que de una u otra forma están relacionadas con el mismo. Por ejemplo, se han de tener en cuenta desastres naturales (terremotos, inundaciones...), desastres producidos por elementos cercanos, como los cortes de fluido eléctrico, y peligros relacionados con operadores, programadores o usuarios del sistema.
  • Amenazas en el sistema.
    Bajo esta denominación se contemplan todas las vulnerabilidades de los equipos y su software que pueden acarrear amenazas a la seguridad, como fallos en el sistema operativo, medidas de protección que éste ofrece, fallos en los programas, copias de seguridad...
  • Amenazas en la red.
    Cada día es menos común que una máquina trabaje aislada de todas las demás; se tiende a comunicar equipos mediante redes locales, intranets o la propia Internet, y esta interconexión acarrea nuevas - y peligrosas - amenazas a la seguridad de los equipos, peligros que hasta el momento de la conexión no se suelen tener en cuenta. Por ejemplo, es necesario analizar aspectos relativos al cifrado de los datos en tránsito por la red, a proteger una red local del resto de internet, o a instalar sistemas de autenticación de usuarios remotos que necesitan acceder a ciertos recursos internos a la organización (como un investigador que conecta desde su casa a través de un módem).
Algo importante a la hora de analizar las amenazas a las que se enfrentan nuestros sistemas es analizar los potenciales tipos de atacantes que pueden intentar violar nuestra seguridad. Es algo normal que a la hora de hablar de atacantes todo el mundo piense en crackers, en piratas informáticos mal llamados hackers. No obstante, esto no es más que el fruto de la repercusión que en todos los medios tienen estos individuos y sus acciones; en realidad, la inmensa mayoría de problemas de seguridad vienen dados por atacantes internos a la organización afectada. En organismos de I+D estos atacantes suelen ser los propios estudiantes (rara vez el personal), así como piratas externos a la entidad que aprovechan la habitualmente mala protección de los sistemas universitarios para acceder a ellos y conseguir así cierto status social dentro de un grupo de piratas. Los conocimientos de estas personas en materias de sistemas operativos, redes o seguridad informática suelen ser muy limitados, y sus actividades no suelen entrañar muchos riesgos a no ser que se utilicen nuestros equipos para atacar a otras organizaciones, en cuyo caso a los posibles problemas legales hay que sumar la mala imagen que nuestras organizaciones adquieren.

No siempre hemos de contemplar a las amenazas como actos intencionados contra nuestro sistema: muchos de los problemas pueden ser ocasionados por accidentes, desde un operador que derrama una taza de café sobre una terminal hasta un usuario que tropieza con el cable de alimentación de un servidor y lo desconecta de la línea eléctrica, pasando por temas como el borrado accidental de datos o los errores de programación; decir `no lo hice a propósito' no ayuda nada en estos casos. Por supuesto, tampoco tenemos que reducirnos a los accesos no autorizados al sistema: un usuario de nuestras máquinas puede intentar conseguir privilegios que no le corresponden, una persona externa a la organización puede lanzar un ataque de negación de servicio contra la misma sin necesidad de conocer ni siquiera un login y una contraseña, etc.

Medidas de protección

Tras identificar todos los recursos que deseamos proteger, así como las posibles vulnerabilidades y amenazas a que nos exponemos y los potenciales atacantes que pueden intentar violar nuestra seguridad, hemos de estudiar cómo proteger nuestros sistemas, sin ofrecer aún implementaciones concretas para protegerlos (esto ya no serían políticas sino mecanismos). Esto implica en primer lugar cuantificar los daños que cada posible vulnerabilidad puede causar teniendo en cuenta las posibilidades de que una amenaza se pueda convertir en realidad. Este cálculo puede realizarse partiendo de hechos sucedidos con anterioridad en nuestra organización, aunque por desgracia en muchos lugares no se suelen registrar los incidentes acaecidos. En este caso, y también a la hora de evaluar los daños sobre recursos intangibles, existen diversas aproximaciones como el método Delphi, que básicamente consiste en preguntar a una serie de especialistas de la organización sobre el daño y las pérdidas que cierto problema puede causar; no obstante, la experiencia del administrador en materias de seguridad suele tener aquí la última palabra a la hora de evaluar los impactos de cada amenaza.

La clasificación de riesgos de cara a estudiar medidas de protección suele realizarse en base al nivel de importancia del daño causado y a la probabilidad aproximada de que ese daño se convierta en realidad; se trata principalmente de no gastar más dinero en una implementación para proteger un recurso de lo que vale dicho recurso o de lo que nos costaría recuperarnos de un daño en él o de su pérdida total. Por ejemplo, podemos seguir un análisis similar en algunos aspectos al problema de la mochila: llamamos al riesgo de perder un recurso i (a la probabilidad de que se produzca un ataque), y le asignamos un valor de 0 a 10 (valores más altos implican más probabilidad); de la misma forma, definimos también de 0 a 10 la importancia de cada recurso, , siendo 10 la importancia más alta. La evaluación del riesgo es entonces el producto de ambos valores, llamado peso o riesgo evaluado de un recurso, , y medido en dinero perdido por unidad de tiempo (generalmente, por año):
De esta forma podemos utilizar hojas de trabajo en las que, para cada recurso, se muestre su nombre y el número asignado, así como los tres valores anteriores. Evidentemente, los recursos que presenten un riesgo evaluado mayor serán los que más medidas de protección deben poseer, ya que esto significa que es probable que sean atacados, y que además el ataque puede causar pérdidas importantes. Es especialmente importante un grupo de riesgos denominados inaceptables, aquellos cuyo peso supera un cierto umbral; se trata de problemas que no nos podemos permitir en nuestros sistemas, por lo que su prevención es crucial para que todo funcione correctamente.

Una vez que conocemos el riesgo evaluado de cada recurso es necesario efectuar lo que se llama el análisis de costes y beneficios. Básicamente consiste en comparar el coste asociado a cada problema (calculado anteriormente, ) con el coste de prevenir dicho problema. El cálculo de este último no suele ser complejo si conocemos las posibles medidas de prevención que tenemos a nuestra disposición: por ejemplo, para saber lo que nos cuesta prevenir los efectos de un incendio en la sala de operaciones, no tenemos más que consultar los precios de sistemas de extinción de fuego, o para saber lo que nos cuesta proteger nuestra red sólo hemos de ver los precios de productos como routers que bloqueen paquetes o cortafuegos completos. No sólo hemos de tener en cuenta el coste de cierta protección, sino también lo que nos puede suponer su implementación y su mantenimiento; en muchos casos existen soluciones gratuitas para prevenir ciertas amenazas, pero estas soluciones tienen un coste asociado relativo a la dificultad de hacerlas funcionar correctamente de una forma contínua en el tiempo, por ejemplo dedicando a un empleado a su implementación y mantenimiento.

Cuando ya hemos realizado este análisis no tenemos más que presentar nuestras cuentas a los responsables de la organización (o adecuarlas al presupuesto que un departamento destina a materias de seguridad), siempre teniendo en cuenta que el gasto de proteger un recurso ante una amenaza ha de ser inferior al gasto que se produciría si la amenaza se convirtiera en realidad. Hemos de tener siempre presente que los riesgos se pueden minimizar, pero nunca eliminarlos completamente, por lo que será recomendable planificar no sólo la prevención ante de un problema sino también la recuperación si el mismo se produce; se suele hablar de medidas proactivas (aquellas que se toman para prevenir un problema) y medidas reactivas (aquellas que se toman cuando el daño se produce, para minimizar sus efectos).

Estrategias de respuesta

>Qué hacer cuando nuestra política de seguridad ha sido violada? La respuesta a esta pregunta depende completamente del tipo de violación que se haya producido, de su gravedad, de quién la haya provocado, de su intención...Si se trata de accidentes o de problemas poco importantes suele ser suficiente con una reprimenda verbal o una advertencia; si ha sido un hecho provocado, quizás es conveniente emprender acciones algo más convincentes, como la clausura de las cuentas de forma temporal o pequeñas sanciones administrativas. En el caso de problemas graves que hayan sido intencionados interesará emprender acciones más duras, como cargos legales o sanciones administrativas firmes (por ejemplo, la expulsión de una universidad).

Una gran limitación que nos va a afectar mucho es la situación de la persona o personas causantes de la violación con respecto a la organización que la ha sufrido. En estos casos se suele diferenciar entre usuarios internos o locales, que son aquellos pertenecientes a la propia organización, y externos, los que no están relacionados directamente con la misma; las diferencias entre ellos son los límites de red, los administrativos, los legales o los políticos. Evidentemente es mucho más fácil buscar responsabilidades ante una violación de la seguridad entre los usuarios internos, ya sea contra la propia organización o contra otra, pero utilizando los recursos de la nuestra; cuando estos casos se dan en redes de I+D, generalmente ni siquiera es necesario llevar el caso ante la justicia, basta con la aplicación de ciertas normas sobre el usuario problemático (desde una sanción hasta la expulsión o despido de la organización).

Existen dos estrategias de respuesta ante un incidente de seguridad ([SH95]):
  • Proteger y proceder.
  • Perseguir y procesar.
La primera de estas estrategias, proteger y proceder, se suele aplicar cuando la organización es muy vulnerable o el nivel de los atacantes es elevado; la filosofía es proteger de manera inmediata la red y los sistemas y restaurar su estado normal, de forma que los usuarios puedan seguir trabajando normalmente. Seguramente será necesario interferir de forma activa las acciones del intruso para evitar más accesos, y analizar el daño causado. La principal desventaja de esta estrategia es que el atacante se da cuenta rápidamente de que ha sido descubierto, y puede emprender acciones para ser identificado, lo que incluso conduce al borrado de logs o de sistemas de ficheros completos; incluso puede cambiar su estrategia de ataque a un nuevo método, y seguir comprometiendo al sistema. Sin embargo, esta estrategia también presenta una parte positiva: el bajo nivel de conocimientos de los atacantes en sistemas habituales hace que en muchas ocasiones se limiten a abandonar su ataque y dedicarse a probar suerte con otros sistemas menos protegidos en otras organizaciones.

La segunda estrategia de respuesta, perseguir y procesar, adopta la filosofía de permitir al atacante proseguir sus actividades, pero de forma controlada y observada por los administradores, de la forma más discreta posible. Con esto, se intentan guardar pruebas para ser utilizadas en la segunda parte de la estrategia, la de acusación y procesamiento del atacante (ya sea ante la justicia o ante los responsables de la organización, si se trata de usuarios internos). Evidentemente corremos el peligro de que el intruso descubra su monitorización y destruya completamente el sistema, así como que nuestros resultados no se tengan en cuenta ante un tribunal debido a las artimañas legales que algunos abogados aprovechan; la parte positiva de esta estrategia es, aparte de la recolección de pruebas, que permite a los responsables conocer las actividades del atacante, qué vulnerabilidades de nuestra organización ha aprovechado para atacarla, cómo se comporta una vez dentro, etc. De esta forma podemos aprovechar el ataque para reforzar los puntos débiles de nuestros sistemas.

A nadie se le escapan los enormes peligros que entraña el permitir a un atacante proseguir con sus actividades dentro de las máquinas; por muy controladas que estén, en cualquier momento casi nada puede evitar que la persona se sienta vigilada, se ponga nerviosa y destruya completamente nuestros datos. Una forma de monitorizar sus actividades sin comprometer excesivamente nuestra integridad es mediante un proceso denominado jailing o encarcelamiento: la idea es construir un sistema que simule al real, pero donde no se encuentren datos importantes, y que permita observar al atacante sin poner en peligro los sistemas reales. Para ello se utiliza una máquina, denominada sistema de sacrificio, que es donde el atacante realmente trabaja, y un segundo sistema, denominado de observación, conectado al anterior y que permite analizar todo lo que esa persona está llevando a cabo. De esta forma conseguimos que el atacante piense que su intrusión ha tenido éxito y continue con ella mientras lo monitorizamos y recopilamos pruebas para presentar en una posible demanda o acusación. Si deseamos construir una cárcel es necesario que dispongamos de unos conocimientos medios o elevados de programación de sistemas; utilidades como chroot() nos pueden ser de gran ayuda, así como software de simulación como Deception Tookit (DTK), que simula el éxito de un ataque ante el pirata que lo lanza, pero que realmente nos está informa del intento de violación producido.

Sin importar la estrategia adoptada ante un ataque, siempre es recomendable ponerse en contacto con entidades externas a nuestra organización, incluyendo por ejemplo fuerzas de seguridad (en España, Guardia Civil o Policía Nacional), gabinetes jurídicos o equipos de expertos en seguridad informática, como el CERT. En el caso de instituciones de I+D, en España existe IrisCERT (http://www.rediris.es/cert/), el equipo de respuesta ante emergencias de seguridad de RedIRIS, la red universitaria española.

Outsourcing

Cada vez es más habitual que las empresas contraten los servicios de seguridad de una compañía externa, especializada en la materia, y que permita olvidarse - relativamente, como veremos después - al personal de esa empresa de los aspectos técnicos y organizativos de la seguridad, para poder centrarse así en su línea de negocio correspondiente; esta política es lo que se conoce como outsourcing y se intenta traducir por `externalización', aplicado en nuestro caso a la seguridad corporativa. A los que somos puramente técnicos muchas veces se nos olvida que la seguridad en sí misma no es ningún fin, sino una herramienta al servicio de los negocios, y por tanto nuestros esfuerzos han de ir orientados a proteger el `patrimonio' (humano, tecnológico, económico...) de quien contrata nuestros servicios: al director de una gran firma probablemente le importe muy poco que hayamos implantado en sus instalaciones el mejor cortafuegos del mercado junto a un fabuloso sistema distribuido de detección de intrusos si después un atacante puede entrar con toda facilidad en la sala de máquinas y robar varias cintas de backup con toda la información crítica de esa compañía; y si esto sucede, simplemente hemos hecho mal nuestro trabajo.

>Por qué va a querer una empresa determinada que personas ajenas a la misma gestionen su seguridad? Al fin y al cabo, estamos hablando de la protección de muchos activos de la compañía, y encomendar esa tarea tan crítica a un tercero, de quien en principio - ni en final - no tenemos porqué confiar, no parece a primera vista una buena idea...Existen diferentes motivos para llegar a externalizar nuestra seguridad; por un lado, como hemos comentado, un outsourcing permite a la empresa que lo contrata despreocuparse relativamente de su seguridad para centrarse en sus líneas de negocio. Además, al contratar a personal especializado - al menos en principio - en la seguridad se consigue - también en principio - un nivel mayor de protección, tanto por el factor humano (el contratado ha de tener gente con un alto nivel en diferentes materias de seguridad para poder ofrecer correctamente sus servicios) como técnico (dispondrá también de productos y sistemas más específicos, algo de lo que probablemente el contratante no puede disponer tan fácilmente). Teóricamente, estamos reduciendo riesgos a la vez que reducimos costes, por lo que parece que nos encontramos ante la panacea de la seguridad.

Desgraciadamente, el mundo real no es tan bonito como lo se puede escribir sobre un papel; el outsourcing presenta a priori graves inconvenientes, y quizás el más importante sea el que ya hemos adelantado: dejar toda nuestra seguridad en manos de desconocidos, por muy buenas referencias que podamos tener de ellos. Muchas empresas dedicadas a ofrecer servicios de gestión externa de seguridad están formadas por ex-piratas (<incluso existen algunas de ellas que se jactan de esto!), lo cual no deja de ser contradictorio: estamos dejando al cuidado de nuestro rebaño a lobos, o cuanto menos ex-lobos, algo que plantea, o debe plantear, ciertas cuestiones éticas. No voy a expresar de nuevo mi punto de vista (que no deja de ser una mera opinión) acerca de los piratas, porque creo que ya ha quedado suficientemente claro en diferentes puntos de este documento, así que cada cual actúe como su conciencia o sus directivos le indiquen. Por supuesto, tampoco quiero meter a todo este tipo de compañías en un mismo saco, porque por lógica habrá de todo, ni entrar ahora a discutir acerca de si para saber defender un entorno hay que saber atacarlo, porque una cosa es saber atacar (algo que se puede aprender en sistemas autorizados, o en nuestro propio laboratorio, sin afectar a ningún tercero) y otra defender que sólo un antiguo pirata es capaz de proteger correctamente un sistema.

Aparte de este `ligero' inconveniente del outsourcing, tenemos otros tipos de problemas a tener también en cuenta; uno de ellos es justamente el límite de uno de los beneficios de esta política: ya que la externalización permite a una empresa `despreocuparse' de su seguridad, podemos encontrar el caso - nada extraño - de un excesivo `despreocupamiento'. Actualmente, el abanico de servicios que ofrece cualquier consultora de seguridad suele abarcar desde auditorías puntuales hasta una delegación total del servicio pasando por todo tipo de soluciones intermedias, y lo que justifica la elección de un modelo u otro es un simple análisis de riesgos: el riesgo de la solución externalizada ha de ser menor que el nivel de riesgo existente si se gestiona la seguridad de forma interna. En cualquier caso, al externalizar se suele introducir una cierta pérdida de control directo sobre algunos recursos de la compañía, y cuando esa pérdida supera un umbral nos encontramos ante un grave problema; en ningún caso es recomendable un desentendimiento total de los servicios externalizados, y el contacto e intercambio de información entre las dos organizaciones (la contratante y la contratada) han de ser contínuos y fluidos.

Cuanto más alejada de las nuevas tecnologías se encuentre la línea de negocio de una determinada empresa, más recomendable suele ser para la misma adoptar una solución de outsourcing ([LU02]); esto es evidente: una empresa frutera, independientemente de lo grande o pequeña que sea, pero perteneciente a un área no relacionada con nuevas tecnologías, rara vez va a disponer de los mismos recursos humanos y técnicos para destinar exclusivamente a seguridad que una empresa de telecomunicaciones o informática. Es habitual - y así debe ser - que el nivel de externalización sea mayor conforme la empresa contratante se aleje del mundo de las nuevas tecnologías, contemplando un amplio abanico que abarca desde la gestión de elementos concretos de protección (como un firewall corporativo) o auditorías y tests de penetración puntuales hasta soluciones de externalización total; en cualquier caso, es necesario insistir de nuevo en el error de `despreocuparse' demasiado de la gestión de nuestra seguridad: incluso a esa empresa frutera que acabamos de comentar le interesará, o al menos así debería ser, recibir como poco un informe mensual donde en unas pocas hojas, y sin entrar en aspectos demasiado técnicos, se le mantenga al día de cualquier aspecto relevante que afecte a su seguridad.

>Qué areas de nuestra seguridad conviene externalizar? Evidentemente, no existe una respuesta universal a esta pregunta. Existen áreas que por su delicadez o criticidad no conviene casi nunca dejar en manos de terceros, como es el caso de la realización y verificación de backups: todos hemos escuchado historias graciosas - o terribles, según en que lado estemos - relacionadas con errores en las copias de seguridad, como ejecutar la simulación de copia en lugar de una copia real para finalizar más rápidamente el proceso de backup. No obstante, elementos importantes pero no críticos a priori, como los tests de penetración, de visibilidad o las auditorías de vulnerabilidades, que habitualmente se suelen externalizar, ya que incluso existen empresas de seguridad especializadas en este tipo de acciones. Otro ejemplo de área a externalizar puede ser la gestión de los cortafuegos corporativos, trabajo que en demasiadas ocasiones recae sobre el área de Seguridad propia y que como veremos en el próximo punto no debería ser así. En definitiva, no podemos dar un listado donde se indiquen por orden las prioridades de externalización, ya que es algo que depende completamente de cada compañía y entorno; ha de ser el personal de la propia compañía, asesorado por consultores de seguridad y por abogados (recordemos que la LOPD está ahí), quien decida qué y de qué forma gestionar en outsourcing.

El `Área de Seguridad'

Casi cualquier mediana o pequeña empresa posee actualmente lo que se viene a llamar el `Área de Seguridad', formada pocas veces a partir de gente que haya sido incorporada a la plantilla a tal efecto, y muchas a partir del reciclaje de personal de otras áreas de la corporación, típicamente las de Sistemas o Comunicaciones. En este punto vamos a hablar brevemente de este área y su posición corporativa, haciendo referencia tanto a sus funciones teóricas como a sus problemas de definición dentro del organigrama de la organización.

>Cuál es la función de este área? Realmente, mientras que todo el personal sabe cual es el cometido de la gente de Desarrollo, Sistemas o Bases de Datos, el del área de Seguridad no suele estar definido de una forma clara: al tratarse en muchos casos, como acabamos de comentar, de personal `reciclado' de otras áreas, se trabaja mucho en aspectos de seguridad - para eso se suele crear, evidentemente -, pero también se acaba realizando funciones que corresponden a otras áreas; esto es especialmente preocupante con respecto a Sistemas, ya que en muchas ocasiones el personal de Seguridad trabaja `demasiado cerca' de esta otra área, llegando a realizar tareas puramente relacionadas con Sistemas, como la gestión de los cortafuegos (no nos referimos a la definición de políticas ni nada parecido, sino únicamente al manejo del mismo). Y si a esto le añadimos que a muchos de los que nos dedicamos a este mundo nos gusta también todo lo relacionado con sistemas - sobre todo si son Unix :-) -, pues llegamos a una situación en la que nadie pone pegas a hacer un trabajo que no le corresponde, con lo cual se vicia el área de Seguridad centrándose únicamente en aspectos técnicos pero descuidando otros que son igual o más importantes. Por si esto fuera poco, existe una serie de funciones en conflicto a la hora de gestionar la seguridad corporativa, típicamente la del administrador de seguridad frente a la del administrador de sistemas, de bases de datos, o incluso frente al operador de sistemas y los desarrolladores.

Teóricamente, el área de Seguridad ha de estar correctamente definida y ser independiente de cualquier otra de la compañía, y por supuesto de la dirección de la misma: aunque en la práctica sea casi imposible conseguirlo, no podemos definir una política de obligado cumplimiento para todos los trabajadores excepto para nuestros jefes. Evidentemente, ha de contar con el apoyo total de la dirección de la entidad, que debe estudiar, aprobar y respaldar permanentemente, y de forma anticipada, las decisiones de seguridad que el área decida llevar a cabo (siempre dentro de unos límites, está claro...).

El trabajo del área debe ser más normativo que técnico: no podemos dedicar al personal de la misma a cambiar contraseñas de usuarios o a gestionar (entendido por `manejar') los cortafuegos corporativos, sino que el área de Seguridad debe definir políticas e implantar mecanismos que obliguen a su cumplimiento, o cuanto menos que avisen a quien corresponda en caso de que una norma no se cumpla. Técnicamente esto no es siempre posible, ya que ni todos los sistemas ni todas las aplicaciones utilizadas tienen porqué ofrecer mecanismos que nos ayuden en nuestra seguridad, pero cuando lo sea es función del área bien su implantación o bien su auditoría (si es implantado por otro área). Si una determinada aplicación no soporta las exigencias definidas en la política de seguridad, pero aún así es imprescindible su uso, el área de Seguridad debe recordar que el cumplimiento de la normativa es igualmente obligatorio; al oir esto, mucha gente puede poner el grito en el cielo: en realidad, si el programa no cumple las especificaciones del área de Seguridad, lo lógico sería prohibir su uso, pero funcionalmente esto no es siempre (realmente, casi nunca) posible: no tenemos más que pensar en una aplicación corporativa que venga gestionando desde hace años las incidencias de la organización, y que evidentemente la dirección no va a sustituir por otra `sólo' por que el área de Seguridad lo indique. Si nuestra política marca que la longitud de clave mínima es de seis caracteres, pero esta aplicación - recordemos, vital para el buen funcionamiento de la organización - acepta contraseñas de cuatro, el usuario no debe poner estas claves tan cortas por mucho que la aplicación las acepte; si lo hace está violando la política de seguridad definida, y el hecho de que el programa le deje hacerlo no es ninguna excusa. La política es en este sentido algo similar al código de circulación: no debemos sobrepasar los límites de velocidad, aunque las caracteríticas mecánicas de nuestro coche nos permitan hacerlo y aunque no siempre tengamos un policia detrás que nos esté vigilando.

Aparte de la definición de políticas y la implantación (o al menos la auditoría) de mecanismos, es tarea del área de Seguridad la realización de análisis de riesgos; aunque el primero sea con diferencia el más costoso, una vez hecho este el resto no suele implicar mucha dificultad. Por supuesto, todo esto ha de ser contínuo en el tiempo - para entender porqué, no tenemos más que fijarnos en lo rápido que cambia cualquier aspecto relacionado con las nuevas tecnologías - y permanente realimentado, de forma que la política de seguridad puede modificar el análisis de riesgos y viceversa. Asociados a los riesgos se definen planes de contingencia para recuperar el servicio en caso de que se materialice un problema determinado; esta documentación ha de ser perfectamente conocida por todo el personal al que involucra, y debe contemplar desde los riesgos más bajos hasta los de nivel más elevado o incluso las catástrofes: >qué pasaría si mañana nuestro CPD se incendia o el edificio se derrumba?, >cuánto tardaríamos en recuperar el servicio?, >sabría cada persona qué hacer en este caso?...
next up previous contents
Siguiente: Apéndices Subir: Otros aspectos de la Anterior: Algunas herramientas de seguridad   Índice General
2002-07-15