Cuanto más acceso, mejor

La cuestión fundamental es: ¿te gustaría que tus aplicaciones o tu infraestructura de TI siguieran teniendo vulnerabilidades de seguridad que podrías identificar y eliminar? Estando en tus cabales, la respuesta obvia sería un rotundo "no". Entonces, ¿por qué no dar acceso a tu código fuente a los expertos en seguridad para que lo evalúen meticulosamente?

Desconfianza. Esta es la respuesta que tienden a dar algunas organizaciones. En este artículo, te animamos a que dejes de lado ese sentimiento, al menos con Fluid Attacks, explicándote que cuanto más acceso tengamos a tu código, mejor puede ser tu postura de ciberseguridad.

Las pruebas de seguridad de software suelen dividirse, además de en otras clasificaciones, en dos grupos: Pruebas de "caja negra" y pruebas de "caja blanca". Aunque algunos puedan hoy en día encontrar esta clasificación errónea e incluso ofensiva por el uso de las palabras "negro" y "blanco" —algo que no pretendemos discutir aquí—, hasta el punto que se han ofrecido palabras sustitutivas como "opaco" y "transparente", lo que pretende denotar es una analogía con la ausencia y presencia de luz para ver lo que hay dentro de la "caja": el código fuente. Por lo tanto, en las pruebas de caja negra, a los expertos en seguridad no se les concede acceso al código fuente del software que se va a evaluar, mientras que en las pruebas de caja blanca, sí.

En las pruebas de caja negra, la evaluación de seguridad parte de lo que puede experimentar el usuario final y se centra en los riesgos asociados a las entradas o inputs y salidas o outputs del producto en funcionamiento. Mientras que en las pruebas de caja blanca, la evaluación se concentra en la estructura interna y el funcionamiento del sistema a nivel de código.

Cuando lo que pretendemos hacer es una prueba de penetración en modo caja negra (un método que podemos asociar con el término "red teaming"), es como si actuáramos desde la perspectiva de atacantes maliciosos en la Internet. Aunque no recibimos permiso inicial para ver el código fuente, podríamos arreglárnoslas para conseguirlo con habilidades en análisis y explotación de vulnerabilidades.

Así que, suponiendo que te demostramos que podemos llegar a una parte de tu código sin que nos lo hayas permitido, podríamos hacerte la siguiente pregunta: "¿Quieres que procedamos a hacer una evaluación exhaustiva de tu código para ver qué otras vulnerabilidades podemos detectar allí?". En ese momento, es posible que tu rechazo a las pruebas de caja blanca ya se haya minimizado o incluso haya desaparecido, al reconocer que tu código está expuesto a los actores de amenazas.

Sin embargo, suponiendo que en un periodo determinado haciendo pen-testing de caja negra, no hayamos conseguido penetrar en tu código, podrías preguntarnos lo siguiente: "Si ustedes no lo han logrado, ¿significa esto que el código de mi producto está a salvo de hackers maliciosos?". Aún peor, es posible que ni siquiera nos hagas esta pregunta, sino que asumas inmediatamente que eso es cierto y abandones las pruebas de seguridad. Pero la respuesta más sensata a esa pregunta sería: "No lo sabemos, pero lo más posible es que no".

Limitar el tiempo disponible para las pruebas de penetración es limitar su profundidad. Esta es una actividad que debe realizarse continuamente. A diferencia de los hackers éticos que se vieron obligados a hacerlo, los actores de amenazas pueden no abandonar su búsqueda de vulnerabilidades. Pueden, por ejemplo, buscar evasiones de autorización y vulnerabilidades de escalamiento de privilegios, las cuales, por desgracia, son bastante comunes en las aplicaciones hoy en día, para llegar a las cuentas de administrador. A partir de ahí, pueden identificar vulnerabilidades, por ejemplo, en las restricciones para cargar y descargar archivos, y conseguir acceso al código fuente. Ya de ahí puede surgir lo peor, según las vulnerabilidades presentes en el código.

Sabiendo que, sea quien sea, es muy posible que alguien acceda al código de tus aplicaciones o infraestructura, ¿no es mejor ahorrar tiempo e ir inmediatamente a evaluarlo para encontrar y remediar sus problemas de seguridad y evitar así daños a tus datos (incluidos los de tus usuarios) y operaciones? Es comprensible que tus dudas estén relacionadas con la protección de la privacidad de tu propiedad intelectual. Pero tú puedes protegerla con la ayuda de una empresa realmente comprometida con la ciberseguridad, cuya buena reputación e integridad puedas verificar fácilmente, y de la que recibirías garantías legales de confidencialidad, como un acuerdo de no divulgación. A esa empresa, deberías solicitarle pentesting de caja blanca o, mejor, “pentesting asistido por código”.

Quizá nos preguntes: "Si les doy acceso a mi código fuente, ¿seguiría siendo pentesting lo que ofrecen?". La respuesta es "sí". En el pentesting asistido por código, el punto de vista del atacante no se deja de lado. En pocas palabras, como su nombre lo indica, los pentesters se basan en tu código fuente para obtener asistencia. Esto termina siendo un trabajo colaborativo en el que la interacción entre los equipos de seguridad y desarrollo puede ser fundamental para comprender el producto y sus problemas de seguridad.

La visibilidad del código ofrece a los expertos en seguridad el máximo alcance para su evaluación. Les permite realizar un análisis más amplio, profundo y preciso en el que pueden vincular fácilmente sus hallazgos a ubicaciones específicas del código. Además, ellos pueden reportar tipos de vulnerabilidades y configuraciones erróneas que solo pueden verse en el código, o que apenas serían perceptibles en la funcionalidad o la lógica de la aplicación en evaluación. Sin embargo, conviene aclarar que no siempre es necesario tener acceso a todo el código de un repositorio y que, de hecho, el pen testing no es lo mismo que la revisión de código fuente. En esta última, el objetivo es realizar un análisis completo del código fuente, mientras que en el primero se hace más énfasis en los objetivos prioritarios (p. ej., componentes críticos de la aplicación) y en los riesgos definidos conjuntamente con el cliente.

Es importante señalar que el pentesting asistido por código permite a los pentesters ahorrar tiempo en las fases de reconocimiento y enumeración. Es decir, ellos pueden encontrar más rápidamente las vías de acceso y los puntos débiles y definir los vectores de ataque adecuados, tales como los relacionados con la inyección de comandos específicos, en función de los controles de seguridad presentes en el código. Además, esta forma de pruebas de penetración permite que las recomendaciones y directrices de remediación sean más precisas, sin recurrir a suposiciones. Identificar y notificar ubicaciones específicas de vulnerabilidades dentro del código fuente facilita el proceso de remediación para tus desarrolladores.

En Fluid Attacks, cuando se trata de pruebas de penetración (porque también ofrecemos pruebas automatizadas como SAST, DAST y SCA y pruebas manuales como la revisión de código fuente), nos centramos en proporcionar pentesting continuo asistido por código. Dentro de nuestra empresa, reconocemos el enorme valor de esta metodología para un amplio reconocimiento de la superficie de ataque de una aplicación o infraestructura y para fortalecer la postura de ciberseguridad de una organización. Somos conscientes de que no revisar el código fuente suele representar una exposición muy alta a los riesgos de ciberseguridad.

Queremos recordarte algo que ya hemos mencionado antes. El hecho de que tu código no sea visible públicamente no significa que sea seguro. Su seguridad depende principalmente de las buenas prácticas que se sigan a lo largo de su desarrollo. De nuevo, está claro que con la privacidad de tu código puedes tratar de proteger tu propiedad intelectual. Aún así, te garantizamos que puedes establecer una relación de confianza mutua con nosotros. Con nuestras herramientas y hackers éticos, buscaremos mantener la exposición al riesgo de esa información y de tus productos de software, en general, al mínimo.

¿Quieres empezar con una prueba gratuita en la que principalmente nuestras herramientas puedan acceder a tu código? Aprovecha ahora mismo nuestra prueba gratuita de 21 días. ¿Quieres comenzar con el paquete completo, incluyendo nuestra IA y nuestros hackers éticos? Contáctanos, hablemos, conozcámonos y establezcamos una relación comercial a largo plazo en favor de tu ciberseguridad.