scenarios. They include the use of formal security protocol and software verification by
languages and tools (examples in [12-14]), error coverage testing, and miscellaneous specific
tools, as chosen by suppliers and/or by safety certification authorities . These functional
requirements can both drive systems specification environments and security standards across
multiple domains.
3) At the connected device level, many minimal security verification requirements, although
included in product specifications or usage procedures, are not included in compliance tests,
standards, and national or European certification procedures. Often only safety requirements
are addressed (e.g. voltage, EMI) in these last types of documents, but security and
cybersecurity are not. Exceptional procedures exist however e.g. for emissions security if the
device is to be certified as TEMPEST. This puts critical services at stake, as these devices often
constitute the “weakest nodes.” Therefore, standards and certification procedures for
connected electronic devices must be upgraded to mandate explicit levels of security testing
at product / service level and not just in terms of generic common criteria (see also Proposal
4.). Many standards-based interface systems such as SCADA, IEEE 802.xx etc.., are primarily
concerned with interoperability and operational performance, and often deal with security as
a lateral or secondary issue. Standards and regulations must include security in the design
phases in the same way that application developments are starting to do. As to certification,
the European Union (EU) must mandate security to be part of all product compliance plans
and promote test suites.
4) The European Union Commission and European Union Agency for Network and Information
Security (ENISA) should, by policy and requirements, uphold and drive the requirements for
resilience and information security certification, common standards, and specification
environments , all also at the design level (see [9,15]). For standards, they could collaborate
with the European Standards Organizations (ETSI, CEN, CENELEC) and other bodies, such as
OMG, cloud standards, software radio standards, etc... While longer term, and because of
interoperability & interconnectivity, a comprehensive approach should be mandated, a risk-
based approach in key sectors would be the starting point irrespective of whether they are
regulated or not.
5) The minimum levels for resilience (e.g. for control systems [16]) and information security (e.g.
ISO 27001) should be set by application field or service domain whenever the EU already
applies common European certification rules and procedures.
6) In addition to engineering end-to-end complete resilience and security, when critical services
reach individual citizens, then “privacy by design” must be engineered alongside “security by
design” [17-18]. This means that privacy-enhancing mechanisms must be deeply rooted at
design level inside the same architectures. Consent to collection and storage of private
information by end users must not come at odds with overall resilience and security, such that
when security and resilience tools for critical infrastructures require private data, they must
always be aggregated or anonymized, like envisaged by the European General Protection
Regulation [19].
Electronic copy available at: https://ssrn.com/abstract=3599193