PUNTO

PENDIENTE ACCION SOLICITADA APLICA/ NO APLICA A CD SERVICIOS Respuesta a banco

02.01_CYBER_v2_ Implementar una solución anti-DoS/DDoS para proteger los componentes del servicio APLICA Rechazar por fecha
MX expuestos a Internet de ataques de denegación de servicio.

Elaborar un escenario específico de indisponibilidad de los equipos y sistemas por

infección de Ransomware dentro del plan de continuidad que incluya todos los
procedimientos relacionados (desarrollarlos en el caso de que no existan):
02.02_CYBER_v2_
- Procedimientos de contención APLICA Rechazar por fecha
MX y aislamiento. - Procedimiento de replataformado de
equipos. - Procedimiento de replataformado de
equipos.

Implementar un control que garantice que el acceso a sistemas e información deL

03.09_CYBER_v2_ BANCO El cual se limita únicamente a equipos corporativos gestionados por el APLICA Rechazar por fecha
MX proveedor. Ejemplo: restricción por dirección IP pública del proveedor, acceso desde
equipo corporativo con certificado digital del proveedor, etc.

Implementar una metodología formal de desarrollo seguro que siga las mejoras
04.01_CYBER_v2_ prácticas de la industria (ejemplo: OWASP), de forma que durante la fase de desarrollo
NO APLICA rechazar por otros
MX no se introduzcan vulnerabilidades intrínsecas a los propios lenguajes de desarrollo
utilizados.

Implementar un mecanismo para que no se utilicen datos reales en los entornos no

04.02_CYBER_v2_ productivos, que pueden ser mecanismos de anonimización mediante algoritmos de
MX anonimización/enmascarado/sanitización de datos o mecanismo para la utilización de NO APLICA rechazar por otros
datos ficticios.

Registrar los logs de los accesos y actividades de los usuarios implicados en el servicio
05.02_CYBER_v2_ prestado. Estos logs deben incluir al menos los siguientes campos: identificador de
APLICA Rechazar por fecha
MX usuario, fecha/hora, resultado del acceso (OK/KO) en el caso de los accesos y
descripción de la actividad en el caso de la actividad.

Implementar un sistema que centralice, correlacione y monitorice los logs de acceso y

05.03_CYBER_v2_ actividad de los usuarios que acceden al entorno del servicio prestado. (Ejemplo: SIEM).
NO APLICA rechazar por otros
MX Además, tanto los accesos como la actividad de los usuarios deberán ser monitorizados
para la detección de incidentes de seguridad.
05.04_CYBER_v2_ Implementar un equipo de personas dedicado a la monitorización, atención y respuesta NO APLICA rechazar por otros
MX de alertas de seguridad para los eventos generados en el entorno del servicio prestado.

Obtener una certificación de seguridad de la información estándar reconocida por la

06.01_CYBER_v2_ industria (ejemplo: ISO 27001, SOC-2, etc.) o realizar una auditoría de seguridad de la
información por parte de un tercero independiente y especializado. Tanto si se obtiene APLICA Rechazar por fecha
MX
una certificación como si se realiza una auditoría independiente, se debe incluir en el
alcance el entorno del servicio prestado.

Implementar una solución antimalware para las estaciones de trabajo del proveedor.
06.06_CYBER_v2_ Esta solución debe incluir protección contra las últimas amenazas identificadas,
APLICA Rechazar por fecha
MX escanear periódicamente las estaciones de trabajo, actualizar las firmas periódicamente
y no debe poder ser deshabilitado en ningún caso por los usuarios finales.

Implementar una solución antimalware para los sistemas relacionados con el servicio
06.07_CYBER_v2_ prestado. Esta solución debe incluir protección contra las últimas amenazas
MX identificadas, escanear periódicamente los sistemas, actualizar las firmas APLICA Rechazar por fecha
periódicamente y no debe poder ser deshabilitado en ningún caso por los usuarios
finales.

Implementar un procedimiento formal de gestión de parches de seguridad que incluya

07.01_CYBER_v2_ al menos aspectos como la identificación, aplicabilidad, pruebas, distribución ordenada NO APLICA rechazar por otros
MX de los parches, etc. y contemple la aplicación de cambios urgentes (ejemplo: instalación
de parche para corrección de vulnerabilidades críticas 0-day).

07.02_CYBER_v2_ Implementar un procedimiento formal de gestión de vulnerabilidades que incluya su

MX identificación, registro, categorización y tratamiento. Se deberán recoger plazos de SI APLICA Rechazar por fecha
resolución de las vulnerabilidades en función de su criticidad.

Realizar un test de intrusión sobre la infraestructura utilizada para la prestación del

07.05_CYBER_v2_ servicio por parte de un tercero independiente y especializado. Este test deberá
MX realizarse anualmente y/o cuando tengan lugar cambios significativos en la SI APLICA Rechazar por fecha
infraestructura.

Implementar una política/procedimiento formal de gestión de claves criptográficas que

08.03_CYBER_v2_ incluya aspectos clave de la gestión del ciclo de vida tales como generación, custodia,
MX revocación, protocolo de diseño criptográfico, algoritmos usados, intercambio y NO APLICA rechazar por otros
medidas de seguridad para el sistema de generación y almacenamiento de claves.
 Implementar y formalizar dentro de una política de seguridad corporativa un
08.05_CYBER_v2_ mecanismo de borrado lógico seguro de la información, esto es, que el proceso sea APLICA Rechazar por fecha
MX irreversible y que, una vez borrada, no se pueda recuperar de ninguna manera.
Ejemplo: borrado de medios a bajo nivel, software específico de borrado seguro, etc.

09.01_CYBER_v2_ Implementar medidas de seguridad perimetral para la protección de las redes externas
APLICA Rechazar por fecha
MX que incluyan una DMZ para la protección y separación de las redes internas.

Elaborar una política formal de accesos remotos que incluya todas las casuísticas para
09.04_CYBER_v2_ los accesos remotos de los empleados a la red del proveedor, identificando los NO APLICA rechazar por otros
MX entornos accesibles y las medidas de seguridad empleadas. Los accesos remotos
deberán protegerse mediante cifrado (ejemplo: mediante VPN).

09.05_CYBER_v2_ Implementar un cortafuegos de aplicación web (WAF) configurado en modo bloqueo

MX con el fin de proteger las aplicaciones expuestas a Internet. APLICA Rechazar por fecha

Elaborar y distribuir una política formal de contraseñas para los usuarios del proveedor
que incluya, al menos, los siguientes aspectos:

- Longitud mínima de 8 caracteres.

- Al menos 3 de las 4 características: minúsculas, mayúsculas, números o símbolos.

03.01_CYBER_v2_
MX APLICA Rechazar por fecha
- La entrega de las nuevas contraseñas debe ser segura y confidencial y deben ser
cambiadas tras el primer login.

- Las nuevas contraseñas no pueden haber sido usadas en los últimos 365 días y
deben ser validadas contra una lista negra con el fin de evitar palabras predecibles.

Elaborar y distribuir una política formal de contraseñas para los usuarios del Grupo
Santander que incluya, al menos, los siguientes aspectos:

- Longitud mínima de 8 caracteres.

03.02_CYBER_v2_
MX APLICA Rechazar por fecha
 - Al menos 3 de las 4 características: minúsculas, mayúsculas, números o símbolos.
03.02_CYBER_v2_
MX APLICA Rechazar por fecha
- La entrega de las nuevas contraseñas debe ser segura y confidencial y deben ser
cambiadas tras el primer login.

- Las nuevas contraseñas no pueden haber sido usadas en los últimos 365 días y
deben ser validadas contra una lista negra con el fin de evitar palabras predecibles.

O, en su defecto, integrar la autenticación de los usuarios con el directorio corporativo

03.03_CYBER_v2_ Implementar un método robusto de autenticación para la conexión/comunicación de

NO APLICA rechazar por otros
MX los sistemas de Grupo Santander que incluya cifrado y, si aplica, contraseñas robustas.

Implementar un procedimiento formal de gestión de usuarios que cubra al menos los

03.04_CYBER_v2_ procesos de alta, baja, modificación y revisión periódica de los usuarios. En el proceso
APLICA Rechazar por fecha
MX de revisión periódica deberá generarse un informe/registro con los resultados de cada
revisión.

Implementar una solución para que los identificadores de los usuarios finales sean
únicos y unívocos, esto es, que identifiquen unívocamente a las personas físicas que los
03.05_CYBER_v2_ utilizan. En la medida de lo posible, intentar que la identificación unívoca de personas
MX físicas se realice internamente dentro del proveedor y evitar la utilización de datos APLICA Rechazar por fecha
personales para la construcción de los identificadores (ej. pepe12345 en lugar de
jose.pérez.lópez).

En caso de no ser necesario su uso, desactivar todas las cuentas genéricas. En caso de
03.06_CYBER_v2_ serlo, elaborar y mantener un inventario de todas las cuentas genéricas, registrando la
APLICA Rechazar por fecha
MX justificación de su uso y, en caso de ser utilizadas por una o varias personas físicas, los
responsables nominales de dichas cuentas.

Implementar un mecanismo de autenticación de doble factor para los accesos de los

usuarios privilegiados.

03.07_CYBER_v2_ El doble factor deberá ser una combinación de 2 de los siguientes 3 ejes:
MX NO APLICA Rechazar por otros
- Algo que se sabe (ejemplo: contraseña)
- Algo que se tiene (ejemplo: token físico)
- Algo que se es (ejemplo: huella dactilar)

Implementar un procedimiento formal de gestión de incidentes de seguridad que

05.01_CYBER_v2_ incluya al menos la detección, clasificación, escalado, resolución y lecciones aprendidas
MX de todos los incidentes de seguridad, y que incluya canales y plazos de comunicación APLICA Rechazar por fecha
especialmente para los incidentes relacionados con el tratamiento de los datos de
carácter personal de clientes o empleados de Grupo Santander.
06.03_CYBER_v2_ Implementar un procedimiento formal de gestión de cambios tecnológicos que incluya,
MX al menos, aspectos como creación, planificación, aprobación y revisión de cambios. APLICA Rechazar por fecha

Establecer un sistema de roles y permisos de forma que los usuarios finales no tengan
06.08_CYBER_v2_ permisos de administración sobre las estaciones de trabajo desde las que se presta el
APLICA Rechazar por fecha
MX servicio y por tanto no puedan acceder a características avanzadas del sistema que
pudieran comprometer los controles de seguridad implementados.

08.01_CYBER_v2_ Implementar un sistema de cifrado en almacenamiento basado en un algoritmo

NO APLICA Rechazar por otros
MX robusto aceptado por la industria.

Implementar un sistema de cifrado en tránsito basado en un algoritmo robusto

08.02_CYBER_v2_ aceptado por la industria para proteger el intercambio de información entre proveedor
NO APLICA Rechazar por otros
MX y Grupo (ejemplo: SFTP, cifrado de correo electrónico) y el acceso a la información
desde Internet (ejemplo: HTTPS).

08.04_CYBER_v2_ Garantizar
el aislamiento físico o lógico de los datos del Grupo Santander respecto a los
de otros clientes: máquinas físicas separadas, bases de datos distintas, entornos APLICA Rechazar por fecha
MX
virtuales, instancias de Cloud, etc.

En las estaciones de trabajo donde se almacene y/o procese información del Grupo
Santander implementar controles para evitar la fuga de datos, al menos:

- Bloqueo/restricción de almacenamiento en medios extraíbles (ej. puertos USB).

08.06_CYBER_v2_ APLICA Rechazar por fecha
MX
- Restricción de navegación por sitios de almacenamiento web (ej. Dropbox, Gmail).

Complementariamente se pueden implementar los siguientes controles: cifrar el disco

duro local (ej. BitLocker) para evitar posibles fugas en caso de extravío, implementar
una política corporativa de buenas prácticas del uso de recursos (correo, navegación
web, etc.), implementar una solución DLP, etc.
 Quien ayudara a realizar ese
COMENTARIOS Fecha de implementacion respaldo

Consultar con ing. Julio / No aplica con

banco, solamente aplicaria a CESTEK en caso
de contar con página web propia o servidor Apr-22
propio. (A.10, A.12.2,A.12.4, A.13, A.14)

Consultar con ing. Julio / Si aplica en cuanto

a generar un protocolo de prevensión y
acción antivirus informáticos (A.10, Apr-22
A.12.2,A.12.4, A.13, A.14)

existe una plataforma a la cual mediante

una cuanta asignada por el banco tenemos Apr-22
acceso

No se hacen desarrollos para el banco Apr-22

No se hacen desarrollos para el banco Apr-22

Aplica en cuanto a mantener un registro del

personal que cuenta con acceso a la Apr-22
plataforma del cliente (A.12.4)

El unico acceso al banco es al portal de

reportes de fallas de sucursales y edificios y
esto se hace por internet por lo que no es Apr-22
posible realizar esto. / No aplica
 El unico acceso al banco es al portal de
reportes de fallas de sucursales y edificios y
esto se hace por internet por lo que no es Apr-22
posible realizar esto.

Se esta en el proceso de certificacion ISO

27001 May-22

Consultar con ing. Julio / Aplica con los

anexos A.10, A.12.2,A.12.4, A.13, A.14 Apr-22

El unico acceso al banco es al portal de

reportes de fallas de sucursales y edificios y
esto se hace por internet por lo que no es Apr-22
posible realizar esto. / Aplica con los anexos
A.10, A.12.2,A.12.4, A.13, A.14

no se desarrollan software

Dentro del análisis de riesgo de debe de

considerar las fuentes bajo las cuales se
puede vulnerar un sistema (memorias
externas, discos duros externos, correos
electrónicos, celulares y tarjetas SD, etc.) Apr-22

Aplica un equipo es conectado a alguna de

las redes o plataformas del BANCO Apr-22

No aplica, no generan claves criptográficas Apr-22

Aplica con los anexos A.8.3, A.9.2.6, A.11.2.7 Apr-22

Aplica con los anexos A.8.3, A.9.2.6, A.11.2.7 Apr-22

No hay accesos remotos de nuestro

personal Apr-22

Aplica solo si se tiene una aplicación web

interna dentro de CESTEK (A.10, Apr-22
A.12.2,A.12.4, A.13, A.14)

Aplica con anexo A.9.4 Apr-22

El unico acceso al banco es al portal de

reportes de fallas de sucursales y edificios.
Los usuarios nos fueron asignados por el
propio banco. /Aplica con A.9.4

Apr-22
Pedir Miguel investigue si las contraseñas de
acceso al portal de fallas las podemos
cambiar nosotros; en caso afirmativo, que Apr-22
elabore el procedimiento.

No podemos hacer esto porque el acceso es

por internet directo en el portal de reporte
de fallas.

No se utiliza ningun VPN Apr-22

Se elaborara procedimiento Apr-22

Pedir Miguel se implementara

procedimiento del punto anterior
considerando nombre.apellido para todo el Apr-22
personal. / Aplica con anexo A.9.4

Pedir Miguel revise usuarios para quitar los

Apr-22
genericos / Aplica con anexo A.9.4

No se cuenta con un mecanismo de

verificacion de huella dactilar ni con token Apr-22

Aplica con el anexo A.16 Apr-22

 Aplica anexo a.12.1.2 Apr-22

se revisara y se reimplementen los grupos y

Apr-22
permisos de los usuarios. / Aplica con A.9.2

No aplica a menos que se cifre la

Apr-22
información

No aplica a menos que se cifre la

Apr-22
información

no se cuenta con exclusividad para el

Apr-22
manejo de datos de santander

se puede realizar Apr-22