miércoles, 11 de febrero de 2009

Reconocer el fracaso en seguridad


Leo en VariableNotFound dos entradas buenísimas sobre los programadores con producción neta negativa, y sobre las 101 formas de saber que tu proyecto está condenado al fracaso (proyecto de desarrollo, claro está). Si hacemos una lista parecida sobre fracaso en seguridad, yo pondría las siguientes.
  • Agregar características generales al final del proyecto. Por ejemplo, en seguridad: pensar que se puede securizar al final.
  • No concienciar al equipo de desarrollo sobre aspectos fundamentales (por ejemplo seguridad)
  • No formar al equipo de desarrollo en técnicas de desarrollo seguro que han de utilizar al escribir código, o en las decisiones de diseño que puede ser necesario tomar
  • No proporcionar tiempo al equipo de desarrollo para que se forme él solito sobre los temas que les competen, por ejemplo seguridad
  • Considerar inaceptable el coste en tiempo (y por tanto dinero) que supone el repaso del código, la implantación de medidas de seguridad, o la realización de pruebas de hacking al final, viéndolo como un gasto superfluo en todos los casos, en vez de una inversión
  • No seguir un verdadero ciclo de desarrollo seguro, que contemple la seguridad como uno de los aspectos fundamentales en cada una de sus fases
Además de tener razones por las que se fracasa en seguridad por no hacer cosas, se me ocurren ahora mismo razones por las que se fracasa en seguridad precisamente por hacer cosas:
  • Considerar que sabemos más que los expertos del mundo mundial, reinventando la rueda. Hay mil ejemplos: usar algoritmos de cifrado de nuestra invención que "nadie puede romper porque sólo los conozco yo", crear identificadores de sesión con formato propio, no usar las funciones de la API para validar entradas porque ya tenemos nosotros las nuestras, etc...
  • Hacer un sistema que siendo seguro, molesta constantemente al usuario (de esto, todo el mundo menciona el mismo ejemplo, para qué repetir)
  • Hacer un sistema tan seguro que penaliza otros aspectos, haciéndolo menos atractivo o útil al usuario, que por tanto comprará otro producto (¿para qué hacer un producto súper seguro que no comprará nadie?. Aunque de esto, no se me ocurre ningún ejemplo ahora mismo)
¿Se os ocurren otras formas?

Slds!

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

No hay comentarios: