Category

Conformity Assessment

Remote identification component for EIDAS certificate issuance services

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

Identity proofing is not an eIDAS trusted service by itself, but a component of other trusted services. A remote identity proofing service component can be used by many different trust services.

Providers of remote identification services based on video and audio transmission systems from the applicant’s equipment can be audited according to ETSI EN 319 403-1 so that this audit can subsequently be used by a qualified certificate issuing service provider without this part of the service having to be audited again.

The standard used to assess providers of remote identification services is the recently published standard ETSI TS 119 461. This standard has been developed taking into account the following aspects:

  • It is based on ETSI EN 319 401 which contains common requirements for all trust services.
  • It includes specific requirements for the verification of the identity of natural persons.
  1.  It compiles best practice requirements on how to use certain means to implement the three tasks of “collection of attributes and electronic evidence”, “verification of electronic attributes and evidence’, and ‘binding the requested action (e.g. issuing a certificate) to the identity of the applicant’.
  2. It specifies how identity proofing processes can be constructed by combining means to achieve the basic desired outcome of the identity proofing process.
  • It links to the requirements of section 6.2 of EN 319 411-1 and EN 319 411-2 by indicating ways to fulfil these requirements by remote identification.
  • Although it lays down specific requirements for providing qualified trust services, e.g. issuing of qualified certificates of natural persons, the identity verification service is not a qualified service by itself.

The security requirements of ETSI TS 119 461 cover the most common risks, which fall into two main categories:

  • Forged evidence: An applicant falsely claims an identity using forged means of evidence.
  • Impersonation: An applicant uses valid means of evidence associated with another person.

Potential operational risks and social engineering risks are also taken into account.

Saturday November 13th, 2021

Electronic notices and registered e-mail are essential in long-distance relationships.

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

As streets, businesses, and public buildings emptied, other places took center stage. Electronic notifications were already doing so, but they are another of the protagonists of this period of State of Alarm due to the COVID-19 pandemic.

An electronic system of notifications allows any type of natural or legal person to receive the different notices and documents that the Public Administrations have issued in digital format.

The Tax Agency, the Directorate General of Traffic, and the Social Security are the main issuing bodies of this type of notification that allow public entities to make significant savings in terms of messaging and users to save travel time as they no longer have to be present when the notification is delivered.

The private sector has also developed reliable notification systems, which can now be adapted to the requirements of EU Regulation 910/2014 (EIDAS) and can thus be converted into certified delivery systems. This is provided for in Articles 43 and 44 of the EIDAS Regulation:

Article 43 – Legal effect of an electronic registered delivery service

1.   Data sent and received using an electronic registered delivery service shall not be denied legal effect and admissibility as evidence in legal proceedings solely on the grounds that it is in an electronic form or that it does not meet the requirements of the qualified electronic registered delivery service.

2.   Data sent and received using a qualified electronic registered delivery service shall enjoy the presumption of the integrity of the data, the sending of that data by the identified sender, its receipt by the identified addressee and the accuracy of the date and time of sending and receipt indicated by the qualified electronic registered delivery service.

Article 44 – Requirements for qualified electronic registered delivery services

1.   Qualified electronic registered delivery services shall meet the following requirements:

(a)

they are provided by one or more qualified trust service provider(s);

(b)

they ensure with a high level of confidence the identification of the sender;

(c)

they ensure the identification of the addressee before the delivery of the data;

(d)

the sending and receiving of data is secured by an advanced electronic signature or an advanced electronic seal of a qualified trust service provider in such a manner as to preclude the possibility of the data being changed undetectably;

(e)

any change of the data needed for the purpose of sending or receiving the data is clearly indicated to the sender and addressee of the data;

(f)

the date and time of sending, receiving and any change of data are indicated by a qualified electronic time stamp.

In the event of the data being transferred between two or more qualified trust service providers, the requirements in points (a) to (f) shall apply to all the qualified trust service providers.

2.   The Commission may, by means of implementing acts, establish reference numbers of standards for processes for sending and receiving data. Compliance with the requirements laid down in paragraph 1 shall be presumed where the process for sending and receiving data meets those standards. Those implementing acts shall be adopted in accordance with the examination procedure referred to in Article 48(2).

Although the Commission has not published standards that provide a presumption of compliance, ETSI has published the following evaluation standards:

  • EN 319 521 – Policy & security requirements for electronic registered delivery service providers
  • EN 319 531 – Policy & security requirements for registered electronic mail (REM) service providers

At TCAB, we are in a position to assess trustworthy registered electronic delivery service providers. according to EIDAS and ETS Standards. Call us at +34 91 388 0789 to clarify your doubts.

 

Tuesday May 19th, 2020

Security audits for projects with Blockchain and SmartContracts

By Auditoría, Blockchain, Conformity AssessmentNo Comments

According to some estimates, blockchain technology companies can expect business volumes of 6 billion euros by 2020. However, they must first deal with blockchain security vulnerabilities, which, despite their relevance, continue to be underestimated when It deals with the so-called “distributed accounting” technology (or DLT).

A comment here, to clarify the “distributed ledger” (DLT) widespread term that in my opinion should be renamed as “distributed accounting”, or better, “RJT Replicated Journal Technology” since it really registers entries in the log as they are produced, not reflecting the accounting itself.

Security vulnerabilities in block chains

Some aspects of security have to do with the use of cryptography, and given that cryptography is used intensively in blockchain contexts, there is a widespread belief that blockchain systems are inherently safe.

However, in complex systems, different attack vectors appear that must be identified and remedied, so that excessive confidence in the technology can be dangerous.

In fact, the technology called DLT is subject to a series of problems that centralized databases do not have.

The security risks of Blockchain exist, and must be recognized and mitigated so that Blockchain fulfills its promise to transform the way in which data is stored and how it affects the projects that use it.

As more government, industrial and commercial sectors adopt technology, the need to address these problems sooner rather than later becomes paramount.

Blockchain Vulnerabilities

Vulnerabilities of the interface system

One of the most likely vulnerabilities with DLT originates outside of the blockchain itself.

The interface system is the equipment that a user uses to access services based on blockchain.

In this system credentials are introduced, enough reason to attract attackers who exploit vulnerabilities. Other times, manipulating the “clipboard” the memory area used for copy and paste functions can allow an attacker to change the destination account of a transaction.

Malware detection is a desirable feature in tools that anticipate minimizing attacks on the interface system.

Security of public key cryptography

Those who propose transactions to form part of the chain (for example, value transfers in the case of crypto-assets and cryptocurrencies) sign them with a private key and give information about their public key. The private key is filed with the portfolio or equivalent mechanism. The protection of the equipment is again essential. But there are certain risks (for example, based on quantum computing) that in the future could allow obtaining the private key from the public one. To minimize risk, there are techniques associated with single-use portfolios that can be adopted.

Key backups should not be kept on the system that is used daily. And even less without encrypting.

Third party platforms

As cyber-currencies and applications using related technologies (such as DLT) become popular, the third-party solutions market will experience growth. Some possible services to be offered by third parties are:

  • Blockchain integration platforms
  • Payment processors
  • Wallets
  • Fintech entities
  • Cryptocurrency payment platforms
  • Smart contracts

These platforms use different vulnerable technologies, in addition to blockchain-specific ones. They are true Providers of Digital Trust Services and should comply with the standard EN 319 401 that the EIDAS Regulation imposes on Qualified Providers.

Control of  deployment

When a project starts or evolves within it, exhaustive tests must be carried out to detect vulnerabilities in the code before it passes to the final execution environment. This is especially relevant in smartcontracts. In the smarcontracts languages ​​such as Solidity are frequently used, with “defects” similar to those of Javascript. A case of special relevance may be to include the addresses of the portfolios in quotes. If not, the addresses are truncated and the amounts remitted can end up in an irrecoverable limbo.

Size of the block chain

Depending on the type of cryptoactive and how its transaction management system has been designed for its annotation in the block chain, it may be necessary to preserve the entire chain of blocks from its origins. Some variants allow converting the transaction history into a “status photo” from which the previous history can be discarded. Be that as it may, the more transactions are made, the more the chain grows, which can create sizing problems in the equipment in which they are managed.

51% attacks

Some cryptoactive systems with different block confirmation philosophies (PoW, Proof of Work, PoS, Proof of Stake, …) could be attacked by groups that exceed the 51% participation in the consensus mechanism. Therefore, it would be advisable to anticipate the need for reversion mechanisms and the responsibility for the execution of such mechanisms.

There have been real cases of this type of attack on Pow mechanism (theoretical until recently) that is understood knowing that a large number of mining equipment accumulation centers are built in countries where electricity is cheap and supervision is scarce

Lack of maturity of blockchain technology

In all technologies, essential lessons are learned as they are adopted and generalized. Problems are discovered and reselled. Blockchain technology is still in the early stages of development and all risks and their effects are not understood.

Risks due to insufficient standardization

Many of the blockchain systems are deployed with a “Whitepaper” and source code of the project available on Github. Although it is an exercise in transparency, it is often revealed that the promoters of such projects have little interest in knowing the standards or adopting them.

It is particularly striking in the field of electronic signature, whose main market has matured over the years giving rise to various laws and technical standards that create legal presumptions for those who adopt technology and that define the standards that facilitate their interoperability.

In contrast, the use of electronic signature technology in blockchain projects seems to come from undergraduate students who have read the basics of electronic signature theory and who ignore the advance of the standards. They look like academic exercises, instead of responding to market demands that require systems to interoperate and that their developers know the laws and standards.

Fortunately UNE and ISO (among other standardization bodies) are beginning to propose standards for the blockchain world, which should not ignore the advances made in common technologies with a certain level of maturity.

It should be remembered that standardization, against what its critics affirm, does not limit innovation but opens up new possibilities for it. And leaves solved problems that were undertaken in the past minimizing the risk of reinventing the wheel each time.

Subtle vulnerabilities

There are vulnerabilities difficult to detect that are visible after incidents of a certain magnitude. It is advisable to provide for reversion mechanisms before deployment in order to manage problems that have not been previously identified.

An example is shown by the case of “The DAO”

A “DAO” (Distributed Autonomous Organization) is a Decentralized Autonomous Organization built on some types of blockchain, with code execution functionality for intelligent contracts associated with investments in the capital of markedly digital companies. You could say that a DAO is a crowdsourcing venture capital fund that is managed on the basis of embedded smartcontracts in a chain of blocks. There are many DAOs, each created to host and execute smart contracts for specific organizations.

One of those DAO, known as “The DAO”, was founded in 2016 by members of the Ethereum team. During its creation period, The DAO made history in the field of crowdfunding by raising 150 million dollars. Shortly after, The DAO made history, once again, by being the first DAO to be pirated.

During the crowdsale, many members of the Ethereum community expressed concern that the DAO code could be attacked. Subsequently, a member of the DAO team found a “recursive error” but erroneously believed that there were no DAO funds at risk. A hacker proved he was wrong.

The attack occurred when the attacker exploited two vulnerabilities in the DAO code. The hacker knew that the code was designed to allow both a split and a transfer of tokens between accounts. The hacker also realized that the code would not update account balances fast enough to prevent the transfer of the same tokens more than once.

The hacker executed a spinoff function, creating a “child DAO” account and made repeated transfer requests from his first account in quick succession. Since the code did not decrease the original account balances after each transfer, there was nothing to prevent the same tokens being repeated about 40 times each, without destroying the original tokens.

After transferring $ 55 million in Ether, the hacker terminated the attack and some additional events happened, so I invite you to investigate this issue from which great lessons are drawn.

Call us if you need us

When serious blockchain projects are proposed, their promoters invest in technology developments that help define transaction types, identity management models, block confirmation mechanisms, block production rates and transaction limits. per block. There are many aspects that make each project different.

One that should begin to be taken into account is that of the project audit. Maybe he does not detect all the problems, but he will discover the main ones. We must begin to value what is already known and avoid making mistakes that have already been committed.

Contact the Trust Conformity Assessment Body (TCAB) if you need to audit a blockchain project.

Wednesday July 11th, 2018

eIDAS: Conformity Assessment of Electronic Trust Service Providers

By Conformity AssessmentNo Comments

Compliance with the requirements of EU Regulation 910/2014 (eIdAS) by qualified Trust Electronic Service Providers consists in the compliance with several technical standards that the auditor will use to evaluate the entity:

The evaluator, for example TCAB (Trust Conformity Assessment Body), must be accredited on the basis of EN 319403  based itself on ISO 17065.

Once the TSP receives the CAR (Conformity Assessment Report) (in Spanish, IEC, Conformity Assessment Report) it must submit it to the Supervisory Body, to the State Secretariat for Telecommunications and to the Information Society of the Ministry of Industry, Energy and Tourism.

Once the CAR has been notified, the SETSI will incorporate the TSP’s information into the TSL Trust List, which implies the recognition and admissibility of the audited services in Europe.

 

 

Thursday September 22nd, 2016

Security requirements for Digital Trust Service Providers

By Conformity AssessmentNo Comments

The standard EN 319 401 establishes the technical and organizational security measures that must be met by Digital Trust Service Providers.

This article is a brief abstract of such requests:

  • 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:
    1. Security Officers: Overall responsibility for administering the implementation of the security practices.
    2. System Administrators: Authorized to install, configure and maintain the TSP trustworthy systems for service management.
    3. System Operators: Responsible for operating the TSP trustworthy systems on a day-to-day basis. Authorized to perform system backup and recovery.
    4. 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.

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:

  1. Start-up and shutdown of the logging functions; and
  2. 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.

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

Saturday January 23rd, 2016