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
 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

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).

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

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).

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

Fecha última modificación: Noviembre 2021
Fecha próxima revisión: Noviembre 2024
 Requerimientos de Seguridad de la Información

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.

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

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.

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

Fecha última modificación: Noviembre 2021
Fecha próxima revisión: Noviembre 2024
 Requerimientos de Seguridad de la Información

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).

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

Fecha última modificación: Noviembre 2021
Fecha próxima revisión: Noviembre 2024
 Requerimientos de Seguridad de la Información

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

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.

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

Fecha última modificación: Noviembre 2021
Fecha próxima revisión: Noviembre 2024
 Requerimientos de Seguridad de la Informació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.

ID Req. RSI_05 Versión <1.0>

Nombre Requerimiento de auditoría

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

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.

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

Fecha última modificación: Noviembre 2021
Fecha próxima revisión: Noviembre 2024
 Requerimientos de Seguridad de la Información

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.

ID Req. RSI_06 Versión <1.0>

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:
4706-Requerimientos de Seguridad de la Información Página 8 de 24
Fecha última modificación: Noviembre 2021
Fecha próxima revisión: Noviembre 2024
 Requerimientos de Seguridad de la Información

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

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

Fecha última modificación: Noviembre 2021
Fecha próxima revisión: Noviembre 2024
 Requerimientos de Seguridad de la Información

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

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

Fecha última modificación: Noviembre 2021
Fecha próxima revisión: Noviembre 2024
 Requerimientos de Seguridad de la Información

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.

ID Req. RSI_07 Versión <1.0>

Nombre Requerimiento de clasificación y confidencialidad de la información

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

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.

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

Fecha última modificación: Noviembre 2021
Fecha próxima revisión: Noviembre 2024
 Requerimientos de Seguridad de la Información

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.

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

Fecha última modificación: Noviembre 2021
Fecha próxima revisión: Noviembre 2024
 Requerimientos de Seguridad de la Información

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.

ID Req. RSI_08 Versión <1.0>

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.

ID Req. RSI_09 Versión <1.0>

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.

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

Fecha última modificación: Noviembre 2021
Fecha próxima revisión: Noviembre 2024
 Requerimientos de Seguridad de la Información

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

ID Req. RSI_09 Versión <1.0>

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.

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

Fecha última modificación: Noviembre 2021
Fecha próxima revisión: Noviembre 2024
 Requerimientos de Seguridad de la Información

ANEXOS
Anexo 1: Lineamientos de arquitectura de seguridad

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

Fecha última modificación: Noviembre 2021
Fecha próxima revisión: Noviembre 2024
 Requerimientos de Seguridad de la Información

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.

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

Fecha última modificación: Noviembre 2021
Fecha próxima revisión: Noviembre 2024
 Requerimientos de Seguridad de la Información

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)

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

Fecha última modificación: Noviembre 2021
Fecha próxima revisión: Noviembre 2024
 Requerimientos de Seguridad de la Información

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.

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

Fecha última modificación: Noviembre 2021
Fecha próxima revisión: Noviembre 2024
 Requerimientos de Seguridad de la Información

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

vulnerabilidad Nivel Alto
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.

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

Fecha última modificación: Noviembre 2021
Fecha próxima revisión: Noviembre 2024
 Requerimientos de Seguridad de la Información

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
vulnerabilidad Nivel Alto

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.

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

Fecha última modificación: Noviembre 2021
Fecha próxima revisión: Noviembre 2024
 Requerimientos de Seguridad de la Información

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
vulnerabilidad Nivel Medio
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.

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

Fecha última modificación: Noviembre 2021
Fecha próxima revisión: Noviembre 2024
 Requerimientos de Seguridad de la Información

 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
vulnerabilidad Nivel Medio
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.

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

Fecha última modificación: Noviembre 2021
Fecha próxima revisión: Noviembre 2024
 Requerimientos de Seguridad de la Información

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.

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

Fecha última modificación: Noviembre 2021
Fecha próxima revisión: Noviembre 2024
 Requerimientos de Seguridad de la Información

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

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

Fecha última modificación: Noviembre 2021
Fecha próxima revisión: Noviembre 2024