02 febrero 2009

Seguridad en el desarrollo

La seguridad en el desarrollo de aplicaciones es uno de los mayores caballos de batalla dentro de este mundillo. Sobre todo teniendo en cuenta la creciente complejidad de dichos desarrollos y los decrecientes márgenes de actuación que suelen tener los desarrolladores, sobre todo en plazos.

Hace un par de semanas se publicó una noticia en la que un estudio alertaba sobre los peores 25 errores de programación, orientada a identificar las prácticas de programación con mayores riesgos desde el punto de vista de la seguridad. En el artículo me llama la atención que primero se afirme que "la mayor parte de los errores podrían ser evitados si los programadores fueran más cautelosos con su trabajo", y más adelante se diga que "la mayoría de los errores de la lista son relativamente desconocidos entre los propios programadores y no forman parte de los estudios de los desarrolladores". Es decir, que apuntan a la falta de cautela y a la insuficiente profundidad de conocimientos al respecto como dos de las principales causas de estos graves errores.

No quiero entrar a valorar estas posibles causas, y si realmente las presiones empresariales tienen más o menos peso que las que indica el artículo. No obstante, sí que quiero prestar algo de atención a la posibilidad de que los conocimientos de los programadores respecto de estos errores puedan ser insuficientes. En este otro artículo se enumeran cuáles son en concreto estos 25 errores, agrupados en 3 categorías:
  • Interacción insegura entre componentes
  • Administración inadecuada de los recursos del sistema
  • Técnicas de "defensa" mal utilizadas o ignoradas

¿Creéis que realmente puede haber un insuficiente conocimiento al respecto acerca de estos errores? ¿Conocéis algún programa de estudios que contemple de forma explícita estos tres ámbitos?

No obstante, creo que el mayor problema de la inseguridad en los desarrollos es, más allá de la problemática técnica, la ausencia de responsabilidades en torno al software. Prácticamente nadie se hace responsable de los fallos que pueda tener el software que desarrolla ni de las consecuencias que puedan tener dichos fallos. Sí, es cierto que en el mercado de software actual esto parece impensable, pero... ¿No es precisamente esta falta de asunción de responsabilidades la que nos ha llevado a que a un PC no se le puedan exigir las mismas garantías que a un coche? Y no obstante hay PCs que controlan sistemas mucho más sensibles para la vida humana que un coche...

En definitiva, creo que la solución a la inseguridad en el desarrollo tiene una muy difícil solución, y no por los problemas que provoca el propio mercado, la atención o la formación, sino porque en dicho mercado prácticamente no hay nadie dispuesto a asumir formalmente los riesgos derivados de vender un software que pueda tener errores de seguridad. Que se conozcan cuáles son los mayores errores no garantiza que se vayan a querer subsanar, si el esfuerzo no merece la pena en términos económicos...

2 comentarios:

Edgard dijo...

Interesante. Durante mi etapa de programador (unos cuantos años y unos cuantos entornos/lenguajes) no recuerdo apenas haber tenido especificaciones formales y concretas en materia de seguridad (ni siquiera existían relativas a lo que se tenía que desarrollar en esencia :-), pero eso es otro tema). Yo creo que el problema de fondo está en los mismísimos orígenes, es decir, el usuario. Como mucho de forma compartida con el "experto" que recoge y contrasta los requerimientos de los usuarios. Desde el punto de vista del usuario es obvio que la aplicación práctica de la seguridad tiende a 0 (salvo muy pocas excepciones en las que la "seguridad" forma parte del ciclo de desarrollo/adquisición de cualquier software o como mínimo participa personal dedicado a esos aspectos), por tanto, la patata caliente la tienen realmente los "analistas" de la solución (funcionales, orgánicos, jefes de proyecto, etc. o como se quieran llamar). Al igual que se proponen pantallas muy bonitas con sus campitos de datos y demás también deberían proponerse los controles intrínsecos a todo ese despliegue operativo-funcional. Desde luego, el programador bastante hace y en muchas ocasiones los pocos controles de seguridad implantados han sido "improvisados" por ellos mismos. También hay que recordar que hay una fase de "pruebas" que deberían neutralizar todas esas debilidades, aunque me temo que si en la fase de desarrollo poca atención se presta aún menos preocupación causa en las pruebas.
Me temo que la cultura de la seguridad en el desarrollo de software le queda mucho camino por recorrer. Una buena iniciativa por parte de isc2 ha sido la más o menos reciente creación de una certificación en este ámbito CSSLP (http://www.isc2.org/csslp-certification.aspx). A ver cuantas empresas de desarrollo se aplican el cuento y "obligan" a que determinado personal vinculado con esta función se acredite en estos aspectos. Obviamente, no asegura nada pero como mínimo se demuestra que se tienen presentes. En resumen, han avanzado muchas cosas tecnológicamente hablando pero en cuanto a la interiorización de la seguridad en los productos de software parece que no se haya avanzado mucho.

Joseba Enjuto dijo...

La verdad es que la certificación que señalas tiene muy buena pinta. Seguro que siendo tan nueva tendrá aspectos que mejorar, pero la verdad es que la iniciativa me parece muy interesante. Como dices, a partir de ahora habrá que ver cuántas organizaciones de desarrollo empiezan a solicitar / valorar / vender profesionales con dicha certificación...