¿Es un requisito la separación de tareas?

Como el libro de O'Reilly, DevOpsSec detalla en el capítulo 2, Separación de tareas (SoD) es un componente importante de los estándares de seguridad de la información: ISO 27001, NIST SP 800-53, COBIT, ITIL, etc. parte de los requisitos reglamentarios para (como mínimo): FFIEC, Sarbanes-Oxley Sección 404, SSAE 16, GLBA, MiFID II y PCI DSS.

Los desarrolladores están de acuerdo en que los entornos de solo lectura, como la Infraestructura inmutable (es decir, el "Movimiento sin SSH") son las mejores prácticas. Incluso verá héroes de desarrolladores como Martin Fowler que prescribe directamente el concepto PhoenixServer, si no el modelo completo ImmutableServer .

Sin embargo, en una organización donde se instilan las Tres Líneas de Defensa (3LoD) (por ejemplo, compañías de servicios financieros o en cualquier lugar que tenga una función de auditoría interna y / o externa), incluso la funcionalidad de solo lectura puede no ser suficiente para cumplir Los requisitos (y pasar una auditoría).

El libro DevOpsSec hace las siguientes recomendaciones más allá de Infutable Infrastructure y SoD (que también recomienda):

• Limite el acceso a datos y configuraciones no públicas.
• Revise el código de registro con cuidado para asegurarse de que los registros no contengan datos confidenciales.
• Audite y revise todo lo que hacen los desarrolladores en producción: cada comando que ejecutan, cada dato que miraron.
• Necesita un control de cambio de detective para rastrear cualquier cambio en Código o configuración realizada fuera de la entrega continua. tubería.
• Es posible que también deba preocuparse por la exfiltración de datos: asegurarse que los desarrolladores no pueden sacar datos del sistema.

Otro control de compensación es Rotation of Duties (RoD), que a menudo va junto con SoD. Si gira a las personas con cierta frecuencia y evita situaciones de colusión, esto puede compensar y respaldar a los otros controles fuertes. Una pieza final sería la integridad de dos partes, en la que un sistema completo de verificación y balance incluye la capacidad de prevenir personas de confianza a través del paradigma "Sin rincones oscuros".

Aquí también hay algunas perspectivas nuevas de Ben Tomhave, un experto de la industria en DevOps y seguridad de aplicaciones - enlace

Como profesional en prácticas de seguridad de la información, estoy de acuerdo con la evaluación de su departamento de seguridad de TI. Seguir las mejores prácticas de seguridad a menudo requiere que las personas comprendan la intención detrás de tales prácticas, en este caso, la adecuada separación de tareas, SoD

Como los desarrolladores en su empresa no parecen estar lo suficientemente motivados / entienden los beneficios de SoD, les explico cómo el beneficio de SoD se beneficiaría a sí mismos. Eche un vistazo a lo que pasó con el OP en este caso. Los desarrolladores razonables deben entender si no tienen acceso a la producción, y suponiendo que los otros 2 elementos de seguridad AAA de autenticación y responsabilidad estén funcionando, no se les puede culpar si un problema surge de su código una vez que se completa el desarrollo.

Los desarrolladores también deben entender que, si bien pueden ser responsables y nunca causar daños maliciosos a los datos financieros / información de la tarjeta de crédito en el entorno de producción al infringir un principio de la CIA, otros desarrolladores pueden no ser tan responsables. Si se produjera un incidente con los datos financieros confidenciales en la producción, puede haber multas significativas para la compañía junto con una reputación dañada que cause la pérdida de ingresos futuros , que se basan en el tamaño de la compañía , puede poner en duda la supervivencia empresarial, impactando directamente la carrera / sustento del desarrollador.

Finalmente, me gustaría ampliar un punto de la excelente respuesta proporcionada por @atdre de que debería tener controles correctivos de respuesta a incidentes para complementar los controles de gestión de cambios detectivos. Si detecta cambios no autorizados realizados en los datos de producción de los programas de monitoreo (por ejemplo, TripWire), debe tener controles de compensación para recuperarse del daño causado (por ejemplo, la utilización de una restauración desde copias de seguridad probadas).