Perspectivas sobre el código seguro

No es ningún secreto que nuestra misión principal es hacer que el software y su desarrollo sean seguros; diseñados teniendo en cuenta la seguridad desde el principio de la producción. Nuestra visión establece un nuevo punto de referencia para la creación de software, en el que los desarrolladores cuentan con las habilidades y los conocimientos necesarios para detectar código vulnerable durante el proceso de escritura y corríjalo incluso antes de que se convierta en un problema.

Por lo tanto, teniendo esto en cuenta, puede pensar que estamos encantados de enterarnos de las nuevas violaciones de datos, ciberataques y códigos explotados que afectan a empresas de todo el mundo; esos incidentes sin duda destacan la necesidad de nuestro servicio en varios mercados verticales. La verdad es que es bastante frustrante. Está claro que, como industria, cometemos los mismos errores una y otra vez, porque la mayor parte de la educación sobre seguridad simplemente no es lo suficientemente sólida como para minimizar el riesgo y detener estas infracciones.

La última víctima de violación de datos es Ticketmaster. Si estuvieras entre los miles de clientes afectados, habrías recibido un correo electrónico notificándote el incidente y cambiándote la contraseña. Nadie espera que se violen sus datos personales simplemente por comprar entradas para un concierto o un evento deportivo, pero aquí estamos.

Es una situación terrible para todos, perjudicial para la reputación de Ticketmaster y para una pésima experiencia de cliente. Sin embargo, hay un problema: no fue del todo culpa de ellos.

Verá, la empresa utilizó los servicios de una aplicación de atención al cliente de terceros de Inbenta Technologies. Ticketmaster UK descubrió que el producto contenía código malicioso, lo que ponía en peligro el cinco por ciento de los datos de sus clientes de todo el mundo.

¿Y cómo se las arreglaron los piratas informáticos para explotar este sistema? ¿Ellos manipuló una sola línea de código JavaScript, personalizado por Inbenta Technologies para los requisitos de Ticketmaster. Según Inbenta, el código se usó en una página para la que no estaba diseñada y, de haberlo sabido, lo habrían identificado como una vulnerabilidad de seguridad.

La vulnerabilidad en sí misma es esencialmente un problema de seguridad de la biblioteca de carga/almacenamiento de archivos, en el que una sola violación puede afectar a todos los sitios en los que se carga el mismo código. Para empezar, el código se puede modificar para recopilar y redirigir datos personales a los atacantes. Se trata de un ataque sencillo con un potencial de daño de gran alcance, y es algo contra lo que estamos trabajando para defendernos con un variedad de ejercicios de entrenamiento en la plataforma para desarrolladores.

Por supuesto, es prácticamente imposible administrar una empresa sin depender de algunas aplicaciones de terceros. Sin embargo, no puedes controlar la forma en que crean su software y, básicamente, no tienes ninguna visibilidad sobre el nivel de seguridad de su código. Se convierte en un ejercicio de confianza. Si su socio externo es laxo en sus prácticas de codificación segura, es posible que esté abriendo la puerta a una violación vuestroempresa.

Entonces, ¿cuál es la solución? En pocas palabras: todos debemos hacerlo mejor. Debemos dejar de pensar en la seguridad como un obstáculo irritante en el camino de la innovación empresarial.

Es más fácil de lo que piensa dotar a su equipo de desarrollo de las herramientas y los conocimientos adecuados para adoptar la seguridad y detener el código incorrecto. Nos complace ver que muchas de las empresas financieras, de telecomunicaciones, minoristas y tecnológicas más grandes y conocidas del mundo han adoptado este nuevo enfoque, pero las empresas de la lista Fortune 100 no deberían dedicarse exclusivamente a la educación en materia de seguridad. Todas las empresas que cuentan con desarrolladores entre su personal necesitan impartir formación para ayudar a los equipos a programar de forma segura.

El documento técnico publicado recientemente que escribí junto con nuestro director de tecnología, Matias Madou, muestra los beneficios de crear una cultura de seguridad en su organización. Detallamos por qué es la clave para impulsar la innovación, mantener la agilidad y reducir el impacto financiero del código inseguro.

Encontrará consejos que incluyen:

* Cómo hacer que la formación en seguridad sea relevante y atractiva para los desarrolladores

* Cómo enseñar a los desarrolladores a identificar y solucionar sus propios problemas

* Cómo ayudar a los desarrolladores a crear su propio código de forma segura.

Te invito a descarga este recurso y úsala para defender la seguridad en tu organización, desarrollar las habilidades de tu equipo y estar a la vanguardia del establecimiento de un estándar de código más alto.

Debemos dejar de pensar en la seguridad como un obstáculo irritante en el camino de la innovación empresarial.

En Secure Code Warrior, siempre buscamos ampliar nuestra cobertura de capacitación. Para que los desarrolladores de sistemas integrados y los administradores de seguridad puedan crear sistemas integrados seguros, nos adentramos en el mundo de la seguridad de los sistemas integrados. En esta publicación, hablaremos sobre el estándar MISRA C 2012 y sobre por qué es necesario cumplirlo para construir sistemas integrados seguros.

Al escribir código en C, es muy fácil implementar cosas que parecen correctas, pero que son intrínsecamente incorrectas. Tu código puede compilarse bien e incluso funcionar bien durante un cierto período de tiempo. Sin embargo, el mismo código podría fallar o mostrar un comportamiento indefinido si el tamaño de entrada o la memoria aumentan. Por ejemplo, un número de entrada determinado hace que un entero se desborde, o una secuencia de caracteres concreta hace que una matriz se salga de los límites.

Aquí es donde el estándar de codificación MISRA C puede ayudar. Las reglas, directrices y mejores prácticas establecidas en el estándar permiten a los desarrolladores escribir código C seguro y confiable para el desarrollo integrado.

MISRA C 2012, la última versión de la norma, agrega nuevas reglas, mejora las existentes y aborda algunas discrepancias. Si todavía utilizas una versión anterior, ahora sería un buen momento para cambiarla.

¿Qué es el estándar de codificación MISRA C?

El estándar MISRA C incluye pautas de seguridad, portabilidad y confiabilidad del código para el lenguaje de programación C. El primer conjunto de directrices se publicó en 1998 y era específico para el lenguaje C.

Sin embargo, desde entonces, el Consorcio MISRA también desarrolla estándares de codificación para C++. Cada documento C de MISRA contiene un conjunto de reglas, ejemplos que no cumplen con las normas y secciones detalladas sobre la información básica que contribuyó al desarrollo de dichas reglas.

C y C++ son los lenguajes más utilizados para desarrollar software embebido. Una de las principales razones es que son rápidos, ya que solo tienen 1 o 2 niveles de abstracción en comparación con el lenguaje de máquina. Pero esto también significa que escribir código seguro, especialmente en C, es difícil y propenso a errores. Por ejemplo, en la mayoría de los lenguajes de alto nivel, como Java y C#, no tienes que preocuparte por cosas triviales como la recolección de basura o la escritura dinámica.

Sin embargo, en C, no hay una forma predefinida de recolectar basura, es decir, si asignas una parte de la memoria para una estructura de datos, tienes que liberarla manualmente, una vez que hayas terminado de usarla. Si no lo haces, C, a diferencia de otros lenguajes, no te liberará memoria, lo que provocará una pérdida de memoria.

MISRA C 2004 (C2) contra MISRA C 2012 (C3) — ¿Qué ha cambiado?

MISRA C: 2012, también conocido como C3, se lanzó por primera vez en abril de 2013. Basándose en el conocimiento de los trabajos de miles de personas y organizaciones, el C3 añade nuevas reglas, mejora la explicación y los antecedentes de algunas reglas existentes y cierra algunas lagunas.

El C3 es compatible con la versión C99 del lenguaje y, al mismo tiempo, mantiene las reglas de la antigua ISO C90. La principal área de enfoque del C3 era reducir los costos habituales de la aplicación de las reglas y, al mismo tiempo, hacer que el uso del lenguaje C fuera más seguro en los sistemas críticos. Todo esto hace que sea prudente cambiar al nuevo estándar, si aún no lo ha hecho.

En general, esta es una lista de los cambios más importantes:

• Corrija los problemas encontrados en la versión de 2004.
• Aumente significativamente el número de reglas decidibles. Una regla es decidible, si una herramienta de análisis puede ayudarle a determinar la conformidad con ella.
• Las reglas se clasifican en «obligatorias», «consultivas» u «obligatorias». Las reglas obligatorias nunca deben infringirse, bajo ninguna circunstancia. Las normas obligatorias y consultivas pueden infringirse en situaciones especiales, siempre que la infracción esté justificada.
• Se ha añadido una guía sobre cómo aplicar reglas al código generado automáticamente. Esto es muy importante porque las mismas directrices del código escrito por humanos no siempre se aplican al generado por una herramienta.
• Elimine las reglas demasiado generalizadas que prohibían el comportamiento razonable de los usuarios. Por ejemplo, anteriormente se recomendaba no usar macros en absoluto, ya que pueden generar diversas dificultades y confusiones (no pueden depurar macros, las macros no tienen espacios de nombres, etc.). Esto impedía el uso de macros, incluso en situaciones en las que podían proporcionar una solución elegante, segura y cómoda. En MISRA C: 2012, se introdujeron nuevas reglas con respecto a las macros, que permitían a las personas usarlas con cuidado, siempre que fuera aplicable. Consulte el siguiente extracto, tomado de un documento de MISRA C, en el que se recomienda utilizar una macro en lugar de una función.

Reglas de MISRA C en acción

Basta de hablar, ahora es el momento de ponerse manos a la obra con algunas reglas de MISRA C, con ejemplos de cómo se aplican.

Utilice tipos compatibles como argumentos de puntero para memcpy, memmove y memcmp

Las funciones estándar de la biblioteca memcpy, memmove, y memcmp realizar un movimiento byte por byte o una comparación del número de bytes especificado. La regla 21.15 de la norma MISRA C 2012 dicta que los dos parámetros de la función deben ser punteros del mismo tipo. Una llamada a una función con tipos de punteros incompatibles podría indicar un error.

Considera la siguiente imagen, tomada del documento oficial de cumplimiento de MISRA. La regla es requerida, decidible, y se aplica tanto a C90 como a C99.

A continuación de la descripción de la regla se muestra un ejemplo.

Como puede ver, dado que los objetos son de diferentes tipos (uint8_t y uint16_t), esta es una solución que no cumple con los requisitos.

Las funciones de manejo de cadenas que no toman longitud como entrada no darán como resultado un acceso fuera de los límites

Las funciones de manejo de cadenas <string.h>que no toman la longitud como entrada no deberían resultar en un acceso fuera de los límites. Las funciones relevantes son: strcat, strchr, strcmp, strcoll, strcpy, strcspn, strlen, strpbrk, strrchr, strspn, strrstr y strtok. La regla es obligatorio, lo que significa que nunca se puede infringir, bajo ninguna circunstancia. Se aplica tanto al C90 como al C99, y es indecidible.

El ejemplo correspondiente es:

Como puede ver, strcpy en la función f1, copiará más allá de la longitud de la cadena, que solo puede contener 5 caracteres. También tenemos un uso seguro y compatible de strcpy, según el cual la cadena solo se copiará si cabe el contenido de «str».

Validar los datos recibidos externamente

Dir 4.14 recomienda comprobar la validez de los datos recibidos de fuentes «externas». La entrada externa puede ser:

• Lee desde un archivo.
• Lee desde una variable de entorno.
• Cualquier entrada del usuario.
• Todo lo que se reciba a través de un canal de comunicación. Por ejemplo, a través de una conexión TCP o una API HTTP, etc.

Esta directiva se inscribe en el requerido categoría, y es aplicable tanto a la C90 como a la C99. La razón de esto es que un programa no tiene control sobre los datos recibidos de fuentes externas, lo que significa que estos datos pueden ser inválidos o malintencionados. Por ejemplo, un programa espera que un usuario introduzca un número, pero el usuario introduce una cadena. Antes de procesar la entrada, el programa debe verificar que realmente se trata de un número.

Cómo cambiar a MISRA C 2012

El cambio a MISRA C 2012 requerirá una actualización en su documento de directrices de codificación. Si no usas una y, en cambio, confías en una herramienta de análisis estático (que es la opción recomendada), es posible que tengas que comprar una versión más reciente de la herramienta. Estas son tres herramientas que comprueban el cumplimiento de la MISRA C 2012:

1. Control de CPU es una herramienta de código abierto que puede comprobar las reglas de MISRA y también detectar varios tipos de errores.
2. PC-Lint Plus es una herramienta de pago que viene con un período de evaluación de 30 días. Además de comprobar el cumplimiento de MISRA C, también puede ayudar a identificar posibles errores y vulnerabilidades.
3. Código SONAR es otra herramienta que comprueba el cumplimiento de MISRA en C y C++.

También hay algunos compiladores que pueden probar el cumplimiento de MISRA. En caso de que se detecte una infracción de la regla, se generarán las correspondientes advertencias o excepciones. Por ejemplo. Programas de Green Hills proporciona compiladores compatibles con todos los estándares MISRA, para arquitecturas de 32 y 64 bits.

Uso de Secure Code Warrior para mejorar las habilidades de los desarrolladores en MISRA C

El producto estrella de Secure Code Warrior, la plataforma de aprendizaje, incluye numerosos desafíos, cursos y evaluaciones interactivos que pueden ayudar a capacitar a los desarrolladores para escribir código C/C++ seguro. El contenido de la plataforma es específico para cada marco y es muy atractivo. Nuestros desafíos de codificación C/C++:Embed se inspiraron en MISRA C, AUTOSAR C++ (MISRA C++) e IEC.

Los desarrolladores pueden embarcarse en viajes de aprendizaje personalizados, en los que identifican las vulnerabilidades específicas de C/C++ y, lo que es más importante, aprenden a corregir esos errores. En este proceso, los desarrolladores pueden hacer un seguimiento de su progreso para identificar sus puntos débiles e incluso disfrutar de un concurso de programación amistoso con sus compañeros. Obtenga más información sobre cómo ayudamos a las industrias automotriz y de transporte con nuestras soluciones.

¿Quiere saber qué tan interactivos y centrados son nuestros desafíos? ¡Prueba algunos desafíos de C/C++:Embed ¡en la plataforma de aprendizaje hoy!

Hace poco me entrevistaron para el Podcast Silver Bullet, presentado por Gary McGraw, en el que hablé sobre las ventajas de la industria sobre la investigación académica, por qué no era trivial iniciar una empresa en Europa y hacia dónde avanzará la industria de la seguridad de las aplicaciones en el futuro.

Si bien nunca tuve la intención de crear un negocio, lo hice porque vi que demasiadas empresas se enfrentaban al mismo problema; escribir código seguro es un desafío para la mayoría de los desarrolladores. Tenemos todo un sector centrado en encontrar problemas de seguridad en el código, y estos problemas no hacen más que acumularse.

Hay muy pocas soluciones que se centren realmente en ayudar de manera eficiente a las organizaciones y a su equipo de desarrollo que tienen dificultades para solucionar los problemas encontrados, y menos aún en tratar de evitar que se introduzcan más problemas en el código. Cada vez son más las organizaciones que se dan cuenta de este círculo vicioso y se dan cuenta de que su equipo de desarrollo necesita formarse para escribir código seguro desde el principio y debe estar equipado con las herramientas y los procesos necesarios para ello.

Si quieres saber más sobre cómo Gary McGraw y yo vemos el avance de la industria, consulta el Podcast Silver Bullet!

Show 139: Matias Madou analiza la formación en desarrollo seguro y la investigación sobre pruebas de seguridad del software

https://www.synopsys.com/software-integrity/resources/podcasts/show-139.html

Una versión de este artículo apareció en Lectura oscura. Se ha actualizado y distribuido aquí.

‍

Desde los primeros rumores sobre las herramientas de IA más novedosas y rompedoras de la cultura, tanto los desarrolladores como los curiosos de la programación las han estado utilizando para generar código con solo tocar un botón. Los expertos en seguridad señalaron rápidamente que, en muchos casos, el código que se estaba produciendo era de mala calidad y vulnerable, y en manos de personas con pocos conocimientos de seguridad, podría provocar una avalancha de aplicaciones y desarrollos web inseguros que afectara a consumidores desprevenidos.

Y luego, hay quienes tienen suficientes conocimientos de seguridad como para usarlos para, bueno, el mal. Por cada hazaña alucinante de la IA, parece que hay un contragolpe con la misma tecnología que se utiliza para propósitos nefastos. La suplantación de identidad, los vídeos fraudulentos totalmente falsos, la creación de malware, las travesuras de niños con guiones generales... estas actividades disruptivas se pueden llevar a cabo mucho más rápido y con menos barreras de entrada.

No cabe duda de que hay muchos cebos de clics que promocionan esta herramienta como revolucionaria, o al menos triunfa cuando se la combina con una habilidad humana «promedio». Si bien parece inevitable que la tecnología de inteligencia artificial tipo LLM cambie la forma en que abordamos muchos aspectos del trabajo (no solo el desarrollo de software), debemos dar un paso atrás y considerar los riesgos más allá de los titulares.

Y como compañero de programación, sus defectos son quizás su atributo más «humano».

Los patrones de codificación deficientes dominan sus soluciones preferidas

Con ChatGPT entrenado en décadas de código y bases de conocimiento existentes, no sorprende que, a pesar de su maravilla y misterio, también sufra los mismos escollos comunes a los que se enfrentan las personas cuando navegan por el código. Los patrones de codificación deficientes son lo más habitual, y todavía hace falta ser un experto en seguridad para generar ejemplos de codificación seguros formulando las preguntas correctas y proporcionando la ingeniería adecuada con rapidez.

Aun así, no hay garantía de que los fragmentos de código proporcionados sean precisos y funcionales desde el punto de vista de la seguridad; la tecnología es propensa a provocar alucinaciones, incluso crear bibliotecas inexistentes cuando se le pide que realice algunas operaciones JSON específicas, tal y como descubrió Mike Shema. Esto podría llevar a los ciberdelincuentes a «hacer alucinaciones», ya que estarían encantados de lanzar algún tipo de malware disfrazado de la biblioteca inventada que ChatGPT recomienda con total confianza.

En última instancia, tenemos que enfrentarnos a la realidad de que, en general, no esperábamos que los desarrolladores fueran suficientemente conscientes de la seguridad ni, como industria, los hemos preparado adecuadamente para escribir código seguro como estado predeterminado. Esto se pondrá de manifiesto en la enorme cantidad de datos de formación que se han introducido en ChatGPT, y podemos esperar unos resultados de seguridad igualmente mediocres de su producción, al menos al principio. Los desarrolladores deberían ser capaces de identificar los errores de seguridad y corregirlos ellos mismos o diseñar mejores instrucciones para obtener un resultado más sólido.

La primera estudio de usuarios a gran escala El examen de cómo los usuarios interactúan con un asistente de codificación de IA para resolver una variedad de funciones relacionadas con la seguridad, realizado por investigadores de la Universidad de Stanford, respalda esta idea, y una observación concluye:

»Observamos que los participantes que tenían acceso al asistente de IA tenían más probabilidades de introducir vulnerabilidades de seguridad en la mayoría de las tareas de programación, pero también más probabilidades de calificar sus respuestas inseguras como seguras en comparación con las de nuestro grupo de control.».

Esto habla de un nivel de confianza predeterminado en el resultado de las herramientas de codificación de IA, ya que producen código que siempre es intrínsecamente seguro, cuando en realidad no lo es.

Entre esto y las inevitables amenazas transmitidas por la IA que impregnarán nuestro futuro, ahora más que nunca, los desarrolladores deben perfeccionar sus habilidades de seguridad y elevar los estándares de calidad del código sin importar su origen.

El camino hacia el desastre de una violación de datos está lleno de buenas intenciones

No debería sorprendernos que los compañeros de programación de IA sean populares, especialmente porque los desarrolladores se enfrentan a una responsabilidad cada vez mayor, a plazos más ajustados y a las ambiciones de innovación de una empresa que recaen sobre sus hombros. Sin embargo, incluso con las mejores intenciones, la falta de conciencia práctica en materia de seguridad a la hora de utilizar la IA para programar conducirá inevitablemente a problemas de seguridad evidentes. Todos los desarrolladores con herramientas de inteligencia artificial y aprendizaje automático generarán más código, y el nivel de riesgo de seguridad dependerá de su nivel de habilidad. Las organizaciones deben ser muy conscientes de que las personas no capacitadas generarán código con mayor rapidez, pero también aumentarán la velocidad de la deuda de seguridad técnica.

Incluso nuestra prueba preliminar (abril de 2023) con ChatGPT ha revelado que generará errores muy básicos que podrían tener consecuencias devastadoras. Cuando le pedimos que creara una rutina de inicio de sesión en PHP utilizando una base de datos MySQL, el código funcional se generó rápidamente. Sin embargo, por defecto almacenaba las contraseñas en texto plano en una base de datos, almacenaba las credenciales de conexión a la base de datos en código y utilizaba un patrón de codificación que podía provocar una inyección de SQL (aunque sí filtraba los parámetros de entrada y detectaba errores en la base de datos). Todos los errores de los novatos, se midan desde cualquier punto de vista:
‍

‍
Las instrucciones adicionales aseguraron que se corrigieran los errores, pero se necesitan conocimientos de seguridad significativos para corregir el rumbo. El uso generalizado y descontrolado de estas herramientas no es mejor que dar rienda suelta a tus proyectos a desarrolladores noveles, y si este código sirve para crear infraestructuras delicadas o procesar datos personales, entonces estamos ante una bomba de relojería a punto de estallar.

Por supuesto, al igual que los desarrolladores junior sin duda aumentan sus habilidades con el tiempo, esperamos que las capacidades de AI/ML mejoren. Dentro de un año, es posible que no cometa errores de seguridad tan obvios y sencillos. Sin embargo, esto tendrá el efecto de aumentar drásticamente los conocimientos de seguridad necesarios para detectar los errores de seguridad más graves, ocultos y no triviales que aún corre el riesgo de producir.

Seguimos mal preparados para encontrar y corregir las vulnerabilidades de seguridad, y la IA amplía la brecha

Si bien en este momento se ha hablado mucho de «girar a la izquierda» durante muchos años, el hecho es que, para la mayoría de las organizaciones, existe una falta significativa de conocimientos prácticos sobre seguridad entre la cohorte de desarrollo, y debemos esforzarnos más para proporcionarles las herramientas y la educación adecuadas que les ayuden en su camino.

Tal como están las cosas, no estamos preparados para los errores de seguridad a los que estamos acostumbrados, por no hablar de los nuevos problemas derivados de la IA, como la inyección rápida y las alucinaciones en cuclillas, que representan vectores de ataque completamente nuevos que están a punto de despegar como la pólvora. Las herramientas de codificación basadas en la IA representan el futuro del arsenal de programación de un desarrollador, pero la formación necesaria para utilizar estas armas de productividad de forma segura debe venir ahora mismo.

‍

In life, generally, communication is a great thing. There’s no quicker way to come to an understanding, learn something new, or build a relationship. In the software space, APIs serve a communicative purpose that allows applications to talk to each other, boosting features and usability. That connectivity often creates a richer experience that end-users love, and increasingly, have come to expect from the software in their day-to-day lives. 

However, like in real life, it’s a big problem when they talk too much. Experian has recently found this out the hard way, when one of their APIs - used by a third-party partner - potentially leaked the credit scores of… well, just about every American citizen.

The problem was patched quickly, but questions remain on whether this vulnerability was truly stopped in its tracks. If one vendor was affected, chances are good that others were too, and there is the possibility that it is a systemic bug, affecting anyone making use of that insecure API.

API security is an issue that isn’t far from the minds of most security experts, and it’s something we need to equip ourselves with the knowledge to fight. 

Any swashbuckling geek can bypass poor API authentication

A feature of many data leaks, breaches, and security incidents, is that they rarely take a mastermind to achieve. Complex, insidious, damaging attacks like we saw with SolarWinds require teams of cybercriminal geniuses to carry out, and they are the exception rather than the rule. 

When an API is built with weak authentication, it’s rather easy for them to be exploited. Bill Demirkapi, the security researcher who discovered Experian’s API bug, determined that it could be accessed without any authentication. Inputting 00/00/0000 in the date of birth field granted him access to a person’s credit score, using only publicly available information like a name and associated mailing address. While this hasn’t been reported, the potential for these records to be scraped and contextualized as a credit-related data dump (and therefore valuable) is certainly there.

Clean and functional authentication processes should be in place no matter how small the use case; a chatterbox API that is not properly secured, and potentially opening up access to multiple systems, is a liability.

Broken Authentication is number two on the OWASP Top 10 API vulnerabilities list. Read more here on how you can avoid this bug, and test your skills on our platform once you’re done feeding your brain.

Poor API security controls are a widespread problem that requires cultural change

It’s not fair to point the finger solely at organizations like Experian, but the lack of nuance and security control diligence displayed in this particular API exposure doesn’t bode well for the many companies out there that are navigating APIs as part of their IT systems and endpoints. 

In general, we have a lot more work to do in not just finding and fixing API vulnerabilities, but understanding them as part of the attack surface we’re supposed to protect. Visibility over APIs - and how they have been built - is a huge concern, and it’s something that should be demanded as part of security best practices. Even an organization with the most stringent security measures can find itself undone by an API that is published and working outside of the company security controls. It is more important than ever to ask where an API has come from, who ultimately maintains it (is it a third-party vendor? How stringent are they with security?), and what information it is accessing. 

Injection vulnerabilities remain a barnacle for every CISO.

API security may seem like a fairly new module to include in a security program, but it can be exploited by some (very) old tricks we’re used to seeing in plain old web software.

A recently disclosed attack on Accellion revealed that chained SQL injection and OS command execution attacks allowed the threat actors to manipulate APIs, extracting a significant haul of sensitive data, including Social Security numbers. They determined that the attackers had to have had extensive knowledge of Accellion’s FTA software to carry out the heist, which would have been possible through substantial reverse engineering.

With the breach happening over December 2020 and January 2021, there was plenty of time for the thieves to cause damage. Further discoveries in February 2021 uncovered a stored XSS vulnerability, with forensic analysis finding that just one API endpoint having improperly sanitized user input made it possible to inject an argument when calling the admin.pl script. 

With over 3000 customers, including many prestigious educational institutions, this breach could be far-reaching. The unfortunate situation is that these exploits were made possible by leveraging common vulnerabilities, many of which could have been addressed at the code level, pre-production, by a security-aware developer. As we keep seeing time and time again, it only takes a small window left open to create big problems. And a culture of human-led cyber defense needs to be part of the strategy in solving a very human problem.

Want to test your API security skills now in Java Spring API, Kotlin Spring API, C# (.NET) Web API and more? Try some API challenges on our Learning Platform (check out all languages:frameworks via the drop-down):
‍

‍

Un desarrollador en su hábitat natural suele ser visto en un estado de profunda concentración, programando funciones asombrosas 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 anteriormente, muchos de nosotros seguimos priorizando las funciones por encima de las mejores prácticas de seguridad. Al fin y al cabo, en la mayoría de las organizaciones, se configura para que sea el trabajo de otra persona y la formación adecuada en materia de seguridad para nosotros es limitada. Las herramientas de análisis estático y pruebas de penetración (más conocidas como SAST) son solo una parte del proceso global para mitigar los riesgos de seguridad, ya que funcionan de forma bastante independiente de lo que hacemos nosotros... hasta que recibimos el código para corregirlo, por supuesto.

Y es en ese momento cuando muchos desarrolladores piensan:»¿Me odian los pentésteres?».

Estas interacciones suelen definir un equipo, una cultura. Lo preocupante es que la falta de comunicación, comprensión y colaboración en general ha creado tensión, al menos por parte del desarrollador. Piénsalo: imagina que has pasado unos cientos de horas esculpiendo una estatua maravillosa, y luego alguien viene con un martillo y empieza a romperla en pedazos después de que te haya dicho que sus cimientos no están a la altura. Esa es la dinámica que se percibe entre un probador y un desarrollador: un extraño masacra a sus favoritos del software por parte de un extraño que no ha trabajado en el proceso con ellos; en cambio, han aumentado la carga de trabajo y han retrasado la satisfacción del código de envío.

Tras haberme mudado al ámbito de la seguridad hace mucho tiempo, puedo ver ambos lados de la historia. Y no, los pentestres no odiar desarrolladores. Es muy probable que el pentester esté sobrecargado de trabajo y bajo mucha presión. Por lo tanto, un flujo constante de errores de seguridad comunes que podrían corregirse con bastante facilidad a nivel de código consume tiempo, recursos y espacio libre para dedicarse a los problemas realmente graves.

Siempre he visto a los pentestres como algo parecido a los 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, exploremos 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 dicen 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. Lamentablemente para los desarrolladores, cuando reciben los resultados de los análisis estáticos y de Pentest, pueden sentirse como una boleta de calificaciones. Les han dado calificaciones bajas, pero al final del día, sus los jefes los evalúan según las funciones que han creado y el tiempo que las han entregado, no si había elementos vulnerables en el software o no.

Para el pobre pentester, se trata de un caso de «no mates al mensajero». No es nada personal: tienen la tarea de encontrar errores y los han encontrado. Es cierto que, a nivel personal, puede que algunos pentésteres sean más gruñones que otros, pero no quieren (o no deberían) tratar de crucificar a los equipos de desarrollo. Sería mucho más fácil para ambos equipos si estuvieran en sintonía con lo que constituye una buena práctica de seguridad. Y no se espera que los desarrolladores sean perfectos; siendo realistas, el equipo de pruebas está ahí para protegerlos del envío de código vulnerable.

«Me han dicho que solucione todos estos problemas menores, ¿no saben que hay prioridades más altas? ¿Y por qué no me ayudan a solucionarlos si tanto les importa?»

Es cierto: la máxima prioridad de un desarrollador siempre será la creación de funciones y, en este loco mundo de rápida digitalización, tendrá que hacerse con rapidez. Si bien algunos programadores tienen un interés personal en la seguridad y la programación segura, la opinión general es que la seguridad es «un problema de otra persona», lo que inevitablemente incluye a los pentestres.

De hecho, las vulnerabilidades más comunes son problemas menores que deben solucionarse. Una vez conocidas, las soluciones son fáciles de ejecutar para cosas como la creación de scripts entre sitios (XSS) y la inyección de SQL... el problema es que muchos desarrolladores no se dan cuenta de que las están introduciendo desde el principio, y estos problemas aparentemente menores son la pequeña oportunidad que un atacante necesita para causar problemas devastadores a una empresa. Según Akamai, entre noviembre de 2017 y marzo de 2019, las vulnerabilidades relacionadas con las inyecciones de SQL tuvieron su origen 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, esa es una estadística aleccionadora.

Algunos equipos de Pentest ayudan a corregir los errores de seguridad, pero otros informarán sobre las malas noticias y esperan que los desarrolladores solucionen las revisiones, incluso si se han mudado a un proyecto diferente cuando esto suceda. Y, en algunos casos, el equipo de desarrollo puede recibir un informe que incluye errores que no pueden (o no se debería esperar que corrijan); aun así, tiene que formar parte de las conclusiones y, una vez más, no tomarse como algo personal.

El «punto medio» para esto sería que los pentestres, el personal de seguridad y los gerentes de desarrollo actuaran más bien como mentores para garantizar que el equipo tenga lo que necesita en términos de capacitación y herramientas eficaces, dando a los programadores individuales la mejor oportunidad de tener éxito y programar de forma segura desde el principio del SDLC. Ambos equipos deberían reunirse a mitad de camino para garantizar que la seguridad se tenga en cuenta desde el principio, como parte de una práctica saludable de DevSecOps.

«Tengo conocimientos de seguridad mucho mejores de los que me imaginan; 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 del SDLC, y las herramientas de análisis estático (SAST) desempeñan un papel fundamental. Y sí, los falsos positivos son un problema con estos y otros tipos de escáneres (DAST/IAST/RAST). Es una molestia en lo que ya de por sí es un proceso lento, que requiere una revisión manual del código y ejerce presión tanto sobre los desarrolladores como sobre los pentésteres. El personal de Pentesting se ha tomado su tiempo para configurar meticulosamente reglas personalizadas para evitar lecturas inexactas y ha proporcionado directrices específicas para cada empresa. Sin embargo, algunas lecturas falsas se escapan y acaban en manos de un desarrollador que se rasca la cabeza.

Este proceso no es perfecto, pero el otro problema es que muchos desarrolladores carecen de los conocimientos suficientes para mitigar muchas de las vulnerabilidades comunes de forma constante. Dado que la formación en seguridad es poco frecuente en la educación superior 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 exceso de confianza en juego (y no es su culpa: nosotros, como industria, necesitamos mejorar a la hora de proporcionarles lo que necesitan).

«No sabía que esta aplicación se iba a probar, pero ahora me he quedado con las tareas de corrección».

A veces, los ingenieros, con exceso de trabajo, asumen que los pentésteres están colgando entre bastidores, esperando el momento de atacar probando una aplicación y haciendo llover a todo el equipo de desarrollo. Hacen pruebas exageradas, son quisquillosos y crean trabajo extra.

El único problema con eso es que ellos también tienen exceso de trabajo (más aún, de hecho), la escasez de habilidades de ciberseguridad es en niveles nefastos y empeorando) y simplemente no tengo tiempo para hacer la prueba sin motivo. No son los únicos responsables de la toma de decisiones a la hora de priorizar las pruebas; podrían 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, perder los sprints actuales de creación de funciones para trabajar en soluciones de seguridad es molesto, especialmente si no es su trabajo. Es posible que la última actualización la haya realizado un equipo anterior u otro proveedor. Sin embargo, la seguridad es un problema de todos. Esto no significa que todos los desarrolladores tengan que hacerse cargo de los errores de seguridad como si los hubieran creado todos ellos mismos, pero sí tienen que unirse a la fiesta en términos de que la seguridad es una responsabilidad compartida.

¿Hacia dónde desde aquí?

A veces, un cambio de mentalidad puede ser todo lo que se necesita para lograr avances significativos en la solución de un problema. Ya hemos hablado de la reacción bastante fría que tienen los desarrolladores ante unos resultados poco favorables en un Pentest, pero ¿y si pudieran convertirlo en un desafío? Quizá puedan pensar en el pentester como un competidor amistoso, alguien a quien pueden derrotar en su propia partida. Al fin y al cabo, un desarrollador preocupado por la seguridad que pueda eliminar los errores más comunes a medida que escribe código hará que su trabajo sea mucho más difícil. Por el contrario, un desarrollador que no se centre en la seguridad será superado ampliamente por sus homólogos de Pentester cuando puedan descifrar fácilmente su software.

Es posible que los pentestres y los desarrolladores no se unan en armonía el 100% de las veces, pero su relación puede mejorar considerablemente si una organización aborda la seguridad como una prioridad clave y capacita a los equipos con los conocimientos y las herramientas adecuados para tener éxito, especialmente a los desarrolladores. Todo depende de si una cultura de seguridad positiva que abarque a toda la empresa es una prioridad, y si queremos librar la batalla (actualmente) perdida contra las vulnerabilidades comunes, no cabe duda de que debería serlo.

Migrar código (léase: código heredado) no es divertido. Se necesita una enorme cantidad de planificación y esfuerzo para lograrlo. Si bien no es el trabajo más emocionante o motivador para los desarrolladores, sí que requiere determinación y la experiencia adecuada para migrar el código heredado a las nuevas versiones de la biblioteca. Hora de Joda a java.time es una de esas migraciones que requiere una planificación y ejecución meticulosas.

Si su proyecto Java comenzó su vida antes de Java SE 8 y utiliza el procesamiento de fecha y hora, es probable que haya utilizado Joda-Time, una biblioteca excelente y un estándar de facto para gestionar las funciones de fecha y hora anteriores a SE 8. Si tu proyecto Aún así usa Joda-Time pero le gustaría migrar a java.time y luego siga leyendo.

La versión de Java SE 8 incluía una API de fecha y hora estándar nueva y mejorada, comúnmente denominada java.time (JSR-310). El proyecto Joda-Time ahora recomienda migrar a java.time (JSR-310).

Si bien java.time (JSR-310) se inspiró en gran medida en Joda-Time, no es compatible con versiones anteriores y los conceptos y terminologías han cambiado. Por eso, migrar de Joda-Time a java.time requiere prestar mucha atención a todas y cada una de las líneas de código que cambias. Esto puede llevar mucho tiempo y casi haría que deseara que hubiera una forma más fácil y automatizada de migrar.

Hay una forma mejor de migrar y la hemos creado con Sensei, un complemento de IntelliJ que realiza automáticamente transformaciones de código según las recetas (reglas) definidas por usted. Dedica tu tiempo a definir recetas reutilizables, en lugar de a realizar tareas de migración repetitivas. La automatización no solo transformará tu código heredado de Joda-Time, sino que también ayudará a los equipos a seguir las directrices que aparecen en el IDE a medida que escriben código nuevo.

Para ayudarlo a comenzar con ventaja, hemos creado un libro de cocina público sobre Sensei Estandarización en java.time (JSR-310) que incluye recetas para migrar de Joda-Time a java.time de una manera menos dolorosa. Se trata de un conjunto de recetas cada vez mayor que seguiremos ampliando para añadir más cobertura con más recetas.

Este es un ejemplo de un ejemplo de migración que puede ayudarle a ver cómo Sensei facilita la migración del código heredado.

Desde la migración manual repetitiva hasta las transformaciones de código automatizadas

Veamos un ejemplo de creación de un nuevo DateTime que muestra algunas trampas ocultas al migrar una sola línea de código de Joda-Time a java.time. A continuación, analizaremos una de las recetas de Sensei de nuestro libro de recetas sobre la estandarización de java.time (JSR-310) y mostraremos cómo captura toda esta información para que cualquier desarrollador pueda volver a utilizar esta misma migración una y otra vez.

En este ejemplo, estamos construyendo un Joda-Time DateTime a partir de 7 argumentos int que representan los valores de los campos DateTime.

¿Cómo migramos esto a un equivalente de java.time?

El javadoc en Joda-Time para este constructor dice:

Construye una instancia a partir de los valores de los campos de fecha y hora utilizando IsoChronology en la zona horaria predeterminada.

Al principio, podemos suponer que hay Fecha/hora clase en java.time, pero no hay ninguna. Si buscas en Google «migrar de la hora de Joda a la hora de Java», lo más probable es que encuentres la entrada del blog de Stephen Colebourne Conversión de Joda-Time a java.time.

Esto le da un buen comienzo y nos indica cómo usar java.time.zonedDateTime o java.time.offsetDateTime. Esta es nuestra primera pregunta, ¿cuál uso? Probablemente ZonedDateTime se basa en los comentarios de Stephen.

Buscando el ZonedDateTime javadoc, no podemos ver ningún constructor en absoluto. Volviendo a la entrada del blog de Stephen, leemos más abajo:

‍Construcción. Joda-Time tiene un constructor que acepta un objeto y realiza la conversión de tipos. java.time solo tiene métodos de fábrica, por lo que la conversión es un problema del usuario, aunque se proporciona un método parse () para las cadenas.

Por lo tanto, debe haber un método de fábrica estático, al buscar los métodos estáticos encontramos uno que se parece bastante, pero no es exactamente el mismo.

Tiene 7 parámetros int como nuestro constructor Joda-Time DateTime original, sin embargo, si no prestas atención, te perderás un detalle importante. El séptimo parámetro ya no representa milisegundos, sino nanosegundos, ya que java.time tiene una precisión mayor que Joda-Time y mide los instantes hasta el nano-segundo. Un detalle importante que podrías haber pasado por alto fácilmente. Además, este método espera un ZoneID, por lo que hace que te preguntes por qué no necesitabas uno antes y por qué lo necesitas ahora.

Recordando el javadoc de nuestro constructor original que mencionaba que usaría la zona horaria predeterminada, ¿tal vez haya una forma de obtener el ZoneID predeterminado?

El javadoc para ZoneID no nos informa sobre ningún constructor de la lista, pero al observar los métodos estáticos vemos que podemos usar Predeterminado del sistema ()

Ahora que hemos resuelto el ZoneID, ¿qué debemos hacer con nuestra conversión de milisegundos a nanosegundos? Tal vez podamos usar java.util.Concurrent.TimeUnit para realizar la conversión.

Este método devuelve un valor long y nuestro método espera un int, por lo que ahora también tenemos que resolver un problema de conversión. Tal vez podríamos probar algo simple. ¿Una multiplicación?

Esto funcionará, pero parece un poco fuera de lugar. Si aún no lo has notado, hemos dedicado una cantidad considerable de tiempo y esfuerzo a migrar una sola línea de código. Pero como puedes imaginar, tenemos muchas ediciones de este tipo que hacer a mano y no hay nada mejor.

Sin embargo, si analizamos un poco más la API java.time, podemos descubrir una solución que parece un poco más fluida.

Aunque ZonedDateTime no tiene una forma obvia de configurar los milisegundos, se puede hacer usando el con el método (campo temporalField, newValue largo), utilizando Cronofield. Mili_de_segundo como TemporalField.

Y el documento de Java menciona que realizará la conversión a nanosegundos por nosotros:

Cuando este campo se usa para establecer un valor, debe comportarse de la misma manera que si se establece NANO_OF_SECOND con el valor multiplicado por 1 000 000.

Así que podemos simplemente especificar 0 para nuestros nanosegundos en el método de fábrica y, a continuación, usar el con método para crear un ZonedDateTime que tenga todos los valores originales, así como los milisegundos.

Al observar nuestro resultado final, parece que solo hemos cambiado una línea de código, ¡realmente no muestra el esfuerzo que se dedicó a investigar solo una migración!

‍

Cree una receta para migrar de forma más rápida y sencilla

Sensei nos proporciona una forma de compartir esta información ganada con tanto esfuerzo con otros desarrolladores. Al crear una receta que recoja todos estos requisitos, permitirá a los usuarios de Sensei realizar esta migración con solo un clic del ratón.

Una receta de Sensei consta de 3 secciones principales:

• Metadatos
• Búsqueda
• Correcciones disponibles

Veamos una receta de Sensei (también se puede ver como una receta de YAML) que nos ayudará a migrar esta llamada a su equivalente en java.time.

DateTime foo = nueva fecha y hora (año, mes del año, día del mes, hora del día, minuto de hora, segundo de minuto, milisegundo de segundo);

Sección de metadatos

La sección de metadatos contiene información sobre la receta y cómo debe usarse.

Sección de búsqueda

La sección de búsqueda de una receta de Sensei especifica a qué elementos de código se debe aplicar esta receta.

buscar:
Creación de instancias:
argumentos:
1:
tipo: int
2:
tipo: int
3:
tipo: int
4:
tipo: int
5:
tipo: int
6:
tipo: int
7:
tipo: int
Recuento de arg: 7
tipo: org.joda.time.DateTime

‍

En esta sección de búsqueda vemos que estamos:

• En busca de un Creación de instancias, es decir, el uso de un Constructor. Nota: hay muchos otros objetivos de búsqueda disponibles
• El constructor debe tener 7 argumentos, esto se especifica en Recuento de arg propiedad
• argumentos 1-7 debe ser de tipo int
• Estamos buscando a los constructores del tipo org.joda.time.dateTime

‍

Sección de correcciones disponibles

La sección AvailableFixes puede especificar una o más correcciones que se pueden aplicar al elemento de código coincidente. Cada corrección puede tener varias acciones y, en nuestro caso, tenemos una única solución que realiza 2 acciones.

‍

• El nombre de la solución se muestra al usuario en el menú «Correcciones rápidas» y describe lo que ocurrirá si el usuario aplica esta solución rápida
• La lista de acciones muestra las acciones que realizará esta solución rápida.
• El volver a escribir la acción reescribirá el elemento de código utilizando una plantilla de bigote. Puede hacer uso de variables y funciones de reemplazo de cadenas.
• El Modificar variable asignada action comprobará si este constructor se utiliza para asignar el valor a una variable. Si es así, esta acción modificará la variable para declararla como el tipo especificado por tipo

‍

Uso de la receta para realizar la transformación del código

Con nuestra receta escrita y habilitada, escanea nuestro código y resalta los segmentos a los que se puede aplicar.

En la siguiente captura de pantalla podemos ver que el constructor objetivo ha sido marcado por Sensei. Al pasar el ratón sobre el constructor marcado, aparecen la opción Recipe ShortDescription y Quickfix Migrar a java.time.ZonedDateTime

‍

Después de seleccionar el Migrar a java.time.ZonedDateTime Quickfix, el código se transforma de acuerdo con las acciones que especificamos en la receta.

‍

Una migración única y prácticas de codificación uniformes en todos los equipos, con Sensei

En nuestro ejemplo anterior, podemos ver que la migración de una sola línea de código puede implicar un conocimiento adquirido con esfuerzo. Sensei puede convertir ese conocimiento en recetas prácticas o libros de cocina que puedan compartirse entre equipos. Puedes planificar una migración rápida única o adoptar el enfoque de realizar transformaciones instantáneas incrementales a java.time a medida que te encuentres con el código de Joda-Time. Puedes activar o desactivar las recetas para realizar las migraciones por etapas o pasos lógicos e incluso ampliar o reducir el alcance de los archivos analizados por Sensei, con la flexibilidad que hace que las migraciones de código sean menos complicadas.

La migración de bibliotecas es solo un ejemplo de las muchas maneras en las que se puede usar Sensei para estandarizar sus proyectos. Siempre puedes estar atento a los antipatrones o a ciertas transformaciones manuales de código que aparecen con frecuencia en las solicitudes de cambios o mientras codificas tú mismo. Si tienes un conjunto de directrices de codificación que los desarrolladores suelen pasar por alto, podrías convertir las directrices en recetas, lo que permitiría a los desarrolladores aplicar las transformaciones de código aprobadas con confianza.

Si tiene alguna pregunta, ¡nos encantaría saber de usted! Únete a nosotros en Slack en: sensei-scw.slack.com

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

‍

Como si no hubiéramos tenido suficientes interrupciones en un año que no se puede nombrar, 2021 comenzó con un golpe ensordecedor para el gobierno de los EE. UU., en forma de una de las peores filtraciones de datos de la historia. El incidente de SolarWinds fue un ataque devastador y sofisticado contra un estado nacional que hizo que varios departamentos gubernamentales y grandes organizaciones entraran en pánico y se esforzaran por proteger sus terminales. Prácticamente todos los usuarios finales del software SolarWinds se vieron comprometidos, y el incidente dejó muy claro que la ciberseguridad y la defensa en las cadenas de suministro de software son fundamentales.

Es obvio que la ciberseguridad es importante, pero ¿qué significa realmente en el contexto de las cadenas de suministro?

El estado de la ciberseguridad en un equipo de desarrollo promedio

Todos los días se produce una enorme cantidad de software, lo que representa miles de millones de líneas de código cada año, y eso no hace más que aumentar con la demanda creada por nuestro estilo de vida cada vez más digital. La población mundial de desarrolladores va camino de crecer para casi 29 millones para 2024, y actualmente no existe ninguna certificación formal para evaluar y certificar su capacidad para codificar de forma segura. Esto no quiere decir que todos los desarrolladores produzcan o reutilicen código inseguro, pero no cabe duda de que existe un riesgo sostenido de que se introduzcan puntos débiles de seguridad básicos en el software en el que confiamos nuestros datos.

Se evalúa la capacidad de los desarrolladores para crear funciones y enviar código lo más rápido posible. La seguridad no ha sido un punto de referencia para su éxito en la mayoría de las organizaciones, pero esa opinión está empezando a cambiar a medida que más empresas se dan cuenta del potencial que tienen para prevenir los errores de seguridad más comunes en las primeras etapas de la creación del software. Sin embargo, la realización y la implementación son dos cosas diferentes y, dado que la mayoría de los cursos de desarrollo terciario omiten cualquier contexto relacionado con las prácticas de codificación seguras, a menudo es el lugar de trabajo del desarrollador el que debe compensar el déficit. Si el desarrollo de habilidades y el intercambio de conocimientos son poco frecuentes o irrelevantes, es probable que no sean efectivos. Por lo tanto, el ciclo de vulnerabilidades recurrentes debido a la falta de desarrollo de habilidades permanece ininterrumpido.

Naturalmente, no es responsabilidad de un desarrollador de software promedio resolver los problemas de ciberseguridad del mundo; después de todo, las organizaciones contratan a esos costosos profesionales de seguridad por una razón. Sin embargo, los gurús de la seguridad escasean y, sin duda, los desarrolladores pueden contribuir a reducir la presión.

Pero, ¿dónde nos deja esto a nosotros (y a los proveedores que crean software para infraestructuras críticas y organizaciones sensibles) en términos de prevenir un ciberataque devastador? Va a requerir, como mínimo, un cambio en el status quo de la adquisición de software.

Los obstáculos que se interponen en el camino de una cadena de suministro de software segura

El viejo adagio de que una cadena solo es tan fuerte como su eslabón más débil es, lamentablemente, igual de cierto cuando se trata del suministro de software. En realidad, no importa si su empresa ha acudido a la fiesta con mejores prácticas de seguridad, una inversión en la mejora de las habilidades de los desarrolladores y una transición hacia un entorno DevSecOps funcional (es decir, que todos compartan la responsabilidad de que el software se fabrique de la forma más segura posible); si utiliza software de un proveedor que tiene problemas de seguridad, los heredará en su ecosistema y asumirá las consecuencias.

Por supuesto, el equipo de seguridad debería ayudar a evaluar la seguridad de las incorporaciones de terceros a la gama tecnológica, pero las decisiones se pueden tomar en función de una necesidad empresarial con pocas opciones de soluciones. En este punto, puede ser un ejercicio de confianza. ¿El proveedor se preocupa por la seguridad tanto como su empresa? ¿Y puede el proveedor evaluar realmente los riesgos de una manera tal como solo usted puede comprenderlos, así como los activos que necesita proteger?

La transparencia es un factor de suma importancia a la hora de evaluar la viabilidad de seguridad de las incorporaciones de software de los proveedores. ¿Lo son desde el principio con sus propias prácticas de seguridad? Deberían enorgullecerse de su enfoque para mantener los datos seguros y debería ser una de las principales prioridades. Si las prácticas de seguridad no se publican en ninguna parte o no hay información disponible, existe una gran probabilidad de que la seguridad no sea una prioridad. El proveedor debería poder responder a las preguntas técnicas y a las certificaciones independientes, como ISO27001 y el SOC2 tampoco haría daño. Además, si no puede «mirar a escondidas» y analizar vulnerabilidades como parte de sus propias prácticas internas de diligencia debida y seguridad, olvídelo.

Dado que la demanda impulsa una implementación tan rápida de las necesidades de software, especialmente si el código del proveedor se está incorporando a los sistemas existentes para realizar acciones en un nuevo contexto, tanto el proveedor como el comprador deben estar en la cima de su juego, y ambos deberían contar con sus desarrolladores sobre el terreno para detectar los errores y defectos de seguridad más comunes antes de su lanzamiento. Podría haber cientos (o miles) de dependencias comprometidas si se añade una nueva incorporación a la telaraña de soluciones tecnológicas existente, y un pequeño fallo podría llevar a una ruina catastrófica.

Entonces, ¿cuál es la solución? ¿Codificar todo internamente, desde cero? Si fue en 1998, eso podría tener sentido. Sin embargo, del mismo modo que ya no le preguntamos a Jeeves dónde está el lavadero de autos más cercano, necesitamos implementar medidas de seguridad realistas que funcionen en el contexto actual.

Todavía no existe una fórmula mágica, pero hay soluciones

Para los compradores, la evaluación de la seguridad del software y las prácticas de desarrollo de los proveedores debe ser una prioridad del programa de seguridad general y del plan de mitigación de riesgos. Haga preguntas sobre las certificaciones, las prácticas y la reputación de seguridad de sus desarrolladores.

Los vendedores (y, de hecho, cualquier empresa que cree software) deben estar preparados para demostrar que la seguridad es una prioridad y deben centrarse en la mejora de las habilidades. Desarrolladores expertos en seguridad tienen una gran demanda y con las herramientas y el soporte adecuados, pueden crearse a partir de su equipo actual y capacitarse para defenderse de los ataques derivados de vulnerabilidades comunes. Pero no les eches en cara ningún entrenamiento antiguo. Déles tiempo para prosperar con herramientas de seguridad que complementen sus flujos de trabajo actuales. Hágalo lo más fácil posible y observe cómo esos molestos errores comienzan a acumularse en el código que impulsa la empresa.

La conclusión es que cualquier riesgo de software se agrava inmediatamente si forma parte de la cadena de suministro y afecta a todos los usuarios y a cualquier sistema en el que se hayan utilizado componentes vulnerables. Si los proveedores no se toman tan en serio la seguridad como las empresas que implementan su software (o si tanto el proveedor como la organización carecen de su programa de seguridad), los ataques más devastadores y de mayor alcance a la cadena de suministro, como SolarWinds, inevitablemente se convertirán en la norma, y este es un problema crítico para todos.

El reciente Orden ejecutiva de ciberseguridad de la Administración Biden sin duda ha hecho hablar a la industria de la seguridad, especialmente a aquellos que buscan convencer a los desarrolladores de la importancia de aplicar las mejores prácticas de codificación segura en su trabajo diario. Por primera vez, los desarrolladores que trabajan en el software que utiliza el gobierno federal deben tener conocimientos de seguridad comprobados y cumplir con las directrices nuevas y evolucionadas.

Esto marca un cambio positivo en el status quo de la ciberdefensa y, finalmente, hace que la mejora adecuada de las habilidades de los desarrolladores sea parte de la conversación. Si bien estas políticas se centran en el gobierno de EE. UU., ofrecen una oportunidad global para que las organizaciones aborden y actualicen los estándares de seguridad actuales, desde los desarrolladores hasta el análisis de la seguridad de las cadenas de suministro de software.

Recientemente, el NIST solicitó comentarios públicos para informar sus próximas actualizaciones de la legislación HIPAA, entre otras, y esta fue una oportunidad imperdible para nosotros de unir la experiencia de nuestra empresa en documentos de posicionamiento que puedan ayudar a informar sobre un enfoque de ciberseguridad dirigido por personas más seguro y efectivo que ayude a las organizaciones a aprovechar sus equipos para obtener mejores resultados.

Como organización impulsada por expertos, tenemos la suerte de contar con algunos de los profesionales de ciberseguridad más dedicados y exitosos que trabajan con nosotros, incluidos el candidato a doctorado Pieter de Cremer y el Dr. Brian Chess, que forma parte de nuestro Consejo Asesor Técnico. Los tres nos pusimos manos a la obra para presentar formalmente documentos de posicionamiento al NIST, en los que destacábamos las maneras en que nuestro enfoque de la mejora de las habilidades de los desarrolladores y la seguridad preventiva en la fase de creación de software podría tener un impacto positivo en los estándares de ciberseguridad en el futuro.

Una vía de desarrollo segura, pavimentada para los desarrolladores

Las herramientas de escaneo de vulnerabilidades, el monitoreo y otras formas de automatización de la seguridad son cada vez más frecuentes, y figuran tanto en la nueva Orden Ejecutiva como en las directrices del NIST. Son una parte cada vez más esencial de un programa de seguridad moderno, pero la historia y el presente demuestran que las herramientas de escaneo, en particular, detectan vulnerabilidades en el software con una eficiencia cada vez mayor, pero esto por sí solo no tiene ningún efecto a la hora de reducirlas o, de hecho, de mejorar la seguridad desde el principio.

Una pila tecnológica engorrosa que distrae y ralentiza el flujo de trabajo de los desarrolladores es una de las razones fundamentales por las que los desarrolladores se desvinculan de la seguridad y la ven de forma negativa. Sin embargo, si los desarrolladores tuvieran un camino pavimentado para un desarrollo seguro, uno que se adaptara no solo a la tecnología, sino también a los lenguajes, los marcos y los objetivos de desarrollo específicos del proyecto, incorporar la seguridad en el proceso de desarrollo desde el principio, con la menor interrupción posible de su productividad, es ideal, lo que se traduciría en una reducción significativa de las vulnerabilidades comunes con el tiempo.

Para leer nuestro documento de posicionamiento del NIST en su totalidad, descárguelo ahora:

Marco de certificación para prácticas de desarrollo seguras: el eslabón perdido (actual)

Hasta la fecha, no existe una certificación formal para verificar las habilidades de codificación segura y las mejores prácticas. Este ha sido un descuido de la industria durante mucho tiempo, y nuestra posición es que es esencial para el futuro, con una ciberdefensa mejorada y un desarrollo seguro.

Sabemos que hay muchas formas de formación en seguridad dirigidas a los desarrolladores, pero si el volumen de filtraciones de datos a gran escala, ciberataques y código de mala calidad que existe es un indicio, no se trata de crear desarrolladores conscientes de la seguridad y no están equipados con los conocimientos necesarios para hacer mella en un problema que no hace más que empeorar.

La mejora de las habilidades de los desarrolladores requiere herramientas y educación que sean relevantes para el trabajo diario, contextuales, breves (pero frecuentes) y les permitan aprovechar los conocimientos existentes en los lenguajes y marcos que realmente utilizan. La formación genérica no basta, y esto debe quedar muy claro en la legislación y en los organismos industriales, como el NIST.

El Marco NICE es más que adecuado para elaborar directrices de certificación exhaustivas que utilicen activamente metodologías que funcionen y que sean de mayor interés y relevancia para los desarrolladores y su trabajo. La alineación con este marco institucional reconocido ayuda a estandarizar las prácticas que realmente marcan la diferencia y proporciona vías más concretas para que las organizaciones las sigan.

Para leer nuestro segundo documento de posicionamiento del NIST en su totalidad, descárguelo ahora:

El factor humano en la ciberseguridad a menudo se olvida, y es hora de que trabajemos para encontrar soluciones humanas para los problemas humanos, como las vulnerabilidades comunes recurrentes. Los errores de hace décadas ya no deberían hacer que nos engañemos, pero será necesario el respaldo de los gobiernos mundiales para cambiar el status quo y lograr un impacto positivo y mensurable.
‍
¿Está preparado para certificar a sus desarrolladores? Ha venido al lugar correcto. Echa un vistazo a nuestro Plataforma de aprendizaje hoy.