aws-summit-madrid-16

SecurityInside en el AWS Summit de Madrid 2016

Tras la visita el año pasado al AWS Summit de Barcelona, en esta ocasión nos pillaba mucho más cerca. El AWS Summit de Madrid se celebró el pasado Jueves en cines Kinépolis con una gran participación de público y de empresas patrocinadoras.

Puesto que trabajo en un entorno compuesto principalmente por servicios cloud de Amazon WS, la visita a este tipo de eventos es totalmente recomendada. Ya sabéis que la filosofía de SecurityInside es no dejar nunca de aprender.

El evento

Tal y como os comenté en la entrada de la Rooted CON, el sitio es un acierto total. Parece que los grandes eventos se están poniendo de acuerdo en utilizar las instalaciones de Kinépolis y, para el asistente, es una gran noticia. No hay problema de aparcamiento, gran oferta de restaurantes, cafeterías, espacio para apagar fuegos en remoto… todo genial.

Para el que no lo tenga claro, el AWS Summit es un evento en el que los responsables de diferentes servicios de Amazon nos explican las novedades y casos prácticos para que podamos utilizarlos en nuestro día a día. Además, lo complementan con ejemplos reales de empresas que han tenido éxito utilizando los diferentes servicios que se ofrecen y que siguen creciendo año a año.

aws-summit-2

Las sesiones

Puesto que el pasado Summit fue hace relativamente poco tiempo, en esta ocasión no hubo demasiadas novedadas, pero sí ejemplos de uso que te hacen pensar y que posiblemente acaben en nuestros sistemas a corto plazo. Lo bueno de este tipo de eventos es que te dan ideas y soluciones en las que no habías caído.

En mi caso particular, la sesión más interesante fue la relativa a la gestión de seguridad. Un repaso completo a la forma en la que tener todo bajo control desde el minuto cero que se nos contó en primera persona por Bill Murray, Director of AWS Security Programs y por los diferentes partners del evento:

aws-summit-madrid-sponsors

Seguridad en Amazon WS

La infraestructura en la nube de Amazon WS está diseñada para ser uno de los entornos de informática en la nube más flexibles y seguros de los disponibles en la actualidad. Ofrece una plataforma extremadamente escalable y de alta fiabilidad para que los clientes puedan implementar aplicaciones y datos de forma rápida y segura.

Los centros de datos de AWS disponen de la máxima seguridad 24/7. Los sistemas ambientales de los centros están diseñados para minimizar el impacto de las interrupciones en las operaciones. La existencia de varias regiones geográficas disponibles hace que la información sobreviva a la mayoría de las averías, incluidas catástrofes naturales.

AWS establece exhaustivos sistemas de supervisión de seguridad y red, protegiendo frente a ataques DDoS y detección de ataques de fuerza bruta contra sistemas de contraseñas en las cuentas de AWS, poniendo a prueba la infraestructura constantemente, desde todos los ángulos posibles y desde diferentes regiones.

Además del amplio equipo de expertos, AWS cuenta con una gran variedad de herramientas y sistemas que automatizan muchas de las tareas de seguridad, desde la gestión de credenciales hasta la supervisión del uso del servidor y red. Los programas de análisis automatizados, por ejemplo, han reducido el tiempo de una evaluación de ingeniería de seguridad de horas a minutos e incrementando la velocidad de análisis de docenas de hosts al día a miles de hosts en el mismo tiempo.

La infraestructura de AWS es mejorada constantemente, sustituyendo el hardware que llega al final de su vida con procesadores más recientes, mejorando así el rendimiento e incorporando tecnologías de seguridad, buscando reducir al máximo las fricciones entre los procesos de seguridad y los servicios.

AWS construye sus centros en múltiples regiones geográficas y numerosas zonas de disponibilidad dentro de cada región. Esto es, las zonas de disponibilidad están físicamente aisladas en una región y ubicadas en zonas de menor riesgo. En caso de improbable fallo, los procesos automatizados pueden desviar el tráfico de datos del cliente de la zona afectada (si hacemos uso de la configuración multi AZ), equilibrando la carga de tráfico entre los demás sitios.

Para clientes obligados a cumplir con determinadas leyes o normas de seguridad, AWS proporciona informes de certificación que describen cómo su infraestructura en la nube cumple con los controles exigidos por estas normas. Cada certificación que AWS obtiene significa que un auditor ha verificado que están instaurados los controles específicos y que funcionan según lo previsto.

Para ayudar al mantenimiento de seguridad de datos y sistemas en la nube, AWS dispone de una amplia variedad de funcionalidades y servicios:

  • Seguridad de red: Provee de diferentes opciones de seguridad a nivel de red para mantener los recursos y comunicaciones con la privacidad deseada.
  • Control de acceso: Solo permite acceso a usuarios, clientes y aplicaciones autorizadas a los recursos AWS, estableciendo políticas de control de acceso, cuentas individuales de usuarios y credenciales únicas.
  • Monitorización y seguimiento: AWS ofrece herramientas para hacer seguimiento y monitorizar los recursos en la nube. Con ellas, hay inmediata visibilidad del inventario, así como sobre usuarios y actividades sobre la aplicación.
  • Copias de seguridad: Una estrategia de seguridad debe incluir backups o snapshots de los datos con regularidad. Por eso, AWS realiza backups automáticos y, en otros casos, es posible configurar snapshots usando las diferentes opciones de configuración.
  • Cifrado: AWS utiliza sistemas de cifrado siempre que sea posible y recomienda su uso. Permite el almacenamiento de datos cifrados, centralización de gestión de claves y almacenamiento en hardware cifrado dedicado.
  • Región aislada: Para clientes con necesidades adicionales por cumplimiento de regulación especial, AWS ofrece regiones aisladas llamadas GovCloud (US) con estrictos y únicos requerimientos de seguridad que permiten un entorno en el que lanzar aplicaciones ITAR.

Ya sabemos que nada es 100% seguro, pero Amazon WS hace un gran esfuerzo por mantener unos servicios con el máximo nivel de fortificación para que nuestra actividad pueda resistir los múltiples vectores de ataque a los que estamos expuestos.

Y tu, ¿utilizas Amazon WS? Recuerda que tienes un gran abanico de recursos gratuitos para empezar a familiarizarte con este ecosistema.

 

De momento, eso es todo. 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.

rooted_16

SecurityInside en la RootedCON 2016

De nuevo llegó el turno de la RootedCON, la Rooted a secas para los amigos. Un evento en el que hackers enseñan y aprenden, en el que profesionales se encuentran y cuentan batallas y, por qué no decirlo, un momento como otro cualquiera para abordar unas buenas burguers con los compañeros y amigos de SecurityInside.

rooted16-securityinside

Un año más, la RootedCON ha vuelto a dar lo mejor de sí. Uno de los eventos de seguridad más importantes e interesantes que, esta vez, ha cambiado de ubicación.

Personalmente estoy encantado con ciudad de la imagen, joder, ¡hay aparcamiento de sobra! Después de unos años en los que aparcar era una lotería y la mayoría optábamos por ir en tren, esta vez la cosa ha sido llegar y aparcar.

La ubicación nueva, además, tiene cerca una buena variedad de sitios donde comer sin tener que desplazarse tanto que tengas que perderte la primera charla de la tarde (algo habitual en las últimas ediciones).

Este año ha habido una buena variedad de temas, que han ido desde el muy presente IoT hasta las ondas cerebrales… una muestra de la reputación del evento, capaz de atraer a tanto y tan variado talento.

En cuanto la organización publique los vídeos de las charlas, actualizaremos esta entrada con la información. Mientras tanto, os dejamos una lista de los recursos que nos han parecido interesantes:

Cabe destacar un año más las tradicionales conchas y lanzamos una propuesta para el año que viene: Café, queremos café, necesitamos café, solicitamos insistentemente café. No es que las charlas sean aburridas (todo lo contrario), pero estar sentado, escuchando, en una sala de cine, a oscuras… entra mucho sueño y el tema café ha sido muy comentado este año.

rooted16-conchas

En cualquier caso, un año más de disfrutar y aprender. Ya estamos listos para la RootedCON 2017!!

tisec-seguros

Espacio tiSec: El despegue de los Seguros de Responsabilidad Cibernética

El pasado Jueves 25 de Febrero, estuve en el espacio tiSec de Revista SIC. Un encuentro de profesionales del sector en el que casi 200 personas pudimos escuchar de primera mano las impresiones sobre una tendencia al alza, la de los seguros de responsabilidad cibernética.

Allí, José de la Peña Muñoz, Director de la revista, nos puso en situación al contarnos que este tema se empezó a escuchar en el 2014 y que, poco a poco, va tomando forma. Desde Revista SIC están totalmente convencidos de que los seguros van a estar muy presentes en un futuro cercano.

Para entender bien todo esto, tuvimos la oportunidad de escuchar tres presentaciones muy interesantes…

 

Modelo de proyecto de integración de la transferencia de riesgos en la transformación digital de las empresas

Fernando Picatoste Mateu, Socio Responsable de Cyber Risk Services en Deloitte, hizo hincapié en que las innovaciones rompen el perímetro de seguridad de las empresas. Hemos pasado a un mundo full digital que expande la actividad de los empleados y usuarios a entornos antes no controlados, como el hogar en dispositivos móviles.

Este cambio, que hace que el trabajo y los activos dejen de estar exclusivamente en la oficina para quedarse en nuestro móvil, tablet, cloud… es algo a lo que el departamento de seguridad y la gestión de riesgos tiene que entender y adaptarse cuanto antes.

La actividad actual pasa por poner controles, pero es imposible estar 100% seguro, por lo que el trato del riesgo residual se convierte en asumirlo o traspasarlo.

En este escenario, las empresas están expuestas a ciberataques y a presión regulatoria, que las empuja poco a poco a la necesidad de contratar seguros que se puedan hacer cargo de cierto tipo de riesgos.

Sin embargo, las empresas siguen reticentes a este cambio, principalmente por:

  • Subestiman los costes (pérdidas) derivados de un ataque.
  • Creen estar protegidas por la normativa legal.
  • Los contratos con las aseguradoras son complejos.

Si se deciden dar el paso, el proceso consistirá en:

  • Realizar un análisis de riesgos sobre los activos de la empresa.
  • Entender las pólizas para saber en qué caso cumpliríamos las condiciones o exclusiones.
  • Valorar el coste de la implantación de controles contra el coste del seguro.
  • Entender correctamente el proceso de reclamación cuando ocurra un suceso.

Por último, nos recuerda que es importante entender que este tipo de seguros cubren los casos de robo, fraude, forense, interrupción… pero nunca van a poder cubrir las pérdidas de reputación o el hecho de que no vuelva a ocurrir.

 

Servicios de ciberseguridad gestionada con coberturas de seguro asociadas

Juan Miguel Velasco López-Urda, Partner Managin Director en Aiuken Solutions, ofreción una visión un tanto catastrófica, pero en gran parte real, de la situación actual.

Estamos en un mundo en el que la conectividad es la base de todo y está basada en unos pilares que dejan bastante que desear. Nos basamos en una arquitectura de red insegura por definición, en unos sistemas operativos vulnerables, en dispositivos que piensan más en el diseño que en la seguridad… y en un entorno que nos adiestra para tener «confianza visual», nos creemos todo lo que nos cuentan.

Es por eso que estamos en un mundo lleno de peligros, lo que hace que los seguros sean reacios a entrar en el mundo de los riesgos cibernéticos. Sin embargo aseguran a pilotos de F1, a gente que hace puenting…

El problema de fondo es que en España no cuantificamos ataques ni impactos, lo que deja a los seguros sin capacidad para evaluar hasta qué punto les puede ser viable ofrecer productos.

Es muy importante que las empresas pierdan el miedo a ofrecer esta información. En América es un dato público que permite medir de forma correcta lo que los ataques representan a las compañías.

En este punto nos contó la experiencia de Aiuken, por lo que os invitamos a visitar su web y conocer sus servicios.

 

Pólizas de seguros para empresas ante riesgos de ciberseguridad

Jesús Marcos de la Fuente, Director del área técnica de seguros patrimoniales en Reale Seguros, vino a contarnos de primera mano el nuevo servicio «Reale Ciber Seguridad», un producto orientado a pymes y autónomos y que cubre:

  • Asistencia Técnica y gastos de investigación del siniestro
  • Gastos de reparación y recuperación de datos borrados y equipos dañados
  • Responsabilidad Civil frente a terceros
  • Responsabilidad por datos de carácter personal
  • Defensa Jurídica

Todo por una cuota que oscila entre los 200 y 400€ anuales y que ofrece asesoramiento e incluso auditoría de los sistemas del cliente.

Un servicio muy interesante y pionero en España que, seguro, irá a más en la versión 2.0 que Jesús nos anunció para medio plazo.

 

El despegue de los Seguros de Responsabilidad Cibernética

Para finalizar, se realizó una mesa de debate. A los anteriores ponentes se unieron Rafael Hernández González, Responsable de Seguridad de la Información de Cepsa, y Alfredo Zorzo Losada, Responsable de Seguros de Orange España.

Los asistentes pudimos realizar todo tipo de preguntas sobre las dudas y complicaciones derivadas de este tipo de servicios, así como la acogida que pueden tener y el futuro de los mismos. Sin duda, un interesante intercambio de ideas muy enriquecedor.

 

Por supuesto, no quiero terminar sin agradecer la invitación al evento a la revista SIC y a los copatrocinadores del evento, Aiuken Solutions y Reale Seguros.

P.D.: Por si te ha sabido a poco, también puedes visitar la crónica oficial del evento.