Conseguir que tus aplicaciones sean seguras (o al menos, intentarlo) 3

Cloud, software propio, software propietario, software libre... ¿Qué camino sigo?

La última vez dejamos una pregunta en el aire ¿Cómo elegir, o en su caso desarrollar, el software? Echémosle valor al toro.

Para empezar, como dice el título: Cloud, software propio, software propietario, software libre... ¿Qué camino sigo?

Cloud (?)

Sobre el uso de tecnologías Cloud se ha escrito mucho. Y en el mundillo de la seguridad abundan quienes que se declaran excépticos. Incluso yo comentaba hace poco algo del tipo: "la nube simplifica mucho las cosas... sobre todo si sabes taparte la nariz y mirar hacia otro lado cuando huele mal". Cosa de la que no me desdigo. Pero que tampoco quisiera llevar más allá de lo razonable. Me explico:

El problema principal que le veo al Cloud cuando de seguridad se trata es que las organizaciones pueden terminar perdiendo el control sobre su información. La dejan en manos de otro y confían en que hará bien las cosas. Pero siguen siendo responsables de ella, legal y moralmente hablando. Está muy bien eso de contratar un servicio y olvidarse de él, pero la seguridad no es algo de lo que te puedas desentender, porque se infiltra en cada matiz de tu organización. Y no puedes comprarla. Recuerda: "no es un producto sino un proceso". Si te la proporciona una empresa, debes implicarte y controlar lo que ésta hace porque, lo haga quien lo haga, no es algo que puedas contemplar de forma independiente del resto de tus actividades.

En ese aspecto, el Cloud no simplifica las cosas. Más bien todo lo contrario. Pero ¿significa eso que no se debe usar? Ni mucho menos.

Hace algún tiempo, en una charla que di sobre vulnerabilidades del tipo CSRF y XSS, alguien me preguntó por las Content Delivery Networks y lo que yo pensaba de utilizarlas como fuente de librerías JavaScript para tus páginas web. Creo que esperaba que me opusiera categóricamente a su uso y, de hecho, me pareció que mi respuesta no le satisfacía. Pero era la única que tengo para este tipo de cosas: depende.

Sí. Depende, principalmente, de si tú eres capaz de hacer las cosas mejor que ellos. O de si tienes los medios necesarios (técnicos, humanos, organizativos, ...) para garantizar el servicio. Por poner un ejemplo: si tu sitio web está alojado en un servidor gratuito que ni siquiera soporta HTTPS quizá sea más fiable descargar algo de un servicio prestado por Google que de él.

Volviendo al Cloud, piensa en el correo electrónico. ¿Tienes medios para instalar un sistema de control de acceso que utilice dos factores? ¿Eres capaz de atender la carga administrativa que supone la gestión (altas, bajas, modificaciones, desbloqueos, etc.) de todos tus usuarios? ¿Tienes un servidor apropiado y con suficiente capacidad? ¿Dispones de un software suficientemente seguro y eres capaz de mantenerlo actualizado para que siga siéndolo? ¿Tienes personal para operarlo sin problemas y dar respuesta rápida a los incidentes de seguridad? ¿Dispones de infraestructuras para garantizar el servicio en caso de que algo falle? ¿Eres capaz de ofrecerlo sobre varios clientes, incluyendo smartphones?

Si respondiste "no" a alguna de estas preguntas... plantéate usar la nube. Plantéate si Gmail.com o Outlook.com, por citar dos ejemplos, hacen mejor que tú estas cosas. Porque es verdad que con la nube pierdes un grado de control pero también lo es que estas grandes empresas, gracias a la economía de escalas, pueden permitirse cosas que tú no. Y están sujetas a un marco regulatorio y a un escrutinio público del que quizá tú escapes.

Eso sí: si te decides por la nube... que no te vendan humo. Elige bien tus compañeros de camino y antes de seleccionarlos piensa en (y asegúrate de que figuren en el contrato) cosas como:

• Cómo se almacenarán tus datos. 
• Qué cifrados se aplicará a tus datos, dónde se realizará la encriptación y quiénes tendrán las claves.
• Quiénes tendrán acceso a tus datos.
• Dónde se van a alojar tus datos y si tienes algún grado de decisión sobre ello.
• Qué normativas les serán aplicables a tus datos.
• Cuántas copias existirán de tus datos.
• Qué control te dejan sobre tus datos y la forma en que se gestionan.
• Qué procedimientos existen para llevarte tus datos a otro servicio y cómo y en qué condiciones puedes utilizarlos.
• Qué responsabilidades asume la empresa propietaria del servicio en la nube  y cuáles asumes tú.
• Cómo te compensará la empresa en caso de que existan problemas de seguridad.
• Cómo actuará la empresa propietaria del servicio en la nube y cómo interactuará contigo (y con tus clientes, si procede) en caso de que se produzcan incidentes de seguridad.
• Qué pasará con tus datos (y con sus copias de seguridad) cuando dejes de trabajar con ellos.

Y repito: "tus datos". Y tu responsabilidad. Si te dicen que esto de la nube es cuestión de confianza... no lo creas. No basta con confiar. Necesitas garantías. Muchas garantías.

Pero si decidiste alejarte de la nube y alojar tú mismo tu software... tampoco habrás acabado de elegir. Te quedan al menos dos cuestiones por responder

¿Software Libre o Propietario?

Buena pregunta... ¿no crees?

O no tan buena, si lo miras bien. Si me pongo a mirar lo que hay por ahí me doy cuenta de que la elección entre software libre o propietario no me parece tan relevante. Conozco aplicaciones de software propietario malas. Malísimas. Con más agujeros que un queso de gruyère. Pero igual de malas las hay de software libre.

Que el código fuente sea público es un arma de doble filo. Como cualquiera que se mueva en estos mares, en alguna ocasión he encontrado una vulnerabilidad en un producto al revisar su código. O he podido realizar con mayor facilidad ataques de SQL Injection al conocer la estructura de la base de datos. Y habrá quien diga: "claro, la gente puede analizar el código y encontrar los problemas y resolverlos -- eso lo hace más seguro".

Y otros replicarán: "pero... ¿quién le dedica el tiempo necesario a analizar la seguridad del código de las aplicaciones que utiliza". O: "pero si el código es cerrado nadie, ni siquiera los delincuentes, lo tendrán tan fácil para dar con las vulnerabilidades".

O: "¿y si los bugs son encontrados por gente que no los hace público y los explota durante mucho tiempo". Porque de esto también hay precedentes. Por poner uno, cuando la NSA reconoció saber de HeartBleed años antes de que fuera publicada.  Y estamos hablando de una vulnerabilidad introducida en 2012 y de la que todos (al menos, los que no estábamos en el ajo) nos enteramos en abril del 2014.

Ambos están en lo cierto y ambos se equivocan. Y yo también. El software es algo demasiado complejo como para que sea el carácter abierto o cerrado de las fuentes lo que determine su seguridad.

Estudia qué aplicación o sistema responde mejor a tus necesidades. Y trata de conocer cómo se desarrolla. Independientemente del tipo de producto, busca algo que no te vaya a dejar en la cuneta. Huye como del fuego de proyectos gestionados por una única persona o un grupo reducido. Aléjate de aquellos que no sean la principal dedicación de quienes los crean y mantienen.

Mira el historial del software, pero no te dejes engañar por la cifra de vulnerabilidades encontradas. Más vulnerabilidades detectadas no quiere necesariamente decir que el software es menos seguro. Quizá sea todo lo contrario y estemos hablando de "más problemas corregidos".

Porque vulnerabilidades, con el tiempo, seguro que aparecen y más aún en aquellos productos software que son utilizados por mucha gente. Entonces lo importante será ver cómo las corrigen. Qué protocolos y procedimientos tienen establecidos para el reporte y la gestión de bugs. Qué tiempos de respuestas manejan. Qué tipo de soluciones suelen darles. Qué recursos dedican a ello.

Lo del software libre tiene un pro y una contra que no quisiera dejar de citar. Por un lado, quizá tengas algún margen de maniobra. Si puedes, trata de participar y aportar recursos a aquellos proyectos de software libre que utilices. Al fin y al cabo, es algo que parece justo y que, visto desde el punto de vista egoísta, te permitirá tener alguna influencia en su evolución.

Y, por otro, ten cuidado con todo lo que parezca salir gratis, sea o no libre. No sólo porque podría no serlo (gastos de formación, consultoría, etc.) sino también porque podría serlo. Al ser gratis y no tener que pasar por los trámites necesarios para pagar una licencia, cualquiera puede pensar en instalárselo. O en tener muchas instancias corriendo. Y con ello podríamos estar perdiendo el control sobre el software instalado en nuestros equipos y sobre la forma en que lo gestionamos y tratamos de mantenerlo tan seguro como nos sea posible. Estaríamos acabando con nuestra útil "lista blanca".

¿Lo hago yo o lo encargo a una empresa?

Si no utilizas un software ya existente, ya sea libre o propietario, también tendrás que decidir si lo haces con tus medios o contratas a alguien.

Aquí te digo lo mismo que cuando hablábamos con la nube: ¿puedes hacerlo tú mejor que ellos?

Pregúntate: ¿con qué personal cuento? ¿se dedica a otras cosas que no les va a permitir centrarse en los desarrollos? ¿me puedo permitir después realizar el mantenimiento del producto? ¿tiene mi personal formación suficiente en programación? ¿la tiene en seguridad y hacking?

Si es que no... piensa en que lo haga otro. Eso sí, antes de encargárselo, hazte las mismas preguntas de antes pero referidas a éste: ¿con qué personal cuenta la empresa? ¿se dedica a otras cosas que no les va a permitir centrarse en MIS desarrollos? ¿se pueden permitir después realizar el mantenimiento del producto? ¿tiene SU personal formación suficiente en programación? ¿la tiene en seguridad y hacking?

Y ni te plantees contratar con nadie que no sea mucho mejor que tú en esto.

Cuando contrates el desarrollo, asegúrate de que aparezcan cláusulas que te garanticen, entre otras cosas:

• La adecuada formación en materia de seguridad de TODO el personal de la empresa involucrado en el proyecto.
• Los datos del personal que va a trabajar en él, con su formación y cualificación, tanto general como específica en materia de seguridad, la relación que tienen con la empresa, el puesto y el tiempo que lleva en ella. Y no estaría de más que les hicieras alguna entrevista antes de decidir.
• La metodología a utilizar, en general y en particular en lo referente a la gestión de seguridad durante todo el ciclo de vida y de mantenimiento.
• La garantía de resolución de las vulnerabilidades que pudiera tener el producto en un tiempo y unas condiciones adecuadas.
• Las responsabilidades que asume la empresa en materia de la seguridad del producto (y no me vale eso tan manido de "la empresa no se hace responsable...") así como de producirse cambios sustanciales en el personal encargado del proyecto.
• Las compensaciones que tendrá que hacerte la empresa en los casos anteriores.
• Y algo que nunca me cansaré de repetir: TRANSFERENCIA DE CONOCIMIENTO. Que la empresa proporcione formación e información que mejore tu organización. Entre otras cosas, en seguridad.

Seguro que me dejo muchas cosas en el tintero, pero en algún momento tengo que dejar de escribir. Dejemos para más adelante algunas notas sobre el ciclo de vida y otros aspectos más técnicos.

Lo importante es que, lo hagas como lo hagas, que no tengas nunca que decir (o volver a decir) eso que una vez oí de "esto es que lo hicieron unos becarios que tuvimos hace tiempo y ahora vaya usted a saber quién será capaz de entenderlo y mantenerlo". 

En aquel caso, si no me falla la memoria, la aplicación tenía vulnerabilidades de Local File Inclusion (no recuerdo si también remoto), SQL Injection y XSS. Que no es poco. 

Y les habían cascado publicidad de pastillitas azules y otros fármacos.