Entradas

Mi experiencia como ponente en CyberCamp18

Aunque el año 2.007 fue un “no parar” en cuanto a esto de dar charlas y talleres tras ganar la Imagine Cup de Microsoft, desde entonces no había tenido la oportunidad de volver a subirme en un escenario para contar cosas.

En estos últimos años, entre formación, autoempleo, autoría de libros, desarrollo de ideas, docencia, consultoría, … y ser padre, se me complicó un poco sacar tiempo.

Sin embargo, tras cumplir el sueño de ser profesor, me apetecía mucho volver a tener los nervios de dar una charla, de dedicar tiempo a montar un taller en el que contar cosas que hago y he ido aprendiendo con la experiencia.

Sin embargo, meter la cabeza en un congreso no es nada sencillo. Hay que apuntarse al CFP (Call For Papers) y enviar lo que tienes en mente. Detallar en qué va a consistir, de qué vas a hablar y tratar de convencer a la organización del evento de que tu propuesta puede aportar valor a la audiencia.

Para que te hagas una idea, me he presentado a 8 congresos antes de conseguir que me aceptaran la primera ponencia. Mi “rebautismo” dando charlas ha sido el evento CyberCamp18.

En esta ocasión lancé un órdago al CFP y me presenté a las tres categorías posibles:

  • Ponencia tecnológica: propuse hablar de mi proyecto personal DefenderEye. Quería contar los motivos que me hicieron desarrollar la herramienta, para qué sirve y mostrar desde dentro cómo funciona (detallando código, infra, …).
  • Charla motivacional: propuse una charla en la que contar cómo iniciarse en el mundo de la seguridad, la formación disponible, certificaciones, tipos de perfiles laborales y, sobre todo, consejos basados en mi experiencia como gestor de equipos de seguridad y mi relación con RRHH en cuanto a búsqueda de perfiles. Todo, desde un punto de vista de mucho humor.
  • Taller técnico: propuse un taller en el que describir los principales servicios de AWS junto con las “best practices”a tener en cuenta para tener lo más seguro posible nuestro entorno.

Tras semanas de espera, me llegaron tres correos a la vez en la que se me comunicaba que no había sido elegido para las dos primeras opciones. Cuando abrí el tercero ya estaba resignado a que, un año más, no había conseguido el objetivo.

Sin embargo, en esta ocasión, el texto era diferente:

Una vez superada la emoción inicial, vienen los nervios… ¿soy capaz de estar dos horas hablando? ¿Me quedaré corto? ¿Me pasaré de tiempo?

Inicialmente hice una lista de todo lo que consideraba que debía contar, el cálculo de tiempo me daba… casi cinco horas. Mal empezamos…

Tras refinar, quitar y pulir temario, lo dejé en tres horas. Seguía sin valer.

Finalmente, tras muchas revisiones y el doloroso proceso de quitar cosas que sientes que tendrían que estar, conseguí clavar las 2 horas oficiales.

El resultado lo tenéis aquí, espero que os guste!

¿Y la experiencia, qué tal? Pues la verdad es que estupenda. La sensación de volver a subirme a un escenario y de tener de nuevo a un grupo de personas con ganas de escuchar lo que vienes a contar es realmente maravillosa.

No puedo más que dar las gracias al público que asistió al taller, todos mostraron interés en lo que le estaba contando y me lanzaron preguntas que denotaban que les estaba aportando valor, así que considero el objetivo cumplido.

Por otra parte, la organización de Incibe se portaron de 10. Trato amable, preocupación en todo momento por lo que pudiera necesitar y siempre con una gran sonrisa. Se nota que hablamos de un evento organizado desde la ilusión y las ganas de hacer algo interesante.

Sin mucho más que contar, me despido. Por mi parte, trataré de estar en CyberCamp19 y volver a formar parte de un evento tan importante como este.

Saludos!

security-monkey-netflix

Security Monkey: Controla la seguridad de AWS con Netflix (parte 1)

Supongo que todos conocéis Netflix a estas alturas, el servicio VOD con suscripción mensual que aterrizó en España hace unos meses y ya es todo un éxito.

Pero, además de ser una forma estupenda de ver películas y series, puede ofrecernos mucho que aprender gracias a lo que algunos (yo no :D) llaman pornografía tecnológica.

Netflix es una de esas empresas que se rodea de los mejores ingenieros para poder ofrecer un servicio con calidad por encima de lo normal. En ese sentido, leer de forma regular “The Netflix Tech Blog” es altamente recomendable.

 

Aprendiendo de los mejores

Que profesionales tan altamente cualificados como los que trabajan en Neflix dediquen una parte de su tiempo a contarnos cómo hacen las cosas, es algo de agradecer. Vivimos en un mundo en el que estamos obligados a aprender de forma contínua y este tipo de lecturas nos abren la mente a nuevas formas de hacer las cosas.

Puedes encontrar temas tan interesantes como:

Y sobre todo, en general de elementos de Amazon WS (unos servicios con los que suelo trabajar tal y como os conté en Controla lo que hacen tus usuarios con Amazon WS IAM (parte 1) y Controla lo que hacen tus usuarios con Amazon WS IAM (parte 2)).

aws-summit-1

 

Security Monkey

Revisando esto, me he encontrado con una solución desarrollada por el equipo Netflix que tiene por objetivo monitorizar y analizar la seguridad de los servicios de AWS.

Se trata de un desarrollo propio que ofrecen como open source y que nos permite monitorizar la configuración de los servicios EC2, RDS, S3 e IAM. Cualquier cambio que se realice sobre ellos quedará registrado para que tengamos el control de todo lo que sucede.

Está pensada para correr sobre una máquina Linux y almacenar la información en una PostgreSQL. A nivel tecnológico está escrita en Python utilizando el framework Flask, utilizando datos JSON servidos mediante una API REST.

Casos de uso típicos serían:

  • Visualización de cambios históricos de un elemento (como los cambios en grupos de seguridad).
  • Auditorías de configuraciones incorrectas (como permisos en buckets S3).

Para conseguir esto, Security Monkey cuenta con tres componentes principales:

  • Watcher, es el encargado de observar nuestra cuenta para detectar cambios. Cuando eso ocurre, se almacena esa información en la base de datos interna.
  • Notifier, es el encargado de avisarnos cuando se produce un evento que podemos personalizar.
  • Auditor, es el encargado de realizar pruebas y revisiones sobre los elementos, reglas y políticas. Podemos definir aquello que no queremos que ocurra para que salte una alarma si se encuentra (como grupos de seguridad con puertos abiertos al mundo).

Una vez lo tengamos funcionando podremos acceder mediante su interfaz web, configurar los elementos que queremos monitorizar y ver todo en detalle.

 

¿Te ha gustado tanto como a mi? Entonces descarga el proyecto desde su repositorio y coméntanos qué tal tu experiencia. Yo lo haré en un post en el que os mostraré el proceso de instalación, configuración y uso. De momento, esto es todo, espero que os esté resultando interesante.

Como siempre digo, si ves algún error, no estás de acuerdo con lo que cuento o quieres hacer alguna aportación, no dudes en pasarte por los comentarios.

Controla lo que hacen tus usuarios con Amazon WS IAM (parte 2)

En la primera parte de esta serie de post relativos a la gestión de usuarios (IAM) en Amazon WS, estuvimos conversando sobre la forma en la que conceder permisos de forma ordenada y sencilla, así como algunos consejos para tener el control de todo lo que ocurre. Si no lo recuerdas, no dudes en echarle un vistazo antes de seguir.

Algo realmente importante en este panel IAM es el control sobre la cuenta root. No se aconseja utilizar dicha cuenta y Amazon nos anima en el panel de control a activar autenticación multifactor (MFA).

aws-iam-2-1

Panel de control de Amazon WS IAM

 

Como se puede ver en este ejemplo, uno de los checks importantes de seguridad es activar ese MFA. El motivo es sencillo, añadir una capa extra de seguridad al acceso con el usuario que tiene capacidad para hacer cualquier cosa, incluso eliminar la propia cuenta.

De esta forma, para entrar como root, se necesitará la contraseña (algo que el usuario sabe) y otro elemento que ahora veremos (algo que el usuario tiene). En mi caso, ese elemento es un código temporal que puede ser gestionado de diferentes formas:

aws-iam-2-2

Opciones MFA en Amazon WS

 

Básicamente, podemos optar por soluciones software o hardware. En mi caso particular, estoy utilizando la primera mediante apps para móviles. ¿El motivo? Hoy en día todo el mundo tiene smartphone, todos lo llevan siempre a mano y casi todos (en esto parece que la concienciación ha servido) tienen un patrón de bloqueo. Esto hace que “lo que el usuario tiene” esté mejor controlado que un dispositivo o tarjeta que sólo usa para acceso puntual.

De esta forma, si alguien pierde el teléfono puede avisar de inmediato para que su usuario sea puesto en cuarentena hasta que se renueven tanto la contraseña como el sistema mfa.

Las opciones de apps son estas:

aws-iam-2-3

Apps MFA para móviles

 

Por utilizar siempre la misma, recomiendo Google Authenticator para Android o iOS. Sólo tenemos que acceder a la pestaña “Security Credentials” del usuario y pulsar sobre la opción “Manage MFA Device”.

aws-iam-2-4

 

Al seleccionarlo, se inicia el proceso. En nuestro caso, seleccionamos dispositivo virtual (app para móvil):

aws-iam-2-5

 

Únicamente tendríamos que arrancar la aplicación y escanear el qr que aparece en pantalla. Tras hacerlo, se nos piden dos códigos consecutivos para comprobar que todo funciona correctamente y listo.

aws-iam-2-6

 

La próxima vez que entremos en el panel de control de Amazon WS con este usuario, se nos pedirá un código que podremos consultar en nuestra app.

aws-iam-2-7

 

De esta forma, los pasos recomendables para la gestión de usuarios en Amazon WS IAM se podrían resumir en:

  1. Desde la cuenta root, crear un usuario para administración.
  2. Activar MFA en root y admin.
  3. Desde admin, gestionar usuarios, grupos y políticas.

Por supuesto, recuerda que el MFA también puede ser activado para el resto de usuarios. Al principio se mostrarán reticentes a utilizarlo, pero ya sabes que concienciar y hacer entender que ciertas medidas son necesarias para tratar de asegurar los activos de la empresa es parte fundamental de nuestro trabajo.

 

De momento, esto es todo, espero que os esté resultando interesante. Como siempre digo, si ves algún error, no estás de acuerdo con lo que cuento o quieres hacer alguna aportación, no dudes en pasarte por los comentarios.

Controla lo que hacen tus usuarios con Amazon WS IAM (parte 1)

En proyectos pasados y actuales he tenido que lidiar con los servicios cloud de Amazon, los conocidos como Amazon Web Services. Para los que no los conozcan, son un conjunto de servicios de computación, almacenamiento, base de datos, redes, análisis… que permiten montar infraestructuras complejas, eficientes y escalablas a precios muy competitivos (se paga por uso).

En un principio me tocó montar la red, servidores, servicios y bases de datos. Ahora ando desde otro punto de vista, el de tratar de asegurar la infraestructura para que la continuidad de negocio de mi trabajo actual no se vea comprometida. La puerta de entrada son los usuarios y de eso vamos a hablar hoy.

 

Entendiendo Amazon WS IAM

Para gestionar el acceso a los recursos, AWS cuenta con un servicio llamada IAM (Identity & Access Management) que permite gestionar el acceso a los recursos en base a diferentes identidades:

Usuarios: es una entidad individual, una persona que utiliza recursos. Cuando creamos un usuario, le podemos dar acceso a la consola de administración o a la api para que pueda interactuar con aquello que deseemos de AWS mediante políticas de uso.

Grupos: se utilizan para agrupar usuarios que tienen características similares y, por tanto, permisos similares. Normalmente se usan para crear departamentos en los que todos los usuarios tienen que tener acceso a los mismo recursos. Editar, añadir o eliminar una política al grupo, afecta inmediatamente a todos los usuarios del mismo.

Roles: son parecidos a los usuarios, pero de forma inpersonal. Son permisos que se conceden para llevar a cabo determinadas tareas puntuales. Se suelen usar para asignar a máquinas o procesos que se lanzan de forma automática o incluso aquellas que se lanzan de forma manual sin importar el usuario que lo hace (no es el usuario el que tiene los premisos, es el popio proceso).

 

¿Cómo indico qué se puede o no hacer?

Para eso están las policies, que son reglas que se aplican para cada servicio y que pueden contener todo tipo de detalle para hacerlas completamente a medida. Una policy tiene un aspecto similar a esto:

Tener cierto control y destreza a la hora de escribir estas policies es complicado, por eso Amazon nos pone a mano dos recursos interesantes:

  • AWS Policy Generator: una web en la que podemos ver todas las opciones que hay para cada servicio e incluso generar el fichero para hacer copy-paste.
aws-policy-generator

Web para generar policies de AWS.

 

  • Herramienta interna de simulación: desde la consola de administración de IAM podemos hacer una simulación de la policy que realizará una prueba sobre los recursos y acciones que definamos.
aws-simulate-policy1

Enlace para simular policy concreta

 

aws-simulate-policy2

Pantalla del simulador de policies

 

Asignación de policies

A la hora de aplicarlas sobre un usuario o grupo, podemos optar por hacerlo de dos formas:

  • Managed: podemos verlo como un policies que tenemos almacenadas y que asignamos con intención de que sea algo permanente (aunque, por supuesto, podemos revocar en cualquier momento).
  • Inline: es algo así como permisos temporales que se asignan con la intención de que sea algo puntual, ya sea por la persona o grupo que lo recibe o por el tipo de permiso que se concede.

 

¿Vemos un ejemplo?

Con todo esto, una posible situación sería asignar grupos por departamento y entorno de desarrollo, asignando las policies necesarias para cada zona concreta. Por ejemplo:

  • Departamento1-DEV: policies para usuarios del departamento1 con acceso a recursos de desarrollo.
  • Departamento1-PRE: policies para usuarios del departamento1 con acceso a recursos de preproducción.
  • Departamento1-PRO: policies para usuarios del departamento1 con acceso a recursos de producción.

Puesto que un usuario puede pertenecer a varios grupos, no habría problema en asignar a “Usuario1” a los grupos “DEV” y “PRE” del “Departamento1”.

 

Control casero

Cuando todo esto empieza a crecer, utilizo un pequeño script que me lista todos los usuarios, así como las políticas que tiene asignadas como grupo o individualmente. Me sirve para exportar rápidamente esa información y poder ver en papel la foto actual de los permisos. Si utilizas la consola, tienes que entrar uno a uno y es un poco coñazo.

Lo único que hago es tirar consultas sobre la API para mostrar, de forma ordenada, la información que necesito.

Me gustaría trabajar en ampliar este script para que sea capaz de avisarme de cambios tanto en policies como en el contenido de las mismas, de forma que si un usuario “obtiene cambios fuera de control”, pueda enterarme lo antes posible.

El resultado de este código es algo así:

aws-policy-script

Resultados del primer usuario

Lo que podéis ver aquí es el modo paso a paso (step = True) con los resultados del primer usuario (el nombre es lo que hay borrado junto a [**]). Se ve rápidamente que no tiene policies de tipo inline o managed y que, todo lo que tiene, le llega por pertenecer a dos grupos del mismo departamento y diferente entorno (DEV y PRE). Las policies asociadas a cada grupo aparecen a la derecha del mismo.

Como véis, un script muy sencillo, pero que me permite exportar rápidamente la información que necesito para verificar si algún usuario tiene permisos que no debe o pertenece a algún grupo equivocado.

 

De momento, esto es todo, en la continuación de esta entrada hablaremos del usuario root y de la autenticación con segundo factor. Espero que os esté resultando interesante y, como siempre digo, si ves algún error, no estás de acuerdo con lo que cuento o quieres hacer alguna aportación, no dudes en pasarte por los comentarios.