¿Están mis datos y ficheros personales y empresariales que están alojados en el Cloud cumpliendo con lo exigido en la LOPD?

Hola! de nuevo, hoy vengo con un tema un poco controversial, sobre los servicios en la nube llamado también cloud y su cumplimiento con la LOPD (Ley de Orgánica de Protección de Datos)  que en España protege los derechos de las personas a salvaguardar su honor e intimidad personal y familiar de los ciudadanos y el pleno ejercicio de sus derechos.

Esta Ley está regida y controlada por la AGPD (Agencia Española de Protección De Datos) en este sentido es de por sí controversial los servicios en la nube como en este caso en particular los ofrecidos por la empresa Microsoft.

Uno de sus productos estrella y que aloja una serie de soluciones empresariales es el Office 365 que contiene los productos Exchange Online (Correo electrónico), SharePoint Online (Gestión de documentos y contenido), Project Server Online (Gestión de Proyectos), Skype Empresarial (Comunicaciones Unificadas), Onedrive Empresarial (Almacenamiento de Ficheros) y la suite de productos de Office 2016 (Word, Excel, PowerPoint y NotePad).

En este sentido la pregunta que muchos nos hacemos es la siguiente.

¿Están mis datos y ficheros personales y empresariales que están alojados en el Cloud cumpliendo con lo exigido en la LOPD?

La respuesta es un rotundo «SI» de hecho ha sido Microsoft pionero en España en cumplir la LOPD, de por si existe un libro que habla exclusivamente de este tema y que puedes descargar en el siguiente enlace:

LOPD Libro Microsoft

https://www.google.es/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCAQFjAAahUKEwjDy97wxp_IAhVBBBoKHbi5AC8&url=http%3A%2F%2Fdownload.microsoft.com%2Fdownload%2FC%2F2%2F6%2FC2689C05-2B67-4D11-BD2A-43CF9DBCE59E%2FLibro_LOPD_V2_Alta.pdf&usg=AFQjCNFVe8JwJ0y4lEOt45oRpm-2KKhNoQ&sig2=m1B9K8Vaq3jKw7q7-AkvzA

Tambien la AGPD ha publicado una nota donde ha certificado que las soluciones corporativas de Microsoft cumple con las garantías para la exportación de los datos.

Los productos y soluciones corporativos son: Office 365, Dynamics CRM Online y Microsoft Azure.

Cloud

Hay que aclarar que esto es una garantía en cuanto a que da a los usuarios corporativos la tranquilidad de la protección de su intimidad personal y a las empresas la tranquilidad que sus datos están protegidos.

Aumentando la confianza de las empresas en migrar sus datos desde su CPD tradicional a la nube (Cloud), con todas las ventajas que trae ello consigo.

Nota: https://news.microsoft.com/es-es/2014/06/06/aepd-servicios-cloud-microsoft/

Asi que dormir tranquilos que los datos en Microsoft están a salvo y cumpliendo la ley…..

Hasta la próxima.

auditoria-de-codigo

Auditoría de código: algo necesario pero que nunca hacemos (parte 2)

En la entrada anterior de esta serie de posts dedicados a la auditoría de código, hicimos una introducción sobre los problemas derivados del trabajo habitual. Es muy normal que haya fallos, descuidos o simple desconocimiento en cualquier proceso en el que un humano participa.

Vimos que el desarrollo de software no es una excepción y pudimos comprobar cómo han ido evolucionando los proyectos para convertirse en auténticos mastodontes.

Llegamos a la conclusión de que auditar el código de grandes proyectos es algo necesario y establecimos un momento óptimo cercano al 70% de desarrollo sobre una rama estable y que pueda compilar. ¿Hasta aquí todo bien? ¿Seguimos?

Primer acercamiento al código fuente

Si el código no es nuestro (lo que es común en una auditoría) necesitamos saber a qué nos enfrentamos. No tardaremos lo mismo ni nos encontraremos con los mismos problemas en un proyecto con miles de líneas pero sencillo, que en otro con pocas pero excesivamente complejo.

Por lo tanto, nuestra primera misión es conocer elementos tales como:

  • ¿Cuántas LOC (líneas de código) tiene?
  • ¿Cuántas funciones? ¿Son sencillas o complejas?
  • ¿Utiliza APIs de terceros?
  • ¿Está bien comentado?
  • ¿Existe documentación? ¿Está actualizada?

No podemos olvidarnos de requisitos externos que pueden complicar el proceso. Hace unos años participé en proyecto militar en el que recibí un código fuente con las siguientes características:

  • El código fuente era de la versión 7.
  • La documentación era de la versión 4 (a partir de ahí desarrollaron con prisa y no hubo tiempo para actualizar… ¿os suena?).
  • Para compilar era necesaria una llave USB… que no tenía y que tardó varios meses en llegar.

Desde luego no es el mejor escenario. Cuando te enfrentas a un proyecto así, cuanta más información puedas obtener, más sencillo será tu trabajo.

Mi consejo cuando te enfrentes a un proceso de auditoría de código es: insiste, profundiza y no tengas miedo a ser pesado. Puede que preguntando tres veces en lugar de una obtengas datos que te sean de mucha ayuda.

Herramientas de información

En nuestro acercamiento al código fuente, nos será de mucha ayuda tener una visión de conjunto antes de entrar a saco con el código. Por suerte dispones de gran cantidad de herramientas que te pueden ayudar en este paso.

En la siguiente captura podéis ver un ejemplo de una de esas herramientas (en este caso Code Analyzer) evaluando un pequeño proyecto java.

Análisis de proyecto con Code Analyzer

Como podéis ver, de forma rápida nos ofrece una visión de conjunto indicando LOC, comentarios, espacios en blanco

Complejidad del código

El siguiente paso será evaluar la complejidad funcional de lo que tenemos entre manos. Esto será una tarea sencilla si recibimos una buena documentación en la que todos los procesos estén descritos a nivel funcional (si hay diagramas de secuencia entonces será todo un éxito).

Si no lo tenemos, tendremos que evaluar el código realizando una tarea inicial de análisis de caminos independientes que se pueden tomar en los if-else, switches, cases, bucles… para trazar un mapa y poder contarlos.

¡Ojo! No te confundas, no se trata de contar sin más, debes evaluar las opciones. Mejor vemos un ejemplo, ¿no?

if (var > 10){
   if (var > 20){
      print "Mayor que 20";
   }
   else{
      print "Entre 10 y 20";
   }
}
else{
   print "Menor que 10";
}

En este caso podemos ver claramente que la existencia de dos condicionales hace que existan tres caminos diferentes de ejecución:

  • Camino A: La variable es menor que 10.
  • Camino B: La variable se encuentra entre 10 y 20.
  • Camino C: La variable es mayor que 20.

Esto se puede hacer a mano, pero también dispones de herramientas que te ayudarán a hacerlo de forma más sencilla, aquí tienes algunas de ellas:

En esta captura puedes ver el resultado de consultar la complejidad utilizando el plugin Metrics para Eclipse sobre el proyecto JAVA anterior:

Complejidad ciclomática con Metrics para Eclipse

El resultado lo podremos interpretar de la siguiente forma:

    Medidad de complejidad

Significado

1-10

  • Código estructurado con facilidad para hacer pruebas.
  • Poco riesgo de seguridad asociado.
  • Coste de auditoría bajo.

10-20

  • Código complejo con dificultad media para pruebas.
  • Riesgo medio de seguridad.
  • Coste de auditoría medio.

20-40

  • Código muy complejo con gran dificultad para pruebas.
  • Riesgo alto de seguridad.
  • Coste de auditoría elevado.

>40

  • Código excesivamente complejo, es muy probable que no se puedan realizar todas las pruebas.
  • Riesgo muy alto de seguridad.
  • Coste de auditoría muy elevado.

NOTA: Si quieres profundizar más sobre el cálculo de la complejidad ciclomática, estos enlaces te serán de gran utilidad:

Planificando la auditoría

Una vez tenemos el código y hemos comprendido a qué nos enfrentamos (LOC, complejidad, documentación…) estamos en condiciones de afrontar el proceso y qué mejor forma que haciendo eso que tanto nos gusta, planificar.

Lo principal será definir el equipo que se va a encargar de realizar la auditoría, puede ser una persona o muchas más (como siempre, dependerá del presupuesto, la urgencia y varios elementos específicos del proyecto).

La recomendación es que se trate de varias personas con formación y experiencia en ámbitos diferentes. Sería ideal contar con alguien especializado en diferentes entornos de desarrollo (escritorio, móvil, web), lenguajes o sistemas.

Planificaremos entonces una serie de sesiones semanales en las que cada miembro del equipo tendrá plena libertad para usar aquellas herramientas o técnicas con las que se sienta más cómodo (de ahí la importancia de que el equipo tenga diferentes perfiles).

Cada día se realizará una reunión de seguimiento corta (siguiendo la idea de SCRUM) y después se iniciará el proceso por el que cada miembro se encargará de un máximo de 1000 LOC/h y durante un máximo de 3 horas, ya que la concentración es muy importante en este proceso y no conviene que el equipo esté cansado o aburrido (lo cual es fácil cuando llevas un par de horas leyendo código de otro…).

¿Qué nos queda?

Tenemos y conocemos el código, longitud, complejidad, documentación y requisitos de funcionamiento. Tenemos al equipo listo con una cantidad de horas y LOC asignadas. ¿Tenemos ganas de empezar?

Pues nos vemos en la siguiente entrada en la que profundizaremos en las fases de la auditoría, en las tareas habituales y en un montón de cosas más.

Como siempre digo, si ves algún error, no estás de acuerdo con lo que cuento o quieres hacer alguna aportación, no dudes en pasarte por los comentarios.

auditoria-de-codigo

Auditoría de código: algo necesario pero que nunca hacemos (parte 1)

A lo largo de varias publicaciones, vamos a adentrarnos en el mundo de la auditoría de código para ver lo importante que es tener cierto control de lo que se hace para poder construir nuestro software de la forma más segura posible.

Una pequeña (bueno, no tanto) introducción

En el mundo de la seguridad de la información, como en todo, hay ciertos elementos más importantes que otros y que impactan de lleno sobre la posibilidad o no de que algo ocurra.

El usuario es un actor principal dentro de este mundo. Lo que yo llamo la “constante de inutilidad” (capacidad para cometer errores con los que decir “joer, qué inútil soy!”) de las personas es un factor vital para la seguridad global de un sistema, ya que si ponemos cientos de medidas pero el usuario publica la contraseña maestra en Facebook, estamos perdidos…

Todos tenemos un torpe en nuestro interior que nos empuja a cometer fallos, a despistarnos, a relajarnos y a dejar pasar cosas de forma inconsciente y (más a menudo de lo esperado) totalmente consciente.

Esto mismo se puede llevar al mundo del desarrollo de software. Cada vez que nos ponemos el mono de desarrolladores y comenzamos a picar código, podemos cometer una serie de errores o seguir patrones “desaconsejables” que pueden hacer que nuestro resultado sea totalmente vulnerable.

La evolución del código fuente

A lo largo de las últimas décadas, el desarrollo de software ha crecido exponencialmente. El uso de nuevas tecnologías en un mundo cada vez más conectado ha creado una gran dependencia de software que gestione y coordine todo.

Cuando comencé en esto de la informática, me dedicaba a escribir en BASIC programas de decenas de líneas, incluso me atrevía a hacer cosas con cientos de líneas que luego grababa en cinta.

Hoy en día, cualquier desarrollo sencillo se nos va a los miles y crece de forma increíble si hablamos de grandes funcionalidades. Mira, por ejemplo, cómo van creciendo las cifras conforme hablamos de software (loc = lines of code):

100.000 loc

Photoshop 1.0

2.500.000 loc

Windows 3.1

9.500.000 loc

Firefox 38

40.000.000 loc

Windows 7

61.000.000 loc

Facebook

 

¿Y esto en qué nos afecta?

Lógicamente, cuanto mayor es algo que hacemos, más probabilidad de fallo hay en su interior. Este tipo de soluciones software se desarrollan por grandes equipos de personas que cuentan con peculiaridades, manías y constantes de inutilidad diferentes.

En este escenario aparecen siempre fallos, problemas, descuidos que harán que ese software sea vulnerable, poniendo en peligro a la organización, empresa o usuario que lo utiliza.

Ahorra mientras solucionas

Generalmente se suele ver “desde arriba” que los procesos de auditoría de código son una pérdida de tiempo y que si surge un fallo, ya se arreglará. La verdad es más cruda, arreglar fallos se vuelve más y más caro cuanto más avanza el desarrollo.

Solucionar, mitigar o eliminar posibilidades de fallo es sencillo y barato en el momento del diseño. Hacerlo cuando hay varios millones de líneas y cientos de usuarios haciendo uso del software se puede volver inmensamente complejo y costoso.

Entonces la pregunta que surge es directa, ¿cuándo se debe hacer una auditoría de código? El momento óptimo ocurre cuando estamos alrededor del 70% del desarrollo de cada versión funcional y sobre un proyecto que podamos compilar.

¡Pero mucho ojo!, hay que buscar equilibrio entre el desarrollo y el auditor, el objetivo es mejorar, no entorpecer.

¿Manos a la obra?

En esta entrada sólo queríamos hacer una introducción al proceso de auditoría de código para ir avanzando en las siguientes entradas. Si te parece interesante lo que hemos empezado a contar, no dudes en pasarte por aquí para entrar en detalle.

¡Te esperamos!