Requerimientos de Seguridad de La Información

Procedimiento
Documento 4706
Requerimientos de Seguridad de la
Información
Información del Documento

El siguiente documento, son los requerimientos que solicita seguridad de
Objetivo
la información que deben ser cubiertos por los sistemas y aplicativos.
Cas. Documento que aplica directamente a los sistemas y aplicativos.
Información de la Versión
Fecha Elaboración Noviembre 2021
Fecha Última Modificación Noviembre 2021
Fecha Próxima Revisión Noviembre 2024

Responsable del
Jefe Ciberseguridad – Mario Alday L.
documento
Equipo Desarrollador Área Ciberseguridad
Revisor Aprobador
Nombre: Fecha: Nombre: Carlos Monroy Fecha: Noviembre 2021
Cargo: Cargo: Oficial de Ciberseguridad y Seguridad de la Información

Nombre: Fecha: Nombre: Fecha:
Cargo: Cargo:
Requerimientos de Seguridad de la Información
Responsables de la ejecución
Los responsables para alinearse con estos requerimientos son toda área responsable
de implementar servicios o aplicativos dentro de CAS.
Desarrollo
2.1 Requerimientos.
2.1.1 Requerimientos de Seguridad de la Información

Estos requerimientos son los solicitados por Seguridad de la información y deben ser
cubiertos por los sistemas o aplicativos. Cualquier variación en ellos debe ser validado
oportunamente con Seguridad de la Información.
ID Req. RSI_01 Versión <1.0>
Nombre Requerimiento de identificación
Descripción El sistema debe tener las siguientes características relacionadas con

breve la identificación de los usuarios:
El sistema debe permitir la creación de User ID de al menos 8

RSI_01.1 caracteres
RSI_01.2 El sistema no debe permitir la creación de User ID duplicado.
RSI_01.3 El sistema no debe permitir la creación de User ID en blanco.
El sistema debe permitir la des-habilitación y/o eliminación de

RSI_01.4 identificadores de usuarios.
Todos los identificadores de usuario (User ID), que no se hayan utilizado

durante un período máximo de 90 días calendario (plazo de inactividad)
deben ser deshabilitados. (de forma automática o manual).
RSI_01.5 Si el proceso anterior es:
- Automático: el sistema/aplicación debe poseer parámetro de
configuración de plazo.
4706-Requerimientos de Seguridad de la Información Página 2 de 24

Fecha última modificación: Noviembre 2021
Fecha próxima revisión: Noviembre 2024
Nombre Requerimiento de identificación

breve la identificación de los usuarios:
- Manual: debe existir un procedimiento documentado de dicho
proceso o un log que permita el control.
Transcurrido un período de 90 días desde la fecha en que el
identificador fue deshabilitado por inactividad (ver puntos anteriores), sin
que exista ninguna reclamación, el identificador será borrado salvo causa
justificada (enfermedad, vacaciones, maternidad, otro.)
El sistema debe permitir el ingreso de campos descriptivos durante

RSI_01.6 la creación del usuario (ej. Nombre, Apellidos, Empresa, RUT, Unidad de
Negocio, Cargo, etc.)
En el caso de utilizar en el desarrollo del sistema paquetes de

software y/o sistemas propietarios, se deben cambiar los usuarios que
RSI_01.7 están definidos por defecto, tales como Administrador, Director, Auditor,
Invitado, SA, etc.
Eliminar las cuentas de usuario de proveedores que no sea necesario

mantener para la operación del sistema. En caso de ser necesario
RSI_01.8 mantenerlas, cambiar sus contraseñas de inmediato, una vez sea puesta en
producción la aplicación.
El sistema debe permitir creación de User ID con fecha de

RSI_01.9 caducidad/vigencia definida (personal externo, pasante, alumno en
práctica, consultora, proveedor temporal).
Nombre Requerimiento de autenticación

breve la autenticación de los usuarios:
El sistema debe requerir autenticación con User Id y contraseña.
RSI_02.1 Además de requerir contraseña esta debe contener un algoritmo

de cifrado fuerte. Base64 no tiene fortaleza por lo que se deben
implementar algoritmos como NTLM y SHA1 (RSA).

Las pantallas de presentación de los sistemas previas al mecanismo

de autenticación deben mostrar la mínima información necesaria.
- Nombre del Sistema
RSI_02.2
- User ID (campo)
- Contraseña (Campo)
- Link de ayuda si “Olvidó la contraseña” (Opcional)
La autenticación de un usuario se debe realizar una vez que toda la

RSI_02.3
información necesaria para la validación haya sido proporcionada.
Frente a una autenticación fallida se debe entregar un mensaje

genérico (por ejemplo “Autenticación Fallida, ingrese nuevamente”), sin
RSI_02.4 incluir mensajes específicos que puedan indicar cuál ha sido la secuencia
del proceso que ha fallado, como por ejemplo, “Password Errónea”,
“Usuario no existe”, etc.
El sistema debe bloquear los User ID si hay 5 intentos fallidos de

RSI_02.5
autenticación seguidos en menos de 10 a 60 minutos.
Una vez completado el proceso de autenticación, se debe presentar

RSI_02.6 al usuario la fecha y hora del anterior acceso satisfactorio, así como el
número de autenticaciones fallidas realizadas desde esta fecha.
Nombre Requerimiento de contraseñas

breve las contraseñas de los usuarios:
El sistema debe obligar a los usuarios a cambiar su contraseña al

RSI_03.1
conectarse por primera vez.
El sistema debe obligar a todos los usuarios a cambiar su contraseña

RSI_03.2
inmediatamente después que el usuario solicite reseteo de su contraseña.

El sistema debe permitir la configuración del parámetro del plazo de

días para el cambio de contraseña, y dicho parámetro se debe configurar
RSI_03.3
para forzar el cambio de las contraseñas que no se hayan modificado en un
periodo mayor a 90 días.
El sistema debe permitir que el usuario modifique su contraseña

RSI_03.4 cuando éste lo requiera con la limitación de que pueda cambiarla más de
una vez al día para evitar que recicle contraseñas para volver a la original.
Al realizar el cambio de contraseña, el sistema debe poseer las

siguientes funcionalidades:
- Las contraseñas no se deben visualizar en pantalla durante la
introducción de las mismas.
- Se debe solicitar la contraseña antigua para permitir el cambio de
contraseña.
RSI_03.5 - Se debe solicitar confirmación de la nueva contraseña para
permitir el cambio de contraseña.
- No se debe permitir la reutilización de las 5 últimas contraseñas
que el usuario haya utilizado.
- Las contraseñas deben tener un largo mínimo de 10 caracteres.
- El sistema debe exigir que la contraseña tenga a lo menos un
número y una mayúscula.
Las contraseñas se deben almacenar, transmitir e ingresar cifradas,

bajo un algoritmo de hashing (sistema de encriptación unidireccional).
RSI_03.6 Mínimo deben usar NTLM o SHA1, por otro lado base64 queda
descartado al ser un algoritmo que permite realizar reversa del texto
fácilmente.
Tanto para el cifrado de contraseñas, acceso desde redes internas y

externas, y transmisión de datos confidenciales utilice un cifrado sólido, a
RSI_03.7
través de tecnologías tales como SSH, VPN o TLS (validar versiones
aceptadas a la fecha).

Nombre Requerimiento de control de accesos

breve al control de acceso de los usuarios:
El sistema debe poseer control de acceso basado en el perfilamiento

de las funcionalidades, por lo tanto, el sistema debe otorgar acceso a la
RSI_04.1 información mediante la agrupación de permisos que conformen perfiles,
de manera que nunca se asignen los permisos uno a uno directamente a
usuarios individuales.
El sistema debe permitir realizar una adecuada segregación de

funciones en forma única y mediante la definición de perfiles y la asociación
de usuarios a estos.
Usuarios funcionales:
• áreas de negocio que utilizan el sistema (usuarios)
• monitoreo de accesos y actividad de los usuarios (supervisores a
nivel funcional)
Administradores:
• Administración y operación del sistema
(cambios de margen Utilidad, Iva, comisiones etc)
RSI_04.2 • Desarrollo y mantenimiento del sistema (indexación de bases,
respaldos, proceso de cierre, etc)
• Administración de seguridad (generación de perfiles, usuarios,
generación de informes y logs de auditoría)
• Auditoría de seguridad (visualizador de transacciones, generador
de informes de usuarios y recolección de archivos de logs de auditoría)
La asignación de un perfil a un usuario debe ser en estricta
coherencia con el cargo o función que el usuario debe desempeñar.
Para el caso de sistemas utilizados por colaboradores de Clínica
Alemana, éstos deben poder integrarse a los grupos dinámicos de Azure
Active Directory para poder entregar los permisos mediante el esquema de
roles de la aplicación.

Las áreas de negocio usuarias del sistema deben definir las

funcionalidades que conformarán un perfil para cada cargo que requiera
acceso. Sobre esta definición el área usuaria debe generar la matriz de
perfiles del sistema
El sistema debe borrar la información en pantalla y suspender las

RSI_04.3
sesiones que tengan un tiempo de inactividad igual o superior a 30 minutos.
El sistema no debe presentar al usuario opciones o funcionalidades

RSI_04.4
a las que no tenga acceso.
Dependiendo del sistema, se deben establecer ventanas de tiempo

RSI_04.5
para acceder al sistema (sólo en horario laboral, días laborales, etc ).
La información contenida en los sistemas de información grabados

RSI_04.6 en nubes o sistemas externos de un proveedor, deben estar aislados a nivel
de arquitectura de los sistemas de otros clientes de la nube o del proveedor.
En el caso de envíos de comunicaciones oficiales a paciente, estas

RSI_04.6 deben realizarse mediante canales seguros como correos electrónicos
firmados para garantizar la autenticidad del contenido y remitente.
Nombre Requerimiento de auditoría

breve el control de acceso de los usuarios:
El sistema debe generar log de auditoría, en formato legible con

RSI_05.1
acceso expedito al registro de auditoría almacenado.
El log de acceso debe registrar todos los intentos válidos e inválidos

RSI_05.2
de conexión al sistema.
El log de administración debe registrar todos los cambios realizados

RSI_05.3
a los parámetros de configuración de seguridad.

El log de administración debe registrar toda la actividad de accesos

RSI_05.4
(Altas-Bajas-Modificación de usuarios).
El log de administración debe registrar la imagen anterior y posterior

RSI_05.5
al cambio realizado (parámetros de seguridad o cambio de perfil).
El log transaccional debe registrar toda la actividad realizada por un

RSI_05.6
usuario (registra la imagen anterior y posterior a un cambio realizado)
Los logs de auditoría deben estar protegidos de modificaciones y

RSI_05.7 deben existir controles para detectar si los mecanismos han sido violados y
los logs han sufrido manipulación.
Los registros de log deben contener, a lo menos, la siguiente

información:
• User Id de la persona, programa o elemento que origina el evento
que se registra.
RSI_05.8
•Fecha y hora del elemento que origina el evento que se registra.
• Descripción o motivo del evento que se registra: acceso, caída de
un sistema, error que se ha producido, cambio de parámetros, etc.
• Tipo de Acción: Autorizado, Rechazado
Implemente pistas de auditoría en la aplicación con la actividad de

usuarios, en especial de usuarios privilegiados (Identificación del usuario;
RSI_05.9 tipo de evento; fecha y hora; indicación de éxito o fallo; origen del evento;
identificación o nombre de los datos componentes del sistema o recursos
afectados).
Se debe evaluar la necesidad de enviar el log a herramienta de

RSI_05.10
monitoreo centralizado.
Nombre Requerimiento de seguridad de plataforma WEB
Descripción El sistema debe tener las siguientes características relacionadas

breve con la seguridad en plataforma WEB:
El Diseño y la Arquitectura de la plataforma debe ser revisada y

RSI_06.1
certificada por el área de Arquitectura de Sistemas.
El Servidor WEB debe estar en un segmento de red protegido por

RSI_06.2
un Firewall.
El Servidor WEB debe estar en un segmento de red protegido con

RSI_06.3
un IDS/IPS/WAF.
Para los sistemas cuyo acceso estará disponible desde Internet, es

obligatorio la ejecución de un test del tipo Ethical Hacking por parte de una
RSI_06.4 empresa de seguridad, antes de entrar en producción. El resultado de
dicho test será revisado por Seguridad de la Información quien gestionará
las vulnerabilidades con el JP a cargo del proyecto para su resolución.
El código de programación del sistema debe cumplir con las 10

principales reglas (top ten) del Open Web Application Security Project
(OWASP; 'Proyecto de seguridad de aplicaciones web abiertas').
Dentro de las vulnerabilidades Owasp se pueden encontrar:
Referencias de
Vulnerabilidad
Mitigación
RSI_06.5
Owasp mitigación
de Inyección
Inyección
Mitigación a través
de Queries
parametrizadas

Owasp mitigación
Pérdida de Autenticación de perdida de
autenticación
Mitigación de
Exposición de Datos
exposición de
Sensibles
datos sensibles
Mitigación de
Entidades Externas XML
Entidades Externas
(XXE)
XML
Mitigación Perdida
Pérdida de Control de
de Control de
Acceso
Acceso
Angular mitigación
Cross-Site Scripting (XSS)
de XSS
Uso de Componentes con

Vulnerabilidades Conocidas:
El detalle, explicación y mitigación de cada vulnerabilidad puede

ser encontrado en la guía de Owasp adjunta:
OWASP-Top-10-201
7-es.pdf

Todo sitio que presente datos de paciente o que maneje inicios de

RSI_06.6
sesión, debe contar con un certificado digital SSL válido.
RSI_06.7 Se debe restringir el acceso al código fuente de programas.
Revisión de código antes del envío a producción o a los clientes, a

RSI_06.8
fin de identificar posibles vulnerabilidades de la codificación.
Las aplicaciones deben proveer validaciones de ingreso de datos de

RSI_06.9
entrada, manejo de errores.
No incluir las llaves de cifrado y contraseñas en el código fuente de

RSI_06.10
la aplicación o ser desplegadas en logs o pantallas.
Las pruebas del sistema deberán incluir, de ser necesario, pruebas

RSI_06.11 de: instalación, volumen, stress, rendimiento, almacenamiento,
configuración, funcionalidad, seguridad, vuelta atrás.
La etapa de pruebas debe verificar que no exista impacto en las

RSI_06.12 aplicaciones con las cuales va a interactuar el nuevo desarrollo o
modificación de producto existente.
Nombre Requerimiento de clasificación y confidencialidad de la información

breve la clasificación y confidencialidad de la información:
El Propietario de la Información debe estar formalmente definido.

RSI_07.1
(presentación de acta)
La información utilizada por el sistema debe estar clasificada por el

Propietario de la Información según las categorías definidas en la
RSI_07.2 normativa corporativa.

Se puede realizar la clasificación ejecutando el siguiente formulario:

https://redcap.alemana.cl/surveys/?s=HNFTJFEF9F
La información RESERVADA o RESTRINGIDA y todos los activos que

RSI_07.3 la tratan serán identificados y registrados en un documento o planilla para
ser entregado a seguridad de la información.
Las pantallas de despliegue de información clasificada deben

RSI_07.4 mostrar su categoría de clasificación (Restringida, Reservada, Uso Interno,
con letra mayúscula, tipo letra Arial, tamaño 14, negrita, color negro).
Las pantallas que despliegan información clasificada como

Reservada o Restringida debe incluir bajo el etiquetado el siguiente texto:
RSI_07.5
Esta información sólo puede ser distribuida a las personas autorizadas,
formal y previamente, por su Propietario.
Las pantallas que despliegan información clasificada como Uso

Interno debe incluir bajo el etiquetado el siguiente texto:
RSI_07.6
Esta información sólo puede ser distribuida entre los trabajadores
de la Compañía.
Identifique los criterios para purga de datos de acuerdo con el

RSI_07.7 servicio asociado, con la finalidad de eliminar información que no sea
necesaria mantener en línea.
Todos los cambios en producción deben estar debidamente

RSI_07.8 documentados y autorizados por la contraparte usuaria con sus pruebas
realizadas y certificadas
Incluir en contratos con terceras partes las cláusulas de seguridad

RSI_07.9 exigidas por Clínica alemana (ej.: cláusula de confidencialidad, derecho de
auditabilidad).
RSI_07.10 Se debe documentar la estrategia de restauración del servicio.
Se debe aprobar la estrategia de restauración de los servicios ante

RSI_07.11 contingencia y que esta cumpla con los niveles de servicios (SLA) requeridos
por el negocio.

Se debe obtener información oportuna sobre las vulnerabilidades

RSI_07.12
técnicas de las tecnologías de información que están siendo utilizadas.
Se debe evaluar la exposición de la organización a tales

RSI_07.13 vulnerabilidades y tomar las medidas apropiadas para tratar los riesgos
asociados.
Requerimientos de Control de Cambios, Mantenimiento y Actualización

Nombre
de versiones.
Descripción El sistema debe tener las siguientes características relacionadas con las
breve modificaciones a los sistemas de información:
Se deben especificar las políticas de respaldo utilizadas, indicando medio

RSI_08.1 de almacenamiento, tipo de respaldo, duración del respaldo y su método
de destrucción.
Indicar política de actualizaciones y parches de seguridad. Se debe

RSI_08.2 señalar cada cuanto se actualizan las plataformas que dan soporte al
sistema y cada cuanto se aplican los parches de seguridad.
Detallar cuales son las segregaciones de ambientes de arquitectura

RSI_08.3 que poseen (EJ: Desarrollo, control de calidad, preproducción,
producción) que existen.
Nombre Requerimientos de Control de Control de Interfaces y de Datos
Descripción El sistema debe tener las siguientes características relacionadas

breve con el control de interfaces:
Las interfaces contienen algoritmos de encriptación o viajan a

RSI_09.1
través de canales cifrados como VPN’s.

Existen controles ante fallos en las comunicaciones que permitan

RSI_09.2
detectar transmisiones erróneas, incompletas o duplicadas
RSI_10 Requerimientos de Continuidad Operacional
Nombre Requerimientos de Control de Control de Interfaces y de Datos
El sistema debe estar respaldado por un plan de continuidad

Descripción
breve operacional que permita seguir utilizando sus servicios ante un corte
parcial:
Debe existir un servidor secundario de procesamiento que permita

continuar funcionando en caso de un incidente o desastre. Este punto
RSI_09.1
también aplica para los sistemas situados en la nube donde se debe
operar con otro servidor de respaldo para la continuidad.
Los servidores primarios y secundarios de contingencia deben

RSI_09.2
poder sincronizarse ante la vuelta y resolución de incidentes.
Los sistemas externos a CAS deben contar con un soporte o canal

RSI_10.3 de contacto que pueda estar disponible 24 horas x 7 días en caso de tener
incidentes.
Deben existir clausulas y posibilidad técnica de poder rescatar o

RSI_10.4
migrar la información a distintas plataformas si se requiere.

ANEXOS
Anexo 1: Lineamientos de arquitectura de seguridad

Anexo 2: Datadome - Herramienta para seguridad perimetral para

aplicaciones Web
https://datadome.co/
Herramienta que provee protección contra-bots. Entre sus características están:

- protección para secuestro de cuentas
Web scraping (robots que extraen información de la web)
Denegación de servicio (DDoS de capa 7)
Credentias Stuffing & craking, ataques de fuerza bruta para usuario y password
Sobrecargas del servidor
Sql inyection
Creación de cuentas falsas
Scan de seguridad
Esta integrada en todos los sitios con dominio clinicaalemana.cl y analiza el trafico con modelos
de IA para identificar bots y otros ataques
A nivel técnico para los sitios web basta con incluir un script, mientras que para protección del
lado del servidor se requiere incluir código middelware según la tecnología.

Anexo 2: Análisis Ethical Hacking
1. Objetivo:
Identificar vulnerabilidades de seguridad recogiendo los flujos y la metodología Owasp top 10.
A través del Ethical Hacking y/o un Penetration Testing, se puede detectar el nivel de seguridad
interno y externo de los aplicativos y sistemas de información, lo que permite determinar el
grado de acceso que tendría un atacante con intenciones mailicosas a los sistemas con
información crítica.
2. Marcos de Referencia:
2.1. Vulnerabilidades:
Framework Organización Versión
API Security Top 10 OWASP 2019
CWE ID CWE ID 3.4.1
2.2. Ponderación de criticidad:
Framework Organización Versión
Common Vulnerability Forum of Incident 3.1

Scoring System (CVSS) Response and Security Teams
(FIRST)

3. Niveles de ponderación de criticidad:
Se identifican 5 niveles de criticidad que se desprenden del framework CVSS 3.1:
Riesgo
Crítico
Alto
Medio
Bajo
Informacional
Best Practice
4. Ejemplos de tipos de Vulnerabilidades:
Tipo de
vulnerabilidad Code Injection Nivel Alto
El servicio procesa de manera directa los inputs provenientes desde

Descripción clientes externos sin validar correctamente su contenido, permitiendo, la
inyección de caracteres de control y/o inyección de código malicioso.
Cuando el software permite que la entrada de un usuario contenga

la sintaxis del código, podría ser posible que un atacante elaborara el código
Impacto
de tal manera que alterara el flujo de control previsto del software. Tal
alteración podría llevar a una ejecución arbitraria del código.
Se debe “sanitizar”, parametrizar y validar las entradas al servicio de

Mitigación
manera segura y correcta.

Tipo de Broken User

vulnerabilidad Nivel Alto
Authentication
Se posibilitan ataques de tipo fuerza bruta en diferentes

Descripción procedimientos, como, por ejemplo, validación y extracción masiva de
datos, y enumeración de directorios, archivos o componentes.
Establecer rate limit basado en suscripción de JWT (JSON Web

Token), evitando el uso de la dirección IP de origen como factor de filtro.
Mitigación
En el caso de la enumeración de directorios, archivos y componentes, se
deben establecer quotas de bytes.
Tipo de Lack of Resources & Rate

Limiting
Se identifica que el servicio REST API no mantiene un límite de

Descripción request, y producto de esto, es posible realizar múltiples y consecutivas
invocaciones obteniendo una denegación de servicio e inhabilitando este.
Establecer un “request limit” por usuario o sesión, y realizar

Mitigación pruebas de seguridad sobre los cambios realizados, considerado como
recertificación para ambiente de QA o producción.
Tipo de
vulnerabilidad Insecure Host Domain Nivel Alto
Se detecta que algún proveedor del host y dominio se encuentra

Descripción comprometido y en la lista negra de Google Safe Browsing, esto, debido a
que el sitio alberga código malicioso.
Consumir recursos de un proveedor de servicios comprometido

Impacto (Hackeado) puede vulnerar la seguridad de los sistemas de los cuales
depende e introducir vectores de ataque adicionales.

Cambiar el proveedor de dominio a uno seguro o realizar una

Mitigación
limpieza de los artefactos comprometidos en el dominio.
Uncontrolled Resource
Tipo de Consumption
Se utiliza el tiempo de expiración de JWT en lugar de rate limit,

Descripción
facilitando la evasión de control de consumo.
Utilización de exploits basados en Python u otro lenguaje de

Impacto programación, para evadir la expiración de JWT, logrando realizar múltiples
requests al endpoint, evadiendo el control de seguridad.
Establecer rate limit basado en quota o suscripción de JWT (JSON

Web Token), evitando el uso de la dirección IP de origen como factor de
Mitigación
filtro. La interfaz API debe entregar un estado 429 como resultado, y
bloquear al usuario por tiempo recomendado de 3 minutos o más.
Tipo de
vulnerabilidad Path Traversal Nivel Alto
Consiste en forzar el acceso a ficheros del servidor que están fuera

del directorio raíz (document root) del servicio Web, y no deberían ser
Descripción alcanzables a través del servicio. Un atacante puede manipular una URL de
forma que el sitio web revelará el contenido de ficheros arbitrarios
ubicados en cualquier lugar del servidor web.
Mediante este tipo de ataques, el atacante puede leer directorios y

ficheros que normalmente no debería, y acceder así a información privada
Impacto del servidor como pueden ser ficheros de configuración o scripts.
Para evitar esta vulnerabilidad, se debe eliminar el parámetro no

Mitigación necesario de la petición, ya que no es necesario sean pasados ni por GET ni
POST, para evitar ser modificado por un usuario.

Tipode RelianceonSecurity
vulnerabilidad Nivel Medio
Through Obscurity
Los mecanismos para generación algunos recursos, son fácilmente

Descripción sometidos a fuzzing o ingeniería reversa para identificar el mecanismo de
generación.
Generación particular de diccionarios para ataques de fuerza bruta

Impacto basados en la ID del usuario o en la nomenclatura de nombres de exámenes
médicos.
Utilización de una variable, función o clase que permita generar

Mitigación strings seguros criptográficamente, basados en MD5+Salt u otra función de
hashing.
Tipo de Security
Misconfiguration
 Ausencia de múltiples cabeceras de seguridad, y utilización de

cabeceras basadas en API key.
 Existen múltiples versiones de HTTP habilitados posibilitando ataques
Descripción de tipo HTTP request smuggling, entre otros.
 Al modificar las directivas para invocación de archivos, es posible
obtener información sobre la estructura y los servicios del proyecto, en
formato de full path disclosure.
 Utilizar JWT (JSON Web Token) de forma restrictiva para consumo de
todos los API endpoints, y trasladar el uso de API key a otra capa de
desarrollo (variable de entorno, etc.) o infraestructura. Foco en la
implementación de CORS (Cross-origin Resource Shared) y Bearer
Authentication.
Mitigación
 Deshabilitar el soporte para HTTP/0.9, las conexiones persistentes en
HTTP/1.1, y planificar una migración a HTTP/2.0, deshabilitando el
soporte para la cabecera Upgrade en esta última versión y, de ser
posible, establecer sólo conexiones cerradas, imposibilitando el uso
del valor keep-alive mediante la cabecera Connection.

 realizar las gestiones que sean necesarias; cambiar el componente

para lecturas de archivos por una invocación directa, o sanitizar y
controlar la entrada de datos.
Exposure of Sensitive
Tipode System Information to an
Unauthorized Control
Sphere
Descripción El componente expone públicamente información técnica
Un atacante puede aprovechar esta información para conocer

detalles técnicos sobre la arquitectura de la información almacenada, así ́
Impacto
como también interactuar con la API para intentar realizar consultas no
autorizadas.
Se recomienda configurar el servicio para no exponer información

Mitigación
técnica.
Insecure Transportation
Tipo de
vulnerabilidad Security Protocol Nivel Bajo
Supported (TLS1.0)
TLS 1.0 tiene varios defectos. Un atacante puede causar fallas en la

Descripción conexión y puede desencadenar el uso de TLS 1.0 para explotar
vulnerabilidades como BEAST (Exploit Browser Against SSL / TLS).
Mantener una única versión de TLS (1.3), cifrados soportados por la

Mitigación
versión, y un certificado SSL que no sea Wildcar y autofirmado.
HTTP Strict Transport

Tipo de
vulnerabilidad Security (HSTS) Policy Nivel Bajo
Not Enabled
política de Seguridad de Transporte Estricta de HTTP (HSTS) no está

Descripción
habilitada.

El sitio web de destino se sirve no sólo de HTTP sino también de HTTPS y

carece de aplicación de políticas de HSTS.
El HTTP Strict Transport Security (HSTS) es un mecanismo de política de

seguridad en la web por el cual un servidor web declara que el usuario que
cumple con las normas.
Los agentes (como un navegador web) deben interactuar con él usando

sólo conexiones HTTP (HTTPS) seguras. La política de HSTS es comunicada
por el servidor al agente de usuario a través de un campo de cabecera de
respuesta HTTP llamado "StrictTransportSecurity".
Impacto La política HSTS especifica un período de tiempo durante el cual el agente

de usuario acceder al servidor sólo de forma segura.
Cuando una aplicación web emite la Política HSTS a los agentes de usuario,
los agentes de usuario conformes se comportan de la siguiente manera:
 Convierten automáticamente cualquier enlace inseguro que

haga referencia a la aplicación web en enlaces seguros. (Por
ejemplo, http://example.com/some/page/ será modificado a
https://example.com/some/page/ antes de acceder al servidor).
 Si no se puede garantizar la seguridad de la conexión (por ejemplo, el

certificado TLS del servidor es autofirmado), muestran un mensaje de
error y no permiten que el para acceder a la aplicación web.
Mitigación Configure su servidor web para redirigir las peticiones HTTP a HTTPS.
Tipode
vulnerabilidad Expect‐CT Not Enabled Nivel Best Practice
Descripción ExpectCT no está activado.

La transparencia de los certificados es una tecnología que hace

imposible (o al menos muy difícil) que una CA emita un certificado SSL para
un dominio sin que el certificado sea visible para el propietario de ese
dominio.
Google anunció que, a partir de abril de 2018, si se encuentra con un

Impacto certificado que no se ve en el registro de transparencia de certificados (CT),
se considerará que el certificado es inválido y rechazará la conexión
Configure su servidor web para responder con ExpectCT header.

Mitigación
Expect‐CT: enforce, max‐age=7776000, report‐
uri="https://ABSOLUTE_REPORT_URL"
Tipode MissingX‐XSS‐Protection
vulnerabilidad Nivel Best Practice
Header
falta el encabezado X‐XSS‐Protection, lo que significa que este sitio

Descripción
web podría ser susceptible a un ataque Crosssite Scripting (XSS).
Añade el XXSSProtection
Mitigación header with a value of "1; mode= block".
X‐XSS‐Protection: 1; mode=block
Control de cambios
Versión Elaborado por Páginas Descripción de la Fecha de

revisadas modificación elaboración
1.0 Área Ciberseguridad Todas Versión Inicial Noviembre 2021


Requerimientos de Seguridad de La Información

Cargado por

Copyright:

Formatos disponibles

Requerimientos de Seguridad de La Información

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

Requerimientos de Seguridad de La Información

Cargado por

Copyright:

Formatos disponibles

Procedimiento

Información del Documento

Fecha Última Modificación Noviembre 2021

Fecha Próxima Revisión Noviembre 2024

Nombre: Fecha: Nombre: Carlos Monroy Fecha: Noviembre 2021

Cargo: Cargo: Oficial de Ciberseguridad y Seguridad de la Información

2.1.1 Requerimientos de Seguridad de la Información

ID Req. RSI_01 Versión <1.0>

Nombre Requerimiento de identificación

Descripción El sistema debe tener las siguientes características relacionadas con

El sistema debe permitir la creación de User ID de al menos 8

RSI_01.2 El sistema no debe permitir la creación de User ID duplicado.

RSI_01.3 El sistema no debe permitir la creación de User ID en blanco.

El sistema debe permitir la des-habilitación y/o eliminación de

Todos los identificadores de usuario (User ID), que no se hayan utilizado

4706-Requerimientos de Seguridad de la Información Página 2 de 24

ID Req. RSI_01 Versión <1.0>

Nombre Requerimiento de identificación

Descripción El sistema debe tener las siguientes características relacionadas con

El sistema debe permitir el ingreso de campos descriptivos durante

En el caso de utilizar en el desarrollo del sistema paquetes de

Eliminar las cuentas de usuario de proveedores que no sea necesario

El sistema debe permitir creación de User ID con fecha de

ID Req. RSI_02 Versión <1.0>

Nombre Requerimiento de autenticación

Descripción El sistema debe tener las siguientes características relacionadas con

El sistema debe requerir autenticación con User Id y contraseña.

RSI_02.1 Además de requerir contraseña esta debe contener un algoritmo

4706-Requerimientos de Seguridad de la Información Página 3 de 24

Las pantallas de presentación de los sistemas previas al mecanismo

La autenticación de un usuario se debe realizar una vez que toda la

Frente a una autenticación fallida se debe entregar un mensaje

El sistema debe bloquear los User ID si hay 5 intentos fallidos de

Una vez completado el proceso de autenticación, se debe presentar

ID Req. RSI_03 Versión <1.0>

Nombre Requerimiento de contraseñas

Descripción El sistema debe tener las siguientes características relacionadas con

El sistema debe obligar a los usuarios a cambiar su contraseña al

El sistema debe obligar a todos los usuarios a cambiar su contraseña

4706-Requerimientos de Seguridad de la Información Página 4 de 24

El sistema debe permitir la configuración del parámetro del plazo de

El sistema debe permitir que el usuario modifique su contraseña

Al realizar el cambio de contraseña, el sistema debe poseer las

Las contraseñas se deben almacenar, transmitir e ingresar cifradas,

Tanto para el cifrado de contraseñas, acceso desde redes internas y

4706-Requerimientos de Seguridad de la Información Página 5 de 24

ID Req. RSI_04 Versión <1.0>

Nombre Requerimiento de control de accesos

Descripción El sistema debe tener las siguientes características relacionadas con

El sistema debe poseer control de acceso basado en el perfilamiento

El sistema debe permitir realizar una adecuada segregación de

4706-Requerimientos de Seguridad de la Información Página 6 de 24

Las áreas de negocio usuarias del sistema deben definir las

El sistema debe borrar la información en pantalla y suspender las

El sistema no debe presentar al usuario opciones o funcionalidades

Dependiendo del sistema, se deben establecer ventanas de tiempo

La información contenida en los sistemas de información grabados

En el caso de envíos de comunicaciones oficiales a paciente, estas

ID Req. RSI_05 Versión <1.0>