Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Reglamento Global de
Seguridad en la
Infraestructura IT
Norma Corporativa
Aprobado por el Comité Global de Seguridad de Telefónica en
su reunión del 24 de Julio de 2017.
Telefónica, S.A.
Edición 1, Julio 2017
Reglamento de Seguridad en la Infraestructura IT
Dirección Global de Seguridad, Telefónica S.A.
CONTROL DE CAMBIOS
INDICE
1. INTRODUCCIÓN 4
2. CONTROLES DE SEGURIDAD 6
1. INTRODUCCIÓN
1.3. Contenido
Tras este capítulo introductorio, en el capítulo 2 se indican los controles de seguridad que se deben de
aplicar en el dominio de Seguridad en la Infraestructura IT.
Así mismo, se incluye un ANEXO que enumera los documentos de procedimiento que desarrollan los
controles y responsabilidades descritos en el capítulo 2.
Para cada control se establece el principio de actuación y el objetivo del mismo.
Así mismo, se establece la categorización de cada control como FUNDAMENTAL o ESPECIALIZADO.
Los controles FUNDAMENTALES forman parte imprescindible del Sistema de Gestión de la Seguridad
(SGS).
Los controles ESPECIALIZADOS son aquellos que dependen de factores tecnológicos o normativos que
pueden no estar presentes en todas las Unidades de Negocio / OB.
1.5. Referencias
[1] Política Global de Seguridad. Aprobada por el Consejo de Administración de Telefónica S.A.
[2] Normativa Global de Seguridad. Aprobada por el Consejo de Administración de Telefónica S.A.
[3] Portal Web de Normas Corporativas del Grupo Telefónica. Disponible en la Intranet Global.
[4] Manual de referencia del Marco Normativo con los Estándares y Regulaciones aplicables.
Telefónica S.A.
[5] ISO/IEC 27035:2011. Information security incident management. International Standard
Organization.
1.6. Definiciones
A efectos del presente documento:
Propietario del Activo: es el empleado o cargo que decide sobre la finalidad, contenido y uso del
activo, siendo por tanto responsable de la seguridad del mismo (Apdo. 2.5, Ref [2]).
Principio de privilegios mínimos: es un principio básico de la seguridad, que consiste en que “Todo
está prohibido, salvo que esté explícitamente permitido”. Siguiendo este principio de actuación, un
usuario sólo tendrá acceso de lectura a los Activos para los que haya recibido autorización, salvo
que dicha autorización incluyese permisos de escritura o modificación.
Malware: El malware (del inglés “malicious software”), también llamado badware, código maligno,
software malicioso, software dañino o software malintencionado, es un tipo de software que tiene
como objetivo infiltrarse o dañar un sistema de información sin el consentimiento de su propietario.
SIEM: Gestión de Eventos y Seguridad de la Información (del inglés “Security Information and Event
Management”) es la forma de denominar a la plataformas, herramientas o software que permiten
aplicar inteligencia y reglas definidas a la gestión de eventos de seguridad, permitiendo identificar
tendencias y detectar ciberataques.
VLAN: Acrónimo de virtual LAN (Red de área local virtual), es un método para crear redes lógicas
independientes dentro de una misma red física.
SLA: Acrónimo de Service Level Agreement (Acuerdo de Nivel de Servicio), es la forma de denominar
al acuerdo que establece las características de disponibilidad, tiempos de atención, etc. de un
servicio.
Equipo de Respuesta a Incidentes: Equipo de miembros debidamente capacitados y de confianza
de la organización que maneja los incidentes de seguridad durante su ciclo de vida (Apdo. 3.2, Ref.
[5]). También se conoce como CERT o CSIRT.
2. CONTROLES DE SEGURIDAD
El enfoque del Grupo Telefónica sobre Seguridad en la Infraestructura IT se basa en el adecuado
conocimiento de sus activos, sus características, su funcionamiento y operativa, e importancia para el
negocio, de forma que toda plataforma esté documentada, adecuadamente planificada, administrada
y mantenida, garantizando el cumplimiento de los requisitos de seguridad aplicables, para minimizar el
riesgo de indisponibilidad, acceso no autorizado o destrucción de la plataforma o las aplicaciones e
información que éstas sustenta.
La Normativa Global de Seguridad, Ref. [2] establece los objetivos de control (OC) necesarios para
alcanzar un nivel de seguridad homogéneo y adecuado a las necesidades del negocio. A continuación,
se describen los objetivos desarrollados en el presente Reglamento:
OC.18 Asegurar el funcionamiento correcto y seguro de las instalaciones de tratamiento de la
información.
OC.19 Evitar la pérdida de datos.
OC.20 Registrar eventos y generar evidencias.
OC.21 Asegurar la integridad del software en explotación.
OC.22 Reducir los riesgos resultantes de la explotación de las vulnerabilidades técnicas.
Para asegurar el cumplimiento de dicho objetivo, se establecen los siguientes controles de seguridad,
cuya correspondencia con los Estándares y Regulaciones aplicables se puede consultar en el Manual
de referencia del Marco Normativo con los Estándares y Regulaciones aplicables, Ref. [4].
Fallo seguro.
Las plataformas, sistemas y aplicaciones se diseñarán, configurarán y mantendrán
adecuadamente para garantizar su disponibilidad y evitar el fallo de las mismas.
Así mismo, el diseño y configuración de las mismas garantizará la confidencialidad e integridad de
la información que soporten, de forma que en caso de fallo, la información no sea accesible a
personas no autorizadas y no puede manipularse ni modificarse.
Seguridad en el desarrollo.
Los sistemas y aplicaciones se desarrollarán tomando la seguridad como un principio de diseño,
garantizando que no se crean debilidades en el sistema y que se aplican todos los controles de
seguridad establecidos. Ver apartado Diseño de sistemas seguros en el Reglamento de
Seguridad en el Ciclo de Vida de Desarrollo.
Seguridad usable.
Los controles de seguridad aplicados no deben obstaculizar a los usuarios en el desempeño de su
trabajo, deben documentarse adecuadamente y no deben ser difíciles de entender y manejar.
constante, y que la configuración de los mismos incluye los controles de seguridad requeridos, de
forma que se garantice la Confidencialidad, Integridad y Disponibilidad de los sistemas y de la
información que soportan.
2.2.4. Bastionado
El bastionado, o hardening en inglés, consiste en la aplicación de configuraciones específicas y
controles de seguridad en las plataformas, sistemas y aplicaciones, para conseguir que éstas sean más
robustas, garantizándose su operación sin fallos y protegiéndolas frente a ciberamenazas.
Para garantizar la seguridad de las plataformas, sistemas y aplicaciones, las empresas del Grupo
Telefónica deben definir y aplicar configuraciones seguras a sus plataformas, sistemas y aplicaciones,
que cubran los siguientes niveles de actuación:
Nivel BIOS (por ejemplo, limitar el acceso y la modificación de los parámetros de configuración de
las plataformas tecnológicas, así como impedir la modificación no autorizada de su Firmware,
etc.).
Nivel sistema (por ejemplo, limitar el acceso y la modificación de parámetros en el Panel de
Control y los directorios / librerías / ficheros que soportan el funcionamiento del sistema, etc.).
Nivel servicios (por ejemplo, deshabilitar los servicios no esenciales y/o aquellos que no resulten
necesarios para la operativa planificada, etc.).
Nivel usuario / cuenta (por ejemplo, establecer roles y permisos basados en el principio de
privilegios mínimos, asegurar la actualización de las contraseñas de los usuarios con una vigencia
máxima de 120 días, eliminar los usuarios predefinidos, etc.).
Nivel actualizaciones / parches (por ejemplo, asegurar que los sistemas y aplicaciones se
encuentran actualizados mediante un calendario de aplicación de parches y actualizaciones y,
establecer un procedimiento de aplicación prioritaria de aquellos parches o actualizaciones de
seguridad, etc.).
Nivel antivirus (por ejemplo, asegurar la ejecución de herramientas antivirus o de protección
contra el malware en los sistemas, etc.).
Nivel redes (por ejemplo, asegurar la protección de las plataformas mediante la adecuada
configuración de los cortafuegos o firewalls, etc.).
Nivel monitorización (por ejemplo, asegurar la adecuada configuración de las herramientas
necesarias para la monitorización de la actividad de red, de usuarios, de procesos, etc., en las
plataformas, sistemas y aplicaciones).
Las áreas locales de Seguridad coordinarán y supervisarán de bastionado de las plataformas, sistemas
y aplicaciones bajo su responsabilidad, apoyándose en las áreas locales de Tecnologías de la
Información, quienes aplicarán las configuraciones seguras establecidas globalmente a todos los
activos bajo su responsabilidad.
Los análisis de vulnerabilidades se ejecutarán con una periodicidad definida según la siguiente tabla:
Periodicidad
Activo Análisis vulnerabilidades Test penetración
Activos críticos o activos expuestos a Internet Mensual Semestral
Activos no críticos y no expuestos a Internet Semestral Anual
Las vulnerabilidades encontradas serán reportadas al CSIRT, que procederá a su resolución según lo
dispuesto en el apartado 2.2.5. Corrección de vulnerabilidades técnicas del Reglamento de
Ciberseguridad.
Esta monitorización es aplicable tanto a los activos controlados por la empresa como a los servicios en
la nube o externalizados.
Todos los activos deberán configurarse de forma que el sistema operativo almacene la información de
los registros (logs) de los eventos, como mínimo deberá incluir:
Activo en el que se ha producido el evento
Código identificador del usuario, programa o elementos que origina el evento (ID usuario, ID
proceso, IP, etc.)
Fecha y hora en que se produce el evento
Descripción o motivo del evento que se registra (tipo de acceso, recurso accedido, caída de un
sistema, error que se ha producido, etc.)
Sobre aquellos activos que han sido clasificados como NO críticos por su importancia para el negocio
(ver Reglamento de Gestión de Activos para más información sobre la clasificación de activos) se
realizará una monitorización reactiva, que generará alertas en caso de pérdida de disponibilidad de los
mismas o ante la ocurrencia de otros fenómenos como el bloqueo de una IP o un usuario debido a la
superación del umbral de conexiones infructuosas.
Las alertas generadas por la monitorización reactiva serán tratadas por el personal de las áreas locales
de Tecnologías de la Información y las Comunicaciones, según su proceso de gestión de incidencias,
pero deberá asegurase la custodia de los LOGs (o registros) de los sistemas, caso de requerirse
investigaciones forenses.
La aplicación de los parches (también denominados actualizaciones del sistema o Service Packs, si
incluyen varias actualizaciones) será realizada por el contacto técnico del Activo (normalmente, las
áreas locales de Operación de Tecnologías de la Información y las Comunicaciones o equivalente,
dependiendo de la organización interna de cada Unidad de Negocio / OB), atendiendo a la criticidad de
los mismos.
Activos críticos Activos no críticos
Urgencia Definición Plazo máximo aplicación Plazo máximo aplicación
Parche que corrige una vulnerabilidad
Crítico 72 h 7 días
crítica.
Parche que corrige vulnerabilidad de 3 meses, o basado en
Importante importancia alta o afecta a un activo 7 días calendario de parches; lo
clasificado como alto por el negocio. que ocurra primero
Parche que corrige una vulnerabilidad Basado en calendario de Basado en calendario de
Moderado
de importancia baja. parches parches
Parche que añade funcionalidad a la Basado en calendario de Basado en calendario de
Bajo
plataforma / sistema / aplicación. parches parches
Aquellas Unidades de Negocio / OBs que por requisitos legales, normativos o contractuales operen
infraestructuras de clave pública, o PKI por sus siglas en inglés, de forma interna, deberán elaborar un
Procedimiento Interno de Gestión de infraestructuras de clave pública que desarrolle, entre otros, los
siguientes requisitos:
Establecimiento del Propietario y el Contacto Técnico de la infraestructura de clave pública.
Establecimiento de la Autoridad de Certificación (CA) raíz y una o más CA (sub-CA) subsidiarias.
Controles de seguridad aplicables a las Autoridades de Certificación (CA raíz y sub-CAs).
Definición del modelo de integración de la infraestructura de clave pública con las plataformas,
sistemas y aplicaciones de la organización, y los requisitos de la infraestructura técnica necesaria.
Establecimiento de una o más Autoridades de Registro (RA).
Procedimientos para el manejo de certificados digitales de clave pública: Generar un certificado,
revocar un certificado, etc.
Establecimiento de un listado de certificados revocados (CRL).
Procedimientos para el manejo de excepciones en el funcionamiento de la infraestructura de clave
pública.