Product Cybersecurity Standard

Objective, history, addressees, application notes

Without sufficiently secure products, there can be no sufficiently secure processes: Cyber attackers regularly take advantage of the lack of IT security of networked products to successfully compromise IT systems and computer networks. As a result, companies are confronted with security gaps in their IT over which they often have no knowledge or control. To address this shortcoming, the European Union has introduced regulations such as the Cyber Resilience Act (CRA) to ensure higher security standards for all products with digital elements in the future.

The new „Product Cybersecurity Standard“ (PCS) supports the implementation of „security by design“ in IT products, i.e. the consideration of cybersecurity from the beginning of development to its discontinuation from the market. To this end, it defines basic requirements for what distinguishes data-secure and privacy-compliant digital and networked products, taking into account the current digital threat situation. The set of requirements provides concrete assistance for manufacturers of connected products in their timely preparation for the implementation standards of the Cyber Resilience Act and beyond. They are basednon the proven EICAR standards, which have stood for additional security in networked products for years.

The PCS enable companies and providers of networked services to create the basis for higher IT security for their products by means of an initially voluntary public commitment, which in some cases goes beyond regulatory requirements: additional hurdles are imposed in particular for the use of data and information by third parties. In this way, PCS is meeting the increased manufacturer responsibility in the field of IT security and the growing need for trust in networked products. trol systematics, data flows, external and internal interfaces, data storage, personnel security, etc.

A. To Claim Adherence To This Product Cybersecurity Standard,
An It Product Shall Fulfil The Following Requirements:

  1. The requirements in this standard apply to all parts of the product including the whole digital supply-chain and product lifecycle:- Code developed by the vendor (which includes the developer/manufacturer of the IT product)
    – Code developed by external parties and included in the product by the vendor, including open source
    – Code run on the user’s device
    – Any form of hardware necessary for the proper operation of the IT product
    – Backend systems operated by the vendor or any subcontractor or third party to the extent they store, or process data received from the user’s device or are relevant for the functionality of the user’s device including cloud computing.The term “code” is to be understood broadly in this context and refers to all instructions that are created for a computer program or part thereof as part of software development and that de-scribe, represent and influence its functionality in a specific programming language. This inclu-des not only the program code itself, but also its management governance, identity and rights.
  2. The product must comply with the principles of security by design. This requires threat modelling to take place from the start of development to the end of the product life cycle. Only a vendor with in depth knowled-ge of the system architecture, will be able to identify product-related risks and take risk-mitigating measures.
  3. The vendor shall have a sufficient understanding of all code in the product, both internally and ex-ternally developed, to be able to ensure compliance with this standard. The vendor shall have imple-mented a governance process for third party code, which is defined, documented and strictly followed.
  4. The vendor shall have sufficient control over all parts of the product’s code, both, internally and externally developed, to make sure that any discovered faults that conflict with this standard can be mitigated promptly. This requires a timely patch management and coordinated vulnerability disclosure (CVD) policies which are made public for access of cybersecurity researchers and cybersecurity authorities. The vendor shall be especi-ally aware of third-party risks and should choose third parties responsibly according to pre-defined standards.
  5. The vendor shall have IT emergency plans in place enabling him to react appropriately to IT emergency situati-ons, document them, minimize damage and restore functionality as quickly as possible. In case of a vulnerability, a security gap, a data breach or any other malfunction, the vendor shall inform his clients and, if applicable, the com-petent authorities immediately. The vendor shall develop, promote and support appropriate countermeasures.
  6. The vendor shall publish a privacy declaration covering the product and its ecosystem. This declaration is written in a clear and comprehensive way and does not obfuscate relevant information. It contains at least the items mentioned in this standard and is kept up to date when new versions of the product are released.
  7. The product is designed to fulfil solely its claimed objectives; the claimed objectives are fully described in the product documentation and privacy declaration.
  8. The vendor does not support any scheme that requires the non-detection of malicious activities concerning the product and its ecosystem that could be harmful to the user, its IT systems and the protection of any kind of data.
  9. The product does not contain any hidden functionality or any other intended functionality that is not an-ticipated by the publicly claimed objectives, including the product documentation and privacy declaration.
  10. More specifically, the product does not contain any back door, and the vendor does not support any third-party access (TPA) scheme. Back door means any, published or non-published access to the application, its code and user data other than the access described with the claimed objectives, which are clearly publicly sta-ted according to the values of this standard, as well as in the product documentation and privacy declaration.
  11. The product uses cryptographic methods to protect data that is transferred to and from the device and pro-cessed at any location under the control of the vendor, including the device itself, subcontractors and third par-ties. The vendor uses cryptographic methods to ensure the integrity of any code, updates or data installed on the user’s devices as part of the product. Any used cryptographic method is based on algorithms and protocols that are considered to be of sufficient strength according to the current state of the art of technology also with regard to future technology developments. Code providing cryptographic algorithms and protocols is either based on widely accepted crypto libraries or otherwise engineered to provide sufficient security and be of suffi-cient quality to ensure a high level of data confidentiality according to the current state of the art of technology.
  12. Information identifying the device owner, the product license owner or any other natural person using the de-vice must not be transferred to the vendor unless there is a compelling reason as an exceptional case (privacy by design). The privacy declaration shall clearly and publicly state if such data is transferred, to what extent and for what (legal) reason. Where possible, the user‘s consent must be obtained in advance after giving sufficient information.
  13. Where data is processed by the vendor, any subcontractor or third party, appropriate identity and ac-cess control management and system security should ensure that only authorized persons have access to the data necessary for the functioning of the product.
  14. User-owned content, like contacts, passwords, messages, pictures, documents and any other perso-nal files, must not be transferred to the vendor, a subcontractor or any other third party without the user’s explicit consent, which is not automatically preselected (privacy by default). The privacy declaration shall clearly state in advance if such data can be transferred, to what extent, for what reason, when the trans-ferred data will be deleted, and which measures are taken to secure the transferred datasets adequately.
  15. Technical information, like device configuration, the application files, usage of features in the product, installed updates and other similar data, may be processed by the vendor only if this data is absolutely essential for fulfilling the product’s intended purpose and security and is not in conflict with any signifi-cant user interest or the declarations in this general standard. The privacy declaration shall clearly and publicly state in advance if such data is transferred, to what extent, for what reason, when the transfer-red data will be deleted and which measures are taken to secure the transferred datasets adequately.
  16. The product must comply with all general legal requirements of the law of the country in which it is used. If stricter legal requirements for cybersecurity and data privacy apply in certain countries than is the case in the country of origin of the product, the product must demonstrably comply with these stricter legal requirements.
  17. If any type of product related data is transferred to a foreign country with a different definition of (di-gital) legal protection than the country of origin of the data, including the possible access by security aut-horities and/or intelligence agencies including lawful interception of user data, the user will be explicitly informed of this and of the associated risks before using the product. This can be done, for example, in the product documentation or the privacy declaration. Users must be aware of the potential risks of in-ternational data storage in advance so that they can make an informed decision. Wherever possible, the vendor must provide adequate technical and organizational protective measures to compensate for the-se risks and to inform the user as fast as possible of any kind of data access according to this provision.

B. The Vendor Of The Product Agrees To Be Subject To An Indepen-Dent Evaluation And Verification Of The Above Identified Requi-Rements. All The Afore Mentioned Measures Must Be Documented Accordingly By The Vendor So That They Can Be Easily Presented In The Course Of Such A Verification.

Download Info-Flyer

Trustworthiness Strategy

The EICAR Trustworthiness Strategy is to enhance transparency in the contemporary IT Security environment and its ever evolving threats and vulnerabilities scenario and to enable trust into IT Security products that help creating a safer environment.

The strategy encompasses first steps to enhance trust and transparency into IT security products by developing minimum standards for the trustworthiness of IT security products, starting by developing minimum standards for Anti Malware-products and the development of minimum requirements for testing organizations. Subsequent steps encompass testing, verification and certification schemes and community building.

Currently EICAR is in quest of finding industry partners as corporate EICAR Members who would actively participate and contribute to the process of adaption to the constant changing environment and the furthering of the research endeavour for the verifiability of trustworthiness.

Recently the AV Test Lab “Vezprog” and the AV vendor G-Data have become new EICAR partners in the Trustworthiness Strategy.
A two days WS in week 17 (the exact days still t.b.c.) with partners is planned to be held at G-Data premises in Bochum at which the German Federal Office for Information Security (BSI) has also indicated its interest of partnership and participation.