Por qué las inyecciones SQL son las cucarachas del mundo de la seguridad de las aplicaciones (y cómo los CISO pueden erradicarlas de una vez por todas)

Existe una teoría conocida que afirma que las cucarachas pueden sobrevivir prácticamente a todo, incluso a una explosión nuclear. Aunque esta teoría solo es cierta hasta cierto punto, debido a la simple composición de su cuerpo, son extremadamente resistentes para su tamaño y difíciles de exterminar en la mayoría de las condiciones.

He estado pensando... si las cucarachas tuvieran un equivalente en el mundo digital, serían las vulnerabilidades de inyección SQL (SQLi) en el código. Se trata de una brecha de seguridad conocida desde hace más de veinte años, pero las empresas siguen siendo víctimas de ella una y otra vez. El ataque generalizado y costoso a Target fue el resultado de una inyección SQL, al igual que un caso de piratería informática en las elecciones de Illinois, donde se revelaron los datos de 200 000 votantes, lo que llevó al FBI a recomendar a todos los administradores de TI que trabajaran rápidamente para reforzar sus prácticas de seguridad.

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

Parece ridículo que la misma vulnerabilidad de seguridad siga apareciendo en un número considerable de análisis de seguridad de aplicaciones. Sabemos cómo funciona y sabemos cómo detenerla. ¿Cómo es posible? La verdad es que la seguridad de nuestro software tiene mucho margen de mejora.

El informe de Veracode sobre el estado de la seguridad del software, basado en 400 000 análisis de aplicaciones realizados en 2017, reveló «una estadística alarmante: solo el 30 % de las aplicaciones cumplían la directriz OWASP Top 10. Esta ha sido una constante en los últimos cinco años. Casi una de cada tres aplicaciones analizadas recientemente presentaba inyecciones SQL. Esto demuestra que se trata de un problema muy extendido. No aprendemos de nuestros errores y, al parecer, los CISO se enfrentan a una dura batalla para encontrar suficientes talentos en materia de seguridad. Por lo general, la proporción de especialistas en seguridad de aplicaciones con respecto a los desarrolladores es insuficiente, con una ratio de 1:100.

¿Por qué la seguridad del software es vital?

No es ningún secreto que hay escasez de talento especializado en seguridad, pero también debemos tener en cuenta que los desarrolladores no solucionan los problemas inmediatamente cuando surgen y, evidentemente, no están preparados para evitar que se produzcan vulnerabilidades de seguridad. En el mismo informe de Veracode se reveló que solo hay medidas correctivas documentadas para el 14,4 % de todas las vulnerabilidades de seguridad en el desarrollo. En otras palabras, la mayoría de las vulnerabilidades de seguridad se notificaron sin medidas correctivas. Menos de un tercio de las vulnerabilidades de seguridad se corrigieron en los primeros 90 días, y el 42 % de las vulnerabilidades de seguridad nunca se corrigieron durante el período de desarrollo.

Hablo constantemente con expertos en seguridad, CISO y directores generales, y me he dado cuenta de que muchas empresas están tan frustradas por el número de vulnerabilidades de seguridad detectadas que no pueden mitigarse (además de la lacra que son las falsas alarmas) que han dejado de buscarlas, cruzan los dedos y esperan lo mejor.

¿Por qué los expertos en seguridad de aplicaciones permiten que esto suceda?

No se equivoque: los empleados de AppSec son muy conscientes de los problemas que hay en el código. Al fin y al cabo, esa es una de sus competencias principales, lo que los convierte en un recurso tan valioso para el equipo. Sin embargo, a menudo se ven afectados por varios factores.

Por ejemplo, un gestor de seguridad de aplicaciones encuentra un problema y pregunta al desarrollador: «¿Puede reparar el código?». La respuesta a esta importante pregunta varía de una organización a otra, pero, en general, el desarrollador está tan abrumado por el cumplimiento de estrictos sprints para la implementación de funciones que simplemente no tiene tiempo para solucionar estos problemas, ni tampoco las herramientas adecuadas para ayudarle. Los expertos en AppSec pueden ser capaces de identificar las vulnerabilidades de seguridad, pero a menudo no tienen las habilidades y/o el acceso necesarios para solucionarlas in situ.

También debemos tener claro que para cada problema existe un proceso en el que se debe encontrar una solución, implementarla y luego probarla. Incluso para el problema más pequeño que se encuentra en el código, el tiempo que puede llevar solucionarlo, por no hablar de los recursos necesarios, es inmenso. Hay más de 700 vulnerabilidades de seguridad que pueden introducirse en el software, y es simplemente imposible que una sola persona pueda protegerse de todas ellas. Por esta razón, la mayoría de las empresas se limitan a seguir el OWASP Top 10. Mientras tanto, los desarrolladores crean constantemente nuevas funciones y, a cambio, introducen continuamente vulnerabilidades de seguridad en el código que escriben.

¿Cuál es la solución?

El hecho es que no proporcionamos a nuestros desarrolladores las herramientas y la formación necesarias para fomentar una programación segura y eficaz. No existen normas que obliguen a las empresas a garantizar que los desarrolladores cuenten con los conocimientos adecuados en materia de seguridad, y la triste realidad es que la mayoría de las universidades y programas de prácticas tampoco preparan a los jóvenes desarrolladores para programar de forma segura.

Si alguien quiere pilotar un avión, debe seguir un procedimiento muy estricto que garantiza que reciba formación, experiencia práctica, exámenes médicos, conocimientos de seguridad y pruebas antes de poder volar. Nadie se atrevería a imaginar que alguien sin esta preparación exhaustiva y sin la validación de sus habilidades volara por los aires, pero eso es precisamente lo que ocurre a diario al escribir código.

Debemos dedicar tiempo a enseñar a los desarrolladores a escribir código seguro. Sin embargo, en el mundo actual, en el que el desarrollo de software es vertiginoso y escasean los buenos desarrolladores y expertos en seguridad, esto nunca parece ser una prioridad. Es hora de cambiar el discurso.

Un titular reciente del Foro Económico Mundial proclamaba: «Sin seguridad no puede haber economía digital», y en el contenido adjunto se argumentaba la necesidad de la seguridad como elemento central de cualquier estrategia de transformación digital. «La seguridad protege a las empresas y les permite ser innovadoras y desarrollar nuevos productos y servicios. La seguridad no solo tiene una función defensiva, sino que también ofrece a las empresas una ventaja estratégica para el crecimiento».

La mejora de las habilidades y los resultados en la programación segura proporcionará a las empresas un potente nivel de protección cibernética y les ayudará a crear un código mejor y más rápido. Los desarrolladores no tienen que convertirse en expertos en seguridad, pero deben estar capacitados de forma positiva y práctica para ser la primera línea de defensa contra los ciberataques. Los desarrolladores pueden ser los próximos héroes de la seguridad y la innovación. Son personas muy inteligentes, creativas a la hora de resolver problemas y, en general, interesadas en ampliar sus habilidades. Aproveche sus puntos fuertes con la formación especializada que se merecen y comprométase con un estándar más alto de seguridad del software. Lea nuestro informe técnico para obtener más información.

Si alguien quiere pilotar un avión, debe seguir un procedimiento muy estricto que garantiza que reciba formación, experiencia práctica, exámenes médicos, conocimientos de seguridad y pruebas antes de poder volar. Nadie se atrevería a imaginar que alguien sin esta preparación exhaustiva y sin la validación de sus habilidades volara por los aires, pero eso es precisamente lo que ocurre a diario al escribir código.