PROCESO

FORMATO

Este formato refleja los requisitos establecidos en el Subsistema de seguridad de la Información como protocolo de
requisitos dili

Aplica
REQUERIMIENTOS DE SEGURIDAD DE LA INFORMACIÓN Justificación
SI NO
No. Análisis y especificación de requisitos de seguridad de la
Requerimiento información
1 El sistema debe permitir la Gestión de Seguridad de
Usuarios, grupos de usuarios y asignación de Roles y perfiles
de usuarios, permitiendo asociar las acciones disponibles en
el sistema a roles de usuario, permitiendo parametrizar las
funcionalidades que cada actor puede usar en el sistema, los
permisos de acceso al sistema para los usuarios podrán ser
cambiados solamente por el administrador de acceso a
datos.

2 La aplicación al ingresar al usuario debe mostrar la última

3 fecha y horapuede
Un usuario de ingreso
estar yasociado
debe garantizar solo roles,
a uno o más una sesión
de tal
manera que los menús de navegación del sistema se
muestran o despliegan dependiendo de las acciones
asociadas a cada rol de usuario, permitiendo así que cuando
el usuario es autenticado correctamente el sistema verifica
los roles que tiene activos para otorgarle únicamente las
acciones autorizadas a realizar.

4 El sistema debe proveer una consulta que permita a un

usuario con los privilegios asignados, consultar los registros
de auditoria, aplicando criterios de filtro (usuario, maquina,
rango de fechas y tipo de operación,usuarios activos, los
perfiles de los mismos, los usuarios inactivos con sus fechas
de bajas y altas).

5 El diseño del sistema debe definir los criterios necesarios

para asegurar la trazabilidad y auditoría sobre las acciones
6 El diseño del sistema debe tener en cuenta mecanismos que
aseguren el registro histórico para poder mantener la
trazabilidad de las acciones realizadas por los usuarios,
contemplando el registro de auditoría que contiene
información de fecha y hora, identificación del registro,
tabla afectada, descripción del evento, tipo de evento,
usuario que realiza la acción, identificación de sesión y
dirección IP del usuario que efectuó la transacción.

7 El sistema debe integrarse un sistema de autenticación LDAP

8 –ElBeToC entre
sistema debeotros. Para usuarios
garantizar externosde
el cumplimiento (por
la ejemplo:
normatividad vigente en cuanto a protección de datos
personales, debe permitir el manejo de excepciones previa
autorización de los usuarios finales (ciudadanos), cuando los
sistemas de información soliciten datos personales al
usuario final se debe establecer un mecanismo que permita
registrar que se ha autorizado o no el tratamiento de los
mismos.

9 El sistema debe contemplar las prácticas de desarrollo

10 seguro de aplicaciones
El sistema debe permitiry/o
el implementación segura de de
respaldo de la información
acuerdo a las necesidades del líder funcional de la
aplicación.

11 El sistema debe asegurar los aspectos de la transacción,

asegurando la información de autenticación secreta de
usuario (User´s Secret Authentication Information),
validando y verificando que la transacción permanezca
confidencial y que se mantenga la privacidad asociada con
todas las partes involucradas.

12 En la información confidencial solo puede ser consultada por

13 los perfilesdebe
El sistema autorizados e igualmente
desarrollarse restringir
aplicando patronesdocumentos
y
recomendaciones de programación que incrementen la
seguridad de datos.

14 Se deben aplicar técnicas de construcción de acuerdo a los

lineamientos y buenas practicas sugeridas por Microsoft
para el desarrrollo seguro de acuerdo al estandar que se
use.
 15 Se debe desarrollar el control de sesiones seguras y
validación de datos, desinfección y eliminación de códigos
de depuración (Debugging Codes)

16 A nivel de la base de datos debe poder definirse reglas de

17 validación de integridad
El sistema debe contemplarde datos (unicidad,
un modelo referencial
de datos que y
negocio).
garantice
18 El sistemabase
debede datos
tener única para
capacidad deevitar que
calificar se pueda la
y etiquetar
presentar
informaciónduplicidad
generada de información.
o procesada
19 El sistema debe tener capacidad de por ellos, según
resguardar Ley 1712
y procesar la
de 2014.
información generada o procesada dando cumplimiento a lo
20 El sistema debe cerrar las transacciones luego de máximo 10
Seguridad exigido
minutos por la
dedebeLey 1581
inactividad. de 2012
21 de las El sistema incluir controles de bloqueo de cuenta
aplicaciones en después de un máximo de 5 intentos erróneos a fin de evitar
ombligo redes ataques de fuerza bruta.
públicas y
Protección
22 de las La aplicación debe cumplir con controles de seguridad
transacciones relacionados a su utilización a través de redes públicas y
privadas, garantizando la confidencialidad, integridad y
disponibilidad de la información y acceso a ella.

23 Encriptar las comunicaciones de los servicios expuestos en

24 redes
Requerirpúblicas
el uso de métodos fuertes de autenticación para
25 las
El sistema debe core
aplicaciones delunNegocio
incluir mecanismoexpuestas a redes
de cifrado públicas
de los datos
26 que se transportan entre los diferentes componentes
El sistema debe permitir la implementación de certificados
tecnológicos
digitales tantoydebe
los datos sensibles
en software comoelende hardware.
la base de datos que
27 La aplicación
representen un altoimplementar mecanismo de firma o
nivel de confidencialidad.
28 validación o autorización
El sistema debe incluir usodededocumentos
criptografíamediante
para firma
mecánica o
transacciones digital.
y/o campos sobre
sensibles según lo
29 El sistema debe funcionar protocolo SSLindiquen las
(certificados
normas
internos de la entidad cuando los sistemas de informaciónde
vigentes y las necesidades específicas del negocio
acuerdo comoylocertificados
sean internas determinevalidos
la entidad.
públicamente cuando los
sistemas de información estén expuestas a internet).

30 Implementar controles para evitar la pérdida o duplicación

Control 31
de de
Lasinformación
páginas webde lastenga
que transacciones.
interacción con el usuario debe
cambios en estar implementados con el protocolo HTTPS (HyperText
sistemas y Transfer Protocol Secure), los datos que se envían estarán
ambientes de protegidos con el protocolo TLS (Transport Layer Security)
32 seguro
desarrollo Aplicar el procedimiento de control de cambios vigente en la
33 Entidad.
Probar el nuevo software en un ambiente separado tanto de
los ambientes de producción como de desarrollo.

Pruebas de
aceptación y
seguridad de
sistemas34 Los implementadores de sistemas de información deben
35 usar herramientas
Programa detalladopara el análisis de
de actividades código y escáner
y entradas de
de las pruebas
vulnerabilidades
yLas
salidas y
esperadas deben
enhacer corregir
una variedad los defectos encontrados
de condiciones
36 pruebas
antes se deben
de entregar el sistema en uninstacias
a las ambiente dedepruebas
pruebasy
realista,
producciónpara asegurar que las pruebas son confiables.
 37 Se debe evitar el uso de datos operacionales que contengan
información de datos personales o cualquier otra
información confidencial para propósitos de prueba. Si esta
información de datos personales u otra información
confidencial se usa para propósitos de las pruebas, todos los
detalles y contenido sensibles se deberían proteger
eliminándolos o modificándolos, la información operacional
se debe borrar del ambiente de pruebas inmediatamente
después de finalizar las pruebas.

38 Debe haber una autorización separada cada vez que se copia

información operacional a un ambiente de pruebas.

39 El sistema debe evidenciar que, a través de pruebas de

40 vulnerabilidad,
El implementadorgarantiza la seguridad
del sistema de la información.
de información, debe
Estas pruebas deben suministrar evidencia
suministrar las evidencias de que se han hecho de que se usaron
pruebas
umbrales de seguridad para establecer niveles mínimos
suficientes para vigilar que no exista contenido malicioso
aceptables
intencional de calidad
y no de la seguridad
intencional y de lade
en el momento privacidad.
la entrega.

OWASP - Se
deben cumplir
con los controles
relativos a
OWASP 41 A1– Inyección: Las fallas de inyección, tales como SQL, OS, y
42 LDAP, ocurren
A2–Pérdida de cuando datos no
Autenticación confiables
y Gestión son enviados
de Sesiones: Las a un
intérprete
funciones de la aplicación relacionadas a autenticacióndatos
como parte de un comando o consulta. Los y
hostiles delsesiones
gestión de atacanteson
pueden engañar al intérprete
frecuentemente y
implementadas
ejecutar comandos
incorrectamente, no intencionados
permitiendo o accedercomprometer
a los atacantes datos no
autorizados.
contraseñas, claves, token de sesiones, o explotar otras
fallas de implementación para asumir la identidad de otros
usuarios.

43 A3–Secuencia de Comandos en Sitios Cruzados (XSS): Las

44 fallas XSS ocurren
A4 – Referencia cada vez
Directa que una
Insegura aplicación
a Objetos: Unatoma datos
referencia
no confiables
directa y los
a objetos ocurreenvía al navegador
cuando un web sin
desarrollador una expone
45 A5– Configuración
validación de Seguridad
y codificación apropiada. Incorrecta:
XSS permite Una buena
a los tal
una referencia
seguridad a
requiere un objeto de
tener Sensibles:
definidaimplementación
eMuchas
implementada interno,
una
46 atacantes
A6
como ejecutar
–Exposición
un fichero, secuencia
dedirectorio,
Datos de comandos
oaplicación,
base de datos. en el navegador
aplicaciones
Sin untrabajo,
chequeo
configuración
de
web la víctima
no protegen segura
los cuales para la
pueden
adecuadamente secuestrar
datos marcos
las de
sesiones
sensibles tales de
47 de control
A7–Ausencia
servidor de de acceso
de Control
aplicación, u otra
de protección,
Acceso
servidor web, a las
baselos atacantes
Funciones:
de datos, La
y
usuario,
como
pueden destruir
números
manipular sitios web,
de tarjetas o dirigir
deverifican al
créditopara
estas configuraciones
referencias usuario
olos hacia
credenciales
acceder de sitio
un
datos no
mayoría
plataforma.
malicioso. de aplicaciones
Todas estas web derechos
deben ser de
autenticación.
autorizados.
acceso a nivel Los atacantes
de función antes pueden robar
de hacer visible o modificar tales
definidas,
datos para implementadas, y mantenidas queen porlalo
yaidentidad misma
interfaz
general de llevar
no usuario.
son
a cabo
seguras
fraudes,
A pesar
por de esto,
defecto.
roboslas de
Esto aplicaciones
incluye
u otros
mantener
delitos.
necesitan Muchas
verificar aplicaciones
el control de web no protegen
acceso en librerías
el servidor
todo el software
adecuadamente actualizado,
datos sensibles incluidas
tales las
como números de de
código
cuando
utilizadasse accede
por la a cada
aplicación. función. Si las solicitudes de acceso
tarjetas de crédito
no se verifican, los oatacantes
credencialespodrán de autenticación.
realizar peticiones Los sin
atacantes pueden robar
la autorización apropiada. o modificar tales datos para llevar a
cabo fraudes, robos de identidad u otros delitos. Los datos
sensibles requieren de métodos de protección adicionales
tales como el cifrado de datos, así como también de
precauciones especiales en un intercambio de datos con el
navegador.
 48 A8–Falsificación de Peticiones en Sitios Cruzados (CSRF): Un
ataque CSRF obliga al navegador de una víctima autenticada
a enviar una petición HTTP falsificada, incluyendo la sesión
del usuario y cualquier otra información de autenticación
incluida automáticamente, a una aplicación web vulnerable.
Esto permite al atacante forzar al navegador de la víctima
para generar pedidos que la aplicación vulnerable piensa
son peticiones legítimas provenientes de la víctima.

49 A9–Uso de Componentes con Vulnerabilidades Conocidas:

50 Algunos componentes
A10–Redirecciones tales como
y reenvíos las librerías,
no validados: Laslos
aplicaciones
frameworks
web frecuentemente redirigen y reenvían a lossiempre
y otros módulos de software casi usuarios
Desarrollo funcionan
hacia otrascon todosolos
páginas privilegios.
sitios Si se ataca
web, y utilizan datosunno
Externo componente
confiables para vulnerable
determinar estolapodría
páginafacilitar la intrusión
de destino. Sin una en
51 el
El servidor
equipo de
validación o una perdida
implementación
apropiada, seria de datos.
del sistema
los atacantes puedenLas aplicaciones
deredirigir
información
a las
que
debe utilicen
disponer
víctimas componentes
hacia del tiempo
sitios con vulnerabilidades
dentro
de phishing odel cronograma
malware, conocidas
o utilizar
debilitan
establecidolasydefensas
reenvíos para el sistema
acceder de la información
de aplicación
páginas y permiten
contratado
no autorizadas. ampliar el
para que
rango de posiblesde
los profesionales ataques e impactos. Nacional de Salud
la Superintendencia
realicen la validación al cumplimiento de los requisitos de
Seguridad antes descritos. La Superintendencia realizará
pruebas de Web penetration Testing, análisis de
vulnerabilidades o ethical hacking según sea el caso, en la
fase de pruebas y despliegue; el equipo de implementación
deberá llevar a cabo las tareas o correcciones que puedan
generarse como resultado de las validaciones efectuadas
por la Superintendencia Nacional de Salud.

52 La Supersalud proveerá las herramientas especializadas para

llevar a cabo las pruebas referenciadas en el párrafo
anterior, sin embargo, es responsabilidad del contratista
proveer el canal de acceso mediante el cual la Supersalud
pueda conectarse con la aplicación a la cual se le realizarán
las diferentes pruebas de Testing enunciadas en este
capítulo.

53 Se deben definir acuerdos de licenciamiento, propiedad de

los códigos y derechos de propiedad intelectual.

54 Se deben definir requisitos contractuales para prácticas

55 seguras
Se debe de diseño,documentación
entregar codificación, pruebas, ensayos
eficaz del de de
ambiente
aceptación para determinar la calidad y
construcción usado para crear entregables. exactitud de los
entregables.

Diseño
56 Las aplicaciones deben poder ejecutarse sobre las dos
57 versiones más recientes
Se debe establecer en todos
un control sus componentes
de versiones para cualquier
(software base, bases de datos,
tipo de aplicaciones. (DevOps). frameworks de desarrollo,
etc) y se debe garantizar dentro de los acuerdos de niveles
58 del servicio de
Asegurarse conque
los el
proveedores el soporte
almacenamiento para
de los al menos
detalles de lalas
dos versiones de software siguientes a su salida a
transacción esté afuera de cualquier entorno accesible
producción.
públicamente, por ejemplo, en una plataforma de
almacenamiento existente en la intranet de la organización,
y no retenido ni expuesto en un medio de almacenamiento
accesible directamente desde Internet.

59 La coordinación de aplicaciones junto con el procedimiento

de control de versiones debe permitir realizar la trazabilidad
de los cambios realizados en las mismas y el control estricto
de las versiones en los diferentes ambientes (desarrollo,
pruebas y producción)

60 El acceso a los diferentes ambientes (desarrollo, calidad o

pruebas y producción) deben estar completamente
segregados y los proveedores y/o desarrolladores no deben
tener acceso al ambiente de producción, en caso de ser
requerido el acceso al ambiente de desarrollo este deberá
estar justificado por el coordinador del área y/o por el jefe
de la Oficina de Tecnologías de la Información y su acceso
será controlado y supervisado por personal de planta de la
OTI, bajo ninguna circunstancia se realizaran ajustes al
ambiente de producción sin pasar por los otros dos
ambientes ni por el procedimiento de control de versiones
respectivo.

61 Todo intercambio de información realizado entre

62 aplicaciones
Es requerido se
querealizará deaplicaciones
todas las manera automática desde las
sean desarrolladas
mismas aplicaciones, con el fin de reducir las posibilidades
de manera nativa sobre el estándar IPv6 con compatibilidad
de error
para humano y la pérdida de confidencialidad e
IPv4.
integridad de la información, para ello se usará el protocolo
HTTPS con Rest- Bearer Token y sus características de
seguridad.
 PROVISIÓN DE SOLUCIONES TECNOLÓGICAS

REQUERIMIENTOS DE SEGURIDAD PARA APLICACIONES

ación como protocolo de seguridad en el desarrollo de las aplicaciones en la Superintendencia Nacional de Salud, favor leer ca
requisitos diligenciar el campo no aplica con una "x" y hacer la justificación de la exclusión

Mandatorio para la salida en

Implementado Permite salida a producción
Justificación Exclusión. vivo
SI NO SI NO SI
 CÓDIGO RSFT03

VERSIÓN 2

Nacional de Salud, favor leer cada uno de los requisitos y en caso de que no vayan a incluir algunos de los
usión

rmite salida a producción Fecha de

Responsable Observaciones
Implementación
NO