Dando un nuevo paso

Hola,

El pasado día 16 de Enero fue mi último día de trabajo en Canon. He estado en España hasta ayer, resolviendo unos temas personales y tratando de descansar un poco, así que perdón por el silencio al respecto :)

Mañana comienzo una nueva andadura. Estuve meditando mucho qué hacer con mi futuro. Tenía claro que quería quedarme en Holanda, aunque por fortuna siempre te acaban contactando de otros sitios para ver si tienes interés en alguna posición. Curiosamente nunca me contactaron de España, pero bueno, siempre hay lugares como Reino Unido y Alemania que están dispuestos a darte una oportunidad. Gracias por el interés y siento haber declinado.

Finalmente voy a incorporarme a Deloitte. Lo haré en su unidad de Enterprise Risk Services (ERS), y la verdad, estoy muy contento con el cambio. Tenía ganas de volver al mundo de la prestación de servicios especializados por diversos motivos: El principal es que son puestos exigentes, muy exigentes, en los que se aprende mucho y donde estás continuamente motivado para atender requisitos de clientes con diversas necesidades y proyectos, algunos de ellos extremadamente complejos y voluminosos, lo que te obliga a que tengas que dar lo mejor de tí mismo todos los días y que tengas que esforzarte mucho para estar al tanto de lo que ocurre no sólo en el mundo de la seguridad, sino también en lo que concierne a tecnología y negocios. También clave a la hora de decidirme ha sido la valía y la categoría del equipo humano con el que tendré el gusto de trabajar, profesionales y cualificados en extremo y de los que sin duda aprenderé todos los días, creciendo con ellos como persona y profesional.

Aunque estaré en el área de Seguridad, Privacidad y Resiliencia, trabajando en diferentes verticales, espero también poder ayudar a mis nuevos compañeros en otros áreas de interés dentro del ERS, como por ejemplo estrategias de riesgo, control y gobierno, data risk, auditoría interna o gestión de riesgo. Todos son campos que me gustan y estoy seguro que surgirán proyectos interesantes. Por otro lado, Deloitte es una compañía con amplia huella internacional y esto me brindará oportunidades futuras de poder trabajar con clientes y compañeros en todo el planeta, lo cual siempre es un incentivo, dado que soy una persona que disfruta de la multiculturalidad, de la vocación de ofrecer servicios de calidad y diferenciados independientemente de dónde se ofrezcan, y de rendir al máximo cuando me rodean profesionales de la más alta cualificación con diversos orígenes y trayectorias, tanto en el lado del cliente como del prestador de servicios.

Desde estas líneas les mando a mis compañeros y amigos de Canon EMEA, y en especial al equipo de seguridad y gobierno, un saludo y mis mejores deseos. Son gente excepcional, me han tratado muy bien estos dos años y medio y les deseo todo lo mejor en adelante. He aprendido mucho con ellos, me han dado la oportunidad de conocer nuevas áreas de trabajo en el mundo de la seguridad informática y la tecnología en general y han sido excepcionales en el trato personal. Por ello, como comentaba, mi más cordial saludo y mis mejores deseos para el futuro. Ha sido un auténtico placer aprender con ellos, labrar buenas amistades y desarrollar actividades en muchos países y en multitud de proyectos exigentes. También mis mejores deseos para los proveedores y terceras partes con las que he trabajado en este periodo, quizás demasiados para ser enumerados. Good luck guys, and thanks for everything.

También un saludo a los que me han ayudado y apoyado a la hora de tomar esta decisión. En esta vida hay gente que merece especial reconocimiento, y sin duda, es el momento de acordarme de los que te apoyan sin arrugarse cuando lo necesitas. Muchas gracias, sé que me estáis leyendo. Os debo una. Habida cuenta de que seguiré ubicado en Holanda, ya sabéis, hay que repetir visitas y juergas pasadas :)

Un abrazo, y nos seguimos leyendo.

Sergio

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