h--SENA-GD-Guia-Desarrollo-Seguro--1-

Vista previa del material en texto

GTI-G -00X V. 
01 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
GUÍA PARA DESARROLLO SEGURO 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
PROCESO DE GESTION DE TECNOLOGIAS DE LA INFORMACION 
OFICINA DE SISTEMAS 
SERVICIO NACIONAL DE APRENDIZAJE 
 
 
 
 
 
 
 
 
 
 GTI-G -00X V. 
01 
 
Contenido 
1. INTRODUCCIÓN .......................................................................................................................... 3 
2. OBJETIVOS ................................................................................................................................... 3 
3. ALCANCE ..................................................................................................................................... 3 
4. DEFINICIONES ............................................................................................................................. 3 
5. MARCO NORMATIVO ................................................................................................................. 4 
6. DESARROLLO SEGURO DE NUEVAS SOLUCIONES ...................................................................... 4 
6.1 Fase – I. Planificación, Análisis y Diseño ................................................................................ 5 
6.1.1 Administración de autenticación y contraseñas .................................................................... 7 
6.2.1. Requisitos de seguridad ................................................................................................... 10 
6.2.2. Recomendaciones en el desarrollo de sistemas de información .................................... 11 
6.2.3. Practicas en el desarrollo de sistemas de información ................................................... 13 
6.2.4. Aspectos a verificar durante el desarrollo de sistema de información ........................... 14 
6.3. Fase III - Sensibilización ........................................................................................................ 17 
7. BIBLIOGRAFIA. .......................................................................................................................... 19 
 
 
 
 GTI-G -00X V. 
01 
 
1. INTRODUCCIÓN 
 
Este documento describe los lineamientos y parámetros de seguridad que se deben aplicar 
para implementar acciones de desarrollo seguro de las nuevas soluciones de software 
(sistemas, aplicaciones y/o herramientas) del Servicio Nacional de aprendizaje - SENA, para 
ello se apoya en el diligenciamiento de tres listas de chequeo que consolidan los aspectos 
mínimos de seguridad en las tres fases del desarrollo. 
 
2. OBJETIVOS 
 
• Definir las recomendaciones para el desarrollo de software seguro. 
• Definir los formatos a utilizar en el proceso de desarrollo de software para que cumpla 
con los lineamientos mínimos de seguridad. 
 
3. ALCANCE 
 
El documento define las recomendaciones de seguridad en el proceso de desarrollo de 
nuevas soluciones de software (sistema, aplicaciones o herramientas) que se desarrollen al 
interior del Servicio Nacional de Aprendizaje – SENA y a su vez, aplica para los desarrollos 
que sean tercerizados por la Entidad. Además, define las listas de chequeo que acompañan 
la validación de cada fase de desarrollo. 
 
4. DEFINICIONES 
 
• Confidencialidad: Capacidad que garantiza que el software preserva cualquiera de las 
características, activos manejados, ocultos o no accesibles a usuarios no autorizados. 
• Disponibilidad: Capacidad que garantiza que el software es operativo y accesible por 
los usuarios a quien va destinado. 
• Vulnerabilidad: Debilidad de un activo o control que puede ser explotada por una o más 
amenaza. 
• Incidencia: Es toda interrupción o reducción de la calidad no planificada del servicio. 
• Hardware: Conjunto de componentes físicos de un sistema informático. 
• Software: Programas y documentación de apoyo que permiten y facilitan el uso de la 
computadora además de automatizar procesos. El software controla el funcionamiento 
del hardware y el procesamiento de datos. 
 
 GTI-G -00X V. 
01 
• SGSI. Conjunto de políticas de administración de la información. 
 
5. MARCO NORMATIVO 
 
• ISO 27001. Norma internacional emitida por la Organización Internacional de 
Normalización (ISO) y describe cómo gestionar la seguridad de la información en una 
empresa y guía la implantación de un Sistema de Gestión de Seguridad de la 
Información. 
• Ley 1581 de protección de datos personales. 
• Ley 1978 de 2019. Por la cual se moderniza el sector de las tecnologías de la información 
y las comunicaciones (tic), se distribuyen competencias, se crea un regulador único y se 
dictan otras disposiciones 
• Ley 1955 de 2019. Por el cual se expide el Plan Nacional de Desarrollo 2018-2022 "Pacto 
por Colombia, Pacto por la Equidad". 
• Directiva presidencial 2 de 2019 presidencia. Simplificación de la interacción digital 
entre los ciudadanos y el estado. 
• Decreto 1008 de 2018. Por el cual se establecen los lineamientos generales de la política 
de Gobierno Digital y se subroga el capítulo 1 del título 9 de la parte 2 del libro 2 del 
Decreto 1078 de 2015, Decreto Único Reglamentario del sector de Tecnologías de la 
Información y las Comunicaciones. 
• Decreto 1078 de 2015. Por medio del cual se expide el Decreto Único Reglamentario del 
Sector de Tecnologías de la Información y las Comunicaciones. 
 
6. DESARROLLO SEGURO DE NUEVAS SOLUCIONES 
 
El desarrollo de Software Seguro se ha convertido en una de las partes dentro del esquema 
de seguridad de las entidades, para esto implementar controles de seguridad y validación 
de datos en el proceso del ciclo de vida de desarrollo del software, con el objetivo de 
asegurar que los nuevos sistemas de información cuentan con un desarrollo seguro. 
 
Hoy por hoy es fundamental que todo sistema de información se desarrolle considerando 
los controles que puedan abordar posibles ataques que se puedan presentar a causa del 
código fuente, en la etapa de operación y mantenimiento para asegurar la integridad del 
software, para ello a continuación se definen los lineamientos que tienen como objetivo 
cumplir con este tipo de controles. 
 
 
 GTI-G -00X V. 
01 
A continuación, se describen algunas recomendaciones generales para el desarrollo seguro 
de software: 
• Se debe asegurar que los proveedores o terceros que hagan parte de etapas de diseño, 
desarrollo, implementación o mantenimiento de sistemas de información deben firmar 
acuerdos de confidencialidad. 
• Los contratistas y terceros deben seguir estándares, buenas prácticas o modelos de 
madurez de desarrollo seguro. 
• Los activos de información requeridos para el desarrollo de software también deben ser 
entregados al proveedor de la infraestructura, con acta de entrega, custodia y 
responsabilidad sobre los activos. 
• Los riesgos que se encuentren en el ciclo de vida de desarrollo deben quedar 
documentados. 
• Los desarrollos que se realicen en el SENA o contraten con terceros, se debe asegurar 
los derechos de autor y la propiedad intelectual del código fuente de acuerdo a la 
normatividad colombiana. 
• A nivel de Infraestructura y seguridad se debe asegurar ambientes de desarrollo, 
pruebas y producción, teniendo en cuenta que la separación de funciones y ambientes 
lógicos de trabajo, actualizaciones, realización de copias de seguridad, plan de 
recuperación de incidentes, accesos múltiples, conectividad, instalaciones, asistencia a 
los equipos usuarios de ambiente, acuerdos de nivel de servicio y acuerdos con terceros. 
 
 
Para el desarrollo seguro, se plantean las siguientes fases, las cuales deben tener en cuenta 
de manera adicional, las indicaciones que publique el Sistema de Gestión de Seguridad de 
la Información - SGSI del El Servicio Nacional de Aprendizaje - SENA: 
 
• Fase I. Planificación, Análisis y Diseño 
• Fase II. Desarrollo 
• Fase III. Sensibilización 
 
6.1 Fase – I. Planificación, Análisisy Diseño 
 
En esta fase se definen los objetivos y requisitos de seguridad que se requieren 
implementar, los cuales se determinan basados en: 
 
• Arquitectura definida para el sistema de información. 
• Plataforma tecnologica donde operará el sistema. 
• Tipos de datos que se almacenará. 
 
 GTI-G -00X V. 
01 
• Tipos de registro que el sistema debe generar, acceso a los recursos, uso de 
privilegios, perfiles de usuario. 
• Tipos de acceso a los datos deben ser estructurados de acuerdo a los perfiles 
definidos, lectura, escritura, modificación y eliminación. 
• Modo de autenticación al ingreso del aplicativo por usuario y contraseñas y demás 
elementos de seguridad para ingreso. 
 
En esta fase es necesario identificar los posibles riesgos que puedan afectar el desarrollo de 
la nueva solución, entre los cuales se debe contemplar: 
• Definición de tiempos que no están acorde al alcance del proyecto 
• Reuniones donde no se definen claramente el alcance del proyecto 
• Mala definición de la información confidencial y pública 
• No identificar claramente los roles y permisos 
• Priorización errónea de las actividades a realizar por cada uno de los 
desarrolladores. 
• Requerimientos de desarrollo que no son claros 
• Mala documentación de requerimientos 
• Trazabilidad y priorización de los requerimientos ambiguos 
• Falta de documentación 
• Falta de comunicación con los líderes del proyecto 
• Baja disponibilidad por parte de los líderes del proyecto 
 
Posterior a este detalle, se debe desarrollar una lista de chequeo para asegurar los 
parámetros de desarrollo seguro, la cual se encuentra definida como lista de chequeo Fase 
I y se presenta a continuación: 
 
 
Tabla 6.1-1: lista de Chequeo desarrollo seguro Fase I. 
Lista de chequeo Fase I 
Nombre del Proyecto: 
Responsable del Proyecto: Sistema: 
CONFIDENCIALIDAD SI NO N.A 
1 ¿El aplicativo tiene páginas clasificadas privadas? 
2 
¿El aplicativo requiere autenticación para todos los recursos y páginas excepto aquellas 
específicamente clasificadas como públicas? 
 
3 ¿Se definieron cuáles de los datos que almacenará el aplicativo son privados y cuáles públicos? 
4 ¿Se definieron los tipos de registro que debe generar el sistema? 
 
 GTI-G -00X V. 
01 
5 ¿Se definieron los accesos a los recursos del sistema? 
6 ¿Se definieron los perfiles de usuario con sus respectivos permisos? 
7 ¿Se definió el modo de autenticación al ingreso del aplicativo? 
INTEGRIDAD SI NO N.A 
8 
¿Se valida todos los datos brindados por el usuario antes de procesarlos, incluyendo todos los 
parámetros, URLs y contenidos de cabeceras HTTP (por ejemplo, nombres de Cookies y 
valores)? 
 
9 
¿Se contempló no difundir información sensible en respuestas de error, incluyendo detalles 
del sistema, identificadores de sesión o información de la cuenta? 
 
10 ¿Se contempló controles para administración de sesiones? 
11 
¿Se contempló que la función de logout debe terminar completamente con la sesión o 
conexión asociada y debe estar disponible en todas las páginas protegidas por autenticación? 
 
12 
¿Se contempló el uso de registro de log’s y que los datos del registro de log contengan 
información importante? 
 
13 ¿Se contempló registrar en un log todas las fallas en los controles de acceso? 
14 
¿Se contempló no guardar información sensible en logs, incluyendo detalles innecesarios del 
sistema? 
 
15 ¿Se contempló asegurar que existan mecanismos para conducir un análisis de los logs? 
16 ¿Se definió las acciones a tomar si no se pueden registrar logs? 
17 
¿Se contempló que el ambiente de desarrollo y pruebas sea configurado con la misma 
seguridad que el ambiente de producción? 
 
18 
¿Se contempló no habilitar funcionalidades de completar automáticamente en aquellos 
formularios que contienen información sensible, incluyendo la autenticación? 
 
19 
Se contempló la funcionalidad de captchas (verificar que el usuario que está accediendo a 
determinados datos es un humano y no una máquina) 
 
DISPONIBILIDAD SI NO N.A 
20 ¿Se contempló el lugar de almacenamiento de los logs? 
21 ¿Se contemplaron los riegos del proyecto en esta etapa? 
22 ¿Se contemplaron acciones para minimizar los riesgos del proyecto? 
23 Concepto: 
Fuente: elaboración Ministerio de Salud y Protección Social 
 
6.1.1 Administración de autenticación y contraseñas 
 
En esta sesión, se realizan las recomendaciones a tener presente para la administración y 
autenticación de contraseñas, considerando lo siguiente: 
 
 GTI-G -00X V. 
01 
 
• Si los usuarios requieren realizar algún tipo de transacción, se debe requerir 
autenticación para el acceso a estas funcionalidades 
• Todos los controles de autenticación deben ser efectuados en un sistema en el cual 
se confíe. 
• Se deben establecer y utilizar servicios de autenticación estándares y probados. 
• Utilizar una implementación centralizada para todos los controles de autenticación, 
incluyendo librerías que llamen a servicios externos de autenticación. 
• Todos los controles de autenticación deben fallar de una forma segura. En caso de 
error u excepción el portal o sitio web no deberá proveer información relacionada 
con información de autenticación del usuario. 
• Si la aplicación administra un almacenamiento de credenciales, se debe asegurar 
que únicamente se almacena el hash con sal (salty hash) de las contraseñas y que el 
archivo/tabla que guarda las contraseñas y claves solo puede ser escrito por la 
aplicación (si es posible, no utilizar el algoritmo de hash MD5). 
• El hash de las contraseñas debe ser implementado en un sistema en el cual se confíe. 
• Validar los datos de autenticación únicamente luego de haber completado todos los 
datos de entrada, especialmente en implementaciones de autenticación secuencial. 
• Las respuestas a los fallos en la autenticación no deben indicar cual parte de la 
autenticación fue incorrecta. Como modo de ejemplo, en lugar de “usuario inválido” 
o “contraseña inválida”, utilizar “usuario y/o contraseña inválidos” en ambos casos. 
Las repuestas a los errores deben ser idénticas tanto a nivel de lo desplegado como 
a nivel de código fuente. 
• Utilizar autenticación para conexiones a sistemas externos que involucren 
información o funciones sensibles. 
• Las credenciales de autenticación para acceder a servicios externos a la aplicación 
deben ser cifradas y almacenadas en ubicaciones protegidas en un sistema en el cual 
se confíe. El código fuente NO es una ubicación segura. 
• Utilizar únicamente solicitudes del tipo HTTP POST para la transmisión de 
credenciales de autenticación. 
• Utilizar únicamente conexiones o datos cifrados para el envío de contraseñas que 
no sean temporales; en algunos casos, en envío de la contraseña de acceso puede 
requerir la solicitud de un dato que conozca el cliente “cédula”. Contraseñas 
temporales como aquellas asociadas con reset por correo electrónico, pueden ser 
una excepción. 
• No se debe desplegar en la pantalla la contraseña ingresada. A modo de ejemplo, en 
formularios web, utilizar el tipo de entrada “password”. 
 
 GTI-G -00X V. 
01 
• Deshabilitar las cuentas luego de un número establecido de intentos errados de 
ingreso al sistema. Un número ideal para el bloqueo de la cuenta son tres intentos 
fallidos. 
• El cambio y reinicio de contraseñas requieren los mismos niveles de control como 
aquellos asociados a la creación y autenticación de cuentas. 
• Las preguntas para el reinicio de contraseñas deben contemplar un amplio rango de 
respuestas aleatorias. 
• Si se utiliza un reinicio por correo electrónico, únicamente enviar un link o 
contraseñas temporales a cuentas previamente registradas en el sistema. 
• Las contraseñas y links temporales deben tener un periodo de validezcorto. 
• Forzar el cambio de contraseñas temporales luego de su utilización. 
• Notificar a los usuarios cada vez que se produce un reinicio de la contraseña. 
• Prevenir la reutilización de contraseñas. 
• Deshabilitar la funcionalidad de “recordar” para los campos de contraseñas, 
“Autocomplete”. 
• El último acceso (fallido o exitoso) debe ser reportado al usuario en su siguiente 
acceso exitoso. 
• Implementar un monitoreo para identificar ataques a múltiples cuentas utilizando 
la misma contraseña. Este tipo de ataques debe quedar registrado en los logs que 
maneja el portal o sitio web. 
• Reautenticar usuarios antes de la realización de operaciones críticas. 
• Utilizar autenticación multi-factor para las cuentas más sensibles o de mayor valor. 
• Utilizar los controles del servidor o del framework para la administración de 
sesiones. La aplicación solo debe reconocer estos identificadores como válidos. 
• La creación de identificadores de sesión solo debe ser realizada en un sistema en 
cual se confíe (por ejemplo: el servidor). 
• Se debe considerar ataques de tipo “Cookie Replay”. El Portal, para las zonas en las 
cuales se requiera autenticación del cliente, debe permitir el control de los 
identificadores de sesión “session_ID”. No deberá ser posible tener dos sesiones 
simultáneas con el mismo “session_ID”, para cuyo caso las dos sesiones deberán ser 
cerradas. 
• Los controles de administración de sesiones deben utilizar algoritmos que generen 
identificadores suficientemente aleatorios. 
• Definir el dominio y ruta para las cookies que contienen identificadores de sesión 
autenticados con un valor apropiadamente estricto para el sitio. 
 
 
6.1.2. Política de Contraseñas. 
 
 GTI-G -00X V. 
01 
 
Las contraseñas de los usuarios de los sistemas de información, deben contemplar las 
siguientes reglas: 
 
• Estar formada por al menos 8 caracteres. 
• Contener caracteres al menos dos de las siguientes tres clases de caracteres: 
o Alfabéticos 
o Numéricos 
o Caracteres especiales y de puntuación 
• La contraseña de los aplicativos deberá forzarse el cambio al menos una vez cada año. 
• Los aplicativos nunca deben solicitar ni revelar contraseñas por correo electrónico. 
• Se debe habilitar una opción para el cambio de su contraseña de forma segura. 
• Se debe disponer la posibilidad en los aplicativos de “He olvidado mi contraseña” para 
que el usuario pueda obtenerla de forma automática en caso de olvido. 
 
Se deben, impartir las siguientes indicaciones a los usuarios al entregarles las contraseñas : 
 
• Se recomienda cambiar la contraseña en el primer momento de acceder a la cuenta, 
para que la nueva contraseña sea distinta a la que va en la solicitud. 
• No escribir nunca las contraseñas o almacenarlas en algún fichero. 
• Las contraseñas deben ser suficientemente largas y fáciles de recordar. Para ello 
recomendar crear la contraseña a partir de una frase que resulte fácil de reproducir, con 
ejemplos fáciles de entender. 
• La contraseña no se debe revelar a nadie, ni directamente, ni por teléfono, ni en 
respuesta a mensajes de correo electrónico en las que se le solicite. 
• Las contraseñas se deben almacenar encriptadas en las bases de datos. Y este algoritmo 
debe ser seguro. 
 
 
6.2. Fase II – Desarrollo y Despliegue 
 
A continuación, se describen los requisitos de seguridad, las recomendaciones y practicas 
asociadas a la Fase II. 
 
6.2.1. Requisitos de seguridad 
 
 
 GTI-G -00X V. 
01 
Se debe tener en cuenta los siguientes aspectos antes de dar inicio al desarrollo de los 
sistemas de información: 
 
• Se debe contar con ambiente de producción, pruebas y desarrollo y estos deben ser 
independientes. Estos ambientes deben ser lo más similar posible, a efectos de 
prevenir situaciones en las cuales el software desarrollado presente 
comportamientos distintos y errores en el ambiente de pruebas y producción. 
• Los desarrolladores deben realizar su trabajo exclusivamente en ambiente de 
desarrollo, nunca en otros ambientes. 
• Los nombres de dominio para los ambientes de producción, preproducción y 
desarrollo deben ser diferentes a efectos de evitar confusión durante la ejecución 
de las pruebas, puesta en producción y desarrollo. 
• Es necesarios que se tenga instalado el mismo manejador de base de datos y versión 
en los ambientes de prueba y producción. Si esto no es posible, usar herramientas 
automatizadas de propagación de una base de datos a otros. 
• Se debe contemplar incluir réplicas de todos los componentes con los cuales el 
software tendrá interoperación en producción incluyendo: otras aplicaciones cliente 
servidor, bases de datos relacionales, componentes middleware, interfaces, 
demonios (daemons), procesos personalizados, utilidades FTP. 
 
6.2.2. Recomendaciones en el desarrollo de sistemas de información 
 
Se deben seguir las siguientes recomendaciones: 
 
• Autentificar adecuadamente la información confidencial y los sistemas informáticos 
sólo deben ser accesibles por las personas con los roles y permisos definidos en la 
fase I. 
• No utilizar campos ocultos para almacenar información sensible, porque esto 
permitiría que se exponga datos e información del funcionamiento interno de los 
aplicativos, permitiendo que sean manipulados 
• En caso de que se requiera hacer uso de campos ocultos encamínelos a que la 
información contenida no sea confidencial o sensible, y si fuera necesario utilizar 
información sensible o confidencial esta debe utilizar mecanismos de cifrado con el 
fin de que se garantice su integridad. 
• Comprobar las entradas: Es necesario que se verifique y controle los datos que son 
introducidos en los aplicativos, estos deben estar dentro del rango de valores 
definidos, es decir si son de tipo numérico que lo sean y que no sobrepasen la 
longitud determinada, sobre todo en los que son tipo cadena. 
 
 GTI-G -00X V. 
01 
• Valores límite de salida: Aquí se debe controlar la salida de los métodos, que el dato 
resultante de una operación esté dentro de los parámetros definidos antes de 
asignarlo. 
• Formato de salida: Los formatos de salida no deben ser cambiados por funciones 
debido a que estos pueden ocasionar errores en el buffer. 
• Validar los argumentos que se pasan a un componente en otro ámbito de control 
con el fin de que no se introduzcan argumentos alternativos, utilizando la misma 
codificación de caracteres, validando los datos resultantes de una combinación de 
datos de diferentes fuentes, ya que los datos individuales pueden haber pasado la 
validación, pero violar las restricciones una vez hayan sido combinados 
• Asegurar que los métodos que llevan a cabo controles de seguridad sean declarados 
como privados o finales, prohibiendo la extensión de los mismos ya que las clases 
no finales pueden verse comprometidas si una subclase maliciosa reemplaza los 
métodos y omite las comprobaciones. 
• Se debe proteger la información que se muestra sobre los procesos activos ya que 
muchos sistemas operativos permiten a un usuario observar la información de 
procesos que pertenecen a otros usuarios. 
• Esta información puede incluir argumentos de línea de comandos o la configuración 
de la variable de entorno, lo que puede provocar un ataque contra el software por 
parte de otros usuarios si entre esos datos se incluye información confidencial. 
• Se debe evitar el uso de datos reales de carácter personal en las pruebas anteriores 
a la implantación o modificación de un sistema, salvo que se garantice el nivel de 
seguridad correspondiente al tipo de información tratada. 
• Se debe evitar exponer al usuario alguna referencia directa a un objeto de la 
aplicación, como un archivo, directorio, base de datos, o clave, como un parámetro 
del URL o dentro de un formulario, es decir se debe utilizar mapas de referencias 
indirectas para referencias objetos del servidor,empleando contraseñas que 
garanticen que el usuario que intenta acceder al recurso dispone de los permisos 
suficientes, así como evitar la publicación directa de recursos a través del acceso 
directo mediante una URL que pueda ser predicha. 
• Evitar generar código con valores ingresados por el usuario. 
• Reemplazar sentencias SQL dinámicas por Stored Procedures. 
• Controlar que los datos de salida sean adecuados, es decir, que cumplan con lo 
solicitado en los requerimientos, como por ejemplo que el valor obtenido se 
encuentre dentro de los parámetros definidos. Si esta acción no se tiene en cuenta 
puede hacer que la funcionalidad desarrollada falle o regrese un resultado que no 
corresponda, así como permitiendo que el aplicativo no realice las acciones 
requeridas. 
 
 GTI-G -00X V. 
01 
 
6.2.3. Practicas en el desarrollo de sistemas de información 
 
En el este ítem se describen las buenas practicas a nivel de desarrollo: 
• Emplear nombres descriptivos, en la declaración de variables, es decir, que hagan 
alusión a su nombre y no a su tipo. 
• Evitar el uso de variables Globales, dado que se puede acceder a estas variables por 
terceras funciones ya sea por malicia o por infortunio asignando un valor no 
deseado, este tipo de variables puede ser accesado por muchas funciones a lo largo 
del programa siendo muy difícil de detectar las fallas que genera. 
• Inicializar siempre las variables. 
• La aplicación deberá generar y almacenar un log de auditoria sobre las tablas y 
transacciones críticas, que permita consultar como mínimo: ID de usuario, fecha, 
hora, nombre de la máquina donde ejecutó la aplicación, dirección IP, MAC, tabla 
modificada, acción ejecutada (creación, modificación, borrado). Si el volumen de 
datos y la carga transaccional de la aplicación no es muy elevada es aconsejable 
registrar los valores anteriores y actuales. 
• Los comentarios que contenga el código fuente deben ir enfocados a describir la 
funcionalidad que se está programando, en los bloques de código extenso es 
recomendable dividirlos e introducir un comentario al principio con el fin de guiar al 
desarrollador, sería óptimo que exista una línea blanca de separación, estos 
comentarios no deben ser excesivos, es decir describiendo lo obvio. 
• Reutilización de Código Fuente: En lo posible se recomienda la reutilización de 
código fuente, ya que la no reutilización de código induce a errores cada vez que se 
desarrolla un nuevo componente de la solución. En caso de requerir funciones de 
seguridad específicas es recomendable hacer uso de librerías y/o piezas de código 
ya construidas para tal fin, con el fin de aprovechar la experiencia de los 
desarrolladores especializados en estas áreas. 
• No excederse con el número de niveles en las instrucciones anidadas. 
• No mezclar datos con código. 
• Evitar usar métodos con muchos parámetros, en caso de que sea necesario es 
recomendable contemplar la creación de una clase que contenga las propiedades 
requeridas. 
• No hacer comparaciones explícitas con expresiones booleanas con true o false, es 
mejor asignar la condición a una variable y utilizar la variable en las comparaciones, 
nombre las variables de forma afirmativa. 
 
 GTI-G -00X V. 
01 
• Se debe considerar la validación de todos los parámetros de las interfaces de 
programación de aplicaciones (API) exportadas, verificando que sean válidos, esto 
incluye los datos que parecen ser coherentes pero que están más allá del intervalo 
de valores aceptado, como los tamaños de búfer excesivos. No utilice aserciones 
para comprobar los parámetros de las API exportadas, porque las aserciones se 
quitarán en la versión de lanzamiento. 
• Se debe considerar emplear las API criptográficas por firmas reconocidas (IBM, 
Microsoft, entre otros.), en lugar de escribir a su propio software criptográfico, con 
ello los desarrolladores podrán concentrarse en la generación de aplicaciones. 
• Cuando una funcionalidad se requiera implementar en diferentes aplicaciones se 
recomienda crear una función, una rutina, un servicio o un componente que sea 
reutilizable para cualquier aplicación. 
 
6.2.4. Aspectos a verificar durante el desarrollo de sistema de información 
 
Es importante verificar los siguientes aspectos durante la fase de desarrollo de las nuevas 
soluciones: 
 
• Las pruebas iniciales se deben realizar a partir de los requerimientos definidos y 
aprobados. 
• Las pruebas funcionales de acuerdo a las funcionalidades solicitadas deben buscar 
descartar errores que se presenten al utilizar el aplicativo o el módulo desarrollado. 
• En caso de que el requerimiento provenga de un mantenimiento es necesario 
verificar todas las funcionalidades del sistema que se puedan afectar por la 
integración de la nueva funcionalidad. 
• También es necesario probar el nivel de acceso al aplicativo, con el fin de valorar 
que únicamente accedan los usuarios autorizados y sólo a los módulos definidos de 
acuerdo a su rol. 
• Las pruebas de seguridad funcional se deben basar en los requerimientos definidos 
con respecto a: 
o Autenticación solicitada, complejidad de contraseñas basada en la política 
definida en este documento y restricciones de acceso según lo diseñado en roles 
y permisos. 
o Bloqueo automático de cuentas de acceso. 
o Funcionalidad de captchas (verificar que el usuario que está accediendo a 
determinados datos es un humano y no una máquina). 
o Lo registrado en los logs, así como su almacenamiento. 
o Los mensajes de error que se deben presentar en las acciones validadas. 
 
 GTI-G -00X V. 
01 
o En la preparación de datos para pruebas, estos preferiblemente no deben ser 
reales; sin embargo, teniendo en cuenta que para algunas pruebas puede ser 
una tarea compleja la preparación manual de datos y que puede ser ineficiente 
debido a la integridad 
 
Con relación a esta información, se aplica la lista de chequeo de la fase II, presentada a 
continuación. 
 
 
Tabla 6.2.4-1: lista de Chequeo desarrollo seguro Fase II. 
 
 GTI-G -00X V. 
01 
Lista de chequeo Fase II 
Nombre del Proyecto: 
Responsable del Proyecto: Sistema: 
ID CONFIDENCIALIDAD SI NO N.A 
1 ¿Se implementaron las páginas que fueron definidas como clasificadas privadas? 
2 ¿Se implementó la autenticación para todos los recursos y páginas definidas excepto 
aquellas que específicamente fueron clasificadas como públicas? 
 
3 
4 
¿Los datos almacenados definidos como privados cuentan con las restricciones 
correspondientes? 
5 ¿Se implementaron los tipos de registro que debe generar el sistema? 
6 
¿Fueron implementados los accesos a los recursos del sistema, con base en los 
requerimientos? 
7 ¿Se implementaron los perfiles de usuario con sus respectivos permisos, con base en los 
requerimientos? 
8 
¿Se firmaron y verificaron los acuerdos de confidencialidad para los intervinientes del 
proyecto? 
9 ¿Fueron implementadas y tenidas en cuenta todas políticas establecidas en el Ministerio? 
INTEGRIDAD SI NO N.A 
10 
¿Se verificó que el ambiente de desarrollo y pruebas esté configurado con la misma 
seguridad que el ambiente? 
 
11 ¿Se validaron todos los datos brindados por el usuario antes de incluirlos en el aplicativo? 
12 
¿Se realizaron pruebas para validar que los mensajes de error no difundan información 
sensible ni detalles del sistema, identificadores de sesión o información de la cuenta? 
 
13 ¿Se implementó el control de sesiones? 
14 
¿Se realizaron pruebas para validar la función de logout que termine completamente con la 
sesión o conexión asociada y estar disponible en todas las páginas definidas que deberían 
ser protegidas por autenticación? 
15 ¿Se implementó los eventos definidos para el log con sus distintos niveles de logging? 
16 
¿En las pruebas se verificó que el registro del logtenga todas las fallas en los controles de 
acceso? 
17 
¿En las pruebas se verificó que no se guarde información sensible, ni detalles innecesarios 
del sistema? 
18 ¿Se validaron que las acciones definidas cuando no se registre información en el log 
funcionen? 
19 ¿Se definió las acciones a tomar si no se pueden registrar logs? 
20 
¿Las pruebas realizadas verificaron que no exista la funcionalidad de completar 
automáticamente en los formularios que contienen información sensible, incluyendo la 
autenticación? 
21 ¿Se validó la funcionalidad captchas? 
22 ¿Se cumple con la política de contraseñas definida? 
 
 GTI-G -00X V. 
01 
23 
¿Los desarrolladores sólo realizaron su trabajo en el ambiente de desarrollo, nunca en 
otros ambientes directamente? 
24 ¿Los nombres de dominio para los ambientes de producción, pruebas y desarrollo, son 
diferentes? 
25 ¿Para las pruebas se utilizó datos que no eran reales o anonimizados? 
26 
¿En general las pruebas realizadas contemplaron los lineamientos de seguridad estipulados 
en el presente documento? 
 
DISPONIBILIDAD SI NO N.A 
27 ¿Se contó con el ambiente de desarrollo? 
28 ¿Se contó con el ambiente de pruebas? 
29 
¿La seguridad de los ambientes de desarrollo y pruebas tenían el mismo nivel de seguridad 
que el de producción? 
 
30 ¿Se verificó el almacenamiento de los logs? 
31 ¿Se implementaron las acciones para minimizar los riesgos? 
32 
¿Se solicitaron los permisos para el acceso a los ambientes de acuerdo al perfil de cada 
persona? 
33 ¿Fueron asignados los permisos de acceso a los ambientes de acuerdo a lo solicitado? 
Fuente: elaboración Ministerio de Salud y Protección Social 
 
6.3. Fase III - Sensibilización 
 
En esta fase se contemplan las actividades de la guía de uso y apropiación, realizar la puesta 
en producción del Sistema de Información o Mantenimiento de Software, según el 
procedimiento de servicios tecnológicos. 
 
En la sensibilización o transferencia de conocimiento y en la puesta en producción se debe 
contemplar las políticas de seguridad de la información, la importancia del buen uso del 
aplicativo, así como la confidencialidad que maneja el aplicativo, como las restricciones, 
roles y perfiles, manejos de usuarios y contraseñas con los que va a contar el aplicativo. 
 
Con relación a esta información se aplica la lista de chequeo de la fase III. 
 
 
 GTI-G -00X V. 
01 
Lista de chequeo Fase III 
Nombre del Proyecto: 
Responsable del Proyecto: Sistema: 
CONFIDENCIALIDAD SI NO N.A. 
1 
¿Se implementó el mínimo privilegio y/o la restricción del acceso de usuarios solamente a la 
funcionalidad desarrollada del aplicativo? 
 
 
 
 
 
 
2 
¿Se verificó que el aplicativo o funcionalidad desarrollada no contenga comentarios en el 
código de producción que sea accesible por el usuario que puedan revelar información 
sensible? 
 
 
 
 
 
 
3 
¿La sensibilización del aplicativo o funcionalidad desarrollada se enfocó en las políticas de 
seguridad de la información planteadas en el Ministerio, haciendo énfasis en la 
confidencialidad que contempla el aplicativo o funcionalidad? 
 
 
 
 
 
 
 
 
4 
¿Se libere adecuadamente la memoria previa a la salida de una función y de todos los puntos 
de finalización de la aplicación? 
 
 
 
 
 
 
INTEGRIDAD SI NO N.A. 
5 
¿Se removió el código de testeo o cualquier funcionalidad que no sea tenida en cuenta en 
producción, previo a realizar la puesta en producción? 
 
 
 
 
 
 
6 ¿Se contempló el uso de APIs previstas para el acceso a funciones específicas? 
7 
¿Los mantenimientos o incidencias presentadas antes de ser implementadas contemplaron 
los lineamientos de seguridad? 
 
 
 
 
 
 
8 
¿Se revisaron los controles y los procedimientos existentes con respecto a la integridad para 
garantizar que no serán comprometidos por los cambios solicitados en los mantenimientos o 
incidentes presentados? 
 
 
 
 
 
 
9 
¿Se realizan pruebas a los incidentes o mantenimientos presentados para validar que no 
afecten los requisitos de seguridad de la información para otros aplicativos o 
funcionalidades? 
 
 
 
 
 
 
DISPONIBILIDAD SI NO N.A. 
10 
¿Los aplicativos Misionales o funcionalidades nuevas publicados en el ambiente de 
producción contemplan los mecanismos de seguridad en cuanto a prevención, detección y 
recuperación? 
 
 
 
 
 
 
11 
¿La solución aplicada o el desarrollo realizado por causa de un incidente o mantenimiento 
respectivamente se encuentran debidamente registrados en el formato pertinente, así como 
la examinación de los requisitos de seguridad que debe contemplar o se vieron afectados? 
 
 
 
 
 
 
 
 
 
12 Concepto: 
Fuente: elaboración Ministerio de Salud y Protección Social 
 
 
 
 
 GTI-G -00X V. 
01 
7. BIBLIOGRAFIA. 
 
Ministerio de las Tecnologías de la Información, M. (2018). Manual de Gobierno Digital. 
Bogotá: Dirección de Gobierno Digital. 
MINTIC. (2014). G.SIS.01 Guía del dominio de Sistemas de Información . Bogotá. 
MINTIC. (2017). Qué es el marco de referencia para la gestiión de TI. En MINTIC, G.GEN.01 
Generalidades del Marco de (pág. 12). Bgotá: MINTIC. 
MinTIC. (15 de 09 de 2019). Marco de Referencia. Obtenido de 
https://www.mintic.gov.co/arquitecturati/630/w3-propertyvalue-8114.html 
MinTIC. (20 de 09 de 2019). Plan de Gobierno Digital. Obtenido de 
https://estrategia.gobiernoenlinea.gov.co/623/articles-81473_recurso_1.pdf 
MINTIC, M. (18 de Septiembre de 2019). IT4+. Obtenido de 
https://www.mintic.gov.co/gestion-ti/Gestion-IT4+ 
MINTIC, M. (18 de Septiembre de 2019). Marco de referencia de la arquitectura 
empresarial del Estado Colombiano. Obtenido de 
https://www.mintic.gov.co/arquitecturati/630/w3-channel.html 
Ministerio De Salud Y Protección Social. (Octubre 2018). Lineamientos de Desarrollo 
Seguro de Software. Obtenido de 
https://www.minsalud.gov.co/Ministerio/Institucional/Procesos%20y%20procedi
mientos/CVSS01.pdf 
 
 
 
https://www.mintic.gov.co/arquitecturati/630/w3-channel.html
https://www.minsalud.gov.co/Ministerio/Institucional/Procesos%20y%20procedimientos/CVSS01.pdf
https://www.minsalud.gov.co/Ministerio/Institucional/Procesos%20y%20procedimientos/CVSS01.pdf