Category

Conformity Assessment

Componente de videoidentificación remota para servicios EIDAS de emisión de certificados

By #eIdAS, Auditoría, Certificados cualificados, Conformity Assessment, Electronic Trust Services, EN 319 411-1, EN 319 411-2, Remote identification, SEPBLAC, TS 119 461, Video onboardingNo Comments

La comprobación de identidad no es un servicio de confianza eIDAS por sí mismo, sino un componente de otros servicios de confianza. Un componente de servicio de comprobación de identidad remota puede ser utilizado por muchos servicios de confianza diferentes.

Los prestadores de servicios de identificación remota en base a sistemas de transmisión de video y audio desde el equipo del solicitante pueden ser auditados siguiendo la norma ETSI EN 319 403-1 de modo que esta auditoría pueda ser utilizada posteriormente por un prestador cualificado de servicios de emisión de certificados sin que este apartado del servicio tenga que ser auditado de nuevo.

La norma utilizada para evaluar prestadores de servicios de identificación remota es la recientemente publicada ETSI TS 119 461.  Esta norma se ha desarrollado considerando los siguientes aspectos:

  • Está basada en la norma ETSI EN 319 401 que recoge los requisitos comunes para todos los servicios de confianza.
  • Incluye requisitos específicos para la comprobación de la identidad de personas físicas.
  1. Recopila los requisitos de las mejores prácticas sobre cómo utilizar determinados medios para implementar las tres tareas de «recogida de atributos y evidencias electrónicas»,
    «comprobación de atributos y evidencias electrónicas», y «vinculación de la acción solicitada (por ejemplo, emisión de un certificado) con la identidad de solicitante».
  2. Especifica cómo pueden construirse los procesos de demostración de la identidad mediante la combinación de medios para alcanzar el resultado básico deseado del proceso de comprobación de la identidad
  • Enlaza con los requisitos del apartado 6.2 de las normas  EN 319 411-1 y EN 319 411-2 6.2 indicando formas de dar cumplimiento a esos requisitos mediante la identificación remota.
  • Aunque establece los requisitos específicos para prestar servicios de confianza cualificados, por ejemplo, de expedición de certificados cualificads de persona física,  el servicio de comprobación de la identidad no es por si solo un servicio cualificado.

Los requisitos de seguridad de la norma ETSI TS 119 461 cubren los riesgos más comunes, que se dividen en dos categorías principales:

  • Evidencias falsificadas: Un solicitante alega falsamente una identidad  utilizando medios de pruebas falsificados.
  • Suplantación de identidad: Un solicitante utiliza medios de prueba válidos asociados a otra persona

También se tienen en cuenta potenciales riesgos operativos y los riesgos de ingeniería social.

Las notificaciones electrónicas y el correo electrónico certificado esenciales en las relaciones a distancia

By #eIdAS, Auditoría, Conformity Assessment, Conformity Assessment Body, electronic delivery, Electronic Trust Services, Entrega certificada, notificacionesNo Comments

Cuando las calles, negocios y edificios públicos se vaciaban, otros lugar ganaban protagonismo. Las notificaciones electrónicas ya lo venían haciendo, pero son otras de las protagonistas de este periodo de Estado de alarma por la pandemia COVID-19. 

Un sistema electrónico de notificaciones  permite que cualquier tipo de persona física o jurídica, pueda recibir los distintos avisos y documentos que las Administraciones Públicas han emitido  en formato digital.

La Agencia Tributaria, la Dirección General De Tráfico o la Seguridad Social son los principales organismos emisores de este tipo de notificaciones que permiten a las entidades públicas un ahorro importante en aspectos de mensajería y a los usuarios ahorrar tiempo de desplazamiento ya que no hsy que estar presentes en el momento en el que la notificación es entregada. 

El sectot privado también ha desarollado sistemas de notificación fehaciente, que en la actualidad pueden adaptarse a lo exigido por el Reglamento UE 910/2014 (EIDAS) y así pueden convertirse en sistemas de entrega certificada. Lo contempla en Reglamento EIDAS en los artículos 43 y 44:

Artículo 43

Efecto jurídico de un servicio de entrega electrónica certificada

1.   A los datos enviados y recibidos mediante un servicio de entrega electrónica certificada no se les denegarán efectos jurídicos ni admisibilidad como prueba en procedimientos judiciales por el mero hecho de que estén en formato electrónico o no cumplan los requisitos de servicio cualificado de entrega electrónica certificada.

2.   Los datos enviados y recibidos mediante un servicio cualificado de entrega electrónica certificada disfrutarán de la presunción de la integridad de los datos, el envío de dichos datos por el remitente identificado, la recepción por el destinatario identificado y la exactitud de la fecha y hora de envío y recepción de los datos que indica el servicio cualificado de entrega electrónica certificada.

Artículo 44

Requisitos de los servicios cualificados de entrega electrónica certificada

1.   Los servicios cualificados de entrega electrónica certificada cumplirán los requisitos siguientes:

a)

ser prestados por uno o más prestadores cualificados de servicios de confianza;

b)

asegurar con un alto nivel de fiabilidad la identificación del remitente;

c)

garantizar la identificación del destinatario antes de la entrega de los datos;

d)

estar protegidos el envío y recepción de datos por una firma electrónica avanzada o un sello electrónico avanzado de un prestador cualificado de servicios de confianza de tal forma que se impida la posibilidad de que se modifiquen los datos sin que se detecte;

e)

indicar claramente al emisor y al destinatario de los datos cualquier modificación de los datos necesarios a efectos del envío o recepción de los datos;

f)

indicar mediante un sello cualificado de tiempo electrónico la fecha y hora de envío, recepción y eventual modificación de los datos.

En caso de que los datos se transfieran entre dos o más prestadores cualificados de servicios de confianza, se aplicarán los requisitos establecidos en las letras a) a f) a todos los prestadores cualificados de servicios de confianza.

2.   La Comisión podrá, mediante actos de ejecución, establecer números de referencia de normas relativas a los procesos de envío y recepción de datos. Se presumirá el cumplimiento de los requisitos establecidos en el apartado 1 cuando el proceso de envío y recepción de datos se ajuste a dichas normas. Estos actos de ejecución se adoptarán con arreglo al procedimiento de examen contemplado en el artículo 48, apartado 2.

Aunque la Comisión no ha publicado normas  que supongan la presunción de cumplimiento, ETSI ha publicado las siguientes normas de evaluación:

  • EN 319 521 – Política y requisitos de seguridad para los proveedores de servicios de entrega electrónica certificada (Policy & security requirements for electronic registered delivery service providers )
  • EN 319 531 – Política y requisitos de seguridad para los proveedores de servicios de correo electrónico certificado – CEC (Policy & security requirements for registered electronic mail – REM – service providers)-

En TCAB, estamos en disposición de evaluar prestadores de servicios de confianza de entrega electrónica certificada según el Reglamento EIDAS y la normativa técnica de ETSI. Llamenos al +34 91 388 0789 para aclarar sus dudas.

 

Auditorías de seguridad para proyectos con Blockchain y SmartContracts

By Auditoría, Blockchain, Conformity AssessmentNo Comments

Según algunas estimaciones, las empresas de tecnología de blockchain pueden esperar volúmenes de negocio de 6 mil millones de euros en 2020. Sin embargo, antes deben lidiar con las vulnerabilidades de seguridad de blockchain, que, a pesar de su relevancia se siguen minusvalorando cuando se trata de la  llamada tecnología de “contabilidad distribuida”.

Un inciso terminológico, para acotar el término “libro mayor distribuido” (distributed ledger technology, DLT) que cuenta con una traducción más afortunada como “contabilidad distribuida”.  En mi opinión se ajusta más a la realidad el término “RJT Replicated Journal Technology”  ya que el tipo de libro contable que registra los movimiientos en las blockchains es el llamado “libro diario”. Por ello, mi preferencia frente al término DLT es el de  RJP Replicated Journal Paradigm o RJT Replicated Journal Technology

Vulnerabilidades de seguridad en cadenas de bloques

Algunos aspectos de la seguridad tienen que ver con el uso de la criptografía, y dado que en los contextos de cadenas de bloques se usa intensivamente la criptografía, existe la creencia generalizada de que los sistemas de blockchain, son seguros de por sí.

Sin embargo en sistemas complejos aparecen continuamente diferentes vectores de ataque que hay que identificar y remediar, por lo que el exceso de confianza en la tecnología puede ser peligroso.

De hecho, la tecnología denominada DLT está sujeta a una serie de problemas que las bases de datos centralizadas no tienen.

Los riesgos de seguridad de Blockchain  existen, y deben ser reconocidos y mitigados para que  blockchain cumpla su promesa de transformar la manera en que se almacenan los datos y cómo afectan a los proyectos que las usan.

A medida que más sectores gubernamentales, industriales y comerciales adoptan la tecnología, la necesidad de abordar estos problemas más pronto que tarde se convierte en primordial.

Vulnerabilidades de Blockchain

Vulnerabilidades del sistema de interfaz

Una de las vulnerabilidades más probables con DLT se origina fuera de la propia blockchain.

El sistema de interfaz es el equipo que un usuario emplea para acceder a servicios basado en blockchain.

En ese sistema se introducen las credenciales, motivo suficiente para atraer atacantes que aprovechen vulnerabilidades. Otras veces, manipular el “clipboard” la zona de memoria usada para las funciones de copiar y pegar puede permitir a un atacante cambiar la cuenta de destino de una transacción.

La detección de malware es una funcionalidad deseable en las herramientas que prevean minimizar los ataques a sistema de interfaz.

Seguridad de la criptografía de clave pública

Quienes proponen transacciones para que formen pare de la cadena (por ejemplo, transferencias de valor en el caso de los criptoactivos y criptomonedas) las firman con una clave privada y dan información sobre su clave pública. La clave privada se archiva con la cartera o mecanismo equivalente. La protección del equipo es de nuevo, esencial. Pero existen ciertos riesgos (por ejemplo, en base a la computación cuántica) que en el futuro podría permitir obtener la clave privada a partir de la pública. Para minimizar el riesgo, hay técnicas asociadas a carteras de un solo uso que se pueden adoptar.

Los backups de claves no se deberían conservar en el sistema que se usa a diario. Y aún menos sin cifrar.

Plataformas de terceros

Conforme se popularizan las cibermonedas y las aplicaciones que emplean tecnologías afines (como DLT) el mercado de soluciones de terceros experimentará crecimiento. Algunos posibles servicios a ofertar por terceros son:

  • Plataformas de integración de Blockchain
  • Procesadores de pago
  • Carteras
  • Entidades Fintech
  • Plataformas de pago de criptomonedas
  • Contratos inteligentes

Estas plataformas usan diferentes tecnologías vulnerables, además de las específicas de blockchain. Son verdaderos Prestadores de Servicios de Confianza Digital y deberían cumplir la norma EN 319 401 que el Reglamento EIDAS impone a los Prestadores Cualificados.

Control del paso a producción

Cuando se inicia un proyecto o se evoluciona dentro de el, deben realizarse pruebas exhaustivas para detectar vulnerabilidades en el código antes de su paso a entorno final de ejecución. Eso es de especial relevancia en los smartcontracts. En los smarcontracts se usan con frecuencia lenguajes como Solidity, con “defectos” similares a los de Javascript. Un caso de especial relevancia puede ser incluir entre comillas las direcciones de las carteras. De no hacerlo, las direcciones se truncan y los montos remitidos pueden acabar en un limbo irrecuperable.

Tamaño de la cadena de bloques

Dependiendo del tipo de criptoactivo y de como se ha diseñado su sistema de gestión de transacciones para su anotación en la cadena de bloques, puede ser que sea necesario conservar toda la cadena de bloques desde sus orígenes. Algunas variantes permiten convertir el histórico de transacciones en una “foto de estado” a partir de la cual puede desecharse el histórico anterior. Sea como sea, cuantas más transacciones se hacen más crece la cadena, lo que puede crear problemas de dimensionamiento en los equipos en los que se gestionan.

Ataques del 51%

Algunos sistemas de criptoactivos con diferentes filosofías de confirmación de bloques (PoW, Proof of Work, PoS, Proof of Stake, …) podrían atacarse por colectivos que que superen el 51% de participación en el mecanismo de consenso. Por tanto convendría prever si es necesario contar con mecanismos de reversión, y la responsabilidad de ejecución de tales mecanismos.

Se han dado casos reales de este tipo de ataque sobre mecanismo Pow (teórico hasta hace poco tiempo) que se entiende sabiendo que un gran número de centros de acumulación de equipamiento de minería se construyen en países donde la energía eléctrica es barata y la supervisión escasa

Falta de madurez de la tecnología

En todas las tecnologías se aprenden lecciones esenciales conforme se adoptan y se generalizan. Se descubren problemas y se reselven. La tecnología blockchain todavía está en los estadios iniciales de desarrollo y no se comprenden todos los riesgos y sus efectos.

Riesgos por normalización insuficiente

Muchos de los sistemas de blockchain se despliegan con un “Whitepaper” y código fuente del proyecto disponible en Github. Aunque es un ejercicio de transparencia, a menudo se revela que los promotores de tales proyectos tienen escaso interés en conocer los estándares o en adoptarlos.

Es particularmente llamativo en el ámbito de la firma electrónica, cuyo mercado principal ha madurado a lo largo de los años dando lugar a diversas leyes y normas técnicas que crean presunciones legales a quienes adoptan la tecnología y que define los estándares que facilitan su interoperabilidad.

En cambio, el uso de la tecnología de firma electrónica en los proyectos de blockchain parece provenir de alumnos de grado que han leído lo básico de la teoría de firma electrónica y que ignoran el avance de los estándares. Parecen ejercicios académicos, en vez de responder  exigencias de un mercado que impone que los sistemas puedan interoperar y que sus desarrolladores conozcan las leyes y los estándares.

Afortunadamente UNE e ISO (entre otros organismos de estandarización) están comenzando a proponer estándares para el mundo de blockchain, que no deberían soslayar los avances producidos en las tecnologías comunes con cierto nivel de madurez.

Cabe recordar que la estandarización, contra lo que afirman sus críticos, no cercena  la innovación sino que abre nuevas posibilidades para ella. Y deja resueltos problemas que se acometieron en el pasado minimizando el riego a reinventar a rueda cada vez.

Vulnerabilidades sutiles

Existen vulnerabilidades difíciles de detectar que se hacen visibles tras incidentes de cierta magnitud. Conviene prever mecanismos de reversión antes del despliegue para poder gestionar los problemas que no se han podido identificar con anterioridad.

Un ejemplo nos lo enseña el caso de “The DAO”

Una”DAO” (Distributed autonomous organization) es una Organización Autónoma Descentralizada construida en algunos tipos de blockchain, con funcionalidad de ejecución de código para contratos inteligentes asociados a inversiones en el capital de empresas marcadamente digitales. Se podría decir que un DAO es un fondo de capital  riesgo de crowdsourcing que se gestiona en base a smartcontracts embebidos en una cadena de bloques. Hay muchos DAO, cada uno creado para alojar y ejecutar contratos inteligentes para organizaciones específicas.

Uno de esos DAO, conocido como “The DAO”, fue fundado en 2016 por miembros del equipo de Ethereum. Durante su período de creación, The DAO hizo historia en el ámbito del crowdfunding recaudando 150 millones de dólares. Poco después, The DAO hizo historia, una vez más, al ser el primer DAO en ser pirateado.

Durante el crowdsale, muchos miembros de la comunidad de Ethereum expresaron su preocupación de que el código DAO fuera susceptible de ser atacado. Posteriormente, un miembro del equipo de la DAO encontró un “error recursivo” pero erróneamente creyó que no había fondos de la DAO en riesgo. Un hacker demostró que estaba equivocado.

El ataque se produjo cuando el atacante explotó dos vulnerabilidades en el código DAO. El hacker sabía que el código estaba diseñado para permitir tanto una división como una transferencia de tokens entre cuentas. El hacker también se dio cuenta de que el código no actualizaría los saldos de las cuentas lo suficientemente rápido como para evitar la transferencia de los mismos tokens más de una vez.

El hacker ejecutó una función de escisión, creando una cuenta “child DAO” y realizó repetidas solicitudes de transferencia desde su primera cuenta en rápida sucesión. Como el código no disminuía los saldos de cuenta originales después de cada transferencia, no había nada que impidiera que los mismos tokens se repitieran unas 40 veces cada uno, sin que se destruyeran los tokens originales.

Después de transferir $ 55 millones en Ether, el hacker dio por terminado el ataque y algunos hechos adicionales se sucedieron, por lo que invito a investigar sobre este asunto del que se extraen grandes eseñanzas.

A quien acudir.

Cuando se plantean proyectos serios de blockchain, sus impulsores invierten en los desarrolladres de tecnología que ayudan a definir los tipos de transacción, los modelos de gestión de identidad, los mecanismos de confirmación de bloques, los ritmos de producción de bloques y el límite de transacciones por bloque. Hay muchos aspectos que hacen diferencial cada proyecto.

Uno de que deberá empezar a tenerse en cuenta es el de la auditoría de proyecto. Quizá no detecte todos los problemas, pero descubrirá los principales. hay que empezar a poner en valor lo que ya se conoce y evitar cometer errores que ya se cometieron.

Contacte con Trust Conformity Assessment Body (TCAB) si necesita auditar un proyecto de blockchain.

eIdAS: Evaluación de Conformidad de Prestadores de Servicios Electrónicos de Confianza

By Conformity AssessmentNo Comments

El cumplimiento de los requisitos del Reglamento UE 910/2014 (eIdAS) por parte de los prestadores cualificados de servicios electrónicos de confianza se traduce en el cumplimiento de varias normas técnicas que usará el auditor para evaluar a la entidad:

El evaluador, por ejemplo TCAB (Trust Conformity Assessment Body), debe estar acreditado en base a la norma EN 319403 basada a su vez en la norma ISO 17065.

Una vez el prestador recibe el CAR (Conformity Assessment Report) (en español, IEC, Informe de evaluación de la conformidad) debe presentarlo al organismo de supervisión, la Secretaría de Estado de Telecomunicaciones y para la Sociedad de la información del Ministerio de Industria, Energía y Turismo.

Una vez, notificado el CAR, la SETSI incorporará la información del Prestador en la Lista de Confianza TSL, lo que implica el reconocimiento y admisibilidad de los servicios auditados en toda Europa.

 

Requisitos de seguridad para Prestadores de Servicios de Confianza Digital

By Conformity AssessmentNo Comments

La norma EN 319 401 establece las medidas de seguridad técnicas y irganizativas que deben cumplir los prestadores de servicios de confianza digital.

Este artículo es un breve estracto de tales requistos:

  • The TSP shall use trustworthy systems and products that are protected against modification and ensure the technical security and reliability of the processes supported by them. In particular:
  • The TSP shall control physical access to components of the TSP’s system whose security is critical to the provision of its trust services and minimize risks related to physical security. In particular:
    1. physical access to components of the TSP’s system whose security is critical to the provision of its trust services shall be limited to authorized individuals;
    2. controls shall be implemented to avoid loss, damage or compromise of assets and interruption to business activities;
    3. controls shall be implemented to avoid compromise or theft of information and information processing facilities; and
    4. components that are critical for the secure operation of the trust service shall be located in a protected security perimeter with physical protection against intrusion, controls on access through the security perimeter and alarms to detect intrusion
  • Appropriate security controls shall be in place for the management of any cryptographic keys and any cryptographic devices throughout their lifecycle.
  • The TSP’s system access shall be limited to authorized individuals.
    In particular:

    1. Controls (e.g. firewalls) shall protect the TSP’s internal network domains from unauthorized access including access by subscribers and third parties. Firewalls should also be configured to prevent all protocols and accesses not required for the operation of the TSP.
    2. The TSP shall administer user  access of operators, administrators and system auditors. The administration shall include user account management and timely modification or removal of access.
    3. Access to information and application system functions shall be restricted in accordance with the access control policy. The TSP system shall provide sufficient computer security controls for the separation of trusted roles identified in TSP’s practices, including the separation of security administration and operation functions. Particularly, use of system utility programs shall be restricted and controlled.
    4. TSP personnel shall be identified and authenticated before using critical applications related to the service.
    5. TSP personnel shall be accountable for their activities (e.g. retaining event logs).
    6. Sensitive data shall be protected against being revealed through re-used storage objects (e.g. deleted files) being accessible to unauthorized users.
  • All media shall be handled securely in accordance with requirements of the information classification scheme. Media containing sensitive data shall be securely disposed of when no longer required.
  • The TSP shall ensure an appropriate level of protection  of its assets including information assets. In particular, the TSP shall maintain an inventory of all information assets and shall assign a classification consistent with the risk assessment.
  • The TSP shall ensure that employees and contractors support the trustworthiness of the TSP’s operations. In particular:
    1. The TSP shall employ staff and, if applicable, subcontractors, who possess the necessary expertise, reliability, experience, and qualifications and who have received training regarding security and personal data protection rules as  appropriate for the offered services and the job function.
    2. TSP personnel should be able to fulfil the requirement of  «expert knowledge, experience and qualifications» through formal training and credentials, or actual experience, or a combination of the two. This should include regular (at least every 12 months) updates on new threats and current security practices.
    3. Appropriate disciplinary sanctions shall be applied to personnel violating TSP policies or procedures.
    4. Security roles and responsibilities, as specified in the TSP’s management security policy, shall be documented in job descriptions or in documents available to all concerned personnel. Trusted roles, on which the security of the TSP’s operation is dependent, shall be clearly identified. Trusted roles shall be named by the management and shall be accepted by the management and the person to fulfil the role.
    5. TSP personnel (both temporary and permanent) shall have job descriptions defined from the view point of roles fulfilled with segregation of duties and least privilege, determining position sensitivity based on the duties and access levels, background screening and employee training and awareness. Where appropriate, these shall differentiate between general functions and TSP specific functions. These should include skills and experience requirements.
    6. Personnel shall exercise administrative and management procedures and processes that are in line with the TSP’s information security management procedures.
    7. Managerial personnel shall possess experience or training with respect to the trust service that is provided, familiarity with security procedures for personnel with security responsibilities and experience with information security and risk assessment sufficient to carry out management functions.
    8. All TSP personnel in trusted roles shall be free from conflict of interest that might prejudice the impartiality of the TSP operations.
    9. Trusted roles shall include roles that involve the following responsibilities:
      • Security Officers: Overall responsibility for administering the implementation of the security practices.
      • System Administrators: Authorized to install, configure and maintain the TSP trustworthy systems for service management.
      • System Operators: Responsible for operating the TSP trustworthy systems on a day-to-day basis. Authorized to perform system backup and recovery.
      • System Auditors: Authorized to view archives and audit logs of the TSP trustworthy systems.
    10. TSP personnel shall be formally appointed to trusted roles by senior management responsible for security requiring the principle of «least privilege» when accessing or when configuring access privileges.
    11. Personnel shall not have access to the trusted functions until any necessary checks are completed.
  • Conflicting duties and areas of responsibility shall be segregated to reduce opportunities for unauthorized or unintentional modification  or misuse of the TSP assets.
  • The TSP shall carry out a risk assessment to identify, analyse and evaluate trust service risks taking into account business and technical issues.
  • The TSP  shall select the appropriate risk treatment measures, taking account of the risk assessment results. The risk treatment measures shall ensure that the level of security is commensurate to the degree of risk.
  • The TSP shall determine all security requirements and operational procedures that are necessary to implement the risk treatment options measures chosen as documented in the information security policy and the trust service practice statement.
  • The risk assessment shall be regularly reviewed and revised.
  • The TSP shall specify the set of policies and practices appropriate for the trust services it is providing. These shall be approved by management, published and communicated to employees and external parties as relevant.
  • The TSP shall have a statement of the practices and procedures for the trust service provided. In particular:
    1. The TSP shall have a statement of the practices and procedures used to address all the requirements identified for the applicable TSP policy.
    2. The TSP’s trust service practice statement shall identify the obligations of all external organizations supporting the TSP services including the applicable policies and practices.
    3. The TSP shall make available to subscribers and relying parties its practice statement, and other relevant documentation, as necessary to assess conformance to the service policy.
    4. The TSP shall have a management body with overall responsibility for the TSP with final authority for approving the TSP practice statement.
    5. The TSP management shall implement the practices.
    6. The TSP shall define a review process for the practices including responsibilities for maintaining the TSP practice statement.
    7. The TSP shall notify notice of changes it intends to make in its practice statement and shall, following approval by management, make the revised TSP practice statement immediately available to subscribers and relying parties.
    8. The TSP shall state in its practices the provisions made for termination of service
  • TSP shall make the terms and conditions regarding its services available to all subscribers and relying parties.
  • These terms and conditions shall at least specify for each trust service policy supported by the TSP the following:
    1. the trust service policy being applied;
    2. any limitations on the use of the service such as the expected life-time of public key certificates.
    3. the subscriber’s obligations, if any;
    4. information for parties relying on the trust service, such as how to verify the trust service token, any possible limitations on the validity period associated with the trust service token.
    5. the period of time during which TSP event logs are retained;
    6. limitations of liability;
    7. limitations on the use of the services provided including the limitation for damages arising from the use of services exceeding such limitations;
    8. the applicable legal system;
    9. procedures for complaints and dispute settlement;
    10. whether  the TSP’s trust service has been assessed to be conformant with the trust service policy, and if so through which conformity assessment scheme; and the TSP contact information.
  • Customers shall be informed about the limitations in advance.
  • Terms and conditions shall be made available through a durable means of communication. This information shall be available in a readily understandable language. It may be transmitted electronically.
  • The TSP shall define an information security policy which is approved by management and which sets out the organization’s approach to managing its information security. In particular:
    1. A TSP’s information security policy shall be documented, implemented and maintained including the security controls and operating procedures for TSP facilities, systems and information assets providing the services. The TSP shall publish and communicate this information security policy to all employees who are impacted by it.
    2. The TSP shall retain overall responsibility for conformance with the procedures prescribed in its information security policy, even when the TSP functionality is undertaken by outsourcers. TSP shall define the outsourcers liability and ensure that outsourcer are bound to implement any controls required by the TSP
    3. The TSP information security policy and inventory of assets for information security shall be reviewed at planned intervals or if significant changes occur to ensure their continuing suitability, adequacy and effectiveness. Any changes that will impact on the level of security provided shall be approved by the TSP high level management body. The configuration of the TSPs systems shall be regularly checked for changes which violate the TSPs security policies.
    4. A TSP’s management security policy shall be documented, implemented and maintained including the security controls and operating procedures for TSP facilities, systems and information assets providing the services.
  • The TSP organization shall be reliable. In particular:
    1. Trust service practices under which the TSP operates shall be non-discriminatory.
    2. The TSP shall make its services accessible to all applicants whose activities fall within its declared field of operation and that agree to abide by their obligations as specified in the TSP terms and conditions.
    3. The TSP shall maintain sufficient financial resources and/or obtain appropriate liability insurance, in accordance with national law, to cover liabilities arising from its operations and/or activities.
    4. The TSP shall have the financial stability and resources required to operate in conformity with this policy.
    5. The TSP shall have  policies and procedures for the resolution of complaints and disputes received from customers or other relying parties about the provisioning of the services or any other related matters.
    6. The TSP shall have a documented agreement and contractual relationship in place where the provisioning of services involves subcontracting, outsourcing or other third party arrangements.
  • Conflicting duties and areas of responsibility shall be segregated to reduce opportunities for unauthorized or unintentional modification  or misuse of the TSP assets.
  • The TSP shall ensure that employees and contractors support the trustworthiness of the TSP’s operations. In particular:
    1. The TSP shall employ staff and, if applicable, subcontractors, who possess the necessary expertise, reliability, experience, and qualifications and who have received training regarding security and personal data protection rules as  appropriate for the offered services and the job function.
    2. TSP personnel should be able to fulfil the requirement of  «expert knowledge, experience and qualifications» through formal training and credentials, or actual experience, or a combination of the two. This should include regular (at least every 12 months) updates on new threats and current security practices.
    3. Appropriate disciplinary sanctions shall be applied to personnel violating TSP policies or procedures.Security roles and responsibilities, as specified in the TSP’s management security policy, shall be documented in job descriptions or in documents available to all concerned personnel.
    4. Trusted roles, on which the security of the TSP’s operation is dependent, shall be clearly identified. Trusted roles shall be named by the management and shall be accepted by the management and the person to fulfil the role.
    5. TSP personnel (both temporary and permanent) shall have job descriptions defined from the view point of roles fulfilled with segregation of duties and least privilege (see clause 7.1.2), determining position sensitivity based on the duties and access levels, background screening and employee training and awareness. Where appropriate, these shall differentiate between general functions and TSP specific functions. These should include skills and experience requirements.
    6. Personnel shall exercise administrative and management procedures and processes that are in line with the TSP’s information security management procedures.
    7. Managerial personnel shall possess experience or training with respect to the trust service that is provided, familiarity with security procedures for personnel with security responsibilities and experience with information security and risk assessment sufficient to carry out management functions.
    8. All TSP personnel in trusted roles shall be free from conflict of interest that might prejudice the impartiality of the TSP operations.

i) Trusted roles shall include roles that involve the following responsibilities:
i) Security Officers: Overall responsibility for administering the implementation of the security practices.
ii) System Administrators: Authorized to install, configure and maintain the TSP trustworthy systems for service management.
iii) System Operators: Responsible for operating the TSP trustworthy systems on a day-to-day basis. Authorized to perform system backup and recovery.
iv) System Auditors: Authorized to view archives and audit logs of the TSP trustworthy systems.

j) TSP personnel shall be formally appointed to trusted roles by senior management responsible for security requiring the principle of «least privilege» when accessing or when configuring access privileges.
k) Personnel shall not have access to the trusted functions until any necessary checks are completed.
NOTE 9: In some countries it is not possible for TSP to obtain information on past convictions without the collaboration of the candidate employee.

 

The TSP shall ensure an appropriate level of protection  of its assets including information assets.
NOTE 1: See clause 8 of ISO/IEC 27002:2013 [i.3] for guidance.
In particular, the TSP shall maintain an inventory of all information assets and shall assign a classification consistent with the risk assessment.

All media shall be handled securely in accordance with requirements of the information classification scheme. Media containing sensitive data shall be securely disposed of when no longer required

 

The TSP’s system access shall be limited to authorized individuals.
In particular:
a) Controls (e.g. firewalls) shall protect the TSP’s internal network domains from unauthorized access including access by subscribers and third parties. Firewalls should also be configured to prevent all protocols and accesses not required for the operation of the TSP.
b) The TSP shall administer user  access of operators, administrators and system auditors. The administration shall include user account management and timely modification or removal of access.
c) Access to information and application system functions shall be restricted in accordance with the access control policy. The TSP system shall provide sufficient computer security controls for the separation of trusted roles identified in TSP’s practices, including the separation of security administration and operation functions. Particularly, use of system utility programs shall be restricted and controlled.
d) TSP personnel shall be identified and authenticated before using critical applications related to the service.
e) TSP personnel shall be accountable for their activities.
EXAMPLE: By retaining event logs.
f) Sensitive data shall be protected against being revealed through re-used storage objects (e.g. deleted files) being accessible to unauthorized users.

 

Appropriate security controls shall be in place for the management of any cryptographic keys and any cryptographic devices throughout their lifecycle

The TSP shall control physical access to components of the TSP’s system whose security is critical to the provision of its trust services and minimize risks related to physical security.

In particular:
a) physical access to components of the TSP’s system whose security is critical to the provision of its trust services shall be limited to authorized individuals;
NOTE 2: Criticality is identified through risk assessment, or through application security requirements, as requiring a security protection.
b) controls shall be implemented to avoid loss, damage or compromise of assets and interruption to business activities;
c) controls shall be implemented to avoid compromise or theft of information and information processing facilities; and
d) components that are critical for the secure operation of the trust service shall be located in a protected security perimeter with physical protection against intrusion, controls on access through the security perimeter and alarms to detect intrusion.

 

  • The TSP shall use trustworthy systems and products that are protected against modification and ensure the technical security and reliability of the processes supported by them.  In particular
    1. An analysis of security requirements shall be carried out at the design and requirements specification stage of any systems development project undertaken by the TSP or on behalf of the TSP to ensure that security is built into Information Technology’s systems.
      b) Change control procedures shall be applied for releases, modifications and emergency software fixes of any operational software.c) The integrity of TSP systems and information shall be protected against viruses, malicious and unauthorized software.
      d) Media used within the TSP systems shall be securely handled to protect media from damage, theft, unauthorized access and obsolescence.
      e) Media management procedures shall protect against obsolescence and deterioration of media within the period of time that records are required to be retained.
      f) Procedures shall be established and implemented for all trusted and administrative roles that impact on the provision of services.
      g) The TSP shall specify and apply procedures for ensuring security patches are applied within a reasonable time after they come available.  A security patch need not be applied if it would introduce additional vulnerabilities or instabilities that outweigh the benefits of applying the security patch. The reason for not applying any security patches shall be documented.

The TSP shall protect its network and systems from attack.
In particular:
a) The TSP shall segment its systems into networks or zones based on risk assessment considering functional, logical, and physical (including location) relationship between trustworthy systems and services. The TSP shall apply the same security controls to all systems co-located in the same zone.
b) The TSP shall restrict access and communications between zones to those necessary for the operation of the TSP. Not needed connections and services shall be explicitly forbidden or deactivated. The established rule set shall be reviewed on a regular basis.
c) The TSP shall maintain any elements of their critical systems (e.g. Root CA systems see ETSI EN 319 411-1 [i.12]) in a secured zone.
d) A dedicated network for administration of IT systems that is separated from the operational network shall be established. Systems used for administration shall not be used for non-administrative purposes.
e) Test platform and production platform shall be separated from other environments not concerned with live operations (e.g development).
f) Communication between distinct trustworthy systems shall only be established through trusted channels that are logically distinct from other communication channels and provide assured identification of its end points and protection of the channel data from modification or disclosure.
g) If external availability of the trust service is required, the external network connection to the internet shall be redundant to ensure availability of the services in case of a single failure. This may be achieved by two different network connections to one of more internet providers.
h) The TSP shall undergo or perform a regular vulnerability scan on public and private IP addresses identified by the TSP and record evidence that each vulnerability scan was performed by a person or entity with the skills, tools, proficiency, code of ethics, and independence necessary to provide a reliable report.
NOTE 1: See item 4c of the CA Browser Forum network security guide [i.8] for guidance regarding the time period.
i) The TSP shall undergo a penetration test on the TSP’s systems at set up and after infrastructure or application upgrades or modifications that the TSP determines are significant. The TSP shall record evidence that each penetration test was performed by a person or entity with the skills, tools, proficiency, code of ethics, and independence necessary to provide a reliable report.
NOTE 2: See item 4d of the CA Browser Forum network security guide [i.8] for guidance regarding the time period.

System activities concerning access to IT systems, user of IT systems, and service requests shall be monitored.
In particular:
a) Monitoring activities should take account of the sensitivity of any information collected or analysed.
b) Abnormal system activities that indicate a potential security violation, including intrusion into the TSP network, shall be detected and reported as alarms.
NOTE 1: Abnormal network system activities can comprise (external) network scans or packet drops.
c) The TSP IT systems shall monitor the following events:
i) Start-up and shutdown of the logging functions; and
ii) Availability and utilization of needed services with the TSP network.

d) The TSP shall act in a timely and co-ordinated manner in order to respond quickly to incidents and to limit the impact of breaches of security. The TSP shall appoint trusted role personnel to follow up on alerts of potentially critical security events and ensure that relevant incidents are reported in line with the TSP’s procedures.
e) The TSP shall establish procedures to notify the appropriate parties in line with the applicable regulatory rules of any breach of security or loss of integrity that has a significant impact on the trust service provided and on the personal data maintained therein.
NOTE 2: For TSPs operating within the European Union see Regulation (EU) No 910/2014 [i.2] Article 19.2 and contact the national supervisory body, or other competent authority for further guidance in implementing this article.
f) Where the breach of security or loss of integrity is likely to adversely affect a natural or legal person to whom the trusted service has been provided, the TSP shall also notify the natural or legal person of the breach of security or loss of integrity without undue delay.
g) Audit logs shall be monitored or reviewed regularly to identify evidence of malicious activity implementing automatic mechanisms to process the audit logs and alert personnel of possible critical security events.
NOTE 3: See clause 16 of ISO/IEC 27002:2013 [i.3] for guidance.
h) The TSP shall remediate within a reasonable period after the discovery of a critical vulnerability not previously addressed by the TSP. If this is not possible the TSP shall create and implement a plan to mitigate the critical vulnerability or the TSP shall document the factual basis for the TSP’s determination that the vulnerability does not require remediation.
NOTE 4: Further recommendations are given in the CA Browser Forum network security guide [i.8] item 4 f).
i) Incident reporting and response procedures shall be employed in such a way that damage from security incidents and malfunctions are minimized.

The TSP shall record and keep accessible for an appropriate period of time, including after the activities of the TSP have ceased, all relevant information concerning data issued and received by the TSP, in particular, for the purpose of providing evidence in legal proceedings and for the purpose of ensuring continuity of the service.
In particular:
a) The confidentiality and integrity of current and archived records concerning operation of services shall be maintained.
b) Records concerning the operation of services shall be completely and confidentially archived in accordance with disclosed business practices.
c) Records concerning the operation of services shall be made available if required for the purposes of providing evidence of the correct operation of the services for the purpose of legal proceedings.
d) The precise time of significant TSP environmental, key management and clock synchronization events shall be recorded. The time used to record events as required in the audit log shall be synchronised with UTC at least once a day.
e) Records concerning services shall be held for a period of time after the expiration of the validity of the signing keys or any trust service token as appropriate for providing necessary legal evidence and as notified in the TSP disclosure statement.
f) The events shall be logged in a way that they cannot be easily deleted or destroyed (except if reliably transferred to long-term media) within the period of time that they are required to be held.
EXAMPLE: This can be achieved, for example, through the use of write-only media, a record of each removable media used and the use of off-site backup.

In the event of a disaster, including compromise of the private signing key or trust service credentials, operations shall be restored as soon as possible. In particular, the TSP shall define and maintain a continuity plan to enact in case of a disaster.
NOTE 1: Other disaster situations include failure of critical components of a TSP trustworthy system, including hardware and software.
NOTE 2: See clause 17 of ISO/IEC 27002:2013 [i.3] for guidance.

Potential disruptions to subscribers and relying parties shall be minimized as a result of the cessation of the TSP’s services, and in particular continued maintenance of information required to verify the correctness of trust services shall be provided.
In particular:
a) The TSP shall have an up-to-date termination plan.
b) Before the TSP terminates its services at least the following procedures apply:
i) the TSP shall inform the following of the termination: all subscribers and other entities with which the TSP has agreements or other form of established relations, among which relying parties and TSP. In addition, this information shall be made available to other relying parties;
ii) TSP shall terminate authorization of all subcontractors to act on behalf of the TSP in carrying out any functions relating to the process of issuing trust service tokens;
iii) the TSP shall transfer obligations to a reliable party for maintaining all information necessary to provide evidence of the operation of the TSP for a reasonable period, unless it can be demonstrated that the TSP does not hold any such information; and
iv) TSP private keys, including backup copies, shall be destroyed, or withdrawn from use, in a manner such that the private keys cannot be retrieved;
v) where possible TSP should make arrangements to transfer provision of trust services for its existing customers to another TSP.
c) The TSP shall have an arrangement to cover the costs to fulfil these minimum requirements in case the TSP becomes bankrupt or for other reasons is unable to cover the costs by itself, as far as possible within the constraints of applicable legislation regarding bankruptcy.
d) The TSP shall state in its practices the provisions made for termination of service. This shall include:
i) notification of affected entities; and
ii) transferring the TSP obligations to other parties.
e) The TSP shall maintain or transfer to a reliable party its obligations to make available its public key or its trust service tokens to relying parties for a reasonable period.

The TSP shall ensure that it operates in a legal and trustworthy manner:
In particular:
a) The TSP shall provide evidence on how it meets the applicable legal requirements.
b) Trust services provided and end user products used in the provision of those services shall be made accessible for persons with disabilities.  Applicable standards such as ETSI EN 301 549 [i.13] should be taken into account.

c) Appropriate technical and organizational measures shall be taken against unauthorized or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data.
NOTE: TSPs operating in Europe are required to ensure that personal data is processed in accordance with Directive 95/46/EC [i.1]. In this respect,  authentication for a service online concerns processing of only those identification data which are adequate, relevant and not excessive to grant access to that service online.