Archivo de la etiqueta: podcast

Podcast – 35 – SIEM

Podcast – 35 – SIEM

 
 
00:00 / 17:50
 
1X
 
Logo SIEM

SIEM
Fuente imagen: Gigaom

Hoy hablaremos de los SIEM (Security Information and Event Management). Estos sistemas surgen de la combinación de dos tareas, que inicialmente realizaban productos específicos: SIM (Security Information Management) y SEM (Security Event Management). Si bien cada una de estas funciones puede ser independiente de la anterior, la verdad es que para gestionar un evento necesitas tener información, así que los desarrolladores, sobretodo los de soluciones propietarias, han tendido a fusionar las dos tareas en un único sistema. En este capítulo no haremos diferencia entre funciones, sino que explicaremos el funcionamiento global de un sistema SIEM.

Los SIEM son probablemente una de las herramientas más difíciles de ajustar y que genera un mayor trabajo de gestión, muchas veces repetitivo, por lo que es muy importante que se tengan en cuenta en cualquier proyecto de implantación de un SIEM: se requiere mucho trabajo de ajuste del sistema para que el análisis de la información sea correcto y las alarmas generadas sean válidas e interesantes. Así cómo otros sistemas de protección, como los antivirus o sistemas anti-spam, pueden dejarse en modo automático, los SIEM deben ser gestionados, analizados y ajustados por técnicos especialistas si se quiere obtener resultados tangibles. Por este motivo no es extraño que muchas empresas prefieran contratar un SOC externo que gestione el SIEM con sus alarmas.

Veamos todos los pasos necesarios para obtener información, analizarla y obtener las alertas oportunas:

1. Recopilación de logs

El primer punto para un sistema de gestión de información es, precisamente recoger esa información. Aquí tenemos dos opciones para obtener los logs: la primera opción es que los sistemas que queremos analizar envíen una copia de sus logs a nuestro sistema SIEM; y la segunda sería que el sistema SIEM haga peticiones periódicas a los sistemas a controlar. Para el intercambio de información podemos utilizar protocolos estándares, como Syslog o SNMP, o bien la conexión con agentes instalados en los servidores a controlar. Lo más probable es que, debido a los entorno heterogéneos de cualquier empresa mediana, el sistema SIEM utilice una combinación de todas las opciones para recoger el máximo de información posible.

1.a Normalización de logs

Micro con feed

Fuente imagen:PerfectYourPodcast

Al integrar información de diferentes fuentes debemos asegurarnos que guarden un formato común para poder hacer el análisis posterior. Cada fabricante decide cómo generar los registros de eventos de su plataforma y puede decidir cambiar el formato de logs entre diferentes productos o, incluso, entre versiones de un mismo sistema. Quizás el ejemplo más visual sea el formato de fecha de cuándo sucedió un evento: el formato estadounidense o el español son diferentes (p.e. el orden del número de día o mes cambia), también puede cambiar el texto si el idioma del sistema operativo es diferente (aunque sea lo mismo no queda el mismo registro un lunes que un Monday). Igualmente importante es que todos los equipos tengan sus relojes sincronizados para que el SIEM pueda conocer el orden cronológico de los eventos: para ello se suele utilizar un servidor NTP centralizado.

2. Almacenamiento de logs

En este punto más que el propio formato de almacenamiento de los registros, la principal característica técnica a tener en cuenta es la información extra que añade el sistema para permitir un tratamiento posterior más eficiente. El marcado, etiquetado, categorización, o cualquier otro nombre que los comerciales quieran dar, debe permitir la selección de registros para su posterior correlación. Como suele sucede no existe un único tipo ni un sistema estandarizado de elegir qué y cómo almacenar los registros y todo tiene sus ventajas e inconvenientes.

Otro punto a tratar en este punto es qué logs de eventos queremos almacenar: la primera aproximación suele ser que queremos guardar todo, pero el gran tamaño de almacenamiento (que cuesta dinero) y la gran carga de trabajo de revisión, pronto llevan a cambiar de estrategia para buscar un equilibrio entre el todo, la nada y lo que podemos gestionar.

3. Correlación de logs

La correlación automática de los registros de eventos es, precisamente, la parte fundamental y el motivo de la existencia de estos sistemas. Diferentes algoritmos rastrean los eventos almacenados en busca de patrones que les permitan detectar un comportamiento anómalo que genere un evento de seguridad a estudiar. Este rastreo sistemático y pormenorizado de los eventos almacenados permite una detección de patrones muy superior a la de la intuición humana, por lo que estas herramientas son imprescindibles para un departamento de seguridad y, justifican su obligatoriedad de uso en algunas normativas.

Si bien muchos comerciales hablarán aquí de machine-learning, deep learning, inteligencia artificial, e incluso de deep-IA-learning o cualquier otro nombre marketiniano: la realidad es que se necesita de un sistema que en base a múltiples registros que provienen de diferentes fuentes, que en principio no están correlacionadas, se encuentren patrones de acciones no habituales que deban ser analizados por un especialista.

Estos eventos pueden ser tan simples como detectar que un usuario de VPN se conecta desde una ubicación no habitual (p.e. si yo, que vivo en Mallorca me conecto desde casa y al cabo de dos horas lo hago desde Singapur es probable que algo no cuadre) o el movimiento de ficheros entre servidores en horario nocturno; o bien procesos tan elaborados como detectar un APT en base a comunicaciones entre servidores. Las posibilidades de detección varían mucho en función del sistema SIEM utilizado y, sobre todo, de la cantidad de logs almacenados y correlacionados.

4. Gestión de alarmas

El resultado esperado de un sistema de gestión de información y eventos de seguridad es que tras todo el sistema acaben dando como resultado una serie de alarmas, con la mayor cantidad de información posible, que un especialista deba revisar. La gestión de una alarma de seguridad debería seguir el mismo procedimiento que la gestión de incidencias de IT de la empresa: todo debe quedar registrado en el sistema de gestión de incidencias y debe tratarse de la misma forma.

Hay que tener presente que los responsables de tratar con las incidencias de seguridad deben tener unos conocimientos amplios de muchas ramas de los sistemas IT (bases de datos, redes, sistemas operativos, etc.) para poder gestionar de forma eficiente la gran variedad de eventos que surgirán.

Un tema a tener en cuenta es que, al menos, durante los primeros meses de funcionamiento de un sistema SIEM, se generarán múltiples incidencias que resultarán ser falsos positivos por lo que los administradores del sistema deben retroalimentar correctamente al producto para que aprenda que situaciones pueden ser consideradas normales. No es extraño que los primeros meses de trabajo con un SIEM los responsables consideren que no sirve para nada ya que “pierden” la mayoría del tiempo persiguiendo falsos positivos. La gran ventaja del SIEM aparecerá una vez que ya esté estable y con una cantidad de información suficiente para tener un conocimiento del comportamiento habitual de nuestra empresa.

Y hasta aquí una explicación rápida de las partes y el funcionamiento técnico de un SIEM, así pues si pensáis implementarlo en vuestro negocio debéis tener en cuenta que los principios son duros ya que es una herramienta que precisa de administradores casi en exclusiva y con amplios conocimientos.

Además, es un sistema que debe ser gestionado y adaptado cada vez que la empresa lo necesite: por ejemplo, si nuestra empresa abre una nueva tienda en Noruega, el SIEM empezará a detectar conexiones a los sistemas corporativos desde direcciones noruegas o nuevos archivos almacenados con idioma noruego: es muy probable que este comportamiento genere eventos de seguridad que deberán ser catalogados correctamente en el sistema. Igualmente si se cierra la sede de Japón, habrá que avisar al sistema de que ya no deberían aparecer conexiones desde ese país y que no aparecerán textos kanji en nuestros sistemas.

Por todo esto no es nada raro que una empresa que deba tener un SIEM por normativa subcontrate los servicios a un tercero. Estos servicios SOC, que permiten cumplir con la legislación y traspasar los riesgos a un tercero, pueden realizar un buen papel para la detección de conductas generales pero adolecen de la capacidad de adaptación al negocio que tendría un equipo interno. Pero claro, aquí ya hay que valorar necesidades, capacidades y costos.


Si queréis proponerme algún tema del que hablar, felicitarme o echarme una bronca podéis hacerlo en Twitter (@Securizando_), por correo electrónico, en el contacto del blog o bien pasaros por el grupo de Telegram.

Y esto es todo por hoy, ¡hasta la próxima!

Podcast – 34 – Port Knocking

Podcast – 34 – Port Knocking

 
 
00:00 /
 
1X
 

Hoy hablaremos sobre una técnica de ‘seguridad por oscuridad’: el Port Knocking. Podéis encontrar una entrada en la Wikipedia española con el nombre de “Golpeo de puertos”. Ciertamente es una traducción literal de la expresión inglesa y es el único sitio donde la he visto, por lo que si me lo permitís me quedaré con Port Knocking.

Micro con feed

Fuente imagen:PerfectYourPodcast

Según algunas fuentes esta técnica apareció por primera vez en 2003 en un artículo de la revista “SysAdmin Magazine” como un mecanismo de autenticación ante un cortafuegos. La idea es permitir el acceso a un servicio a través de un firewall que tiene los puertos cerrados por defecto.

Recordemos que los firewall tradicionales permiten o deniegan el tráfico en función de las direcciones IP origen/destino y de los puertos usados.

La idea básica del Port Knocking es simple: el cliente realiza una serie de intentos de conexión a una secuencia de puertos concreta. Si esta secuencia es correcta, el firewall habilitará el acceso al puerto para acceder al servicio protegido. Así pues, la “contraseña de acceso” al servicio sería la secuencia de puertos que debe ejecutarse antes de conectar con el servicio protegido.

Port Knoking

Ejemplo de Port Knocking. Fuente imagen: CyberVault

Veamos el ejemplo más sencillo de esta técnica: Supongamos que tenemos una página web oculta mediante esta técnica. Para acceder a esa página primero hay que ‘tocar’ los puertos 55, 34034 y 24124.

  1. Cuando cualquier usuario quiera conectar al servidor web protegido el firewall denegará la conexión como si no existiera ningún servicio web operativo. Así se consigue ocultar el servicio de miradas ajenas.
  2. Cuando queremos acceder a nuestra web oculta lanzamos tres peticiones de conexión TCP en el orden correcto: a cada petición recibiremos respuesta de que el puerto está cerrado (igual que recibiría cualquier intento de acceso a un puerto cerrado). Es decir, el Port Knocking no daría pistas de su existencia.
  3. Una vez realizada la secuencia en el orden correcto, en nuestra cuarta conexión accederíamos a nuestra página web y el firewall nos permitiría el paso. A partir de ese momento podemos trabajar con neustra web oculta sin problemas.

Así pues, la clave para acceder al servicio oculto es la secuencia exacta de peticiones que debemos realizar antes de acceder a la web.

Obviamente una vez abierto el acceso, el propio servicio puede (y debe) tener sus propias medidas de seguridad. El Port Knocking dificulta el descubrimiento del servicio, pero en su versión más sencilla (que es la que hemos explicado) no protege al propio servicio. En nuestro ejemplo una vez revelado un servicio web, la propia aplicación web debería tener un control de acceso, por ejemplo, con usuario/contraseña.

Esta técnica puede ser útil para proteger un servicio de miradas indiscretas, pero dónde no podemos saber con antelación desde dónde se conectarán nuestros clientes (servicios en itinerancia, redes móviles, direccionamiento IP dinámico etc.). Si nuestros clientes siempre tienen la misma IP es más sencillo configurar el firewall para que habilite el acceso normal únicamente a una serie de direcciones específicas y bloquee el del resto del mundo.

El principal problema de este modelo más sencillo de Port Knocking es que es débil frente ataques de repetición: si un atacante consigue capturar el tráfico de red (o los logs del propio firewall) podrá darse cuenta de esta secuencia repetida aparentemente sin sentido y averiguar la existencia del servicio secreto simplemente enviando la misma secuencia de peticiones. Una manera de dificultar esta detección sería el uso de puertos comúnmente comprobados por escaneadores de vulnerabilidades, aunque, obviamente, en una secuencia distinta a la habitual: a nadie extraña ver intentos de peticiones a puertos comunes (SMTP, FTP, telnet, ssh, etc.) por lo que se dificultaría que, entre todas las peticiones que hay en cualquier firewall, se detectase el patrón de acceso.

Otras técnicas para evitar los ataques de repetición implican el conocimiento de una clave previa:

  1. Codificaremos la información de nuestra dirección IP origen y el puerto destino al que queremos acceder (donde está el servicio oculto). Por ejemplo: IPPUERTO = 6 bytes.
  2. Ciframos esta cadena de caracteres con la clave adecuada
  3. Cogemos el valor del cifrado y lo separamos en bytes. Cada byte puede tener un valor entre 0 y 255. Así obtenemos una secuencia de valores del 0 al 255
  4. Sumamos a estos valores obtenidos un valor base (por ejemplo 23000). Y enviamos una conexión nueva al puerto resultante de esta operación.
  5. El firewall que recibe las peticiones puede restar el valor base (conocido de antemano) y obtener así los valores de bytes resultantes del cifrado
  6. Como el firewall conoce la clave de cifrado puede obtener el mensaje inicial y así puede abrir el acceso desde la IP origen al puerto solicitado.

Este sistema tiene la ventaja que ante un ataque de repetición (donde se enviasen los mismos paquetes) simplemente se abriría el firewall para la IP origen cifrada en el paquete y no para la IP del atacante. La elección de un valor base al que sumar a los puertos puede ser fija o realizarse de forma dinámica (en función de la hora, día del mes, etc.) permitiendo así dificultar los ataques de repetición y generar una alerta en el sistema en caso de detectar intentos de conexiones en puertos no adecuados a la franja temporal).

Una funcionalidad de este sistema es que permite abrir accesos a diferentes servicios sin cambiar el esquema, o bien incluso enviar los mensajes de Port Knocking desde direcciones IP diferentes a las que se usarán después para conectar al servicio protegido.

Un caso de control de acceso, que de forma irónica se incluye en la categoría de Port Knocking, son los sistemas Single Packet Authorization: es decir autenticación en un único paquete. A modo resumen se enviaría en un único paquete toda la información de IP origen y servicio al que se quiere acceder de forma cifrada en un único paquete. El firewall lo interpretaría y actuaría en consecuencia. Con este esquema se dificulta en gran medida la detección del sistema de ocultación, si bien al enviar un único paquete no parece que caiga en la categoría de Port Knocking 😉

Este método de protección, aunque parece sacado de una película de espías, podría ser una capa de seguridad adicional útil en algunas ocasiones. No es una configuración habitual en empresas (al menos no en las no tecnológicas), pero puede ser interesante que busquéis este tipo de patrones en los logs de firewall con las herramientas SIEM… quizás os llevéis alguna sorpresa.

Podcast – 34 – Port Knocking

Podcast – 33 – OWASP

Podcast – 33 – OWASP

 
 
00:00 /
 
1X
 

El tema del capítulo de hoy fue sugerido por nuestro compañero del grupo de Telegram Fran Andrades (@andradesfran en Twiter). Así que, a petición de los oyentes (al menos de uno), hoy hablaremos de OWASP.

OWASP logo

Logo OWASP. Fuente iamgen: OWASP.org

Empecemos por lo primero: OWASP son las siglas de Open Web Application Security Project, que se traduciría como Proyecto abierto de seguridad en aplicaciones web. Nació en 2001 y su misión es combatir las causas que hacen que el software sea inseguro. Para gestionar este proyecto se creó, ya en 2004, una entidad sin ánimo de lucro: la Fundación OWASP. Si bien dicha fundación es la responsable legal de la gestión del proyecto y de la infraestructura (tanto técnica como humana) necesaria para su funcionamiento, el trabajo es realizado por una comunidad de usuarios, organizaciones educativas y empresas que se coordinan en la denominada Comunidad OWASP.

Así pues, la Comunidad OWASP crea, adapta y traduce documentación, guías y consejos sobre el desarrollo de software seguro, que es la razón de ser del Proyecto, mientras que la Fundación se encarga de gestionar los trabajos administrativos y de infraestructura que permiten que todo funcione. Espero haber aclarado un poco qué hace quién 🙂

Los cuatro pilares del proyecto OWASP son:

  • Abierto: Todo el resultado de la gestión es público
  • Innovación: Se promulga la innovación y experimentación para buscar nuevas soluciones a los problemas del desarrollo seguro
  • Global: Cualquier persona puede participar
  • Integridad: La comunidad OWASP está formada por un gran número de personas y siempre propone soluciones independientes a cualquier fabricante garantizando así su independencia

OWASP busca como objetivo final el desarrollo seguro de aplicaciones, para lo cual desarrolla diferentes proyectos que buscan conseguir la seguridad en diferentes aspectos del desarrollo de aplicaciones web. Se han creado herramientas software que permiten detectar vulnerabilidades en el propio código (como WebScarab, DotNet…), guías sobre cómo programar de forma segura y que comprobaciones hacer; se han creado plataformas de formación (como webGoat), pero el proyecto más conocido de OWASP es Top10: el documento donde se identifican y explican las 10 vulnerabilidades más críticas en las aplicaciones web.

El documento OWASP Top10, que nació en 2003, se actualiza y presenta cada 3 años. Top10 se ha convertido en un estándar de facto utilizado por los desarrolladores para determinar y combatir las causas del software inseguro.

Micro con feed

Fuente imagen:PerfectYourPodcast

Si bien las primeras versiones se daba prioridad a la prevalencia de las vulnerabilidades en 2010 se cambió el enfoque hacia la gestión de riesgos. La última actualización de Top10 aparece en 2017 y no en 2016 como era de esperar ya que se decidió realizar un cambio profundo en los procedimientos de elaboración de dicho documento y en la forma de recolectar la información de múltiples fuentes (voluntarios, empresas, entidades de seguridad oficiales…). Igualmente se ha cambiado el método de clasificación de las vulnerabilidades, por lo que no todas las categorías coinciden con la de los años anteriores.

Veamos pues un resumen del listado de las 10 vulnerabilidades más críticas en las aplicaciones web:

  1. En primera posición desde 2010 (en 2007 estaba en segunda posición) se encuentra la vulnerabilidades por inyección de comandos. En los capítulos decimoséptimo y decimoctavo ya hablamos sobre las inyecciones SQL, si bien esta categoría no se limita únicamente a este lenguaje. La vulnerabilidad aparece cuando no se analiza correctamente la información recibida por la aplicación y permite la ejecución de código no deseado.

  2. Las implementaciones incorrectas o incompletas de las funciones de autenticación y gestión de sesiones son las causantes de que en segundo lugar del Top10 tengamos la categoría Pérdida de autenticación. En este caso el riesgo principal es la suplantación de identidad de otro usuario al comprometerse contraseñas, tokens de usuarios o sistemas de recuperación de sesiones.

  3. Si bien en el documento de 2013 la Exposición de datos sensibles se encontraba en sexta posición en la última versión sube hasta la tercera. La gran difusión de aplicaciones web que hacen uso de datos sensibles, hace que la no protección adecuada de esta información se convierta en uno de los riesgos más críticos. Los sistemas web deben asegurar que esta información sensible esté siempre cifrada tanto en almacenamiento como en transmisión.

  4. En cuarta posición aparece una nueva vulnerabilidad: La gestión de Entidades Externas XML. Al parecer mucho procesadores XML antiguos permiten, de forma predeterminada, la llamada a funciones externas, así un atacante malicioso sólo debe enviar un fichero XML que haga referencia a una URL maliciosa para conseguir su ejecución en el servidor.

  5. La categoría de Pérdida de control de acceso incluye todas las ocasiones en las que las restricciones a los usuarios autenticados no se aplican correctamente. Así un usuario podría llegar a ver o modificar información de otros, cambiar permisos de accesos, etc. Si en la posición dos nos centrábamos en debilidades en el acceso al sistema, aquí estaríamos hablando de las funcionalidades disponibles dentro del sistema.

  6. Las aplicaciones web pueden ser vulnerables no por fallos en la programación sino por una Configuración de seguridad incorrecta. La falta de securización de la infraestructura; la permanencia de servicios no necesarios; la no actualización de versiones de aplicaciones vulnerables; o no cambiar las contraseñas por defecto son ejemplos de vulnerabilidades dentro de esta categoría.

  7. En séptima posición nos encontramos las vulnerabilidades de Cross Site Scripting. Esto sucede cuando una aplicación toma datos no confiables y los entrega al navegador del usuario para que los ejecute. Así se permite la ejecución de comandos en el navegador de la víctima pudiendo modificar sitios web, redirigir al usuario a sitios maliciosos o secuestrar una sesión.

  8. Cuando una aplicación debe convertir diferentes objetos de un formato a otro (p.e. de XML a JSON), debe estar preparada para tratar correctamente objetos manipulados, desordenados o repetidos para evitar caer en la deserialización insegura. Este tipo de ataques suelen buscar una ejecución de código en el servidor o la elevación de privilegios.

  9. Teniendo en cuenta que muchos componentes (como bibliotecas, módulos o frameworks) se ejecutan con los mismos permisos que la aplicación a la que sirven, si estos elementos resultan ser vulnerables afectarán directamente a la seguridad de la aplicación. Así pues el uso de componentes con vulnerabilidades conocidas puede debilitar las defensas de las propias aplicaciones.

  10. En la posición 10 se propone una de las vulnerabilidades más comentadas: el registro y monitoreo insuficiente. Los últimos estudios demuestran que el tiempo de detección de una brecha de seguridad es de cerca de 200 días y que generalmente son detectados por terceros y no por los propios sistemas internos. Uno de los motivos de esta alta permanencia de los ataques es la falta de un registro de acciones completo y una revisión y monitorización insuficiente.

Logo TOP10

OWASP Top10 2017. Fuente imagen: Dragonjar

Tras repasar el nuevo Top10 se puede ver que los cambios en la metodología de trabajo y toma de decisiones ha llevado a situaciones no acostumbradas: Por ejemplo podemos ver en la cuarta posición una vulnerabilidad por el uso de procesadores XML antiguos o malconfigurados; mientras que la vulnerabilidad de uso de configuraciones de seguridad incorrectas (más genérica que la específica de XML) se encuentra en sexta posición. Aunque inicialmente puede chocar esta clasificación los autores proponen destacar específicamente la vulnerabilidad de procesadores XML mal configurados por su especial ocurrencia frente a otros sistemas mal configurados. Se busca así destacar un problema específico con la intención de que sea corregido más rápidamente que si simplemente estuviera englobado en la problemática más general.

Igualmente la introducción del monitoreo insuficiente como una vulnerabilidad del Top10, aunque en última posición, genera algunas dudas ya que puede deducirse que no es una vulnerabilidad de las aplicaciones web en sí, sino más bien del entorno de gestión y administración de sistemas.

Aún con todas estas dudas sobre categorías específicas, OWASP Top10 es un estándar de facto para que los desarrolladores de aplicaciones web puedan determinar y combatir las causas que hace que sus aplicaciones sean inseguras.

Si quieres participar en la Comunidad OWASP y ayudar en cualquiera de sus proyectos, sólo debes solicitar una cuenta en www.owasp.org. Si no eres un gran programador siempre puedes ayudar con traducciones, guías de estilo, revisiones de documentos, etc.

Podcast -33 – OWASP