Search Results for: cloud

Evadiendo por la via rápida el challenge de CloudFlare for-fun-and-profit

Para hoy tenemos una entrada de Vicente, un antiguo compañero de S2 Grupo, administrador de sistemas y fanático de la naturaleza. Se le puede encontrar en su twitter @vicendominguez y en su blog.

¡Buenos días amigos! Vuestro sysadmin favorito al teclado hoy. Vamos a la materia.

En el mercado existen multitud de herramientas para pentesting. Todas ellas incorporan sistemas de evasión tanto de IDS, como WAF etc.; nmap incorpora fragmentación, cloak, decoys, spoof, custom data packet; sqlmap lleva check-waf y un montón de tampers, y así casi-todas. Echadle un vistazo porque la lista de aplicaciones que usáis todos los días para vuestros pentest favoritos que incorporan estos extras es considerable. Además tienen cierto éxito con los habituales sistemas de protección/detección. Ya sabéis de lo que hablo. En detección: snort, suricata…; en protección-waf: modsecurity, naxsi… y todos estos requieren algunos esfuerzos “extras” para detectar todas las posibilidades existentes. Bien. Fantástico.

Y luego de todo esto, tenemos CloudFlare.

[Read more…]

Paseando por las nubes: una visión panorámica de la computación cloud

Este lunes y martes, 8 y 9 de julio respectivamente, se celebró en el campus universitario de Albacete un curso de verano dedicado al Cloud Computing, organizado por personal de la propia Universidad de Castilla – La Mancha.

Nos brindaron la oportunidad de participar y aportar nuestra visión sobre los aspectos de seguridad que deberíamos contemplar cuando planteamos hacer uso de servicios en la nube.

Este curso fue moderado por la Drª. Dª. Carmen Carrión y por la Drª. Dª. Blanca Caminero (ambas profesoras titulares del Departamento de Sistemas Informáticos de la Universidad de Castilla – La Mancha). En el mismo se trataba de abordar una visión de la situación, uso, evolución y adopción de las soluciones en la nube en la actualidad, desde distintos puntos de vista. Abarcando desde la perspectiva del cliente a la del proveedor desde aspectos de seguridad hasta aspectos puramente prácticos.

[Read more…]

Real Cloud Security

(Please note this post was originally published in the Spanish version of Security Art Work last 2th Oct 2012)

Acto I: La nube

(En una pequeña sala están reunidos el Director General, el Director de Seguridad y el Director de Marketing. Éste viene con la PC Actual debajo del brazo)

CMO: Blablablabla Cloud blablabla costes blablabla disponibilidad blablablabla Google.
CSO: Blablabla SLA blablabla, blablabla LOPD, deslocalización, blablabla blablabla privacidad, blablabla.
CEO: Blablablabla euros, blablabla personal, IT blablabla servidores. ¿Seguridad? Blablablabla.
CSO: Blablabla, blablabla LOPD, sanciones, blablabla robo de datos, blablabla prensa. Blablabla impacto y riesgo.
CMO: ¿Inseguro? Jajajajaja, blablabla, blablabla y blablabla. CSO blablabla, desconfianza. Blabla, blabla, Gartner, ¿blablabla? Blablablabla. Eso no pasa.
CEO: Blablablabla CIO, blablabla IT blablabla presupuesto.
CSO: Alea jacta est.

Acto II: Miel sobre hojuelas

(Mientras el Director General observa el tablet del Director de Marketing ven pasar al Director de Seguridad, quien acelera el paso pero es interceptado en pleno pasillo)

CMO: Blablabla acceso, blablabla iPad, iPhone. ¿Blablabla? ¿CSO? Blablabla, estos de seguridad blablabla. Acceso, blablabla, password blablabla, blablabla SSL.
CEO: Blablabla cómodo, blabla, blablabla acierto. Blablablabla razón, costes blabla, blablabla empresa 2.0.
CSO: Pater Noster qui es in caelis, sanctificétur nomen Tuum

Acto III: Un pequeño problema

(Ha pasado algo en las Islas Marshall que ha inutilizado la conexión con el proveedor de cloud y, no se sabe aún, puede haber ocasionado pérdida de datos)

CEO: Blablabla corte, blabla borrado, blablabla acceso. ¡¡Blablablabla datos, blablabla nube!!
CMO: Blablablabla probabilidad, blabla Gartner blablablabla CIO, blabla CSO.
CSO: Blablabla riesgo, blablabla impacto, blabla calidad de servicio, blablabla Google.
CEO: Blablabla reputación, blablabla negocio, ¡blablabla Google!
CMO: …
CSO: …

Acto IV: Elige tu propia aventura

(¿Os acordáis de estos libros? Pues en este post lo mismo ;)

Opción #1

CSO: Blablabla backup, blabla ignífuga, blablablabla recuperación, sistema blablabla.
CEO: Muacs.

Opción #2

10 CEO: …
20 CMO: …
30 CSO: …
goto 10

Opción #3

CSO: Blablablabla ¿CIO?
CIO: Blablabla, Terms of Service, blablablabla denuncia, blablabla compensación, blablablabla.
CEO: Blablabla datos, blablabla disponibles blablabla por mis #@!*& blablabla diez euros.

¿Qué, cómo ha acabado la aventura en la nube?

Por cierto, si has sido capaz de seguir esta conversación, quizás te interese este vídeo que ha localizado nuestro compañero Adrián:

Requisitos del ENS para proveedores de Cloud Computing

Algunos de ustedes se habrán planteado sin duda la posibilidad de externalizar algún plataforma a un servicio cloud, o hacer uso de alguna herramienta SaaS. Además seguramente la mayoría se habrán cuestionado acerca de las implicaciones de seguridad que puedo conllevar delegar la gestión de la información en un proveedor. Efectivamente, la gestión de la información y de los servicios por un tercero supone la pérdida parcial de control sobre sus sistemas de información y no nos engañemos, el ser humano no es un fan acérrimo de la incertidumbre (que se lo digan a los mercados…), a la vez que esta externalización supone que cierta parte de la gestión de los riesgos y el cumplimiento legal recaiga en el tercero.

Anteriormente en este blog ya hemos hablado en alguna ocasión sobre el cloud computing ([1] [2] [3] [4] [5]). Así pues de acuerdo con lo expuesto, en este post intentaremos arrojar un poco de luz sobre los aspectos legales que deben ser tenidos en cuenta a la hora de contratar un servicio en la nube, aunque solo entraremos en detalles referentes al cumplimiento del ENS y no de un modo exhaustivo.

Si somos un Administración Pública afectada por el ENS, tendremos en cuenta las consideraciones descritas en el punto 4.4. del Anexo II del ENS, como se indica a continuación:

4.4 Servicios externos [op.ext].

Cuando se utilicen recursos externos a la organización, sean servicios, equipos, instalaciones o personal, deberá tenerse en cuenta que la delegación se limita a las funciones.

La organización sigue siendo en todo momento responsable de los riesgos en que se incurre en la medida en que impacten sobre la información manejada y los servicios finales prestados por la organización.

La organización dispondrá las medidas necesarias para poder ejercer su responsabilidad y mantener el control en todo momento.

Este punto comprende 3 apartados:

  • 4.4.1 Contratación y acuerdos de nivel de servicio (solo aplicable a sistemas categorizados de nivel medio o alto)
  • 4.4.2 Gestión diaria (solo aplicable a sistemas categorizados de nivel medio o alto)
  • 4.4.3 Medios alternativos (Solo aplicable a sistemas con disponibilidad categorizada de nivel alto)

En primer lugar, previo a la contratación se deberá hacer o revisar el análisis de riesgos, para evaluar si el riesgo que introducimos al migrar servicios a la nube es mayor que el de tener los sistemas de información en local, en cuyo caso deberemos valorar si el nivel de riesgos es superior al criterio asumible por la Dirección de la entidad, siempre teniendo en cuenta los aspectos contractuales ofrecidos por el proveedor.

En lo referente al punto 4.4.1 el contratante deberá requerir contractualmente, siempre y cuando vaya a migrar servicios categorizados de nivel medio o superior:

  • Descripción del servicio, identificando el lugar o lugares donde residirán los sistemas.
  • Acuerdos de nivel de servicio.
    • Tiempo de respuesta ante desastres.
    • Tiempo de recuperación del servicio.
    • Porcentaje de disponibilidad del servicio.
    • Penalizaciones.
  • Funciones y obligaciones.
  • Devolución o destrucción de la información tras la finalización del acuerdo

Además, en caso de que se incluya el tratamiento de datos, éste deberá estar regulado de acuerdo a lo estipulado en el artículo 12 de LOPD, y siempre teniendo en cuenta las implicaciones que puedan las transferencias internacionales de datos.

Por otra parte, de acuerdo al apartado 4.4.2. Gestión diaria, es necesario establecer un proceso de monitorización para ver cumplimiento de SLA así como otras obligaciones que estén incluidas en el servicio, procedimientos de coordinar mantenimientos (como puede ser actualizaciones) y procedimientos para coordinación de incidencias y desastres. Por último de acuerdo con el punto 4.4.3 se deberán aportar garantías de disponibilidad del servicio ante la caída del servicio contratado. Es decir, que además de disponer de SLA ante desastre, el proveedor disponga de medidas que permitan la continuidad de negocio.

Sin entrar a detallar de modo exhaustivo los requisitos en la contratación de servicios cloud, he querido dar unas pinceladas rápidas de los aspectos que deben ser revisados por las Administraciones Públicas para la contratación de estos servicios. Por otra parte, los principales proveedores se ubican fuera del ámbito nacional, haciendo uso de infraestructura ubicada a su vez en otros países, por lo que están sujetos a legislación que puede ser equiparable o no la Española. Por ello, un aspecto recomendable sería la existencia de un certificación de acuerdo con la norma ISO 27001 cuyo alcance incluyan los servicios de Cloud Computing, para disponer de unas garantías de seguridad razonables.

Sin lugar a dudas el Cloud Computing está de moda, pero la controversia está servida cuando se trata de seguridad en la nube y no hay ninguna duda de que queda un largo recorrido cuando de asegurar la nube se trata. Pasen, con nubes o sin ellas, un buen fin de semana.

[Sobre el autor]

El cloud más seguro… y más dulce

(N.d.E. Después de las entradas técnicas de los últimos días, hoy traemos una visión diferente y más «fresca» del cloud)

Desde hace ya tiempo existe un consenso general sobre el hecho de algo está pasando, algo grande y profundo que, todavía hoy, no estamos muy seguros de lo que en realidad es.

Mucho se ha hablado acerca del cloud computing, y no es mi intención aburrir más a la audiencia con el tema. Ya parece que más o menos estamos todos de acuerdo de lo que estamos hablando. ¿O no?

Hace un par de años cayó en mis manos un estudio sesudo de una fundación innovadora acerca de eso que estaba generando tanto entusiasmo y alboroto. Me gustó la explicación que daban acerca del concepto. Se preguntaban entonces que era exactamente el cloud computing: ¿la evolución de internet? ¿Un nuevo modelo de computación? ¿Una forma de ofrecerlo todo como servicio? ¿O quizá suponía la industrialización de las tecnologías de la información, como ocurrió hace un siglo con la electricidad cuando se empezó a usar de forma masiva en la economía y en la sociedad?

El cloud computing, en su opinión, era todo lo mencionado y algo más. Era como la fábula de los ciegos y el elefante. Cada uno toca una parte diferente del elefante. Después comparan lo que han percibido y se dan cuenta de que están en completo desacuerdo.

[Read more…]

Cloud computing, el análisis de riesgos y los “servicios dinámicos” de seguridad

A estas alturas todos estaremos de acuerdo en que nos enfrentamos a cambios singulares en la forma de entender la gestión de las infraestructuras TIC. La irrupción de los servicios de cloud computing, y con ellos la IAAS “Infraestructure as a service”, va a provocar en los próximos años una reestructuración de gran calibre en este tipo de servicios, en buena parte consecuencia del desarrollo masivo de los servicios de virtualización que nos permite cambiar nuestras máquinas virtuales de CPD o datacenter en un abrir y cerrar de ojos, al menos teóricamente.

Todo esto tiene unas implicaciones en materia de seguridad de proporciones colosales. Los modelos de seguridad actuales, fundamentalmente “estáticos”, tienen que evolucionar a modelos de seguridad “dinámicos” adaptados a las necesidades de los servicios en la nube, porque esta tendencia no tiene vuelta atrás. No se trata de que opinemos si es mejor o peor la seguridad de los servicios “cloud”, se trata de que diseñemos servicios de seguridad adecuados a esta realidad, que como todo tiene aspectos positivos y aspectos negativos.

Ganamos en algunas cosas. Uno de nuestros puntos débiles en la seguridad ha sido siempre la disponibilidad y la continuidad de negocio. En este caso, en la nube, con escenarios de siniestro complicados como la caída de un datacenter por un desastre natural, la solución parece al alcance de cualquiera y los RTO parecen asumibles por cualquier tipo de negocio. Es evidente que hay muchas cosas que rediseñar en los servicios de seguridad en la nube.

Tomemos el caso de Google que tenía, en 2008, 36 localizaciones para sus centros de procesos de datos con entornos virtualizados que les permite cambiar estas ubicaciones de forma, digamos, “ágil”. Uno de sus objetivos es, lógicamente, minimizar el coste de hospedaje de su infraestructura y dado que podemos asumir que en un datacenter el 50% del coste es el coste energético de la refrigeración, entenderemos que los gestores de la infraestructura de Google busquen términos de eficiencia energética cada vez mejores. Por lo que hemos leído el factor PUE (Power use efficency) alcanzado por Google es impresionante: 1,21 de media. Esto supone que cada watio útil que llega a una máquina que da servicio a sus clientes necesita 1,2 watios de consumo real. Evidentemente esto se puede conseguir haciendo uso de datacenters que requieren poco uso energético para refrigerar las maquinas y por tanto llevándose, por ejemplo, los sistemas a localizaciones frías que utilicen aire del ambiente para refrigerar las salas técnicas. Todo esto se puede además complicar utilizando estrategias tipo “follow the moon” mediante las que buscamos tarifas nocturnas de consumo energético y por tanto tarifas económicas que, en definitiva, permiten reducir el coste de suministro eléctrico de la máquina y directamente el coste del servicio.

Si en este entorno empezamos a pensar en seguridad la primera reacción es la de estupefacción. Si ya es complicado conseguir un nivel de seguridad adecuado en entornos estáticos desde el punto de vista físico, si el entorno lógico, con la virtualización, es un entorno altamente cambiante y además el físico también, el resultado es directamente un manicomio especializado en la práctica de torturas, como medida terapéutica, para los profesionales de la seguridad.

Evidentemente este escenario que se nos viene encima no es compatible con las prácticas de seguridad actuales de la mayor parte de las empresas especializadas en este tipo de servicio. Este escenario nos está pidiendo a gritos que adaptemos las políticas, los procedimientos, los controles, los sistemas de monitorización y gestión de la seguridad a estos entornos que cambian a una velocidad endiablada.

Pensemos, por ejemplo, en un análisis de riesgos tradicional. En nuestra opinión, los análisis de riesgos tradicionales son ya de por si poco útiles, sobre todo si hacen uso de metodologías pesadas y complejas como puede ser el caso de algunas metodologías que todos conocemos ;-). Vaya por delante que son metodologías muy valiosas y que conforman un buen punto de partida teórico, pero que en mi opinión no pueden ser utilizadas de forma práctica sin los matices pertinentes. ¿Por qué? Básicamente porque nos enfrentamos a entornos en continuo cambio. Cuando se diseñaron este tipo de metodologías se hicieron pensando en infraestructuras manejables, con evoluciones tranquilas, y en las que revisar el análisis de riesgos periódicamente una vez al año podía ser suficiente. Estas no son las hipótesis de partida a las que nos enfrentamos hoy y por tanto estas metodologías no sirven cuando las aplicamos tal cual fueron diseñadas.

Nos enfrentamos a entornos cambiantes desde el punto de vista lógico, con continuas variaciones que tienen impactos en la estrategia de seguridad clarísimos y por si fuera poco, en virtud de lo comentado en la introducción de esta entrada, nos enfrentamos también a entornos físicos cambiantes. En estas circunstancias las amenazas son variables, sus probabilidades también y por tanto los riesgos también. En definitiva, dentro del marco de servicios dinámicos de seguridad al que nos hemos referido, tendremos que diseñar metodologías ágiles de análisis de riesgos en tiempo real.

Mucho vamos a tener que trabajar para poder definir un marco global de productos y servicios de seguridad dinámica en este nuevo entorno, y mucho tienen que opinar lectores asiduos de este blog en esta materia… pasen en cualquier caso, ya sea pasados por agua o no, un buen fin de semana.

Seguridad en Cloud computing

He decidido poner el término Cloud computing en el titulo del post para tener mas visitas, ya que es un termino de moda, pero si me disculpan la pequeña «trampa», en su lugar voy a hablar de la seguridad en Infraestructuras compartidas, que es un tema tanto o más interesante en seguridad.

Cuando hablamos de Infraestructuras compartidas nos referimos a la serie de infraestructuras TI que en cualquier organización son compartidas por diversos proyectos. Por ejemplo es habitual que se comparta la infraestructura de red, el almacenamiento en una cabina de discos, o los mismos servidores físicos mediante virtualización; si es un proveedor de servicios el que ofrece la infraestructura, estos elementos estarán compartidos además entre diversos clientes que en si mismo son organizaciones diferentes (vamos, el servicio de hosting de toda la vida).

Así pues, vamos a comentar diversas vulnerabilidades que con las medidas adecuadas están contempladas y en teoría resueltas, pero que son en todo caso posibles vulnerabilidades que pueden aparecer cuando se comparten infraestructuras.

Infraestructura de red compartida: No es difícil imaginar un escenario donde tenemos varios servidores conectados a la misma infraestructura de red, donde, si todo se configura bien no deberían haber problemas, pero si se configura mal, pueden pasar entre otras las siguientes cosas: (1)

  • Sniffing: Un equipo puede ver el trafico del equipo de al lado; esto puede pasar si están conectados al mismo switch y no se han tomado las necesarias precauciones (arp posisoning).
  • DOS: Al estar un equipo próximo a otro, puede atacarlo con un gran ancho de banda o un gran numero de conexiones.
  • Interceptar/sustituir: Es posible que un equipo pueda suplantar a otro (p.e. cambiando la IP) para interceptar el trafico o suplantar respuestas.
  • Atacar: Es posible que al compartir una misma infraestructura de red, desde dentro de la misma red (por ejemplo dentro de la misma DMZ) los equipos puedan atacar a los otros, teniendo mas visibilidad de servicios que desde el exterior están cerrados. Una descripción de cómo hacer esto pueden encontrarla aquí.

¿Están las infraestructuras de red compartidas convenientemente independizadas en los servicios de hosting y de Cloud?

Infraestructura de disco compartida: En cualquier infraestructura TI, es habitual que se disponga de una cabina de disco (SAN/NAS) a la que se conectan todos los servidores (desde servidores internos, hasta servidores de la DMZ)(2)

  • Acceso a datos (no autorizados): Técnicamente es posible que un servidor se conecte al disco de otro servidor si comparte cabina, con lo que podría leer o incluso alterar los datos. Las cabinas de disco normalmente limitan qué servidor puede conectar a qué parte de disco, basándose en la direccion «MAC» (se llama WWN) de la tarjeta. ¿Podría un hacker cambiar esa dirección? ¿Tenemos hard-zoning para evitar este ataque? Aun no he visto ninguna instalación en que se configure hard-zoning ya que es bastante mas incómodo. Si piensa que es muy raro que todos los servidores tengan acceso a los mismos discos, piense en todos sus servidores host de virtualizacion que pueden acceder a todos los discos del cluster.
  • DOS/Carga: ¿Qué pasa si un servidor monopoliza todos los recursos?
  • Acceso a datos borrados: ¿Qué pasa si montamos una unidad de disco en el servidor de un cliente y luego la conectamos a otro servidor de otro cliente? ¿Si leemos el disco vemos los datos del otro cliente? Muchos me diréis que es una posibilidad muy extraña ya que las cabinas de discos limpian las LUNs antes de asignarlas, pero esto «se le paso» a Amazon Ec2.

¿Están las infraestructuras de almacenamiento convenientemente independizadas en los servicios de hosting y de Cloud? (3)

  • Virtualización: Cualquier entorno TI de hoy en día dispone de servidores virtualizados, ya que es una de la manera mas efectivas de compartir recursos, garantizar la disponibilidad, ahorrar energía y muchas otras cosas. Numerosos sistemas Cloud (IAAS) están basados fundamentalmente en sistemas virtualizados, con APIs de autoprovisionamiento. Veamos algunos de los ataques que se pueden realizar en este tipo de entornos.
    • Ataques de guest a host: Ya han aparecido vulnerabilidades mediante las cuales un guest ha podido ejecutar código en el espacio del host, y por lo tanto desde un servidor virtual es posible atacar a otras maquinas virtuales. Véase este enlace para más detalles.
    • Consolas remotas compartidas (el «control panel» del cloud): Si tenemos un sistema de virtualización compartido, al cual accedemos desde una consola de gestión remota a través de Internet, ¿qué pasa si esta consola de gestión tiene alguna vulnerabilidad y alguien coge el control? Pueden haber muchos posibles problemas, desde vulnerabilidades de la aplicación de gestión remota (XSS para robo de sesión sería un ataque viable) a posibles pérdidas de credenciales. La autenticación de estos sistemas por ahora es simple y sin dispositivos robustos. Otro vector de ataque pueden ser las APIs de gestión de ofrecidas por los servicios de cloud, ya que mediante estas APIs se pueden crear o destruir servidores; ¿seguro que no hay vulnerabilidades mediante las cuales se puedan crear o destruir servidores de otro cliente?
    • Carga/DOS/QOS: ¿Qué pasa si un cliente monopoliza todos los recursos?
    • Vulnerabilidades del host (desde fuera, o desde los guests): El host es otro sistema que puede ser atacado, bien desde donde sea accesible (consola de gestión p.e.) o bien desde los propios guest que debido a alguna vulnerabilidad son capaces de coger control de host. Dicho de otra forma, aunque uno pueda tener su servidor web y sus aplicativos securizados, quizá el host que los alberga no lo está.
  • Servidores web/servidores de aplicaciones compartidos: Es habitual compartir el mismo servidor de aplicaciones entre diversos proyectos, pero hay que contemplar los problemas que nos podemos encontrar:(4)
    • Tienen acceso al mismo almacenamiento.
    • Son el mismo usuario de maquina/BBDD/memoria.
    • QOS: Puede un usuario degradar el rendimiento de todos los usuarios.

    Un ejemplo de estos servicios en la nube son: Windows azure o Google Application Engine.

¿Están las infraestructuras de virtualización convenientemente independizadas en los servicios de hosting y de Cloud?

Hosting/Aplicaciones SAAS compartidas: Dentro de lo que está tan de moda del cloud, también se incluyen de alguna manera las aplicaciones compartidas modelo cloud (SAAS). En el fondo, éste es el modelo mas antiguo de hosting, en el que las aplicaciones originales eran servidores web, servidores de correo compartidos entre diversos clientes. Hoy en día se ofrecen aplicaciones mas elaboradas que ofrecen más valor a las organizaciones. Veamos qué problemas nos podemos encontrar en estos modelos.

Imagínese que comparte aplicación entre «perfiles» o clientes. Es posible que dos usuarios de la misma aplicación, por algún error de diseño de ésta, tengan acceso a lectura o modificación de otro usuario. Por ejemplo, recordarán que hace poco sucedió que un usuario de facebook podía ver cualquier conversación del chat de otro. Así pues, si usamos de manera compartida una «aplicación» SAAS, nos podemos encontrar con posibles problemas si no ésta no está bien implementada. ¿Podría pasar que en nuestro CRM en SAAS por un error de programación pudiéramos ver los clientes de otra empresa también albergada en este SAAS? Facebook tuvo una vulnerabilidad con la que podías ver los chats de otros usuarios.

¿Están las aplicaciones convenientemente independizadas en los servicios de hosting y de Cloud? (5)

Mira por dónde, sin quererlo, he acabado hablando de Cloud Computing, nada nuevo respecto a lo que ya conocemos en cuanto a infraestructuras compartidas, pero sin duda una novedad en cuanto a que está todo junto, con las ventajas que esto aporta, pero con el añadido que hay que considerarlo todo conjuntamente.

Por repasar los tipos de Cloud existentes:

  • IAAS, Infraestructure as a service: básicamente podríamos decir que tenemos una macroplataforma virtualizada bajo demanda (1)(2)(3).
  • PAAS, Platform as a Service: tenemos una especie de servidor de aplicaciones distribuido y autoescalable (4).
  • SAAS, Software as a Service: tenemos una aplicación general la cual nos da servicio (5).

En este post hemos revisado algunas vulnerabilidades desde un punto de vista técnico que aparecen si compartimos infraestructuras. Desde el punto de vista de control sobre los servicios externalizados y concentrados en datacenters de megacorporaciones también hay mucho que hablar, y por otro lado los proveedores de sistemas virtuales están redefiniendo sus productos haciendo que cada vez se parezcan mas a una nube «privada» en cuanto a que se dispone de unas infraestructuras compartidas autogestionadas. Todas la posibles vulnerabilidades mencionadas sólo son posibles puntos de fallo por donde aparecerán vulnerabilidades, que aunque en principio ya están contempladas y cubiertas, debemos contar que irán apareciendo nuevas vulnerabilidades causadas por compartir infraestructura. Si dicha infraestructura es sólo compartida entre proyectos internos de la organización los riesgos son unos, pero si la infraestructura es compartida con no sabemos quién, y disponible en Internet los riesgos son mayores. Esto es lo que hay que saber valorar.

A pesar de ello, los servicios en Cloud son la evolución lógica de hosting (infraestructuras compartidas de toda la vida). Todo lo que tuviera sentido en ese entorno ahora lo puede tener en la nube; en todo caso los proyectos que necesitan una grandísima escalabilidad normalmente están asociados a accesos desde Internet, en cuyo caso la nube tiene todo el sentido del mundo, ya que nos permite acceder a proveedores con grandes capacidades de almacenamiento, ancho de banda y servidores. Es más, me atrevería a apostar que los proveedores serios de Cloud sí tienen en mente que todos los recursos compartidos deben estar independizados, y probablemente sean más conscientes de estos riesgos que los provedores de hosting más tradicionales, con aproximaciones más «ligeras» al Cloud.

Dicho esto, pasen un buen fin de semana, y ¡¡nos vemos en la nube!!

¿Qué pasa con la Seguridad y el Cloud Computing?

Algunos tuvimos la oportunidad de celebrar el pasado día mundial de Internet con una mesa redonda sobre Cloud Computing en la que participaron ocho personalidades de distintas multinacionales, de las que solo una de ellas era española. La mesa redonda estuvo moderada por la Consejera de Justicia y Administraciones Públicas de la Generalitat Valenciana y la verdad es que fue bastante interesante, e incluso yo diría que pertinente y adecuada en los tiempos que corren, tanto por la forma, como por el fondo.

Cloud es una moda. Todos estaban de acuerdo en que ya no es una utopía. Es una realidad, pero una realidad de moda. También parecían estar todos de acuerdo que una de las grandes ventajas que tiene este nuevo paradigma (así lo presentan algunos) es la reducción de costes. “Es una nueva forma de hacer outsourcing en un entorno global y virtual”, decían algunos. “Es una forma clara de reducir costes e incluso de incrementar la productividad”, decían otros. La verdad es que en medio de todas estas afirmaciones, vertidas incluso en ocasiones con pasión, yo me preguntaba si no será este otro de esos conceptos que usan las grandes firmas para seguir haciendo negocio con cosas que el resto de los mortales no acaban de entender.

En mi humilde opinión Cloud Computing es un concepto muy interesante que seguro ya tiene y tendrá aplicaciones en diversos campos, ahora bien, la solución a todos los problemas no es el Cloud Computing, ni siquiera es un modelo de gestión o una tecnología disruptiva equivalente, como algunos defienden, a la aparición de Internet. Para empezar, porque es un modelo que ya funciona en la red desde hace tiempo y porque lo único que se ha hecho es bautizarlo con un nombre pegadizo que estoy seguro moverá cifras millonarias en los próximos años.

Se habla de la consolidación de unos cuantos Data Centers gigantes a nivel mundial como proveedores de servicios en la nube y su connivencia con unos cuantos operadores y algunos proveedores de aplicaciones en la misma nube. Se habla del traslado de cantidades ingentes de información a la nube, de información de todo tipo y color, se habla de los inmensos beneficios que le puede suponer para una empresa de tamaño medio hacer uso de este modelo, e incluso, alguno se atreve a poner un ejemplo dónde los ahorros de costes superan el 50%, citando incluso la organización en cuestión.

Yo no sé si esto será exacto o si será una “realidad aumentada”, pero ¿alguien se ha parado a pensar lo que realmente significa esto? ¿Alguien se ha parado a pensar en las implicaciones de seguridad que puede tener el traslado indiscriminado del conocimiento de las organizaciones de todo tipo a la nube? ¿Alguien se ha parado a pensar en el riesgo de la concentración de activos y conocimiento para una compañía o para un estado? Si a veces no pueden las organizaciones confiar en sus propios equipos, ¿por qué van a hacerlo en los equipos de terceros de forma masiva e indiscriminada? ¿No creen ustedes que aunque este modelo tiene y va a tener sentido para algún tipo de aplicaciones e información no lo puede tener nunca para otro?

Yo creo que como siempre se han hecho algunos análisis interesados de las virtudes de este concepto y que se han propagado a los cuatro vientos sus ventajas, pero también creo que no se ha contado de la misma forma sus inconvenientes, aunque me consta que si se han analizado. No hay más que ver el estudio que ha publicado recientemente la Cloud Security Alliance (CSA) [PDF] donde tímidamente o superficialmente (como quieran ustedes llamarlo) analizan los principales problemas de seguridad con los que se encuentra el Cloud Computing llevado a sus extremos. Cloud Computing es por tanto una moda con grandes virtudes y con grandes defectos. Si no se desarrolla con sumo cuidado, el mismo concepto es, en sí mismo, una amenaza para la seguridad de las organizaciones. No conté las palabras que se usaron en la mesa redonda pero les aseguro que la palabra Seguridad salió muchas veces y la usaron todos los participantes en la mesa redonda, incluyendo algunos invitados del público. Evidentemente esto quiere decir algo, ¿no creen?

Seguro que seguiremos hablando del recién nacido “Cloud” porque va a dar mucho juego….

Detectando dominios “demasiado” legítimos

A la hora de utilizar un dominio para la comunicación con el servidor de mando y control y/o de exfiltración, los grupos de mayor sofisticación suelen utilizar nombres que pasan desapercibidos en un primer vistazo (e incluso hasta después de varios) por los analistas.

La utilización de palabras del ámbito tecnológico o relacionadas con el sector de la organización suelen proporcionar una capa adicional de ocultación en las ya de por sí discretas comunicaciones. Sin embargo, ¿podemos detectar estos dominios?

El objetivo del siguiente artículo es buscar patrones entre los IoC de diferentes APT y compararlos con el listado del millón de dominios más utilizados que proporciona Alexa, de cara a generar un algoritmo que permita ponderar la probabilidad de que un dominio intente hacerse pasar por legítimo.

[Read more…]

Vientos remotos, tempestades locales (I)

[Nota: Esta serie de posts es una narración de un análisis forense de un caso práctico de respuesta ante incidentes totalmente ficticio (pero contada, esperamos, de forma didáctica y con gracia y salero). Si queréis una versión con la misma dosis técnica pero con menos narrativa, podéis consultar el vídeo de la charla que el autor dio en las XIII Jornadas STIC del CCN-CERT, o echar un ojo las slides de la presentación].

[Nota 2: Estos posts desgranan un taller de análisis forense englobado dentro de la respuesta ante un incidente. Habrá algunas cosas que se podrían hacer de manera más eficiente y elegante, pero la idea era hacerlas de forma sencilla para que sean fáciles de entender. Y como todo buen taller práctico, se puede seguir paso a paso: el CCN-CERT está alojando en LORETO todo el material, que podéis descargar desde aquí. Tenéis tanto las evidencias en bruto (si queréis primero intentar encontrar el bicho por vuestra cuenta sin leer nada de la solución) como una guía paso a paso con todas las herramientas y evidencias necesarias en cada paso].


La semana no ha sido especialmente agradable para Ángela de la Guarda, CISO del MINAF (Ministerio de la Alegría y la Felicidad). A la media docena de reuniones para dar el último empujón a la implantación del ENS (Esquema Nacional de Seguridad) en el MINAF se ha sumado el papeleo de la renovación de varios contratos del área… y la crisis de la pérdida de la alta disponibilidad de uno de los sistemas críticos de la subdirección TIC del MINAF: se ha roto una de las dos máquinas de café (lo que significa una sola máquina para alrededor de 80 personas; imagina el aumento de la latencia y los timeout que ello implica).

Menos mal que ya estamos a viernes, y el fin de semana se acerca con un spa, la serie Fleabag y un rato de cacharreo con la Raspberry Pi 4… o esos eran los planes de Ángela hasta que recibe una llamada urgente del CCN-CERT (el por qué estas llamadas son siempre los viernes a las 14.15h es algo que solo $deity sabe, pero casi siempre son a estas horas). 

[Read more…]