Coloriuris Prestador de Servicios de Confianza

3.- Declaración de prácticas

3.1.- Introducción

3.2.- El ciclo de vida de los certificados

3.2.1.- Solicitud de certificados

3.2.2.- Tramitación de la solicitud de certificados.

3.2.3.- Emisión de certificados

3.2.4.- Aceptación de certificados

3.2.5.- Uso del par de claves y del certificado.

3.2.6. Renovación de certificados.

3.2.7. Renovación de claves

3.2.8. Modificación de certificados.

3.2.9. Revocación y suspensión de certificados.

3.2.9.1. Circunstancias para la revocación

3.2.9.2. Entidad que puede solicitar la revocación

3.2.9.3. Procedimiento de solicitud de revocación

3.2.9.4. Periodo de gracia de la solicitud de revocación

3.2.9.5. Circunstancias para la suspensión

3.2.9.6. Entidad que puede solicitar la suspensión

3.2.9.7. Procedimiento para la solicitud de suspensión

3.2.9.8. Límites del período de suspensión

3.2.9.9. Frecuencia de emisión de CRLs

3.2.9.10. Requisitos de comprobación de estado de certificados

3.2.9.11. Otras formas de divulgación de información de revocación disponibles

3.2.9.12. Requisitos especiales de renovación de claves comprometidas

3.2.10. Servicios de comprobación de estado de certificados.

3.2.10.1 Características operativas

3.2.10.2 Disponibilidad del servicio

3.2.11. Finalización de la suscripción

3.2.12. Depósito y recuperación de claves

3.3.- Controles de seguridad física, de procedimiento y de personal

3.3.1.- Controles de seguridad física

3.3.1.1.- Localización y construcción de las instalaciones

3.3.1.2.- Acceso físico

3.3.1.3.- Electricidad y aire acondicionado

3.3.1.4.- Exposición al agua

3.3.1.5.- Prevención y protección de incendios

3.3.1.6.- Almacenamiento de soportes

3.3.1.7.- Tratamiento de residuos

3.3.1.8.- Copia de respaldo fuera de las instalaciones

3.3.2.- Controles de procedimientos

3.3.2.1.- Funciones fiables

3.3.2.2.- Número de personas por tarea

3.3.2.3.- Identificación y autenticación para cada rol

3.3.2.4.- Separación de tareas en los diferentes roles

3.3.3.- Controles de personal

3.3.3.1.- Requisitos de historial, calificaciones, experiencia y autenticación

3.3.3.2.- Procedimientos de investigación de historial

3.3.3.3.- Requisitos de formación

3.3.3.4.- Requisitos y frecuencia de actualización formativa

3.3.3.5.- Secuencia y frecuencia de rotación laboral

3.3.3.6.- Sanciones para acciones no autorizadas

3.3.3.7.- Requisitos de contratación de personal

3.3.3.8.- Suministro de documentación al personal

3.3.4.- Procedimientos de log y auditoría

3.3.4.1.- Tipo de eventos registrados

3.3.4.2.- Frecuencia de procesamiento de logs

3.3.4.3.- Periodo de retención del log

3.3.4.4.- Protección del log

3.3.4.5.- Procedimiento de backup del log

3.3.4.6.- Recolección de logs

3.3.4.7.- Notificación de la acción causante de los logs

3.3.4.8.- Análisis de vulnerabilidades

3.3.5.- Archivado de registros

3.3.5.1.- Tipo de registros archivados

3.3.5.2.- Periodo de retención del archivo

3.3.5.3.- Protección del archivo

3.3.5.4.- Procedimientos de backup del archivo

3.3.5.5.- Requisitos para el sellado de tiempo de los registros

3.3.5.6.- Sistema de archivo

3.3.5.7.- Procedimientos para obtener y verificar la información del archivo

3.3.6.- Cambio de claves

3.3.7.- Plan de contingencias

3.3.7.1.- Procedimientos de gestión de incidencias

3.3.7.2.- Plan de actuación ante datos y software corruptos

3.3.7.3.- Procedimiento ante compromiso de la clave privada

3.3.7.4.- Continuidad de negocio después de un desastre

3.3.8.- Terminación de la AC o AR

3.3.8.1.- Entidad de Certificación

3.3.8.2.- Entidad de Registro

3.4.- Controles de seguridad técnica

3.4.1.- Generación e instalación del par de claves

3.4.1.1.- Generación del par de claves

3.4.1.2.- Distribución de la clave privada al firmante o creador de sello

3.4.1.3.- Distribución de la clave pública al emisor del certificado

3.4.1.4.- Distribución de las claves públicas de las autoridades prestadoras de servicios

3.4.1.5.- Tamaños de claves

3.4.1.6.- Algoritmos de firma de certificados

3.4.1.7.- Usos admitidos de las claves (KeyUsage field X.509v3)

3.4.2.- Protección de la clave privada

3.4.2.1.- Estándares de módulos criptográficos

3.4.2.2.- Control por más de una persona (n de m) sobre la clave privada

3.4.2.3.- Custodia de la clave privada

3.4.2.4.- Copia de respaldo de la clave privada

3.4.2.5.- Archivado de la clave privada

3.4.2.6.- Trasferencia de la clave privada a o desde el módulo criptográfico

3.4.2.7.- Almacenamiento de la clave privada en el módulo criptográfico

3.4.2.8.- Método de activación de la clave privada

3.4.2.9.- Método de desactivación de la clave privada

3.4.2.10.- Método de destrucción de la clave privada

3.4.2.11.- Calificación del módulo criptográfico

3.4.3.- Otros aspectos de gestión del par de claves

3.4.3.1.- Archivo de la clave pública

3.4.3.2.- Periodos de utilización de las claves pública y privada

3.4.4.- Datos de activación

3.4.4.1.- Generación e instalación de datos de activación

3.4.4.2.- Protección de datos de activación

3.4.4.3.- Otros aspectos de los datos de activación

3.4.5.- Controles de seguridad informática

3.4.5.1.- Requisitos técnicos específicos de seguridad informática

3.4.5.2.- Evaluación del nivel de seguridad informática

3.4.6.- Controles técnicos del ciclo de vida

3.4.6.1.- Controles de desarrollo de sistemas

3.4.6.2.- Controles de gestión de la seguridad

3.4.7.- Controles de seguridad de red

3.4.8.- Fuente de tiempo

3.1.- Introducción

El funcionamiento de CIPSC se basa en las infraestructuras técnicas, los procedimientos y los mecanismos de control que se describen en esta Declaración de prácticas. Junto con el capítulo anterior, que se refiere a las Políticas, regulan la operación y requisitos que son comunes a los distintos servicios de confianza prestados por CIPSC.

Este documento y la demás información que resulte relevante para que los firmantes, creadores de sellos y partes usuarias valoren los servicios de CIPSC, se publican en los repositorios descritos en el apartado 1.6.3.

El Responsable de Administración de Políticas es responsable de mantener y aprobar todas las políticas y prácticas que rigen el funcionamiento de CIPSC, así como de la implementación y aplicación de las mismas. Entre otras medidas, CIPSC realiza evaluaciones y auditorías periódicas para determinar el estado de los controles y procedimientos de seguridad, efectuar el análisis de vulnerabilidades y aplicar las medidas que resulten pertinentes.

Coloriuris, a través del Responsable de Administración de Políticas, se responsabiliza de adoptar las medidas de seguridad necesarias para cumplir con los estándares y leyes que sean de aplicación, así como con las políticas y prácticas recogidas en el presente documento para la prestación de los servicios.

3.2.- El ciclo de vida de los certificados

Todos los certificados emitidos y utilizados por las Autoridades de CIPSC se ajustan al estándar X.509 versión 3 y al RFC 3039 «Internet X.509 Public Key Infrastructure Qualified Certificates Profile«.

Los identificadores únicos (OID) de los algoritmos con cifrado RSA utilizados son los siguientes:

  • SHA256RSA: 1.2.840.113549.1.1.11
  • SHA512RSA: 1.2.840.113549.1.1.13

Las especificaciones contenidas en este apartado lo son sin perjuicio de las estipulaciones previstas en cada una de las políticas de certificación correspondientes a cada tipo de certificado.

3.2.1.- Solicitud de certificados

La Autoridad de Registro de CIPSC que reciba la solicitud le compete el determinar que el tipo de certificado solicitado se adecue a las características concretas del solicitante, de conformidad con el contenido de la Política de Certificación aplicable a dicho certificado y, de este modo, resolver la solicitud formulada.

En cada Política de Certificación se especifica la información que debe suministrarse con carácter previo, a quien solicite un certificado.

Sin perjuicio de lo cual se informa que:

  1. La identificación de las personas físicas que soliciten un certificado reconocido exigirá su personación ante el operador de registro de la Autoridad de Registro de CIPSC (o de las A.R. externas que puedan crearse en el futuro) y se acreditará mediante el documento nacional de identidad, pasaporte u otros medios admitidos en derecho. Podrá prescindirse de la personación si su firma en la solicitud de expedición de un certificado reconocido ha sido legitimada en presencia notarial.
  2. En el caso de certificados reconocidos de personas jurídicas (sellos electrónicos conforme a la denominación dada por R.U.E. 910/2014), el operador de registro de la A.R. de CIPSC (o de las A.R. externas que puedan crearse en el futuro) comprobará, además, los datos relativos a la constitución y personalidad jurídica y a la extensión y vigencia de las facultades de representación del solicitante mediante los documentos públicos que sirvan para acreditar los extremos citados de manera fehaciente y su inscripción en el correspondiente registro público.

3.2.2.- Tramitación de la solicitud de certificados.

Compete a la Autoridad de Registro de CIPSC la comprobación de la identidad del solicitante, la verificación de la documentación y la constatación de que el solicitante ha firmado el documento de comparecencia. Una vez completa la solicitud, la Autoridad de Registro la remitirá a la AC correspondiente de CIPSC.

3.2.3.- Emisión de certificados

CIPSC no es responsable de la monitorización, investigación o confirmación de la exactitud de la información contenida en el certificado con posterioridad a su emisión. En el caso de recibir información sobre la inexactitud o la no aplicabilidad actual de la información contenida en el certificado, este puede ser revocado.

La emisión del certificado tendrá lugar una vez que CIPSC haya llevado a cabo las verificaciones necesarias para validar la solicitud de certificación. El mecanismo por el que determina la naturaleza y la forma de realizar dichas comprobaciones es la Política para la prestación de los servicios de certificación.

3.2.4.- Aceptación de certificados

La aceptación de los certificados por parte de los firmantes y/o creadores de sellos se produce en el momento de la firma del contrato de certificación asociado a cada Política de Certificación. La aceptación del contrato implica el conocimiento y aceptación por parte del firmante y/o creador de sellos de la Política de Certificación asociada.

3.2.5.- Uso del par de claves y del certificado.

Los usos del par de claves y certificado quedan definidos por cada Política de Certificación asociada.

3.2.6. Renovación de certificados.

En cada una de las Políticas de Certificación asociadas a cada tipo de certificado se detalla la posibilidad o no de renovar los certificados, así como las condiciones para proceder a su renovación.

3.2.7. Renovación de claves

La renovación de claves implica necesariamente la renovación de certificado y no se pueden llevar a cabo como procesos separados.

3.2.8. Modificación de certificados.

No se pueden modificar los campos de los certificados. Cualquier modificación necesaria implicará un proceso de renovación del certificado.

3.2.9. Revocación y suspensión de certificados.

3.2.9.1. Circunstancias para la revocación

En general un certificado se revoca cuando:

  • El firmante/creador de sellos o sus claves o las claves de sus certificados se han comprometido por:
    • El robo, pérdida, revelación, modificación, u otro compromiso o sospecha de compromiso de la clave privada del usuario.
    • El mal uso deliberado de claves y certificados, o la falta de observación de los requerimientos operacionales del acuerdo de suscripción, o de la presente DPC.
  • Se produce la emisión defectuosa de un certificado debido a:
    • Que no se ha satisfecho un prerrequisito material para la emisión del certificado.
    • Que un factor fundamental en el certificado se sepa o crea razonablemente que puede ser falso.
    • Un error de entrada de datos u otro error de proceso.
  • El par de claves generado por un usuario final se revela como “débil”.
  • La información contenida en un certificado o utilizada para realizar su solicitud se convierte en inexacta, por ejemplo cuando el dueño de un certificado cambia su nombre.
  • Una solicitud de revocación válida se recibe de un usuario final.
  • Una solicitud de revocación válida se recibe de una tercera parte autorizada, por ejemplo una orden judicial.
  • El certificado de una AR o AC superior en la jerarquía de confianza del certificado es revocado.

Si bien las circunstancias para la revocación podrán ser especificadas en cada Política de Certificación correspondiente.

3.2.9.2. Entidad que puede solicitar la revocación

La revocación de un certificado se puede instar tanto por el firmante/creador de sellos como por parte de CIPSC, así como por cualquier persona que conozca fehacientemente que los datos asociados al certificado se convierten en inexactos o incorrectos.

Los firmantes y creadores de sellos pueden solicitar la revocación de su certificado por cualquier causa y deben solicitarla bajo las condiciones especificadas en el siguiente apartado.

3.2.9.3. Procedimiento de solicitud de revocación

El procedimiento para la solicitud de la revocación de cada tipo de certificado se definirá en la Política de Certificación correspondiente.

3.2.9.4. Periodo de gracia de la solicitud de revocación

La revocación se realizará de forma inmediata al procesamiento de cada solicitud verificada como válida. Por tanto no existe ningún periodo de gracia asociado a este proceso.

3.2.9.5. Circunstancias para la suspensión

La suspensión implica invalidez del certificado durante el tiempo que permanece suspendido. La suspensión únicamente se puede declarar si así lo dispone una autoridad judicial o administrativa, por el tiempo que la misma establezca. CIPSC no soporta la suspensión de certificados como operación independiente sobre sus certificados.

3.2.9.6. Entidad que puede solicitar la suspensión

La suspensión solo se podrá solicitar por parte de una autoridad judicial o administrativa.

3.2.9.7. Procedimiento para la solicitud de suspensión

La suspensión de un certificado deberá solicitarse por mandamiento judicial o administrativo.

3.2.9.8. Límites del período de suspensión

El que establezca la autoridad judicial o administrativa competente.

3.2.9.9. Frecuencia de emisión de CRLs

CIPSC publicará las CRL’s de sus AACC en su repositorio cada 7 días siempre que no se hayan producido revocaciones, en caso de haber una revocación, la CRL correspondiente se publicará inmediatamente, sin perjuicio de que esta revocación pueda conocerse también mediante OCSP.

3.2.9.10. Requisitos de comprobación de estado de certificados

La verificación del estado de los certificados es obligatoria para cada uso de los certificados de entidades finales. Dicha comprobación puede hacerse a través del protocolo OCSP que proporciona CIPSC indicado en el apartado 4.2.1.5.

Adicionalmente CIPSC también contempla la publicación de CRLs.

3.2.9.11. Otras formas de divulgación de información de revocación disponibles

CIPSC se reserva la posibilidad de establecer en el futuro otras formas para informar de la revocación de los certificados.

3.2.9.12. Requisitos especiales de renovación de claves comprometidas

No hay ninguna variación en las cláusulas anteriores cuando la revocación sea debida al compromiso de la clave privada.

3.2.10. Servicios de comprobación de estado de certificados.

3.2.10.1 Características operativas

CIPSC ofrece un servicio gratuito de publicación de Listas de Certificados Revocados (CRL) sin restricciones de acceso. Adicionalmente, ofrece servicios de validación de certificados mediante el protocolo OCSP,

3.2.10.2 Disponibilidad del servicio

Los sistemas CRLs y OCSP de consulta en línea del estado de los certificados están disponibles durante las 24 horas los 7 días de la semana.

Podrán programarse interrupciones de los servicios cuando sea estrictamente necesario por razones técnicas, en cuyo caso estas deberán anunciarse con una antelación de al menos 24 horas en el directorio indicado en el epígrafe 1.6.3.

Cuando la interrupción se deba a causas de fuerza mayor o incidencias graves, CIPSC actuará con la máxima diligencia para conseguir la puesta en marcha de los servicios, así como para minimizar los posibles perjuicios que se hayan causado a los firmantes, creadores de sellos y/o partes usuarias

3.2.11. Finalización de la suscripción.

La suscripción finaliza con la expiración o revocación del certificado.

3.2.12. Depósito y recuperación de claves.

CIPSC no ofrece ese servicio.

3.3.- Controles de seguridad física, de procedimiento y de personal

3.3.1.- Controles de seguridad física

3.3.1.1.- Localización y construcción de las instalaciones

Las instalaciones en las que se procesa información cumplen los siguientes requisitos físicos:

  • El edificio que contiene las instalaciones de procesamiento de información es físicamente sólido, los muros externos del emplazamiento son de construcción sólida y está permanentemente vigilado por cámaras de seguridad, permitiendo únicamente el acceso a personas debidamente autorizadas.
  • La sala de procesamiento tiene sus puertas cerradas y protegidas contra accesos no autorizados y no dispone de ventanas.

3.3.1.2.- Acceso físico

Las instalaciones disponen de un sistema de control de acceso físico:

  • Únicamente está permitido el acceso a personal autorizado.
  • Los derechos de acceso al área segura son revisados y actualizados periódicamente.
  • Se requiere que todo el personal porte algún elemento de identificación visible y se fomenta que el personal requiera dicha identificación a cualquiera que no disponga de la misma.
  • El personal ajeno a la operación de CIPSC que se encuentre trabajando en sus instalaciones es supervisado.
  • Se mantiene de forma segura un fichero de los accesos conforme a la ISO 27001.
  • Las puertas de entrada están dotadas con mecanismos de acceso.
  • Un circuito cerrado de televisión que monitoriza la sala desde la que se presta el servicio de certificación.

3.3.1.3.- Electricidad y aire acondicionado

El Centro de Proceso de Datos cuenta con sistemas de energía y aire acondicionado adecuados para garantizar un entorno operativo fiable.

Así mismo las instalaciones disponen de una funcionalidad de alimentación ininterrumpida (SAI) que mantiene los equipos en funcionamiento durante el tiempo necesario para el cierre ordenado de los sistemas en el caso en que un fallo de energía o aire acondicionado provocara la caída de los mismos.

3.3.1.4.- Exposición al agua

Se han adoptado las medidas necesarias para minimizar los riesgos derivados de los daños por agua.

3.3.1.5.- Prevención y protección de incendios

El Centro de Procesos de Datos dispone de sistemas de detección automática de incendios con la finalidad de:

  • Avisar del inicio de un incendio al servicio de vigilancia y al personal.
  • Cumplir con las misiones de desconexión del sistema de ventilación, corte de la energía eléctrica y el disparo de la instalación automática de extinción.

3.3.1.6.- Almacenamiento de soportes

Los soportes de las copias de seguridad se almacenan de forma segura.

3.3.1.7.- Tratamiento de residuos

Los soportes que contengan información confidencial se destruyen de tal manera que la información no pueda recuperarse después de su destrucción.

3.3.1.8.- Copia de respaldo fuera de las instalaciones

CIPSC almacena los soportes de las copias de seguridad de forma que se encuentren protegidos frente a accidentes y a una distancia suficiente para evitar que resulten dañados en el caso de un desastre en el emplazamiento principal.

3.3.2.- Controles de procedimientos

3.3.2.1.- Funciones fiables

Se define “rol de confianza” como aquel al que se le asignan funciones que pueden dar lugar a problemas de seguridad si no se realizan adecuadamente, bien por accidente o de forma malintencionada.

Con la finalidad de incrementar la probabilidad de que las funciones correspondientes a un “rol de confianza” se realicen correctamente, se contemplan dos enfoques:

  • El primero es el diseño y configuración de la tecnología, de forma que se eviten errores y se prohíba un comportamiento inadecuado.
  • El segundo es la distribución de las funciones entre varias personas de forma que la actividad malintencionada requiera la connivencia de varias de ellas.

Según lo especificado en la norma CEN CWA 14167-1, los roles mínimos establecidos son:

  • Responsable de Seguridad (Security Officer): Mantiene la responsabilidad global sobre la administración y la implementación de las políticas y procedimientos de seguridad.
  • Administradores del sistema de Certificación (System Administrators): Autorizado para realizar cambios en la configuración del sistema.
  • Operadores de Sistemas (System Operator): Responsables de la gestión del día a día del sistema (Monitorización, backup, recovery,…)
  • Auditor interno (System Auditor): Autorizado a acceder a los logs del sistema y verificar los procedimientos que se realizan sobre el mismo.
  • Operador de AC – Operador de Certificación : Responsables de activar las claves de CA en el entorno Online.
  • Operador de AR (Registration Officer): Responsables de aprobar, emitir, suspender y revocar los certificados de Entidad final.

Concretamente:

Las tareas de Auditor son incompatibles en el tiempo con las tareas de Certificación e incompatibles con Sistemas.

Las personas implicadas en Administración de Sistemas no podrán ejercer ninguna actividad en las tareas de Auditoría o Certificación.

3.3.2.2.- Número de personas por tarea

Para reforzar la seguridad del sistema, se asignan personas diferentes para cada rol con la excepción del rol de operador que puede ser asumido por el administrador.

Además, se pueden asignar múltiples individuos a un mismo rol.

3.3.2.3.- Identificación y autenticación para cada rol

Los roles de confianza exigen la autenticación con un medio suficientemente seguro, y en cualquier caso siempre con usuarios personales.

3.3.2.4.- Separación de tareas en los diferentes roles

Las personas asignadas para cada rol son identificadas por el auditor interno que se asegurara que cada persona realiza las operaciones para las que está asignado.

Cada persona solo controla los activos necesarios para su rol, asegurando así que ninguna persona accede a recursos no asignados.

3.3.3.- Controles de personal

3.3.3.1.- Requisitos de historial, calificaciones, experiencia y autenticación

CIPSC emplea personal que posee la experiencia y calificación necesarias para los servicios que debe realizar.

Todo el personal con roles fiables está libre de intereses que puedan perjudicar la imparcialidad de las operaciones de CIPSC.

3.3.3.2.- Procedimientos de investigación de historial

No aplica según la legislación española.

3.3.3.3.- Requisitos de formación

El personal de CIPSC recibe la formación requerida para asegurar su competencia en la realización de sus funciones. Se incluye en la formación los siguientes puntos:

  • Entrega de una copia de la Declaración de Prácticas de Certificación.
  • Concienciación sobre la seguridad.
  • Operación del software y hardware para cada rol específico.
  • Procedimientos de seguridad para cada rol específico.
  • Procedimiento de operación y administración para cada rol específico.
  • Procedimientos para la recuperación de desastres.

3.3.3.4.- Requisitos y frecuencia de actualización formativa

Ante cambios tecnológicos del entorno, introducción de nuevas herramientas o modificación de procedimientos operativos, se llevará a cabo la formación adecuada para el personal afectado.

Ante cambios en la Declaración de Prácticas de Certificación, Políticas de Certificación u otros documentos relevantes, se llevarán a cabo sesiones formativas.

3.3.3.5.- Secuencia y frecuencia de rotación laboral

No aplicable.

3.3.3.6.- Sanciones para acciones no autorizadas

En el caso de comisión de una acción no autorizada con respecto a la operación de la Autoridad de Certificación se tomarán medidas disciplinarias. Se considerarán acciones no autorizadas las que contravengan la Declaración de Prácticas de Certificación o las Políticas de Certificación pertinentes tanto de forma negligente como malintencionada.

Si se produce alguna infracción, CIPSC suspenderá el acceso de las personas involucradas a todos los sistemas de información de CIPSC de forma inmediata al conocimiento del hecho.

Adicionalmente, en función de la gravedad de las infracciones, se aplicarán las sanciones previstas en el convenio colectivo de la empresa, o el Estatuto de los Trabajadores según corresponda a la situación laboral del infractor.

3.3.3.7.- Requisitos de contratación de personal

CIPSC manifiesta que cumple en su integridad la normativa vigente en materia de igualdad de oportunidades entre hombres y mujeres, y que además tiene una política activa al respecto.

CIPSC se compromete a que todo el personal adscrito a los Servicios conozca, asuma y cumpla las obligaciones de esta Política y Declaración de Prácticas en cuanto a la forma y modo de su cumplimiento, seguridad y confidencialidad, que se harán extensivas a todos los intervinientes en los procesos, tratamientos y ejecución de las labores de certificación, constituyendo su código ético. A tal efecto CIPSC se compromete a obtener de cada uno de sus empleados y colaboradores un compromiso escrito en tal sentido.

CIPSC declara conocer los Principios del Pacto Mundial de las Naciones Unidas, asumiendo íntegramente su contenido y comprometiéndose a su estricto cumplimiento.

En relación a la asignación de roles y responsabilidades se estará a lo dispuesto en el apartado 3.3.2.1.

3.3.3.8.- Suministro de documentación al personal

Todo el personal relacionado con roles fiables recibe:

  • Una copia de la Declaración de Prácticas de Certificación
  • La documentación que define las obligaciones y procedimientos de cada rol.
  • Tiene acceso a los manuales relativos a la operación de los diferentes componentes del sistema.

3.3.4.- Procedimientos de log y auditoría

Se utilizarán los ficheros de log para reconstruir los eventos significativos que han sido realizados por el software utilizado por CIPSC y las Entidades de Registro y el usuario o evento que los originó. Será también utilizado como un medio de arbitraje en posibles disputas mediante la comprobación de la validez de una firma en un momento determinado.

3.3.4.1.- Tipo de eventos registrados

Se almacenan en los logs:

  • Todos los eventos relativos al ciclo de vida de las claves criptográficas.
  • Todos los eventos relativos al ciclo de vida de los certificados.
  • Todos los eventos relativos a la emisión de dispositivos criptográficos.
  • Todos los eventos relativos a la administración de cuentas de operadores y administradores de CIPSC.

Se graba la fecha y hora de cada evento, utilizando una base de tiempos fiable.

3.3.4.2.- Frecuencia de procesamiento de logs

Los ficheros log son revisados periódicamente por el auditor de CIPSC.

3.3.4.3.- Periodo de retención del log

La información generada en el fichero log se mantiene en línea hasta el momento de ser archivada. Una vez archivados, los ficheros log son mantenidos durante 7 años.

3.3.4.4.- Protección del log

Se asigna a los Auditores el derecho de lectura del registro de log.

Está impedido el borrado no autorizado de los registros de log y la modificación de los mismos, mediante la escritura de los registros de log en un medio no modificable como un CD-ROM u otros.

3.3.4.5.- Procedimiento de backup del log

Se realizan copias de seguridad del log en línea con la misma planificación y controles que para el resto de elementos del sistema de CIPSC.

3.3.4.6.- Recolección de logs

Los archivos de log de AACC y AARR son almacenados en los sistemas internos de CIPSC.

3.3.4.7.- Notificación de la acción causante de los logs

No está contemplada la notificación de la acción de los ficheros log al origen del evento.

3.3.4.8.- Análisis de vulnerabilidades

Se realiza un análisis de vulnerabilidades periódico en los sistemas internos de CIPSC.

3.3.5.- Archivado de registros

3.3.5.1.- Tipo de registros archivados

Los tipos de datos o ficheros que son archivados, entre otros, son los siguientes:

  • Datos relacionados con el procedimiento de registro y solicitud de certificados;
  • Los registros de auditoría de la sección anterior;
  • Histórico de claves

3.3.5.2.- Periodo de retención del archivo

Toda la información y documentación relativa a los certificados se conserva durante 15 años (a partir de la fecha de emisión).

3.3.5.3.- Protección del archivo

Se adoptarán las medidas de protección del archivo, para que no pueda ser manipulado ni destruido su contenido.

3.3.5.4.- Procedimientos de backup del archivo

Existe una política de copias de seguridad, Plan de Contingencias y plan de continuidad de negocio que definen los criterios y estrategias de actuación ante una incidencia. El diseño de toda la estrategia de actuación ante incidencias se basa en el correspondiente inventario de activos y análisis de riesgos.

3.3.5.5.- Requisitos para el sellado de tiempo de los registros

Los sistemas de información empleados por CIPSC garantizan el registro de los instantes de tiempo en los que se realizan. El instante de tiempo de los sistemas proviene de una fuente segura de fecha y hora. Todos los sistemas sincronizan su instante de tiempo con esta fuente.

3.3.5.6.- Sistema de archivo

El sistema de archivo se encuentra ubicado en las instalaciones de CIPSC y en las entidades que participan en la prestación del servicio.

3.3.5.7.- Procedimientos para obtener y verificar la información del archivo

El acceso a esta información está restringido al personal autorizado a tal efecto, protegiéndose frente a accesos físicos y lógicos según lo establecido en otras secciones del apartado 3.4 y el apartado 3.5 de la presente Declaración de Prácticas de Certificación.

3.3.6.- Cambio de claves

Para renovar un certificado de usuario, bien porque haya sido revocado o porque haya caducado, se deberá solicitar un nuevo certificado, siguiendo el proceso de emisión de certificados previsto en la Documentación específica para cada certificado.

La renovación de claves lleva aparejada la renovación del certificado.

3.3.7.- Plan de contingencias

3.3.7.1.- Procedimientos de gestión de incidencias

Existe un Plan de Contingencias que define las acciones a realizar, recursos a utilizar y personal a emplear en el caso de producirse un acontecimiento intencionado o accidental que inutilice o degrade los recursos y los servicios de certificación prestados por CIPSC.

Los principales objetivos del Plan de Contingencia son:

  • Maximizar la efectividad de las operaciones de recuperación mediante el establecimiento de tres fases:
    • Fase de Notificación/Evaluación/Activación para detectar, evaluar los daños y activar el plan.
    • Fase de Recuperación para restablecer temporal y parcialmente los servicios hasta la recuperación de los daños provocados en el sistema original.
    • Fase de Reconstitución para restaurar el sistema y los procesos a su operativa habitual.
  • Identificar las actividades, recursos y procedimientos necesarios para la prestación parcial de los servicios de certificación en un CPD alternativo durante interrupciones prolongadas de la operativa habitual.
  • Asignar responsabilidades al personal designado de CIPSC y facilitar una guía para la recuperación de la operativa habitual durante largos periodos de interrupción.
  • Asegurar la coordinación de todos los agentes (departamentos de la entidad, puntos de contacto externos y vendedores) que participen en la estrategia de contingencia planificada.

El Plan de Contingencias de CIPSC es de aplicación al conjunto de funciones, operaciones y recursos necesarios para restaurar la prestación de servicios de certificación. Dicho plan se aplica al personal de CIPSC asociado a la prestación de los servicios de certificación.

El Plan de Contingencias establece la participación de ciertos grupos en la recuperación de las operaciones de CIPSC.

La evaluación de los daños y el plan de acción se describen en el Plan de Contingencias.

En el caso de producirse la circunstancia de que el algoritmo, la combinación de los tamaños de clave utilizados o cualquier otra circunstancia técnica que mermara significativamente la seguridad técnica del sistema se aplicará dicho Plan de Contingencia. Se realizará un análisis de impacto. En ese análisis se estudiará la criticidad del problema de seguridad, su ámbito y la estrategia de recuperación ante la incidencia. Los puntos que se deben definir como mínimo en el informe de análisis de impacto son:

  • Descripción detallada de la contingencia, ámbito temporal, etc
  • Criticidad, ámbito
  • Solución o soluciones propuestas
  • Plan de despliegue de la solución elegida, que incluirá al menos:
    • Notificación a los usuarios por el medio considerado más eficaz. Se incluirá tanto a los solicitantes como a los firmantes, creadores de sellos y verificadores (terceras partes confiables) de los certificados.
    • Se informará en la web de la contingencia producida
    • Revocación de los certificados afectados
    • Estrategia de renovación

3.3.7.2.- Plan de actuación ante datos y software corruptos

Si los recursos hardware, software, y/o datos se alteran o son sospechosos de haber sido alterados se detendrá el funcionamiento de los servicios de CIPSC hasta el restablecimiento de un entorno seguro con la incorporación de nuevos componentes de eficiencia acreditable. De forma paralela se realizará una auditoría para identificar la causa de la alteración y asegurar la no reproducción de la misma.

En el caso de verse afectados certificados emitidos, se notificará del hecho a los firmantes , creadores de sellos de los mismos así como a MINETUR y se procederá a su recertificación.

3.3.7.3.- Procedimiento ante compromiso de la clave privada

La AC Raíz revocará el certificado de una AC subordinada en el caso que la clave privada de esa CA haya sido comprometida.

En el caso que la AC Raíz deba revocar el certificado de la AC subordinada, lo notificará inmediatamente a:

  • La AC emisora
  • Todas las AARR autorizadas para el registro de esa AC
  • Todos los signatarios titulares de certificados emitidos por esa AA.
  • Ministerio de Industria Energía y Turismo de España.

La AC Raíz, también publicará el certificado revocado en la CRL/ARL (Lista de Revocación de Autoridades de Certificación).

Después de resolver los factores que indujeron la revocación, la AC Raíz puede:

  • Generar un nuevo certificado para la AC subordinada.
  • Asegurar que todos los nuevos certificados y CRL emitidos por la AC son firmados utilizando la nueva clave.

La AC subordinada podrá emitir certificados a todas las entidades finales afectadas.

En caso de que la clave comprometida sea la de la AC raíz, se eliminará el certificado de todas las aplicaciones y se distribuirá uno nuevo.

3.3.7.4.- Continuidad de negocio después de un desastre

Se suspenderá la operación de la AC hasta el momento en que se haya completado el procedimiento de recuperación de desastre y se halle funcionando correctamente en el centro principal o alternativo.

Se activará el Plan de Contingencias y de Continuidad de Negocio de CIPSC.

3.3.8.- Terminación de la AC o AR

3.3.8.1.- Entidad de Certificación

En caso de cese de su actividad, CIPSC comunicará a los firmantes y creadores de sellos por cualquier medio que garantice el envío y la recepción de la notificación, con un plazo mínimo de antelación de 2 meses a su fecha de su extinción, su intención de cesar como prestador de servicios de certificación.

De la misma manera, se notificará a PSCs y cualquier entidad con la que CIPSC mantenga alguna relación contractual de uso de sus certificados.

Asimismo comunicará al Ministerio de Industria, Energía y Turismo, con la antelación indicada en el anterior apartado, el cese de su actividad y el destino que vaya a dar a los certificados, especificando, en su caso, si va a transferir la gestión y a quién o si extinguirá su vigencia.

La responsabilidad de esta notificación corresponde al Responsable de Seguridad de CIPSC, quien decidirá el mecanismo más adecuado.

En el supuesto de que CIPSC decidiera transferir la actividad a otro prestador de servicios de certificación, comunicará al Ministerio de Industria, Energía y Turismo y a los firmantes y creadores de sellos de sus certificados los acuerdos de transferencia. A tal efecto CIPSC enviará el documento explicativo de las condiciones de transferencia así como de las condiciones de utilización que regularán las relaciones entre los firmantes y/o creadores de sellos y el PSC al cual se transfieren los certificados. Esta comunicación se realizará por cualquier medio que garantice el envío y la recepción de la notificación, con una antelación mínima de 2 meses al cese de su actividad.

Los firmantes y creadores de sellos deberán consentir de forma expresa la transferencia de los certificados, aceptando las condiciones del PSC al que se transfieren. Transcurrido el plazo de dos meses, sin que exista acuerdo de transferencia o sin que los firmantes y creadores de sellos acepten expresamente la misma, los certificados serán revocados.

En el supuesto de que no existieran acuerdos con otros PSC, finalizado el plazo de los 2 meses de antelación en la comunicación, todos los certificados serán revocados de manera automática.

CIPSC remitirá al Ministerio de Industria, Energía y Turismo, con carácter previo al cese definitivo de su actividad la información relativa a los certificados electrónicos cuya vigencia haya sido extinguida para que éste se haga cargo de su custodia a efectos de lo previsto en el artículo 20.1.f).

Se dará por finalizado cualquier autorización de terceros con los que CIPSC mantenga un contrato de prestación de servicios (identificación, emisión, albergue, etc.)

3.3.8.2.- Entidad de Registro

Una vez la Entidad de Registro cese en el ejercicio de las funciones que asuma transferirá los registros que mantenga a CIPSC, mientras exista obligación de mantener archivada la información dado que en otro caso, será cancelada y destruida.

3.4.- Controles de seguridad técnica

3.4.1.- Generación e instalación del par de claves

CIPSC adopta las medidas precisas para garantizar que las claves privadas de sus autoridades sean secretas y para mantener su integridad.

3.4.1.1.- Generación del par de claves

Elementos donde se genera el par de claves para cada una de las diferentes entidades que componen CIPSC:

  • AC raíz: la máquina donde reside la AC raíz dispone de un dispositivo criptográfico (HSM) para la generación de claves de la AC raíz.
  • AACC subordinadas: se deberán generar en un módulo criptográfico en cada máquina que albergue AACC.
  • Certificados de usuario emitidos en tarjeta criptográfica o HSM: las claves son generadas por el dispositivo criptográfico.
  • Certificado de usuario emitido en soporte software criptográfico: sus claves son generadas por el servidor donde reside el servicio
  • Servidor de la Autoridad de Time Stamping (TSA) y Servidor de Validación OCSP: claves generadas en el módulo criptográfico asociado al sistema en el que residen ambos servidores.
  • Para el caso de las claves generadas por el propio poseedor, éstas deberán ser generadas siguiendo las recomendaciones de algoritmo y longitud de clave mínimas definidas en ETSI TS 102 176

3.4.1.2.- Distribución de la clave privada al firmante o creador de sello

Método de entrega de la clave privada para las diferentes entidades que componen o colaboran con CIPSC:

  • Certificados emitidos en tarjeta criptográfica: las claves privadas de autenticación y de firma se entregan con el dispositivo criptográfico.
  • Certificados emitidos en HSM: las claves privadas de autenticación y de firma se albergan en el dispositivo criptográfico.
  • Certificados emitidos en soporte software: la clave privada es generada en el propio servidor. No necesita ser entregada.

3.4.1.3.- Distribución de la clave pública al emisor del certificado

El método de entrega de la clave pública de las diferentes entidades que componen o colaboran con CIPSC al emisor de certificados correspondiente es el siguiente:

  • AACC subordinadas: la clave pública es enviada a la AC raíz mediante formato X.509 o PKCS#10.
  • Certificados emitidos en dispositivo criptográfico: se leen del dispositivo criptográfico.
  • Certificado emitido en soporte software: la clave pública es enviada a la AC de CIPSC mediante formato X.509 o PKCS#10.

3.4.1.4.- Distribución de las claves públicas de las autoridades prestadoras de servicios

Las claves públicas de las Autoridades prestadoras de servicios se publicarán, así como su cadena de confianza, mediante los correspondientes certificados electrónicos en los repositorios descritos en el apartado 1.6.3 de este documento. El formato de los certificados será el definido por el estándar X509. v3, y su contenido y periodo de validez el que se determine en las Políticas correspondientes.

En la presente Declaración de Prácticas de Certificación, en el anexo II, se publican además las diferentes huellas de las AACC raíces y AACC subordinadas.

3.4.1.5.- Tamaños de claves

El tamaño de las claves dependiendo de los casos es:

  • Al menos 2048 bits para claves de personas físicas y jurídicas, servidor OCSP, servidor TSA y certificados técnicos.
  • Al menos 2048 bits para claves de AACC subordinadas.
  • Al menos 4096 bits para claves raíz de AC.

Si se determinara que cualquiera de las longitudes de la clave han dejado de aportar un nivel suficiente de seguridad, CIPSC los sustituirá por otras cuyo nivel de seguridad se considere suficiente, y publicará la información sobre dichos cambios en el repositorio mencionado en el apartado 1.6.3.

3.4.1.6.- Algoritmos de firma de certificados

El identificador de algoritmo (AlgorithmIdentifier) que emplea CIPSC para firmar los certificados es SHA-256 (algoritmo de hash) con RSA (algoritmo de firma) que corresponde al identificador para «Secure Hash Algorithm 256 (SHA256) with Rivest, Shamir and Adleman (RSA) encryption».

Los certificados de usuario final están firmados con RSA con SHA-256. CIPSC recomienda a los usuarios finales que utilicen RSA con SHA-256 o superior a la hora de firmar con el certificado.

CIPSC utiliza un algoritmo cualificado por la industria y adecuado para el propósito de firma reconocida. Se tendrá en cuenta para ello el periodo de vigencia del certificado además sigue las recomendaciones indicadas por los diferentes estándares de ETSI.

En el caso de producirse la circunstancia de que el algoritmo, la combinación de los tamaños de clave utilizados o cualquier otra circunstancia técnica que mermara significativamente la seguridad técnica del sistema se aplicará el Plan de Contingencia. Se realizará un análisis de impacto. En ese análisis se estudiará la criticidad del problema de seguridad, su ámbito y la estrategia de recuperación ante la incidencia. Los puntos que se deben definir como mínimo en el informe de análisis de impacto son:

  • Descripción detallada de la contingencia, ámbito temporal, etc
  • Criticidad, ámbito
  • Solución o soluciones propuestas
  • Plan de despliegue de la solución elegida, que incluirá al menos:
    • Notificación a los usuarios por el medio considerado más eficaz. Se incluirá tanto a los solicitantes como a los firmantes, creadores de sellos y verificadores (terceras partes confiables) de los certificados.
    • Se informará en la web de la contingencia producida o Revocación de los certificados afectados
    • Estrategia de renovación

3.4.1.7.- Usos admitidos de las claves (KeyUsage field X.509v3)

Todos los certificados incluyen la extensión Key Usage y Extended Key Usage, indicando los usos habilitados de la claves.

Las claves de AC raíz únicamente se utilizarán para firmar certificados de AACC subordinadas y ARLs, y que las claves de las AC subordinadas o emisoras únicamente se utilizarán para firmar certificados de usuario final y CRLs

Los usos admitidos de la clave para cada certificado están definidos en el apartado específico de cada certificado.

3.4.2.- Protección de la clave privada

3.4.2.1.- Estándares de módulos criptográficos

Un módulo de seguridad criptográfico (HSM) es un dispositivo de seguridad que genera y protege claves criptográficas. CIPSC utiliza módulos criptográficos hardware desarrollados por terceros y disponibles comercialmente. CIPSC únicamente utiliza módulos criptográficos con certificación FIPS 140-2 Nivel 3, CC EAL 4+ o superior.

CIPSC comprueba que los módulos de seguridad criptográficos no han sido manipulados durante su transporte y almacenamiento, y que conservan los embalajes originales de fábrica.

En cuanto a los dispositivos criptográficos con certificados para firma electrónica cualificada, aptas como dispositivos seguros de creación de firma (DSCF), cumplen el nivel de seguridad CC EAL4+, aunque también son admisibles las certificaciones equivalentes ITSEC E3 o FIPS 140-2 Nivel 2 como mínimo.

La norma europea de referencia para los dispositivos de firmantes o creadores de sellos utilizados es CEN CWA 14169.

CIPSC, en cualquier caso, mantiene el control sobre la preparación, almacenamiento y distribución de los dispositivos de los firmantes y creadores de sellos en los que CIPSC genera las claves.

3.4.2.2.- Control por más de una persona (n de m) sobre la clave privada

La utilización de las claves privadas de las AACC requiere la aprobación de al menos dos personas.

3.4.2.3.- Custodia de la clave privada

La clave privada de las AACC raíz están custodiadas por un dispositivo criptográfico hardware certificado con la norma FIPS 140-2 nivel 3 y/o CC EAL4+, garantizando que la clave privada nunca está fuera del dispositivo criptográfico. La activación y uso de la clave privada requiere el control multipersona detallado anteriormente.

Las claves privadas de las AC Subordinadas están custodiadas en dispositivos criptográficos seguros certificados con la norma FIPS 140-2 nivel 3 y CC EAL4+.

En los casos en los que el firmante o creador de sellos custodie la clave privada éste será el responsable de mantenerla bajo su exclusivo control.

3.4.2.4.- Copia de respaldo de la clave privada

A fin de garantizar la continuidad del servicio en caso de desastre total (destrucción del HSM que alberga las claves privadas de los certificados raíz) existe una copia de respaldo en un dispositivo seguro de creación de firma de las mismas características que el HSM en producción.

La copia de respaldo se ha llevado a cabo por el Administrador del Sistema de Certificación y el Operador de la Autoridad de Certificación, bajo supervisión del Responsable de Seguridad, conforme a lo dispuesto en el apartado 3.4.2.2, que conserva dicha copia de respaldo en una caja fuerte a una distancia suficiente del emplazamiento principal.

3.4.2.5.- Archivado de la clave privada

CIPSC no archivará la clave privada de firma de certificados después de la expiración del periodo de validez de la misma.

Las claves privadas de los certificados internos que usan los distintos componentes del sistema de la AC para comunicarse entre sí, firmar y cifrar la información podrán ser archivadas, después de la emisión del último certificado.

Las claves privadas de los firmantes y creadores de sellos pueden ser archivadas por ellos mismos, mediante la conservación del dispositivo de creación de firma u otros métodos, debido a que pueden ser necesarias para descifrar la información histórica cifrada con la clave pública, siempre que el dispositivo de custodia permita la operación.

3.4.2.6.- Trasferencia de la clave privada a o desde el módulo criptográfico

Sólo en caso de contingencia se utiliza el procedimiento a que se refiere el apartado 3.4.2.4, que se describe en el plan de contingencias, para recuperar las claves privadas en los módulos criptográficos.

3.4.2.7.- Almacenamiento de la clave privada en el módulo criptográfico

Las claves privadas, tanto de las AACC como AACC subordinadas se generan directamente dentro del módulo criptográfico que las va a albergar. CIPSC sigue para la generación de las claves de las AACC las recomendaciones de ETSI TS 101 456, 7.2.1.

En los casos en los que se almacenen claves privadas fuera de los módulos criptográficos, éstas estarán protegidas de forma que se asegure el mismo nivel de protección que si estuviesen físicamente en el interior de los módulos criptográficos. Todos los HSMs utilizados por CIPSC para almacenar claves privadas de Autoridades de Certificación poseen la certificación Common Criteria 4+.

3.4.2.8.- Método de activación de la clave privada

Las claves de la AC Raíz y de las AACC subordinadas se activan por un proceso que requiere la utilización simultánea de n de m dispositivos criptográficos.

El acceso a la clave privada del firmante o creador de sellos se realiza por medio de un PIN. El dispositivo tiene un sistema de protección contra intentos de acceso que lo bloquean cuando se introducen más de tres veces un código de acceso erróneo. El firmante o creador de sellos dispone de un código de desbloqueo del dispositivo. Si se introduce tres veces erróneamente, el dispositivo se bloquea definitivamente, quedando inservible.

3.4.2.9.- Método de desactivación de la clave privada

Un administrador puede proceder a la desactivación de la clave de las Autoridades de CIPSC mediante el procedimiento proporcionado por el sistema del HSM.

En el caso del firmante o creador de sellos, la extracción del dispositivo criptográfico del lector supone la finalización de cualquier acción de operación en curso.

3.4.2.10.- Método de destrucción de la clave privada

El manual del HSM proporciona un método seguro de destrucción de claves de la AC.

En el caso de retirar el HSM que alberga las claves de la AC, éstas serán destruidas.

Este procedimiento no se aplica a las claves de firma o autenticación de usuario emitidas en tarjeta criptográfica salvo, en el caso de renovación de claves reutilizando el mismo dispositivo criptográfico, en el cual se destruirá la clave anterior y se generarán nuevas claves sobre el mismo soporte.

3.4.2.11.- Calificación del módulo criptográfico

Según indicado en el apartado 3.4.2.1 del presente documento

3.4.3.- Otros aspectos de gestión del par de claves

3.4.3.1.- Archivo de la clave pública

Los certificados generados por la AC, y por lo tanto las claves públicas, son almacenados por la AC durante el periodo de tiempo obligado por la legislación vigente.

3.4.3.2.- Periodos de utilización de las claves pública y privada

Es el periodo de validez de cada uno de los certificados.

3.4.4.- Datos de activación

3.4.4.1.- Generación e instalación de datos de activación

  • Para los certificados de las AC, los datos de activación se generan en tokens criptográficos en posesión de personal autorizado,
  • Certificados emitidos en dispositivo criptográfico: la utilización de la clave privada asociada a cada certificado requiere de un dato de activación (PIN) o contraseña.El dato de activación (PIN) o contraseña:
    • Se genera de forma aleatoria por el software de CIPSC y se graba en el dispositivo criptográfico que soporta el certificado.
    • Se genera e imprime en el momento de emitirse el certificado.
    • Se entrega al usuario por un sistema que permite mantener la confidencialidad.
    • CIPSC proporciona al firmante o creador de sellos una función para el cambio del PIN en la tarjeta.
    • El PIN nunca se almacena.
  • Certificados emitidos en soporte software: la instalación y puesta en marcha de la clave privada asociada a los certificados requiere la utilización de los sistemas de seguridad que el propio usuario haya definido.

3.4.4.2.- Protección de datos de activación

En relación a los datos de activación de firma se requiere a los usuarios de los certificados:

  • Memorizarlos.
  • Emplear el máximo cuidado en protegerlos.
  • No almacenarlos junto al dispositivo criptográfico ni compartirlos con otras personas.
  • Cambiar el PIN y PUK antes de utilizarlo

3.4.4.3.- Otros aspectos de los datos de activación

No se estipula el tiempo de vida de los datos de activación. No obstante, se recomienda cambiarlos periódicamente para disminuir la posibilidad de que sean descubiertos.

3.4.5.- Controles de seguridad informática

3.4.5.1.- Requisitos técnicos específicos de seguridad informática

Existen una serie de controles en el emplazamiento de los diferentes elementos del sistema de prestación de servicio de certificación de CIPSC (AACC, BBDD de CIPSC, Servicios Internet de CIPSC, Operación AC y Gestión de Red):

  • Controles operacionales.
    • Se documentan los procesos de operación a cargo del operador de la A.C. Y el administrador del sistema de seguridad conforme a los manuales del fabricante del HSM.Existe un Plan de Contingencias.
    • Están implantadas herramientas de protección contra virus y códigos malignos.
    • Se lleva a cabo un mantenimiento continuado del equipamiento, con el fin de asegurar su disponibilidad e integridad continuadas.
    • La información de los soportes de información obsoletos y los medios removibles es borrada; los equipos son etiquetados y entregados al responsable de seguridad que los conserva en lugar seguro hasta su destrucción por parte de empresas especializadas.
  • Intercambios de datos. Los siguientes intercambios de datos van cifrados para asegurar la debida confidencialidad.
    • Transmisión de datos de registro entre las AARR y la base de datos de registro.
    • Transmisión de datos de prerregistro.
    • La comunicación entre las AARR y las AACC.
  • El servicio de publicación de revocaciones posee las funcionalidades necesarias para que se garantice un funcionamiento 24×7.
  • Control de accesos.
    • Se utilizarán IDs de usuario únicos, de forma que los usuarios son relacionados con las acciones que realizan y se les puede responsabilizar de sus acciones.
    • La asignación de derechos se lleva a cabo siguiendo el principio de concesión mínima de privilegios.
    • Eliminación inmediata de los derechos de acceso de los usuarios que cambian de puesto de trabajo o abandonan la organización.
    • Revisión trimestral del nivel de acceso asignado a los usuarios.
    • La asignación de privilegios especiales se realiza “caso a caso” y se suprimen una vez terminada la causa que motivó su asignación.

3.4.5.2.- Evaluación del nivel de seguridad informática

La seguridad de los equipos viene reflejada por un análisis de riesgos iniciales de tal forma que las medidas de seguridad implantadas son respuesta a la probabilidad e impacto producido cuando un grupo de amenazas definidas puedan aprovechar brechas de seguridad tal como se describe en el plan de contingencias y continuidad de negocio.

La seguridad física está garantizada por las instalaciones ya definidas anteriormente y la gestión de personal.

3.4.6.- Controles técnicos del ciclo de vida

3.4.6.1.- Controles de desarrollo de sistemas

Se realiza un análisis de requisitos de seguridad durante las fases de diseño y especificación de requisitos de cualquier componente utilizado en las aplicaciones de Autoridad de certificación y de Autoridad de Registro, para garantizar que los sistemas son seguros. Se utilizan procedimientos de control de cambios para las nuevas versiones, actualizaciones y parches de emergencia, de dichos componentes.

3.4.6.2.- Controles de gestión de la seguridad

CIPSC mantiene un inventario de todos los activos informáticos y realizará una clasificación de los mismos de acuerdo con sus necesidades de protección, coherente con el análisis de riesgos efectuado.

La configuración de los sistemas se audita de forma periódica, de acuerdo con lo establecido en la sección correspondiente de este documento.

Los sistemas de CIPSC se protegen contra virus y software no autorizado y malintencionado.

Se realiza un seguimiento de las necesidades de capacidad, y se planificarán procedimientos para garantizar suficiente disponibilidad electrónica y de almacenaje para los activos informativos.

3.4.7.- Controles de seguridad de red

Se garantiza que el acceso a las diferentes redes de CIPSC es limitado a individuos debidamente autorizados. En particular:

  • Se implementan controles (como por ejemplo cortafuegos) para proteger la red interna de dominios externos accesibles por terceras partes. Los cortafuegos se configuran de forma que se impidan accesos y protocolos que no sean necesarios para la operación de la CIPSC.
  • Los datos sensibles se protegen cuando se intercambian a través de redes no seguras (incluyendo los datos de registro del firmante/creador de sellos).
  • Se garantiza que los componentes locales de red (como enrutadores) se encuentran ubicados en entornos seguros, así como la auditoría periódica de sus configuraciones.

3.4.8.- Fuente de tiempo

CIPSC obtiene el tiempo de sus sistemas de una conexión al Real Observatorio de la Armada siguiendo el protocolo NTP. La descripción del protocolo NTP se puede encontrar en el estándar de IETF RFC 5905.