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álisis y 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?
¿El aplicativo requiere autenticación para todos los recursos y páginas excepto aquellas
2
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
¿Se valida todos los datos brindados por el usuario antes de procesarlos, incluyendo todos los
8 parámetros, URLs y contenidos de cabeceras HTTP (por ejemplo, nombres de Cookies y
valores)?
¿Se contempló no difundir información sensible en respuestas de error, incluyendo detalles
9
del sistema, identificadores de sesión o información de la cuenta?
10 ¿Se contempló controles para administración de sesiones?
¿Se contempló que la función de logout debe terminar completamente con la sesión o
11
conexión asociada y debe estar disponible en todas las páginas protegidas por autenticación?
¿Se contempló el uso de registro de log’s y que los datos del registro de log contengan
12
información importante?
13 ¿Se contempló registrar en un log todas las fallas en los controles de acceso?
¿Se contempló no guardar información sensible en logs, incluyendo detalles innecesarios del
14
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?
¿Se contempló que el ambiente de desarrollo y pruebas sea configurado con la misma
17
seguridad que el ambiente de producción?
¿Se contempló no habilitar funcionalidades de completar automáticamente en aquellos
18
formularios que contienen información sensible, incluyendo la autenticación?
Se contempló la funcionalidad de captchas (verificar que el usuario que está accediendo a
19
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 validez corto.
• 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
3 aquellas que específicamente fueron clasificadas como públicas?
¿Los datos almacenados definidos como privados cuentan con las restricciones
4
correspondientes?
5 ¿Se implementaron los tipos de registro que debe generar el sistema?
¿Fueron implementados los accesos a los recursos del sistema, con base en los
6
requerimientos?

7 ¿Se implementaron los perfiles de usuario con sus respectivos permisos, con base en los
requerimientos?
¿Se firmaron y verificaron los acuerdos de confidencialidad para los intervinientes del
8
proyecto?
9 ¿Fueron implementadas y tenidas en cuenta todas políticas establecidas en el Ministerio?
INTEGRIDAD SI NO N.A

¿Se verificó que el ambiente de desarrollo y pruebas esté configurado con la misma
10
seguridad que el ambiente?

11 ¿Se validaron todos los datos brindados por el usuario antes de incluirlos en el aplicativo?

¿Se realizaron pruebas para validar que los mensajes de error no difundan información
12
sensible ni detalles del sistema, identificadores de sesión o información de la cuenta?

13 ¿Se implementó el control de sesiones?

¿Se realizaron pruebas para validar la función de logout que termine completamente con la
14
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?
¿En las pruebas se verificó que el registro del log tenga todas las fallas en los controles de
16
acceso?
¿En las pruebas se verificó que no se guarde información sensible, ni detalles innecesarios
17
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?
¿Las pruebas realizadas verificaron que no exista la funcionalidad de completar
20 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
 ¿Los desarrolladores sólo realizaron su trabajo en el ambiente de desarrollo, nunca en
23
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?

¿En general las pruebas realizadas contemplaron los lineamientos de seguridad estipulados
26
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?
¿La seguridad de los ambientes de desarrollo y pruebas tenían el mismo nivel de seguridad
29
que el de producción?
30 ¿Se verificó el almacenamiento de los logs?
31 ¿Se implementaron las acciones para minimizar los riesgos?
¿Se solicitaron los permisos para el acceso a los ambientes de acuerdo al perfil de cada
32
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.
¿Se implementó el mínimo privilegio y/o la restricción del acceso de usuarios solamente a la
1
funcionalidad desarrollada del aplicativo?

¿Se verificó que el aplicativo o funcionalidad desarrollada no contenga comentarios en el

2 código de producción que sea accesible por el usuario que puedan revelar información
sensible?
¿La sensibilización del aplicativo o funcionalidad desarrollada se enfocó en las políticas de
3 seguridad de la información planteadas en el Ministerio, haciendo énfasis en la
confidencialidad que contempla el aplicativo o funcionalidad?
¿Se libere adecuadamente la memoria previa a la salida de una función y de todos los puntos
4
de finalización de la aplicación?

INTEGRIDAD SI NO N.A.
¿Se removió el código de testeo o cualquier funcionalidad que no sea tenida en cuenta en
5
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?
¿Los mantenimientos o incidencias presentadas antes de ser implementadas contemplaron
7
los lineamientos de seguridad?
¿Se revisaron los controles y los procedimientos existentes con respecto a la integridad para
8 garantizar que no serán comprometidos por los cambios solicitados en los mantenimientos o
incidentes presentados?
¿Se realizan pruebas a los incidentes o mantenimientos presentados para validar que no
9 afecten los requisitos de seguridad de la información para otros aplicativos o
funcionalidades?
DISPONIBILIDAD SI NO N.A.
¿Los aplicativos Misionales o funcionalidades nuevas publicados en el ambiente de
10 producción contemplan los mecanismos de seguridad en cuanto a prevención, detección y
recuperación?
¿La solución aplicada o el desarrollo realizado por causa de un incidente o mantenimiento
11 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

GTI-G -00X V.
01