SecurityInside Live: Mundo Hacker Day 2017

Al igual que el año pasado, me voy al evento «Mundo Hacker Day 2017» para asistir en primera persona a las interesantes charlas que grandes expertos en seguridad van a ofrecer.

Leer más

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.

Cuando la Seguridad Informática es una Inversión

Hace algunos años era imposible pensar que la seguridad informática era ni remotamente imprescindible en las organizaciones, pero esto ha cambiado radicalmente en los últimos cinco años.

Esto debido principalmente al auge de las aplicaciones móviles, debido al boom de los teléfonos inteligentes los llamados smartphones, si a esto le sumamos los smart TV, las tabletas, relojes inteligentes pues sin lugar a dudas las organizaciones tienen que blindarse de una gran cantidad de equipos, herramientas (software) y hardware de seguridad informática.

Uno de los estudios más respetables realizados por la firma Gartner revela que con el internet de las cosas un total de 6.4 billones de dispositivos estarán conectados a internet.

http://www.gartner.com/newsroom/id/3165317

No nos imaginamos la cantidad de recursos que hay que poner en marcha para mantener a raya la seguridad informática, un tema que cada dia nos tomamos más en serio y que ya dejó de ser un gasto netamente de capricho de las empresas.

Gartner

Figura 1. IOT (Internet of Things)

Todo lo que nos viene es una gran avalancha de que tendremos que contener de la mejor manera, se dice que por cada vez que de da de alta un dispositivo con acceso a internet se nos duplica el esfuerzo para securizar cada elemento de seguridad.

Un estudio revela también que las empresa invierten en promedio unos 50.000 € cifra que en mi opinión puede ser discreta dependiendo del core business de la empresa.

Este interesante articulo de Forbes nos da una perspectiva bastante real de lo que estamos comentando.

http://www.forbes.com/sites/tonybradley/2016/03/23/6-tips-to-help-you-avoid-a-near-miss-in-security/#4291eab438c3

Esto nos lleva a lo que se llama ROSI que significa la el retorno de la inversión de la seguridad informática.

Esto me trae un buen recuerdo de un artículo que pude leer en el país y que resume bastante bien el tema de la inversion en la seguridad informática.

Con la famosa coletilla «A mi no me va a pasar» pero cuando te pasa la cantidad de dinero que se pierden por no tener por ejemplo un sitio web bancario en linea cada segundo que pasa fuera de servicio son bits que se convierten a la final en miles de euros.

El pais

http://www.elpais.com.uy/economia-y-mercado/desafio-invertir-seguridad-informatica-anadir.html

Entonces podemos decir con propiedad que la seguridad informática ya no es un juego es algo que cada dia se toma más en serio para poder brindar un servicio de calidad sin riesgos a que nuestras organizaciones sean vulnerables.

Hasta la próxima……

 

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:

{
   "Version": "2012-10-17",
   "Statement": [{
      "Effect": "Allow",
      "Action": "ec2:Describe*",
      "Resource": "*"
    }
   ]
}

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.

##########################################################################################
#
# File: iam-list-users-policies.py
# Author: Cristobal Espinosa
# 
# https://boto3.readthedocs.org/en/latest/reference/services/index.html
#
##########################################################################################

# Imports ################################################################################
import boto3
from colorama import init, Fore, Style
##########################################################################################

# Initial values #########################################################################
init(autoreset=True)

step = False # Set as True to step by step view
##########################################################################################

print 
print Fore.GREEN + '-- IAM POLICIES CONTROL'
print Fore.GREEN + '----------------------------------------------------------------------------------'
print 

client = boto3.client('iam')

user_list = client.list_users()

# List users
for user in user_list['Users']:
    print Fore.YELLOW + '[**] ' + Fore.WHITE + user['UserName'] + ':'
    
    # List user inline policies
    print Fore.YELLOW + '\t[*] ' + Fore.WHITE + 'User inline policies:'
    user_policies = client.list_user_policies(UserName = user['UserName'])
        
    for policy in user_policies['PolicyNames']: 
        print '\t\t- ' + policy
    
    print    
    
    # List user managed policies
    print Fore.YELLOW + '\t[*] ' + Fore.WHITE + 'User managed policies:'
    user_policies = client.list_attached_user_policies(UserName = user['UserName'])
        
    for policy in user_policies['AttachedPolicies']: 
        print '\t\t- ' + policy['PolicyName']
    
    print

    # Get user groups    
    user_groups = client.list_groups_for_user(UserName = user['UserName'])

    print Fore.YELLOW + '\t[*] ' + Fore.WHITE + 'User groups and associated policies:'
    for group in user_groups['Groups']:
        
        group_policies = client.list_attached_group_policies(GroupName = group['GroupName'])
                        
        for group_policy in group_policies['AttachedPolicies']:
            print '\t\t- [' + group['GroupName'] + '] -> ' + group_policy['PolicyName']
    
        print

    print Fore.GREEN + '----------------------------------------------------------------------------------'
    print  
    
    if step: 
        raw_input("Press Enter to continue...")  
        print

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.

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.