Guia de Lineamientos Desarrollo Segurod e Software

CICLO DE VIDA Y REINGENIERÍA DE
PROCESO Código CVSS01

SISTEMAS DE INFORMACIÓN
DOCUMENTO Lineamientos de Desarrollo Seguro
Versión 02
SOPORTE de Software
LINEAMIENTOS DE DESARROLLO SEGURO DE SOFTWARE
MINISTERIO DE SALUD Y PROTECCIÓN SOCIAL

BOGOTÁ, NOVIEMBRE 2022
Página 1 de Una vez impreso o descargado este documento se considera copia no controlada ASIF13- Versión 1
18
Versión 02
SOPORTE de Software
TABLA DE CONTENIDO
1. OBJETIVO ....................................................................................................................................................... 4
2. ALCANCE ........................................................................................................................................................ 4
3. ÁMBITO DE APLICACIÓN .............................................................................................................................. 4
4. DOCUMENTOS ASOCIADOS A LA GUÍA...................................................................................................... 4
5. NORMATIVA Y OTROS DOCUMENTOS EXTERNOS ................................................................................... 4
6. DEFINICIONES ................................................................................................................................................ 5
7. INTRODUCCIÓN ............................................................................................................................................. 6
8. CONSIDERACIONES GENERALES ............................................................................................................... 6
9. CONTEXTUALIZACIÓN EN DESARROLLO SEGURO DE SOFTWARE ...................................................... 7
10. LINEAMIENTOS BASADOS EN EL PROCESO CVSC01 CICLO DE VIDA Y REINGENIERÍA DE SISTEMAS
DE INFORMACIÓN.................................................................................................................................................. 7
10.1 Fase I - (Planificación - Análisis - Diseño)................................................................................................. 7
10.1.1 Requisitos de Seguridad .......................................................................................................................... 8
10.1.2 Lista de Chequeo Fase I – (Planificación – Análisis – Diseño) – Aplicativos....................................... 9
10.1.3 Recomendaciones que se deben tener en cuenta en la administración de autenticación y
contraseñas ............................................................................................................................................................ 9
10.1.4 Política de Contraseñas para software desarrollado ........................................................................... 11
10.1.5 Fase II - (Desarrollo – Verificación de Cumplimiento de Especificaciones del Sistema- Verificar
Software Seguro- Realizar la publicación del Software en ambiente de pre-producción y gestionar
aprobación del área funcional) ........................................................................................................................... 12
10.1.6 Requisitos de Seguridad para la fase II ................................................................................................. 12
10.1.7 En desarrollo ........................................................................................................................................... 13
10.1.8 Buenas Prácticas de Desarrollo de Software ....................................................................................... 13
10.1.9 En Verificación de Cumplimiento de Especificaciones del Sistema................................................... 14
10.2 Lista de Chequeo Fase II - (Desarrollo - Verificación de Cumplimiento de Especificaciones del
Sistema- Verificar Software Seguro - Realizar la publicación del Software en ambiente de pre-producción y
gestionar aprobación del área funciona) ........................................................................................................... 15
10.3 Fase III - (Sensibilizar el uso del sistema de información, Realizar la puesta en producción del
Sistema de Información o Mantenimiento de Software, Analizar el mantenimiento de software o
atención a incidencias del sistema de información) .............................................................................. 16
10.3.1 Requisitos de Seguridad para la fase III ................................................................................................ 16
18
Versión 02
SOPORTE de Software
10.3.2 Lista de Chequeo Fase III - (Sensibilizar el uso del sistema de información, Realizar la puesta en
producción del Sistema de Información o Mantenimiento de Software, Analizar el mantenimiento de
software o atención a incidencias del sistema de información) ...................................................................... 17
18
Versión 02
SOPORTE de Software
1. OBJETIVO
Definir un documento que contenga los lineamientos y recomendaciones para la construcción de software Seguro, teniendo en cuenta los
controles especificados por la norma ISO/IEC 27002 - Numerales 9. Control de Acceso, 9.4 Control de acceso a las aplicaciones y a los
Sistemas de información, 14. Adquisición, desarrollo y Mantenimiento de los sistemas de Información, 14.1 Requisitos de seguridad de
los sistemas de información, 14.2 Seguridad en los procesos de desarrollo y soporte, 14.3 Datos de prueba.
2. ALCANCE
Aplica al ciclo de vida de todos los Aplicativos Misionales del Ministerio de Salud y Protección Social.
3. ÁMBITO DE APLICACIÓN
Este documento está orientado a los funcionarios involucrados en el desarrollo de Software Misional, analistas de requerimientos,
arquitectos, grupos de Innovación Tecnológica, Sistemas de información y datos, Infraestructura de Tecnologías de la Información y
Seguridad de la Información y Protección de Datos Personales.
Implementación de controles requeridos a través de la norma ISO-27002, - Numerales 9. Control de Acceso, 9.4 Control de acceso a las
aplicaciones y a los Sistemas de información, 14. Adquisición, desarrollo y Mantenimiento de los sistemas de Información, 14.1 Requisitos
de seguridad de los sistemas de información, 14.2 Seguridad en los procesos de desarrollo y soporte, 14.3 Datos de prueba.
4. DOCUMENTOS ASOCIADOS A LA GUÍA
- ASIS05 Política General de Seguridad de la Información del Ministerio de Salud y Protección Social.
- ASIS04 Política de Privacidad y Confidencialidad del MSPS.
- Proceso CVSC01 Ciclo de Vida y Reingeniería de Sistemas de Información.
- Proceso SIMC01 Administración de Sistemas de Información.
- Procedimiento CVSP01 Gestión del Desarrollo y/o Mantenimiento de Software Misional.
- Procedimiento CVSP04 Recepción de Software
- Procedimiento SIMP01 Ingreso de Aplicaciones Misionales al Centro de Datos Externo.
- Formato CVSF20 Listas de Chequeo de Software Seguro.
- Formato CVSF25 Listas de Chequeo de Recepción de Software.
- administración del sistema integrado de gestión
- procedimiento: Sistema de Gestión de Seguridad de la Información.
- ASIS02 Declaración de Aplicabilidad
- ASIM02 Manual de políticas de seguridad de la información (Política de Desarrollo)
- Proceso ASIC01
-
5. NORMATIVA Y OTROS DOCUMENTOS EXTERNOS
- Decreto 4107 de 2011: Artículo 10. Funciones de la Oficina de Tecnología de la información y la comunicación – OTIC.
- Resolución 425 del 18 de marzo de 2022: Por la cual se crean, organizan y conforman los Grupos Internos en la Oficina de
Tecnología de la Información y la Comunicación - TIC del Ministerio de Salud y Protección Social"
18
Versión 02
SOPORTE de Software
6. DEFINICIONES
• 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.
• Hardware: Conjunto de componentes físicos de un sistema informático.
• Vulnerabilidad: Debilidad de un activo o control que puede ser explotada por una o más amenaza.
• Integridad: Capacidad que garantiza que el código del software, activos manejados, configuraciones y comportamientos no puedan
ser o no hayan sido modificados o alterado.
• Disponibilidad: Capacidad que garantiza que el software es operativo y accesible por los usuarios a quien va destinado.
• Confidencialidad: Capacidad que garantiza que el software preserva cualquiera de las características, activos manejados, ocultos
o no accesibles a usuarios no autorizados.
• Hash: Función que asigna una cadena de longitud arbitraria a un valor de tamaño fijo de una manera determinista. Tal función puede
o no tener aplicaciones criptográficas. SHA es una de las muchas funciones hash. Una función hash es como una firma para un texto
o fichero. SHA-256 es un hash de 64 dígitos hexadecimales (un resumen, por ejemplo
bd4526534df7b33772c2f1ee26d97c39ff11379c8848e4e19d74ad849ef66423) casi único de un tamaño fijo de 256 bits (32 bytes). Un
hash solo se calcula en una dirección y no se puede decodificar de vuelta.
• Incidencia: Es toda interrupción o reducción de la calidad no planificada del servicio
• POST: HTTP define un conjunto de métodos de petición para indicar la acción que se desea realizar para un recurso determinado.
El método POST se utiliza para enviar una entidad a un recurso en específico, causando a menudo un cambio en el estado o efectos
secundarios en el servidor.
• Protocolo HTTPS o modo de navegación segura: HTTPS son las siglas en ingles de "Protocolo seguro de transferencia de
hipertexto", Usa el puerto 443 y permite realizar una conexión segura o sea de esa forma toda la información que viaja por internet
hacia dicho sitio o viceversa, es encriptada y nadie la puede interceptar. Es usado en bancos, tiendas online y todos los sitios donde
se realice cualquier tipo de operación financiera, pero también en sitios o servicios donde es necesario autentificarse con un nombre
de usuario y una contraseña.
El sistema HTTPS utiliza un cifrado basado en SSL/TLS para crear un canal cifrado (cuyo nivel de cifrado depende del servidor
remoto y del navegador utilizado por el cliente) más apropiado para el tráfico de información sensible que el protocolo HTTP. De este
modo se consigue que la información sensible (usuario y claves de paso normalmente) no pueda ser usada por un atacante que haya
conseguido interceptar la transferencia de datos de la conexión, ya que lo único que obtendrá será un flujo de datos cifrados que le
resultará imposible de descifrar.
El puerto estándar para este protocolo es el 443.
• Certificados SSL: SSL significa "Secure Sockets Layer". SSL Definición, Secure Sockets Layer es un protocolo diseñado para
permitir que las aplicaciones para transmitir información de ida y de manera segura hacia atrás. Las aplicaciones que utilizan el
protocolo Secure Sockets Layer sí saben cómo dar y recibir claves de cifrado con otras aplicaciones, así como la manera de cifrar y
descifrar los datos enviados entre los dos.
18
Versión 02
SOPORTE de Software
Los certificados SSL, certificados digitales o certificados de clave pública, son certificaciones que expenden empresas de seguridad
informática reconocidas como "Autoridades de certificación" sobre el estado de un sitio web, cuando este usa sus servicios. Las
principales son VeriSign (Symantec), Geotrust, GoDaddy, Comodo y GlobalSign.
En esos casos estas empresas escanean constantemente el contenido de dicho sitio en busca de malware u otro contenido malicioso,
lo protegen y lo validan.
7. INTRODUCCIÓN
El desarrollar e implementar soluciones de Software Seguro se ha convertido en uno de los objetivos esenciales dentro del esquema de
ciberseguridad de las organizaciones, es por ello que se hace necesario asegurar la inclusión de controles de seguridad, validación de
datos en el proceso del ciclo de vida del software para la creación de software más seguro y cumplir los requisitos de seguridad.
Actualmente todo sistema requiere y debe incorporar buenas prácticas de desarrollo de software, con el fin de repeler los ataques
maliciosos que se le puedan presentar; obligando al desarrollador a no sólo concentrarse en los usuarios y sus requerimientos, sino
también en los posibles ataques que puedan presentársele al software, en particular, lo que tiene que ver con la seguridad del código
fuente, por lo que deben ser consideradas durante el ciclo de vida de software, además, la seguridad debe de ser preservada durante
la operación y el mantenimiento para asegurar la integridad del software, así como definir y documentar los lineamientos de desarrollo
seguro, es por ello que el Ministerio de Salud y Protección Social ve la necesidad de crear este documento.
8. CONSIDERACIONES GENERALES
Las siguientes corresponden a consideraciones generales que deberían ser concebidas inicialmente para el desarrollo de software:
• En la fase de diseño y levantamiento de requerimientos, los coordinadores de los grupos deben identificar los requerimientos
establecidos por las normativas o estándares aplicables, como son ISO 27001, PCI-DSS (si aplica), Ley 1581 de protección de datos
personales, Lineamientos de operación de la OTIC, así como en todas las otras fases del Ciclo de Vida de Desarrollo de Software,
teniendo en cuenta lo establecido en los documentos: “Política de Privacidad y Confidencialidad del MSPS”, “CVSP01 Gestión del
Desarrollo y/o Mantenimiento de Software Misional”, “CVSG01 Guía para el Ciclo de Vida de un Sistema de Información”, en general
todo lo establecido en el proceso: “CVSC01 Ciclo de Vida y Reingeniería de Sistemas de Información”.
• También se deben tener en cuenta que los activos de información del MSPS requeridos para la operación en producción, deben ser
entregados al proveedor de la infraestructura con acta de entrega, custodia y responsabilidad sobre los activos, de manera que se
garantice su uso adecuado, teniendo en cuenta lo estipulado en el documento del proceso “SIMC01 Administración de Sistemas de
Información” y procedimiento “SIMP01 Ingreso de Aplicaciones Misionales al centro de datos externo”, CVSP04 Recepción de
Software.
• Todo proveedor o tercero que participe en las etapas de diseño, desarrollo, implementación o mantenimiento de aplicaciones debe
firmar el acuerdo de confidencialidad como se establece en el documento de: “Política de Privacidad y Confidencialidad del MSPS”.
• Todo tercero debe seguir estándares, buenas prácticas o modelos de madurez de desarrollo seguro, basándose en (o publicadas
por) OWASP, NIST, SANS, SAMM, BSIMM o MICROSOFT. Al respecto de esta consideración, en el presente documento se
contemplarán algunas de las vulnerabilidades referidas en OWASP (Validación de datos de entrada, Administración de autenticación
y contraseñas, Administración de sesiones, Control de Acceso, Prácticas Criptográficas, Manejo de errores y Logs, y Protección de
datos).
• Hay que mencionar además que los activos de información del MSPS 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, de manera que se
garantice su uso adecuado y disponibilidad para los encargados del desarrollo de aplicativos misionales para seguir el proceso de
“CVSC01 Ciclo de Vida y Reingeniería de Sistemas de Información”.
18
Versión 02
SOPORTE de Software
• Los riesgos que se encuentren a lo largo del ciclo de vida de desarrollo (al menos en las fases de diseño, definición de arquitectura
y desarrollo) deben quedar documentados (principalmente aquellos que no han sido gestionados o que deben ser aceptados por la
organización), por lo que para esta actividad se debe tener en cuenta lo establecido en el proceso “ASIC01 Sistema de Gestión y
Mejoramiento Institucional y el procedimiento “Administración de Riesgos Institucionales”, así como lo descrito en las fichas de los
riesgos para el proceso CVSC01 ubicados en la intranet.
• Para los desarrollos que se realicen o contraten, se debe asegurar los derechos de autor y la propiedad intelectual del código fuente
al Ministerio, para lo cual el software se debe registrar y patentar, de acuerdo a la legislación colombiana. Este lineamiento debe
realizarle de acuerdo al procedimiento que establezca el MSPS.
• Los Grupos de Infraestructura y seguridad debe contar con procesos y procedimientos claramente definidos, socializados y que
puedan ser auditados para la asignación de Ambientes, uso compartido, 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, así como lo contemplados en el Acuerdo Marco - CCE-430-1-AMP-2016 de compra
eficiente. (Servicios estandarizados de uso y gestión de recursos infraestructura de seguridad, orientada a robustecer la protección y
la prevención de intrusos a los Servicios de Nube Privada adquiridos por la entidad)
• Se debe contar con los ambientes de desarrollo, pruebas y producción, teniendo en cuenta que la separación de funciones y
ambientes lógicos de trabajo es un método para reducir el riesgo accidental o deliberado del mal uso del sistema.
• Así mismo, es necesario implementar para todos los ambientes, a todos y cada uno de los equipos software de seguridad (antivirus,
privilegios de acceso y otros que apliquen), con el propósito de proteger la integridad de los sistemas informáticos y de
telecomunicaciones.
• Se debe contemplar el Principio del mínimo privilegio, los intervinientes en el desarrollo de software deben tener habilitado
exclusivamente los derechos de acceso (escritura, lectura, etc.) a los objetos que ineludiblemente requieran para cumplir las funciones
del puesto que ocupan.
9. CONTEXTUALIZACIÓN EN DESARROLLO SEGURO DE SOFTWARE
La OTIC asignará un responsable para la debida socialización y apropiación de los funcionarios de las políticas, procesos y procedimientos
referidos en este documento, así:
Socialización inicial y apropiación a todos los funcionarios que intervienen en la OTIC:
• Socialización inicial y apropiación a los funcionarios nuevos que ingresen a la entidad.

• Socializaciones periódicas por actualizaciones de los mismos.
10. LINEAMIENTOS BASADOS EN EL PROCESO CVSC01 CICLO DE VIDA Y REINGENIERÍA DE

Los lineamientos que se dispondrán en este documento están basados en los pilares de la seguridad de la información confidencialidad,
en cuanto al acceso a los activos del sistema, los cuales deberán limitarse únicamente a usuarios autorizados, integridad basándose en
que los activos del sistema sólo podrán ser borrados o modificados por usuarios que estén autorizados, disponibilidad en cuanto que se
garantice a los usuarios que se autoricen el acceso a los activos en un tiempo razonable.
10.1 Fase I - (Planificación - Análisis - Diseño)
18
Versión 02
SOPORTE de Software
En esta fase se contemplarán las etapas del procedimiento Gestión del desarrollo y/o mantenimiento de software misional - Definir el
alcance, la estructura y los requerimientos - Realizar el levantamiento de información - Efectuar el análisis de la información recolectada
y Solicitar la Infraestructura para Disponer los Ambientes de Desarrollo y Prueba.
10.1.1 Requisitos de Seguridad
Se debe identificar los objetivos y requisitos de seguridad que se requieren contemplar e implementar, estos se pueden determinar basado
en lo siguiente:
1. Arquitectura que va a emplear la aplicación.

2. Plataforma donde correrá la aplicación.
3. Tipos de datos que se almacenarán, consultarán o transferirán, es decir se debe definir cuáles son confidenciales y/o públicos.
4. Tipos de registro que el sistema debe generar, acceso a los recursos, uso de privilegios, perfiles de usuario. Los tipos de acceso a
los datos deben ser estructurados de acuerdo a los perfiles definidos, lectura, escritura, modificación y eliminación.
5. Definir cómo será el modo de autenticación al ingreso del aplicativo por usuario y contraseñas, tokens, entre otros.
6. Plantear, aclarar, diligenciar y/o tramitar lo establecido en la Política de Privacidad y Confidencialidad del MSPS para el proyecto.
7. En esta etapa es necesario contemplar los riesgos del proyecto entre los cuales se debe contemplar lo siguiente:
• El tiempo designado para el desarrollo no es suficiente, es decir mala planeación en la calendarización.

• Reuniones no suficientes y poco productivas.
• Inhabilidad o incapacidad durante el desarrollo por parte de un integrante del grupo.
• Mala definición de la información confidencial y pública, así como los roles y permisos.
• Priorización errónea de las actividades a realizar por cada uno de los integrantes.
• Ausencia o demora de respuestas en el trabajo asignado.
• Conflictos frecuentes que pueden ser por mal ambiente de trabajo al interior del grupo.
• Definición de los requerimientos poco claros.
• Documentación de los requerimientos incompleta.
• Problemas con alguno de los diseños.
• Conflictos con la trazabilidad y/o priorización de los requerimientos
• Falla en la documentación de algún diagrama.
• Falta de comunicación con los líderes del proyecto.
• Baja disponibilidad por parte de los líderes del proyecto.
Así como las acciones correctivas y/o preventivas que se tendrán en el proyecto, como las siguientes:
• Establecer tiempos con holgura previendo imprevistos y/o asumir el tiempo adicional requerido y hacer las notificaciones pertinentes.
• Establecer compromisos y los temas a tratar antes de las reuniones, enviar previamente la documentación respectiva para que todos
tengan conocimiento de lo que se tratará en las reuniones y/o solicitar mediación, de los superiores encargados del proyecto.
• Definir responsables que pueden suplir la ausencia de las personas que integran el grupo inicial de definición de requerimientos y/o
asumir el tiempo que se prolongaría el proyecto.
• Es recomendable que se contemple y adicione en el cronograma de actividades el tiempo que corresponda a la curva de aprendizaje
de la persona que se agregue y llegue a realizar actividades en particular que puedan ser directas y no tan dependientes de las del
resto del equipo, teniendo en cuenta las características con las que debe contar la persona incluida con respecto a habilidades y
conocimientos.
• Las personas intervinientes en el proceso deben tener conocimiento claro de qué es la información con la cual se trabajará, dispondrá
y niveles de importancia para su cumplimiento y/o asumir que no se valoró priorizó requerimientos, ni clasificó correctamente la
información, roles y permisos.
• Establecer compromisos con los líderes, usuarios que solicitan el requerimiento, así como la forma de escalamiento del
incumplimiento de las actividades por parte de los intervinientes del proyecto.
18
Versión 02
SOPORTE de Software
10.1.2 Lista de Chequeo Fase I – (Planificación – Análisis – Diseño) – Aplicativos
Para esta etapa se dispone de los mínimos interrogantes que debe contener la lista de chequeo, para la verificación de Desarrollo de
Software Seguro. De ser necesario según la particularidad del proyecto se pueden adicionar o modificar las sugeridas.
Fase I - (Planificación - Análisis - Diseño) – Aplicativos
Nombre del Proyecto
Responsable del Proyecto Sistema
ITEM CONFIDENCIALIDAD SI NO N.A.
¿El aplicativo tiene páginas clasificadas privadas?
¿El aplicativo requiere autenticación para todos los recursos y páginas excepto aquellas específicamente
clasificadas como públicas?
¿Se definieron cuáles de los datos que almacenará el aplicativo son privados y cuáles públicos?
¿Se definieron los tipos de registro que debe generar el sistema?
¿Se definieron los accesos a los recursos del sistema?
¿Se definieron los perfiles de usuario con sus respectivos permisos?
¿Se definió el modo de autenticación al ingreso del aplicativo?
ITEM INTEGRIDAD SI NO N.A.
¿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)?
¿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?
¿Se contempló controles para administración de sesiones?
¿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?
¿Se contempló el uso de registro de log’s y que los datos del registro de log contengan información
importante?
¿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 sistema?
¿Se contempló asegurar que existan mecanismos para conducir un análisis de los logs?
¿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 seguridad que el
ambiente de producción?
¿Se contempló no habilitar funcionalidades de completar automáticamente en aquellos formularios que
contienen información sensible, incluyendo la autenticación?
¿Se contempló la funcionalidad de captchas (verificar que el usuario que está accediendo a determinados
datos es un humano y no una máquina)
ITEM DISPONIBILIDAD SI NO N.A.
¿Se contempló el lugar de almacenamiento de los logs?
¿Se contemplaron los riegos del proyecto en esta etapa?
¿Se contemplaron acciones para minimizar los riesgos del proyecto?
Concepto:
10.1.3 Recomendaciones que se deben tener en cuenta en la administración de autenticación y

contraseñas
En ítem se enumeran algunas recomendaciones que se deben tener en cuenta en la administración, autenticación y manejo de
contraseñas, tome en cuenta las que se ajustan a lo definido en el proyecto:
18
Versión 02
SOPORTE de Software
• Si los usuarios requieren realizar algún tipo de transacción, se debe requerir autenticación para el acceso a estas funcionalidades
dentro del portal. No se requerirá autenticación para aquellas páginas específicamente clasificadas como públicas.
• Todos los controles de autenticación deben ser efectuados en un sistema en el cual se confíe. (por ejemplo: el servidor).
• Se deben establecer y utilizar servicios de autenticación estándares y probados cuando sea posible.
• 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.
• Se debe considerar como restringido el acceso a la administración del Portal. Idealmente se debe tener un control por dirección IP
pública el cual limite la conexión desde cualquier lugar diferente a la Entidad y a las instalaciones del proveedor de software (en caso
que aplique).
• 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 (por ejemplo: el servidor).
• 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 (ejemplo: el servidor). 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 cifradas o datos cifrados para el envío de contraseñas que no sean temporales (por ejemplo: correo
cifrado); 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” (input type “password”).
• 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.
• Re autenticar 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).
18
Versión 02
SOPORTE de Software
• 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.
• 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.
• Se debe establecer un tiempo de vida de la sesión lo más corto posible, balanceando los riesgos con los requerimientos del negocio.
En la mayoría de los casos, nunca debería ser superior a varias horas.
• Si una sesión fue establecida antes del inicio de sesión (login), se deberá cerrar dicha sesión y establecer una nueva luego de un
inicio de sesión exitoso.
• Generar un nuevo identificador de sesión luego de cada re autenticación.
• No permitir inicios de sesión concurrentes con el mismo usuario.
• No exponer identificadores de sesión en URLs, mensajes de error ni logs. Los identificadores de sesión solo deben ser ubicados en
la cabecera de la cookie HTTP. A modo de ejemplo, no transmitir el identificador de sesión como un parámetro GET
• Proteger la información sobre las sesiones del lado del servidor implementando los controles de acceso apropiados.
• Generar un nuevo identificador de sesión y desactivar el anterior de forma periódica. De esta forma se pueden mitigar algunos
escenarios de robo de sesiones donde el identificador se compromete.
• Generar un nuevo identificador de sesión si la seguridad cambia de HTTP a HTTPS, como puede suceder durante la autenticación.
Dentro de la aplicación es recomendable usar siempre HTTPS en lugar de cambiar entre HTTP y HTTPS.
• Considerar el manejo de sesión complementario para operaciones sensible del lado del servidor, como pueden ser: gestión de
cuentas o utilizando tokens o parámetros por sesión.
• Manejo de sesión complementario para operaciones sensibles o críticas utilizando tokens o parámetros por pedido (per request) en
lugar de por sesión.
• Configurar el atributo “secure” para las cookies transmitidas sobre una conexión SSL, TLS.
• Configurar las cookies con el atributo HttpOnly, salvo que se requiera específicamente scripts del lado del cliente en la aplicación,
para leer o configurar una cookie.
10.1.4 Política de Contraseñas para software desarrollado
Todas las contraseñas de los usuarios de los aplicativos misionales del Ministerio de Salud y Protección Social deben contemplar las
siguientes reglas:
a. Estar formada por al menos 8 caracteres.

b. Contener caracteres al menos dos de las siguientes tres clases de caracteres:
o Alfabéticos (o sea, a-z, A-Z); no se recomienda utilizar la “ñ” o vocales con tilde.
o Numéricos (o sea, 0-9).
o Caracteres especiales y de puntuación (!@#$%^&*()_+|~- =\`{}[]:";'<>?,./)
c. La contraseña de los aplicativos Misionales del Ministerio de Salud y Protección Social deberá forzarse el
cambio al menos una vez cada año.
d. Los aplicativos del Ministerio de Salud y Protección Social no deben nunca solicitar ni revelar contraseñas
por correo electrónico.
e. Se debe habilitar una opción para el cambio de su contraseña de forma segura.
f. Se debe disponer en el portal de servicios de cada aplicativo Misional del Ministerio de Salud y Protección
Social el servicio de “He olvidado mi contraseña” para que el usuario pueda obtenerla de forma automática
en caso de olvido.
Todos los aplicativos Misionales del Ministerio de Salud y Protección Social deben formalizar e informar a los usuarios que utilicen los
aplicativos Misionales del Ministerio de Salud y Protección Social lo siguiente:
Que no deben utilizar contraseñas que se puedan adivinar fácilmente, como pueden ser:
18
Versión 02
SOPORTE de Software
• Una cadena de caracteres derivada del nombre de la cuenta del usuario.

• Una cadena de caracteres formada por la repetición de caracteres.
• Una palabra contenida en un diccionario (de lengua española o extranjera).
• Una palabra de diccionario seguida o precedida de un carácter (p.ej. “palabra1” o “Xpalabra” o “palabra!”.
• Fechas de cumpleaños u otra información personal tales como dirección o número de teléfono.
• Conjuntos de letras o números que sigan un patrón sencillo, tales como aaabbb, qwerty, abcdef, 123321, etc.
Así como las siguientes recomendaciones:
• 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.
• Es muy recomendable utilizar el servicio “He olvidado mi contraseña” para poder obtenerla de forma automática en caso de olvido;
para ello hay que hacer una configuración previa de esta utilidad, disponible en el Portal de Servicios.
• 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.
• Aunque se ha especificado en el apartado anterior que la contraseña se cambiará al menos una vez al año, recomendar que dicho
cambio se haga al menos cada 6 meses y, en cualquier caso, siempre que se tenga alguna sospecha de que haya podido ser
conocida o adivinada por algún tercero
• 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 (Sha256)
10.1.5 Fase II - (Desarrollo – Verificación de Cumplimiento de Especificaciones del Sistema- Verificar

Software Seguro- Realizar la publicación del Software en ambiente de pre-producción y gestionar
aprobación del área funcional)
En esta fase se contemplarán las etapas del procedimiento Gestión del desarrollo y/o mantenimiento de software misional - Definir el
alcance, la estructura y los requerimientos - Realizar el desarrollo de Software - Verificar el cumplimiento de las especificaciones del
sistema - Verificar Software Seguro - Realizar la publicación del Software en ambiente de pre-producción y gestionar aprobación del área
funcional
Adicional a este documento se debe tener en cuenta el documento de Buenas Prácticas Codificación proporcionado por Microsoft al
Ministerio de Salud y Protección Social.
10.1.6 Requisitos de Seguridad para la fase II
En este ítem se debe tener en cuenta lo siguiente, previo al inicio del desarrollo:
• 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. La solicitud de creación de estos ambientes debe realizarse bajo los parámetros
establecidos, en el procedimiento “SIMP03 Gestión de Solicitudes de Infraestructura y Seguridad para los Sistemas de Información
Misionales”, así como lo contemplado en la “Guía Para el Ciclo de Vida de un Sistema de Información”.
• Los desarrolladores deben realizar su trabajo exclusivamente en ambiente de desarrollo, nunca en otros ambientes directamente.
• Los nombres de dominio para los ambientes de producción, pruebas 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.
18
Versión 02
SOPORTE de Software
• 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 y otros.
10.1.7 En desarrollo
1. 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.
2. 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
3. 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.
4. 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.
5. 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.
6. Formato de salida: Los formatos de salida no deben ser cambiados por funciones debido a que estos pueden
ocasionar errores en el buffer.
7. 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
8. 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.
9. 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.
10. 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.
11. 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.
12. Evitar generar código con valores ingresados por el usuario.
13. Reemplazar sentencias SQL dinámicas por Stored Procedures.
14. 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.
10.1.8 Buenas Prácticas de Desarrollo de Software
• 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.
18
Versión 02
SOPORTE de Software
• Inicializar siempre las variables.

• La aplicación deberá generar y almacenar un log de auditoría 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.
• 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.
10.1.9 En Verificación de Cumplimiento de Especificaciones del Sistema
En esta fase se deben contemplar las siguientes recomendaciones:
1. Las pruebas iniciales se deben realizar a partir de los requerimientos definidos y aprobados en el documento
“CVSF04_Especificación_de_requerimientos”, el alcance de éstas pruebas es el de validar que el sistema
cumple con el funcionamiento esperado y los requisitos de seguridad de acceso al sistema, a los datos y
procesos definidos, así como a los distintos recursos del sistema
2. 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.
3. 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
4. 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.
5. Las pruebas de seguridad funcional se deben basar en los requerimientos definidos con respecto a:
• 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.
• Bloqueo automático de cuentas de acceso.
• Funcionalidad de captchas (verificar que el usuario que está accediendo a determinados datos es un humano y no una máquina).
• Lo registrado en los logs, así como su almacenamiento.
• Los mensajes de error que se deben presentar en las acciones validadas.
• 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
18
Versión 02
SOPORTE de Software
referencial que deben mantener las relaciones de los registros y llegase a ser necesario emplear información real para las pruebas,
esta información debe ser anonimizada, con el fin de resguardar la confidencialidad de la información empleada.
• Adicionalmente los datos de prueba sean creados o los reales anonimizados, estos se deben realizar ingresando de forma mutada a
los diferentes módulos de la aplicación en donde se solicite datos, es decir, con diferente signo, tipo, longitud, fuera del rango
solicitado, caracteres especiales, valores nulos y/o aleatorios.
• Es necesario que se contemple la posibilidad de realizar pruebas de rendimiento de software, estructurando escenarios que sometan
la aplicación a su máximo rendimiento y consumo de recursos.
• Para las pruebas que se realicen a los aplicativos Misionales del MSPS, debe designarse una persona diferente al desarrollador del
requerimiento.
• Aunque el proyecto haya tenido que ajustar y actualizar su cronograma por ampliación o reducción de tiempo, nunca se debe recortar
el tiempo destinado para las pruebas, debido a que se debe asegurar siempre que el proyecto que se entregue esté libre de errores,
debido a que si se recorta el tiempo en pruebas puede incurrirse en muchos más errores de los habituales.
6. No se debe publicar ningún aplicativo sin la debida aprobación de acuerdo a los procedimientos establecidos.
10.2 Lista de Chequeo Fase II - (Desarrollo - Verificación de Cumplimiento de Especificaciones del

Sistema- Verificar Software Seguro - Realizar la publicación del Software en ambiente de pre-
producción y gestionar aprobación del área funciona)
Fase II - (Desarrollo – Verificación de Cumplimiento de Especificaciones del Sistema- Verificar Software Seguro- Realizar la
publicación del Software en ambiente de pre-producción y gestionar aprobación del área funciona)
Nombre del Proyecto
¿Se implementaron las páginas que fueron definidas como clasificadas privadas?
¿Se implementó la autenticación para todos los recursos y páginas definidas excepto aquellas que
específicamente fueron clasificadas como públicas?
¿Los datos almacenados definidos como privados cuentan con las restricciones correspondientes?
¿Se implementaron los tipos de registro que debe generar el sistema?
¿Fueron implementados los accesos a los recursos del sistema, con base en los requerimientos?
¿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 proyecto?
¿Fueron implementadas y tenidas en cuenta todas políticas establecidas en el Ministerio?
¿Se verificó que el ambiente de desarrollo y pruebas esté configurado con la misma seguridad que el ambiente
de producción?
¿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 sensible ni detalles del
sistema, identificadores de sesión o información de la cuenta?
¿Se implementó el control de sesiones?
¿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?
¿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 acceso?
¿En las pruebas se verificó que no se guarde información sensible, ni detalles innecesarios del sistema?
¿Se validaron que las acciones definidas cuando no se registre información en el log funcionen?
¿Se definió las acciones a tomar si no se pueden registrar logs?
¿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?
¿Se validó la funcionalidad captchas?
¿Se cumple con la política de contraseñas definida?
18
Versión 02
SOPORTE de Software
¿Los desarrolladores sólo realizaron su trabajo en el ambiente de desarrollo, nunca en otros ambientes
directamente?
¿Los nombres de dominio para los ambientes de producción, pruebas y desarrollo, son diferentes?
¿Para las pruebas se utilizó datos que no eran reales o anonimizados?
¿En general las pruebas realizadas contemplaron los lineamientos de seguridad estipulados en el presente
documento?
¿Se contó con el ambiente de desarrollo?
¿Se contó con el ambiente de pruebas?
¿La seguridad de los ambientes de desarrollo y pruebas tenían el mismo nivel de seguridad que el de producción?
¿Se verificó el almacenamiento de los logs?
¿Se implementaron las acciones para minimizar los riesgos?
¿Se solicitaron los permisos para el acceso a los ambientes de acuerdo al perfil de cada persona?
¿Fueron asignados los permisos de acceso a los ambientes de acuerdo a lo solicitado?
Concepto:
10.3 Fase III - (Sensibilizar el uso del sistema de información, Realizar la puesta en producción del Sistema
de Información o Mantenimiento de Software, Analizar el mantenimiento de software o atención a
incidencias del sistema de información)
En esta fase se contemplarán las etapas del procedimiento, Sensibilizar el uso del sistema de información, Realizar la puesta en producción
del Sistema de Información o Mantenimiento de Software, Analizar el mantenimiento de software o atención a incidencias del sistema de
información.
10.3.1 Requisitos de Seguridad para la fase III
• En la sensibilización o transferencia de conocimiento 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.
• La puesta en producción debe seguir el procedimiento establecido en el procedimiento SIMP03 Gestión de Solicitudes de
Infraestructura y Seguridad para los Sistemas de Información Misionales.
• Los aplicativos Misionales del MSPS publicados en el ambiente de producción deben contemplar los mecanismos de seguridad en
tres grupos:
1. Prevención: Evitando desviaciones respecto a la política de seguridad del Ministerio de Salud y Protección Social.
2. Detección: Mostrando las desviaciones si se producen, violaciones o intentos de violación de la seguridad del sistema donde se
encuentran ubicados los aplicativos Misionales del Ministerio de Salud y Protección Social.
3. Recuperación: Los cuales deben ser aplicados cuando se ha detectado una violación de la seguridad del sistema para recuperar su
normal funcionamiento.
Aunado a lo anterior, se debe tener en cuenta los acuerdos y lineamientos contemplados en acuerdos de terceros, así como los
contemplados en Colombia Compra Eficiente en el Acuerdo Marco para la adquisición de Servicios de Nube Privada (acuerdo marco -
cce-430-1-amp-2016)
Es necesario también que se contemple lo establecido en el MSPS en el procedimiento “Gestión de Solicitudes de Infraestructura y
Seguridad para los Sistemas de Información Misionales”, “Guía para la solicitud de Servicios de Infraestructura y Seguridad de la OTIC” y
la “Guía para la gestión de cambios en aplicaciones misionales”.
• Todos los cambios para los aplicativos misionales del MSPS sin excepción deberán tener en cuenta lo establecido en la Gestión de
Cambios contemplada en el proceso Ciclo de Vida y Reingeniería de Sistemas de Información., en el procedimiento CVSP01 Gestión
del desarrollo y o mantenimiento de software misional., en las actividades “Realizar la puesta en producción del Sistema de
18
Versión 02
SOPORTE de Software
Información o Mantenimiento de Software” y “Analizar el mantenimiento de software o atención a incidencias del sistema de
información”, dado que la solicitud Formato “GVTF01 Solicitud Servicio Requerimiento” es analizada y si es aprobada la solicitud, se
determina la prioridad de la misma, posterior a ello se especifica en el formato “CVSF10 Mantenimiento software Especificación” y su
solución modelada en el Formato “CVSF11_Solucion_incidencia_de_software”. Así se contempla que los cambios solicitados han
sido evaluados, autorizados, probados, aceptados y documentados con la finalidad de evitar impactos negativos en la calidad,
confidencialidad, integridad, disponibilidad y funcionalidad de los aplicativos misionales.
• Se debe en todos los mantenimientos o incidencias que se presenten contemplar su implementación teniendo en cuenta los
lineamientos de seguridad planteados en el presente documento, así como en su implementación la confidencialidad, integridad y
disponibilidad que afecten o modifiquen estos requerimientos.
10.3.2 Lista de Chequeo Fase III - (Sensibilizar el uso del sistema de información, Realizar la puesta en
producción del Sistema de Información o Mantenimiento de Software, Analizar el mantenimiento de
software o atención a incidencias del sistema de información)
Fase III -(Sensibilizar el uso del sistema de información, Realizar la puesta en producción del Sistema de Información o
Mantenimiento de Software, Analizar el mantenimiento de software o atención a incidencias del sistema de información)
Nombre del Proyecto
¿Se implementó el mínimo privilegio y/o la restricción del acceso de usuarios solamente a la funcionalidad
desarrollada del aplicativo?
¿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?
¿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?
¿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?
¿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?
¿Se contempló el uso de APIs previstas para el acceso a funciones específicas?
¿Los mantenimientos o incidencias presentadas antes de ser implementadas contemplaron los lineamientos de
seguridad?
¿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?
¿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?
¿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?
¿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?
Concepto:
18
Versión 02
SOPORTE de Software
REFERENCIAS BIBLIOGRÁFICAS
• Raecillacastellana, 21 ago. 2016 17:05:14, Recuperado de https://developer.mozilla.org/es/docs/Web/Reference.
• Julián, G. (2013) 18 Marzo 2016, HTTPS: así funciona. Genbeta.com. Recuperado de http://www.genbeta.com/web/https-asi-
funciona
[ii] Julián, M. (2011). 18 Marzo 2016, Explicando el protocolo HTTPS. Genbeta.com. Recuperado de http://www.genbeta.com/guia-
de-inicio/explicando-el-protocolo-https
• Raúl Hernández, 24 junio, 2016, Recuperado de https://testeandosoftware.com/owasp-top-10-vulnerabilities-videos/
• 01/03/2013 versión 1.5.0 de MADEJA, Desarrollo especificaciones para la obtención de sistemas de información seguros,
Recuperado de http://www.juntadeandalucia.es/servicios/madeja/
ELABORADO POR: REVISADO POR: APROBADO POR:

Nombre y Cargo: Nombre y Cargo: Nombre y Cargo:
Marcela Mosquera B.,Profesional José Berardo Prieto Camelo, : Luz Marcela Silva Fajardo Jefe de la
Especializado Oficina de TIC. Coordinador Grupo de Sistemas de Oficina de TIC (E)
Mariela Saavedra Cruz, Contratista Información y Datos
Oficina de TIC
Fecha: 3 de noviembre de 2022 Fecha: 3 de noviembre de 2022 Fecha: 15 de noviembre de 2022
18

Guia de Lineamientos Desarrollo Segurod e Software

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Guia de Lineamientos Desarrollo Segurod e Software

Cargado por

Copyright:

Formatos disponibles

CICLO DE VIDA Y REINGENIERÍA DE

PROCESO Código CVSS01

LINEAMIENTOS DE DESARROLLO SEGURO DE SOFTWARE

MINISTERIO DE SALUD Y PROTECCIÓN SOCIAL

4. DOCUMENTOS ASOCIADOS A LA GUÍA

5. NORMATIVA Y OTROS DOCUMENTOS EXTERNOS

• Hardware: Conjunto de componentes físicos de un sistema informático.

• Incidencia: Es toda interrupción o reducción de la calidad no planificada del servicio

El puerto estándar para este protocolo es el 443.

9. CONTEXTUALIZACIÓN EN DESARROLLO SEGURO DE SOFTWARE

Socialización inicial y apropiación a todos los funcionarios que intervienen en la OTIC:

• Socialización inicial y apropiación a los funcionarios nuevos que ingresen a la entidad.

10. LINEAMIENTOS BASADOS EN EL PROCESO CVSC01 CICLO DE VIDA Y REINGENIERÍA DE

10.1.1 Requisitos de Seguridad

1. Arquitectura que va a emplear la aplicación.

• El tiempo designado para el desarrollo no es suficiente, es decir mala planeación en la calendarización.

10.1.2 Lista de Chequeo Fase I – (Planificación – Análisis – Diseño) – Aplicativos

10.1.3 Recomendaciones que se deben tener en cuenta en la administración de autenticación y

10.1.4 Política de Contraseñas para software desarrollado

a. Estar formada por al menos 8 caracteres.

• Una cadena de caracteres derivada del nombre de la cuenta del usuario.

Así como las siguientes recomendaciones:

10.1.5 Fase II - (Desarrollo – Verificación de Cumplimiento de Especificaciones del Sistema- Verificar

10.1.6 Requisitos de Seguridad para la fase II

• Inicializar siempre las variables.

10.1.9 En Verificación de Cumplimiento de Especificaciones del Sistema

En esta fase se deben contemplar las siguientes recomendaciones:

10.2 Lista de Chequeo Fase II - (Desarrollo - Verificación de Cumplimiento de Especificaciones del

10.3.1 Requisitos de Seguridad para la fase III

• Raecillacastellana, 21 ago. 2016 17:05:14, Recuperado de https://developer.mozilla.org/es/docs/Web/Reference.

• Raúl Hernández, 24 junio, 2016, Recuperado de https://testeandosoftware.com/owasp-top-10-vulnerabilities-videos/

ELABORADO POR: REVISADO POR: APROBADO POR:

Fecha: 3 de noviembre de 2022 Fecha: 3 de noviembre de 2022 Fecha: 15 de noviembre de 2022

También podría gustarte