Skip to content
22 jul 2012

Ciberseguridad: algo más que una palabra de moda

Publicado por Sergio Hernando

Buenas,

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,

30 abr 2012

Instalar y usar LaTeX en Windows (Actualización 2012)

Publicado por Sergio Hernando

Buenas,

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:

  1.  
  2.  
  3. \documentclass {article}
  4. \usepackage [spanish] {babel}
  5. \usepackage [T1]{fontenc}
  6. \usepackage [latin1]{inputenc}\begin{document}
  7. \title{Instalando y usando \LaTeX\ en Windows}
  8. \author{Sergio Hernando - http://www.sahw.com}
  9. \maketitle
  10.  
  11. \begin{abstract}
  12. Bienvenidos al PDF más absurdo que has leído en los últimos 20 años
  13. \end{abstract}
  14.  
  15. \section{Esto es un delimitador de sección como otro cualquiera}
  16.  
  17. Aquí podemos escribir todo el texto que queramos. Blablabla ...
  18.  
  19. \begin{enumerate}
  20. \item Número 1
  21. \item Número 2
  22. \end{enumerate}
  23.  
  24. \section{Es posible emplear fórmulas matemáticas}
  25.  
  26. Por ejemplo, una integral:
  27.  
  28. $$ \gamma = \int_0^1 \frac{x}{2+5x^4} dx $$
  29.  
  30. También podemos escribir una matriz de datos:
  31.  
  32. \begin{eqnarray}
  33. V = \frac{4 \pi r^3}{3}
  34. \end{eqnarray}
  35.  
  36. \section{... y enlaces bibliográficos}
  37.  
  38. \begin{thebibliography}{9}
  39. \bibitem[Welsh y Kauffman, 1995]{Welsh:1995} Welsh, Matt y Lar Kauffman. \textsl{Running Linux}, O' Reilly \& Associates, Inc. Sebastopol, CA, 1995.
  40. \end{thebibliography}
  41.  
  42. \section{Y con esto y un bizcocho ...}
  43.  
  44. Hasta mañana a las 8
  45.  
  46. \end{document}
  47.  
  48.  

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

Un saludo,

Switch to our mobile site