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.
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.
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).
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:
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:
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».
Al seleccionarlo, se inicia el proceso. En nuestro caso, seleccionamos dispositivo virtual (app para móvil):
Ú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.
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.
De esta forma, los pasos recomendables para la gestión de usuarios en Amazon WS IAM se podrían resumir en:
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.
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.
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.
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.
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……
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.
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).
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:
A la hora de aplicarlas sobre un usuario o grupo, podemos optar por hacerlo de dos formas:
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:
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».
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í:
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.
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…
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:
Si se deciden dar el paso, el proceso consistirá en:
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.
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.
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:
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.
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.