Categories
Community General In detail OpenSource Security Social

Presentación del libro “DevOps y seguridad cloud” en el FNAC Fòrum

WhatsApp Image 2020-01-24 at 07.12
El 23 de enero tuvo lugar en el Fórum Fnac de la Illa Diagonal la presentación del libro “Devops y seguridad cloud”, de los autores Jordi Guijarro Olivares(i2CAT), Joan Caparrós Ramírez (CSUC) y Lorenzo Cubero Luque (NetCentric).
El acto ha contado con la participación del Dr. Josep Jorba, director del Postgrado de Cloud Computing de la UOC, el Dr. Remo Suppi, profesor de la UAB y el Sr. Raúl Sánchez de Rancher Labs que han acompañado a los tres autores.
El libro, publicado por UOC Media (el sello editorial de la UOC), surge como parte del material elaborado en el postgrado en Cloud Computing de la UOC, programa dirigido a los que quieran orientar su experiencia en el ámbito de la computación y modelos en nube. Con el objetivo de capacitar a la empresa ya sus profesionales de IT, ofrece los conocimientos, habilidades y herramientas necesarias para perfiles especialistas en el ámbito devops y de cloud, un perfil profesional altamente demandado en el mercado laboral , tanto en el ámbito nacional como internacional.
Así, su lectura ayuda a profundizar en retos, como la integración continua (CI) y la entrega continua (CD) de la mano de tecnologías de containers como Docker y plataformas como Kubernetes (K8S), bajo servicios de infraestructura como Amazon Web Services (AWS), herramientas de automatización como terraformar y de testing como Jenkins. Además, incluye casos de uso para ir más allá también para la parte práctica.
http://www.editorialuoc.cat/devops-y-seguridad-cloud
Gracias por vuestra asistencia, muy contentos de como fue la presentación y las primeras opiniones sobre el Libro.
https://www.amazon.es/Devops-Seguridad-Cloud-657-Manuales/dp/8491806237/ref=sr_1_1?__mk_es_ES=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=devops+y+seguridad+cloud&qid=1575970105&sr=8-1
Os dejamos una galería de fotos del evento:


 

Categories
Community General Guide In detail Interoperability OpenSource Security Social

LIBRO CLOUDADMINS: Devops y seguridad Cloud

Hola a tod@s,

NOVEDAD! LIBRO BY @cloudadms

Conceptos DevOps avanzados, casos de uso con Rancher (K8S), AWS, OpenNebula, Jenkins, Terraform
http://www.editorialuoc.cat/devops-y-seguridad-cloud
devopsyseguridadcloud
 
DevOps y seguridad cloud surge como parte del material elaborado en el posgrado en Administración y Cloud Computing de la UOC, programa dirigido a los que deseen orientar su experiencia al ámbito de la computación y modelos cloud. Con el objetivo de capacitar a la empresa y a sus profesionales de IT, ofrece los conocimientos, habilidades y herramientas necesarias para perfiles especialistas en el ámbito DevOps y computación en la nube, un perfil profesional altamente demandado en el mercado laboral, tanto en el ámbito nacional como internacional.
 
La nube comprende el concepto básico por el que definiremos la entrega de servicios informáticos a clientes o usuarios por medio de una red. Este nuevo modelo de prestación de servicios permite añadir una capa de abstracción frente a los clientes que no saben dónde estos están ubicados (normalmente alojados en varios proveedores y repartidos por todo el mundo) ni la gestión de recursos que usan. Los servicios en la nube atienden las peticiones recibidas y aportan una flexibilidad y adaptabilidad de recursos frente a la demanda de forma totalmente transparente.
En el libro una vez vistos los conceptos básicos a modo de introducción, se centra en la materia necesaria para tener una visión más avanzada sobre el enfoque del rol de DevOps.

  • Uno de los puntos en los que centraremos nuestra atención es la gestión de la configuración, que nos permitirá acercar todos los entornos que utilizaremos para que sean lo más parecidos posible al entorno de producción final.
  • Uno de los pilares de DevOps es la integración continua que permite agregar los pequeños cambios realizados por los desarrolladores al conjunto de software desarrollado de manera que puedan ser testados y desplegados en entornos de desarrollo lo antes posible. • Veremos también diferentes estrategias de ‘testing’, todas ellas con el objetivo de minimizar los posibles errores que puedan producirse en los entornos productivos. Asimismo, se intentan detectar los errores en etapas tempranas del desarrollo cuando su corrección es más sencilla y menos costosa. • Como continuación de la integración continua veremos el concepto de entrega continua en su aplicación más práctica, donde aprovecharemos para explicar un extenso ejemplo.

Y en consecuencia, ¿interesado/a en cómo afrontarlo?

  • La gestión de infraestructura y de los diferentes entornos como resultado de las distintas etapas de la entrega continua. Tanto la infraestructura como los diferentes entornos deben ser extremadamente flexibles para adaptarse rápidamente a los cambios que se puedan producir en las diferentes etapas del desarrollo.
  • La gestión de los datos también representa un reto en cuanto que deben ser persistentes y estar disponibles a pesar de que el software que da acceso a ellos va cambiando constantemente.

usecases
Ahora depende de ti, reserva tu libro y sumérgete en retos como son la integración continua (CI) y la entrega continua (CD) de la mano de tecnologías de containers como Docker y plataformas como Kubernetes (K8S), bajo servicios de infraestructura como Amazon Web Services (AWS), herramientas de automatización como Terraform y de testing como Jenkins. Practica y vive una experiencia que te llevará al siguiente nivel. Y no olvides de compartir tu experiencia con nosotros, menciona @cloudadms en Twitter. ¡SUERTE! http://www.editorialuoc.cat/devops-y-seguridad-cloud

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
In detail OpenSource Security

OpenvSwitch y OpenNebula – 3a entrega

openvswitch
opennebula_logo
Siguiendo con la serie de posts sobre OpenvSwitch y OpenNebula en los que vamos viendo la integración de OpenNebula con Open vSwitch a través del driver, vamos a ver en esta última entrega cómo se aplica el control de MAC-Spoofing en openNebula y cómo añadir también control para IP-Spoofing que por defecto no viene en el driver de OpenNebula.

MAC-Spoofing

En caso de que una máquina se cambie la MAC, sabemos que se puede hacer un ataque de man-in-the-middle entre otros problemas derivados, para evitar esto OpenNebula añade una regla al Open vSwitch para fijar la MAC, el comando que se ejecuta és de la siguiente forma, donde <mac> es la MAC asignada por OpenNebula a la máquina virtual y <puerto> es el puerto que se ha creado sobre el bridge de OpenvSwitch:

# ovs-ofctl add-flow br32 in_port=<port>,dl_src=<mac>,priority=40000,actions=normal
# ovs-ofctl add-flow br32 in_port=<port>,priority=39000,actions=drop

Los comandos anteriores lo que hacen es filtrar todo el tráfico por defecto en el puerto (prioridad 39000) y sólo dejar pasar el tráfico por el puerto que tenga la mac de la máquina virtual cómo destino/origen (prioridad 40000). Más prioridad indica que en caso de hacer match se ejecutará esta y no pasara a las siguientes.
En primer lugar vamos a probar que efectivamente si cambiamos la MAC de una máquina virtual el tráfico hacia esta es descartado . Hacemos dos máquinas virtuales con la IP 192.168.2.29 y 192.168.2.31 situadas en el mismo host físico , y cambiamos la MAC de la segunda con el macchanger :

# macchanger -r eth1

Seguidamente hacemos un ping entre las dos redes y vemos como efectivamente no llegan tanto los pings de la primera a la segunda como los de la segunda a la primera .
También hacemos un tcpdump en la segunda mientras hacemos el ping:

20:15:10.946400 ARP, Request who-has 192.168.2.31 tell 192.168.2.29, length 46
20:15:10.946409 ARP, Reply 192.168.2.31 is-at 10:c7:43:8a:dc:8d, length 28

Vemos como los broadcast de petición who-has si que nos llegan ya que estos no tienen ninguna MAC de destino asociada, pero al contestar la segunda máquina los paquetes son descartados y el mensaje anterior se repite ya que la primera máquina va repitiendo al no encontrar ninguna máquina que conteste con su MAC a la petición .
Si después de hacer el ping ejecutamos en la primera máquina lo siguiente:

# arp- a

Nos da la siguiente salida :

? (192.168.2.31) at <incomplete> on eth1

Lo cual nos confirma que los paquetes de respuesta de la IP en la petición ARP no está llegando a la primera máquina .
Vamos a hacer la misma prueba borrando las reglas de Open vSwitch que no permiten el tráfico más que en la MAC asignada , ejecutamos los siguientes comandos en la máquina física:

ovs-ofctl del-flows <bridge> dl_src=<mac>
ovs-ofctl del-flows <bridge> in_port=<port>

donde <bridge> es el bridge sobre el que estamos poniendo las máquinas virtuales , <mac> es la MAC inicial de la segunda máquina y <puerto> es el puerto virtual sobre el que se ha creado la máquina virtual en el bridge .
Ahora hacemos un ping desde la primera a la segunda y viceversa y vemos cómo efectivamente llegan los pings después de haber falseado la MAC de la segunda . Si miramos la tabla ARP de la primera máquina :

# arp- a

Vemos lo siguiente:

? (192.168.2.31) at 10:c7:43:8a:dc:8d [ether] on eth1

Así pues vemos como efectivamente la máquina está viendo la MAC falseada.
En este apartado tan sólo hemos comprovado que efectivamente funciona el control de MAC-Spoofing en OpenNebula, en el próximo apartado vamos a ver cómo OpenNebula no tiene implementado el control de IP-Spoofing y como implementar éste.

IP-Spoofing

Si cambiamos la IP a una máquina con OpenNebula veremos cómo efectivamente és possible falsear las IPs que OpenNebula assigna a nuestra máquina virtual. Los comandos vistos en el anterior apartado para que no sea posible hacer MAC-Spoofing són los siguientes:

# ovs-ofctl add-flow <bridge> in_port=<port>,dl_src=<mac>,priority=40000,actions=normal
# ovs-ofctl add-flow <bridge> in_port=<port>,priority=39000,actions=drop

Los comandos que se ejecutan para añadir los filtros, cómo vimos en la segunda entrega:

# ovs-ofctl add-flow <bridge> tcp,dl_dst=<mac>,tp_dst=<port>/<mask>,dl_vlan=<vlan>,actions=drop

y para añadir el filtro icmp:

ovs-ofctl add-flow <bridge> icmp,dl_dst=<mac>,dl_vlan=<vlan>,actions=drop

Vemos pues que no se está aplicando ningún filtro si la IP no corresponde a la que se ha definido, también hemos visto ya en el apartado anterior cómo el segundo comando del primer bloque nos filtra todo el tráfico que pase por la puerto virtual asignado a la máquina virtual , pero con una prioridad menor a la primera, que lo que hace es dejar pasar el tráfico del puerto en cuestión que coincida con la MAC de la máquina virtual.
Para el fin de que en el primer comando se filtre también lo que no coincida con la IP , necesitamos añadir el tag nw_src=<ip> , pero para añadirlo open vswitch nos obliga definir el protocolo cómo IP, ya que por ejemplo con el protocolo ARP no tiene sentido, para definir el protocolo como IP lo haremos añadiendo dl_type=0x0800
Así pues el primer comando queda de la siguiente forma:

# ovs-ofctl add-flow <bridge> dl_type=0x0800,in_port=<port_virtual>,dl_src=<mac>,nw_src=<ip>,priority=40000,actions=normal

Con este comando, pero vemos que mientras antes se dejava pasar el tráfico ARP, ahora no se está permitiendo, así pues necesitamos añadir una nueva regla que deje pasar el tráfico ARP para la MAC correspondiente. Para especificar el tráfico ARP se hace con dl_type=0x0806. Así pues, la regla quedará de la siguiente forma:

# ovs-ofctl add-flow <bridge> dl_type=0x0806,dl_src=<mac>,in_port=<port_virtual>,priority=40000,actions=normal

Una vez aplicada la regla se ha probado y funciona correctamente el control de IP-Spoofing.
Con este post terminamos la serie de Open vSwitch y OpenNebula. Para bajar el driver entero, se puede bajar de aqui.
Un saludo des del cloud! 😉

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 Social

Videos del I Congreso de Seguridad en la Red. (UOC-Con)

.
El pasado 4 de Junio se celebró en Barcelona el I congreso de seguridad en la red (UOC-Con) organizado por la UOC. Las charlas, muy interesantes, se enfocaron a ciberguerra y ciberespionaje.
Sin más os dejamos los videos de cada  una de ellas, no tienen pérdida.




Jesús Luna García – Generando Confianza en el Cloud



Vicente Díaz – 2013: Del cibercrimen a la ciberguerra



David Barroso – Ataques dirigidos a activistas



Chema Alonso – WorldWar III

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

Categories
General Security

Guía de Seguridad en el Cloud Computing

En el grupo de Security by Default de Linkedin nos enlancan una interesante guía de Seguridad en áreas críticas en el Cloud. Esta tiene en cuenta aspectos legales, administrativos y técnicos.

Guía de Seguridad en áreas críticas del Cloud Computing V 3.0 formato PDF: https://www.ismsforum.es/ficheros/descargas/guia-csa1354629608.pdf

CRYPTEX – Seguridad de la Información seguridad-informacion.blogspot.com.es

El Capítulo Español de la Cloud Security Alliance, CSA-ES, ha completado los trabajos de traducción al español de la guía de CSA Global “ Security Guidance for Critical Areas of Focus in Cloud Computing”.  Esta Guía es la mejor y más completa referencia a nivel internacional sobre las medidas de seguridad y aspectos a tener en cuenta que pueden aplicar las organizaciones que desean apoyarse en los servicios que ofrecen la Nube o que desean migrar sus servicios TI actuales a ella. (leer más)

Comité Técnico Operativo de la Cloud Security Alliance España