Ejecutar trabajo con los clientes me hace siempre replantearme las cosas, esepcialmente dado que soy de los que cree firmemente que la mejor manera de mejorar es aprender remangándonse en el terreno y usar ese conocimiento en trabajos venideros. Y en estos escenarios, cuanto más complejo, mejor.

Si existe un campo hoy en día dentro de la seguridad donde las cosas están poco claras y donde muchos caminan cual veletas, ese es el mundo de la ciberseguridad. Aunque no soy muy amante del sufijo ciber -independientemente de que esté aceptado por la RAE o no- creo que a muchos les puede servir para centrar la conversación. Yo prefiero hablar de operaciones de seguridad, o lo que viene a ser lo mismo, la traslación del mundo de operaciones en el ámbito de TI o los negocios a las actividades necesarias para mantener la seguridad de un entorno determinado. Un poco más abajo explicaremos de qué va esto, y por qué esto no es una colección adicional de buzz words de las muchas que tragamos día a día.

Cualquiera que lea noticias, siga blogs o comparta en Twitter información sobre operaciones de seguridad habrá notado que desde el año pasado este es un campo en ebullición. También por desgracia, salvo las excepciones del malware para ciber espionaje o ciber ataques, léase Stuxnet, Duqu o The Flame, casi todo el debate se centra en cuestiones triviales que de poco o nada sirven a las empresas que quieren afrontar con mejores garantías la problemática de la ciberseguridad.

Y digo con mejores garantías porque en este mundo en el que vivimos, y como todos ya sabemos, protegerse al 100% es imposible. En casa podemos lograr cómodamente un buen estado de seguridad, ya que podemos parchear cuando nos da la gana, no tenemos que mantener aplicaciones y sistemas que están fuera de soporte, no tenemos que someternos a una disciplina de gestión de cambios, ventanas de cambios en producción, ciclos de pruebas eternos, técnica de sistemas, no tenemos cientos de IPs expuestas al tráfico de Internet y sitios Web públicos, no tenemos que lidiar con 200 vendedores distintos y otras 200 maneras de hacer las cosas, no tenemos que integrar negocios que hemos comprado, no tenemos que segregar negocios que hemos vendido, no tenemos que formar equipos virtuales con gente que habla en 10 idiomas distintos, con 10 maneras y culturas de trabajo distintas, no hay necesidad de escribir casos de negocio para resolver problemas, no hay que lidiar con la aprobación de partidas presupuestarias, no hay que mantener 100.000 estaciones diseminadas en 40 países ... podríamos estar horas enumerando aspectos que hacen que la seguridad en casa sea una cosa, y que la seguridad corporativa sea otra bien distinta. En resumen: no dependemos de nosotros mismos.

Precisamente el eterno y erróneo intento de intentar solucionar en la empresa las cosas como las solucionamos en casa es una de las causas principales de que los problemas para corporaciones sean importantes, crecientes y cada vez más difíciles de resolver. Cuando hablo con mis clientes les traslado la idea de un cambio de mentalidad que a muchos les impresiona en un principio y que resulta difícil de digerir: yo lo llamo el estado permanente de compromiso. Seamos honestos: por mucho test de intrusión que hagas, por mucho antivirus que corras y por mucho IDS que tengas desplegado, los amigos de lo ajeno van a encontrar siempre la manera de entrar. Son demasiadas las variables que tenemos que controlar para pretender que podemos controlarlas todas. Es imposible y hay que partir de esa base para construir mejor seguridad.

Añadamos a esto el hecho que los vectores de ataque, que eran puramente técnicos en el pasado en su amplia mayoría, están ahora centrados en las personas, lógicamente con el apoyo en la explotación de tecnología. Por eso hace 5 años era aceptable tener una granja de IDS/IPS, y confiar la seguridad a San Firewall, San Microsoft Update y San Test de Intrusión, y hoy en día confiar la seguridad sólo en esos sistemas es una pérdida de tiempo. Agreguemos al cóctel la pérdida del perímetro, que ya no existe como tal, la integración de business partners en las redes corporativas y la explosión de ofrecimiento de servicios que tradicionalmente eran de back-end en frontales web para la interacción con usuarios, que demamdamos más y más servicios en nuestros dispositivos.

Quizás la consecuencia más dramática del estado permanente de compromiso es la asunción, por dolorosa que sea, de que la prevención no es suficiente. Aunque sigue siendo buena idea prevenir, la prevención siempre termina fallando, y es entonces cuando es preciso tener medidas reactivas en plaza para intentar reducir el impacto de un evento de violación de la seguridad. Pero tampoco vale sólo con correr una consola SIEM escupiendo alertas, porque nuevamente, los mecanismos preventivos van a fallar, y cuando lo hagan, vas a tener un problema.

No hay soluciones fáciles a estos problemas. Los nuevos escenarios requieren nuevas maneras de hacer las cosas. Tener definido un mapa de amenazas es la parte básica, hay que identificar de manera cristalina qué queremos proteger, cómo y de qué. Este paso tan sencillo es ciencia ficción para muchos, y lógicamente, sin esta base es imposible intentar organizarse para afrontar las amenazas reales que puedan estar acechando a la vuelta de la esquina. Pero aquí no acaba todo. A todos se nos llena la boca con ArcSight, enVision o Q1, y muchos son los que corren estos SIEMs, pero, ¿cuántos tienen realmente un sistema adaptado a los tiempos modernos? ¿Cuántos SIEMs ha ahí fuera corriendo todavía los clásicos casos de usuario inútiles, como intentos de fuerza bruta, o logins en horario fuera de oficina?

Si queremos tener garantías de mínimo impacto, quizás convenga tener a mano fuentes creíbles de información de amenazas. Esto es lo que veréis anunciado como threat intelligence, y viene a ser información, generalmente generada por terceros, que emplearemos para detectar lo más cerano al tiempo real amenazas de seguridad que se van descrubriendo y sobre las que normalmente no tenemos visibilidad. Y sí, aquí si juega un papel importante un SIEM potente para articularlo todo: información de seguridad que emana de nuestros sistemas, integración con fuentes de inteligencia externas, plataformas de análisis automatizado de malware, y todo ello conjugado con casos de usuario específicos para nuestras pretensiones: recordad lo que hemos escrito sobre escenarios más arriba. Pero una vez más, esto no se resuelve con un SIEM únicamente, la correlación es vital en escenarios compejos de ataque, con lo que resulta también crucial establecer cómo hacer dicha correlación con datos cercanos al tiempo real y con datos no tan cercanos.

Y para terminar de complicar las cosas, y nuevamente me remito al estado permanente de compromiso, aún con todas estas cosas los malos van a encontrar la manera de entrar. Hay que saber reaccionar, lo que implica tener procedimientos de respuesta ante incidentes sólidos, entrenarse con escenarios red flag, tener habilitada una disciplina forense para el análisis de brechas de seguridad, instruir a los usuarios en temas de concienciación ... y todo esto hay que coordinarlo de una manera centralizada, suficientementre flexible y orientada a los resultados. Es lo que conocemos como un centro de operaciones de seguridad, o SOC, que para más inri, no vale con articular de una manera técnica, ya que es preciso, como en cualquier otra área del negocio, gestionar con aspectos económicos y administrativos, lo que implica métricas, programas de mejora, evaluación de la respuesta de los operadores, del escalado y gestión de los incidentes, KPIs que se hayan establecido .... y ese larguísimo etcétera.

Como resulta fácil comprobar, dar el salto cualitativo de una manera de gestionar las operaciones de seguridad centrada en la tecnología hacia una manera eficiente y centralizada de gestionar un centro de operaciones de seguridad donde atendamos la problemática de las personas y los procesos además de la tecnología no es nada sencillo. Es harto complicado, para ser más concretos. El nivel de inversión y de cambios es tan brutal que muchos, directamente, miran hacia otro lado. Prefieren seguir confiando en test de intrusión, actualización de antivirus y parches en sus exploradores. Y rezando por las noches para que al día siguiente no sean ellos los que salten a los titulares.

Un lujo que podrías permitirte en casa, pero que te acabará hundiendo en el mundo de los negocios. Es hora de cambiar el chip. Tú decides.

BONUS 10 consejos prácticos para implementar un SIEM/SOC

Os dejo una lista de cosas que veo en el terreno y que pueden daros una idea de cómo no afrontar la problemática de la ciberseguridad. El orden no implica importancia: todas estas cosas son vitales.

1. Este es un tema que requiere cambiar a las personas, tecnología y procesos. No dejes estas tareas en manos de personas que sólo son hábiles con el nmap y el Nessus, o sólo con el Powerpoint.
2. Desconfía de implantadores que no tengan credenciales. Pídelas. Y verifícalas. Montar un SIEM/SOC es algo que no está al alcance de cuaquiera que clame ser consultor de seguridad. Requiere experiencia en el terreno, y preferiblemente, en el mismo vertical donde tú vas a implementar. Esto no es un proyecto de una semana y media.
3. Haz tus inversiones de manera escalonada. No quieras hacerlo todo en 6 meses, o te atragantarás. Y lo que es peor: el CFO se atragantará también. Construye un pla creíble que ofrezca resultados escalonados, que te ayudarán a vender mejor lo que haces en la organización, lo que al final te posibilitará accesoa presupuesto de manera incremental.
4. Mide tus posibilidades. Si esto se te escapa de las manos, acude a gente externa para que te ayude. Lo mismo aplica a la operación, si no tienes gente en casa que pueda hacerlo, ya que construir un 24x7 requiere sudor y euros, contrátalo fuera. Sin dudarlo.
5. Si escoges primero la tecnología y tratas después de que todo gire alrededor de ella, acabarás estampándote contra la pared. Hazlo al revés: primero entiende tu negocio y luego selecciona la tecnología que te ayude a protegerlo. Suena elemental pero es la primera causa de fallo en estas integraciones.
6. Cuando hables con tu CFO, déjale claro que esto es un tema que requiere no sólo CAPEX, sino también OPEX. Que nadie se lleve a engaños, un SIEM/SOC además de inversión inicial requiere financiación continua.
7. Presta mucha atención a los casos declarados en el SIEM. Cuando no estén documentados desde la A a la Z, para cubrir cada uno de los riesgos principales del negocio, alerta roja. Cada operador del SOC tiene que tener muy claro qué hacer en cada uno de los casos y sus etapas, revisa con tu integrador otras implantaciones similares antes de contratar, y no te cortes un pelo a la hora de pedir estas cosas como prueba de que se ha implantado algo creíble y no un spaghetti inútil de alertas.
8. Invierte en ajustar y en probar. No esperes, ni de lejos, que estas integraciones sean 100% exitosas cuando concluya el despliegue. Nada más lejos de la realidad.
9. Cuando selecciones tecnología, presta mucha atención a la integrabilidad de las plataformas que quieras someter a disciplina del SIEM/SOC. Es normal tener en casa muchas tecnologías distintas que no hablan entre sí, salvo que tengas un middleware decente, así que pídele a tu integrador que te explique con pelos y señales cómo piensa conectarlo todo. Y que te explique qué viene out of the box, y qué hay que desarrollar. Costes ocultos a la vista ...
10. Por último, entrena los casos de reacción ante indicadores de compromiso hasta la saciedad. Son lo que marcan la diferencia a la hora de lidiar con lo verdaderamente complicado, aka lo que puede hundirte.

Saludos,

Hace 7 años publiqué una nota sobre cómo instalar y usar LaTeX en Windows. Curiosamente es uno de los enlaces que más tráfico trae al blog, y son muchos los que han tenido problemas a la hora de seguir los pasos descritos en el artículo original. Recientemente varios usuarios y amiguetes me han pedido una revisión del texto original porque al parecer las instrucciones que dejé escritas años atrás ya no son tan válidas, vaya, que sorpresa :P

Dicho esto, os dejo una guía rápida que espero sirva de actualización para el artículo original, y que espero resuelva los problemas que estáis encontrando. Lo que sí quiero recalcar es que LaTeX es un lenguaje de programación, y por tanto, cuando se encuentran problemas hay que ser autosuficientes y tirar de documentación (Google, comprarse un libro, esas cosillas ...). También comentar que LaTeX no está pensado para escribir documentos en general, sino más bien de índole científica.

Como norma general, en un entorno gráfico como Windows se necesitan al menos 3 componentes para poder generar y visualizar documentos LaTeX.

• Un compilador LaTeX, en nuestro caso MiKTeX
• Un editor, para no tener que andar escribiendo código en el bloc de notas (aunque yo lo prefiero, sinceramente). En este caso emplearemos TeXniCCenter, aunque existen infinidad de editores, con lo que os recomiendo que os paséis por http://en.wikipedia.org/wiki/Comparison_of_TeX_editors para aprender más sobre el editor que os pueda convenir en cada caso
• Un visualizador del fichero de salida compatible con PostScript, la mayoría de los usuarios empleará Adobe Reader para tales menesteres

Instalando un compilador para LaTeX: MiKTeX

Es el mismo compilador que os recomendé en 2005. Y lo sigo haciendo. Este editor es plenamente funcional con las versiones más modernas de Windows: Windows 7, Windows Vista con Service Pack 2 (con la excepción de Starter Edition), Windows XP con Service Pack 3, 2008 R2 y 2003 R2. Nota: Las versiones más modernas no funcionan con Windows 9x/Me/NT/2000.

El proceso de instalación comienza descargando MiKTeX desde http://miktex.org/2.9/setup. Como buen programa Windows el proceso de instalación se acompaña con el típico paso a paso. Primero seleccionamos una ruta para instalar (en WIndows 7 64bit por defecto es C:\Program Files (x86)\MiKTeX 2.9) y luego un formato de papel preferido (por defecto es A4). El instalador nos preguntará también que hacer con los paquetes que falten, por defecto la opción es "ask me first", y no hay problema en que así sea. Iniciamos el proceso de instalación, y esperamos a que concluya.

Problemas usuales en este paso:

• Cuelgue/crash en plataformas 64bit si se emplea un instalador 32bit lanzado sin permisos de administrador. Solución: lanzar el instalador con permisos de administrador
• Inestabilidades en el paquete de instalación 64bit. Es experimental, con lo que se soluciona utilizando el instalador de 32bit

Una vez finalizado el proceso de instalación procedemos a instalar un editor. Cualquier problema adicional que os encontréis en esta fase debe ser resuelto consultando el soporte de MiKTeX, que está disponibles en http://miktex.org/support. Me encanta que dejéis comentarios pero por desgracia no soy Rappel y no controlo bien la adivinación remota, así que sin tener delante de mis narices el equipo me resulta difícil evaluar cada caso :)

Instalando un editor: TeXnicCenter

Es el editor recomendado por su sencillez de instalación y uso. En la sección de descargas de TeXnicCenter tenéis un binario que se llama TeXnicCenter 1 RC 1 Installer.

Tras el proceso de instalación se abrirá un pequeño configurador en el que debemos especificar la ruta donde están los ficheros binarios esenciales de MikTeX, que son tex.exe y latex.exe. En una instalación por defecto en Windows 7 64bit, estos ficheros están en C:\Program Files (x86)\MiKTeX 2.9\miktex\bin. El configurador sólo seguirá adelante si especificamos la ruta correctamente.

A continuación el configurador nos pregunta por la ruta del visor PostScript. Es opcional, pulsad "siguiente". Finalizad el proceso.

Problemas usuales en este paso:

• Erorres en la instalación al no poder escribir el directorio de programas de Windows. Solución: instalar como administrador
• Al iniciar el configurador la ruta de está vacía. Solución: Esto es normal, instalad antes MiKTeX y seleccionar aquí la carpeta bin dentro de la ruta donde hayáis instalado MiKTeX, que por defecto es algo similar a C:\Program Files (x86)\MiKTeX 2.9\miktex\bin)
• Errores diversos al especificar las opciones del visor PostScript. Solución: Es configuración opcional, si no sabes lo que es, mejor no tocar. Lee la documentación antes de toquetear opciones que no conoces :)

Un ejemplo para practicar

Os dejo una porción de código para que practiquéis:

 
 
\documentclass {article}
\usepackage [spanish] {babel}
\usepackage [T1]{fontenc}
\usepackage [latin1]{inputenc}\begin{document}
\title{Instalando y usando \LaTeX\ en Windows}
\author{Sergio Hernando - http://www.sahw.com}
\maketitle
 
\begin{abstract}
	Bienvenidos al PDF más absurdo que has leído en los últimos 20 años
\end{abstract}
 
\section{Esto es un delimitador de sección como otro cualquiera}
 
Aquí podemos escribir todo el texto que queramos. Blablabla ...
 
	\begin{enumerate}
	\item Número 1
	\item Número 2	
	\end{enumerate}
 
\section{Es posible emplear fórmulas matemáticas}
 
Por ejemplo, una integral:
 
	$$ \gamma = \int_0^1 \frac{x}{2+5x^4} dx $$
 
También podemos escribir una matriz de datos:
 
	\begin{eqnarray}
	V = \frac{4 \pi r^3}{3}
	\end{eqnarray}
 
\section{... y  enlaces bibliográficos}
 
	\begin{thebibliography}{9}
	\bibitem[Welsh y Kauffman, 1995]{Welsh:1995} Welsh, Matt y Lar Kauffman. \textsl{Running Linux}, O' Reilly \& Associates, Inc. Sebastopol, CA, 1995.
	\end{thebibliography}
 
\section{Y con esto y un bizcocho ...}
 
Hasta mañana a las 8
 
\end{document}
 
 

El fichero tex lo podéis descargar aquí, y el PDF resultante lo tenéis aquí.

Un saludo,

No soy muy dado a escribir parrafadas, y menos si no tienen relación con los temas que sabéis que me gustan. Pero a veces hago excepciones, o intento relacionar los offtopics con asuntos que sí me interesan y que sí guardan relación con las temáticas del blog.

Acabo de leer hace un rato un demoledor post de Jose A. Pérez llamado Abandona toda esperanza. Conciso, corto pero hiriente y mordaz, y que me veo a suscribir plenamente. Aunque es duro leer algo así, qué queréis que os diga, no me queda más remedio que estar de acuerdo. Por citar un párrafo:

Digámoslo claro: el Gobierno español no está apostando por una sociedad del conocimiento, sino por un modelo económico basado en la mano de obra. Un país de paletos sin formación que sirven copas y hacen camas a los chicos listos de Europa

La barbarie es tan notoria que hasta medios prestigiosos, como Nature, tildan los eventos como suicidio científico. Otro artículo demoledor, de estos que conviene leer de vez en cuando para ver cómo ven los demás cómo se desenvuelve España en esta situación de crisis.

Aunque el artículo se centra en todo lo que los recortes en I+D suponen, yo quiero desde aquí recordar que la tecnología, ese mundo que nos apasiona a todos los que aquí nos damos cita de vez en cuando, también es investigación, y también es desarrollo. Esto no va sólo de recortar partidas presupuestarias en Sanidad, lo cual de por sí es espeluznante. El progreso de una nación y el bienestar de su ciudadanía dependen muy mucho de la tecnología, y de cómo se consume y se produce. Aunque es lícito apostar por ser un país puramente de servicios, ya que bien hecho puede resultar en una situación económica satisfactoria para los ciudadanos, yo creo que es un craso error jugárselo todo a una sóla carta. Dejar a un lado la I+D y centrarse sólo en lo que ha resultado ser un fiasco continuado a lo largo de los últimos años es una apuesta perdedora.

Las tecnologías de la información son también I+D. Hace tiempo comentaba en este blog que, habiendo perdido las posiciones de liderazgo en el ámbito de las TI -si es que alguna vez las hemos tenido-, España debería plantearse resignarse temporalmente a ser un país de bajo coste que capture el negocio de las subcontrataciones en TI que se hacen en otros países con mejores perspectivas económicas. Os conté cómo Portugal y sus profesionales han tomado nota de lo que se está cociendo, y que escucharlos ofrecer tarifas de descuento del 30, 40 y 50% sobre la media europea es lo normal, y que nadie en Portugal se cree peor persona por dedicarse a realizar proyectos a menor coste, como tradicionalmente han venido haciendo y hacen países como India, Egipto, Rumanía o la República Checa, por citar algunos ejemplos. Para mí es mejor eso que tirarlo todo por la borda. No pasa nada si durante una temporada le hacemos la cama a los chicos listos de Europa, y aprovechamos para aprender de nuestros errores, formarnos con la máxima disciplina y conseguimos atesorar la masa crítica necesaria para pasar de hacer la cama a que nos la hagan.

Naturalmente no espero que todos asintáis y que compartáis mi punto de vista. Nuestra cultura es muy reacia a bajarse los pantalones, aunque sea una estrategia temporal para reestructurarse y volver a convertirse en líderes. Recibo muchas críticas a este planteamiento y estáis en vuestro derecho a hacerlas. También os puedo contar que conozco a bastantes personas que, al igual que yo, dábamos palmas con las orejas si sacábamos en el año 2000 400 euros al mes por nuestro trabajo. Y muchas de estas personas han aguantado el tirón, han sabido ser pacientes y no han dudado en rebajar sus pretensiones económicas hasta que han adquirido peso y representatividad suficientes como para ni atender el teléfono o el correo si la tarifa diaria a percibir es menor a 1800 o 2000 euros. Para mí es una cuestión de decidir entre negarse a aguantar el chaparrón, o aguantarlo con vistas no sólo a sobrevivir, sino a aspirar a ser de nuevo los líderes, y poder subirnos los pantalones nuevamente.

Pero cuando se recorta en I+D, cuando se condena el progreso tecnológico de esa manera tan absurda e injustificada, corremos el mismo riesgo que está corriendo la única carta a la que nos estamos jugando el progreso y el bienestar de esta generación y de las que vienen. Otros países están tomando nota de que los chicos listos de Europa buscan normalmente cama, comida y bebida en cálidas arenas, y que a la gran mayoría les importa un bledo que sean las arenas españolas, las italianas, las griegas, las africanas, las caribeñas o las asiáticas. Lo que les importa es que la calidad/precio les parezca satisfactoria. A ojos de estos países y sus avispados inversores basta con ofrecer turismo a menor coste para dejarnos también fuera de juego en la que parece ser nuestra única apuesta de futuro, cosa sencilla teniendo en cuenta los disparatados precios que hay que pagar en España para alojarse, comer y beber en una zona turística.

Igual que nos están robando el queso con paquetes turísticos de calidad y menor precio, no os quepa duda que están pasando lo mismo con las TI. El número de países emergentes ofreciendo calidad aceptable a costes bajos es creciente, y nosotros entre tanto, no sólo tiramos por la borda la I+D que nos permitiría ser líderes, sino que encima pretendemos cobrar el residuo a tarifas noruegas. No amigos, no. Los chicos listos de Europa no van a dudar en dejarnos en la estacada no sólo en la playa y los restaurantes. También lo harán sin contemplaciones en el mundo de las TI y de hecho, lo están haciendo.

Recortar en I+D es un error. Es un lujo que no podemos permitirnos. Días como hoy me entristece ver lo que pasa en mi país de origen, y me preocupa seriamente el futuro de las personas que allí viven. Sigo deseando que las cosas cambien, pero noticias como ésta me están haciendo ver claro que quizás, y parafraseando a José A. Pérez, ha llegado el momento de abandonar la esperanza.

Os dejo unas notas sobre un experimento reciente que he estado realizado con una instalación peculiar de Snort, en este caso en el propio router, por si fueran de vuestro interés.

Necesitamos:

• Un router con DD-WRT. En mi caso es un Asus RT-N16
• Preparar el router para optware, y aquí la recomendación es seguir los pasos descritos en el wiki
• El router debe tener entrada USB, porque lo aconsejable es instalar optware en un dispositivo externo, en este caso una llave o disco USB, para no agotar el escaso espacio disponible en el router. Es recomendable emplear ext2 (cosa que yo no he hecho, por cierto), ya que ext3 como sabéis es un sistema de ficheros con journaling y por tanto, con ext2 podemos acelerar el acceso al disco al no tener que efectuar dicho journaling. Recomendación: Leer el wiki.
• Habilitar en el router JFFS (Journalling Flash File System). JFFS/JFFS2 proporciona un area de reescritura en el router que es necesario para instalar paquetes vía ipkg, así que hay que habilitarlo. Es una opción dentro de la administración de DD-WRT:

  

Paso 1. Conectamos el medio externo y verificamos que monta adecuadamente

Los incrédulos pueden tirar de la shell para verificar, lo cual nos vendrá bien para verificar también que tenemos soporte JFFS. Es fácil observar parte de la estructura flash de almacenamiento montada en /jffs en la línea /dev/mtdblock/4 on /jffs type jffs2 (rw)

Paso 2. Lanzamos la preparación de optware

Esto se hace vía consola en dos cómodos pasos:

1. Descarga wget -O /tmp/prep_optware http://wd.mirmana.com/prep_optware
2. Ejecución del script de preparación sh /tmp/prep_optware

Paso 3. Una vez finalizada la instalación de optware, lanzamos una consulta de disponibilidad de Snort

Paso 4. Instalamos, siendo recomendable forzar la instalación de dependencias

ipkg -force-depends install snort

Paso 5. Verificamos la instalación

Paso 6. Nos fabricamos un fichero de configuración de snort al uso para nuestras pruebas

Si alguien quiere copiar y pegar, el fichero está disponible aquí. Es un ejemplo muy sencillo en el que emplearemos el preprocesador stream5 para generar dos tipos de alerta: una para cualquier tráfico externo hacia nuestra red, y cualquier tráfico puramente interno, tal y como se muestra en el fichero de configuración.

Paso 7. Lanzamos Snort

Para ello indicamos el fichero de configuración recién creado y una ruta donde escribir las alertas y los logs. En mi caso por comodidad, las he ubicado también dentro de /opc para evitar el colapso por agotamiento de almacenamiento:

snort -i vlan1 -c /opt/etc/snort/test.conf -l /opt/etc/snort/snortlog

Nótese que lanzo sobre la primera vlan (vlan1) que tengo definida en el router y que corresponde al primer puerto LAN del dispositivo. Cada cual que escoja la que desee.

Paso 8. Observamos si el invento funciona

Aprovechando que SSH está activo, nos asomamos con un cliente gráfico, o bien lanzamos un ls por la consola. El caso es comprobar que se estén generando logs y alertas.

Paso 9. Nos damos una vuelta

Pues eso, dejamos que corra el aire un poquito antes de ir impacientes a ver las alertas :)

Paso 10. A investigar

Pues en ausencia de procedimientos de asignación de prioridad, escalada y notificación, y habida cuenta de que nuestras reglas dispararán mútiples veces antes numerosos eventos, inspeccionamos el fichero de alertas a mano. En mi caso he detectado a un impresentable haciendo un ataque de fuerza bruta sobre el servidor SSH de otra máquina de la infraestructura:

Mmmm. Espera. 192.168.1.120. Esa es la IP de mi portátil ... y la máquina destino es una máquina virtual del laboratorio que también reconozco. Y la propia alerta me dice que es un evento ocurrido en la red interna. Oh wait.... :)

Saludos,

Í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

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

Buenas,

Tercera y última entrega. Hoy hablaremos, un poco más brevemente, de dos aspectos adicionales que pueden ser sujeto de un proceso de auditoría de un CPD. Especialmente importantes los asuntos contractuales, que a la larga siempre están presentes en un proceso de compra de tecnología o en la prestación de servicios de mantenimiento, y que adquieren especial relevancia en operaciones de externalización, habida cuenta de que en este tipo de operativas es posible abandonar el modelo de propiedad por el modelo de uso de recursos, con lo que se pierde control sobre la adquisición de equipos y sobre los contratos que giran a su alrededor.

También, dependiendo de la legislación y según el estilo de gestión de la organización, los preceptos de gestión energética pueden tener valor especial, ya sea por alineamiento con política interna o sistemas de gestión medioambiental, o incluso por la fiscalidad ventajosa que en muchas jurisdicciones tiene la explotación energética eficiente de CPDs. Y evidentemente, por el impacto positivo que siempre acarrea la gestión eficiente en la cuenta de resultados.

Aspectos contractuales

No existen pócimas mágicas en este apartado y tampoco pretende este ser un artículo donde se expliquen todas y cada una de las posibilidades existentes. Hay infinidad de maneras de afrontar esta tarea, pero en todas ellas se trata de hacer lo mismo: obtener cierto nivel de confianza en los acuerdos contractuales necesarios para operar el CPD sin que resultenn lesivos para los intereses de la organización.

A mí me ha ido bien recomendando que se establezca en el flujo del proceso de compras tantos puntos de control como áreas queramos que participen en el proceso y asesoren adecuadamente al comprador. En este caso, los departamentos de Seguridad y Gobierno deberían participar en las compras para poder suministrar a los decisores información valiosa sobre lo que se va a comprar desde el punto de vista de la seguridad, el gobierno y el cumplimiento.

El ejemplo típico que se puede presenciar estos días es la contratación de servicios en la nube. Imaginemos que la organización "A" ha decidido que, por cuestiones de rentabilidad, le es mucho más favorable sacar el proceso de nóminas de la organización, algo además relativamente frecuente en grandes organizaciones y que ha sido acelerado con la disponibilidad de servicios SAP, Oracle y similares que pueden contratarse en un modelo as a service. En este caso el negocio suele quedarse en la siguiente valoración: comparar el coste total de explotación resultante de mantener el servicio en propiedad frente al coste de la externalización de la infraestructura y el software. En paralelo se le suele echar un vistazo a los SLAs (es decir, si la cosa va mal, qué repercusión tiene esto sobre mi disponibilidad, cuánto tiempo se puede quedar el servicio sin operación, etc.), los modelos de soporte y eventualmente, se puede tirar de un Dun & Bradstreet o similar para ver qué proyección económica tiene el proveedor cara al futuro. Rara vez se va más allá, a no ser que otras áreas participen en el proceso.

Como podéis imaginar, la intervención de un departamento de Seguridad puede alertar al negocio de muchas cosas que van más allá de los costes y los SLAs primarios, lo cual puede servir para que los compradores adquieran un servicio en mejores condiciones globales, no sólo económicas. Así por ejemplo:

- Se pueden evaluar los riesgos de externalizar un proceso que contiene información con cierto nivel de criticidad y sensibilidad

- Se puede evaluar a priori la seguridad solicitando evidencias sobre cómo se gestiona por parte del proveedor de servicios

- Se puede sugerir la inclusión de cláusulas de auditabilidad

- Se pueden advertir problemas potenciales de conflicto de interés por la ausencia de controles de segregación en la solución a contratar

Aunque este es sin duda objecto de una labor de auditoría con mucho más alcance -como por ejemplo la auditoría de un proceso de compras- es recomendable, al menos, indagar en los mínimos y tener una idea clara de cómo se gestionan los contratos en un CPD, haciendo especial hincapié en niveles de servicio, condiciones, garantías y seguridad del proveedor. A grosso modo, algunas de las áreas que suelen encerrar sorpresas son:

- Los servicios de mantenimiento de terceros, y concretamente, los niveles de servicio y condiciones de reposición de materiales y traslado de técnicos en caso de incidencias

- Las condiciones para que el proveedor establezca distintos niveles de criticidad en eventos de disrupción operacional así como los tiempos de respuesta resultantes. Ojo a los eventos de seguridad

- La ausencia de cláusulas de auditabilidad en los procesos de externalización, lo que impide realizar verificaciones de seguridad y auditoría en caso de contratarse

- La declinación de responsabilidad del proveedor en caso de que exista un incidente de seguridad en la infraestructura y el software que mantiene para nosotros

- Políticas de gestión de cambios que no se acomoden a nuestras necesidades (especiamente, instalación de parches y actualizaciones)

- La ausencia o deficiencia de las operaciones de seguridad en el servicio: cortafuegos, IDS e IPS, SIEM, etc.

- La ausencia o deficiencia de mecanismos de continuidad de servicios, locales y remotos.

Son tan sólo algunos ejemplos. Conviene dedicar tiempo a ver este tema con profundiad, y articular, en cooperación con el área Legal, las cláusulas mínimas que deben ser incorporadas.

Gestión energética

En el área de gestión energética el objetivo principal que se persigue es combinar el ahorro con la aplicación de medidas favorables con el medio ambiente. Es frecuente encontrar en la literatura referencias a dos conceptos: Power Usage Effectiveness (PUE) y Data Center Efficiency (DCE) como indicadores de gestión energécitca en un CPD.

Matemáticamente son conceptos muy sencillos de obtener: PUE equivale a la relación entre la carga energética total del CPD respecto a la carga total necesaria para alimentar los equipos de TI, con lo que se calcula dividiendo ambos. DCE es el resultado, en porcentaje, de la operación inversa, es decir, qué porcentaje de energía es necesario para alimentar el equipamiento TI respecto al total de las instalaciones.

Así, por ejemplo, si la potencia necesaria para la alimentación de equipamiento de TI es de 10 KW y la potencia total del CPD es de 12 KW, tendremos que el PUE es de 1.2, mientras que el DCE será del 83%, lo que implica que estamos en un CPD muy eficiente. Si la carga TI es de 10 KW y la potencia total del CPD es de 35 KW, el PUE se dispara a 3.5 mientras que el DCE se reduce al 29%, lo que implica que estamos ante un CPD muy ineficiente, en el que gran parte de la energía no se destina a la tarea fundamental de un CPD, que es el alojamiento y operación de tecnología.

Orientativamente, suelen considerarse como válidos los siguientes valores y calificaciones energéticas:

- PUE 3.0 y DCE del 33%: Centro muy ineficiente
- PUE 2.5 y DCE del 40%: Centro ineficiente
- PUE 2.0 y DCE 50%: Centro intermedio
- PUE 1.5 y DCE 67%: Centro eficiente
- PUE 1.2 y DCE 83%: Centro muy eficiente

A la vista de estas definiciones, la ecuación es clara: cuanto menor es el PUE, más ahorramos. Y esto no es porque lo diga yo: menor PUE significa que el gasto energético en lo que no es alimentación TI -en igualdad de carga de equipamiento- es menor, con lo que la factura energética es también menor.

Como podéis imaginar, el grueso de la energía no estrictamente dedicada a los elementos de TI es principalmente la refrigeración, y por tanto, es el factor que casi siempre hace que el PUE suba o baje. Es fundamental por tanto tener un control muy estricto sobre las condiciones de refrigeración y concretamente, sobre los flujos de aire. Esta disciplina se puede complicar todo lo que se quiera y más, y es muy recomendable documentarse al respecto para averiguar la contidad de parámetros que pueden afectar a la circulación de aire dentro de un CPD. Creedme que es una disciplina compleja, y que existen empresas especializadas en este tipo de optimización.

Otro aspecto a tener en cuenta es determinar cuáles son los umbrales de refrigeración que se hayan definido: más de una ve he entrado en un CPD que en vez de un centro de proceso parecía una cámara de congelación de Pescanova, con el consiguiente despilfarro energético. Entre el frío polar y el calor sahariano siempre hay un término medio en el que la operación no queda comprometida, y cada vez se prefieren más las localizaciones donde se puede aprovechar la baja temperatura ambiente y la presencia de agua cercana para reducir el uso de acondicionadores de aire.

Por último conviene recordar que lograr la eficiencia energética en un CPD no es sólo problema del dueño del CPD. Igual que es nuestra obligación como propietarios la de interesarnos por lograr la eficiencia, por los motivos descritos, es tambien nuestra obligación conducir a los proveedores en esa dirección.

Un saludo, y hasta la próxima ;)

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

Í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

Hace ocho años comenzó la andadura de este vuestro blog. Bueno, esto no es del todo cierto. Realmente el cumple del blog fue ayer.

Y precisamente ayer regresé de unas vacaciones en mi tierra, donde casualmente unos desalmados que dicen ser mis amigos me echaron en cara su tradicional ya te vale, tienes el blog abandonado navideño. Razón no les falta. Y es que mantener al día la cuenta de Facebook te deja poco tiempo para escribir artículos. Oh wait.

No me quiero enrollar más de la cuenta. Gracias a todos. Como siempre, un placer teneros por aquí y continuar aprendiendo de vosotros, compartiendo, cada vez que el tiempo libre lo permite, contenidos que espero sean de vuestra utilidad y agrado.

Un saludo y feliz 2012 para todos. Nos seguimos leyendo :)

Quería desearos a todos unas felices fiestas y un próspero y productivo 2012. Este ha sido un año duro en todos los sentidos, y parece que, por desgracia, 2012 no será mucho mejor. No obstante, ante las adversidades, siempre nos queda sacar pecho y seguir mirando hacia adelante pase lo que pase. Nos ha tocado vivir tiempos difíciles, y es por esta razón que siempre insisto en que tenemos que ser valientes y profesionales, ya que cuando ambas cualidades se combinan nos convertimos en imparables dueños de nuestro destino y automáticamente deja de importar el número de zancadillas que nos pongan, ya que saldremos adelante victoriosos. Siempre.

En lo personal, 2011 ha sido un año cargado de muchas cosas, momentos mejores, peores, viajes, experiencias, aprendizaje, aciertos, meteduras de pata, gente que se fue, gente que vino ... También ha sido un año en el que he ultimado los detalles para un importante cambio en mi vida que espero poder compartir con vosotros a mediados de Enero. Stay tuned :)

Aunque aquí en el blog no me prodigue mucho, quiero recordaos que tengo actividad casi a diaria en mi cuenta Twitter, con lo que si os interesan las temáticas del blog pasaos por allí. También estáis invitados a mi cuenta Google+, con lo que no dejéis de darme un toque si queréis hablar de cualquier tema o si necesitáis ayuda. Sois más que bienvenidos. Mil perdones a la enorme cantidad de gente que me ha agregado a Facebook, pero de momento no tengo la cuenta activa y es por esto que no he aceptado vuestras solicitudes de amistad. ¡Sorry!

Quiero acordarme también de todos los que diariamente ayudáis a diseminar conmigo conocimiento y experiencia en TI, seguridad y análisis forense, creo que estamos haciendo una magnífica labor no sólo educando a los usuarios finales, sino también formando a los futuros profesionales en estos ramos de actividad y dando soporte a los que intentan ganarse el pan diariamente con estas disciplinas. Es para sentirse orgulloso.

Por último quisiera dejaros en forma de felicitación navideña un poco de música. En este caso he escogido un remix de Erol Alkan de un tema llamado "Forever Doplhin Love", original de Connan Mockasin. Espero os guste tanto como a mí :)

Un abrazo para todos, y pasadlo bien. Gracias por estar ahí.

Sergio

Í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

Buenas,

¿Te han encargado una revisión de un data center y no sabes por dónde empezar? ¿Vas a contratar servicios de terceros en una operación de outsourcing y no terminas de fiarte? ¿Te has leído unos checklist de cloud computing y te saben a poco? Estás de suerte. Quizás lo que aquí te cuente te sirva de algo.

Aunque a definición adecuada quizás sea centro de procesamiento de datos (CPD), o por lo menos es la a mí me suena mejor, emplearemos indistintamente data center o centro de datos para referirnos a ese espacio singular donde se almacena una cantidad determinada de equipamiento informático y electrónico destinada a dar soporte a servicios de negocio determinados.

En estos data centers, indistintamente de que sean públicos, privados o mixtos, se dan una serie de condiciones tanto físicas como lógicas, así como procedimientales y técnicas, que definen la seguridad de dicha infraestructura. Auditarlos puede ser una tarea compleja, porque son instalaciones complejas, luego en este artículo no tiene mucho sentido ver todas y cada una de las distintas posibilidades y desarrollar un plan de auditoría para cada una de las facetas. Así que en vez de desarrollar punto a punto un programa de trabajo, lo que haré será detallar lo que suele hacerse mal en un centro de datos, de modo que estas pistas te sirvan de ayuda para poder orientar tu trabajo.

Hablaremos de las siguientes categorías: Seguridad física, seguridad lógica, gestión energética y problemas contractuales. En principio tengo previsto dedicar un artículo a seguridad física, otro a lógica y por último uno donde hablaré un poco de gestión energética y asuntos contractuales.

Seguridad física

Entran dentro de esta categoría todas las medidas para asegurar la integridad física de los equipos almacenados. Desde la verja exterior hasta los mecanismos de extinción de incendios. Como podéis imaginar, es un tema complejo dado que son muchos los factores que intervienen. Los CPD suelen, y digo suelen, tener buenas características de seguridad física, ya que si son suficientemente serios, se diseñan con la seguridad en mente. No obstante suele ser común encontrarse sorpresas en las siguientes áreas:

• Control de acceso. Especialmente en las zonas "cero", es decir, aquellos compartimentos del data center que albergan la infraestructura más valiosa. En una infraestructura de este tipo es deseable siempre tener control en tiempo real de quién entra a dónde, y para qué. No encontrarse con un sistema de control de acceso que genere los registros adecuados y los conserve convenientemente es motivo de incidencia. Se van implantando poco a poco sistemas biométricos y siguen siendo válidos los mecanismos de acceso con tarjetas inteligentes. No os cortéis a la hora de pedir logs de los sistemas de control, y no os extrañe que surjan problemas. Por increíble que parezca, este es un tema donde siempre aparecen incidencias.
• Pruebas de mecanismos de detección y alarma. Todos los responsables de seguridad física te enseñarán extintores, la sala de contraincendios, los sensores de humedad, de temperatura, de detección de humo y de movimiento. Pero no todos pueden enseñarte pruebas fehacientes de que estos sistemas están siendo probados regularmente y que funcionan como es debido. En muchos países, y por motivos de legislación, es obligatorio realizar pruebas periódicas de los sistemas, pero no asumáis que esto pasa en todos los sitios y que las pruebas son exhaustivas. Dedicad un poco de tiempo a esto
• Acceso de mercancías y personal de proveedores. No sería la primera vez que llegar a las zonas cero del CPD es imposible si se pretende la intrusión a través de las vías de acceso convencionales, pero sencillo o relativamente sencillo si se utilizan los accesos especiales para equipamiento y proveedores. Como comprenderéis, si te compras un z114 o un z196, no vas a meterlo por el torno de acceso de los empleados y a maniobrarlo por los pasillos. Para esto existen accesos especiales, generalmente un muelle de carga y descarga donde las mercancías son gestionadas. Recorred este acceso y miradlo con lupa, yo me he encontrado de todo aquí: desde fulanos con destornillador en mano caminando solos por la zona cero a puertas del muelle abiertas de par en par y con gente metiendo y sacando cajas, por citar algunos ejemplos.
• Ausencia de seguridad perimetral o seguridad perimetral insuficiente. Aunque suene a broma, es algo que puede suceder. No es la primera vez que un CPD tiene medidas internas de seguridad físicas excepcionales y que luego, al darse uno una vuelta por allí, descubre que todo está protegido por una verja que un niño de 7 años puede saltarse, o que hay una ventana abierta por la que entrar y quitarse de encima la mayoría de controles de acceso. Si has quedado a las 9 para auditar, procura estar allí a las 8 u 8.30 y date una vuelta por fuera. Las sorpresas están al acecho
• Gestión de energía y continuidad. Es un tema amplio de tratar, y en definitiva engloba todo lo que tiene que ver con el aprovisionamiento energético del CPD. Un CPD es un sitio donde se consume muchisima energía, y por tanto, requiere de medidas especiales para asegurar que el flujo energético esté garantizado ante cualquier tipo de incidente, y que en el peor de los casos, el suministro pueda ser establecido por medios alternativos. Por norma general el CPD suele tener dos o más acometidas de proveedores de energía eléctrica independientes, para no depender exclusivamente de un único proveedor, y es frecuente que internamente se hagan abastecimientos a zonas teniendo en cuenta si requieren máxima resiliencia eléctrica o no. Cuando todo va mal y se pierde completamente el fluido eléctrico, es normal contar con una batería de generadores diesel para garantizar el suministro en caso de contingencia eléctrica grave. Yo sugiero que os presenten pruebas fehacientes de que estos generadores se prueban periódicamente, y que no os tiemble el pulso pidiendo evidencias de carga en los depósitos de combustible. Un esquema unifilar que muestre la redundancia eléctrica suele ayudar igualmente. Como no vamos a andar apagando servidores para ver si aquello funciona, solicitad acceso a un rack con tomas independientes eléctricas y pedid una visita a la sala de cuadros eléctricos para determinar si eso verdaderamente opera con acometidas independientes o no.
• Ausencia de compartimentación. Especialmente relevante en el caso de data centers públicos o destinados al uso de múltiples clientes. En estos casos es de esperar que cada cliente tenga su infraestructura en una jaula y que la cerradura esté, lógicamente, cerrada. Mal asunto si al visitar nuestra infraestructura fuera posible tirar de un cable de la competencia.

Otros problemas: Algunos modelos de CPD que puedes encontrarte

• El CPD jardín botánico. Dícese de aquel en el que el exterior, más que un data center, parece que es un vivero de plantas con vegetación tan espesa que allí podría esconderse un tigre de bengala alegremente. Uno no sabe si está en un centro de datos o en un parque zoológico. Cuidado con este detalle, que puede parecer nimio pero es fuente de problemas. Aparte del hecho de que la vegetación en el perímetro puede servir para que además del tigre se escondan los amigos de lo ajeno, el exceso de vegetación puede ser dañino para la infraestructura, no sólo los cimientos y cerramientos, sino para las conducciones eléctricas, de agua, etc. Adicionalmente, denota falta de cuidado y probablemente es una pista que deba hacer sospechar que allí se están ahorrando costes de una manera equivocada.
• El data center IKEA / el cuartillo de los de informática. Este es el caso que nos encontramos cuando visitamos un centro que sobre el papel debería ser eso, un CPD, pero que en realidad no es otra cosa que un aparador Sjövik de la conocida firma sueca con servidores apilados y cables, o en el mejor de los casos, una pequeña sala al fondo del pasillo, que en vez de tener infraestructura de CPD es en realidad el cuarto de los del departamento de informática, y donde guardan todos sus preciados tesoros, esos que son tan necesarios y útiles en el día a día, como monitores de CRT, equipos 386, impresoras matriciales, cartuchos llenos de polvo, discos duros metidos en cajas de zapatos y ese largo etcétera típicamente asociable a los tipos del área de informática con síndrome de diógenes.
• El data center "Feria de Torremolinos". Es el nombre que le doy al típico CPD en el cual el orden del cableado recuerda más al de una atracción de feria cuando la ves por detrás que a una sala de cómputo. Cables por todos sitios, racks interconectados por el techo con catenarias, puertas de rack aciertas o que directamente, no existen, armarios que con las pisadas se balancean, cableado sin código alguno de colores, servidores alojados en los racks sin ningún tipo de orden y etiqueado ... la lista se puede hacer muy larga. Un CPD tiene que ser un sitio con orden, limpieza y donde de un plumazo se puedan localizar máquinas por grupos o servicios sin tener que hacer una investigación previa.
• El data center tropical. Aquel en el que nada más entrar se siente el calor del trópico. Sólo falta que te pongan un daikiri con una sombrilla de papel y que te dejen tender la toalla. En un data center suele hacer frío, porque hay que refrigerarlo y mantener una condición óptima de temperatura. Que al entrar sintamos calor, o que al pasear notemos que la temperatura no es constante es indicar de problemas en la refrigeración. Esto es una incidencia severa, ya que los efectos de la temperatura son manifiestos: menores rendimientos, mayores costes de operación y máquinas cuyo ciclo de vida se ve acortado innecesariamente.
• El CPD "Cueva de Nerja", o aquel en el que para acceder al suelo técnico o a los falsos techos se requiere un máster en espeleología. Tanto suelos como techos deben ser fácilmente accesibles. Yo suelo pedir que levanten el suelo y no tengo reparos en colarme allí para ver qué se cuece en el suelo. Es un indicador perfecto de mantenimiento y para ver con tus propios ojos la infraestrcutrura de seguridad, como los detectores de inundación. Es un sitio donde no es conveniente encontrarse migajas de pan, un papel albal arrugado y una lata de cocacola dejadas atrás por algún técnico de mantenimiento que no tenía mejor sitio donde desayunar. No te olvides la linterna en casa.
• El CPD "Thyssen-Bornemisza" o aquel donde los clientes se pasean alegremente como si eso fuera un museo, cámara de vídeo y/o fotos en mano y con un responsable de CPD que no tiene reparos en hacer un tour guiado explicando a los clientes potenciales lo que allí hay guardado. No hay necesidad de que nadie filme ni fotografíe tu infraestructura, que además de revelar datos técnicos, frecuentemente tiene etiquetadas direcciones IP, descripciones de servicios y nombres de máquinas, y que por desgracia, puede eventualmente contener contraseñas de emergencia pegadas a las consolas de los racks. Hay que ser muy estricto con estos controles y con su verificación.
• El CPD "Biblioteca de Turín". Es aquel que además de CPD, es lugar de archivo de toneladas y toneladas de papel. Es típico en pequeños edificios donde la infraesructura de CPD es una sala más, y donde por motivos de espacio se suele compartir la sala para archivar documentación. Yo no he venido aquí a pedir prestado el Código Da Vinci, de modo que este tipo de situaciones es fuente de incidencia. El riesgo eléctrico y el papel no son buenos compañeros por lo general.

Dónde encontrar información exhaustiva sobre seguridad física

Existen numerosas fuentes aunque yo tampoco conozco ninguna que aglutine en un único documento todo lo que puede y debe ser auditado, en términos de seguridad física. Quien quiera documentarse en profundidad o realizar su propio programa de trabajo puede recurrir a NIST, que tiene mucha información al respecto, y podéis encontrar referencias a mejores prácticas de seguridad en al menos los siguientes documentos

NIST FIPS 200 Security Controls for Federal Information Systems
NIST SP 800-100 Information Security Handbook for Managers
NIST SP 800-96 PIV Card / Reader Interoperability Guidelines
NIST SP 800-92 Guide to Computer Security Log Management
NIST SP 800-86 Guide to Integrating Forensic Techniques into Incident Response
NIST SP 800-78 Cryptographic Algorithms and Key Sizes for Personal Identity Verification
NIST SP 800-76 Biometric Data Specification for Personal Identity Verification
NIST SP 800-73 Rev 1 Integrated Circuit Card for Personal Identification Verification
NIST SP 800-66 An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule
NIST SP 800-58 Security Considerations for Voice Over IP Systems
NIST SP 800-24 PBX Vulnerability Analysis: Finding Holes in Your PBX Before Someone Else Does
NIST SP 800-14 Generally Accepted Principles and Practices for Securing Information Technology Systems
NIST SP 800-12 An Introduction to Computer Security: The NIST Handbook

En la próxima entrega veremos los problemas usuales en la seguridad lógica, tanto de la propia operación del centro como de los servicios allí alojados.

Un saludo,