Un estudio reciente de la Universidad de Columbia reveló que nos vemos abrumados por más de 70 decisiones al día. Y eso contando solo las importantes, ya que una investigación anterior de la Universidad de Cornell determinó que cada día tomamos más de 200 decisiones únicamente en relación con la comida.
Muchas de las decisiones que tomamos a lo largo del día carecen de importancia a largo plazo. Su impacto es mínimo y la mayoría no pueden calificarse de «buenas» o «malas». Son simplemente la opción que elegimos. Sin embargo, algunas decisiones tienen consecuencias importantes. Algunas son intencionadas y se toman tras una cuidadosa reflexión. Otras son involuntarias y solo resultan evidentes a posteriori.
Algunas consecuencias imprevistas que parecen obvias en retrospectiva están relacionadas con la seguridad de nuestras aplicaciones.
DECISIONES: PLATAFORMAS, FRAMEWORKS Y COMPONENTES
Desde el primer día de desarrollo se toman decisiones. Muchas de ellas giran en torno a plataformas y frameworks, bibliotecas y componentes de terceros. Durante el desarrollo se toman muchas decisiones de este tipo. Actualmente, se estima que entre el 80 % y el 90 % de una aplicación está compuesto por componentes de código abierto o de terceros. Cada decisión que conlleva la inclusión de un componente de código abierto o de terceros puede tener consecuencias, especialmente en lo que respecta a la seguridad de la aplicación. El análisis de Black Duck Software indica que cada producto de software comercial contiene una media de 105 componentes de código abierto.
A primera vista, esas consecuencias no son tan alarmantes. Al fin y al cabo, un estudio de Contrast Security concluye que las bibliotecas de software representan solo el 7 % de las vulnerabilidades. Black Duck detectó una media de 22,5 vulnerabilidades de código abierto por aplicación. El cuarenta por ciento (40 %) de esas vulnerabilidades se calificaron como «graves». Aun así, es una cifra mínima si se tiene en cuenta que el 10-20 % restante de una aplicación —el código personalizado— es responsable de la mayoría de las vulnerabilidades de las aplicaciones.
Por desgracia, la mayoría de las vulnerabilidades no se divulgan mediante CVE ni van acompañadas de código de explotación de ejemplo fácilmente accesible para los atacantes. Los ciberdelincuentes no tienen que esforzarse demasiado para encontrar objetivos en un entorno en el que miles y miles de aplicaciones web suelen utilizar los mismos componentes y bibliotecas. Actualmente, builtwith.com —que realiza un seguimiento de las tecnologías utilizadas para crear aplicaciones y sitios web— contabiliza cerca de 40.000 sitios activos que dependen de Apache Struts. La mayoría conocemos la explotación con éxito de vulnerabilidades publicadas en Apache Struts 2, que provocó cierto pánico en Internet. La divulgación de vulnerabilidades graves en otras bibliotecas de código abierto y de terceros muy utilizadas, como OpenSSL, ha provocado situaciones de pánico similares.
Pero no solo puede resultar problemática la decisión de incluir bibliotecas o componentes de terceros, o de desarrollar aplicaciones sobre frameworks de código abierto. Otras decisiones que tomamos durante el desarrollo también pueden tener graves repercusiones, especialmente cuando dan lugar a prácticas de desarrollo poco seguras.
DECISIONES: SACRIFICAR LA SEGURIDAD POR LA RAPIDEZ
Nunca sorprende oír que se ha sacrificado la seguridad en favor de la velocidad. Siempre ha sido así. Una encuesta de McAfee de 2014 realizada a 504 profesionales de la seguridad reveló que «en aproximadamente un tercio de las organizaciones encuestadas, los operadores admitieron que intentan mejorar el rendimiento de la red desactivando habitualmente las funciones de seguridad del cortafuegos».
Resulta que el desarrollo no es diferente. Su prioridad no es la velocidad de ejecución, sino la del proceso de desarrollo. Para satisfacer la demanda de lanzar al mercado aplicaciones y actualizaciones con mayor rapidez, muchos reconocen que omiten por completo la seguridad durante el desarrollo. Una encuesta de Arxan | IBM de 2017 realizada a desarrolladores de aplicaciones móviles y del IoT reveló que el 26 % de los encuestados no somete las aplicaciones móviles a ningún tipo de prueba para detectar problemas de seguridad, y casi la mitad (el 48 %) tampoco prueba las aplicaciones del IoT. El 69 % señaló la presión por entregar como el motivo por el que a menudo se omite la seguridad.
Una encuesta realizada entre los asistentes a nuestro evento para clientes, «Agility», este verano confirmó que esta es la realidad. Más de la mitad —el 62 %— admitió que en su organización habían sacrificado la seguridad en favor de la rapidez.
Y luego están las decisiones que se toman sobre cómo abordan las organizaciones las vulnerabilidades descubiertas. El análisis de Black Duck reveló que el 10 % de las aplicaciones analizadas en 2018 seguían siendo vulnerables a Heartbleed, una vulnerabilidad de 2014. Un estudio de ServiceNow realizado por Ponemon reveló un dato preocupante: el 57 % de las víctimas de brechas de seguridad reconocieron que podrían haberlas evitado instalando un parche disponible.
LAS DECISIONES 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 aplicaciones son importantes. No son decisiones comparables a elegir entre una hamburguesa o una ensalada para comer; sus repercusiones pueden afectar no solo al departamento de TI y a la empresa, sino también a los clientes que confían en que los proveedores de aplicaciones se tomen la seguridad en serio.
Muy pocos podemos afirmar que nunca hemos recibido una carta dirigida al «Estimado usuario de la aplicación» en la que se nos informa de que nuestros datos han quedado expuestos. Eso no justifica que nos tomemos la seguridad a la ligera; al contrario, todos debemos esforzarnos por proteger mejor la información personal y privada de nuestros clientes.
La mejor manera de hacerlo es reconocer que cada decisión que tomamos desde el primer día de desarrollo supone una oportunidad para mejorar la seguridad de las aplicaciones que desarrollamos. Elijamos de forma consciente y acertada.
Sobre el autor
Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.
Más artículos de Lori Mac VittieArtículos relacionados del blog
Proteger los endpoints de las API dificulta la seguridad de las API
Descubre las complejidades de la seguridad de las API, los retos a los que se enfrentan las organizaciones, la evolución de los ataques contra endpoints de API y la necesidad de políticas de seguridad adaptadas.
¿Qué es el sesgo de la IA y por qué es importante para TI?
Descubre los fundamentos del aprendizaje de la IA. Aprende cómo pueden surgir sesgos en la IA y qué riesgos plantean para las TI y la transformación digital.
Redefiniendo la ciberseguridad en el extremo de la nube distribuida con IA y telemetría en tiempo real
La transformación digital y la adopción de tecnologías en la nube están provocando cambios en las arquitecturas de las aplicaciones. Estos cambios introducen nuevas superficies de ataque, que son el objetivo de métodos de ataque avanzados, altamente organizados y con motivaciones económicas. Mediante el uso del framework Morpheus de NVIDIA, F5 está investigando técnicas para detectar estas amenazas avanzadas con telemetría en tiempo real y análisis basados en IA.
El papel de la nube en las aplicaciones nativas del edge
No debería sorprender que, al igual que la aparición de la nube dio lugar a las aplicaciones nativas de la nube, el edge esté impulsando un conjunto de aplicaciones nativas del edge. Sin embargo, estas aplicaciones no residirán únicamente en el edge. Al mismo tiempo, están surgiendo nuevos patrones arquitectónicos que aprovechan las aplicaciones alojadas en la nube y en el centro de datos.
La creciente diversidad de ubicaciones y usuarios está impulsando a las empresas hacia el edge
En el contexto del ámbito de las aplicaciones, el término «usuario» siempre se ha referido a la entidad que interactúa con una aplicación. Del mismo modo que los cambios en las arquitecturas de las aplicaciones impulsan cambios en las tecnologías que permiten ofrecerlas y protegerlas, los cambios en la definición de usuario han provocado cambios en los lugares donde se despliegan las aplicaciones.
El edge está impulsando un renacimiento de las infraestructuras
A medida que las organizaciones aumentan la generación de datos y tratan de extraer valor empresarial de ellos, sin duda recurrirán a la analítica y la automatización basadas en la IA y el aprendizaje automático. Precisamente este tipo de cargas de trabajo son las que más se beneficiarían de una infraestructura optimizada y, sin embargo, hoy en día son las que menos probabilidades tienen de poder aprovecharla.