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

Según una teoría muy conocida, las cucarachas pueden sobrevivir prácticamente a todo, incluso a una explosión nuclear. Aunque esta teoría solo es cierta hasta cierto punto, su sencilla composición corporal las hace extremadamente resistentes para su tamaño y difíciles de erradicar en la mayoría de las condiciones.

Me dije... si las cucarachas tuvieran un equivalente en el mundo digital, serían las vulnerabilidades de inyección SQL (SQLi) en el código. Esta vulnerabilidad se conoce desde hace más de veinte años, pero las organizaciones siguen siendo víctimas de ella una y otra vez. El ataque generalizado y costoso contra 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 200 000 expedientes de votantes, lo que llevó al FBI a recomendar a todos los administradores informáticos que reforzaran rápidamente sus prácticas de seguridad.

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

Parece ridículo que esta misma vulnerabilidad siga apareciendo en un número importante de análisis de seguridad de aplicaciones. Sabemos cómo funciona y cómo detenerla. ¿Cómo es posible? La verdad es que la seguridad de nuestro software aún puede mejorarse.

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 con la política del Top 10 de OWASP. Este tema ha sido recurrente en los últimos cinco años, ya que se han detectado inyecciones SQL en casi una de cada tres aplicaciones analizadas recientemente. Esto demuestra que se trata de un problema endémico: no aprendemos de nuestros errores y los responsables de la seguridad informática parecen tener dificultades para contratar a suficientes profesionales especializados en seguridad. Por regla general, la proporción entre especialistas en seguridad de aplicaciones y desarrolladores es insuficiente para cada 100.

¿Por qué la seguridad del software está en modo de supervivencia?

No es ningún secreto que los especialistas en seguridad son escasos, pero también debemos prestar atención al hecho de que los desarrolladores no resuelven los problemas a medida que surgen y están claramente mal equipados para no introducir vulnerabilidades desde el principio. En el mismo informe de Veracode, se reveló que solo el 14,4 % de todas las vulnerabilidades relacionadas con el desarrollo contaban con medidas de mitigación documentadas. En otras palabras, la mayoría de las vulnerabilidades se presentaron sin medidas de mitigación relacionadas con el desarrollo. Menos de un tercio de las vulnerabilidades se corrigieron durante los primeros 90 días, y el 42 % de las vulnerabilidades nunca se corrigieron durante el período de desarrollo.

Hablo constantemente con profesionales de la seguridad, RSSI y directores generales y, como anécdota, he descubierto que muchas empresas están tan frustradas por el número de vulnerabilidades detectadas que no pueden mitigarse (además de la plaga conocida como falsos positivos), que dejan completamente de buscarlas, cruzan los dedos y esperan que todo salga bien.

¿Por qué los profesionales de la seguridad de aplicaciones permiten que esto suceda?

No se equivoquen: los usuarios de AppSec son muy conscientes de los problemas del código. Después de todo, es una de sus competencias básicas lo que los convierte en un recurso tan valioso para el equipo. Sin embargo, a menudo se ven obstaculizados por varios factores.

Por ejemplo, un responsable de AppSec detectará un problema y preguntará al desarrollador: «¿Puede corregir el código?». La respuesta a esta importante pregunta varía de una organización a otra, pero, en general, el desarrollador está tan ocupado cumpliendo con los estrictos sprints de suministro de funcionalidades que simplemente no tiene tiempo para resolver estos problemas, ni las herramientas adecuadas para ayudarle. Los propios profesionales de la seguridad de las aplicaciones pueden ser capaces de identificar las vulnerabilidades, pero a menudo no tienen las habilidades y/o el acceso necesarios para remediarlas in situ.

También debemos darnos cuenta de que, para cada problema, hay que encontrar una solución, implementarla y luego probarla. Incluso para el más mínimo problema detectado en el código, el tiempo que se necesita para resolverlo, por no hablar de los recursos necesarios, es inmenso. Se pueden introducir más de 700 vulnerabilidades en el software, y es simplemente imposible que una sola persona pueda defenderse de todas ellas. Por esta razón, la mayoría de las empresas se ciñen únicamente al Top 10 de la OWASP. Mientras tanto, los desarrolladores siguen creando funcionalidades y, a su vez, introduciendo vulnerabilidades 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 favorecer el éxito de la codificación segura. No existe ninguna normativa que obligue a las empresas a garantizar que los desarrolladores posean las competencias adecuadas en materia de seguridad, y la triste realidad es que la mayoría de las universidades y los programas de prácticas tampoco preparan a los desarrolladores principiantes para codificar de forma segura.

Cuando una persona desea pilotar un avión, existe un proceso muy riguroso que garantiza una formación, experiencia práctica, controles médicos, conocimientos en materia de seguridad y exámenes antes de poder volar. Nadie se atrevería a imaginar que se le dejaría volar sin esta preparación exhaustiva y esta validación de competencias, pero eso es lo que ocurre a diario con la escritura de código.

Debemos dedicar tiempo a formar a los desarrolladores en la escritura de código seguro. Sin embargo, en el mundo actual, donde el desarrollo de software es rápido y los buenos desarrolladores y profesionales de la seguridad son escasos, esto nunca parece ser una prioridad. Es hora de cambiar de conversación.

Un título reciente del Foro Económico Mundial proclamaba: «No puede haber economía digital sin seguridad», y el contenido que lo acompañaba defendía la necesidad de situar la seguridad en el centro de cualquier estrategia de transformación digital. «La seguridad es lo que protege a las empresas, les permite innovar y crear nuevos productos y servicios. Más allá de su función defensiva, la seguridad proporciona a las empresas una ventaja estratégica en términos de crecimiento».

La mejora de las competencias y los resultados en materia de codificación segura añadirá una potente capa de ciberprotección a las organizaciones, ayudándolas a crear un código más eficaz y rápido. Los desarrolladores no necesitan 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 convertirse en los próximos héroes de la seguridad y la innovación. Son personas muy inteligentes, saben resolver problemas de forma creativa y, por lo general, desean desarrollar sus habilidades. Aproveche sus puntos fuertes con la formación especializada que se merecen y comprométase a cumplir normas de seguridad de software más estrictas. Lea nuestro libro blanco para obtener más información.

Cuando una persona desea pilotar un avión, existe un proceso muy riguroso que garantiza una formación, experiencia práctica, controles médicos, conocimientos en materia de seguridad y exámenes antes de poder volar. Nadie se atrevería a imaginar que se le dejaría volar sin esta preparación exhaustiva y esta validación de competencias, pero eso es lo que ocurre a diario con la escritura de código.