Guías para desarrollar en forma segura

La seguridad en el ciclo de desarrollo de aplicaciones ya no es opcional, tiene que ser considerada como un elemento vital y crítico para cualquier tipo de producto ya sea una aplicación web, móvil, cliente, etc. sin ningún tipo de excusa.

Por ejemplo la nueva Comunicación BCRA "A" 5374 en su punto 6.7.1 dice:

6.7.1. Tabla de requisitos mínimos de Concientización y Capacitación

Los contenidos del programa de CC deben incluir técnicas específicas para el desarrollo/adquisición/fabricación, implementación, homologación y prueba de características de seguridad de los dispositivos y piezas de software provisto por la entidad/operador, asegurando que el personal involucrado interno/externo se encuentra debidamente capacitado para disminuir las fallas de implementación de las características de seguridad.

Es frecuente oír en la industria lo difícil y costoso que es aplicar seguridad en el desarrollo y muchas compañías lo utilizan como excusa para producir productos de baja calidad, que lo único que hace es perjudicar a la industria del software y todavía más a sus clientes exponiéndoles a los peligros de Internet.

Por supuesto que requiere un esfuerzo, dedicación, gasta recursos, modifica los paradigmas de desarrollo y además tiene un precio. Pero los verdaderos problemas son otros que parece que muy pocos entienden o quieren ver como son la falta de conocimientos en la materia o foco en el beneficio en vez del cliente.

A continuación pongo una serie de puntos a modo de guía de supervivencia que debemos tener en cuenta a la hora de meternos en esta odisea.

1. Decisión: Existen 4 marcos principales de seguridad en el desarrollo que las compañías pueden utilizar como son el SDL de Microsoft, CLASP de OWASP, Touchpoints de Cigital y el BSIMM como punto de partida. Debemos escoger el que mejor se adapte a nuestras necesidades y no al revés.  No “Copy&Paste” de un marco sino adáptalo a ti.
2. Selectivo: No es necesario aplicar el marco entero, solo seleccionar aquellas partes que nos interesen rebajando el tiempo de implantación y su coste. Por ejemplo Microsoft tiene 3 variantes: SDL para productos, SDL-LOB para aplicaciones de negocio y SDL-Agile para programación agile.
3. Expertos: Si no tenemos las habilidades en casa debemos buscar ayuda fuera, aunque tenemos que tener cuidado ya que en el fondo muy poca gente tiene experiencia en este campo. Un punto de partida pueden ser las empresas que se han certificado en el SDL de Microsoft. Es conveniente contratar o formar a nuestro personal en este proceso de seguridad para tenerlo en casa.
4. Formación: Una buena formación es el camino al éxito. Ofrecer diversos cursos de formación en función de la audiencia y los conocimientos que queremos que nuestros equipos obtengan. Existen diversas certificaciones que nos pueden ayudar como CSSLP del ISC2 y las certificaciones de desarrollo seguro de SANS y las de GIAC.
5. Paciencia: Microsoft es sin duda el líder en desarrollo seguro como se puede apreciar en estos últimos años (2008-2009), pero tenemos que tener en cuenta que llevan trabajando en este tema desde 2002 y con amplios recursos (humanos y económicos). Seguramente nosotros seremos más modestos que Microsoft, por lo que debemos ser más listos y eficientes.
6. Realidad: Nuestro producto ganará en calidad pero en ningún momento debemos pensar que seremos capaces de evitar 100% los fallos de seguridad. El SDL de Microsoft lo define perfectamente: evitar todos los fallos posibles y mitigar aquellos que se escapen mediante otros mecanismos de seguridad (antivirus, cortafuegos, autenticación, criptografía, etc…).
7. Unión: Debemos proteger la infraestructura y las aplicaciones (desarrollo) dentro de nuestra estrategia de seguridad. Por lo tanto estas 2 áreas están estrechamente ligadas y deben trabajar juntas sin ningún tipo de excusa. La seguridad es responsabilidad de todos en la organización.
8. Sin Escape: Aplicar la seguridad tanto si desarrollamos en casa como si esta externalizado. En caso de externalización deberíamos aplicarles nuestros estándares de calidad.  Igualmente si compramos productos de terceros debemos tener ciertas garantías que han seguido un proceso de desarrollo seguro.
9. Evolución: Esto es un proceso y en continua evolución. Nuestro marco de seguridad no debe ser estático sino que debe adaptarse a los tiempos: tecnología, procesos y personas.
10. Respuesta: Debemos estar preparados para lo peor por lo que es conveniente tener un plan de respuesta en caso de inseguridad en nuestra aplicación que contemple quien debe estar involucrado, como manejar la situación, comunicación, etc.

 Fuente: Simon Roses

Suscríbete a nuestro Boletín