In the European Parliament inquiry into massive surveillance, the questions was raised what the technological and organisational feasibility is of developing a European security base line & standard, and then of enforcing its adoption and implementation within Europe with all key Internet stakeholders. What would be the advantages and disadvantages of proceeding that way? What are the on-going initiatives and how do they compare with each other? This blog explores these questions.
What are security baselines?
A security baseline defines a set of basic security objectives, which are pragmatic and complete, but do not impose any technical (or other) means. The details on fulfilment of these objectives are determined by the owner of a specific (IT) environment and depend on the characteristics of that environment. Derogations usually are possible and expected (but preferably explicitly). Baselines do not cover strategy or public regulations, but offer guidance for tactical and operational measures in terms of people, process and technology.
Security baselines are well known instruments for designing security in single organizations and industries (including the public sector). The objectives of baselines consist of topics (indicators, the ‘what’), norms (standards, the level) and metrics (the how much and how do we know/measure). Usually such baselines build on market standards such as ISO2700x, which is considered best practice. ENISA has drafted a shortlist of such information security standards in 2012. In the last two years this list has grown significantly across Europe, with many translations of ISO2700x to national or industry standards.
Security baselines are considered a policy option for security in Europe
Given the fact that networks and systems are interconnected and influence each other, fragmented approaches in security hinder the creation of trust among peers, which is a prerequisite for cooperation and information sharing. According to the draft NIS Directive, there “currently is no effective mechanism at EU level for effective cooperation and collaboration. (…) this may result in uncoordinated regulatory interventions, incoherent strategies and divergent standards. Internal Market barriers may also rise, by increased compliance costs for cross-border operating businesses”.
Earlier EU studies covered the subject of security baselines before, as an option to improve e-government and e-health services for instance: “The development of such a baseline starts by outlining a security strategy on a political level that presents a roadmap of security measures for Europe. Implementing a security check list could be the short-term measure to start improving the level of security of eGovernment services. In the mid-term perspective it would be relevant to start looking at policy options that can achieve Security by Design of crucial components. In the long-term, policy measures that push for highly secure entire IT-systems become relevant”
This idea takes the idea of security baselines much further: from a true baseline with objectives to secure components to secure IT systems. The focus shifts from standardization to certification, much more detailed, much more compulsory.
This paragraph here is restricted to the initial step, the checklist/standards as comfort building measure within organizations, between organizations in an industry or supply chain (or in an e-government context) or between Member States.
A good example of such a baseline as comfort building measure in a supply chain is the PCI-DSS standard, which defines security objectives for different actors in the chain of card payments (Point of Sale (device), merchant, services provider, acquirer). This helps establish secure transactions even if multiple different businesses are involved.
The draft NIS Directive is less far reaching in its ambitions. Article 14(1) prescribes a risk based approach for selecting appropriate measures, but the draft Directive does not refer to a specific set of measures or a specific standard. Using standards is encouraged, but the choice is left open:
1. To ensure convergent implementation of Article 14(1), Member States shall encourage the use of standards and/or specifications relevant to networks and information security.
2. The Commission shall draw up, by means of implementing acts a list of the standards referred to in paragraph 1. The list shall be published in the Official Journal of the European Union.”
The question here is, if a big step forward, namely harmonization of security baselines across the EU, would provide more safeguards for privacy and security against unlawful massive surveillance.
EU security baselines do not necessarily offer protection against massive surveillance
As mentioned, a common European security baseline aims to raise the general level of security in Europe, several slightly more specific aims have been attached to the concept. Not all necessarily and specifically including mitigating massive surveillance risks though. If this is the case depends on the scope and objectives in the baseline.
The main benefits of security baselines would be at least improved co-operation across borders through a common understanding and language, better protection of (then formerly) ‘weakest links’ and easier (more uniform) audit or other form of supervision.  By raising the overall level of protection, EU Member States and their citizens should become less attractive for attackers than lesser protected countries. This is because the costs will rise of surveillance, cybercrime or other attacks. However, to really offer more security & privacy against massive surveillance targeting the EU, specific objectives will have to be set and the accompanying controls rigorously implemented. Incorporating those specific objectives probably meet political discussion.
Market standards offer a good starting point for a generic EU security baseline
An earlier ENISA study pointed out that EU-wide security good practice (or baseline) should be based on ISO 27001/27002 standards. And if business continuity requirements are included, those could be based on BS 25999. The idea of different sets of requirements for different kinds of businesses can be adopted from PCI-DSS, although some of the implementation enforcing mechanisms in the card payment industry are not available or not as strong in other sectors. Regulation is probably needed where the market system will not lead to spontaneous adoption of baselines.
For generic baselines the content will not be the main hurdle for implementation, also because according to the mentioned study, ISO2700x is used extensively across Europe. Out of scope for this study however was a detailed comparison of all national and industry standards/baselines. This report cannot conclude on the barriers deriving from differences between nations and/or industries.
The scope is a mainly political challenge
Scoping is one of the first issues to tackle with baselines: what/who do the EU security baselines cover? Critical Information Infrastructure, including the Internet and other telecom backbone? E-government systems? Financial Services? All services providers for EU citizens? The broader the scope, the more stakeholders will be involved, the more complex decision making will be. This scope would ideally match that of the NIS Directive, which was when writing this report still under debate. The draft version holds a fairly broad scope in Annex II however. Discussion is on-going at the moment of writing. The current regulatory framework only covers telecommunication companies.
In the end this is not a technical discussion, but a political one. For certain some sectors / facilities should be included, to help mitigate the risks of massive surveillance. For instance (mobile) telecommunications and Internet backbone facilities, but also ICT hardware and software, social media and (other) Cloud services. These are the services used extensively for producing, sharing, processing and storing massive amounts of personal data.
The digital world is dynamic, so should implementations of baselines
With the fast pacing developments in both technology and attack mechanisms, security can only be successful as an on-going process, with continuous iterations to adopt to new circumstances. Any framework, standard or baseline should be able to be high-level enough to leave room for swift operational adjustments. This is the current practice with the standards mentioned earlier, describing objectives. Organizations implementing the standard as their baseline put in the details and can adjust these according to a scheme that fits their needs (or possibilities). That scheme can range from years to months. The standards themselves are also periodically evaluated and adjusted to new times. ISO2700x for instance was revised between 2005 and 2013.
Following this train of thought, a EU baseline needs to be concrete and high level enough to leave room to move for organizations and adjust to new threats. And also the EU baseline needs to be periodically evaluated.
Compliance to baselines requires an accepted level of monitoring
A measure installed to achieve trust, can only be trusted if it can be seen and checked. Earlier studies (ENISA 2012, STOA 2013) therefore recommend that there should be some form of supervision and oversight of implementation at EU and Member State level. Performance metrics (for a common KPI dashboard) should be mandatory in Europe to benchmark. Different institutional set-ups of such supervision are possible and need to be evaluated. These set-ups are out-of-scope for this study, but we embrace the idea of oversight and supervision. It is advisable to combine this role with participating in evaluation of the baseline itself, as the supervising authority or authorities will have a good overview of the workings of the baseline.
Beyond baselines: certification for ICT hardware
In general security baselines do not prescribe detailed security requirements for hardware and software. This would require a different instrument, which will be much more costly to implement and maintain. Certification of hardware and software is such an instrument. In theory, the use of certified product evaluations or certified development processes could be made mandatory, but it will be very hard to enforce if components are produced outside the EU.
This latter statement is especially true for software. It can be ordered on the web, downloaded and installed with ease. Modern coding, programming and assembling tools can make millions software producers, large and very small, publishing millions of lines of code on a daily basis. It is difficult to envision a situation where every (major) software in use within the EU is certified.
For ICT hardware this is substantially different. It is much harder to design, produce and distribute hardware on a large scale. Import and export of hardware is also a physical process, with more opportunities for supervision and enforcement of regulations. We see a parallel with the automotive industry, where all new car models are examined and approved before entering EU roads. In this process of homologation approval of a (certified?) authority or institute in one EU country leads to approval for all EU countries. This experience can be reused and adopted to the context of cybersecurity. Lastly, in order to ensure a level playing field and maximum security certification should be implemented for both EU and non-EU produced ICT-hardware.
Want to comment on this post? Please do!
This blogpost is based on early results of a study into mitigating the security and privacy risks of massive surveillance for European citizens. This study is being executed by order of the European Parliament (STOA / LIBE committee). Comments can be used as input for this study. Leaving a comment is considered to be a conscent for use of your comment as potential input. Many thanks!