El BYOD del Ministro del Interior

El escenario de la seguridad corporativa anda muy revuelto en los últimos meses debido a la nueva problemática de seguridad planteada por los usuarios finales respecto al poder usar sus propios dispositivos que se simplifica con el acrónimo BYOD ("Bring your own device").
Esta nueva problemática no es más que el fiel reflejo del difícil equilibrio entre la seguridad y la operatividad productiva en la empresa.  El impacto de esta tendencia, que viene para quedarse porque están siendo las capas directivas las principales precursoras de esa necesidad depende también de las circunstancias particulares de cada organización y de cómo haya ido resolviendo los problemas de gestionar la seguridad corporativa en estos últimos años.

El BYOD creo que no plantea mayores riesgos que los ya existentes respecto al uso de portátiles y los riesgos de interceptación de comunicaciones o dispositivos de almacenamiento USB y los riesgos de extravío o pérdida. Sin embargo, ahora se añaden como restricciones las posibles limitaciones respecto de la aplicación de las políticas corporativas de seguridad sobre dispositivos que no son propiedad de la organización. Obviamente a mayor número de dispositivos que pueden contener información corporativa, mayor probabilidad del extravío de algunos de ellos con las correspondientes fugas de información.

La noticia sale hoy a primera plana con la noticia de la pérdida del Ipad del Ministro del Interior. Según los datos aportados por la noticia, se tuvo que montar un operativo para tratar de recuperar el dichoso dispositivo que fue extraviado en un viaje en Ave. Los dispositivos Apple incorporan una funcionalidad de localización si se tiene activo el servicio iCloud y la funcionalidad de localización. Parece ser que efectivamente todos estos servicios estaban configurados y se pudo conocer la posición del dichoso aparato.

Resulta curioso leer el trozo del artículo donde tratan de quitarle hierro al asunto demostrando que el problema estaba controlado.

"En ningún momento ha habido preocupación por los contenidos que tenía", señala un portavoz de Interior, ya que el iPad del ministro tiene importantes medidas de seguridad. Si no se mete la contraseña correcta, se destruye toda la información que lleva.

Curiosamente estas son las medidas de seguridad estándar que lleva este tipo de dispositivos cuando se activa la clave de acceso. En cualquier caso, también se permite el borrado remoto si se tiene activa la funcionalidad de localización, cuestión que en ningún momento se aclara si finalmente fue empleada. Sin embargo lo que a mi me sorprende es que el Ministro del Interior tenga activa la cuenta iCloud y el servicio de localización GPS dado que potencialmente podría permitir tenerlo localizado y controlado. Si además suponemos que se emplean los servicios habituales de Apple para tal efecto, con algo de ingeniería social podrían tratar de localizar la cuenta iCloud del Ministro para tratar de obtener acceso a ella y a toda su información. Y es aquí cuando se plantea otro problema de seguridad que es la dispersión de información en servicios de Cloud sobre entornos de alta confidencialidad que en cualquier caso y por comprometer la seguridad del Estado, no deberían usar servicios externos y no controlados por la propia Administración (Bajo la premisa de que sea el servicio de iCloud el que haya permitido la localización del dispositivo).

En cualquier caso, el BYOD supone una reflexión seria para el mundo de la seguridad. Quizás esta tendencia supone un punto de inflexión respecto a las estrategias tradicionales que venían siendo utilizadas donde las tomas de decisiones se hacen en base a las necesidades de seguridad y el modelo de negocio pero teniendo al usuario como un "cliente/victima" de las imposiciones establecidas. El BYOD supone ahora tener que pensar y diseñar estrategias de seguridad bajo dos premisas importantes: "transparencia de las medidas" en el sentido de hacerlas lo más sencillas de utilizar para que no supongan una excesiva barrera de uso y "user center" en el sentido de que deben permitir o facilitar en la medida de lo posible la operatividad y acceso a los recursos corporativos para permitir a los empleados el trabajo desde cualquier lugar en cualquier momento. El BYOD es el triunfo de la movilidad materializado por la introducción de dispositivos tan sencillos de manejar como las tabletas que permiten disponer de un entorno de trabajo limitado pero suficientemente potente para poder resolver las cuestiones operativas más básicas como leer el correo, revisar documentación, elaborar escritos, etc.

En la problemática técnica para torear con el BYOD,  los riesgos se estratifican por diferentes capas y plantean cuestiones que tienen que ser resueltas desde perspectivas diferentes.

• La protección física del propio dispositivo que debe tratarse desde la seguridad física con pautas sobre la custodia y uso de estos elementos en entornos inseguros.
• La protección lógica del acceso y conexión a los sistemas de información corporativos, donde la autenticación toma ahora mayor relevancia dado que es el punto crítico para autorizar el acceso.
• La conectividad del dispositivo desde lugares externos a los sistemas de información en donde el uso de protocolos de comunicaciones seguros deben evitar la interceptación de comunicaciones y  el robo de credenciales.
• La protección lógica de la información que reside en el dispositivo donde la criptografía puede garantizar que frente a la pérdida o robo, no habrá fugas de información.
• A esto pueden añadirse el uso de tecnologías proactivas en la detección y control del flujo de información como podrían ser los sistemas DLP de los que ya hablé hace unos años pero que no parecen haberse popularizado demasiado. 

La receta anterior además debe reforzarse con una intensa monitorización y una estrategia basada en la detección de anomalías a las que contribuyen las herramientas SIEM que cada vez van a adquirir más importancia y que serán el verdadero corazón de la seguridad en los próximos años. Realmente lo que ocurre es que la seguridad lógica copia la misma estrategia de la seguridad física y la detección de incidentes y la notificación para su resolución son la operativa común que mejor funciona. El modelo policial y la notificación de incidentes vía teléfonos 112 que empleamos en el mundo físico y que tan buenos resultados ofrece.

Personas, confianza y cloud computing

La reflexión de hoy va a ser breve porque ha sido un día intenso. Ayer casi por casualidad leí en el muro de Facebook de un compañero una reflexión sobre cuales son los pilares que usamos las personas para construir la confianza en otras personas. En palabras de Jose María Gasalla, conferenciante, escritor y profesor de la Deusto Business School, la confianza que dan, depositan o generan las personas se sustenta sobre 7 pilares:

• Consciencia: entender a las partes implicadas y la situación en la que se encuentran.
• Claridad: compartir la realidad y obviar resto.
• Coherencia: predicar con el ejemplo, hacer a cabo aquello que piensas y dices.
• Consistencia: dar cuerpo a los valores que te representan.
• Cumplimiento: alcanzar con garantías los compromisos generados.
• Competencia: representar la profesionalidad, hacer las cosas bien.
• Coraje: ir más allá, hacer lo extraordinario. 

Hoy tocaba hablar con los compañeros de Isaca e Itsmf Valencia sobre la cloud en una mesa redonda y ayer pensaba si esto no sería aplicable también a la confianza en general que aplicamos sobre las cosas. En la mesa redonda la primera pregunta de Nuria Lago ha sido precisamente que qué pediríamos a una empresa en la cloud y mi instinto directamente ha respondido "Confianza". Aunque no se si he podido expresarlo bien, quiero compartir mi traducción de los pilares anteriores de la confianza cuando nos referimos a la cloud.

• Consciencia: entender a las partes implicadas y la situación en la que se encuentran, es decir, que tanto cliente como prestador del servicio de cloud sean conscientes del rol que representan cada uno y de las delimitaciones de responsabilidad que deben establecerse en la prestación del servicio. De esa forma en caso de conflicto se conocerá la linea que separa la responsabilidad de las partes y se juzgará con mayor precisión quién cometió el error.
• Claridad: compartir la realidad y obviar resto. Esto en este contexto debería ser traducido por transparencia y sería un ejercicio del prestador por informar e incluso poder representar los niveles de servicio mediante gráficas de forma que se pueda acreditar el cumplimiento. Algo como las gráficas de consumo a las que estamos tan acostumbrados en los recibos de luz, teléfono o gas pero llevado al contexto del SLA firmado con el proveedor de cloud.
• Coherencia: predicar con el ejemplo, hacer a cabo aquello que piensas y dices. Esto estaría relacionado con ser ejemplo también en materia de gestión TI y disponer de las acreditaciones en materia de buenas prácticas más adecuadas para demostrar a tus clientes que eres capaz de hacerlo bien y además estás comprometido con la mejora continua.
• Consistencia: dar cuerpo a los valores que te representan. En los temas de la cloud el término más adecuado podría ser resiliencia, es decir, la garantía de robustez del servicio para tener claro que si ocurriera algún incidente el proveedor dispone de un plan B para no dejarte tirado o al menos, que el RTO sea el pactado.
• Cumplimiento: alcanzar con garantías los compromisos generados. Esto estaría también vinculado a la transparencia y sería la demostración mes a mes de los cumplimientos en las gráficas anteriores de los acuerdos de nivel de servicio o bien asumir las consecuentes penalizaciones en caso de cualquier incumplimiento.
• Competencia: representar la profesionalidad, hacer las cosas bien. Fruto de la coherencia y de la aplicación de las buenas prácticas de Gobierno TI deberían llegar los resultados. Los sellos, si se cree en ellos y se aplican con rigor, deben lograr objetivos planteados y deben suponer una mejora progresiva de resultados.
• Coraje: ir más allá, hacer lo extraordinario. Este sería quizás el término más dificil de ajustar pero que podría estar relacionado con buscar la excelencia y podría enmarcarse dentro de ese compromiso de mejora continua. Además, dada la volatilidad de las tecnologías que se emplean, un proveedor debe garantizar los servicios que ofrece en el día a día y pensar en los que querrá ofrecer o podrá mejorar en el futuro. Aquellos proveedores cloud que estén mirando siempre al futuro serán seguramente los que mejor se adapten a los continuos cambios en el área TI. Esa plasticidad o elasticidad que hace al bambú ser resiliente, ser capaz de adecuarse en todos los contextos y permanecer siempre recto.

En breve postearé un Seguridad y las nubes II con un análisis de pros y contras que había anotado fruto de los distintos documentos que había leído para preparar la mesa redonda de hoy, pero eso será ya para  otro día que esté mas fresco.

Seguridad en la nube

La cloud computing es el tema de moda de este año y empiezan ya a publicarse estudios y documentos interesantes que tratan de enfocar el tema en materia de seguridad. Desde luego que la Cloud no sería posible sin una tecnología previa de gran importancia como es la virtualización pero además y como se comenta en casi todos los foros, no es algo nuevo. La "cloud computing" es un nuevo apellido a una serie de servicios tecnológicos que en los primeros tiempos del despliegue de Internet en España, cuando el principal negocio era el acceso y los proveedores de servicios ISP (Internet Service Provider), algunos ya planteaban nuevos modelos de uso de software basado en el alquiler ASP (Aplication Service Provider). En aquel primitivo escenario, el cliente se planteaba poder disfrutar del uso de una aplicación muy cara bajo regimen de alquiler y teniendo a su disposición un servidor (propio o compartido) alojado en un proveedor de acceso a Internet. Es evidencia de aquel momento y aquellos planteamientos un artículo que publicó mi jefe en Innosec, Gustavo San Felipe (Actual CISO en Acens) donde hablaba de la problemática de la seguridad en entornos donde los clientes compartían recursos y de las necesidades de garantizar servicios por parte del proveedor. Aquello era el año 2000 y se publicó en la Revista Nº40 de SIC.

Aunque el escenario ha cambiado, sobre todo incrementándose en complejidad, en el fondo se plantean las mismas inquietudes de aquel momento, la responsabilidad y confianza que se puede depositar en un servicio tecnológico remoto relevante.

A estas alturas ya han ido apareciendo diferentes documentos que merece la pena recopilar en este artículo y que sirven para tener una visión completa de cómo se plantea la problemática de la seguridad en la cloud computing.

1.- Estudio de riesgos en la Cloud de Enisa (En castellano). Son 140 folios con un estudio pormenorizado de los diferentes tipos de riesgos que la nube plantea en sus diferentes modalidades (IaaS, PaaS y SaaS). Es uno de los estudios más completos para tener una visión clara de los problemas que la nube plantea y cómo gestionar en ese contexto la seguridad.

2.- Estudio de la seguridad en la Cloud del BSI alemán (En ingles).  Son 70 folios del organismo aleman que establece los requisitos mínimos de seguridad que todo prestador debe satisfacer. Además, en este estudio, el análisis contempla criterios según las necesidades de disponibilidad o confidencialidad y las versiones de cloud públicas o privadas. Este documento es recomendado para los que se inician en el tema dado que en la introducción tiene una explicación detallada de los principales conceptos manejados bajo el término cloud así como las diferentes modalidades de servicios.

3.- Documento Enisa sobre como monitorizar los acuerdos de nivel de servicios en la nube prestados por terceros (En Ingles).  Son 64 folios con una definición marco de qué debe contemplar un SLA para servicios en la nube y cómo valorar por parte de un cliente la calidad del servicio prestado atendiendo a diferentes criterios (porque no solo la disponibilidad es suficiente en muchos casos). Esta guía de ENISA incluye  una descripción detallada de cada parámetro de seguridad a medir y cómo hacerlo. Los parámetros de seguridad a cubrir son: la disponibilidad del servicio; la respuesta a incidentes; la flexibilidad del servicio y la tolerancia de la carga; la gestión del ciclo de vida de los datos; el cumplimiento técnico y la gestión de la seguridad; la gestión de los cambios; el aislamiento de datos y la administración de los registros así como el análisis forense de seguridad de la información. 

4.- Documento de la AEPD y el Consejo General de la Abogacía donde habla del uso de la Cloud en despachos de abogados. (En castellano). Son 20 folios centrados en la problemática del uso de la cloud en el sector de la abogacía pero que es interesante e ilustrativo porque ha sido elaborando en colaboración con la Agencia Española de Protección de Datos (AEPD) y aporta su visión respecto a los requisitos legales de cumplimiento de la Cloud en el marco de la LOPD. Por tanto, de este informe se pueden deducir con carácter general qué cosas hay que exigir dentro del marco de cumplimiento en materia de protección de datos.

Del informe del BSI alemán me gusta este esquema gráfico de las cosas que están bajo el término "Cloud" y establece por un lado la arquitectura física y lógica de los sistemas de información y por otro las capas de gestión que el proveedor de servicio debe implementar. Bajo este contexto es obvio que los diferentes prestadores de servicio van a competir por el mercado intentando diferenciarse del resto y acreditando confianza. Para ello se están apoyando en la certificación de sus sistemas de información o servicios bajo las normas ISO 27001 (Seguridad de la información) e ISO 20000 (Gestión de servicios TI). Obviamente estas certificaciones sólo acreditan el cumplimiento de unos requisitos y la implantación de unas buenas prácticas de gestión TI aunque ello no tiene por qué suponer el logro de unos óptimos resultados (de la aplicación de esos marcos de gestión). En este contexto, la aparición de la reciente ISO 22300 también va a ser muy relevante dado que una de las cosas que más preocupan a los clientes en la cloud es que pasaría con sus datos en caso de una contingencia grave. Certificar un servicio en Cloud bajo la norma ISO 22300 al menos es un indicativo de que existen planes de continuidad de negocio y que se han probado. 

Mi reflexión/resumen de todo lo que voy leyendo al respecto es que las decisiones de saltar a la nube deben contemplar los siguientes factores:

1. Modalidad de cloud a emplear. Decidir el salto a la nube que se quiere dar. Los saltos a las modalidades IaaS y PaaS son más reversibles que los saltos a la modalidad SaaS. Por tanto, garantizan más autonomía en caso de problemas con el prestador o permiten montar rápidamente un servicio alternativo si ocurriese algo. Para ello es importante también decidir cual es la política de backup y qué parte se debe sincronizar desde la Nube con la organización que contrata. Tener al menos los datos te salva en caso de problemas gordos para poder garantizar "continuidad de servicio".
    
2. Definición de los términos y condiciones del servicio. El aspecto crucial de todo este asunto es también el proceso de contratación porque es cuando el prestador de servicios TI es flexible y se intenta amoldar al cliente. En este sentido, los contratos deben ser muy claros, concisos y concretos. El problema es cuando el proveedor TI es tan grande que es inflexible a las necesidades de clientes individuales. Además, es necesario hablar de penalizaciones porque un corte de X días tiene impactos no solo cuantificables por el coste del servicio sino también por las consecuencias de la ausencia del mismo aunque en la luz y el agua no se ven de esa forma.
   
3. Legislación y cumplimiento: Esto debe ser contemplado desde dos perspectivas. Por un lado, el marco jurídico donde se resuelven los conflictos porque si los problemas se resuelven en EE.UU. y sus tribunales las cosas tienen un coste en caso de conflicto y legislación aplicable. La temida Patriot Act permite a los americanos meterle mano a todo tipo de cosas. Por otro, garantizando el cumplimiento del marco legal de aplicación al que externaliza el servicio. La LOPD habla de diligencia del responsable del fichero frente a la externalización y que impera por tanto tener garantías de cumplimiento con carácter previo a la contratación. Además, no solo habría que mirar el presente de la materia (Actual ENS en Administraciones Públicas y LOPD) sino también el futuro (Nueva directiva de privacidad de la Unión Europea). 

De todo ello se evidencia en el contrato de servicios de cloud deberá  tener varios ejes y que obviamente debe ser redactado por perfiles jurídicos muy bien asesorados por los perfiles técnicos que tienen claro lo que quieren regular. Un buen acuerdo de nivel de servicio debe concretar y determinar los siguientes puntos:

• Introducción
• Descripción técnica del servicio.
•  Alcance
• Roles y responsabilidades
• Por parte del suministrador.
• Por parte del cliente.
• Operación del servicio
• Solicitud.
• Horas de operación
• Tiempos de respuesta.
• Mantenimiento y cambios
• Contingencias e incidencias cubiertas por el acuerdo.
• Procedimiento de escalado.
• Medición del servicio y su calidad.
• Notificación de incidentes en el prestador.
• Políticas o Normas complementarias a garantizar (Donde encaja este anexo técnico).
• Entrada en vigor y revisión del SLA.
• Aprobador del SLA.
• Revisor del SLA.
• Penalizaciones por incumplimiento.

De cualquier forma es justo y necesario pensar que todas estas cuestiones surgen ahora por la novedad de este tipo de servicios y la ausencia de experiencias de uso por parte de los clientes. En estos momentos aparecerán cientos de servicios y proveedores bajo las siglas cloud y será el tiempo quien realice una selección natural y vaya manteniendo y haciendo sobrevivir a aquellos que gocen del prestigio y la confianza de sus clientes en base a su fiabilidad, robustez y seguridad. Cuando todo el mundo piensa que el salto a la nube es peligroso en base a los riesgos ya identificados y por la alta dependencia de este nuevo tipo de terceros, debería al mismo tiempo plantearse que la misma dependencia existe de los proveedores de suministros básicos como la luz o el agua y sin embargo a ellos no se le plantean tantas exigencias respecto a garantizar continuidad de servicio y justificar el cumplimiento de SLA. Un corte de suministro tiene un impacto similar en una empresa que la caída de los servicios de cloud o del proveedor de telecomunicaciones que nos permite alcanzar la cloud. Por tanto, por coherencia, a todos los eslabones de la cadena hay que pedirles idénticas garantías y robustez. En el tema de suministros básicos, la Ley de Protección de Infraestructuras Críticas ya está forzando a que la continuidad sea un tema resuelto.