Desarrollar software seguro es caro, pero “caro” es relativo. Si lo comparamos contra el escenario de no hacerlo y que nada pase, entonces sí representa un costo mayor, ya que requieres de un tiempo de desarrollo y entrega más largo, dinero para herramientas, entrenamiento, análisis externos, etc.
En general, argumentar que “nos van a hackear” no resulta convincente para conseguir el presupuesto necesario. Pero, ¿qué pasa si la informacion de tu sistema es distribuida, modificada o eliminada sin tu consentimiento? El impacto puede ser de reputación y/o legal (si la informacion es filtrada) o de experiencia el usuario (si el servicio se degrada). En ambos casos hay un impacto monetario asociado.
Uber
Hoy se dio a conocer que millones de cuentas de Uber fueron comprometidas, y no con alguna estrategia sofisticada, sino simplemente accesando al código fuente en un repositorio privado en Github y obteniedo de allí credenciales correspondientes al almacenamiento de los datos en AWS. De entrada les costó 100 mil dolares en soborno a los hackers para que supuestamente borraran la información, pero ahora que se vieron legalmente obligados a hacer público el evento, las demandas y multas les caeran por montones.
Cuando hablamos de seguridad, en general se nos vienen a la cabeza los passwords, certificados, o firewalls en la parte física. Algunas veces nos acordamos de los parches y actualizaciones si es que tenemos algun conocido o amigo trabajando en redes o soporte. El caso de Uber es bueno para ejemplificar que esto va mas allá: es necesario que nuestro equipo de desarrollo entienda lo que implica crear software seguro. Practicas como el no tener credenciales en el codigo fuente, no usar la configuracion por default de los componentes que incluimos en el sistema o validar que no tengan vulnerabilidades publicamente conocidas son extremadamente sencillas e igualmente ignoradas. Muchas veces ni siquiera tenemos idea de los componentes y/o versiones que tenemos incluidas en nuestro sistema.
La seguridad no es algo que pueda dejarse “para después”. Como muchas otras temas de arquitectura, es requisito tomar las desiciones en el último momento responsible. Cuando esperas al final, si es que lo llegas a hacer, puedes enfrentarte al problema de que no todos tus usuarios tengan la version con los parches de seguridad que lanzaste y/o a no tener idea del impacto que se causó.
Es por ello que desde temprano en el ciclo de desarrollo del proyecto deben considerarse temas de seguridad. Muchas veces nos apoyamos solamente en la validacion de nuestro equipo de pruebas (QA) o en el proceso de code review de los desarrolladores, pero sin un entrenamiento adecuado en ninguno de los casos las personas sabrán que revisar. No podemos esperar que encuentren lo que no les hemos pedido explicitamente que busquen; si desconocemos las posibles amenazas a las que podemos enfrentarnos ¿cómo nos protejemos de ellas?. Aqui no aplica el dicho de si eres feliz no preguntes.
No es mi problema
Normalmente tendemos a pensar que la seguridad es responsabilidad de alguien más, pero no es asi. Todos dentro del equipo de desarrollo deben estar al tanto e involucrados.
En general los sistemas operativos y plataformas que utilizamos normalmente invierten mucho dinero en protejerse de las amenazas, ¿cuánto invierte tu equipo en lo mismo? Ahora bien, todo depende del riesgo. No comprarías una alarma de 1 millon de pesos para proteger un coche de 100 mil ¿o si?. Pero es un hecho que todos estamos en riesgo.
Como mencionaba al inicio, decir solamente que hay un riesgo de que te ataquen no es muy útil como estrategia. Para poder realmente lograr algo es necesario ponerlo en terminos concretos; es necesario considerar la seguridad desde una perspectiva más completa, ya que se abarca la privacidad (si me roban, modifican o destruyen mi info), y la confiabilidad (si el sistema no esta disponible debiodo a un ataque), impactando a final de cuentas la calidad del sistema y la experiencia del usuario.
Mucho se ha dicho que todos los negocios son de software hoy en dia. Practicamente no hay nada en la actualidad que este aislado completamente de ello, no importa si es un producto o servicio. Y el problema con la seguridad es que hay dinero detras.
Mas allá de los hackers
En “El Príncipe”, Maquiavelo menciona que todos los seres humanos son malos. Aunque es un punto que puede considerarse debatible, existe un modelo (del que platiqué hace algunos meses en mi presentación “Secure Software Development”) que de cierta manera le da la razón: es conocido como 10:80:10, y en este contexto nos dice que del 100% de los usuarios o involucrados con el sistema
- 10% no intentarán ningún ataque, sin importar las razones
- 80% son oportunistas
- 10% te atacarán sin importar nada
Podemos asumir entonces que adicional a los diabólicos hackers que andan sueltos por el mundo,
- Tus usuarios buscarán tomar ventaja de la aplicación si les resulta provechoso
- Un empleado molesto tomará represalias
- Un consultor que tenga acceso buscará obtener información que le pueda servir
Existen diversos factores que incrementan la probabilidad de esto, como son el valor que se obtiene de algún ataque, la posibilidad de ser atrapado, el castigo que se puede recibir en ese caso, etc.
¿Y ahora quien podrá salvarnos?
Existen diferentes herramientas que nos ayudan a desarrollar software seguro. Las principales con las que he trabajado en los últimos años son
Ambos proveen de bases para identificar los puntos en los que podemos estar fallando al momento de desarrollar software. Dependiendo del contexto en el que te encuentres y el riesgo al que te enfrentas, será el nivel de protección que tendrás que aplicar. En posts futuros incluiré algunos detalles adicionales de prácticas de desarrollo de software seguro.