Auditoría de centros de procesamiento de datos. Parte 2: Seguridad lógica

ÍNDICE

Auditoría de centros de procesamiento de datos. Parte 1: Seguridad física

Auditoría de centros de procesamiento de datos. Parte 2: Seguridad lógica

Auditoría de centros de procesamiento de datos. Parte 3: Aspectos contractuales y de gestión energética

Hola,

Retomamos nuestro hilo de auditoria de CPDs interrumpido por las vacaciones navideñas. Hoy tocaremos la segunda parte, una de las más importantes, que tiene que ver con seguridad lógica. Definir la seguridad lógica como aquella que compete a lo que no es estrictamente físico, y que como su propio nombre indica, deriva de las condiciones lógicas de los distintos sistemas que componen el proceso de negocio en estudio. El caso típico es la seguridad de los sistemas operativos, la reglas de un cortafuegos o la configuración de seguridad de un dispositivo de red, aunque hay muchos aspectos que no estando puramente vinculados a la seguridad lógica tienen impacto en ella. Veremos algunos ejemplos más adelante.

El enfoque nuevamente, tal y como explico en la primera parte, es contaros lo que suele ir mal, para ayudaros a enfocar los análisis en caso de tener que emitir una opinión de las condiciones de un CPD sin disponer para ello de excesivos recursos. Si queréis tener una guía completa podéis emplear las referencias bibliográficas incluidas en el primer artículo. Haceos cargo que cada uno de los escenarios que comento da, por sí mismo, para poder ejecutar una auditoría en profundidad, con lo que me es imposible narrar todo lo que hay que ver y analizar para cada uno de los aspectos. Prefiero mencionar los tópicos, y que cada cual pondere en cada caso la cantidad de esfuerzo que quiere dedicar a cada aspecto.

Lo que suele ir mal

En mi experiencia la mayoría de CPDs suelen tener buena seguridad física, y es en la seguridad lógica donde suelen pinchar. Es común observar deficiencias en los siguientes aspectos:

• Actualización de los sistemas. Englobamos aquí todos los problemas relacionados con la falta de actualización de los elementos del centro de datos: sistemas operativos, aplicaciones, firmware … Conviene siempre obtener evidencias de que los sistemas se están actualizando, y es deseable poder verificar con alguna herramienta de análisis de vulnerabilidades la fiabilidad de lo que nos cuentan con los papeles por delante. Atentos a este punto, no existe CPD en todo el universo que tenga todos y cada uno de los elementos actualizados.
• Configuración de seguridad. Otro clásico. En este apartado incluimos la ausencia de seguridad que deriva de la falta de militarización de los componentes puestos en producción. Ejemplos típicos son la ausencia de fortificación de los sistemas operativos, o dejarse por ahí usuarios por defecto. Es un campo denso, y por tanto, conviene obtener justificación de cómo se fortifican los servicios. Generalmente es aceptable obtener una lista de procedimientos de fortificación por sistema, y verificar aleatoriamente alguno de los elementos para ver que se están aplicando. Si queréis una pista, echad un ojo a los accesos web de los routers y switches, los servicios en escucha en los sistemas operativos y las políticas de contraseñas de los elementos. Sacaréis algo siempre.
• Motorización operacional. Son todas las actividades que ocurren en la sala de control del CPD, y que generalmente tienen que ver con la motorización operativa, es decir, la que se encarga de que las cosas están funciones con normalidad en el natural desenvolvimiento de la actividad. Aunque estrictamente hablando estos procesos son operativos, cuando son insuficientes también son menores las posibilidades de capturar eventos de seguridad que tengan reflejo en el funcionamiento normal de los procesos de negocio o que causen disrupciones, como por ejemplo, los DDoS. Dedicad un buen rato a hablar con el jefe de sala, y sentaos con los operadores para ver que se monitoriza, de qué manera, y cómo se reacciona ante incidentes. Pedir el registro de incidencias es siempre aconsejable para ver que allí se está trabajando con seriedad y no mirando las pantallas.
• Operaciones de seguridad. El gran ausente en muchas ocasiones. En un CPD tiene que haber operaciones de seguridad, sí o sí. Un CPD que no disponga de operaciones de seguridad es simplemente inconcebible. Este saco es tremendamente amplio, pero aquí entran todos los mecanismos usuales de prevención y reacción ante incidentes de seguridad: IDS/IPS, firewalls, honeypots, gestión antifraude, SIEM, DLPs, etc. Hay que dedicar tiempo a entender bien lo que hay en funcionamiento, qué se esta monitorizando, por quién y cómo se garantiza que la propia infraestructura de seguridad sirva para su propósito y no esté expuesta a intromisiones o ataques. Alerta roja si nadie es capaz de contarte en unos minutos al menos qué hay en funcionamiento para prevenir incidentes de seguridad. Una vez más, registro de incidentes de seguridad, iros a los últimos incidentes de severidad máxima, y comprobad qué se hizo, cómo y por quién.
• Segregación de entornos. Otro clásico. Por motivos diversos, que van desde la ignorancia o los errores hasta los intentos de reducción de costes mal enfocados, es relativamente frecuente toparse con entornos que no están debidamente segregados desde el punto de vista lógico. Tener entornos de producción, aceptación, soporte, desarrollo y pruebas compartiendo los mismos discos en distintas particiones es normal, pero también es posible cometer errores de configuración que permitan el salto entre particiones. Generalmente el peligro deriva de la posibilidad de tener desarrolladores accediendo a producción, ya que podrían obtener información que no deben conocer, o incluso modificar componentes. También es posible que se produzcan accesos no autorizados y manipulación de los datos desde otros entornos, como los de soporte, lo cual es especialmente problemático si el soporte lo hace alguna contrata externa. No hay reglas de oro en este capítulo, pero hay que ser férreo cuando se analice este aspecto. Yo suelo sentarme con la gente de desarrollo, y les pido que intenten conectar a bases de datos de producción, o simplemente, que tiren unos pings en la consola para ver si pueden acceder a las máquinas, caso que la segregación esté hecha de esta manera.
• Datos reales en entornos no controlados. Conviene cerciorarse de que los entornos no controlados, generalmente desarrollo y pruebas, no contienen datos reales, o que contemplan medidas de enmascaramiento para impedir que los datos reales de la producción acaben en las memorias USB de los desarrolladores. El principal problema aquí es precisamente ese, que los juegos de datos que se empleen en desarrollo y procedan de los entornos de producción y que no hayan sido convenientemente enmascarados para impedir fugas de información. También es posible encontrarse ficheros y clones de bases de datos en entornos no controlados. Dedicad tiempo a entender cómo se obtienen los juegos de datos de desarrollo y pruebas, y que en caso de ser datos reales, están enmascarados.
• Cifrado. Amplísimo campo, imposible de tratar en profundidad. Comprobad que en general los datos en tránsito y en reposo están cifrados allí donde es suspectible interceptarlos, por ejemplo, en las copias de seguridad de la cintoteca, o la posibilidad de interceptar el tráfico de explotación, que podría contener datos confidenciales como usuarios y contraseñas.
• Compartimentalización de la red. Fundamental. Las redes tienen que tener suficiente segmentación no sólo para poder soportar adecuadamente la segregación de entornos, sino la creación de zonas con distintos requisitos de seguridad. La ausencia de zonas y compartimentalización es un problema de la mayor relevancia, y suele tener su expresión típica en aquellos casos en los que se compromete una máquina determinada, y que por ausencia de segregación, este compromiso faculte el salto a otros segmentos y servicios ajenos al originalmente comprometido que pueden provocar compromisos en cadena. También es frecuente sufrir pérdida operativa en eventos de mantenimiento a consecuencia de una mala compartimentalización, que puede obligar a detener servicios que no son objeto de mantenimiento por el mero hecho de residir en los mismos segmentos de la red en mantenimiento. Aunque no es una regla matemática que se cumpla al 100%, en la gran mayoría de ocasiones la gestión de redes o bien es un desastre soberano o bien es excelente, siendo raro el término intermedio. Cosas que deben haceros sospechar de que hay un chiringuito en ciernes son la ausencia de herramientas centralizadas para la gestión de red y la ausencia de diagramas de red, aunque cuidados con estos últimos, los maestros del Visio y el Powerpoint pueden pintar mucho y ejecutar poco.
• Gestión de cambios. Muchos pensaréis que de entrada es un tema más procedimental que de seguridad lógica, pero las consecuencias sobre la misma son evidentes. Además del citado problema de la falta de actualización otros muchos ejemplos son posibles, algunos frecuentemente olvidados al revisar la seguridad de un CPD. La colocación de código malicioso en la producción por la falta de herramientas de inspección automática del código, o la colocación de programas en producción sin ningún tipo de supervisión por la propia ausencia de una gestión de cambios es una posibilidad que ocurre con cierta habitualidad. Aunque la regulación no implica seguridad, este asunto es siempre tratado en gobierno de TI y cumplimiento, así que echar un ojo a informes al respecto nunca está de más. Solicitad evidencias de la aprobación de un cambio determinado, por ejemplo, un diferencial de código en un programa COBOL del core, y comprobad que está autorizado convenientemente, y que lo que hay en producción es un calco de la versión del programa en desarrollo correspondiente.
• Accesos privilegiados. En un CPD es necesario tener accesos privilegiados para poder operar los servicios. Es una consecuencia natural del empleo de servicios que contemplan gestión de usuarios, como por ejemplo, los sistemas operativos, aunque el acceso privilegiado puede venir definido por otros aspectos, como por ejemplo, segmentos de red determinados en la explotación que son capaces de acceder a servicios críticos. Sea como fuere estos accesos son necesarios, con lo que es de vital importancia comprobar que están bien gestionados. No es sólo una cuestión de verificar que las contraseñas se rotan periódicamente y que la gente no las tiene pegadas en post it en los monitores, es de capital importancia determinar cómo se puede acceder con cuentas privilegiadas a los servicios. Especialmente preocupante si se habilitan accesos remotos para facultar la intervención fuera de horas de oficina o teletrabajo. Cualquier respuesta no inmediata o no concluyente a las preguntas quién accede, cómo y dónde se guardan los logs de estos accesos que quiero verlos es sinónimo de emergencia. Pedir una lista de los usuarios con privilegios altos en un servicio y una explicación de quién es quién suele ser revelador.
• Accesos remotos de terceras partes. Tratad de comprender cómo acceden las terceras partes a la infraestructura, y cuáles son las limitaciones de su acceso. En aquellos casos donde el desarrollo lo hacen contratas externas, donde también es posible que se ocupen del mantenimiento, es crucial entender cómo acceden y cuál es su nivel de privilegio. Aunque es normal que estos accesos se hagan con cabeza, mediante conexiones VPN o circuitos MPLS dedicados, cercioraos de tener absolutamente claro quién accede y cómo. Revisad si los accesos se monitorizan, especialmente en funciones de soporte. Pedir una lista de terceras partes y detalles de conectividad, y no obtener respuesta inmediata, es síntoma de alerta.
• Entornos multicliente (multitenancy). En casos de CPDs públicos o semipúblicos es posible que los servicios sean utilizados por varios clientes. Es un tema de compartimentalización tanto de red como de los propios servicios y sus entornos, así como el de los accesos privilegiados que se concedan al cliente, aunque quiero destarcar de modo independiente por la creciente adopción de estos modelos. No queremos que el root de la competencia pueda ver nuestros datos, ni viceversa. Ni queremos que nuestra base de datos pueda ser accedida desde la partición y las aplicaciones de otro cliente. Tema complejo de resolver, ya qu