Hr betrouwbaarheidsniveaus en_web

  • 44 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
44
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. A guide for government organisationsAssurance levels forauthentication for electronicgovernment services The Standardisation Forum
  • 2. Management summary Background and objective subsequently submit the outcome to the government With the intention of achieving cost reductions, organisation (e.g. electronic declaration of taxes for improved provision of services and in general a more private individuals). The guide is essentially aimed at efficiently operating government, the government is the classification of the security/reliability level now investing in large-scale comprehensive (‘assurance level’) for a certain service. If a govern- electronic government services (e-government ment organisation offers multiple services with services) for citizens and businesses. This implies varying assurance levels, it may consult this guide as (effective) authentication measures. One wants to be an aid in determining whether or not a single level of sure of who it is that they are doing business with. assurance can be implemented for all these different In The Netherlands there is currently still an open services, and if so, which level would be most standard in effect with respect to the necessary appropriate. It does not, however, include the assurance level for identification and authentication mapping of the assurance levels to specific authenti- of persons and parties using such e-government cation tools. These will – in part due to their dynamic services. This open standard is established in the nature – be addressed in a separate document. Dutch General Administrative Law Act (Awb) and within the rules concerning information security. Initial principles & assumptions An ‘open norm’ implies that the relevant requirements The processes behind e-government services in have not been concretely defined. The on-going surge The Netherlands are typically similar in nature and of e-services has consequently also increased the need structure. They generally follow a standard decision- to further supplement this open standard, since it is making process, according to the rules of the General important that government organisations in similar Administrative Law Act, possibly supplemented with situations require (and implement) the same levels of requirements of domain legislation. Their relative reliability and security. This guidebook provides this uniformity means that families of related services are extra supplementary information, and thereby wants definable and allows for the implementation of a to contribute to the transparency, accessibility and system for generically assessing and consolidating credibility of the government and the legal security of risks. The assumption implied in this approach isStandardisation Board and Forum citizens and businesses. that the associated services are provided from withinThe Standardisation Board and Forum were established to promote digital This guide offers a foundation for dialogue between similar online environments and have similarcooperation (interoperability) between the government, businesses and citizens. policy-makers, (process) architects and information vulnerabilities. The system used does however takeInteroperability ensures improved compatibility between different systems and security personnel for the implementation of into account the fact that offline measures can alsofacilitates information sharing. Use of open standards plays an important role in e-services and back office processes. This booklet will be taken in order to ensure the confidentiality of datathis process. additionally offer managers insight into the rationale and to reduce the risk of a stolen or forged identity. behind the determination of assurance levels, so that The guide is based on the nationally valid (legal) rulesThe Standardisation Forum makes recommendations to the Standardisation they may make a well-informed decision. and is consistent with the European STORK frame-Board based on research. Based on the advice of the Forum, the Board in turn work1 for the cross-border use of e-services.makes recommendations to various ministers concerning policies in the areas of Scopeinteroperability and open standards. The Standardisation Forum and Board were This guide is aimed at governmental e-services Methodologyestablished at the initiative of the Ministry of Economic Affairs. Their secretariat offered to citizens and businesses that use these Based on these initial principles, a frameworkis part of Logius, the digital government service of the Ministry of Home Affairs through the internet; this primarily concerns (‘menu’) has been developed for the classificationand Kingdom Relations. services made available through an online portal of services in various assurance levels. (e.g. Omgevingsloket online) or services for which This framework can essentially be seen as a simpleFor more information go to www.forumstandaardisatie.nl. users perform actions in a local application and risk analysis. The method used assumes an estimate 1 Secure idenTity acrOss boRders linKed The Standardisation Forum | Assurance levels for authentication for electronic government services  3
  • 3. Table of Contentsof the value at stake, according to a number of Management summary .................................................................................... 3objective (or objectifiable) criteria and interests.Examples of this are legal requirements, the nature Contents............................................................................................................ 5of the data exchanged (e.g. is personal informationinvolved) and the economic or social interest 1 Introduction ............................................................................................. 7associated with a certain service or process. An 1.1 Uniform assurance levels as a prerequisite for e-government ........................ 7estimate can subsequently be made of the potential 1.2 Guide offers sense of security ...................................................................... 7damage if the service is not used in an appropriate 1.3 Realisation and management of the guide .................................................. 9and legal manner. 1.4 Reading guide ..........................................................................................10By coupling these interests on the one hand to the 1.5 More information ....................................................................................10assurance levels designated by STORK, and on theother hand to the features of services (and service 2 Scope of the guide ..................................................................................12families), a generic classification of services can beachieved with respect to the required assurance level. 3 Initial principles & assumptions .............................................................15 3.1 Risk assessment in broad terms ................................................................ 15Status 3.2 Clustering of services ................................................................................16The choice for an assurance level for a certain 3.3 STORK levels as a basis .............................................................................. 17e-service, and therefore also the application(adoption) of this guide, is and will remain the sole 4 Mapping of services to assurance levels ..................................................21responsibility of the government organisation. 4.1 Criteria ..................................................................................................... 21This guide serves as a tool for government organi­ 4.1.1 The menu .................................................................................................25sations to – based on general legal frameworks – 4.2 Reference scenario ...................................................................................27effectuate this responsibility in a proper and concise 4.3 Correction factors ....................................................................................27manner. It would be wise for implementing 4.4 Examples of services and corresponding assurance levels ............................29organisations to adopt and anchor this guide withintheir implementation policy, and that whendetermining an assurance level for a particularservice they also explicitly indicate the manner inwhich this occurred.This guide is not a static document. The continueddevelopment of e-services and of identification andauthentication tools (e.g. credentials and tokens),in combination with experiences by governmentorganisations with implementing the guide, willreveal the need for any revisions and additions.Logius and the Standardisation Forum will continueto support the guide’s management and furtherdevelopment.4  The Standardisation Forum | Assurance levels for authentication for electronic government services The Standardisation Forum | Assurance levels for authentication for electronic government services  5
  • 4. 1 Introduction 1.1 Uniform assurance levels as a prerequisite for e-government With the intention of achieving cost reductions, improved provision of services and in general a more efficiently operating government, the government is now investing in large-scale electronic government services (e-government services) for citizens and businesses. The Dutch General Administrative Law Act (Awb) requires that electronic traffic between citizens and authoritative bodies takes place in a “sufficiently reliable and confidential” manner. In addition, the Besluit voorschrift informatiebeveiliging rijksdienst (governmental information policy guidelines) also state that the relevant line management team must determine the assurance requirements according to a risk assessment, and subsequently to ensure that appropriate measures are taken. This involves open standards. An essential prerequisite in this is the availability of adequate resources for identification, authentication and authorisation. This will give the government certainty that they are dealing with the right person. Citizens and businesses can in turn be assured that their (confidential) information is submitted in a reliable way directly to the government or that they can be retrieved there. The on-going surge of e-services has consequently also increased the need to further supplement this open standard, since it is important that government organisations in similar situations require (and implement) the same levels of assurance for their e-services. This contributes to the transparency, accessibility and credibility of the government. Furthermore, in the vein of due diligence, it is important that the rationale behind the determination of an assurance level is clear and transparent. This will be in the benefit of the legal security of citizens and businesses. This guide provides this certainty and is based on the nationally valid (legal) rules and is consistent with the European STORK framework2 for the cross-border use of e-services. 1.2 Guide offers sense of security A prerequisite for reliable and confidential e-services is the availability of adequate resources for identification, authentication and authorisation. This will give the government assurance that they are dealing with the right person, and citizens and businesses will in turn also be assured that their (confidential) information is submitted in a reliable way directly to the government or that they can be retrieved there. A uniform solution for this identification, authentication and authorisation does not exist within the great diversity of electronic government services however. A solution with a very high assurance level will in most cases be too expensive, and a solution with a low assurance level may present significant liabilities with respect to fraud and privacy. In order to avoid a proverbial ‘digital keychain nightmare’ 2 Secure identities across borders linked. See document D2.3 - Quality authenticator scheme, paragraph 2.3 and 2.4, available at www.eid-stork.eu, under ‘STORK Materials > Deliverables - Approved/Public’. The Standardisation Forum | Assurance levels for authentication for electronic government services  7
  • 5. for users and for the sake of managing costs, the government is currently will be necessary to conduct a comprehensive risk analysis in order to determine working towards as-generic-as-possible implementable solutions. Examples the assurance level. of this are DigiD (e-signature), PKIoverheid and the eHerkenning (eRecognition) appointments registration system. It is advisable that the service provider makes the classification of their services available in a scheme (policy rules or general binding guidelines, depending on The basic question remains, however, of which tool ought to be used in the context).3 An explanatory note will substantiate the classification so that different situations. This has proved difficult to determine in practice for this is also clear to the users of the service. implementers of public services. This guide has been compiled based on this background. It is intended to contribute to a concise, efficient and responsible determination of the assurance level of electronic government services. 1.3 Realisation and management of the guide This booklet was compiled in collaboration between various government The guide includes a ‘menu’ which contains a generic association of (types of ) organisations4 , facilitated by the Standardisation Forum Bureau and the services and assurance levels based on (legal) criteria. Indications are also eHerkenning (eRecognition) program. included which may lead to classification in a higher or lower assurance level. This guide was presented to the Standardisation Board and Forum with the The guide does not include an association (mapping) of the assurance levels question of whether or not it is sufficiently comprehensive to make a to specific authentication tools (e.g. credentials). substantiated assessment with respect to the scope of application for standards relating to identification and authentication. This was a result of the initial stimulus to begin compiling the guide: namely, the discussion Electronic services Assurance levels Credentials within the Standardisation Forum about placing the requirements for PKI-Overheid on the ‘Comply or Explain’ list of the Standardisation Board5. The Standardisation Forum had previously decided that making a decision Electronic services Credentials High assurance about this matter would not be possible as long as there was insufficient Depending on the nature of (and associated facilities) clarity about the scope of application of PKI-Overheid (that is, about the the service, arrangement of for identification, the process and the risks of Moderate assurance authentication and services which require the assurance level that PKI-Overheid offers). abuse, a particular service authorisation will require a certain level of assurance Limited assurance The draft of the guide was discussed in September 2011 in the Standardisation Forum. The Forum approved the guidebook and deemed it Minimum assurance suitable for the determination of the scope of application of PKI-overheid.6 This decision will be taken into account for further assessment of and decisions about placement of the programme of requirements of PKI- Classification Overheid on the Standardisation Board’s ‘Comply or Explain’ list. The Figure 1: Scope of application of the guide Standardisation Board approved the guide in the autumn of 2011.7 3 Using this menu, architects, information security personnel, lawyers and  Examples of such schemes are the Besluit vaststelling niveau DigiD for Mijnoverheid.nl (Stcrt. 2008, 32) and the Regeling aanwijzing betrouwbaarheidsniveau elektronisch verkeer met de authorities can make a qualified choice for the appropriate assurance level for bestuursrechter (Stcrt. 2010, 15000) (although this of course does not yet include a their services. They are free in this to decide whether or not to apply the substantiation of the decision within the vein of this guidebook). 4 information in this guide. It is important to realise that this is based on a Tax Bureau, CoC, AgentschapNL, IND, Dienst Regelingen, Nictiz, Amsterdam municipality, Ministries of Domestic Affairs, Economic Affairs and of Infrastructure and the Environmment. generic approach. The guide will therefore provide an adequate assurance level 5 See: http://www.forumstandaardisatie.nl/open-standaarden/over-open-standaarden/ determination for the majority of cases, but exceptions are possible. If in a het-pas-toe-of-leg-uit-principe/ 6 certain situation a choice cannot be made using the menu, e.g. because the See: http://www.forumstandaardisatie.nl/fileadmin/os/Vergaderstukken/ FS33-09-11_Verslag_21_september_definitief.pdf nature of the service or the relevant circumstances are considerably different, it 7 See: http://www.forumstandaardisatie.nl/organisatie/college-standardisation/ vergaderstukken-van-het-college/2011/.8  The Standardisation Forum | Assurance levels for authentication for electronic government services The Standardisation Forum | Assurance levels for authentication for electronic government services  9
  • 6. Following this approval the guide was widely distributed amongst govern- ment organisations, accompanied by a recommendation regarding how they may incorporate it into their implementation policies relating to e-services. This guide is not a static document. The continued development of e-services and of identification and authentication tools, in combination with experiences by government organisations with implementing the guide, will reveal the need for revisions and additions. Logius and the Standardisation Forum will continue to support the guide’s management and further development. This is in line with Logius’ management responsibility for various identification and authentication tools and standards, such as DigiD (e-signature) and PKIoverheid, and as of 2012 also eHerkenning (eRecognition). The parties which have been involved in the development of this guide constitute the foundation for a community of users which Logius wants to bring together for the maintenance and further development of this guide­book. In addition, a meeting will be organised twice a year especially for the users, in which a new adjusted version of the guide will be discussed and established, based on the contributions of the meeting. 1.4 Reading guide Chapter 2 addresses the scope of this reference guide. Chapter 3 contains the initial principles and assumptions which apply to the formulation of the ‘menu’. Chapter 4 elaborates further on the method used and includes the actual menu card for classification of services based on the required assurance level. Annex 1 explains the legal framework in which different criteria for the classification of services according to the required assurance level are substantiated. Annex 2 contains several illustrations of the manner in which legal requirements and formulations translate/relate to actual electronic dimension. Annex 3 includes a list of common terminology. 1.5 More information The guide is digitally available at the websites of Logius and The Standardisation Forum (www.logius.nl, www.forumstandaardisatie.nl) and from the eHerkenning (‘eRecognition’) program (www.eherkenning.nl). Questions regarding the relevance and application of this guide may be directed to: Forumstandaardisatie@logius.nl.10  The Standardisation Forum | Assurance levels for authentication for electronic government services The Standardisation Forum | Assurance levels for authentication for electronic government services  11
  • 7. 2 Scope of the guide The guide addresses services and processes which the government provides to relevant information. Confidentiality must similarly be safeguarded in such a to or implements for the benefit of citizens and businesses. This concerns case. The same applies to exchanging of data between government organisati- the domain which is essentially regulated by section 2.3 of the General ons amongst each other (e.g. to consult basic (e.g. municipal) registration Administrative Law Act (Awb)8. In general, the following situations are records, or the exchange of information required for the assessment of an distinguished: application for a permit). 1 Services whereby an individual uses the service on his/her own behalf via internet and also completes the necessary steps him/herself (e.g. visit This domain is (in any case for the ministries and their direct subordinate website, send e-mail, etc.). This definition includes both citizens and departments) covered by the Besluit voorschrift informatiebeveiliging rijksdienst (VIR, independent entrepreneurs who are legally registered as a sole-proprietor- government information security regulations). Decentralised governments ship business. typically already voluntarily employ a similar methodology, whereby they 2 Services which are used by an individual who completes the required operate in the vein of the VIR. Besides this, they are – like the various steps him/herself, but does so on behalf of another natural person or governmental departments – bound to the information security regulations legal entity. pursuant to the Wet gemeentelijke basisadministratie persoonsgegevens (Wet GBA, 3 Services whereby systems communicate with each other without direct Municipal Personal Records Act) and (the content of ) article 13 of the Wbp human involvement (machine-to-machine traffic). (Dutch Data Protection Act). The administrative organi­sation and internal control (AO/IC) and the government organisation’s security policy must, This guide only addresses situation 1. For the time being the scope does not based on all these rules, fulfil the required assurances for the reliability and refer to third-party authorisations/permissions; it only addresses services for confidentiality of the data streams. private individuals themselves or for independent entrepreneurs. This is by no means because the issue of third-party authorisation/permission is not relevant, but rather because the domain of authorisation still remains in a services, processes and associated departments, state of continuous development. Effective methodologies for incorporation systems etc. under the responsibility of of this aspect are therefore not yet available. The same applies to processes traffic between citizens government organisation A involving solely machine-to-machine communication with the government. and government body Based in part on experiences with the use of this guide, further advancement in addressing situations 2 and 3 above will become possible. This guide is also aimed at the determination of the required assurance level for services, processes and associated departments, systems etc. under the responsibility of a particular service. A service provider may offer multiple services requiring government organisation B traffic between burgers different assurance levels – this guide does not specifically state which measures and government body to take in such situations but instead outlines risk-increasing and -reducing aspects relating to service provision. It thereby offers valuable reference points in order to restrict – within limits – the number of assurance levels. Not included in the scope of this guide is the issue of ‘return flow’ from the General Administrative Law Act VIR (civil service bureau) or other frameworks relating to information security government (the response to an application or notification), even though (with other government organisations) identification, authentication and authorisation naturally also play a role in this. It is important that it is understood that the organisation/employee Figure 2: Relationship between Awb (General Administrative Law Act) and regulations relating to ‘behind the counter’ is authorised to take certain decisions and may have access information security 8 Articles 2:13-2:17, included in the Wet elektronisch bestuurlijk verkeer (Act on Electronic Government Communications), (Stb. 2004, 214).12  The Standardisation Forum | Assurance levels for authentication for electronic government services The Standardisation Forum | Assurance levels for authentication for electronic government services  13
  • 8. 3 Initial principles & assumptions In this chapter the initial principles and assumptions are described which were adopted for the compilation of this guide. These concern: • Opting for a simplified and intuitive risk analysis. • Defining families of services. • Adoption of the STORK framework as a foundation for interoperability. The outcome of the approach chosen based on these assumptions is a methodology which gives a general estimation of the risks and which is implementable with relatively little effort. This allows government organisations to determine a required assurance level in a straightforward manner, unless a detailed risk analysis is warranted or mandatory based on rules for information security. 3.1 Risk assessment in broad terms In a number of countries the classification of assurance levels is based on risk analyses.9 The US has also adopted this approach. The Office of Management and Budget established the E-Authentication Guidance for Federal Agencies in 2006.10 This guideline states that each body of the federal government must determine the appropriate assurance level for each separate process or service, based on an estimation of the risks in relation to a great number of variables. It is expected that in time, based on the documented risk analyses, certain fixed rules will become distinguishable. This detailed risk analysis for determining assurance levels is inspired by the liability aspects which play a dominant role in Anglo-Saxon culture. In The Netherlands such an approach would be ineffectual. It is costly, time-consu- ming and can still lead to fragmentation and unjustified inconsistencies, while processes and services typically show many common (mutual) features (e.g. through the application of the General Administrative Law Act on decision-making processes). That is the reason why a methodology was sought to generically estimate and consolidate risks. This system assumes an estimate of the value at stake, according to a number of objective (or objectifiable) criteria and interests. Examples of this are legal requirements, the nature of the data exchanged (e.g. is personal information involved?) and the economic or social interest 9 See Spain, for example: MAGERIT, Methodology for Information System Risk Analysis and Management 10 Ministerio de Administraciones Públicas, June 2006, http://www.epractice.eu/ document/3215. http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf.14  The Standardisation Forum | Assurance levels for authentication for electronic government services The Standardisation Forum | Assurance levels for authentication for electronic government services  15
  • 9. associated with a certain service or process. A prediction can subsequently 3.3 STORK levels as a foundation be made of the potential damage. The STORK framework11, co-developed by the EU, constitutes the backbone of the system of assurance levels to which on the one hand (families of ) The assumption implied with this method is that the associated services are government services can be mapped, and on the other hand the available provided from within similar online environments and have similar authentication tools (e.g. credentials). STORK was initiated with an eye vulnerabilities. The system used does however take into account the fact towards improving the interoperability of electronic identification and that offline measures can also be taken in order to ensure the confidentia- authentication in Europe; so also with regard to cross-border services. lity of data and to reduce the risk of a stolen or forged identity. These In order to answer the question of which tool to employ to facilitate the use measures may include reporting back through another avenue, e.g. a letter of a certain service from one country in another country, it is essential to be to the residential address recorded in municipal personal records. able to compare the relevant identification and authentication tools. This has led to a common framework of Quality Authentication Assurance Levels12. 3.2 Clustering of services As mentioned earlier, the processes behind e-government services are often The first step employed in the STORK framework for establishing the of a similar nature and structure. They generally follow a standard decision- assurance level of an authentication tool (credentials) is the assessment of making process, according to the rules of the General Administrative Law Act, the following independent aspects: possibly supplemented with requirements of domain legislation. Their • The quality of the identification of the person for registration during the relative uniformity means that families of related services are definable, even application process for the credentials. if they differ with respect to the information required for the execution of the • The quality of the procedure with which the credentials are issued to the user. service (both of the customer and from other government organisations) and • The quality of the organisation issuing the credentials and facilitating the the (technical) structure of the service ((online portal, application). associated registration process. • The technical type and robustness of the credentials. We distinguish between the following families: • The security features of the authentication mechanism used to recognise • Requesting general information the credentials every time it is used remotely (via internet). • Signing up for/responding to discussion forums • Applying for newsletters etc. The first 3 aspects serve primarily as procedural safeguards which apply to • Requesting physical government services the registration process. The last two are more technical aspects of the (waste container, collection of bulky refuse) manner in which the credentials are used. • Registration for a personalised webpage • Submitting complaints The eventual assurance level is then determined through a combination of • Submitting applications (for a government service) these aspects. The STORK framework assumes 4 levels. The individual aspect • Requesting/viewing personal information (partially pre-completed form) with the lowest score will ultimately determine the applicable assurance • Providing/adjusting information level, on the principle that ‘the chain is only as strong as the weakest link’. • Accountability This is illustrated in the figure on the next page. • Filing objections This uniformity of services at a higher abstraction level makes it possible to make general conclusions about the required degree of reliability. This will be determined by the general and specific characteristics of the particular service. General characteristics include the nature of the data (personal details demand greater certainty than non-personal data). Specific characte- 11 See www.eid-stork.eu. ristics constitute legal requirements associated with the service (e.g. a (e) 12 The term “reliability level” may also be encountered in relevant literature – this term is signature requirement). This has been an important assumption for the used interchangeably with “assurance level”. classification of services and assurance levels in this guide.16  The Standardisation Forum | Assurance levels for authentication for electronic government services The Standardisation Forum | Assurance levels for authentication for electronic government services  17
  • 10. Quality of the The quality of the Quality The technical type The security STORK QAA level 3 identification of procedure with requirements for the and robustness of features of the natural person for which the organisation issuing the credentials authentication This level requires stricter methods for verifying the attested identity of the registration during credentials are the credentials and mechanism the application issued to the user facilitating the user. These methods must offer a high level of certainty in identifying the process for the registration process claimant. Identity providers are supervised or accredited by the government. identity credentials A 2-factor authentication is required; this would relate to soft certificates or one-time password tokens. RDW, for example, requires this level of authenti- assurance level is equal to the lowest score on the 5 aspects; a high score cation from businesses in the automotive industry which is authorised in that on 1 aspect is pointless if there is a weaker link (lower score) elsewhere. capacity to view certain RDW data. Online banking applications for which customers need a token also employ this level of authentication. STORK QAA level 4 registration, withdrawal etc. use This level requires at least the one-time (for initial registration) physical presence of the user for the registration process and compliance with all Figure 3: Determination of the assurance level according to STORK requirements of national law of the relevant country during issuance of qualified certificates as intended in Annex II of the e-signature Directive 1999/93/EC. For The Netherlands this concerns the requirements of article 1.1, The 4 levels defined by STORK are: part ss, of the Telecommunications Law. The identity credentials provider must furthermore fulfil Annex I of the same directive. In The Netherlands this STORK QAA level 1 article is addressed in article 18:16, section 1, of the Telecommunications Law. This is the lowest assurance level; it either assures a minimal confidence in If government parties or for example notaries want to submit documents the asserted identity of the user or no confidence at all. Identity credentials digitally to the national register, this will be possible through a special are accepted without any form of verification. An example of this is a application: Web-Elan. This system requires the use of a token, a water-mar- procedure in which the applicant receives an e-mail from the issuing agency ked certificate and a digital signature. Users must ensure these themselves. with a hyperlink which must be clicked to be able to use the credentials. This only certainty is that a similar email address exists at the time of application By coupling (mapping) the interests and criteria on the one hand to STORK and that an outside party would theoretically be able to respond to e-mail assurance levels and on the other hand to the features of services (or service messages sent to that address. An example of this is downloading of a tender families), a generic classification of services can be achieved with respect to document from Aanbestedingskalender.nl. the required assurance level. Following from this – without compromising the inherent complexity of the subject matter – a simple and intuitive system STORK QAA level 2 for identification and authentication must be in the user’s interest. This At this level, verification of the identity claimed by the user during the implies as little differentiation as possible, in any case with respect to the registration process for obtaining the authentication credentials takes place reliability requirements set by the government. This is also a contributing by means of a check based on an official document issued by the State (e.g. factor for adopting the 4 STORK levels. a copy of the user’s passport or driver’s licence) or registration. Claimants are not required to appear physically during registration. Credentials with a single-factor authentication will suffice. ‘Factor’ is understood to mean an identity token for a claimed identity, e.g. a username and password combination or a unique code submitted by a trusted party (according to a governmental agreement). Logging in with DigiD, for example for declaring one’s taxes digitally, employs this method.18  The Standardisation Forum | Assurance levels for authentication for electronic government services The Standardisation Forum | Assurance levels for authentication for electronic government services  19
  • 11. 4 Mapping of services to assurance levels Based on the initial principles and assumptions of Chapter 2, a framework has been formulated for the coupling (mapping) of services to the different assurance levels. This framework essentially serves as a simple risk analysis. The method used for this is related to the usual elements of risk analysis. The required assurance level for a certain service can be estimated based on a number of criteria. These criteria all concern the importance of the data and the potential damages if these were to be obtained or modified by unauthorised third-parties. The proposed method does not quantify the threat or the chance that a threat will manifest itself. Instead, assumptions are formulated with respect to the quality of the IT security features and other relevant features of the background processes through which the particular service is provided. These assumptions are incorporated into a so-called reference scenario. Based on the criteria and this reference scenario, an assurance level can subsequently be assigned by consulting a simple table (the ‘menu’, see page 24). The system also applies a number of correction factors. These factors reduce or heighten the threat in relation to the reference scenario. Especially in the latter case, such a simple risk analysis will not suffice and will warrant a comprehensive risk analysis. 4.1 Criteria The following criteria relate to the mapping of assurance levels: 1 Legal consequences If a particular service is based on legislation, this will lead to legal actions by the government organisation (e.g. taking a decision subject to appeal) and will as such be aimed at liability. For cases involving actual performance (e.g. provision of information) the service will not imply liability (legal consequences). It may sometimes be the case that a certain service initially purely involves actual performance, but that it may ultimately still lead to legal consequences later. An example of this is the provision and registra- tion of municipal waste containers according to name and address, whereby these details can also serve as a basis for implementation (e.g. for the correct scheduling of waste collection). This is important for the grading of the assurance level. Applicable values: • No legal consequences/liability • Legal consequences/liability20  The Standardisation Forum | Assurance levels for authentication for electronic government services The Standardisation Forum | Assurance levels for authentication for electronic government services  21
  • 12. 2 Formal legal requirements Category Nature of the information Many services require a signature, either based on the General No personal information The information cannot be traced back to an identified or Administrative Law Act (Awb) or based on specific legal rules. This may identifiable person. involve signing for the sake of authentication, or to confirm a certain action. In specific cases an advanced or qualified electronic signature may Risk category 0 Public information. even be explicitly required, depending on the level of validation required. Publicly available personal information which has been generally acknowledged to not form a risk for the involved individual. Examples of this are telephone books, brochures and public Applicable values: internet websites. • Only general requirements relating to reliability and confidentiality are set • Signature by or on behalf of the claimant is required Risk category I Basic information. Limited number of personal details relating to a single type of • Signature is required; other formal requirements also apply to the signature validation, e.g. membership, employment or client relations, provided that these cannot be considered to be special personal data. 3 Provision of personal information by the individual Personal details are typically processed when using electronic services. Risk category II Increased risk. Special personal data as intended in article 16 of the General “Processing of personal data”, as intended in article 1, part b of the General Administrative Law Act (Wbp), or financial/economic information Administrative Law Act (Wbp), is understood to mean: “every action or every relating to the involved individual. sum of actions relating to personal data [...]”. This involves all data processing actions, from collection up to and including destruction. This Risk category III High risk. criterion relates to situations in which a citizen or business provides or edits Data collected from investigation authorities, DNA database, information subject to special legal confidentiality obligations, personal data themselves from within an electronic service platform. information falling under a code of professional secrecy (e.g. medical) as intended in article 9, part 4 of the General Administra- For the determination of the required assurance levels for the processing of tive Law Act (Wbp). personal data, this guide adopts a classification of risk categories compiled by the College Bescherming Persoonsgegevens (Personal data Protection Board) in the information, which is not subject to aggravating factors. As such, this document Achtergrondstudies en Verkenningen (AV) nr. 2313 (see Annex 2, section 3). information is always classified into risk category II. Risk categories for personal data are designated as follows: The table above further defines the various risk categories: Applicable values: Step 1. Make an initial prediction of the risk category based on the nature of • No personal information at all is processed the data, according to the table on the right. • risk category 0 • risk category I Step 2. Determine any aggravating factors. If the information is considerable • risk category II (i.e. a lot of information of a single person or of multiple people), this can • risk category III constitute an aggravating factor. 4 Displaying personal data, other than that provided by the user Step 3. If one or more aggravating factors exist, advance to the next risk in the same session category (one category higher). An exception to this is financial/economic With electronic services it may occur that personal data is provided or shown through a website or in a message by the service provider to a citizen or business. A higher assurance level may be required for this than for the 13 provision of the same (type of ) personal data by an individual or business Blarkom, G.W. van, Borking, drs. J.J., Beveiliging van persoonsgegevens, Registratiekamer, april 2001, Achtergrondstudies en Verkenningen 23, http://www.cbpweb.nl/Pages/av_23_Beveiliging. themselves. If an applicant independently (on his own behalf ) provides aspx. information, unauthorised validation of course cannot occur. But when22  The Standardisation Forum | Assurance levels for authentication for electronic government services The Standardisation Forum | Assurance levels for authentication for electronic government services  23
  • 13. provided by the government, e.g. by displaying data on a governmental website, 7 Economic interests this may be the case. That is why the displaying of personal data by a govern- Invalid identification may affect economic interests and lead to economic mental website (or the provision of this data in a message) will receive a higher damages. This may involve financial damages due to misuse (abuse) or fraud, sensitivity designation with respect to mapping: a higher assurance level is access by unauthorised parties to competition-sensitive information (potential required for information within the same risk category. See the table on the lost order severity) or leaking of market price-sensitive information. previous page for more explanation about the applicable risk categories. Applicable values: Applicable values: • Zero: There is no economic value – at least no economic damages – to be • No personal data in addition to the information independently provided expected in the event of invalid/incorrect identification/authentication. • risk category 0 • Limited: This concerns only limited economic interests of the individual. • risk category I Incorrect identification/authentication can lead to damages in the order of • risk category II €1,000. • risk category III • Average: This involves greater interests at the individual level or limited business interests. Potential damages are absorbable and/or rectifiable. 5 Processing of the BSN Number Involves amounts up to the order of €10,000 per case. Following on the criteria with respect to the processing/recording of personal • Significant: Economic-scale damages (significantly) more than €10,000. data, the recording of the BSN number (Citizen Service Number) is applied as a separate criterion. The BSN number is by definition a key which can simplify the 8 Public interests coordination (aggregation) of personal data within and amongst organisations. These interests essentially constitute a reflection of the risk for violation of Moreover, stringent legal requirements apply to the use of BSN numbers. collective economic interests, collective security, compromise the integrity of the legal system, etc. A distinction is made between public and social Applicable values: disruption. • BSN not recorded • The BSN number is exclusively provided by the user and potentially Applicable values: mapped (possibly in combination with for example a name for the sake of • Public – disruption of public trust in service provision certainty about the correctness of the BSN number provided). The implicit Low: Complaints, commentary in newspapers; provision of the BSN number by DigiD use is included in this Medium: Ombudsman becomes involved, official parliamentary questions, etc; • The BSN and any supplemental personal data not provided earlier in the High: Minister resigns. process are displayed • Social disruption Low: Disruptions which can be resolved with a single organisation’s resources; 6 Correctness of the provided information Medium: Disruptions demanding coordinated efforts by multiple A special category is formed by the recording of the data provided in a basic organisations, mostly public and private organisations; registry. After all, the potential consequences of inclusion of information in High: Urgent situation; disruptions requiring emergency measures not such a register can be considerable, since such information is considered accounted for in the normal legal, financial (etc.) framework ‘truthful’. A distinction is made however with respect to mutations in non-authentic data and mutations in the authentic data. 4.1.1 The menu In the ‘menu’ on the next page, the defined criteria are mapped against the Applicable values: defined assurance levels. From each of the 8 mentioned criteria, the most • There is no mutation or creation of a basic registry based on the data provided appropriate values can be designated for the corresponding service, resulting • Mutations of non-authentic data in basic registers in the appropriate assurance level. • Mutations of authentic data in basic registers • Creation of authentic data in basic registers24  The Standardisation Forum | Assurance levels for authentication for electronic government services The Standardisation Forum | Assurance levels for authentication for electronic government services  25
  • 14. Criteria Assurance level 4.2 Reference scenario The ‘menu’ is very useful for a specific process- or IT vulnerability. The - no legal consequences 0 (no authentication - general requirements set for reliability and confidentiality requirements) assumptions about this vulnerability are explicitly stated below, and - provision by involved individual (independently) of public essentially constitute the reference scenario. A number of common personal data (risk category 0) deviations/inconsistencies with respect to this scenario have been identified - no displaying of personal data by governmental service provider and serve as correction factors; that is, these factors (may) lead to an - BSN Number not recorded adjustment of the assurance level determined based on the menu card. - no mutations in basic registry - economic interest: zero - public interest: low Assumptions relating to the scope • This concerns interactive, online services for citizens and/or businesses. - no legal consequences 1 • Citizens independently (on their own behalf ) use services, employees use - general requirements set for reliability and confidentiality - provision of personal data, up to and including risk category I services on behalf of the company for which they work. - displaying of personal data, up to and including risk category 0 • Third-party authorisation/permission is secure (elsewhere). - BSN Number not recorded • The type of scheme and corresponding type of service process involved - no mutations in basic registry are clearly distinguished. - economic interest: zero - public interest: low Assumptions relating to the control of IT security and privacy - possible legal consequences 2 • The organisation has working management systems for information - legal requirements with respect to signature security and protection of personal data. - provision of personal data, up to and including risk category II • An implemented and current security plan is in place for IT for the - displaying of personal data, up to and including risk category I particular service in question. This plan is based on common standards - BSN Number is recorded, provided by user, possibly using DigiD - no mutations in basic registry and/or a specific risk analysis. - economic interest: limited • It is (made) known which personal data is processed for the specific - public interest: medium scheme/service as well as the manner in which these are processed. - legal consequences 3 - legal requirements with respect to signature or desired action Assumptions relating to the process which facilitates the service/scheme - provision of personal data, up to and including risk category III • The valid legal requirements for the service are complied with. - displaying of personal data, up to and including risk category II • The user’s identity is authenticated when providing access to the - BSN Number is recorded, whether or not provided by the user requested service. This identity is subsequently adopted in the system - mutation of non-authentic data in basic registries during for following process(es). Supplemental measures for verifying - economic interest: average - public interest: medium this identity via alternative avenues remain restricted to back-office controls; extra controls whereby the user is asked to provide additional - legal consequences 4 validations with respect to their identity are assumed to not exist. - legal requirements for signature, other formal requirements • For services involving a decision by an authoritative body, the decision - processing of personal data of risk category III will always be communicated to the concerned person. Other involved - displaying of personal data - risk category III - BSN Number is recorded, whether or not provided by the user parties may also be notified. This may take place via another avenue than - processing of data leads to mutation or creation of authentic through which the service was originally requested. data in basic registry - economic interest: great 4.3 Correction factors - public interest: high The above-mentioned assumptions (the reference scenario) and the ‘menu’ based on these assumptions will not provide a correct outcome for all situations. Both risk-reducing and risk-increasing factors exist. Risk-reducing26  The Standardisation Forum | Assurance levels for authentication for electronic government services The Standardisation Forum | Assurance levels for authentication for electronic government services  27
  • 15. factors occur especially when there are extra steps in the process. Based on Risk-increasing factors this, a substantiated argument can be made for a lower assurance level than Situations which warrant a comprehensive risk analysis: proposed by the menu. Risk-increasing factors relate mostly to the context of • Services which are inherently subject to political, managerial and image the service in question. These involve factors such as political or managerial (reputational) risks. sensitivity and/or the effect on image (reputation). These are all indicators for • The risk is difficult to determine since only a limited degree of damages (warranting) a subsequent comprehensive risk analysis. attributable directly to the incident is possible, even though significant consequential damages are possible. Such a situation is addressed in the Risk-reducing factors tables in the event of mutation of authentic data in basic registries. This The following risk-reducing factors are distinguished: calls for the highest possible assurance level, unless analyses of (conse- 1 A step is included in the subsequent process whereby the party concerned quential) damages show that a lower risk applies than implicitly assumed. must act/appear physically in such a manner that it would be obviously • Situations involving (process chain) authorisations. In such situations, the evident should another party have used the service or initiated the risk – inherent with such authorisation/permission situations - warrants a process without permission from the concerned individual. separate (risk) analysis. Such authorisation/permission situations are not 2 A step is included in the subsequent process whereby the individual must included in the scope of this guide. act/appear physically in such a manner that the party concerned (natural • The service involves a high potential for large-scale abuse. Especially the person) must report and validate themselves physically with a form of ID combination of sizeable processes limited verification possibilities and, and whereby the BSN Number is verified according to the BSN Number at a large scale, major potential profits. recorded during the process. 3 Feedback with respect to mutations or (proposed) decisions takes place 4.4 Examples of services and associated assurance levels via another avenue than the original electronic channel. By way of examples, this section refers to different services and their correspon- 4 A step is included in the subsequent process which includes information or ding assurance levels according to the criteria above. documents which independently (not related to the use of the service in question) verifies the identity and authorisation of the party concerned. 5 There is continuous and active monitoring which prevents a service from being accessed excessively within a short time period by the same indivi- dual, or for preventing other usage behaviour which may suggest fraud. 6 When the inherent economic interest is the determining factor in establishing the assurance level and when financial services are con- cerned: verification of the bank account details for the account to which payments are deposited. If a risk-reducing factor applies, then under certain conditions the reduction of the ultimate assurance level may be possible in a single step. However, in cases where legal requirements determine the assurance level (e.g. formal signature requirements), reduction will not be possible. Reduction from assurance level I down to 0 is also not possible.28  The Standardisation Forum | Assurance levels for authentication for electronic government services The Standardisation Forum | Assurance levels for authentication for electronic government services  29
  • 16. Criteria Assurance level Anonymously visiting government websites 0 (no requirements) Municipal local services (e.g. reporting deficiencies in public areas, 1 requesting waste containers) Registering for personalised portals 2 (MijnOverheid.nl, mijndenhaag.nl, etc.) Municipal permits (tree pruning/cutting permits, event permits, etc.) Environmental permit for private individuals Financial benefits eligibility for private individuals (subsidy, unemployment benefits, other allowances) Au pair residency permit (Status) information in MijnOverheid.nl Reporting/registering Pressing charges (misdemeanours, minor) Reporting changes Tax declarations for private individuals, with no pre-completed information about personal financial situation Fulfilling permit requirements for private individuals Requesting WOZ (immovable property) value Tax declarations for private individuals; collecting or editing 3 partially pre-completed declaration form (displaying personal data risk category 2) Tender documents Environmental permit for businesses, residency permits for labour/knowledge migrants, official documents (certificate of good conduct, passport, driver’s license, etc.) Tax declarations for businesses Financial eligibility for businesses (subsidy) Compliance with requirements for businesses (annual statement, etc.) Declaration (birth) 4 Consulting medical dossier Pressing charges (criminal offences, serious) Patent applications30  The Standardisation Forum | Assurance levels for authentication for electronic government services The Standardisation Forum | Assurance levels for authentication for electronic government services  31
  • 17. This brochure is a publication by:The Standardisation ForumJanuary 2012