Por qué la inyección SQL es la plaga del mundo de la seguridad de las aplicaciones (y cómo los CISO pueden erradicarla por completo)

Existe una teoría muy conocida que dice que las cucarachas pueden sobrevivir prácticamente a cualquier cosa, incluso a una explosión nuclear. Aunque esta teoría solo es cierta hasta cierto punto, su simple composición corporal las hace muy resistentes en relación con su tamaño, lo que hace que sean difíciles de erradicar en la mayoría de las condiciones.

He estado pensando mucho en ello... Si hay algo en el mundo digital que se pueda comparar con las cucarachas, sin duda es la vulnerabilidad de la inyección SQL (SQLi) en el código.Esta vulnerabilidad se conoce desde hace más de 20 años, pero las organizaciones han sufrido sus efectos en numerosas ocasiones. Su amplia difusión se debe tanto a los costosos ataques dirigidos contra objetivos específicos como a los resultados de la inyección SQL. Tras el hackeo electoral en Illinois, en el que se hicieron públicos 200 000 registros de votantes, el FBI recomendó a todos los administradores de TI que reforzaran rápidamente sus medidas de seguridad.

El informe Hacker Intelligence Initiative de Imperva reveló que, entre 2005 y 2011, se utilizaron ataques SQLi en el 83 % de todas las violaciones de datos denunciadas. A día de hoy, las vulnerabilidades de inyección siguen siendo la mayor amenaza a nivel mundial. OWASP Top 10. Son relativamente sencillas, pero no desaparecen.

Parece absurdo que esta misma vulnerabilidad siga apareciendo en un número considerable de análisis de seguridad de aplicaciones. Conocemos su mecanismo y sabemos cómo impedirla. ¿Cómo es posible que esto siga ocurriendo? La verdad es que nuestra seguridad de software tiene mucho margen de mejora.

El informe sobre la situación de la seguridad del software de Veracode, basado en 400 000 análisis de aplicaciones realizados en 2017, ha revelado unas estadísticas sorprendentes. Solo el 30 % de las aplicaciones superaron las 10 políticas principales de OWASP. Este ha sido un tema recurrente durante los últimos cinco años, y casi un tercio de las aplicaciones analizadas recientemente utilizan inyección SQL.Esto es una prueba de que se trata de un problema generalizado. No estamos aprendiendo de nuestros errores y los CISO parecen enfrentarse a una dura batalla a la hora de contratar personal de seguridad cualificado. Por lo general, una proporción de 1 especialista en seguridad de aplicaciones por cada 100 desarrolladores no es suficiente.

¿Por qué se utiliza la seguridad de software en los dispositivos de soporte vital?

Es bien sabido que hay escasez de expertos en seguridad, pero es evidente que los desarrolladores no corrigen los problemas cuando surgen y que, en primer lugar, no cuentan con los medios necesarios para evitar la introducción de vulnerabilidades. El mismo informe de Veracode reveló que, de todas las vulnerabilidades de desarrollo, solo el 14,4 % contaba con medidas de mitigación documentadas. En otras palabras, la mayoría de las vulnerabilidades se presentaron sin medidas de mitigación de desarrollo.Menos de un tercio de las vulnerabilidades se cerraron en los primeros 90 días, y el 42 % no se cerraron durante el periodo de desarrollo.

Siempre hablo con expertos en seguridad, CISO y directores generales, y me he dado cuenta de que muchas empresas están insatisfechas con el número de vulnerabilidades detectadas que no pueden mitigarse (además de la tragedia que suponen las falsas alarmas) y han dejado de realizar análisis por completo, esperando que todo salga bien.

¿Por qué los profesionales de la seguridad de las aplicaciones provocan esta situación?

Sin duda. Los responsables de AppSec son muy conscientes de los problemas que hay en el código. Al fin y al cabo, esa es una de sus habilidades principales, y eso los convierte en un recurso muy valioso para el equipo. Sin embargo, a menudo se ven obstaculizados por varios factores.

Por ejemplo, el gestor de AppSec detecta un problema y pregunta al desarrollador: «¿Puedes corregir el código?». La respuesta a esta importante pregunta varía según la organización, pero, por lo general, los desarrolladores están tan ocupados cumpliendo con los estrictos sprints de entrega de funciones que no tienen ni el tiempo ni las herramientas adecuadas para resolver el problema. Los propios expertos en seguridad de aplicaciones pueden identificar las vulnerabilidades, pero, en muchos casos, carecen de las habilidades y los derechos de acceso necesarios para corregirlas sobre la marcha.

Además, es necesario reconocer que todos los problemas tienen un proceso que consiste en encontrar una solución, implementarla y probarla. Incluso los problemas más insignificantes que se encuentran en el código requieren recursos, por no hablar del tiempo que lleva corregirlos.El software tiene más de 700 vulnerabilidades, pero es imposible que una sola persona las defienda todas. Por eso la mayoría de las empresas se limitan a seguir el OWASP Top 10. Mientras tanto, los desarrolladores siguen creando funciones y, en última instancia, incorporando vulnerabilidades al código que escriben.

¿Cuál es la solución?

El hecho es que no se proporcionan a los desarrolladores las herramientas y la formación necesarias para llevar a cabo una codificación segura. No existen regulaciones que obliguen a las organizaciones a garantizar que los desarrolladores adquieran las habilidades de seguridad adecuadas. Además, la triste realidad es que la mayoría de las universidades y programas de prácticas no preparan a los desarrolladores junior para que puedan codificar de forma segura.

Cuando alguien quiere pilotar un avión, debe pasar por un proceso muy estricto que incluye formación, experiencia práctica, exámenes médicos, conocimientos de seguridad y pruebas antes de volar. Nadie se imagina que alguien pueda lanzarse al cielo sin una preparación tan minuciosa y una verificación de sus habilidades, pero en la programación esto es algo que ocurre a diario.

Es necesario dedicar tiempo a formar a los desarrolladores para que escriban código seguro. Sin embargo, en el mundo actual, en el que el ritmo de desarrollo de software es rápido y hay escasez de desarrolladores y expertos en seguridad cualificados, parece que esto nunca se convierte en una prioridad. Es hora de cambiar el discurso.

Últimos titulares del Foro Económico Mundial: «No puede haber economía digital sin seguridad», proclama, y en el contenido adjunto se afirma que la seguridad debe ser el núcleo de toda estrategia de transformación digital. «La seguridad protege a las empresas y les permite innovar y crear nuevos productos y servicios. La seguridad no se limita a desempeñar un papel defensivo, sino que también proporciona a las empresas una ventaja competitiva en su crecimiento estratégico».

Mejorar las habilidades y los resultados de la codificación segura añade una potente protección cibernética a la organización y permite crear un código mejor y más rápido. Los desarrolladores no tienen que convertirse en expertos en seguridad, peropara estar en primera línea de defensa contra los ciberataques, necesitan tener un papel activo y práctico. Los desarrolladores pueden convertirse en los próximos héroes de la seguridad y la innovación. Son personas muy inteligentes, creativas a la hora de resolver problemas y, por lo general, están muy motivadas para mejorar sus habilidades. Aproveche sus puntos fuertes con una formación profesional adecuada y anímeles a trabajar para alcanzar unos estándares de seguridad de software más elevados. Lea el informe técnico para obtener más información.

Cuando alguien quiere pilotar un avión, debe pasar por un proceso muy estricto que incluye formación, experiencia práctica, exámenes médicos, conocimientos de seguridad y pruebas antes de volar. Nadie se imagina que alguien pueda lanzarse al cielo sin una preparación tan minuciosa y una verificación de sus habilidades, pero en la programación esto es algo que ocurre a diario.