SSL: Secured by design

SSL es complejo y los fallos relacionados con el son complicados de diagnosticar y corregir. Es normal dejar su implementación para el final entre otras cosas porque si no funciona en plano despues menos.

El problema viene cuando se termina la aplicacion o servicio y se quiere securizar (de prisa y corriendo), un problemon porque no ha sido diseñada para las nuevas condiciones en las que tiene que servir y juntamos en un coctel explosivo la complejidad, la falta de tiempo, rehacer planificaciones, las pruebas y una miriada mas de condicionantes.

SSL debe estar integrado desde el principio y tenido en cuenta en la planificacion. Muchas veces sólo se quiere o se piensa en cifrar comunicaciones o accesos olvidandose que antes de eso es un protocolo de autenticación, es implementar un modelo de seguridad donde no lo habia o donde ya hay uno existente que debe ser retocado y probado.

Los técnicos lo dejan para el final porque trabajar con datos cifrados no ayuda a la depuración y diagnostico de problemas pero esto tiene facil arreglo, especificar que se use certificado en texto plano (que no cifre), en el peor de los casos al habilitar los codecs finales los problemas pueden venir de incompatibilidades entre codecs aceptados por cada parte pero el modelo de seguridad no cambia y sigue probado.

Lo mismo se puede decir del concepto de securización en general, cerrar puertos, securizar cookies, permisos, roles,… es muy comodo dejarlo para el final y eso sin contar que “no es producto”, no es funcionalidad, es un coste extra, horas y trabajo “perdidos” en algo que el usuario no quiere ni ha pedido… (hasta que alguien explota la vulnerabilidad claro…)

Los managers y jefes de proyectos porque la seguridad es lo último y no se paga. La seguridad al igual que la calidad, es un proceso que acompaña el proyecto de principio a fin y de la misma forma que la calidad no se arregla con un “crunch time“, la seguridad tampoco.