|
Background: much of the security determined by software
The study underlines that “fundamental security principles and techniques are often overlooked: clear text password storage, SQL injection vulnerabilities, missing authorisation checks, insufficient logging etc.”. Yet, much of the security of systems is determined by software, as illustrated by ETSI’s technical specification 103 645 v.1.1.1 (Cyber Security for Consumer IoT) where a clear majority of cybersecurity provisions relate to the software implementation.
The study highlights the importance of Security Maturity Models to guide organisations in defining their level of security depending on the requirements they wish to fulfil. It also insists on the notion of security-by-design in the software development lifecycle.
Existing standards and good practices
The study mentions a list of existing standards and good practices, beginning with Common Criteria and OWASP ASVS (Application Security Verification Standard), a community developed verification framework.
Pages 7 to 9 for the complete list of standards and practices.
Missing elements in software security
First, the study points out that there is a lack of coordination between standardisation organisations, which results in standards often overlapping. There is no widely used standardised ways to assess horizontally the security of software products. The study notes that this is even worse for software security certification: only a few schemes exist with limited exposure and acceptance worldwide.
Secondly, the study observes that it is difficult for organisations and individuals to identify the level of security of software products. There is a strong information asymmetry between producers and consumers of software.
Thirdly, the report stresses the difficulties to maintain confidence in the security level of a software product over time as new vulnerabilities might be found or introduced by software changes. In addition, the software operational environment is not covered directly by the same evaluation process.
The study notes that security certification can ironically work against security when it comes to software update: if the software undergoes significant changes, issued certificates might become invalid, hence vendors might refrain from updating their software because they do not want to re-certify their products.
Fourthly, the study shows that assessment of security in a software development process is hard to perform in a reliable way. For instance, a lot of the process effectiveness is determined by skills and the priority security gets: these elements are difficult to measure.
ENISA’s recommendations
1) Develop a common repository for shared security measures
The study recommends aligning requirements across different schemes to prevent proliferation and fragmentation. They also advocate for mapping governance and documenting overlaps to define a common repository for shared security aspects (access control, authorisation, encryption etc.), threat models and approaches against known adversary tactics over different schemes as part of Article 55 of the Cybersecurity Act (CSA) on supplementary cybersecurity information.
“Manufacturer(s) or provider(s) of certified ICT products, ICT services or ICT processes, should consider the deployment and maintenance of repositories not only for publicly disclosed vulnerabilities but also for shared security aspects of certified products, services and processes towards aligning on requirement commonalities and ways to mitigate common security risks.”
2) Improve technical standards landscape
Following the publication of the Union Rolling Work Programme (CSA, Article 47) standardisation bodies should coordinate on the priority areas they can support, put forward standardisation activities to benefit the future developed schemes and communicate periodically such planning to the European Commission and relevant CSA stakeholders.
3) Provide assurance in the engineering process
EU cybersecurity certification schemes should include not only requirements for the end product/service/process but also assurance for the engineering process, by setting process guidelines for software development, maintenance and operation.
4) Increased schemes applicability and clearly communicated assumptions
The study underlines the value of lightweight conformity assessment for Level of Assurance basic during the development of EU cyber certification schemes. Lightweight conformity assessment could be particularly suitable to address the issue of re-certification (through third parties), companies would no longer be prevented from releasing updated software. Certification of the secure software development process is also recommended. The study notes that certification schemes should be applicable horizontally to the widest extent possible.
Furthermore, software and product manufacturers should put forward their experience and expertise and promote the uptake of EU cybersecurity certification schemes, including the self-assessment components.
In addition, during the development of the EU cybersecurity certification schemes, EC, ENISA, SCCG and ECCG should ensure that assumptions on the scope, application area, mitigated threats and achieved security characteristics achieved are clearly communicated to the end users of the framework.
For any question on this issue, do not hesitate to contact Camille Dornier: camille.dornier@eurosmart.com
|
