4 documentos esenciales para cumplir con requisitos de desarrollo seguro
Todo fluye de maravilla en el área TI hasta que un cliente pide “Evidencias” de nuestras prácticas de desarrollo seguro. Ahí es donde todos entramos en pánico.
Probablemente en tu caso existen un puñado de prácticas de ciberseguridad, sin embargo, ¿qué implica realmente implementar prácticas de desarrollo seguro?
La seguridad en el software es la suma de personas, tecnologías y procesos. Quizás has oído acerca de diferentes tipos de pruebas rápidas que puedes obtener con aplicaciones automatizadas. Aunque algunas son útiles para evidenciar la seguridad, esto no va a ser suficiente prueba para tu auditor.
Entonces ¿cómo muestro cumplimiento cuando me piden desarrollo seguro? Sigue leyendo para entender qué documentos debes enviar y qué herramientas te serán útiles para poder obtenerlos.
1. Política de desarrollo seguro
La política de desarrollo seguro describe los lineamientos o prácticas de seguridad que se aplicarán durante la construcción del software de tu empresa.
Este documento definitivamente te lo piden para cumplir con ISO 27001, SOC 2, PCI DSS, pero al mismo tiempo, quienes no están alineados a las normativas también se llegan a topar con el requerimiento en los cuestionarios de ciberseguridad corporativos (ellos sí están alineados).
Los lineamientos que debes contemplar en este documento deben cubrir varios aspectos. Aquí te explicamos los principales:
Validación de entradas y salidas
La validación de entradas es la manera en la que una app trata la información con la que opera, y al ser un punto donde suceden la mayor cantidad de ataques, debes crear lineamientos que generen restricciones para, por ejemplo, permitir 1 solo input válido y los valores que se aceptarán. Otros ejemplos de lineamientos pueden ser:
1.Utilizar una rutina probada y estándar para cada tipo de codificación de salida;
2. Codificar todos los caracteres salvo que sean reconocidos como seguros por el interpretador al que están destinados.
Manejo de autenticaciones
Una práctica de seguridad en la autenticación puede ser: validar la implementación de captcha para evitar ataques de fuzzing y bruteforce sobre el panel de logueo.
Es decir, aquí debes incluir todos los mecanismos o prácticas para que la “acreditación” o autenticación de un usuario no pueda ser eludida y sea lo más segura posible.
Administración de sesiones
Debes crear lineamientos para asegurar las sesiones de los usuarios y así evitar robos de sesiones o vulnerabilidades. Por ejemplo, algunos lineamientos pueden ser:
1. Que exista un tiempo de expiración por inactividad o timeout de sesión
2. Establecer un tiempo de vida de la sesión lo más corto posible (balanceando los riesgos con los requerimientos del negocio)
3. La cookie de sesión no debe ser ejecutada en un equipo distinto al que fue creada, etc.
Hackmetrix Insight: quienes estén regulados por la Ley Fintech México las sesiones deben tener tiempo de caducidad y no se permiten sesiones simultáneas
Prácticas criptográficas
Debes especificar cuáles serán las medidas para encriptar la información de tu app, por ejemplo con estándares de seguridad de la industria como AES-128, AES-256 y TLS 1.2 o TLS 1.3, almacenamiento de claves con Bcrypt (un estándar para cifrar credenciales), Auth0 o JWT.
Hackmetrix Insight: para cumplir con la normativa PCI DSS, el algoritmo de cifrado debe ser 3DES como mínimo. De todas formas, lo recomendable es tener uno más fuerte ya que 3DES es básico para los tiempos que corren.
Manejo de errores
Como por ejemplo, cuidar que los errores internos de tu app muestren mensajes genéricos para no entregar pistas a posibles atacantes.
Es decir, todas las aplicaciones deben diseñarse y programarse previniendo y manejando estos posibles errores y excepciones. Otros ejemplos pueden ser:
1. Verificar que la aplicación reenvíe al index o al 404 frente la alteración manual del path o parámetros.
2. Utilizar manejadores de errores que no muestren información de debugging o de memoria.
Estándares de codificación
Debes incluir lineamientos para asegurarte de que el código cumpla con los “patrones” seguros del lenguaje de programación que utilices. De esta forma, los desarrolladores tendrán una guía para producir código libre de debilidades que puedan ser explotadas por un atacante. Lo importante al establecer estos lineamientos es que el equipo conozca y mantenga presentes estos estándares durante todo el ciclo.
Seguridad de los ambientes
Como la separación de los ambientes por medio de una VPC, uso de diferentes credenciales de acceso para cada ambiente, controlar los accesos a cada ambiente, uso de VPN para no exponer los ambientes a Internet, uso de WAF y firewalls internos que tus entornos reciban únicamente conexiones entrantes desde la VPC y desde la VPN.
Seguridad en el desarrollo tercerizado
En caso de que tu aplicación la desarrolle un tercero, debes detallar cómo será la gestión de la seguridad. Por ejemplo, deberías supervisar si cumplen con algún marco de cumplimiento, controlar las licencias y propiedades de código fuente, conocer qué tipo de estándar siguen para evitar vulnerabilidades, etc. Recuerda que todo esto debe ser plasmado en acuerdos firmados y consensuados con el proveedor.
? Qué enviarle a tu cliente: cuando envíes la política de desarrollo seguro a tu cliente recuerda que debe estar revisado y firmado por tu comité de seguridad de la información (o por la Alta Gerencia, en caso de no contar con un comité).
2. Seguridad en la metodología de desarrollo
Ya tienes tu política y desarrollo seguro ¡Genial! Pero recuerda que es importante trasladar estos lineamientos formales a la práctica diaria de tu empresa, por ejemplo integrando la ciberseguridad al equipo DevOps.
En este punto no solo nos referimos a la incorporación de prácticas y técnicas en un proceso específico, sino a un cambio real desde la cultura organizacional que tome en cuenta a la ciberseguridad como un papel integrado en el ciclo de vida del desarrollo de tus aplicaciones.
Debes saber que existe una metodología llamada DevSecOps en la que la seguridad es una responsabilidad compartida e integrada en todo el proceso que contempla fases con requerimientos de seguridad orientados al cumplimiento. Es decir, DevSecOps contempla el cumplimiento de los estándares de seguridad desde el principio hasta el final del ciclo de desarrollo.
Si quieres adoptar esta metodología, uno de los primeros pasos será, entonces, crear esos requerimientos medibles y validar que sean implementados a lo largo de todo el ciclo de vida de desarrollo.
Por ejemplo, los lineamientos que vimos en la política de desarrollo seguro generalmente se contemplan en las primeras fases del desarrollo, en la fase de Planear (Plan) de esta metodología DevSecOps, ya que es donde se analiza el modelo de amenazas (Threat Modeling): como la autenticación de usuarios, servidores externos, cifrado, adopción de la práctica Policy as a Code (escribir código en un lenguaje de alto nivel para automatizar las políticas y permitir que los desarrolladores trabajen en la definición de funciones sin sacrificar el cumplimiento) o la práctica de Security as a Code (automatizar los controles de seguridad en el pipeline). Aquí se generarán tickets o stories destinados específicamente a la seguridad.
? Qué enviarle a tu cliente: como evidencia puedes mostrar la documentación de tus procedimientos de DevSecOps.
3. Reportes de análisis de código
Existen diferentes tipos de herramientas para analizar la seguridad de tu aplicación desde el código: las de análisis estático (SAST), las de análisis dinámico (DAST) y las híbridas (IASP).
- Las herramientas SAST encuentran vulnerabilidades de seguridad en el código fuente de la aplicación, es decir, analizan el código cuando éste no se está ejecutando.
- Las herramientas DAST, encuentran vulnerabilidades y debilidades en la seguridad de una aplicación en ejecución, normalmente aplicaciones web, es decir se usan durante la fase de prueba y control de calidad de la aplicación.
Puedes usar ambas herramientas en conjunto ya que se conectan al proceso de desarrollo en diferentes etapas. Podemos decir que las SAST brindan comentarios educativos para los desarrolladores, mientras que las DAST brindan una perspectiva externa de la aplicación antes del funcionamiento.
En DevSecOps, el análisis de código se contempla en la fase de Crear (Code o programación) donde el equipo de desarrollo debe informarse en cómo utilizar estas herramientas de seguridad y familiarizarse con los términos, tipos de ataques, etcétera.
Recuerda que tanto las normativas como los cuestionarios de ciberseguridad de corporativos suelen pedirle a las empresas demostrar cómo te encargas de identificar y solucionar las vulnerabilidades en el código de tu software. Con este tipo de herramientas podrás evidenciar las vulnerabilidades medias y bajas que debes remediar.
Herramientas SAST
Si tienes un versionador GIT, las herramientas SAST que te recomendamos son SonarQube o SonarCloud:
- Si instalas SonarQube puedes usar este plugin exclusivo de OWASP Dependency Check.
- SonarCloud hasta el momento no ha lanzado un plugin exclusivo, sin embargo, las reglas que actualmente son cercanas a los requisitos de OWASP y se pueden configurar dentro del escáner con las reglas faltantes para “cumplir” con normativas como ISO 27001.
También te recomendamos Snyk que además de analizar código pueden escanear la infraestructura como código y OWASP ZAP que es open source y gracias a su buen nivel de adopción, cuenta con un plugin o complemento de integración con Jenkins.
Herramientas DAST
Recomendamos Tenable.io y Nessus, son soluciones que prueban aplicaciones web “desde el exterior”, cuando la aplicación se ejecuta en un entorno de prueba o producción.
? Qué enviarle a tu cliente: como evidencia podrías enviar las siguientes capturas de pantallas.
- Escaneo activo en repositorios y dependencias
- Muestra del dashboard del escaneo
- Algún resultado “crítico” y sanitizado
4. Reporte de pentest o ethical hacking
Una prueba de intrusión (pentests o ejercicio de ethical hacking) es una simulación de diferentes ciberataques a los sistemas, redes y aplicaciones de una empresa. El objetivo es encontrar y explotar la mayor cantidad de vulnerabilidades posibles para luego reportarlas y permitir que la empresa las pueda remediar.
Hay varias diferencias con las herramientas automatizadas que vimos previamente: las pruebas de intrusión mezclan pruebas manuales y automatizadas para encontrar vulnerabilidades más allá del código de una aplicación, también buscan vulnerabilidades en las redes internas y externas, y en el factor humano (pueden usar técnicas para manipular a un empleado y así conseguir información confidencial como contraseñas, etc.).
Las pruebas de intrusión son una forma de obtener información de las defensas de una empresa desde la perspectiva de un atacante ya que, por lo general, también se “encadenan” las vulnerabilidades encontradas para llegar hasta los datos más críticos de un negocio.
? Qué enviarle a tu cliente: Si tu empresa ha realizado este tipo de pruebas anteriormente, te recomendamos presentar el último informe de resultados como evidencia de tu compromiso con la protección de datos. Este informe únicamente debe nombrar las vulnerabilidades que han sido reparadas (nunca mostrar el detalle de cómo ha sido vulnerada cada parte).
Si tu última prueba de intrusión ya lleva más de un año o aún no has experimentado este tipo de ejercicios sobre tu plataforma, escríbenos para que te guiemos paso a paso.
Conclusión
Antes o durante el cierre de un contrato, tus clientes pueden pedirte que demuestres las prácticas de desarrollo seguro que utilizas, y tú debes tener la evidencia lista para evitar retrasos y contratiempos en la venta.
Para estos casos, lo recomendable es enviar la política de desarrollo seguro, en la que podrás formalizar las prácticas de desarrollo seguro y demostrar tu compromiso por incluirlas durante la construcción de tus aplicaciones; los procedimientos de tu metodología DevSecOps, para demostrar que la seguridad tiene un papel integrado a lo largo del ciclo de vida de desarrollo de las aplicaciones; los resultados de pruebas de código, para demostrar que has identificado y solucionado las vulnerabilidades más críticas del código de tu software; por último, tu último reporte de pentest para brindar información del último estado de defensa de tu empresa y las vulnerabilidades críticas que has solucionado.
Recuerda que la política de desarrollo seguro y las demás evidencias deberían estar enmarcadas, idealmente, en un programa de ciberseguridad o en una estrategia alineada a un marco de cumplimiento, sobre todo si también quieres crear medidas de seguridad para las demás áreas (como la financiera, comercial, RR.HH., etc.) que manejan información crítica para tu negocio.
Si quieres que te ayudemos con el caso particular de tu startup envíanos un mensaje para darte la guía que necesitas.
