El Día 0 fue el Día 1 del desarrollo
Un estudio reciente de la Universidad de Columbia descubrió que estamos abrumados por más de 70 decisiones al día. Eso si solo contamos las importantes, ya que una investigación anterior de la Universidad de Cornell determinó que tomamos más de 200 decisiones sólo con respecto a la comida en un día determinado.
Muchas de las decisiones que tomamos en un día son intrascendentes a largo plazo. El impacto es mínimo y la mayoría no pueden clasificarse como "buenos" o "malos". Son simplemente la elección que hicimos. Pero algunas decisiones tienen consecuencias importantes. Algunas son intencionales y se hacen con previsión. Otros son imprevistos y sólo se hacen evidentes en retrospectiva.
Algunas consecuencias no deseadas que parecen obvias en retrospectiva se relacionan con la seguridad de nuestras aplicações.
OPCIONES: PLATAFORMAS, MARCOS Y COMPONENTES
Desde el primer día de desarrollo se toman decisiones. Muchas de esas opciones giran en torno a plataformas y marcos, bibliotecas y componentes de terceros. Hay muchas de estas decisiones que se toman durante el desarrollo. Se estima que hoy en día entre el 80 y el 90 % de una aplicação está compuesta por componentes de código abierto o de terceros . Cada una de las decisiones que conducen a la inclusión de un componente de código abierto o de terceros tiene consecuencias potenciales, particularmente con respecto a la seguridad de la aplicação . El análisis de Black Duck Software afirma que hay un promedio de 105 componentes de código abierto por cada oferta de software comercial.
Esas consecuencias, a primera vista, no son tan aterradoras. Después de todo, una investigación de Contrast Security descubre que las bibliotecas de software representan solo el 7% de las vulnerabilidades. Black Duck encontró un promedio de 22,5 vulnerabilidades de código abierto por aplicação. El cuarenta por ciento (40%) de esas vulnerabilidades fueron calificadas como “graves”. Aun así, eso es mínimo considerando que el 10-20% restante de una aplicação (código personalizado) es responsable de la mayoría de las vulnerabilidades en las aplicações.
Lamentablemente, la mayor parte de las vulnerabilidades no se revelan a través de CVE y códigos de explotación de muestra que se vuelven fácilmente accesibles para los atacantes. Los actores maliciosos no necesitan esforzarse tanto para encontrar objetivos en un entorno en el que miles y miles de aplicações web suelen utilizar los mismos componentes y bibliotecas. En este momento, builtwith.com, que rastrea el uso de la tecnología utilizada para crear aplicaciones y sitios web, cuenta casi 40.000 sitios activos que dependen de Apache Struts. La mayoría de nosotros somos conscientes de la explotación exitosa de vulnerabilidades publicadas en Apache Struts 2 que provocaron un leve pánico en Internet. Pánicos similares han sido provocados por revelaciones de vulnerabilidades graves que involucran otras bibliotecas de código abierto y de terceros ampliamente utilizadas, como OpenSSL.
Pero no es sólo la elección de si incluimos bibliotecas o componentes de terceros o creamos aplicaciones en marcos de código abierto lo que es potencialmente problemático. Otras decisiones que tomamos durante el desarrollo también pueden tener repercusiones graves, especialmente cuando conducen a prácticas de desarrollo inseguras.
OPCIONES: COMERCIO DE SEGURIDAD POR VELOCIDAD
Nunca es una sorpresa escuchar que se ha cambiado la seguridad por la velocidad. Siempre ha sido así. Una encuesta de McAfee de 2014 a 504 profesionales de seguridad descubrió que "aproximadamente un tercio de los operadores de las organizaciones encuestadas admitieron que intentan aumentar el rendimiento de la red desactivando rutinariamente las funciones de seguridad del firewall".
Resulta que el desarrollo no es diferente. Su enfoque no está en la velocidad de ejecución, sino en la velocidad del pipeline. Para satisfacer la demanda de lanzamientos más oportunos de aplicações y actualizaciones al mercado, muchos admiten que omiten por completo la seguridad durante el desarrollo. Una encuesta realizada en 2017 por Arxan | IBM a desarrolladores de IoT y dispositivos móviles descubrió que el 26 % de los encuestados no prueba las aplicaciones móviles en absoluto para detectar problemas de seguridad, y casi la mitad (48 %) no prueba las aplicaciones de IoT. La presión para cumplir fue citada por el 69% como la razón por la que a menudo se omite la seguridad.
Una encuesta realizada entre los asistentes a nuestro evento para clientes, Agility , este verano reforzó que esta es la realidad. Más de la mitad (el 62%) admitió que había cambiado la seguridad por la velocidad en su organización.
Y luego están las decisiones que se toman respecto de cómo las organizaciones abordan las vulnerabilidades descubiertas. El análisis de Black Duck reveló que el 10% de las aplicações escaneadas en 2018 todavía eran vulnerables a la vulnerabilidad Heartbleed de 2014. Un estudio de ServiceNow realizado por Ponemon descubrió que un preocupante 57% de las víctimas de violaciones revelaron que podrían haber evitado la violación instalando un parche disponible.
LAS ELECCIONES TIENEN CONSECUENCIAS
Desde el primer día de desarrollo hasta la fase posterior a la implementación, las decisiones que tomamos con respecto a la seguridad de toda la pila de aplicação son importantes. Estas opciones no son comparables con comer una hamburguesa o una ensalada para el almuerzo; son decisiones cuyas ramificaciones pueden repercutir no solo en el área de TI y el negocio, sino también en los clientes que confían en que los proveedores de aplicaciones tomen la seguridad en serio.
Somos muy pocos los que podemos afirmar que nunca hemos recibido una carta de “Estimado usuario de la aplicación” informándonos de que nuestros datos han sido expuestos. Esto no es una licencia para ser negligentes con la seguridad; por el contrario, todos deberíamos esforzarnos por hacer lo mejor para nuestros clientes en la protección de su información personal y privada.
La mejor manera de hacerlo es reconocer que cada elección desde el primer día de desarrollo es una oportunidad para mejorar la seguridad de las aplicações que desarrollamos. Elige consciente y sabiamente.