domingo, 4 de julio de 2010

Desarrollo de Aplicaciones: Funcionalidad vs Seguridad


¿En las corporaciones donde se desarrollan aplicaciones se privilegia la funcionalidad o la seguridad? Hoy en día muchas empresas cuentan con al menos un pequeño equipo de desarrolladores para crear aplicaciones personalizadas (por ejemplo web) ya que la funcionalidad que buscan no la encuentran en aplicaciones de terceros.

Cuando se desarrollan estas aplicaciones internamente, todo mundo quiere que funcionen, es decir, que cumplan con lo que pide el usuario. ¿Seguridad? Ni al caso, eso no es importante y cuesta muy caro desarrollar software seguro para que al final de todas maneras tenga bugs (ni Microsoft logra codificar software bug-free, por qué lo habría de hacer el equipo de desarrolladores de una corporación?).

Aunque lo anterior pueda sonar a sarcasmo de mi parte, léanlo de nuevo y verán que hay verdad en esas líneas: cuesta caro desarrollar software seguro (cierto), de todas maneras probablemente va a tener bugs (cierto) y ni fabricantes que se dedican a desarrollar software logran crearlo 100% libre de bugs (cierto). ¿Entonces para qué esforzarse?

La pregunta anterior la debe de responder cada empresa, aquí podré decir misa y enlistar decenas de razones y ejemplos de la importancia de crear software seguro y por qué no podemos dejar de hacerlo. Y eso sería como convencerlos con la típica presentación PowerPoint. De todas maneras ustedes seguirán teniendo dudas y sosteniendo que es caro hacer software seguro o que de todas maneras tendrá bugs (¿y saben? no los culpo).

Recientemente Errata publicó los resultados de una encuesta que llevó a cabo referente a este tema. Aunque siempre hay que tomar las encuestas con cautela, podemos asomarnos a algunos de sus resultados.

Un 38% de los encuestados afirmó seguir una metodología de desarrollo seguro, mientras que un 81% al menos sabía que existían este tipo de metodologías. Que por cierto, cuáles son?

Existen varias metodologías para centrarse en la creación de software seguro. Una de las primeras que salió al público y que recuerdo fue la de Microsoft: Security Development Lifecycle. Le siguieron otras cuantas como la SDL-Agile (igual de MSFT), la Software Assurance Maturity Model (SAMM), la Building Security in Maturity Model (BSIMM) o la Comprehensive LightWeight Application Security Process (CLASP) patrocinada por OWASP, entre otras.

¿Y qué hay sobre las razones para no adoptar alguna metodología de desarrollo seguro? La encuesta de Errata arroja algunos motivos: “seguirlas consumen mucho tiempo”, “desconocimiento de la existencia de estas metodologías”, “muy costoso seguirlas”, “requiere muchos recursos”, “innecesario”.

También resalta un dato curioso: corporaciones con grupos grandes de desarrolladores (~100) no adoptan estas metodologías tan rápido como aquéllas que tienen pocos codificadores (~10).

En fin, olvídense de la encuesta. Volteemos a nuestras áreas de TI. ¿Qué se hace ahí? ¿Se siguen metodologías de desarrollo de software seguro? Si sí, compartan! Si no es así, las razones son algunas de las listadas aquí (innecesario, costoso, inútil)?

Recuerden que el hecho de no seguir una de estas metodologías no está mal si así lo decidieron de manera consciente, lo que implicaría un riesgo es no analizar qué otros controles compensatorios pueden existir (como por ejemplo un firewall de nivel aplicación para proteger las web-apps).

Para los que no siguen una metodología de desarrollo seguro o incorporan controles compensatorios, no pretendo convencerlos con una encuestita, supongo que tendrán que vivirlo.

Finalmente, algunas citas interesantes sobre este tema:

The root cause of software vul­nerabilities is found in the early stages of the software development life cycle. The majority of vulnerabili­ties could easily be taken out at this stage”.- Marisa Fagan (Errata)

It’s no secret that soft­ware companies value features over security”.- Marisa Fagan (Errata)

Nota: un libro que me encuentro leyendo actualmente es el de “Software Security Testing” de Chris Wysopal. Existen muchos otros más en Amazon muy recomendables (échenme un tweet si les interesa).


No hay comentarios: