Categories
General

Cual es tu sistema de virtualización favorito?

A raíz de la presentación de Roger Pau Monne (Xen tuning) surgío la pregunta que titula este post entre los asistentes de la Centos Dojo 2014 que se celebó hace pocos dias en Barcelona. Des de cloudadmins os queriamos hacer participes la misma pregunta, con un par de opciones extra, para conocer los vuestras preferencias:

Xen/kvm

  • PV
  • HVM
  • LXC

  • OpenVZ
  • Docker
  • Others…

    null
    Nos gustaría conocer por que sistema os decantáis en los distintos proveedores cloud que utilicéis (AWS, Google Cloud Platform, Digital Ocean, Linode, etc). Y si aplicáis algún truquillo para exprimir el rendimiento de vuestras instancias estariamos encatados de que lo compartieráis con nosotros.
    😀

    Categories
    General Guide In detail Security

    Hiera-eyaml: A salvo de miradas indiscretas


    Para todos aquellos que utilizamos Puppet habitualmente hemos implementado módulos para distintos entornos (development, testing, production), distintos problemas, pautas, ideas… Cada una de las declaraciones que podemos hacer en ellos puede tener requerimientos distintos y debemos tener en cuenta los cambios que pueden surgir en un futuro. Probablemente nos hemos encontrado en la situación en la que hemos integrado nuestros datos de configuración (direcciones IP, nombres de aplicaciones, credenciales, o cualquier tipo de datos que no queramos compartir) en el código de nuestro repositorio.
    Existen distintos métodos para separar esta información sensible, a continuación explicaremos como hacerlo a través de Hiera y eyaml.
    Hiera es una herramienta de búsqueda de pares clave/valor para configurar información. Hiera-eyaml es un backend para Hiera que nos proporciona pares de clave/valor cifradas en ficheros yaml para ser utilizadas a través de Puppet.
    PD: Si utilizáis algún gestor de versiones de Ruby como rbenv o rvm tenedlo en cuenta al instalar hiera y hiera-eyaml 😉
    Podemos tomar como ejemplo la configuración de un módulo para gestionar el servicio SSH:

    class ssh {
      $ssh_packages      = ['openssh','openssh-clients','openssh-server']
      $permit_root_login = 'no'
      $ssh_users         = ['root','jeff','gary','hunter']
      package { $ssh_packages:
        ensure => present,
        before => File['/etc/ssh/sshd_config'],
      }
      file { '/etc/ssh/sshd_config':
        ensure  => present,
        owner   => 'root',
        group   => 'root',
        mode    => '0644',
        # Template uses $permit_root_login and $ssh_users
        content => template('ssh/sshd_config.erb'),
      }

    Y este sería la plantilla que podríamos utilizar para el fichero sshd_config:

    Protocol 2
    SyslogFacility AUTHPRIV
    PasswordAuthentication yes
    ChallengeResponseAuthentication no
    GSSAPIAuthentication yes
    GSSAPICleanupCredentials yes
    # PermitRootLogin Setting
    PermitRootLogin <%= permit_root_login %>
    # Allow individual Users
    <% ssh_users.each do |user| -%>
    AllowUser <%= user %>
    <% end -%>
    # Accept locale-related environment variables
    AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
    AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
    AcceptEnv LC_IDENTIFICATION LC_ALL
    X11Forwarding yes
    Subsystem	sftp	/usr/libexec/openssh/sftp-server

    Con Hiera podemos hacer referencia a las variables más sensibles cambiando estas 3 lineas:

    $ssh_packages      = hiera('ssh_packages')
    $permit_root_login = hiera('permit_root_login')
    $ssh_users         = hiera('ssh_users')

     
     
    Hiera-eyaml nos puede ayudar a evitar comprometer nuestros datos sensible en el backend configurado con hiera. Podemos seguir este procedimiento para lograrlo:

    1. Generar claves pública y privada, por defecto las crea dentro del directorio ./keys en que ejecutemos el siguiente comando. $ eyaml createkeys
    2.  

    3. Añadimos el backend eyaml a la configuración de Hiera en /etc/hiera.yaml
      ---
      :backends:
          - eyaml
          - yaml
      :hierarchy:
          - %{environment}
          - common
      :yaml:
          :datadir: '/etc/puppet/hieradata'
      :eyaml:
          :datadir: '/etc/puppet/hieradata'
          # If using the pkcs7 encryptor (default)
          :pkcs7_private_key: /path/to/private_key.pkcs7.pem
          :pkcs7_public_key:  /path/to/public_key.pkcs7.pem
    4.  

    5. Añadir un fichero de configuración eyaml, de este modo no deberemos especificar la ubicación cada vez que queramos cifrar datos, por defecto sería ~/.eyaml/config.yaml pero podemos sobrescribir esta configuración con la variable de entorno EYAML_CONFIG.
    6.  

    7. Encriptamos los datos con el comando $ eyaml encrypt -p y obtenemos un string similar a este
      ENC[PKCS7,Y22exl+OvjDe+drmik2XEeD3VQtl1uZJXFFF2NnrMXDWx0csyqLB/2NOWefvNBTZfOlPvMlAesyr4bUY4I5XeVbVk38XKxeriH69EFAD4CahIZlC8lkE/uDhjJGQfh052eonkungHIcuGKY/5sEbbZl/qufjAtp/ufor15VBJtsXt17tXP4yl5ZP119Fwq8xiREGOL0lVvFYJz2hZc1ppPCNG5lwuLnTekXN/OazNYpf4CMd/HjZFXwcXRtTlzewJLc+/gox2IfByQRhsI/AgogRfYQKocZgFb/DOZoXR7wmIZGeunzwhqfmEtGiqpvJJQ5wVRdzJVpTnANBA5qxeA==]
    8.  

    9. En este punto ya podemos añadir la información cifrada en el fichero eyaml definido en el segundo paso.
      ssh::permit_root_login: ENC[PKCS7,Y22exl+OvjDe+drmik2XEeD3VQtl1uZJXFFF2NnrMXDWx0csyqLB/2NOWefvNBTZfOlPvMlAesyr4bUY4I5XeVbVk38XKxeriH69EFAD4CahIZlC8lkE/uDhjJGQfh052eonkungHIcuGKY/5sEbbZl/qufjAtp/ufor15VBJtsXt17tXP4yl5ZP119Fwq8xiREGOL0lVvFYJz2hZc1ppPCNG5lwuLnTekXN/OazNYpf4CMd/HjZFXwcXRtTlzewJLc+/gox2IfByQRhsI/AgogRfYQKocZgFb/DOZoXR7wmIZGeunzwhqfmEtGiqpvJJQ5wVRdzJVpTnANBA5qxeA==]
    10.  
       

    Debemos tener especial cuidado con las claves generadas con hiera-eyaml y administrar la información cifrada con nuestro gestor de claves favorito (KeepassX, Passpack, etc.) 
    En conclusión podemos obtener varias ventajas de utilizar Hiera en combinación con hiera-eyaml, entre ellas:

    • Facilita la configuración de los distintos entornos: configuramos fácilmente datos por defecto con múltiples niveles de override.
    • Facilita la reutilización de los módulos públicos de Puppet: No edites el código, sólo coloca la información necesaria en Hiera.
    • Facilita la colaboración: No necesitas preocuparte de limpiar tu información antes de mostrar el módulo.

     
    Saludos!

    Categories
    General Social

    Docker Workshop in Barcelona

    Como ya comentamos anteriormente en cloudadmins ha irrumpido con mucha fuerza una nueva forma de virtualizar a través de LxC. Docker empezó como un proyecto interno de Solomon Hykes en dotCloud, un proveedor PaaS (plataforma como servicio) y fue publicado en marzo de 2013. Se trata de una herramienta de virtualización construida sobre LinuX Containers que utiliza funcionalidades de CGROUPS para crear y ejecutar múltiples entornos virtuales de forma aislada. A diferencia de una máquina virtual Docker no permite crear un entorno virtualizado distinto al del OS, procesador y harwarde emulado. En cambio conseguimos un rendimiento mayor ya que el overhead es mucho menor ha diferencia de la virtualización tradicional con hypervisor.

    Tuvimos el placer de asistir al workshop sobre dockers que se llevó a cabo en itnig. En ella repasamos comandos básicos de docker de la mano de Dimtris Kapanidis, podéis reproducir el workshop a través de su cuenta de github docker-workshop. Si no tenéis instalado docker y queréis trastear un poco es posible dar los primeros pasos en su propia web try it! O darle un vistazo a la presentación que tiene colgada en slidshare Xabier Larrakoetxea llamada Ship it with Docker”
    Dimitri nos recomendo utilizar el parámetro -s al buscar imágenes para obtener imágenes de un sitio de confianza.

    sudo docker search -s 10 nginx
    NAME                             DESCRIPTION                                     STARS 
    nginx                            Official build of Nginx.                        110     
    

    A continuación Nicolas Poggi M. presento un caso de uso de como utilizar Docker como proveedor de Vagrant para crear múltiples entornos de desarrollo (link presentación y link desarrollo) y Pep Turró de Redhat nos presento el proyecto ATOMIC y como se esta redefiniendo a través de GearD.
    Finalmente Dimitri de nuevo nos mostro como enlazar contenedores entre distintos hosts a través de Ambassador Pattern Lo que nos abre un extenso abanico de possibilidades en cuanto a la portabilidad y despliegue de LxC. Los 60 asistentes del workshop pudimos disfrutar de unas cervezas por cortesía de Estrella Damm 🙂
    Feliz sysadminday!!
     
    Ref: http://www.meetup.com/docker-barcelona-spain/events/193336922/comments/388505892/

    Categories
    General Monitoring

    Battle Cloud Providers

    microsoft-azure-logo
    Almacenamiento y computación son los recursos que más consumimos habitualmente en nuestros proveedores IaaS. Otros servicios como balanceo de carga, servicio de colas, monitorización de rendimiento de los recursos, etc son considerados en el momento de escoger pero son secundarios en el grueso de la factura final. Estos servicios compiten en costes, rendimiento y disponibilidad. Es sorprendente como recientemente hemos visto anuncios de distintas compañías anunciando reducciones de precios en servicios clave.

    A raíz de estos movimientos es fácil no saber hacía que proveedor dirigirse o que criterio debe prevalecer a la hora de utilizar los distintos servicios que nos proporcionan. Han surgido herramientas como PlanForCloud que pueden ayudarnos en esta tarea. También le debemos dar importancia a las SLA’s que nos ofrecen y al rendimiento de las plataformas que desplegamos en servicios IaaS/PaaS, para ello contamos con aplicaciones como de CloudSleuth, nos permite ver de forma detallada varias métricas que nos ayudan elegir que proveedor es el adecuado para nuestros requerimientos.

    Cloud Pricing Trends
    Ante tanta variedad se nos puede hacer complicado la gestión de tantos servicios, más aún si contamos con varios proveedores, se encuentran en crecimiento plataformas como ECmanaged o eNovance, que nos permiten llevar una administración centralizada de ellos. También herramientas de código abierto como Hydra que nos permiten una mayor flexibilidad y menor coste para llevar a cabo estas tareas. Hemos encontrado este post muy interesante para valorar los distintos proveedores existentes actualmente. A día de hoy AWS sigue siendo la referencia a seguir, veremos como evolucionan las grandes compañías ante tanta competitividad.
    Top Public Clouds Used

    Categories
    General Guide In detail

    Automatizando copias de seguridad de volumenes EBS con boto y Python


    Recientemente hemos visto como AWS ha acogido boto como API de facto para interactuar con muchos de sus servicios (Amazon S3, Amazon EC2, Amazon DynamoDB y muchos más). Boto nos facilita las tareas que realizamos habitualmente a través de CLI, entre ellas la de llevar a cabo una copia de seguridad de nuestros volúmenes EBS. En este artículo vamos describir los pasos para automatizar de forma fácil y sencilla este proceso.
    Para empezar tendremos instalar boto a través pip. Pip es una utilidad de phyton para instalar paquetes.

    pip install boto

    A continuación debemos introducir nuestras credenciales en el archivo de configuración de boto.

    export AWS_ACCESS_KEY_ID="..."
    export AWS_SECRET_ACCESS_KEY="..."

    Debemos utilizar una IAM que tenga como mínimo los siguientes privilegios

    "Action": [
            "ec2:CreateSnapshot",
            "ec2:CreateTags",
            "ec2:DeleteSnapshot",
            "ec2:DescribeAvailabilityZones",
            "ec2:DescribeSnapshots",
            "ec2:DescribeTags",
            "ec2:DescribeVolumeAttribute",
            "ec2:DescribeVolumeStatus",
            "ec2:DescribeVolumes"
          ],

    Seguidamente añadimos una notificación automática a través de SNS de AWS y añadimos la dirección de correo de la IAM que vayamos a utilizar para esta labor.
    Una vez tengamos acceso a nuestros servicios en AWS y disponemos de un ARN válido, llevaremos a cabo las copias de seguridad utilizando esta simple herramienta llamada aws-snapshot-tool. La configuración es muy fácil, solo tenemos que editar el archivo config.py.

    config = {
        'ec2_region_name': 'us-east-1',
        'ec2_region_endpoint': 'ec2.us-east-1.amazonaws.com',
        'tag_name': 'tag:MakeSnapshot',
        'tag_value':    'True',
        'keep_day': 5,
        'keep_week': 5,
        'keep_month': 11,
        'log_file': '/tmp/makesnapshots.log',
    }

    Finalmente solo nos falta etiquetar cada volumen EBS del que queramos obtener un respaldo y establecer la retención de estos.

    # chmod +x makesnapshots.py
    # crontab -e
    30 1 * * 1-5 /opt/aws-snapshot-tool/makesnapshots.py day
    30 2 * * 6 /opt/aws-snapshot-tool/makesnapshots.py week
    30 3 1 * * /opt/aws-snapshot-tool/makesnapshots.py month

    Le podemos encontrar algunas pegas, por ejemplo si disponemos de recursos en distintas regiones de AWS o si queremos aplicar políticas de retención diferentes a nuestros volúmenes EBS. Aún así hemos visto como con boto y Python tenemos una interfaz robusta, muy cómoda de utilizar que nos permite mantener y administrar varios aspectos de nuestros entornos alojados en AWS.
    Otra opción es delegar en terceros como autosnappy 😉
    Ivan Farré
    Cloudadmins.org

    Categories
    General

    ¿Hacia dónde volaran las nubes en 2014?

    Es el momento del año para hacer balance de como ha ido el 2013 y hacer previsiones para este 2014 que empezará en breve. También es el momento del año en el que muchos nos ponemos hacer predicciones sobre los temas más calientes que nos pueden afectar, desde cloudadmins no vamos a ser menos y repasaremos a continuación las posibles tendencias que pueden revolucionar el sector TIC en 2014.

    •  NFV & SDN (Network Functions Virtualisation & Software Defined Networks) SDN se está posicionando como solución de entornos productivos cada vez más flexibles, eficientes y altamente programables, es el caso de iniciativas abanderadas por OpenStack y OpenDaylight Projects. Al mismo tiempo es posible que NFV gane importancia y dirija nuevas funcionalidades en nuestros ISP permitiendo administrar los servicios dentro del cloud, reduciendo drásticamente costes e incrementando su agilidad. Estas pueden ser las tecnologías más disruptivas del próximo año.
    • Big Data: el uso de dispositivos BYOD y la explosión de contenido multimedia de altas prestaciones esta causando grandes retos en el ámbito del almacenamiento de datos y como definir su estrategia. En 2014 debemos preguntarnos cuestiones fundamentales sobre los volumen de datos ¿Cuáles son los objetivos de la arquitectura de almacenamiento? ¿Estamos almacenando los datos correctos y de forma adecuada? ¿De que modo les podemos sacar el mayor provecho? ¿Pueden ir de la mano con técnicas de BI (Bussines Intelligence) y/o Inteligencia Operacional? Para los que estamos más verdes en este tema la siguiente presentación puede introducirnos y aclararnos el concepto de Big Data: “Runaway complexity in Big Data. And a plan to stop it
    • Private Cloud: Estos últimos años hemos visto en el sector TIC la adopción de forma exponencial de tecnologías Cloud. Nadie duda ya de los beneficios nos aporta: pago por uso, flexibilidad, disponibilidad, etc… pero las preocupaciones en cuanto a la seguridad y privacidad siguen presentes. Aspectos que hacen que muchas organizaciones requieran que se implemente una nube privada, antes de dar el salto hacía proveedores de servicios cloud públicos.
    • LXC & Configuration Management: A estas alturas podemos decir que ya hemos vivido la eclosión de herramientas destinadas a la gestión de la configuración (puppet, chef, salt, etc..) y vemos como emerge una nueva forma de gestionar recursos a través de LXC (containers). Algunas herramientas como puppet ya se han subido al carro, dónde Dockers se posiciona dando solución al nuevo enfoque de los sistemas frente a los restos del “futuro” PaaS.

    Para finalizar os dejo una píldora con las mejores herramientas, en el ámbito de la seguridad, de este 2014 gracias a Team Cymru. Buen despegue de año!

    Categories
    General Security

    API's: In the breach of Cloud security

    Cada minuto de cada día se presenta la posibilidad de producirse un contratiempo que comprometa nuestra información. Una de las preocupaciones más relevantes al utilizar infraestructura Cloud reside en el grado de seguridad que nos pueden proporcionar los proveedores, a pesar de las significantes ventajas que este nos ofrece, como el pago por uso. En todo momento pasamos a “confiar” información sensible de nuestra propia empresa o incluso de clientes a terceros. Cuando evaluamos los niveles de seguridad debemos tener muy presentes, entre otros,  la seguridad en la interfaz o APIs.
    Cloud Security Alliance (CSA) hace hincapié en la atención que le debemos prestar a las interfaces o APIs que los proveedores ponen a nuestro alcance. Para ello le dedica un punto en su reporte anual sobre las brechas de seguridad más notables. El uso de APIs inseguras puede exponernos a diversos riesgos relacionados con la confidencialidad, integridad, disponibilidad y “accounting”. Mientras los proveedores deben poner grandes esfuerzos en la securizar sus APIs, nosotros como consumidores de estos servicios es imprescindible analizar con nuestros propios medios para llegar a conocer sus debilidades y sus puntos fuertes. Un buen punto de partida puede ser el listado (Web Services Security Checklist) que nos proporciona Gunnar Peterson en su blog. También muy recomendable la lectura de los siguientes artículos

    Con la proliferación de servicios desarrollados e integrados en el cloud es imprescindible que tomemos seriamente este punto, con el objetivo de evitar que aparezcan en el próximo listado de brechas de seguridad Cloud de CSA. Mientras la mayoría de proveedores siguen luchando para proporcionar una seguridad en sus APIs, integrada en todos los modelos de los servicios que nos ofrecen, es crítico que como consumidores entendamos las implicaciones de seguridad asociadas al uso, gestión, mantenimiento y monitorizaciónq que estas interfaces significan dentro los servicios cloud que adquiramos. Aunque no debemos morir con la idea en la cabeza de que todo lo relacionado con el cloud es inseguro 😉
    If you think the cloud isn’t secure you’re dead wrong
    Ivan Farré

    Categories
    General Security

    El cuento del Cloud que quería ser seguro

    El 4 de junio asistimos a la primera UOC SEC-CON, en ella participaron ponentes de renombre. Se trataron temas diversos, desde la evolución del Cloud en los últimos años, los ataques de ciberseguridad registrados mas célebres y en que consiste el trabajo de los Mossos en delitos cometidos en este ámbito.
    El cuerpo de policia de los Mossos hizo hincapié en la dificultad al recoger evidencias válidas y además Vicente Diaz, Chema Alonso y David Barroso describieron los últimos ataques de más renombre (Stuxnet, Duqu, Flame, hacktivismo).  Este último nos descubrío Tails, un sistema muy aconsejable para los que quieren mantener su privacidad navegando o utilizando equipos de terceros.
    Mientras Jesús Luna, Head of DEEDS’ Security Research Group at TU Darmstadt,  especializado en el área de seguridad en la nube y miembro de Cloud Security Alliance contó en forma de cuento  como habían convergido distintas tecnologías virtualización, WebServices, redes de alta velocidad) para llegar a ofrecer los servicios Cloud que conocemos actualmente: IaaS, PaaS, SaaS, etc…

    Repasamos las distintas modalidades de cloud existentes:

    • híbrido
    • privado
    • público
    • comunitario

    Y  los beneficios que todos conocemos que nos brinda:

    • escalabilidad 
    • pago por uso
    • disponibilidad
    • flexibilidad
    • deslocalización

    Pero topamos con la seguridad, según Jesús Luna, la seguridad y la confianza siguen siendo los principales inhibidores para la adopción de tecnologías Cloud entre PyMES europeas. La elección de Proveedores de Servicios Cloud (CSP)  es motivada a menudo en valoraciones sobre los acuerdos en el nivel de servicio (SLA) y sus costes, además recientemente también se basan en aspectos de seguridad y/o privacidad. Desafortunadamente es muy poco común que un CSP especifique con detalle los niveles de seguridad asociados a sus servicios, de este modo no es posible que los clientes tomen decisiones relevantes basándose en directivas de seguridad.

    Con el objetivo de evitar estas carencias Cloud Security Alliance propone utilizar especificaciones concretas de seguridad en las SLA de los acuerdos con los CSP, llamándolas “Security Level Agreements” o SecLAs. De este modo sería posible crear ecosistemas Cloud confiables, siendo deseable desarrollar técnicas que nos permitan medir i cuantificar estas características para poder compararlas, negociar y predecir posibles agujeros de seguridad.

    Jesús Luna afirmo con firmeza que en un futuro próximo las SLA’s (SecLAs) van a determinar las claves de la relación de los servicios Cloud (CSP) con sus usuarios, también puso énfasis sobre el prospero porvenir de los proveedores de SECaaS.

    Categories
    General Security Social

    Does SECaaS save money?


    Como dice el título, ¿delegar la seguridad del departamento TI puede incrementar los beneficios de una empresa? De ello nos intentaron convencer en el evento Cloud Security 2013 que se llevo acabo a principios de Febrero gracias SVT CloudServices. En él Josep Bardallo, CEO de SVT, nos presento la compañía y nos mostró el punto de vista de SVT sobre el estado actual de la seguridad en la nube, también conocido como SECaaS. Un interesante análisis de aproximadamente 10 minutos que podéis ver a partir del minuto 20 en el siguiente vídeo.
    Además contó con la participación de varias empresas que dieron a conocer casos de éxito al utilizar productos Cloud de SVT. En todos ellos se enfatizaba el hecho de que confiar en las soluciones de SEECaaS les había permitido dedicar todos sus esfuerzos a lo que realmente sabían hacer. Interesante el caso de Roberto Lorente, responsable de sistemas de unos laboratorios farmacéuticos, en el que narra los conflictos que le había generado la LOPD, entre otros, para adquirir este tipo de servicios en su aparición. También pudimos conocer de primera mano, por parte de Pau García Milà, del próximo lanzamiento de eyeOS. 
    En este evento de SVT, como proveedor de servicios SEECaaS, se destaco el hecho pago por uso como ventaja frente al pago de licencias por usuario o equipo, como una de las principales ventajas frente a otros proveedores de servicio. Sin dejar a un lado los otros beneficios de flexibilidad, agilidad y escalabilidad que se derivan de utilizar este tipo productos.
    Finalmente presenciamos una demostración hacker en directo bastante decepcionante. Nos mostraron como con técnicas muy sencillas (google hacking, sql injection básico,  traceroute…) se puede llegar a obtener información critica además de algunas de los productos que ofrece, Cloudjacket.  También echamos de menos un turno preguntas, sobre todo en esta última parte.

    Categories
    In detail Security

    SCIT the digital vaccine – Buscando el 100% de Uptime

     
    Hola a todos,
    Seguramente viendo el título de este POST y de un primer vistazo te preguntarás que tiene que ver  las vacunas con la disponibilidad de los servicios, yo también me hice esa pregunta….

    A día de hoy la información es uno de los activos más importantes de cualquier organización. Mantener la confidencialidad, la disponibilidad y la integridad puede llegar a ser una tarea esencial para mantener los niveles de competitividad y rendimiento de cualquier empresa con el objetivo de conseguir beneficios. Actualmente podemos ver como emergen proveedores de soluciones SECaaS (Security as a Service) como Novell, McAfee, Symantec, etc.
    Es “archiconocido” que todos los sistemas de la información, plataformas TI, están expuestas a un número ingente de amenazas. Aprovechando cualquiera de las vulnerabilidades conocidas o por conocer (0-day) pueden someter cualquier activo crítico de información a espionaje, sabotaje, fraude, etc.
    En esta línea y con el objetivo de reducir los llamados “cyberriesgos” tuve la oportunidad de asistir a principios del 2012 al Fourth Workshop on Cyber Security and Global Affairs and Global Security. En él Arun K. Sood mostró en su presentación unos datos que me impactaron:
    En la figura podemos observar que la brecha de  tiempo entre la intrusión y la respuesta ante el ataques es muy alto. En este intervalo de tiempo un atacante ha podido comprometer información crítica de nuestra organización si no disponemos de las herramientas adecuadas que nos ayuden a disminuirlo. En el siguiente documento podréis obtener información detallada y muy extensa sobre este tema: INFORME SOBRE INVESTIGACIONES DE BRECHAS EN LOS DATOS DE 2012.
    Arun K. Sook es el fundador de SCIT Labs, spin off de la universidad George Mason, tiene como objetivo crear un framework de clusters de servidores securizados.  Este producto, con el objetivo de acercarse al paradigma de 100% de uptime en todos los sentidos, incluye la mitigación del posible compromiso del propio contenido o información. Este proyecto ha sido bautizado con el nombre “the digital vaccine” y tiene como objetivos principales:

    • Asegurar la disponibilidad de los servicios en infraestructuras críticas.
    • Tolerancia cero a cualquier tipo de  intento de intrusión.
    • Conseguir un nivel redundancia o backup óptimo.

    La técnica: La “vacuna” utiliza máquinas virtuales que van rotando cada 60 segundos o menos.  Cada intervalo de rotación se proporciona nuevos servidores que han estado “limpiados” y/o restaurados, este proceso se va repitiendo sucesivamente.

    Pese a la ambición de este proyecto no se han visto avances significativos o detalles técnicos en artículos sobre su funcionamiento. Aún así estaremos atentos a lo que va dar de si este workshop en la edición de 2013 (Cyber Resilience Workshop Series) que se llevará a cabo a final de mes y que seguiremos desde cloudadmins.org.
    Hasta el próximo POST.  Nos vemos,
    Iván Farré – Cloudadmins.org