Piensa en la última vez que estuviste en el trabajo, quizás en un equipo de proyecto de software trabajando con un plazo imposible. Y entonces, llega tu jefe y te dice que hay que hacer una formación de seguridad obligatoria, y que hay que meterla con calzador en tu jornada laboral además de todo lo demás.

Ellos lo saben, y tú lo sabes. Es una gran molestia, pero por razones de cumplimiento, estarás reproduciendo unos aburridos vídeos de formación en segundo plano mientras sigues codificando, entrando y saliendo de ambas tareas y no prestando toda tu atención a ninguna de ellas. Este es un escenario común; es altamente perturbador, y hace perder el tiempo a todos. La mayoría de la formación en seguridad es demasiado genérica, y es fácil ignorar algo que entra y sale de la jornada laboral sin ningún valor real.

Como empresa, nuestro objetivo es ofrecerle un tipo de formación en seguridad mejor y más eficaz, y esto nace de saber exactamente lo que es estar desvinculado de lo que el equipo de AppSec le dice que es importante, cuando cada una de sus prioridades está desalineada. Lo interesante, sin embargo, es que empezamos a pensar en lo que podíamos hacer para reducir la barrera para recibir formación cuando la necesitas: incluso con nuestra plataforma completa, hay algunos pasos que te alejan de tu trabajo, en momentos en los que todavía necesitas un empujón útil pero no puedes dedicar un bloque de concentración a una sesión de formación.

Hemos estudiado cómo se podría implementar el microaprendizaje en el flujo de trabajo, en el IDE o en el gestor de incidencias, de una forma más fluida. Y esto es lo que se nos ocurrió:

Esto se basa en los principios de Just-in-Time (JiT), en los que se le sirve el conocimiento adecuado, en el momento adecuado para que sea inmediatamente efectivo y útil. Es lo contrario del enfoque de aprendizaje "por si acaso", que a menudo es un estado de sobrecarga de información que quita un tiempo precioso y espacio para construir características.

Un código de calidad es un código seguro, y si necesitas un compañero de seguridad no invasivo con el que colaborar de vez en cuando, entonces puede valer la pena que lo pruebes.

Elimine las barreras y lleve la formación hasta usted.

La ciberseguridad puede interesar a algunos, pero no a todos. Y nadie debe esperar que los desarrolladores se conviertan en expertos en seguridad: eso sigue siendo tarea de los equipos especializados en AppSec. Sin embargo, los desarrolladores conscientes de la seguridad son venerados por sus habilidades y la protección que pueden ofrecer a las organizaciones desde la fase de creación del código. Es un puesto muy demandado, y se pueden sentar las bases con el tiempo gracias al microaprendizaje contextual.

Ahora bien, si piensas en la formación integrada como algo más parecido a Clippy(que en paz descanse), es importante tener en cuenta que en el caso de las integraciones de Secure Code Warrior, están construidas por desarrolladores para desarrolladores, por lo que el factor de irritación se ha tenido en cuenta y se ha eliminado.

Vamos a comprobarlo en acción:

Secure Code Warrior para Github inspecciona el código en busca de referencias de Common Weakness Enumeration (CWE) u OWASP en las etiquetas, el título de la incidencia y el cuerpo de la misma para mostrar formación contextual en tiempo real. Si se encuentra una referencia a una vulnerabilidad, se publicará un comentario en la incidencia para ayudar a su rápida resolución y a la prevención de vulnerabilidades recurrentes. Se integra con el problema sin interrumpir su proceso, o hacerle saltar a través de aros para una solución.

Y si se utiliza Jira, el proceso es similar:

Ahora, para las superestrellas de la seguridad, es importante recordar que no todo depende de ti para hacer que la magia ocurra. Vas a necesitar apoyo, formación y una razón para tomarte la seguridad en serio e introducirla en tu propio flujo de trabajo. Por suerte, todo esto forma parte de un proceso DevSecOps que funciona, y muchas organizaciones ya están tomando nota. ¿Por qué no empezar con ventaja?

Descárguelos ahora y díganos lo que piensa.

Desde hace unos años, parece que los ingenieros de software de todo el mundo no se cansan de programar con Rust. Este lenguaje de programación de sistemas relativamente nuevo, producido por Mozilla, ha capturado los corazones de la comunidad de Stack Overflow y, como cohorte muy poco propensa a sufrir tonterías, cuando votan algo como el"lenguaje de programación más amado" cinco años seguidos, es hora de que todos nos sentemos y tomemos nota.

El lenguaje de programación Rust incorpora elementos conocidos y funcionales de lenguajes de uso común, trabajando con una filosofía diferente que se deshace de la complejidad, al tiempo que introduce rendimiento y seguridad. Es una curva de aprendizaje, y muchos desarrolladores no tienen la oportunidad de jugar mucho con él: sólo el 5,1% de los encuestados en Stack Overflow lo utilizan habitualmente. Sin embargo, dejando esto de lado, no se puede negar que es un lenguaje apasionante, y con mucha más potencia de seguridad que sus predecesores, como C y C++. La adopción masiva va a requerir algunos cambios, tanto de comportamiento como tecnológicos... pero ahora mismo, sigue captando la atención de los desarrolladores a nivel teórico.  

... pero espera, tenemos que iluminar una cosa más: es importante tener en cuenta que Rust es un lenguaje de programación que prioriza la seguridad de la memoria, y la erradicación de los errores de seguridad que están casados con problemas comunes de gestión de la memoria. Estos son un gran problema (y sin duda causan más de un equipo de AppSec migrañas), pero no son los únicos desafíos de codificación segura que enfrentamos.

¿Qué impide exactamente el óxido? ¿Y en qué aspectos del panorama de la seguridad seguimos estando expuestos? Desgranemos el último unicornio de la programación:

La nueva frontera de la programación de sistemas modernos con seguridad de memoria

El equipo de investigación y desarrollo de Mozilla ha trabajado en algunos proyectos increíbles, y la inversión en la programación de Rust como pionera del código abierto no es una excepción. Su vídeo introductorio ofrece una visión de su ética, con el tema clave muy claro: el enfoque actual de la seguridad del software es defectuoso, y Rust está diseñado para resolver gran parte de ese problema.

Parece demasiado simplista, sobre todo porque cada dos por tres nos enfrentamos a enormes violaciones de datos, como la reciente y espantosa metedura de pata de EasyJet. Millones de registros de datos se ven comprometidos con frecuencia, casi siempre obra de una vulnerabilidad de la aplicación web, una mala configuración de la seguridad o un ataque de phishing, y lenguajes como C++ existen desde hace décadas. Sin embargo, no ha sido suficiente tiempo para que los desarrolladores los dominen hasta el punto de aplicar las mejores prácticas de codificación segura. ¿Por qué Rust debería ser diferente? Ya han aparecido nuevos lenguajes, y no es que hayan encontrado una manera de erradicar las vulnerabilidades comunes, o de asegurar que cualquier código escrito sea mágicamente perfecto cuando se compila.

Aunque el concepto sea sencillo, a veces son las respuestas simples las que conquistan las preguntas complejas. Rust es, en todo el sentido de la palabra, una revolución en la programación de sistemas a prueba de memoria que cumple con sus promesas en muchos aspectos... y ciertamente salva el tocino de los desarrolladores que son susceptibles de introducir errores que pueden causar grandes problemas si no se detectan. Java, C, C++, e incluso lenguajes más nuevos como Kotlin y Golang, siguen siendo bastante implacables para el desarrollador que no es consciente de la seguridad. Con ellos, no hay advertencias incorporadas, no hay señales particulares de que la impresionante característica que acaba de ser compilada tiene un gremlin de seguridad escondido bajo el capó.

Así que vamos a profundizar:

¿Qué hace que el óxido sea tan seguro?

Por lo general, un desarrollador tiene como objetivo principal crear características, asegurándose de que sean funcionales y fáciles de usar - tal vez incluso fuentes de orgullo que estarían felices de mostrar en su currículum. Es totalmente normal que un desarrollador cree un gran software, lo envíe y pase al siguiente gran proyecto. En ese momento, los equipos de seguridad comprueban si hay vulnerabilidades y, si las encuentran, su aplicación "terminada" puede volver a su equipo para que la corrijan. El problema puede ser sencillo, o puede estar completamente fuera del alcance razonable de un desarrollador para remediarlo.

El problema es que a nivel superficial, los fallos de seguridad no eran aparentes en absoluto, y si el escaneo, las pruebas y la revisión manual del código no los detectan, entonces un atacante puede aprovechar esa pequeña ventana de oportunidad para explotar el fallo.

Ahora, Rust busca evitar que muchas vulnerabilidades lleguen al código en primer lugar: simplemente no compilará si hay errores de sintaxis, u otros errores de seguridad de memoria que causan problemas de producción a lo largo del SDLC. Se trata de una programación a prueba de memoria por diseño, que garantiza que no hay acceso a la memoria no válida (independientemente de cómo se ejecute el software). Y dado que el 70% de los fallos de seguridad son el resultado de problemas relacionados con la gestión de la memoria, esto es una gran hazaña.

El óxido marcará e impedirá:

• Desbordamiento del búfer
• Utilizar después de libre
• Doblemente libre
• Desviación de puntero nulo
• Uso de memoria no inicializada

Si comparamos un fragmento de código de Rust con el de C++, resultará evidente que uno de ellos es seguro por defecto. Mira este ejemplo de un error de desbordamiento de búfer:

#include <iostream></iostream>
#include <string.h></string.h>
int main( void ) {
char a[3] = "12";
char b[4]= "123";
strcpy(a, b); // buffer overflow as len of b is greater than a
std::cout << a << "; " << b << std::endl;
}

Vs.

pub fn main() {
let mut a: [char; 2] = [1, 2];
let b: [char; 3] = [1, 2, 3];
a.copy_from_slice(&b);
}

Rust lanza una advertencia de seguridad, y entra en pánico al llegar a la función copy_from_slice en tiempo de ejecución para evitar el desbordamiento del buffer, pero no en tiempo de compilación.

En este sentido, es uno de los lenguajes que "empiezan por la izquierda". Pondrá de manifiesto los errores y obligará a los desarrolladores a escribir el código de forma correcta para evitar introducir fallos de seguridad relacionados con la memoria, por lo que el cumplimiento de los plazos depende de que el programador preste atención, ponga remedio y se mantenga fiel a la ruta de entrega.

El planteamiento de este lenguaje parece sencillo, pero habría sido una hazaña increíble conseguir que funcionara con esta potente lógica, y lo cumple. Rust es, desde el punto de vista de la seguridad, un paso de gigante... si sólo lo usara más gente. Compañías como Dropbox son pioneras en su uso a gran escala, y eso es genial de ver. Pero, hay más consideraciones antes de llegar a la conclusión de que un problema de adopción es todo lo que nos impide un futuro más seguro.

El ajuste de cuentas de Rust.

Hay un par de pequeños (bueno, grandes) problemas, a saber, que la programación en Rust tiene más flexibilidad para introducir errores de lo que podría parecer. No solucionará las vulnerabilidades del Top 10 de OWASP, que siguen provocando brechas, retrasos y una cultura general de técnicas de codificación inseguras. También hay algo de una dinámica de ángeles y demonios, o, como es más conocido: Rust seguro vs. Rust inseguro.

Como se explica en la documentación oficial, el Rust Seguro es la forma "verdadera" de Rust, y el Rust Inseguro incluye funciones que se consideran "definitivamente no seguras", aunque a veces son necesarias - como si se requiere la integración con algo en otro lenguaje. Sin embargo, incluso con Unsafe Rust, la lista de funcionalidades adicionales sigue siendo limitada. En Rust inseguro, es posible hacer lo siguiente dentro de bloques inseguros:

• Dereferencia de punteros sin procesar
• Llamar a funciones no seguras (incluyendo funciones C, intrínsecas del compilador y el asignador bruto)
• Implementar rasgos inseguros
• Mutar la estática
• Acceder a los campos de las uniones.

Incluso en el llamado modo "inseguro", uno de los superpoderes de la programación de Rust sigue funcionando: el "verificador de préstamos". Por lo general, previene los problemas de memoria, las colisiones en los cálculos paralelos y muchos otros errores a través del análisis estático del código, y este análisis seguirá haciendo comprobaciones en un bloque inseguro, solo que requiere mucho más trabajo para escribir construcciones inseguras sin que el compilador intervenga con una guía en determinadas situaciones.

Esto no parece un gran problema para la mayoría de los desarrolladores experimentados - después de todo, somos conocidos por retocar para obtener lo mejor de nuestras aplicaciones y abrir algunas funciones más geniales - pero potencialmente abre un agujero negro que puede conducir a graves errores de configuración y vulnerabilidades de seguridad: el comportamiento indefinido. La programación en Rust (incluso cuando se utiliza de forma insegura) bloquea las posibilidades de vulnerabilidades bastante bien en comparación con C o C++, pero invocar un comportamiento indefinido puede ser un riesgo.

¿Es el fin de la confianza en la codificación segura dirigida por los desarrolladores?

¿Recuerdas que antes dije que Rust tiene componentes de lenguajes conocidos? Una de las principales vulnerabilidades de seguridad de Rust es que, bueno, tiene componentes de lenguajes conocidos, concretamente C.

Rust sigue siendo un "lenguaje de programación seguro", pero, de nuevo, la introducción de un usuario es donde las cosas pueden despegarse. El desarrollador todavía puede ajustarlo para que se ejecute sin marcar errores (una propuesta atractiva, ya que esto desbloquea más capacidades), y esencialmente, incluso en un estado seguro, los desarrolladores todavía pueden ser tan "inseguros" como quieran, porque tienen una capa de orientación y protección antes de que las cosas puedan ir realmente mal.

Y ambos escenarios anteriores se vuelven más peligrosos a medida que profundizamos, ya que los resultados de Rust son similares a los de las herramientas de escaneo - así como no existe una herramienta SAST/DAST/RAST/IAST del ejército suizo que escanee cada vulnerabilidad, cada vector de ataque y cada problema, Rust tampoco lo hace. Incluso con Rust se pueden introducir algunas vulnerabilidades con bastante facilidad.

El riesgo de comportamiento indefinido cuando se ejecuta Rust inseguro tiene el potencial de abrir problemas de desbordamiento de enteros, mientras que, en general, incluso las configuraciones seguras no evitarán el error humano en las configuraciones erróneas de seguridad, la lógica de negocio o el uso de componentes con vulnerabilidades conocidas. Estos problemas siguen representando una amenaza muy real si se dejan sin parchear, y en un entorno "supuestamente seguro" como el verdadero Rust, puede incluso causar un comportamiento complaciente si un codificador cree que todos los problemas importantes serán recogidos a pesar de todo.

He descubierto que Rust no es muy diferente a un mentor de programación - un ingeniero senior que se ha tomado el tiempo de sentarse con un codificador menos experimentado, revisando su trabajo y mostrándole los posibles errores, señalando las eficiencias y, en algunos casos, asegurándose de que no se compila hasta que esté bien. Sin embargo, es mucho mejor que los programadores de Rust aprendan la teoría y se comprometan con las mejores prácticas por sí mismos, ya que ese mentor podría cortar las cuerdas del delantal, y tú no quieres quedarte colgado.

¿Preparado para encontrar y solucionar vulnerabilidades comunes de Rust ahora mismo? Juega al desafío.

Bueno, esto es todo (por ahora). Hemos llegado al final de nuestra serie de Infraestructura como Código. Esperamos que te hayas divertido conquistando problemas de seguridad en Docker, Ansible, Kubernetes, Terraform y CloudFormation. Sin embargo, antes de despedirnos, tenemos una vulnerabilidad más que dominar: los errores de lógica de negocio.

¿Crees que ya estás preparado para poner a prueba tus habilidades? Prueba el último desafío gamificado:

Si todavía no tienes claras algunas cosas, sigue leyendo:

Las vulnerabilidades en las que queremos centrarnos hoy son los fallos de lógica de negocio. Estos pueden ocurrir cuando los codificadores no implementan adecuadamente las reglas de lógica de negocio que podrían dejar sus aplicaciones vulnerables a diferentes tipos de ataques si un usuario malicioso decide explotarlos. Dependiendo del propósito y la funcionalidad implementada dentro de cada aplicación, un fallo de lógica de negocio puede permitir la escalada de privilegios, el uso inadecuado de recursos o cualquier número de procesos de negocio no deseados.

A diferencia de muchas vulnerabilidades, la implementación incorrecta de reglas de lógica de negocio puede ser sorprendentemente sutil. Requieren una vigilancia especial para garantizar que no se cuelen en las aplicaciones y el código.

¿Cuáles son algunos ejemplos de fallos en la lógica empresarial?

Como ejemplo de lo fácil que puede ser inducir fallos en la lógica de negocio, considere el siguiente ejemplo de un entorno Docker definido con un archivo Docker Compose. Para preparar los contenedores para realizar funciones, un desarrollador podría utilizar una política de recursos estándar, definida en el archivo Docker Compose, como el siguiente ejemplo:

desplegar:
recursos:
límites:
cpus: "0.5"
reservas:
cpus: "0.5"

Aunque a primera vista parece que está bien, esta política de recursos para contenedores no está limitando adecuadamente el uso de recursos. Un atacante podría aprovechar el fallo de la lógica de negocio para implementar un ataque de denegación de servicio (DoS).

Para intentar limitar que los usuarios ocupen demasiados recursos, un desarrollador podría intentar definir mejor lo que puede soportar cada contenedor. Así, el nuevo código podría incluir una restricción de colocación:

desplegar:
recursos:
límites:
cpus: "0.5"
reservas:
cpus: "0.5"
colocación:
restricciones:
- "node.labels.limit_cpu == 100M"
- "node.labels.limit_memory == 0.5"

A primera vista, parece que esto resolvería el fallo de la lógica empresarial. Sin embargo, la nueva restricción de colocación no afecta al límite de uso de recursos para el servicio de contenedores Docker. Sólo se utiliza para seleccionar un nodo para programar el contenedor. En este caso, un ataque DoS sigue siendo posible. El atacante necesitaría comprometer un contenedor Docker primero, pero podría drenar los recursos sin límites después de eso.

Como puede ver, pensar en los fallos de la lógica de negocio y programar para eliminarlos puede ser una tarea complicada.

Eliminación de los fallos de la lógica empresarial

Con los defectos de la lógica de negocio, la clave es saber que existen. Hay que estar atento para mantenerlos fuera del entorno mientras se escribe el nuevo código. Las reglas de negocio y las mejores prácticas deben estar claramente definidas y comprobadas en todas las fases del proceso de desarrollo de la aplicación, incluyendo el diseño, la implementación y las pruebas.

Por ejemplo, para evitar que un fallo de lógica de negocio permita un ataque DoS como el del ejemplo anterior, una buena práctica es limitar la cantidad de recursos que puede utilizar cada contenedor Docker que se cree. Específicamente, la sección de límites debe especificar el número de CPUs y la cantidad de memoria que un contenedor Docker puede utilizar. Un ejemplo sería:

desplegar:
recursos:
límites:
cpus: "0.5"
memoria: 100M
reservas:
cpus: "0.5"
memoria: 50M

El uso de un código como el del ejemplo anterior como política eliminaría un importante fallo de lógica empresarial del entorno y evitaría los ataques DoS. Esto funcionaría incluso si un atacante comprometiera uno de los contenedores Docker. En ese caso, el atacante seguiría sin poder utilizar su punto de apoyo para agotar los recursos.

El modelado de amenazas puede ser útil al definir cómo se producen los diferentes ataques y garantizar que se utilicen reglas de lógica empresarial para prevenirlos y restringirlos. Las pruebas basadas en las reglas de cumplimiento y los casos de abuso conocidos también podrían ser útiles para detectar los fallos de la lógica empresarial que se escapan.

Los fallos en la lógica de negocio son algunas de las vulnerabilidades más sutiles que pueden colarse en las aplicaciones, pero no son menos peligrosas que otros riesgos más destacados. Conocer cómo pueden producirse y utilizar las mejores prácticas puede mantenerlos fuera de su entorno durante el desarrollo de la aplicación, asegurando que nunca lleguen a un entorno de producción donde puedan ser abusados por atacantes que están muy familiarizados con la forma de explotarlos.

Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos de seguridad. También puedes probar una demostración de este desafío de IaC en la plataforma de formación Secure Code Warrior para mantener todos tus conocimientos de ciberseguridad perfeccionados y actualizados.

Nos acercamos al final de nuestra serie Infrastructure as Code, pero ha sido estupendo ayudar a desarrolladores como tú en su viaje de seguridad IaC.

¿Has jugado a los retos? ¿Cuál es tu puntuación hasta ahora? Antes de empezar, veamos cuánto sabes ya sobre los peligros de usar componentes de fuentes no confiables:

¿Todavía tiene trabajo que hacer? Sigue leyendo:

El comportamiento que induce a la vulnerabilidad en el que nos vamos a centrar hoy es el uso de código de fuentes no confiables, una práctica aparentemente benigna que está causando grandes problemas. El uso de código y recursos de código abierto tiene muchas ventajas. En general, permite que los expertos aporten sus ideas, su trabajo e incluso el código completo a repositorios como GitHub para que lo utilicen otras personas que luchan por hacer que un programa o una aplicación se comporten correctamente. El uso de código completo para gobernar las funciones del programa evita que los desarrolladores tengan que reinventar la rueda cada vez que necesitan crear una nueva aplicación.

Sin embargo, utilizar fragmentos de código de fuentes no fiables, no verificadas o incluso potencialmente peligrosas conlleva un gran riesgo. De hecho, el uso de código de fuentes no confiables es una de las formas más comunes en que las vulnerabilidades de seguridad, tanto mayores como menores, se cuelan en aplicaciones que de otro modo serían seguras. A veces, esas vulnerabilidades son inducidas accidentalmente por sus creadores. También ha habido casos en los que el código malicioso fue escrito por atacantes potenciales. El código se comparte entonces con la esperanza de atrapar a las víctimas que lo introducirán en sus aplicaciones.

¿Por qué es peligroso utilizar código de fuentes no fiables?

Supongamos que un desarrollador tiene prisa y necesita configurar una aplicación que está desarrollando. Puede ser un proceso complicado. Así que en lugar de pasar mucho tiempo tratando de resolver todas las configuraciones posibles, hacen una búsqueda en Google y encuentran a alguien que ya ha completado un archivo de configuración aparentemente perfecto. Aunque el desarrollador no sabe nada de la persona que escribió el código, añadirlo a una nueva aplicación es relativamente fácil. Se puede hacer en el entorno Docker utilizando dos líneas:

RUN cd /etc/apache2/sites-available/ && \00 wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\3 fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf

Ahora la imagen de Docker tirará dinámicamente del archivo de configuración de terceros. E incluso si el archivo se prueba y se encuentra bien en el momento, el hecho de que el puntero está ahora incrustado en el código de la nueva aplicación significa que hay una dependencia permanente en el lugar. Días, semanas o meses después, el archivo podría ser alterado por el autor original o por un atacante que haya comprometido el repositorio de código. De repente, el archivo de configuración compartido puede decirle a la aplicación que funcione de forma muy diferente a la prevista, posiblemente dando acceso a usuarios no autorizados o incluso robando directamente los datos y exfiltrándolos.

Una mejor manera de utilizar los recursos compartidos

Si su organización permite el uso de código de fuentes externas, deben establecerse procesos para garantizar que se hace de forma segura. Cuando evalúe el código externo para su posible uso, asegúrese de adquirir componentes de fuentes oficiales sólo mediante enlaces seguros. E incluso en ese caso, nunca debe enlazar con una fuente externa para extraer ese código, ya que eso elimina el proceso de su control. En su lugar, el código aprobado debe ser llevado a una biblioteca segura y sólo utilizado desde esa ubicación protegida. Así que en un entorno Docker, el código se vería así:

COPY src/config/default-ssl.conf /etc/apache2/sites-available/

En lugar de depender de archivos de configuración de terceros remotos, esto se basaría en una copia local de esos archivos. Esto evitará que se realicen cambios inesperados o maliciosos.

Además de utilizar una biblioteca de código seguro, debe establecerse un proceso de gestión de parches para supervisar continuamente los componentes a lo largo del ciclo de vida del software. Todos los componentes del lado del cliente y del servidor también deben ser revisados para detectar alertas de seguridad utilizando herramientas como NVD o CVE. Por último, hay que eliminar las dependencias y funciones no utilizadas o innecesarias que puedan aparecer en el código externo.

Siguiendo estos pasos, los desarrolladores pueden hacer un uso más seguro de los recursos externos sin inducir accidentalmente vulnerabilidades en sus aplicaciones y código.

Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos de seguridad. También puedes probar una demostración de los retos de IaC en la plataforma de formación Secure Code Warrior para mantener todos tus conocimientos de ciberseguridad perfeccionados y actualizados.

Un desarrollador, en su hábitat natural, a menudo se encuentra en un estado de profunda concentración, codificando características impresionantes con plazos ajustados. La creación de funciones suele ser nuestra parte favorita del trabajo y, en realidad, es el resultado fundamental del ciclo de vida del desarrollo de software (SDLC).

Sin embargo, como hemos comentado antes, muchos de nosotros seguimos dando prioridad a las funciones sobre las mejores prácticas de seguridad. Después de todo, en la mayoría de las organizaciones, está configurado para ser el trabajo de otra persona y la formación de seguridad adecuada para nosotros es limitada. Las pruebas de penetración y las herramientas de escaneo de análisis estático (más conocidas como SAST) son sólo una parte del proceso general para mitigar los riesgos de seguridad, operando de forma bastante independiente de lo que hacemos... hasta que el código nos llega de vuelta para las correcciones, por supuesto.

Y es en ese momento cuando muchos desarrolladores piensan:"¿Me odian los pentesters?".

Estas interacciones suelen definir un equipo, una cultura. Lo preocupante es que la falta de comunicación, entendimiento y colaboración en general ha creado tensiones, al menos en el lado del desarrollador. Piénsalo: Imagínate que has pasado unos cientos de horas esculpiendo una estatua maravillosa, y entonces llega alguien con un martillo y empieza a romper trozos de ella después de haberte dicho que sus cimientos no están a la altura. Esa es la dinámica que se percibe entre un probador y un desarrollador: este último ve cómo su software es masacrado por una persona ajena que no ha trabajado en el proceso con él; en cambio, ha ampliado la carga de trabajo y retrasado la satisfacción de enviar el código.

Al haber entrado en el espacio de la seguridad hace tiempo, puedo ver ambos lados de la historia. Y no, los pentesters no odian a los desarrolladores. El pentester está, con toda probabilidad, sobrecargado de trabajo y bajo mucha presión. Por ello, un flujo constante de errores de seguridad comunes que podrían arreglarse fácilmente a nivel de código le quitan tiempo, recursos y espacio para pensar en los problemas realmente serios.

Siempre vi a los pentesters como una especie de padres. Quieren que te vaya bien, y cuando no lo haces... no se enfadan, solo se decepcionan.

Ahora que he puesto esa imagen (quizás un poco injusta) en tu mente, vamos a explorar esto un poco más a fondo. ¿Qué ha provocado esta visión del mundo entre los desarrolladores?

"Por supuesto que me pongo a la defensiva; ¡me están diciendo cómo hacer mi trabajo!"

A nadie le gusta sentir que ha hecho un mal trabajo, o que a alguien no le gusta su trabajo. Desgraciadamente, cuando los desarrolladores reciben los resultados de los análisis estáticos y los pentest, pueden sentirse como si se tratara de un boletín de notas. Les han puesto notas bajas, pero al final del día, sus jefes les evalúan por las características que han construido y el tiempo que han entregado, no por si había elementos vulnerables en el software o no.

Para el pobre pentester, este es un caso de "no disparar al mensajero". No es nada personal: su misión es encontrar bugs, y los han encontrado. Es cierto que, de persona a persona, puede que algunos pentesters sean más gruñones que otros, pero no pretenden (o no deberían) crucificar a los equipos de desarrollo. Sería mucho más fácil para ambos equipos si estuvieran en la misma página con lo que constituye la mejor práctica de seguridad. Y no se espera que los desarrolladores sean perfectos; siendo realistas, el equipo de pruebas está ahí para protegerlos de la entrega de código vulnerable.

"Me han dicho que arregle todos estos problemas menores, ¿no saben que hay prioridades mayores? ¿Y por qué no me ayudan a arreglarlos si les importa tanto?"

Es cierto: la máxima prioridad de un desarrollador siempre será la creación de funcionalidades, y en este loco mundo de rápida digitalización, tendrá que hacerse a toda velocidad. Aunque algunos programadores tienen un interés personal en la seguridad y la codificación segura, el sentimiento general es que la seguridad es "problema de otros", lo que inevitablemente incluye a los pentesters.

La mayoría de las vulnerabilidades comunes son, de hecho, problemas menores para remediar - una vez conocidos, las correcciones son simples de ejecutar para cosas como el cross-site scripting (XSS) y la inyección SQL... el problema es que muchos desarrolladores no se dan cuenta de que los están introduciendo en primer lugar, y estos problemas aparentemente menores son la pequeña ventana de oportunidad que un atacante necesita para causar problemas devastadores para una empresa. Según Akamai, entre noviembre de 2017 y marzo de 2019, las vulnerabilidades de inyección SQL representaron el 65% de todos los vectores de ataque basados en la web. Para una vulnerabilidad que tiene una solución conocida desde hace más de veinte años, es una estadística aleccionadora.

Algunos equipos de pentest ayudan a remediar los fallos de seguridad, pero otros proporcionan un informe con las malas noticias y esperan que los desarrolladores trabajen en las correcciones, incluso si se han trasladado a un proyecto diferente para cuando esto sucede. Y en algunos casos, el equipo de desarrollo puede enfrentarse a un informe que incluya fallos que no pueden (o no se debe esperar que los solucionen); aun así, debe formar parte de las conclusiones y, de nuevo, no debe tomarse como algo personal.

El "término medio" para esto sería que los pentesters, el personal de seguridad y los directores de desarrollo actuaran más bien como mentores para garantizar que el equipo tiene lo que necesita en términos de formación y herramientas eficaces, dando a los codificadores individuales la mejor oportunidad de tener éxito y codificar de forma segura desde el principio del SDLC. Ambos equipos deberían reunirse a mitad de camino para garantizar que la seguridad se tiene en cuenta desde el principio, como parte de una práctica saludable de DevSecOps.

"Tengo muchos más conocimientos de seguridad de los que se me atribuyen; estos informes son en su mayoría falsos positivos, o no son importantes".

El análisis estático es un elemento del proceso de seguridad en el SDLC, y las herramientas de escaneo de análisis estático (SAST) juegan un papel fundamental. Y sí, los falsos positivos son un problema con estos y otros tipos (DAST/IAST/RAST) de escáneres. Es una molestia en lo que ya es un proceso lento, que requiere la revisión manual del código y presiona tanto a los desarrolladores como a los pentesters. El personal de pentesting se ha tomado el tiempo de configurar meticulosamente las reglas personalizadas para evitar lecturas inexactas y ha proporcionado orientación específica para la empresa, sin embargo, algunas lecturas falsas se cuelan y terminan frente a un desarrollador que se rasca la cabeza.

Este proceso no es perfecto, pero el otro problema es que muchos desarrolladores carecen de conocimientos suficientes para mitigar muchas de las vulnerabilidades más comunes de forma constante. Dado que la formación en seguridad es escasa en la educación terciaria y que la formación en el puesto de trabajo varía en cuanto a su eficacia, es lógico que también haya un cierto exceso de confianza (y no es culpa de ellos: nosotros, como industria, tenemos que mejorar para dotarles de lo que necesitan).

"No sabía que esta aplicación iba a ser probada, pero ahora estoy atascado con las tareas de corrección".

A veces, los ingenieros sobrecargados de trabajo asumen que los pentesters están esperando el momento de probar una aplicación y arruinar el desfile del equipo de desarrollo. Están probando en exceso, son puntillosos, están creando trabajo extra.

El único problema es que ellos también están sobrecargados de trabajo (más aún, de hecho, la escasez de habilidades de ciberseguridad está en niveles terribles y empeorando) y simplemente no tienen tiempo para hacer pruebas sin razón. No son los únicos que toman la decisión de dar prioridad a las pruebas; pueden haber sido solicitadas por la alta dirección, un cliente, como parte de una auditoría de seguridad o incluso determinadas como resultado de un programa de recompensas por errores.

Para un desarrollador, ser retirado de los sprints de creación de características actuales para trabajar en correcciones de seguridad es molesto, especialmente si no es su trabajo. Tal vez un equipo anterior hizo la última actualización, u otro proveedor. Sin embargo, la seguridad es un problema de todos. Eso no significa que todos los desarrolladores tengan que apropiarse de los errores de seguridad como si los hubieran hecho ellos mismos, pero sí tienen que participar en la fiesta en términos de que la seguridad es una responsabilidad compartida.

¿A dónde vamos a partir de aquí?

A veces, un cambio de mentalidad puede ser todo lo que se necesita para avanzar significativamente en la solución de un problema. Ya hemos hablado de la reacción más bien fría que tiene un desarrollador ante los resultados menos favorables de un pentest, pero ¿qué pasaría si pudiera convertirlo en un reto? Tal vez podrían pensar en el pentester como un competidor amistoso; alguien a quien pueden vencer en su propio juego. Después de todo, un desarrollador consciente de la seguridad que puede eliminar los errores comunes mientras escribe el código va a hacer su trabajo mucho más difícil. Por el contrario, un desarrollador que no se centra en la seguridad va a ser ampliamente superado por sus homólogos pentester cuando puedan romper fácilmente su software.

Puede que los pentesters y los desarrolladores no estén unidos en armonía el 100% de las veces, pero su relación puede mejorar enormemente cuando una organización aborda la seguridad como una prioridad clave, y empodera a los equipos con los conocimientos y las herramientas adecuadas para tener éxito, especialmente a los desarrolladores. Todo se reduce a si una cultura de seguridad positiva en toda la empresa es una prioridad, y si vamos a luchar la batalla (actualmente) perdida contra las vulnerabilidades comunes, absolutamente debería serlo.

Una versión de este artículo apareció en TFIR.Se ha actualizado y sindicado aquí.

Dicen que el cambio es la única constante en la vida, pero el año 2020 ha supuesto una verdadera prueba para muchos en todo el mundo. La pandemia mundial de COVID-19 nos ha obligado a reflexionar -a un nivel profundo- sobre cómo nos conectamos. El autoaislamiento, el distanciamiento social... estas han sido algunas de las adaptaciones que hemos hecho en el mundo físico, y a pesar de que muchos de nosotros pasamos mucho tiempo en línea, es un escenario bastante diferente no tener otra opción a la hora de comunicarnos y, si es posible, trabajar. Es a la vez una tragedia y un despertar.

Al igual que muchas empresas tecnológicas, el trabajo flexible no es nuevo para nosotros y trabajar desde casa es una de las ventajas del trabajo. Ya en 2009 trabajé a distancia desde Bélgica para empresas de Silicon Valley. La tecnología estaba mucho menos avanzada entonces, pero todavía era posible. Sin embargo, incluso para nosotros ahora, fue un ajuste tener a todos los miembros del equipo trabajando desde casa hasta nuevo aviso. He visto a muchas empresas tomar también esta decisión, incluso a muchas que no estaban tan preparadas como otras para gestionar una plantilla remota.

Ya sea que la incomodidad provenga de las incógnitas de una nueva forma de trabajo, de un poco de desconfianza o tal vez de no "creer" en el trabajo remoto, encuentro que las empresas que se resisten a él tienden a quedarse atrás en términos de atraer a los mejores talentos, mantener el alcance global y, francamente, moverse con los tiempos. Esta crisis actual ha dejado a muchos sin otra opción que encender una fuerza de trabajo remota, ya que la alternativa es un cierre completo de los negocios en medio de un clima económico caótico.

Si hay algo positivo que podemos sacar de esta tragedia, es que la gente habrá visto el beneficio de una fuerza de trabajo digital, y la miríada de formas en que un equipo puede conectarse a pesar de no estar físicamente juntos. Y el sector de la ciberseguridad es uno de los que realmente puede prosperar con un enfoque de trabajo en cualquier lugar y siempre conectado.

Los atacantes no se encerraron, sino que están muy activos y se aprovechan de esta crisis, aprovechando el pánico y la incertidumbre mundial para llevar a cabo ciberataques contra instalaciones médicas. En una situación como la actual, no es descabellado ver un aumento de los ciberataques, especialmente del ransomware. Al fin y al cabo, se está robando para sobrevivir en tiempos de precariedad económica. Esto no hace que esté bien, y el hecho es que podemos seguir trabajando, formándonos y luchando contra los ciberataques en cualquier lugar donde haya una conexión a Internet.

El futuro es flexible, y así es como nosotros -y la industria de la ciberseguridad en su conjunto- podemos hacerlo funcionar ahora y en el futuro:

Los productos "Access-anywhere" son universales y valiosos

Antes de cualquier tipo de situación de cuarentena forzosa, los equipos globales aún tenían que encontrar una forma de colaborar cuando era necesario. Las teleconferencias asequibles debutaron el mismo año que los Rolling Stones (1964), y no cabe duda de que aquellos primeros usuarios tenían los mismos problemas de "¿estás ahí? "no, sigue tú" que hoy en día, aunque podamos vernos en vídeo).

En 2020, la tecnología de las comunicaciones digitales es una parte enorme del sector de las TIC, que mueve miles de millones de dólares, con plataformas nativas en la nube, móviles y sociales que dominan y sustituyen a la tecnología heredada. Innovaciones como Slack, Zoom y Discord nos mantienen más conectados que nunca, especialmente en el trabajo. Y la comunicación es solo un aspecto de la historia.

Los servicios digitales accesibles en cualquier lugar con una conexión a Internet, a la carta, que satisfacen una necesidad básica -ya sea una conexión, un entretenimiento, una productividad- forman parte de nuestro futuro flexible. Como clientes, buscamos la hiperpersonalización y, como empresa, buscamos ofrecer una experiencia digital personal con la misma calidad sin concesiones, independientemente del lugar desde el que se acceda.

En todos los sectores, todos los días, se crean aplicaciones basadas en la web para agilizar los procesos, revolucionar las formas de vida y de trabajo existentes y resolver problemas que quizá no nos habíamos dado cuenta de que teníamos. No estamos ni mucho menos en la cúspide de las herramientas de ciberseguridad y de la formación a la que se puede acceder bajo demanda, de forma atractiva y útil para el usuario, con un beneficio tangible para la empresa.

Los desarrolladores aprecian la flexibilidad en su trabajo diario, y nuestro enfoque en la formación práctica y divertida de codificación segura, así como la integración del flujo de trabajo, se ha elaborado teniendo en cuenta a estos usuarios finales. Las herramientas deben ser fáciles de usar para que no supongan un esfuerzo, y la formación valiosa no se vea como una tarea. Con un campo de juego tan amplio en el sector de la ciberseguridad, ha llegado el momento de innovar en múltiples áreas de ataque y defensa, en las que las metodologías que dan prioridad a la seguridad, como DevSecOps, pueden seguir prosperando aunque todo el mundo esté en casa. Se trata de la colaboración y de un conjunto considerado de herramientas para que cada miembro del equipo haga su trabajo con eficacia, independientemente de su ubicación física.

Entrenamiento cuando más lo necesitas (o cuando quieres cambiar de día)

Una de las ventajas del trabajo flexible es que los desplazamientos a la oficina se eliminan los días en que se realizan tareas desde casa. Para algunos, eso podría suponer unas dos horas de tiempo de calidad y concentrado que se recuperan. En un mundo ideal, todo el personal tendría tiempo en su horario de trabajo normal para aprender y desarrollar sus habilidades, y esto puede ser mucho más fácil en el entorno remoto adecuado. Es beneficioso para sus superestrellas remotas, que pueden sentirse desafiadas y apoyadas por un mayor aprendizaje.

Con un panorama de ciberseguridad que cambia a cada segundo, la formación frecuente es una necesidad para mantenerse al día con las posibles amenazas que podrían afectar a la organización. Y una formación completa y medible que se adapte a las necesidades de la empresa es un gran paso en la dirección correcta. Estos fueron algunos de los factores fundamentales en el diseño de la plataforma Secure Code Warrior ; queríamos una formación a la que se pudiera acceder en cualquier lugar, justo cuando se necesitara, en el lenguaje de desarrollo y el marco de trabajo que eligiera el usuario.

Los desarrolladores tienen una relación tensa con la seguridad y, en muchos sentidos, no se les ha atendido de manera suficientemente específica para que se comprometan adecuadamente con las mejores prácticas de seguridad. La formación bajo demanda y gamificada puede ayudar a ganárselos, independientemente de dónde se encuentren; esto también es imprescindible para garantizar que los equipos y los proveedores deslocalizados muestren también una conciencia de seguridad adecuada, especialmente cuando participan en cualquier tipo de manipulación del software de una organización.

Mantener a su cohorte comprometida y capacitada con una formación que ayudará a la organización (por no hablar de su propia carrera) es un pegamento muy eficaz cuando se trata de retener a sus mejores y más leales talentos... una necesidad absoluta ya que nos enfrentamos a una escasez continua de habilidades de ciberseguridad.

Los trabajadores a distancia pueden estar capacitados, ser productivos y estar seguros

La idea de que para ser productivo hay que estar visible en una oficina de nueve a cinco es una postura bastante anticuada. Y, sin embargo, muchas empresas (incluso algunas de las nuevas y emocionantes) siguen operando con esta noción en mente. Hay un profundo sentimiento de desconfianza en su propia plantilla, como si la mera sugerencia de trabajar desde casa les hiciera imaginarse a sus equipos jugando en ropa interior en lugar de haciendo su trabajo.

O eso o simplemente no han dado el paso de trabajar a distancia de forma viable.

Naturalmente, los miembros del equipo tienen que demostrar que pueden mantener la productividad en casa mostrando el rendimiento, sin embargo, usted tiene que dar a su cohorte la mejor oportunidad de tener éxito fuera de la oficina. Pregúntese:

• ¿Disponen de un hardware adecuado?
• ¿Has puesto en práctica alguna de esas increíbles herramientas de comunicación de las que hemos hablado antes?
• ¿Te has asegurado de que todos los directores se registren y estén presentes digitalmente con su equipo, con reuniones periódicas?
• ¿Ha pensado en herramientas de productividad para hacer un seguimiento de los proyectos y ayudar a dar a cada miembro del equipo dirección, fijación de objetivos y una sensación de logro a medida que completan las tareas?

En el clima actual, muchas empresas se enfrentaron a la decisión de pasar a trabajar a distancia o cerrar por completo. Es posible que algunas empresas que optaron por pasar a una plantilla remota no estuvieran tan preparadas, y es posible que haya que limar algunas asperezas... pero el problema es que estas empresas probablemente también se están exponiendo a algunos riesgos de seguridad.

Evitar los errores de seguridad en los entornos de trabajo a distancia

Hay que tener en cuenta varios vectores de amenaza, ya que es probable que el personal esté en su propia red, y puede estar utilizando una serie de dispositivos para acceder a las cuentas de la empresa, cada uno con sus propias necesidades de seguridad que pueden o no estar en vigor.

En situaciones de trabajo remoto, todo el mundo tiende a recibir un aumento del correo electrónico, además de tener que resolver varios inicios de sesión, sistemas y configuraciones. Es demasiado fácil que los ataques de ingeniería social y el malware se cuelen en un montón de dispositivos fuera del alcance de la seguridad interna. Esto no es una razón para abandonar el trabajo remoto, es una oportunidad de oro para aprender sobre la marcha y hacerlo lo más robusto posible para el futuro. Y en las organizaciones centradas en la seguridad, bueno, es una buena oportunidad para auditar los procesos y "comerse su propia comida de perro" en lo que respecta a las mejores prácticas de seguridad para todos.

Hablando de meteduras de pata, también es importante evaluar tu espacio de trabajo a distancia en busca de posibles amenazas... sobre todo para tu orgullo, como esta pobre pareja. Moraleja: asegúrate de que todo el mundo lleva pantalones si estás en una videollamada.

Los ciberataques no se detienen sólo porque estemos en crisis

Es profundamente perturbador ver los efectos del COVID-19 en todo el mundo, y ahora más que nunca es el momento de unirse y considerar a otras personas en esta crisis sanitaria mundial. La cuestión es que los atacantes se están aprovechando activamente de este miedo y pandemónium generalizados, quizás por la desesperación de poner comida en la mesa. Nosotros, como sociedad, somos increíblemente vulnerables en este momento.

Las instituciones sanitarias, incluido un centro de pruebas de vacunas, han sido golpeadas con ransomware y ataques DDoS, por no hablar de los que intentan aprovecharse de organizaciones financieras y gubernamentales distraídas y con exceso de trabajo lanzando campañas de phishing y malware contra ellas. Otra amenaza inminente rodea a la propia vacuna; se ha informado de que la administración Trump había ofrecido a una empresa alemana grandes sumas de dinero para desarrollar una vacuna COVID-19 para uso exclusivo de Estados Unidos. Los datos de la vacuna son posiblemente la información más valiosa de la Tierra en la actualidad, lo que supondría una recompensa muy atractiva para un atacante.

Esto es un recordatorio demasiado oportuno de que mientras nos autoaislamos de la amenaza muy real de un virus físico, nuestro latido digital también está bajo ataque. La concienciación en materia de seguridad es de suma importancia en todas las organizaciones, y debe impartirse una formación adecuada a todos los niveles; incluso son útiles medidas como imponer el uso de herramientas de gestión de contraseñas y aprender a detectar un correo electrónico de phishing.

Y cuando se trata de desarrolladores, ellos son la primera línea de defensa para asegurar el código producido activamente dentro de la empresa, y pueden ser un activo valioso con su equipo de AppSec para evitar más dolor de un ciberataque cerrando las puertas traseras creadas por las vulnerabilidades comunes.

Las empresas que innovan digitalmente pueden capear las grandes tormentas

Un subproducto muy desafortunado del cierre masivo ha sido la recesión económica, que ha obligado a muchas personas a dejar de trabajar en los sectores más afectados. Todo esto se ha agravado de forma bastante repentina, y es una experiencia que muchos de nosotros probablemente no hemos vivido en nuestra vida.

Aunque no todos los negocios nativos digitales son automáticamente capaces de superar la recesión (ni mucho menos), por su naturaleza, las empresas que se dedican a lo digital son mucho más ágiles, adaptables y sostenibles cuando se dan las circunstancias más inesperadas.

Nuestra empresa puede funcionar de manera eficiente y eficaz con una fuerza de trabajo remota, y esto es una capa adicional de protección para nuestro valioso equipo y los clientes a los que apoyan también. Consideramos que la formación en código seguro y viable es una parte esencial de las empresas modernas, y si nos eligen, podemos cumplir y pivotar según sea necesario. Muchas empresas, por la naturaleza de los productos o servicios que venden, no pueden permitirse el mismo lujo, pero puede ser una sorpresa positiva para ellas investigar dónde se pueden digitalizar los procesos, prepararlos para el futuro y hacerlos tan a la carta como sea posible incluso en los espacios más tradicionales.

Encontrar nuevas formas de conectar es un reto positivo, no un obstáculo

Es un poco dramático, pero me recuerda a la famosa cita de Parque Jurásico en la que el Dr. Ian Malcolm dice: "la vida encuentra un camino". Realmente lo hace, y eso ha sido muy evidente en el cambio de toda nuestra empresa al trabajo a distancia. Equipos que antes no interactuaban mucho están descubriendo intereses comunes en charlas en el refrigerador, juegos de oficina en línea y una lista de reproducción global de Spotify en la oficina. Siempre hay una forma de forjar una relación significativa, y mi consejo es dejar que los equipos exploren y crezcan con ella de forma orgánica.

Para nuestros clientes, ha sido increíble ver que su compromiso con el perfeccionamiento de las habilidades de codificación segura entre los desarrolladores ha trascendido cualquier contratiempo del trabajo remoto. Han utilizado nuestra función tournaments y, aunque normalmente se realizan en persona con un poco de fanfarria, sus versiones virtuales han impulsado un compromiso saludable, una competencia amistosa y una excelente distracción (productiva) de las actividades cotidianas que normalmente se realizan en solitario. Al igual que los videojuegos son ahora un acontecimiento mucho más social que antes, este tipo de formación en el puesto de trabajo impulsa la conexión no sólo con el material del curso, sino con los demás. Y está disponible para cualquiera, en cualquier lugar. Como friki de la seguridad, no puedo dejar de ser parcial, pero este es un momento tan bueno como cualquier otro para ayudar a fomentar el amor por la codificación segura entre los desarrolladores. Todos ellos son superhéroes de la seguridad en espera, y es el momento de reforzar sus líneas de frente de la manera más divertida posible.

Una versión de este artículo apareció en DevOps.com. Se ha actualizado para su sindicación aquí, e incluye enlaces interactivos a los retos de vulnerabilidad.

Creo que todos podemos recordar alguna vez, en una reunión o conferencia, en la que alguien haya tenido problemas con la tecnología de las presentaciones. Ocurre tan a menudo que casi se espera una experiencia torpe, al menos al principio. No es de extrañar, por tanto, que la aplicación de ClickShare haya sido inmediatamente popular entre los usuarios finales. Para ellos, no hay nada más fácil que utilizar una aplicación de ClickShare para trasladar una presentación desde su portátil, tableta o smartphone a una pantalla grande o a un proyector de sala de conferencias. El proveedor de tecnología de imagen y proyección digital Barco, con sede en Bélgica, diseñó su plataforma de automatización para que funcionara así, y las grandes empresas adoptaron el concepto. FutureSource Consulting sitúa la cuota de mercado de Barco en tecnología de conferencias en un 29%, con integración en el 40% de las empresas de la lista Fortune 1.000.

Cuando los investigadores de F-Secure revelaron en diciembre que la aparentemente inocua plataforma de automatización estaba plagada de vulnerabilidades de seguridad, se produjo una gran conmoción en la comunidad empresarial. Los fallos de seguridad descubiertos son de naturaleza crítica, y podrían permitir cualquier número de actividades maliciosas.

Los investigadores demostraron cómo las vulnerabilidades podían permitir a los usuarios remotos fisgonear presentaciones activas, crear puertas traseras en redes seguras o incluso configurar un servidor de distribución de software espía que infectara a todos los usuarios que se conectaran a un dispositivo Barco. De repente, las empresas se enfrentaron a la perspectiva de tener graves problemas de seguridad instalados directamente en las salas de conferencias y oficinas de toda su organización. Y debido a la naturaleza de las vulnerabilidades, un solo dispositivo comprometido podría soportar una brecha en toda la red.

"Un atacante que logre comprometer una unidad obtiene la capacidad de descifrar, así como de producir imágenes cifradas válidas para cualquier unidad, ya sea dentro de una familia o entre familias", escribieron los responsables de F-Secure en su informe. "Además, dicho atacante puede obtener acceso a los datos sensibles en reposo, como el PSK y los certificados configurados del Wi-Fi".

Hay que reconocer que Barco ha sido muy proactivo en la emisión de parches y correcciones de las vulnerabilidades encontradas en sus productos. El proveedor de seguridad Tenable ha publicado recientemente un informe que muestra 15 vulnerabilidades en ocho herramientas de presentación, incluida Barco. Hasta febrero, sólo Barco ha sido activo en el despliegue de correcciones.

Aunque algunas de las vulnerabilidades de Barco requieren cambios en el hardware (y éstos serán una pesadilla para desplegar, si es que una empresa actúa hasta este punto para asegurarlas), muchas de ellas pueden corregirse con parches de software. Esto da a la mayoría de los usuarios de la empresa un plan aparentemente bueno para arreglar sus problemas inmediatos, pero difícilmente están en el claro ahora. Los problemas con Barco son sólo la punta del iceberg cuando se trata de lidiar con las vulnerabilidades de productos de hardware y software bien conocidos.

La raíz del problema

Ahora que los problemas inmediatos se han resuelto, tenemos que preguntarnos cómo los dispositivos con graves fallos de seguridad acabaron en miles de salas de conferencias de todo el mundo, o por qué estaban tan mal diseñados y programados en primer lugar. No es que el equipo de F-Secure estuviera descubriendo vulnerabilidades de día cero o desconocidas hasta entonces. Diez de los fallos descubiertos en los productos de Barco estaban asociados a vulnerabilidades conocidas y comunes, como los ataques de inyección de código. La mayoría ya tenían identificaciones de Vulnerabilidades y Exposiciones Comunes (CVE).

Entonces, ¿cómo se codificaron los CVEs de hace décadas, o incluso se incorporaron a las herramientas de presentación modernas? La única respuesta posible es que los desarrolladores no los conocían o que la seguridad no era una prioridad cuando se diseñaban los dispositivos de Barco. Lamentablemente, esta es una situación común, y ciertamente no es exclusiva de los equipos de Barco.

El mejor momento para solucionar una vulnerabilidad es mientras se desarrolla una aplicación, mucho antes de que se envíe a los usuarios. El peor momento (y el más caro) es después de que un producto se haya desplegado, o después de que haya sido explotado por los atacantes. Esta puede ser una dura lección, que seguramente aprenderá Barco cuando su cuota de mercado, antes impenetrable, se vea afectada tras este fiasco de seguridad.

Reorientar las soluciones de seguridad hacia el proceso de desarrollo no es fácil, pero es necesario en el mundo actual, en el que incluso los dispositivos aparentemente sencillos, como las herramientas de presentación, son sorprendentemente complejos y están conectados en red con todo lo demás. En este entorno, la seguridad debe convertirse en una buena práctica organizativa. No importa si una empresa está programando aplicaciones para las redes sociales o fabricando tostadoras inteligentes, la seguridad debe tenerse en cuenta en todas las facetas de una organización.

Dar prioridad a las mejores prácticas de seguridad y convertirlas en una responsabilidad compartida es el objetivo del movimiento DevSecOps, en el que los equipos de desarrollo, seguridad y operaciones trabajan juntos para codificar y desplegar software y productos seguros. Esto requiere un cambio de cultura como cualquier otra cosa. La nueva mentalidad debe ser que desplegar un producto que funcione con vulnerabilidades de seguridad es un fracaso tan grande como crear uno que no pueda realizar su función principal.

En un entorno DevSecOps saludable, cualquier persona que toque el software debe ser consciente de la seguridad, y los desarrolladores deben recibir formación relevante y frecuente para evitar introducir errores desastrosos en su trabajo. Si los equipos que trabajan para Barco hubieran considerado la seguridad como una responsabilidad compartida, es imposible que una colección tan grande de vulnerabilidades, incluyendo CVEs de hace décadas, hubiera llegado a sus herramientas de presentación.

El camino seguro hacia adelante

Nadie quiere ser el próximo Barco, teniendo que explicar por qué fallos de seguridad bien conocidos se desplegaron a través de sus dispositivos a miles de redes empresariales en todo el mundo. Para evitar ese destino, las empresas que desarrollan software o hardware inteligente deben priorizar inmediatamente la seguridad como una responsabilidad compartida y una mejor práctica organizativa. Crear un programa DevSecOps saludable llevará tiempo y probablemente también requiera un cambio de cultura, pero los resultados merecerán la pena. Un DevSecOps robusto puede aplastar las vulnerabilidades mucho antes de que causen problemas.

A las empresas que compran productos y software les conviene apoyar a las empresas que han adoptado DevSecOps. De este modo, se asegurarán de que los dispositivos y el software que adquieran no sean bombas de relojería a la espera de ser explotados por atacantes cada vez más hábiles.

Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre DevSecOps, y cómo proteger a su organización y a sus clientes de los estragos de los fallos de seguridad y las vulnerabilidades.

¿Quieres conocer a fondo los fallos de seguridad que ha sufrido Barco?

Juega a estos desafíos gamificados en:

• Inyección de comandos del SO en C
• Inyección remota de código en C
• Desbordamiento del búfer en C
• Carga remota de archivos en C
• Credenciales almacenadas en texto plano en C.

Las amenazas a la ciberseguridad hoy en día son omnipresentes e implacables. Se ha vuelto tan grave que tratar de seguirles el paso después de desplegar los programas se ha vuelto casi imposible. En su lugar, las organizaciones astutas están adoptando el concepto de infraestructura como código, por el que los desarrolladores contribuyen a la elaboración de aplicaciones seguras mientras aún se están creando. Esta serie trata de prepararle para la seguridad, para que pueda entender los pasos que puede dar como desarrollador para empezar a desplegar una infraestructura segura como código en su propia organización.

Las desconfiguraciones de seguridad, especialmente las de la variedad de permisos inadecuados, ocurren con mayor frecuencia cuando un desarrollador crea un nuevo usuario o concede permiso a una aplicación como herramienta para realizar una tarea. Por ejemplo, esto podría hacerse para recoger información de una base de datos. Pero si los permisos para el nuevo usuario son demasiado altos, o no están configurados por defecto para la tarea en cuestión, puede introducir una grave vulnerabilidad en el código.

Antes de entrar en materia, ¿por qué no poner a prueba tus habilidades ahora mismo? Intenta encontrar y arreglar algunas vulnerabilidades de permisos inadecuados:

¿Cómo le fue? Profundicemos un poco más:

Dar a un usuario o a una aplicación todos los permisos, o simplemente no molestarse en definir lo que el nuevo usuario debe poder realizar y qué comportamientos están restringidos, es sin duda la forma más rápida de poner en marcha el nuevo código. Y si todo va perfectamente bien, la aplicación hará uso de esos permisos para llevar a cabo su tarea asignada. El peligro es que un hacker descubra este proceso y luego comprometa a ese usuario. Aunque el usuario fue creado para cumplir una función específica para una aplicación concreta, si se ve comprometido puede permitir a un atacante poner en peligro otras aplicaciones, datos o incluso la red.

¿Cómo se aprovechan los fallos de seguridad?

Para visualizar el peligro, echemos un vistazo a cómo se codifica a veces una tarea común dentro del entorno de la nube de Docker. Digamos que un desarrollador está utilizando el servicio Prometheus MySQL Exporter para recoger información de una base de datos. La forma más fácil de permitir que eso ocurra es conceder al exportador permiso para acceder a la base de datos. Así que el código podría ser algo como

FROM mysql:latest
COPY ./scripts/create_users.sh /docker-entrypoint-initdb.d/
USER 999
CREATE USER exporter@% IDENTIFIED BY $EXPORTER_PASSWORD;
GRANT ALL ON *.* TO exporter@%;
GRANT SELECT ON performance_schema.* TO exporter@%;

Esto ciertamente haría que el exportador pudiera cumplir con su tarea. Sin embargo, como los permisos no están definidos, el exportador tiene realmente la capacidad de hacer casi cualquier cosa. Obviamente, el propio exportador nunca actuaría fuera de sus comportamientos programados. Pero, ¿qué pasaría si un atacante fuera capaz de comprometer el servicio del exportador? En ese caso, como se le han dado todos los permisos, el atacante podría realizar todo tipo de tareas no autorizadas con el servicio SQL.

Asegurar y eliminar los permisos indebidos

También en este caso, recurrimos al concepto de infraestructura como código. Si se codifica la seguridad en las aplicaciones a medida que se crean, la red siempre estará en una posición mucho mejor en lo que respecta a la ciberseguridad.

En el ejemplo de Docker de arriba, si un desarrollador quiere que el Prometheus MySQL Exporter sea capaz de consultar una base de datos, puede hacer que eso ocurra de forma más segura definiendo lo que se le debe permitir realizar. Un buen ejemplo de esto sería:

FROM mysql:latest
COPY ./scripts/create_users.sh /docker-entrypoint-initdb.d/
USER 999
CREATE USER exporter@% IDENTIFIED BY $EXPORTER_PASSWORD;
GRANT PROCESS, REPLICATION CLIENT ON *.* TO exporter@%;
GRANT SELECT ON performance_schema.* TO exporter@%;

En este caso, el usuario de MySQL configurado para el servicio Prometheus MySQL Exporter sólo tiene permisos restringidos sobre el servicio MySQL. En concreto, sólo se permiten los privilegios de PROCESS y REPLICATION CLIENT. Esto evitaría que un usuario malicioso se aprovechara de un servicio Prometheus MySQL Exporter comprometido.

La restricción de los permisos a nivel de código puede garantizar que los usuarios y las aplicaciones sólo tengan los permisos necesarios para la tarea en cuestión. Y eso puede contribuir en gran medida a asegurar sus redes y a adoptar el concepto de infraestructura como código.

Consulte las páginas del Secure Code Warrior para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos de seguridad. También puede probar nuestro escaparate de la plataforma de formación Secure Code Warrior para mantener todos sus conocimientos de ciberseguridad perfeccionados y actualizados.

Si usted es un desarrollador que busca aprender más sobre los pasos que puede tomar para comenzar a desplegar una infraestructura segura como código (IaC) en su organización, entonces ha llegado al lugar correcto. Este es el siguiente capítulo de nuestra serie de IaC, diseñada para que te pongas al día en las mejores prácticas de seguridad de IaC.

Antes de empezar, ¿cómo te fue con el desafío de la última entrega? Si dominas la criptografía insegura, veamos cómo te va con la protección insuficiente de la capa de transporte antes de entrar en detalles:

¿Quieres saber más y conseguir una puntuación perfecta? Sigue leyendo:

En nuestro último artículo, hablamos de la importancia de tener una criptografía segura para proteger cualquier dato importante o personal almacenado por aplicaciones y programas. Si tienes una encriptación fuerte, actúa como una perfecta última línea de defensa. Incluso si un atacante es capaz de robar esos datos, si están fuertemente encriptados, entonces la información encerrada dentro de esos archivos sigue estando protegida.

Sin embargo, la protección de los datos en reposo es sólo una parte de una defensa completa de los datos. Siempre que los usuarios válidos necesiten acceder a los datos protegidos, hay que enviárselos. A veces, las aplicaciones también compartirán datos con otros programas como parte de una carga de trabajo general. A menos que la capa de transporte esté protegida, la hace vulnerable tanto al fisgoneo externo como a la visualización interna no autorizada. Por lo tanto, tener una protección insuficiente de la capa de transporte puede causar graves problemas.

Es un problema común. La organización de seguridad OWASP incluso mantiene una página completa sobre la insuficiente protección de la capa de transporte.

¿Por qué es peligrosa una protección insuficiente de la capa de transporte?

Si no proteges suficientemente tus capas de transporte, es relativamente fácil para los hackers expertos interceptar la información que fluye entre tus usuarios y tus aplicaciones utilizando técnicas como los ataques man-in-the-middle. Probablemente el aspecto más peligroso de este tipo de fisgoneo es que es casi completamente invisible para cualquier plataforma o escáner de ciberseguridad interno porque ocurre fuera de su red y de su control.

Por ejemplo, en un entorno Docker desplegando un servicio Nginx:

services:
nginx:
image: localhost:5000/scw_nginx
build: ./nginx
secrets:
- nginx_cert
- nginx_key
volumes:
- type: bind
source: ./nginx/nginx.conf
target: /etc/nginx/nginx.conf
read_only: yes
ports:
- 80:8443
networks:
- frontend
deploy:
restart_policy: *default-restart_policy
resources: *default-resources_policy

La configuración del servicio Nginx no cifrará ni protegerá la conexión, lo que hará que toda la información intercambiada a través del enlace sea vulnerable a diversos ataques o al espionaje.

server {
       server_name scw-dev-blog.org;
       listen 8443;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

A menudo, la primera señal de que alguien podría estar fisgoneando a través de sus capas de transporte es cuando se utiliza un gran número de contraseñas de usuario robadas en ataques posteriores. Si otros datos, como la información de los clientes, los registros financieros o los secretos importantes de la empresa, son robados a través de una capa de transporte insegura, es posible que nunca se dé cuenta de que ha sido comprometida.

Y no es sólo la capa de transporte entre usuarios y aplicaciones la que requiere protección. En el backend, muchas aplicaciones se comunican entre sí y con servidores más avanzados en la cadena del flujo de trabajo. Aunque estas comunicaciones internas no suelen ser vulnerables al espionaje externo, pueden exponer los datos a usuarios que pueden tener permiso para entrar en la red pero no están autorizados a ver cierta información altamente protegida o sensible.

Asegurar adecuadamente las capas de transporte para una protección total de los datos

La protección de las capas de transporte se realiza mejor mientras se crean las aplicaciones. Este proceso empieza por tener una infraestructura backend segura. En el caso de los sitios web, todo debe hacerse utilizando HTTPS. Nunca mezcles la infraestructura HTTP y HTTPS. Incluso deberías configurar tus sitios para que dirijan automáticamente las peticiones HTTP no seguras a la infraestructura HTTPS.

En el ejemplo anterior, un método adecuado para proteger la capa de transporte sería:

server {
       server_name scw-dev-blog.org;
       listen 8443 ssl;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

En ese ejemplo, todas las conexiones con el servicio Nginx están fuertemente encriptadas. La sección del servidor de la configuración de Nginx solo incluye listen 8443 ssl para forzar que SSL proteja las conexiones.

Para proteger sus datos de las amenazas internas, los desarrolladores deben emplear un protocolo de cifrado de capa de transporte fuerte como TLS 1.2. Una vez que se haya implantado TLS 1.2 o su equivalente, los protocolos más débiles como SSL v2 deberían eliminarse por completo de la infraestructura y prohibirse automáticamente su uso.

Y tenga siempre en cuenta que la seguridad de una aplicación no es completa hasta que tanto los datos en reposo como las capas de transporte están suficientemente protegidos. De este modo, podrá garantizar una protección completa de extremo a extremo para los datos, tanto a nivel interno como cuando fluyan hacia usuarios externos autorizados.
Consulte las páginas del Secure Code Warrior para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos de seguridad. También puede probar una demostración de la plataforma de formación Secure Code Warrior para mantener todos sus conocimientos de ciberseguridad perfeccionados y actualizados.