Garantizar la seguridad en el ciclo de vida del software no es opcional cuando trabajas bajo la norma ISO 27001. Desde la adquisición hasta el mantenimiento, cada etapa requiere controles específicos que protejan la información y mantengan la tríada de la seguridad: confidencialidad, integridad y disponibilidad. A continuación se desglosan los lineamientos clave que exige el anexo A en materia de desarrollo seguro.
¿Qué abarca el objetivo de control de adquisición, desarrollo y mantenimiento de sistemas?
Este grupo de controles, el número trece dentro del anexo A, es uno de los más extensos y cubre desde el análisis de requisitos de seguridad hasta las pruebas de aceptación de usuarios [0:42]. Aplica tanto si adquieres software comercial desarrollado por un tercero como si construyes tu propio sistema in-house. La norma no hace distinción: ambos escenarios deben cumplir las mismas directrices de seguridad.
El primer punto fundamental es el análisis de requisitos y especificaciones de seguridad [1:12]. Como oficial de seguridad o líder del equipo de gestión, debes entregar lineamientos claros al área de desarrollo. Lo más importante: tu participación debe iniciar desde el primer requisito de negocio, no cuando el sistema ya está listo para producción. Involucrar al líder de seguridad al final del proyecto es una práctica que la ISO 27001 no permite.
¿Cómo proteger servicios de aplicaciones en redes públicas?
Cuando la arquitectura de una aplicación necesita consumir servicios externos mediante web services o un bus de datos, se deben definir con claridad los mecanismos de seguridad del canal de comunicación [1:52]. A nivel transaccional, cada registro importa, sin importar si operas en el sector financiero o en cualquier otro sector productivo. Las transacciones deben ser eficientes y respetar los principios de seguridad de la información.
¿Por qué es vital la política de desarrollo seguro?
La política de desarrollo seguro es un documento que la norma solicita explícitamente durante una auditoría [2:42]. Funciona como tu línea base: defines los lineamientos, los socializas con el equipo de desarrollo y luego realizas auditorías internas aleatorias para verificar su cumplimiento.
Dentro de esta política se incluye el procedimiento de control de cambios [3:05]. Todo cambio debe quedar documentado dentro de un flujo de información aceptable. No es válido que un área solicite un reporte verbalmente y desarrollo lo ponga en producción sin registro alguno. Debe existir soporte de la solicitud, la construcción y la aprobación del cambio.
¿Qué consideraciones técnicas exige la norma para el entorno de desarrollo?
Las pruebas de estrés y pruebas de carga son necesarias para garantizar que un nuevo sistema no afecte el rendimiento del servidor ni del sistema operativo [3:42]. El área de desarrollo debe optimizar recursos y asegurar que cada componente, incluyendo APIs y DLLs, reciba el mismo nivel de revisión técnica que el sistema principal [4:22].
Los principios de ingeniería de sistemas seguros requieren sensibilizar y capacitar al equipo de desarrollo [4:48ipher]. Un equipo puede ser experto construyendo código en Java, .NET o Python, pero necesita formación específica en seguridad. Si no dominas la herramienta, apóyate en un especialista que combine experiencia técnica con criterios de seguridad.
Respecto a los entornos de desarrollo seguro, es común que estos ambientes tengan permisos excesivamente abiertos [5:24]. El problema surge cuando la aplicación funciona perfectamente en desarrollo, pero falla en producción porque allí los puertos y servicios están restringidos. La recomendación es estandarizar las restric<br>de seguridad entre ambientes para evitar este tipo de incidentes.
¿Qué pasa cuando el desarrollo that lo realiza un tercero?
La externalización del desarrollo no exime del cumplimiento [5:58]. El proveedor seleccionado debe ajustarse a la misthis normatividad. Esto se logra a través de cláusulas contractuales que definan los linea mientos de seguridad e incluyan la posibilidad de realizar auditorías en sitio para verificar que el tercero realmente aplica prácticas de código seguro.
¿Cómo deben gestionarse las pruebas y los datos de prueba?
Las pruebas funcionales de seguridad validan que la aplicación cumpla los requerimientos del usuario sin divulgar información confidencial [6:48]. A su vez, las pruebas de aceptación de usuario (UAT) deben realizarse en un ambiente segregado, lo más parecido posible a producción, nunca en el ambiente de desarrollo [7:12].
Un aspecto crítico es la protección de datos de prueba [7:42]. No puedes entregar una réplica exacta de la base de datos de producción al equipo de desarrollo. El truncamiento de datos es la técnica recomendada: se desfasan los datos para que, por ejemplo, una cédula de cliente se asocie con información de otro registro. Esto mitiga el riesgo de fuga de información y evita que un desarrollador pueda consultar datos reales como saldos de cuenta.
Finalmente, la ISO 27001 se apoya en estándares complementarios para definir el "cómo". Uno de los más relevantes es el OWASP Top Ten [8:48], un estándar de seguridad en desarrollo de software que permite construir listas de chequeo alineadas con los controles del anexo A.
¿Ya aplicas truncamiento de datos en tus ambientes de prueba? Comparte tu experiencia y las prácticas que mejor te han funcionado.
