Agencia de Gobierno Electrónico y Sociedad de la Información y del Conocimiento

Nivel 1

• AD.1-1: se cuenta con lineamientos generales para el desarrollo de los sistemas incluyendo principios básicos de la gestión de proyectos.

Nivel 2

• AD.1-2: se incorporan principios de desarrollo seguro en los proyectos de desarrollo de sistemas.
• AD.1-3: se cuenta con mecanismos para el control de versiones y revisión de código.
• AD.1-4: se sistematizan las actividades de prueba, incluyendo casos de prueba orientados a las validaciones de seguridad.

Nivel 3

• AD.1-5: se define un procedimiento documentado de pruebas de seguridad.
• AD.1-6: se definen los criterios de aceptación de los productos desde la perspectiva de seguridad de la información.
• AD.1-7: los desarrollos subcontratados deben cumplir con requisitos mínimos de seguridad establecidos por la organización, independientemente del ciclo de desarrollo utilizado por el proveedor.

Nivel 4

• AD.1-8: se realizan actividades de control interno para determinar el nivel de cumplimiento con la metodología y procedimientos definidos.
• AD.1-9: el resultado de estas actividades se comunica al RSI y demás partes interesadas.
• AD.1-10: se toman acciones correctivas frente a desvíos detectados en los proyectos de desarrollo o adquisición.

Requisitos de seguridad de la información en los proyectos
Dentro de la metodología de gestión de proyectos de sistemas de información, debe contemplarse los requisitos de seguridad de la información, formando parte de la especificación de requisitos para un nuevo sistema o bien modificaciones en los sistemas existentes. Es recomendable establecer los requisitos de seguridad en etapas tempranas para lograr sistemas más eficaces y eficientes.

Criterios de aceptación
Dentro de los criterios de aceptación de productos, se deben incluir los criterios de cumplimiento con requisitos de seguridad de la información de la organización.

Desarrollo seguro
Deben establecerse pautas o lineamientos para el desarrollo seguro donde se defina o se requiera el uso de una metodología de desarrollo de software que tenga como objetivo producir código seguro en forma consistente.
La metodología de desarrollo debe abordar entre otros, los siguientes aspectos:

• Criterios de aceptación de diseño, pruebas y documentación.
• Participación del usuario directamente o mediante algún rol que los represente.
• Plan de pruebas con participación usuaria.
• Controles de seguridad que sean necesarios (por ejemplo, análisis de riesgo de amenazas, revisiones de código, etc.).
• Lineamientos de seguridad de la información en el ciclo de vida del desarrollo de software.
• Lineamientos de codificación para el lenguaje de desarrollo utilizado. En este punto deberán considerarse aspectos como:
  
  - Niveles mínimos de documentación requerida.
  - Requerimientos de prueba obligatorios.
  - Cómo realizar comentarios entre código y cuál sería el estilo de comentarios preferidos.
  - Manejo de excepciones.
  - Método para nombramiento de variables, funciones, clases y tablas.
  - El código fuente debe ser fácil de mantener y legible.

Control de versiones
Se debe contar con mecanismos para el control de versiones y revisión de código, como Git, Subversion, SourceSafe, CVS, ClearCase, entre otros, con el objetivo de restringir el acceso al código fuente y a las bibliotecas relacionadas. Esto previene añadir o modificar contenido sin autorización. El acceso queda limitado exclusivamente a individuos autorizados, asegurando que solo aquellos con necesidades laborales legítimas puedan realizar cambios o consultas. Se establecen reglas específicas para el acceso, con una supervisión detallada de las actualizaciones y accesos al código por parte de los usuarios.

Desarrollo subcontratado
Si el desarrollo se realiza en forma subcontratada, la organización debe acordar con los proveedores el cumplimiento de las normas de desarrollo seguro que se hayan definido.

• Pautas de desarrollo seguro.
• Metodología de gestión de proyectos.
• Metodología de desarrollo que incluya aspectos de seguridad y evidencia de su revisión periódica.
• Lista de proyectos (desarrollado internamente o adquirido a un tercero) durante el período auditado.
• Listado de aplicaciones.
• Especificación de requerimientos para algunos proyectos seleccionados como muestra, donde se incluyan los requerimientos relativos a seguridad de la información.
• Trazabilidad requerimiento – persona de contacto.
• Documentación generada en relación con los proyectos de desarrollo.
• Muestra de versionado de archivos para el período auditado.
• Política de gestión de cambios.
• Procedimiento de gestión de cambios.
• Detalle de la herramienta (si existiera) que asiste en la gestión de los cambios.
• Listado de solicitudes de cambios en el período auditado.
• Documentación de pruebas de seguridad, criterios de aceptación y entregables vinculados a requisitos de seguridad.
• Evidencias de versionado de archivos y control de acceso al repositorio de código fuente.