👉 Esta actividad te ayuda a cumplir los siguientes requisitos:
TSC: Seguridad (Common Criteria): Principio 11 y 14 del Marco COSO, y CC8.1.
TSC: Integridad del Procesamiento: PI1.1 y PI1.2.
¿Para qué me sirve esta actividad? 📚
Esta actividad te ayudará a establecer los lineamientos formales para garantizar que el desarrollo de software en tu organización se realice utilizando las mejores prácticas de seguridad. Esta política es la base para cumplir con el criterio CC8.1, al definir las reglas para un desarrollo seguro, y es crucial para la Integridad del Procesamiento (PI1.2), ya que busca prevenir la introducción de errores en el código que podrían corromper o procesar incorrectamente los datos.
💡 Las prácticas de desarrollo seguro te permiten construir sistemas más robustos y disminuir las vulnerabilidades que pueden poner en riesgo tus servicios y la información de tus clientes.
¿Qué tengo que hacer? 🚀
Antes de comenzar, es altamente recomendable que tu equipo haya realizado la Capacitación de Desarrollo Seguro. Para realizar este documento, te sugerimos considerar los siguientes aspectos clave que un auditor de SOC 2 esperaría ver:
Seguridad en todo el ciclo de vida del desarrollo
La política debe establecer que la seguridad es una consideración en todas las fases del ciclo de vida, no solo al final. Esto incluye:
Diseño: Requerir prácticas como el modelado de amenazas (threat modeling) para identificar posibles riesgos de seguridad desde la fase de diseño.
Desarrollo: Establecer estándares de codificación segura (por ejemplo, seguir las guías de OWASP Top 10), prohibir el uso de datos sensibles en el código (como contraseñas hard-coded) y gestionar de forma segura las librerías y dependencias de terceros.
Pruebas: Definir la obligatoriedad de realizar pruebas de seguridad, como análisis estático de código (SAST) antes de pasar a la siguiente fase.
Segregación y Seguridad de Ambientes
Un control fundamental. La política debe exigir la separación estricta entre los entornos de desarrollo, pruebas (QA) y producción. Esto es vital para:
Evitar que el código en desarrollo impacte los servicios en producción.
Asegurar que los cambios sean probados exhaustivamente en un entorno aislado y controlado antes de su despliegue.
Proteger los datos de producción, prohibiendo su uso en entornos de desarrollo o pruebas.
Pruebas de aceptación y verificación de la integridad
La política debe definir los tipos de pruebas que se deben realizar para autorizar un cambio. Además de las pruebas funcionales, se deben incluir:
Pruebas de aceptación del usuario (UAT): Para asegurar que la funcionalidad cumple con las expectativas del negocio.
Pruebas de aceptación operativa (OAT): Para validar aspectos no funcionales como el rendimiento, la escalabilidad y la seguridad.
Pruebas de integridad del procesamiento: Se deben realizar pruebas específicas para verificar que los cambios no afectan negativamente la exactitud, completitud o validez de los datos procesados. Por ejemplo, si se modifica un algoritmo de cálculo, los resultados deben ser validados contra un conjunto de datos de prueba con resultados conocidos para asegurar que no se introdujeron errores.
Gestión de proveedores de desarrollo
Si utilizas proveedores externos para el desarrollo, la política debe establecer que estos deben cumplir con los mismos estándares de seguridad que tu equipo interno. Sus contratos deben incluir cláusulas específicas de seguridad y desarrollo seguro.
Estas etapas, y todos los pasos a realizar en cada una de ellas lo trabajarás en el documento “Metodología de Ciclo de Vida de Desarrollo”, que se encuentra dentro del plan de acción de Hackmetrix.
Adicional a todos los aspectos previamente mencionados, un desarrollo seguro eficiente debe involucrar una protección contra vulnerabilidades, capacitación periódica a los involucrados en el proceso, y una gestión adecuada de los proyectos, integrando y cumpliendo siempre los requisitos de seguridad pertinentes.
Nuestro template está estructurado con lineamientos para dar cumplimiento, además cuenta con ejemplos y recomendaciones que te servirán para terminar tu política fácil y rápidamente, pero recuerda que debes ajustarlo al contexto de tu empresa 💪🏼.
💡Los pasos a seguir para terminar la actividad dentro de la plataforma son los siguientes:
Una vez que nuestro equipo haya aprobado la actividad, debes subir el documento final en versión PDF (no editable).
Posteriormente, debes subir la evidencia de su aprobación.
Recomendamos que esta evidencia sea a través de una minuta de sesión de comité (en ese caso, debes subir el documento en PDF de la minuta), o con una captura de pantalla de la respuesta explícita de quién o quiénes lo aprobaron.
Esto debe realizarse por algún medio de comunicación interno de la empresa, como Slack, Teams o el correo electrónico organizacional.
Y por último, debes subir la evidencia de su comunicación.
Al igual que la aprobación, la comunicación del documento puede ser por cualquier medio formal interno de la empresa. Y para esto, debes subir una captura de pantalla donde se muestre que el documento fue comunicado a todos los colaboradores interesados.
Recomendaciones ✅
Integra la Seguridad en tus Herramientas (DevSecOps): Más allá de la capacitación, integra herramientas de seguridad directamente en tu pipeline de desarrollo (CI/CD). Los escáneres automáticos de código (SAST) y de dependencias pueden detectar problemas antes de que el código llegue a la fase de pruebas manuales.
Toma nuestra "Capacitación de Desarrollo Seguro": Asegúrate de que tus desarrolladores cuenten con los conocimientos necesarios para ejercer sus funciones y cumplir los requisitos de esta política.
Mantente informado: Las amenazas y las mejores prácticas de desarrollo evolucionan constantemente. Fomenta una cultura de aprendizaje continuo en tu equipo de desarrollo.
¡Califica este artículo 👇, esto nos ayudará a mejorar nuestro contenido para ti! Recuerda que también puedes contactarnos por nuestro chat de soporte y te brindaremos la atención que necesites.