Mejores prácticas que debes incluir en tu política de desarrollo seguro
No subestimes a una política de desarrollo seguro. Si bien en Internet encontrarás un océano de información sobre las mejores prácticas de desarrollo seguro que se pueden aplicar al entorno de trabajo, esto no será suficiente para tus auditores de seguridad ya que, hasta cierto punto, funcionarán como un “parche” momentáneo.
Si tu intención es crear una cultura de desarrollo seguro en tu equipo TI, lo recomendable siempre es formalizar estos lineamientos en una política de desarrollo seguro para que todos tengan conocimiento de la importancia que toma la ciberseguridad en la empresa.
En esta guía para empresas en crecimiento te aconsejamos sobre las secciones más importantes que debes incluir en tu política y ejemplos de lineamientos de desarrollo seguro, para que puedas crear una política que resista revisiones de auditores de seguridad.
¿Qué es el desarrollo seguro de software?
El desarrollo seguro es el uso de buenas prácticas de seguridad a lo largo del ciclo de vida del software. Estas buenas prácticas deben conformar una metodología o proceso de modo que pueda integrarse a todas las etapas de desarrollo de las aplicaciones (definición, diseño, desarrollo, implementación y mantenimiento).
Es por eso que, habitualmente, se asocia al desarrollo seguro con la metodología DevSecOps, es una de las pocas, sino la única, en la que la seguridad es una responsabilidad compartida e integrada en todo el proceso y donde se incluyen requerimientos orientados al cumplimiento de estándares.
La idea es que los equipos piensen “por defecto” en qué fallos o necesidades de seguridad va a tener la aplicación desde el momento en el que comenzamos a construirla.
Integrar las buenas prácticas desde el inicio evita retrasos en el lanzamiento del producto ya que los errores se corrigen durante la implementación o durante las pruebas. Esto también ahorra costos para el negocio y facilita el cumplimiento de requisitos de seguridad, ya sean de clientes corporativos, reguladores o de estándares internacionales como ISO 27001, PCI DSS, SOC 2, RAN 20-10 o la Ley Fintech de México.
¿Qué es una política de desarrollo seguro?
Para generar una cultura de software seguro primero hay que sentar las bases sobre cómo se van a incorporar los procesos y procedimientos a la metodología de trabajo actual.
En este punto, diseñar una política de desarrollo seguro será de ayuda ya que permitirá formalizar las intenciones y aclarar las responsabilidades de todos en este compromiso por construir una aplicación más segura.
La política de desarrollo seguro debe definir todos los lineamientos o mejores prácticas que se usarán como parte del ciclo de vida de desarrollo, incluyendo la seguridad del ecosistema de herramientas utilizadas. Debe dar instrucciones claras sobre cómo ver, evaluar y demostrar la seguridad en cada fase.
Por otro lado, debes saber que esta política no solo es una mera recomendación, varias normativas y regulaciones la piden como requisito obligatorio.
| ISO 27001 | PCI DSS | SOC 2 | Ley Fintech de México | Capítulo 20-10 (RAN Chile) | |
|---|---|---|---|---|---|
| Nivel de exigencia | Deseable | Obligatorio | Obligatorio | Obligatorio | Obligatorio |
¿Qué debe contener la política de desarrollo seguro?
1. Responsables
Por un lado, debes definir quiénes serán los responsables de diseñar, aprobar y actualizar la política de desarrollo seguro.
Por otro lado, hay que determinar las áreas o personas serán impactadas para que tengan un claro conocimiento de sus compromisos y responsabilidades en sus tareas diarias.
Veamos un ejemplo de las personas que suelen verse involucradas en una política de desarrollo seguro.
- CTO: su función es ejecutar la estrategia de seguridad en el área TI.
- Comité de seguridad de la información: tiene la función de monitorear, implementar e informar sobre aspectos de seguridad dentro de la empresa.
- Área TI: responsables de cumplir con las disposiciones y requerimientos de seguridad dispuestos en la presente política.
Hackmetrix Insight: es recomendable que todo el equipo técnico que participa en el desarrollo de la aplicación tenga conocimiento de lo descrito en la política de desarrollo seguro, incluidos el Scrum Master, Product Owner y Product Manager. De lo contrario, será necesario que algún DevOps experimentado represente la voz de los temas de seguridad cuando se esté pensando o desarrollando alguna funcionalidad.
2. Lineamientos de desarrollo seguro
Al describir estos lineamientos o mejores prácticas puedes describir a nivel general y luego, en otro documento o en este mismo, puedes describir los procedimientos detallados y técnicos para cada apartado. Estos son algunos de los temas más importantes que debes incluir:
Sobre la metodología de desarrollo seguro
Uno de los pilares del software seguro es incluir a la seguridad en todo el ciclo de vida de desarrollo. Como mencionamos previamente, esto suele hacerse mediante la metodología DevSecOps, ya que te ayuda a desarrollar pensando en las necesidades de seguridad que va a requerir nuestra aplicación y a saber con anticipación si hay que cumplir con algún requerimiento de una norma o regulación.
Habitualmente, las empresas que recién comienzan agregan la seguridad al final del proceso de desarrollo. Sin embargo, esta práctica genera riesgos y una defensa incompleta, debido a que las pruebas persiguen objetivos de calidad o de supresión de bugs.
Ejemplos de lineamientos
- Asegurar que los desarrollos cumplan con lo estipulado en la Metodología de Ciclo de Vida. Recomendamos DevSecOps
- Usar técnicas de programación seguras tanto para nuevos desarrollos, y en caso de reutilización de código, asegurarse que siga las buenas prácticas actuales de OWASP TOP 10.
- Mantener las convenciones dictaminadas para los desarrollos, en particular para los despliegues en distintos ambientes, tales como: errores urgentes directos a producción (también llamados Hotfix) y homologación de ambientes (asegurar que posterior a un Deploy el ambiente Máster quede igual a Producción).
Sobre la documentación técnica
Es necesario documentar información sobre la infraestructura, modelo de base de datos y demás especificaciones técnicas del diseño de la app. Esto permite que los desarrolladores y todo el área de TI pueda identificar con mayor precisión los posibles errores y colaborar con las soluciones.
Ejemplos de lineamientos
- Tener una arquitectura de la aplicación que contemple lineamientos de diseño seguro.
- Diseñar un diagrama de infraestructura para administrar adecuadamente los cambios, mejoras y/o problemas que pudieran surgir en la infraestructura tecnológica.
- Documentar la estructura de la base de datos, sus tablas y los algoritmos de cifrado que se utilizan en ella.
- Tener documentación sobre cómo instalar (herramienta o método de revisión de código) en el IDE del desarrollador para verificaciones de estilos comunes.
- Documentar los resultados y la ejecución de pruebas de seguridad.
- Desarrollo de Servicios y Acciones Masivas
- Desarrollos de FrontEnd
Sobre protección de claves
Las credenciales y claves utilizadas en todo el proceso de desarrollo deben estar resguardadas mediante herramientas o prácticas criptográficas.
Ejemplos de lineamientos
- El almacenamiento de claves está protegida y estas se encuentran hasheadas mediante (ej: BCrypt).
- Los integrantes del equipo deben utilizar un gestor de contraseñas (ej. LastPass).
- Los integrantes del equipo no deben compartir contraseñas, si un miembro del equipo requiere un usuario y/o contraseña para acceder a un servicio, el mismo debe solicitarlo al Jefe de Área, el cual se encargará de darle los accesos solicitados.
Sobre los proveedores externos
En caso de que tu aplicación la desarrolle un tercero hay que detallar lineamientos sobre cómo será la gestión de la seguridad, por ejemplo si se van controlar las licencias y propiedades de código fuente, conocer qué tipo de estándar siguen para evitar vulnerabilidades, etc.
Ejemplos de lineamientos
- En el caso de contar con desarrollo externalizado, convenir con el proveedor los requisitos de desarrollo seguro que podrán ser auditados para evaluar a los proveedores de forma colaborativa.
- Se deben establecer condiciones contractuales por parte del proveedor para desarrollos externalizados, para resguardar la propiedad intelectual de la empresa y asegurar la total confidencialidad de su información y de sus clientes.
Sobre la seguridad de entornos o ambientes
Los ambientes de staging y desarrollo forman parte del ecosistema de trabajo durante la construcción de las aplicaciones. Si estos no están bien protegidos, un atacante tomará la ventaja y podrá escalar hacia los componentes que guardan información valiosa para tu negocio. Por eso, también debes dejar claro cuáles serán las prácticas que van a garantizar su seguridad.
Ejemplos de lineamientos
- Segmentar los ambientes, es decir, contar con ambientes de desarrollo, prueba y producción.
- Garantizar que los ambientes no compartan la misma red, base de datos ni claves.
- El tráfico entrante a los ambientes se restringe mediante firewall de red interna, una firewall de externa y un Web Application Firewall.
- Cualquier ambiente de desarrollo estará protegido con restricción de acceso exclusivo al personal autorizado por la Gerencia de TI.
Hackmetrix Insight: conoce las prácticas básicas de protección de entornos en nuestro artículo sobre cómo proteger tus entornos de desarrollo y staging en 3 pasos.
Sobre la gestión del código:
Estos lineamientos estarán centrados en prevenir y detectar a tiempo cualquier tipo de código malicioso y, además, protegerlo del acceso no autorizado antes, durante y después de su lanzamiento.
Ejemplos de lineamientos
- Contar con repositorios en los cuales se restrinja su acceso, grupo de seguridad en entorno CI/CD. A su vez, se debe asegurar que al código fuente se le aplique:
1. Control y trazabilidad de código.
2. Código salvaguardado y recuperable.
3. Seguimiento a los lineamientos del template de merge donde se incluye: problemas relacionados, descripción del problema, motivo del cambio, capturas de pantalla (si tiene cambios visuales), pasos para probar el correcto funcionamiento de los cambios, checklist con puntos que deben cumplirse.
- Contar con aprobaciones de líderes para el pasaje a producción.
- Manejo de versionamiento de los proyectos de desarrollo.
- Asignar planes de capacitación para que el equipo tenga capacidad y conocimiento para:
1. Conocer y evaluar condiciones de seguridad de los desarrollos.
2. Evitar, detectar y resolver incidentes y vulnerabilidades.
Sobre las herramientas que apoyan la gestión del código:
Hay diferentes herramientas que ayudan a encontrar debilidades y mejoras en la calidad del código, por ejemplo, las de análisis estático (SAST), las de análisis dinámico (DAST) y las híbridas (IASP). Por lo general se utilizan en conjunto ya que se conectan al proceso de desarrollo en diferentes etapas.
Ejemplos de lineamientos
- Contar con un SAST, DAST, IAST según resulte necesario, para obtener comentarios de mejora de calidad de código.
- Instalar un IDS/IPS para detectar accesos no autorizados en los equipos o en las redes de la empresa.
Sobre las pruebas de funcionalidad
Estos lineamientos estarán centrados en asegurar los procesos implicados en las pruebas de usuario o pruebas de validación, así sean manuales como automáticas, ya que forman parte del ciclo de vida de desarrollo del producto.
Ejemplos de lineamientos
- Tener establecidos los criterios de aceptación con condiciones para dar por aprobado o rechazado un desarrollo.
- En todos los casos, sean pruebas unitarias, integrales, UAT (User Acceptance Testing), etc., utilizar credenciales de prueba generadas en el entorno de staging o QA y con dominio de la empresa.
- Las pruebas que requieren de datos son realizadas a través de datos de prueba y no con datos productivos.
Sobre el ethical hacking
El ethical hacking (o pentesting) es un asunto que se suele tratar también en documentos de gestión de vulnerabilidades. Si tienes un documento específico sobre esta gestión que incluye el detalle de los procedimientos para identificar, evaluar y tratar vulnerabilidades, puedes enlazarlo directamente en esta política de desarrollo seguro.
Ejemplos de lineamientos
- Se realizará Ethical Hacking cada [FRECUENCIA], lo que corresponde a [MES/MESES] de cada año.
- Determinar si se realizarán Ethical Hacking sobre las aplicaciones y redes de forma previa o posterior al pasaje a producción como medida preventiva.
Hackmetrix Insight: recuerda que la corrección temprana siempre es menos costosa.
Sobre el diseño seguro
Recientemente, la fundación OWASP publicó una nueva categoría de riesgos comunes en las aplicaciones. Esta nueva categoría se centra en arrojar luz sobre cómo prevenir riesgos relacionados al diseño inseguro y fallas arquitectónicas.
Según OWASP, “el diseño seguro requiere un ciclo de vida de desarrollo seguro, alguna forma de patrón de diseño seguro o biblioteca o herramientas de componentes de carreteras pavimentadas y modelado de amenazas”.
Lineamientos recomendados por OWASP
- Establecer y usar una biblioteca de patrones de diseño seguros o componentes listos para usar.
- Diseñar y usar (o contratar de forma externa) un modelado de amenazas (threat modelling) para la autenticación crítica, el control de acceso, la lógica empresarial y los flujos clave.
- El área de desarrollo y de QA debe escribir pruebas unitarias y pruebas de integración para validar que todos los flujos críticos son resistentes al modelo de amenazas.
Sobre la integridad de los datos
Retomando las nuevas recomendaciones de OWASP, otra nueva categoría es la integridad de los datos.
Generalmente cuando el código y la infraestructura no tienen la seguridad adecuadas, provocan fallas en la integridad del producto y/o de sus datos. Por este motivo, hay que crear lineamientos enfocados a prevenir y eliminar estos puntos vulnerables. Un ejemplo claro es cuando una aplicación está basada en bibliotecas o módulos de fuentes, o repositorios que no son de confianza. También entran en juego las aplicaciones con actualización automática que descargan las actualizaciones sin ser verificadas (y un atacante puede cargar su propias actualizaciones maliciosas para ejecutarlas en todas partes).
Lineamientos recomendados por OWASP
- Verificar que el software o los datos provengan de la fuente esperada mediante la firma o mecanismos similares.
- Asegurar que las bibliotecas y dependencias, como npm o Maven, consuman repositorios confiables.
- Asegurar que los datos serializados no firmados o no cifrados no se envíen a clientes que no sean de confianza sin algún tipo de verificación de integridad o firma digital para detectar alteraciones o reproducción de los datos serializados.
- Asegúrese de que su canalización de CI / CD tenga la configuración y el control de acceso adecuados para garantizar la integridad del código que fluye a través de los procesos de construcción e implementación.
- Utilizar una herramienta de seguridad como OWASP Dependency Check o OWASP CycloneDX, para verificar que los componentes no contengan vulnerabilidades conocidas*
*Hackmetrix Insight: para este último lineamiento puedes apoyarte en lo que vimos en la sección anterior de herramientas que apoyan la gestión del código. Hay herramientas SAST que realizan verificaciones similares al OWASP Dependency Check o al OWASP CycloneDX.
3. Vigencia y versionado
Por último y no menos importante, no olvides incluir un apartado con la fecha de vigencia, para que todo el personal tenga claro desde cuándo regirán estos lineamientos.
En otro apartado, incluye información del versionado para llevar el control de las actualizaciones que se hagan al documento. Puedes incluir, por ejemplo:
- Nombre de la persona que confeccionó la política
- Nombre de la persona que la revisó
- Nombre de la persona o grupo de personas que la aprobaron
- Fecha de última actualización
- Versión del documento
Conclusión
Para adoptar una filosofía de desarrollo seguro es necesario integrar prácticas de seguridad de la información y ciberseguridad a todo el ciclo de vida de desarrollo de software.
Esto permitirá que los equipos piensen “por defecto” en qué fallos o necesidades de seguridad tendrá la aplicación para evitar retrasos en el lanzamiento del producto y facilitar el cumplimiento de requisitos de seguridad de clientes, reguladores o de estándares internacionales como ISO 27001, PCI DSS, SOC 2, RAN 20-10 o la Ley Fintech de México.
Si recién estás comenzando a adoptar prácticas de seguridad, lo recomendable es comenzar por el diseño de una política de desarrollo seguro, ya que te permitirá formalizar las intenciones y aclarar las responsabilidades de todos en este compromiso por construir una aplicación más segura.
Los apartados más importantes que debe contener tu política de desarrollo seguro son:
- Responsables
- Lineamientos de seguridad
- Información sobre la vigencia y el versionado del documento
Si sigues los ejemplos que te dejamos arriba podrás crear tu propia política y dar comienzo a una cultura de desarrollo seguro en tu equipo TI.
Recursos relacionados
