La mayor parte de los agujeros de seguridad en las aplicaciones informáticas se debe a errores de programación. ¿Cuál es la responsabilidad de los desarrolladores y de las empresas? ¿Por qué el código seguro aún no es una realidad?
Las aplicaciones informáticas se construyen a partir de diferentes códigos. Estas líneas de programación no son 100 por ciento seguras, y sus errores son aprovechados por delincuentes tecnológicos, a través de virus y acciones de espionaje. Así, millones de personas quedan expuestas a amenazas peligrosas y silenciosas.
La gravedad del problema fue expuesto por un grupo internacional de expertos que difundió una lista con los 25 errores de programación con mayor potencial de daño. Por ejemplo, dos de esos errores fueron explotados en 2008 para instalar código maligno en un millón y medio de sitios web, que luego propagaron código malicioso entre sus visitantes.
El grupo incluye, entre otros, al Ministerio de Seguridad Interior de Estados Unidos y la agencia de seguridad NSA, la organización japonesa IPA y empresas como Microsoft y Symantec. De acuerdo al documento, que puede leerse aquí, la mayoría de estos errores son desconocidos entre los propios programadores, y no integran los estudios de los desarrolladores.
iProfesional entrevistó sobre la seguridad en el desarrollo de los códigos a tres especialistas en seguridad informática argentinos: Ivan Arce, CTO de Core Security Technologies; Roberto G. Langdon, presidente y CEO de 2Minds; y Jorge Cella, gerente de Iniciativas de Seguridad de Microsoft Argentina.
La gravedad del problema fue expuesto por un grupo internacional de expertos que difundió una lista con los 25 errores de programación con mayor potencial de daño. Por ejemplo, dos de esos errores fueron explotados en 2008 para instalar código maligno en un millón y medio de sitios web, que luego propagaron código malicioso entre sus visitantes.
El grupo incluye, entre otros, al Ministerio de Seguridad Interior de Estados Unidos y la agencia de seguridad NSA, la organización japonesa IPA y empresas como Microsoft y Symantec. De acuerdo al documento, que puede leerse aquí, la mayoría de estos errores son desconocidos entre los propios programadores, y no integran los estudios de los desarrolladores.
iProfesional entrevistó sobre la seguridad en el desarrollo de los códigos a tres especialistas en seguridad informática argentinos: Ivan Arce, CTO de Core Security Technologies; Roberto G. Langdon, presidente y CEO de 2Minds; y Jorge Cella, gerente de Iniciativas de Seguridad de Microsoft Argentina.
Arce trabaja para Core Security Technologies, una compañía que se dedica a la evaluación exhaustiva de seguridad informática. Esta firma, con oficinas de investigación y desarrollo en el barrio porteño de Palermo y una sede comercial en Boston, EE.UU., identifica y verifica vulnerabilidades, mide el riesgo operativo y comprueba la efectividad de la seguridad.
En el documento mencionado, Core fue mencionada como una de las organizaciones que hizo contribuciones más sustantivas a la lista de los 25 errores.
-¿Por qué el código seguro no es aún una realidad?
En el documento mencionado, Core fue mencionada como una de las organizaciones que hizo contribuciones más sustantivas a la lista de los 25 errores.
-¿Por qué el código seguro no es aún una realidad?
-El “código seguro” es una quimera, una abstracción formal que no existe en la realidad. Es común pero, en mi opinión, un tanto ingenuo pensar que una serie de artefactos intangibles, por lo general bastante complejos (software) creados por seres humanos -que son imperfectos y falibles- puedan llegar a ser lo suficientemente confiables como para que alguien garantice que con ellos sólo se puede hacer lo que sus “creadores” idearon y absolutamente nada más.
Una vez que se deja de lado la definición taxativa de seguridad absoluta y se la relativiza con las preguntas “¿código seguro para qué?” y “¿cuán seguro?”, la respuesta cambia y es más sencilla.
Hoy en día existen sistemas suficientemente seguros para muchas cosas, pero la mayoría del software no es suficientemente seguro para lo que se espera de él. Creo que las expectativas son demasiado grandes pero que los esfuerzos necesarios por satisfacerlas, incluso las más modestas, siempre son subestimados o ignorados.
-¿Las empresas desarrolladoras de software están preocupadas para que el código que escriben sea más seguro?
Una vez que se deja de lado la definición taxativa de seguridad absoluta y se la relativiza con las preguntas “¿código seguro para qué?” y “¿cuán seguro?”, la respuesta cambia y es más sencilla.
Hoy en día existen sistemas suficientemente seguros para muchas cosas, pero la mayoría del software no es suficientemente seguro para lo que se espera de él. Creo que las expectativas son demasiado grandes pero que los esfuerzos necesarios por satisfacerlas, incluso las más modestas, siempre son subestimados o ignorados.
-¿Las empresas desarrolladoras de software están preocupadas para que el código que escriben sea más seguro?
-Sólo lo están en la medida que esa preocupación sea funcional a su negocio. Es una preocupación importante para las de mayor relevancia a nivel mundial, ya que son las que tienen más por perder si su código no sólo resulta ser inseguro, sino que además esa inseguridad puede ser explotada con consecuencias negativas para sus clientes.
Lamentablemente, la mayoría de las empresas desarrolladoras de software que hoy se preocupan por la seguridad de su código llegaron a ese estadio de forma reactiva, y como consecuencia de haber pasado por alguna serie de incidentes negativos con la seguridad de su software.
Pasar por un proceso como el que describo para empezar a preocuparse por la seguridad del software y empezar a hacer algo al respecto es innecesario y generalmente bastante costoso.
Para muchas pequeñas y medianas empresas que desarrollan software o, en general, tecnologías de información, y que pueden ser más flexibles y dinámicas que las grandes productoras de software, un tratamiento más proactivo o preventivo del problema puede resultar más efectivo y menos costoso.
En todos los casos, a la larga, creo que es siempre mejor resolver las fallas y defectos del software en el estadio más temprano posible de su ciclo de desarrollo. Para las empresas desarrolladoras de software comercial decidir cómo, cuándo y de qué manera hacerlo es una decisión de negocios y no técnica; los clientes (usuario) del software en cuestión pueden tener gran influencia en esa decisión.
-¿Qué medidas están tomando en ese sentido?
Lamentablemente, la mayoría de las empresas desarrolladoras de software que hoy se preocupan por la seguridad de su código llegaron a ese estadio de forma reactiva, y como consecuencia de haber pasado por alguna serie de incidentes negativos con la seguridad de su software.
Pasar por un proceso como el que describo para empezar a preocuparse por la seguridad del software y empezar a hacer algo al respecto es innecesario y generalmente bastante costoso.
Para muchas pequeñas y medianas empresas que desarrollan software o, en general, tecnologías de información, y que pueden ser más flexibles y dinámicas que las grandes productoras de software, un tratamiento más proactivo o preventivo del problema puede resultar más efectivo y menos costoso.
En todos los casos, a la larga, creo que es siempre mejor resolver las fallas y defectos del software en el estadio más temprano posible de su ciclo de desarrollo. Para las empresas desarrolladoras de software comercial decidir cómo, cuándo y de qué manera hacerlo es una decisión de negocios y no técnica; los clientes (usuario) del software en cuestión pueden tener gran influencia en esa decisión.
-¿Qué medidas están tomando en ese sentido?
-Por lo general, cuando hay medidas concretas, ellas conforman una colección de actividades y prácticas inconexas entre sí: actividades genéricas y esporádicas de capacitación en “programación segura”, utilización de herramientas que automatizan la identificación y búsqueda de defectos, implantación de procesos y estándares de ingeniería de software reconocidos por la industria pero no necesariamente adecuados para el propósito en cuestión, contratación de servicios especializados de consultoría y/o asesoramiento en la materia, entre otras.
Todas estas actividades serán útiles en la medida en que respondan a una estrategia más general para la seguridad del código que las englobe y a un análisis racional de los riesgos, costos y el retorno de la inversión para implementarlas. Ese nivel de sofisticación para determinar qué hacer al respecto de la seguridad de los desarrollos es virtualmente inexistente en la industria de software de la Argentina y muy poco frecuente en la de cualquier otro lugar.-¿Se debe replantear por completo la forma en que se escribe el código?-No. Los cambios revolucionarios en la forma en que se escribe código, las herramientas o los procesos que se utilizan no garantizan que los resultados sean mejores, aunque posiblemente sí que sean distintos. Creo más bien que hay que dedicarle más tiempo, dinero y esfuerzo a buscar un mejoramiento constante en la calidad del software (seguridad incluida) y tener la paciencia, inteligencia y constancia para hacer que ese proceso resulte eficiente y tenga un sentido práctico claro en el ámbito específico del grupo o empresa que lo implementa.
Todo esto puede sonar un tanto críptico o vago pero, en resumen, sólo quiere decir que si bien no hay recetas pre-armadas para resolver el problema en cualquier ámbito, en la mayor parte de los casos tampoco hace falta cambiar completamente todo para lograr mejoras visibles.
Todas estas actividades serán útiles en la medida en que respondan a una estrategia más general para la seguridad del código que las englobe y a un análisis racional de los riesgos, costos y el retorno de la inversión para implementarlas. Ese nivel de sofisticación para determinar qué hacer al respecto de la seguridad de los desarrollos es virtualmente inexistente en la industria de software de la Argentina y muy poco frecuente en la de cualquier otro lugar.-¿Se debe replantear por completo la forma en que se escribe el código?-No. Los cambios revolucionarios en la forma en que se escribe código, las herramientas o los procesos que se utilizan no garantizan que los resultados sean mejores, aunque posiblemente sí que sean distintos. Creo más bien que hay que dedicarle más tiempo, dinero y esfuerzo a buscar un mejoramiento constante en la calidad del software (seguridad incluida) y tener la paciencia, inteligencia y constancia para hacer que ese proceso resulte eficiente y tenga un sentido práctico claro en el ámbito específico del grupo o empresa que lo implementa.
Todo esto puede sonar un tanto críptico o vago pero, en resumen, sólo quiere decir que si bien no hay recetas pre-armadas para resolver el problema en cualquier ámbito, en la mayor parte de los casos tampoco hace falta cambiar completamente todo para lograr mejoras visibles.
César Dergarabedian
(©) iProfesional.com
Link relacionado:
- 2009 CWE/SANS Top 25 Most Dangerous Programming Errors
- La seguridad en el código informático es cada vez más una inquietud de todos
1 comentario:
Intresante blog, saludos.
Publicar un comentario