Online Collection Software - Joinup.eu · Online Collection Software Page 13 / 127 Document Version 1.0 dated 14/02/2012 2. INTRODUCTION The main objective of the present document

Online Collection Software Page 1 / 127 Document Version 1.0 dated 14/02/2012

Online Collection Software

Risk Analysis

Date: 14/02/2012

Version: 1.00

Authors: Ivan MARUSICH

Revised by:

Approved by: Natalia Aristimuño (DIGIT.B1)

Mario-Paulo Tenreiro (SG.G4)

Public:

Reference Number:


RECORD OF ADDITIONS AND VARIANTS

Date Version Description Chapter/Sections changed

14/02/2012 1.0 First release


INDEX OF SECTIONS 1. EXECUTIVE SUMMARY....................................................................... 5

2. INTRODUCTION ................................................................................. 13

2.1. APPLICABLE STANDARDS............................................................ 14 ISO/IEC 2700k ................................................................................ 14 OWASP ........................................................................................... 14

3. GLOSSARY ........................................................................................ 15

4. ASSUMPTIONS FOR A RISK ANALYSIS.......................................... 18

4.1. SAFETY/SECURITY CONCEPTS AND PROTECTION OF COMPANY ASSETS ........................................................................................... 18

4.2. GENERAL MODEL AND TERMINOLOGY........................................... 19 4.3. CONCEPTS AND TERMS TO CONSIDER.......................................... 19

5. RISK ANALYSIS METHODOLOGY.................................................... 21

5.1. IDENTIFICATION OF THE PERIMETER ............................................ 21 Component...................................................................................... 21 System ............................................................................................. 22 Macrodatum.................................................................................... 23

5.2. INFORMATION AND COMPONENTS CLASSIFICATION ....................... 24 Macrodata classification questionnaire............................................ 25

5.3. ESTIMATION OF THE EXPOSURE TO THREATS................................ 29 5.4. RISK ESTIMATION....................................................................... 33 5.5. COUNTERMEASURES IDENTIFICATION AND PROTECTION

PROFILE DEFINITION ......................................................................... 34

6. OCS RISK ANALYSIS ........................................................................ 35

6.1. IDENTIFICATION OF THE PERIMETER ............................................ 36 OCS deployment and security set-up through OCS code

customization.......................................................................... 38 Manage initiative details using XML initiative detail file ................ 38 Citizen Initiative sign-up ................................................................. 39 Manage signatures .......................................................................... 40 Exporting collected data .................................................................. 40 Secure logging to the administrative module .................................. 41 Component and Macrodata identification....................................... 41

6.2. INFORMATION AND COMPONENTS CLASSIFICATION ....................... 44 6.3. ESTIMATION OF THE EXPOSURE TO THREAT.................................. 48


6.4. RISK ESTIMATION....................................................................... 60 6.5. COUNTERMEASURES IDENTIFICATION AND PROTECTION

PROFILE DEFINITION ......................................................................... 62 6.6. COMPLIANCE FOCUS ................................................................ 111

7. ANNEX A .......................................................................................... 113

8. ANNEX B .......................................................................................... 119


1. EXECUTIVE SUMMARY

Between December 2011 and January 2012, according European Commission needs, a Risk Analysis has been performed for evaluating the security level of OCS Application. The Risk Analysis Methodology applied for the analysis was based on a mix between:

• MIGRA – Integrated Methodology for the Management of Company Risks (A SelexElsag/Finmeccanica Risk Analysis patented framework compliant with ISO2700k standard family),

• OWASP Threat Risk Modeling, • OWASP ASVS (Application Security Verification Standard).

The security references considered during the analysis has been as follows:

• Commission Implementing Regulation No 1179/2011 of 17 November 2011 – Laying down technical specifications for online collection systems pursuant to Regulation (EU) No 211/2011 of the European Parliament and of the Council on the citizens' initiative.

• ISO/IEC 27000 — Information security management systems — Overview and vocabulary

• ISO/IEC 27001 — Information security management systems — Requirements

• ISO/IEC 27002 — Code of practice for information security management

• ISO/IEC 27005 — Information security risk management • OWASP (Open Web Applications Security Project) best practices • OWASP top ten most critical web application security risks • OWASP Application Security Verification Standard (ASVS) • Common Weakness Enumeration (CWE) • FIPS PUB 140-2 - Security requirements for cryptographic modules

The aim of this chapter is to describe briefly how the applied methodology works and the outcomes of the risk analysis process. Identification of the perimeter After analyzing in detail the architecture and the features of the OCS software, a model has been developed to identify each kind of asset target of the analysis. In particular, perimeter’s components (material assets) and macrodata (immaterial assets) have been identified, as shown in the following table.


Component Name

Component Description

OCS Database Database where all treated data is stored: XML initiative's details, citizens' personal data signatures, administrative credential, etc.

OCS Front-Office

Module that provides an electronic form for EU citizens to express their support for an on-going Citizen Initiative

OCS Back-Office Module used by initiative organisers for the follow-up of signatures, reporting, monitoring and exporting the collected data to the certifying authorities.

Macrodata Name

Macrodata Description

XML Initiative Detail

Collection of data used to define Initiative details: title, subject, description, registration number, date of registration, information about Organiser and contact person, etc.

Citizens' Personals Data

Collection of data about citizens: first name, family name, father's name, permanent residence information, country, date and place of birth, document ID number, etc.

Administrative Credential Credential used to access to OCS administrative module.

Information and Component classification Each macrodata has been subsequently classified through a specific questionnaire which assessed the criticality of information in terms of confidentiality, integrity and availability.

Macrodata Classification Macrodata Name C I A XML Initiative detail - high Low Citizens' personal data High Medium Medium Administrative credential Medium Medium Medium

Taking into account the macrodata classification values and applying the inheritance algorithm to the Risk Assessment Model, the criticality class of each component has been defined as shown in the following table.


Components Classification Component Name C I A OCS Database High High High OCS Front-Office High High High OCS Back-Office Medium High Medium

Estimation of exposure to threats Threats have been indentified by taking into account relevant OWAS top 10 vulnerability and the "STRIDE" method proposed by OWASP. Exposure has been assessed "manually", using DREAD - the most wide spread evaluation model. The details of the estimated levels are given in full text. Below is a brief list of threats to which the perimeter is exposed.

• Injection • Cross-Site Scripting (XSS) • Broken Authentication and Session Management • Insecure Direct Object References exploitation • Insecure Cryptographic Storage exploitation • Failure to Restrict URL Access • Insufficient Transport Layer exploitation • Brute Force Attack • Cryptoanalysis • Network Eavesdropping • Unauthorized access • Application failure

Risk estimation and countermeasures identification Using the values of information criticality and threat exposure, the “intrinsic risk” of the perimeter has been calculated, with the aim of determining the appropriate set of countermeasures for facing and countering risks. The following chart reports the intrinsic risk “at a glance”.


48,5%OCS BACK

OFFICE

22,5%OCS DATABASE

29%OCS FRONT

OFFICE

Each proposed countermeasure has been analyzed to assess if it had been already implemented or not. This process step is a very important topic in determining how many countermeasures contribute to mitigate risks and how many, on the other hand, are not useful in reducing the residual risk value. The following chart reports the comparison between intrinsic and residual risk as outcome of this evaluation.


Going in detail, in the following charts present the Residual Risk Percentages sorted by Component and the contribution of each Component to OCS comprehensive Residual Risk.

Overall, the calculated residual risk stood at 19,56%. That is not so high a percentage; however, it is important to consider the proposed countermeasures to further reduce the risk level.


To make the most effective choices it is advisable to perform a compliance assessment alongside risk analysis. The compliance analysis is done for each of the following references:

• Technical specification implementing regulation (EU) No 211/2011 (for short "TS")

• Common Weakness Enumeration (CWE) • FIPS PUB 140-2 - Security requirements for cryptographic modules • ISO/IEC 27001:2005 - Information technology — Security

techniques — Information security management systems — Requirements

• OWASP Application Security Verification Standard – Web Application Standard (for short OWASP ASVS)

For completeness of this executive summary, the following table lists the countermeasures currently not implemented. It is advisable to decide on the future status of these measures in order to reduce the level of residual risk and increase the compliance of the Software with the security standards.


Threats Countermeasures Source and for more

details Insecure Cryptographic Storage exploitation

A policy on the use of cryptographic controls for protection of information should be developed and implemented.

ISO/IEC 17799:2005 ISO/IEC 27001:2005 Control 12.3.1 - Policy on the use of cryptographic controls

Insecure Cryptographic Storage exploitation

The cryptographic security policy should contain at least the following information: - Definition of Cryptographic Module Security Policy - Purpose of Cryptographic Module Security Policy - Specification of a Cryptographic Module Security Policy - Identification and Authentication Policy - Access Control Policy - Physical Security Policy - Mitigation of Other Attacks Policy

FIPS PUB 140-2 - Security requirements for cryptographic modules

Brute Force Attack

The account is locked for a period of time long enough if a maximum number of authentication attempts is exceeded.

OWASP ASVS – V2.3

Brute Force Attack

The strength of any authentication credentials is sufficient to withstand attacks that are typical of the threats in the deployed environment.

OWASP ASVS – V2.7

Unauthorized access

Make sure that each log event includes: - a time stamp from a reliable source, - severity level of the event, - an indication that this is a security relevant event (if mixed with other logs), - the identity of the user that caused the event (if there is a user associated with the event), - the source IP address of the request associated with the event, - whether the event succeeded or failed, and - a description of the event.

OWASP ASVS – V8.6

Unauthorized access

Make sure that security logs are protected from unauthorized access and modification.

OWASP ASVS – V8.8

Unauthorized access

All relevant statutory, regulatory, and contractual requirements and the organization’s approach to meet these requirements should be explicitly defined, documented, and kept up to date for each information system and the organization.

ISO/IEC 17799:2005 ISO/IEC 27001:2005 Control 15.1.1 - Identification of applicable legislation

Unauthorized access

Access to information and application system functions by users and support personnel should be restricted in accordance with the defined access control policy

ISO/IEC 17799:2005 ISO/IEC 27001:2005 Control 11.6.1 – Information access restriction


Unauthorized access

Information systems should be regularly checked (vulnerability assessment or, better, penetration test) for compliance with security implementation standards.

ISO/IEC 17799:2005 ISO/IEC 27001:2005 Control 15.2.2 – Technical compliance checking

Application failure

Make sure that no malicious code is in any code that was either developed or modified in order to create the application

OWASP ASVS – V13.1

Application failure

Make sure that the integrity of interpreted code, libraries, executables, and configuration files is verified using checksums or hashes.


Application failure

Software technical documentations should be draw up to documents DB Architecture, Data flow and adopted technical solution.

ISO/IEC 17799:2005 ISO/IEC 27001:2005 Control 10.1.1

Finally it is important to underline that the risk analysis concerns just the aspects related to the OCS application. All the other aspects, related with the system and its management is responsibility of the “Organiser”, who will have to lead its own risk assessment to understand and address specific security needs given by the context to ensure that the entire OCS platform will be safe. For this purpose, nnex B contains some suggestions and proposals that the “Organisers” could take into account to check their security system and improve at an acceptable level the overall infrastructure.


2. INTRODUCTION

The main objective of the present document is to perform a Risk Analysis of the Online Collection Software (OCS) in compliance with the following standards:

• ISO/IEC 27000 — Information security management systems — Overview and vocabulary

• ISO/IEC 27001 — Information security management systems — Requirements

• ISO/IEC 27002 — Code of practice for information security management

• ISO/IEC 27005 — Information security risk management Since the OCS is a web based application we also take in consideration:

• OWASP (Open Web Applications Security Project) best practices • OWASP top ten most critical web application security risks • OWASP Application Security Verification Standard (ASVS)

For delivering this activity Selex Elsag has used MIGRA – Integrated Methodology for the Management of Company Risks adequately integrated with the OWASP Threat Risk Modeling and the OWASP ASVS (Application Security Verification Standard). MIGRA is a Finmeccanica Risk Analysis Methodology that supports customers to perform risk assessments based and compliant with ISO2700k standard family. The Methodology is applicable to any "Perimeter" but is specialized, in particular, for performing "information" security assessment in ICT context. To more specialize the approach to a risk analysis of a web application we have integrated MIGRA with the OWASP Threat Risk Modeling that is an essential process for secure web application development and the OWASP ASVS to verify software "security level". The risk analysis is performed also taking in consideration:

• Commission Implementing Regulation No 1179/2011 of 17 November 2011 – Laying down technical specifications for online collection systems pursuant to Regulation (EU) No 211/2011 of the European Parliament and of the Council on the citizens' initiative.

• Information gathered during specific interviews. • Security good practices and security guide lines specific to the

context analyzed.


2.1. Applicable standards

ISO/IEC 2700k

The ISO/IEC 27000-series (also known as the 'ISMS Family of Standards' or 'ISO27k' for short) comprises information security standards published jointly by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). The series provides best practice recommendations on information security management, risks and controls within the context of an overall Information Security Management System (ISMS), similar in design to management systems for quality assurance (the ISO 9000 series) and environmental protection (the ISO 14000 series). The series is deliberately broad in scope, covering more than just privacy, confidentiality and IT or technical security issues. It is applicable to organizations of all shapes and sizes. All organizations are encouraged to assess their information security risks, then implement appropriate information security controls according to their needs, using the guidance and suggestions where relevant. Given the dynamic nature of information security, the ISMS concept incorporates continuous feedback and improvement activities, summarized by Deming's "plan-do-check-act" approach, that seek to address changes in the threats, vulnerabilities or impacts of information security incidents. The standards are the product of ISO/IEC JTC1 (Joint Technical Committee 1) SC27 (Sub Committee 27), an international body that meets in person twice a year. At present, eleven of the standards in the series are published and available, while several more are still under development. The original ISO/IEC standards are sold directly by ISO, while sales outlets associated with various national standards bodies also sell various versions including local translations. OWASP

The Open Web Application Security Project (OWASP) is an open community dedicated to enabling organizations to develop, purchase, and maintain applications that can be trusted. At OWASP you’ll find free and open …

• Application security tools and standards


• Complete books on application security testing, secure code development, and security code review

• Standard security controls and libraries • Local chapters worldwide • Cutting edge research • Extensive conferences worldwide • Mailing lists • And more

In particular the OWASP Application Security Verification Standard (ASVS) provides a basis for testing application technical security controls, as well as any technical security controls in the environment, that are relied on to protect against vulnerabilities such as Cross-Site Scripting (XSS) and SQL injection. This standard can be used to establish a level of confidence in the security of Web applications.

3. GLOSSARY

Term Definition Captcha Abbreviation of: “Completely Automated

Public Turing-test to tell Computers and Humans Apart” A Captcha is a reaction test used in computing as an attempt to ensure that the response is not generated by a computer. E.g. asking a user to retype a picture that shows a word, which is legible for a human being but not legible for a computer.

Citizen of the Union A citizen is a person who holds the nationality of one of the 27 EU Member States.

Citizens’ committee A citizens’ committee is a group of at least 7 organisers who are residents in at least 7 different EU countries responsible for the preparation of a citizens’ initiative and the submission to the Commission.

Citizens’ initiative A citizens’ initiative is a proposal for a legal act of the Union by a citizens’ committee.


Term Definition Commodity hardware Commodity hardware is hardware that is

easily and affordably available. A device that is said to use "commodity hardware" is one that uses components that were previously available or designed and are thus not necessarily unique to that device.

Component Resource or entity forming part of the Perimeter which needs protection as it is potentially exposed to risk of Threats.

Countermeasure Technical device or organizational procedure that can counter one or more threats and lower the risk level

Data controllers A data controller is a person who (either alone or jointly or in common with other persons) determines the purposes for which and the manner in which any personal data are, or are to be, processed.

Encryption Encryption is the conversion of data into a form, called a ciphertext, using an algorithm, that cannot be easily understood by unauthorized people.

Exposure Set of external type conditions which make the occurrence of harm more or less probable

Harm Negative effect of a threat Identity stores An identity store is the location where user

identification and authentication information is stored.

Input validation Input validation is the process of ensuring that a program collects clean, correct and useful data. Validation “rules” check the correctness, meaningfulness, and security of data entered in the system.

Local File Inclusion Local File Inclusion is the process of including files on a server through the web browser. This vulnerability occurs when a page is not properly sanitized, and allows directory traversal characters to be injected.

MIGRA Integrated Methodology for the Management of Company Risks.

Online collection system

An online collection system is a web based application designed to collect data over a

http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci213853,00.html





Term Definition network.

Open-source software (OSS)

Open-source software (OSS) is computer software that is available in source code form for which the source code and certain other rights normally reserved for copyright holders are provided under a software license that permits users to study, change, and improve the software.

Organisers Organisers are citizens of the Union forming a citizens’ committee responsible for the preparation of a citizens’ initiative and the submission to the Commission.

OWASP Open Web Application Security Project. OWASP ASVS OWASP Application Security Verification

Standard. Portal Front-end site. Processing Processing of data is any process that uses a

computer program to enter data and summarise, analyse or otherwise convert data into usable information.

Protection Measure See countermeasure EU Register The register is an online register made

available by the Commission to provide the information about the initiative, in particular on the subject-matter and objectives as well as on the sources of funding and support for the proposed citizens' initiative.

Reusable Software is reusable if a segment of source code can be used again to add new functionalities with slight or no modification.

Risk Possibility that a negative event will occur intended as the product between the probability of occurrence of the event and the consequent harm

Safety/Security The condition of being free from harm, or more commonly, the absence of danger

Session A session is an interactive information exchange between communicating devices.


Term Definition Signatory A signatory is a citizen of the European Union,

who supports an initiative by completing a statement of support.

Site Visitor Any site visitor or “end user” of the front-end site/portal.

System Aggregate of homogenous components in terms of criticality, functionality, and need for protection

Threat Potential event harmful to the component to protect

Vulnerability Set of internal type conditions which make the occurrence of any harm more or less probable

Web application A web application is a software application that can be accessed over a network or internet.

4. ASSUMPTIONS FOR A RISK ANALYSIS

4.1. Safety/Security concepts and protection of company assets

The most widely accepted definition of safety/security is the condition of being free from harm, or more commonly, the absence of danger.

In the specific business context, safety/security can mean the condition of being risk free to the extent that the company can carry out its mission. This condition therefore involves the study of the technical and organizational measures that protect the company through the protection of the resources that contribute to company processes.

Safety is used when referring to potential “physical” injury to people even though, in a sense, the word security also implies this. The concept of security is closely connected to other terms (concepts) such as protection, danger, threat, attack, harm and, finally, risk. This document will deal with the concept of risk.

The risk analysis performed on "Online Collection Software" is a security assessment that doesn't include the "safety domain". So, are analyzed and evaluate "technology" threats and risks to determine which countermeasures are suggested to securing the Software.


4.2. General model and terminology

A risk analysis methodology must be based on, and take account of, a series of concepts and the “shared” interrelations and definitions of the community and nowadays considered in documents that are widely available and accepted in companies, called “standards”. The definition and correct understanding of these concepts is not generalized however so they need to be briefly described to provide a better understanding of this methodology and so as to clarify the concepts and create a common knowledge base. As will be seen, these concepts are important for preparing a model for risk analysis.

The aim is to illustrate the general model that MIGRA is modeled on for the protection of company assets using precautionary measures and control. This general model summarizes and illustrates principles and terminology that are widely shared in the community of people working in the security area and applicable standards.

4.3. Concepts and terms to consider

The first stage in defining a general model is to identify the entity in question and give it a definition.

Various entities will be examined in the treatment that follows. Sometimes, certain qualities will be associated with these entities. Quality and quantity taken as a whole will be referred to using the term "concepts".

We have previously defined security. Now we can consider the concept of risk.

We can define risk as the possibility that a negative event will occur which will cause harm to someone or something. The reference to harm is not redundant as it can cause damage to one party, but give an advantage to another: if it creates an advantage, it cannot be considered to be a risk.

Risk is closely associated with the concept of threat, which could be said to constitute an equivalent of it, purged of the probability and consequential harm characteristics. Previously we defined risk as the possibility that a negative event would occur causing harm to someone or something. Threat is actually that event.

Another important concept, which appears more like a quality of the subject at risk rather than another entity, is the exposure of a determined subject to a determined threat. It is worthwhile to consider this concept correlated to the concept of vulnerability, which also forms part of the category of the quality of the subject.


Regarding a certain subject and in relation to a determined threat, the exposure can be defined as the group of external type conditions acting on the subject which makes the occurrence of harm due to the threat in question more or less probable. On the other hand, vulnerability is a different concept even though it is complementary and parallel to the previous concept, and refers to the group of internal conditions acting on the subject.

Going from the field of risk analysis to that of risk management brings us to the important concept of countermeasures. This term refers to the devices, procedures, guide lines, security and organizational solution that can counter the risk level and lower it.


5. RISK ANALYSIS METHODOLOGY

Analysts who have to make a Risk Assessment will have to face four types of basic concepts and use them: components, macrodatum, threat, and countermeasures. The fundamentals of these concepts will be described below in addition to an explanation of how they work. In particular are explained below the steps to perform a risk analysis using Migra methodology. These steps are reassumed as follow:

• Identification of the Perimeter • Information and Components Classification • Estimation of the exposure to threat • Risk estimation • Countermeasure identification and Protection Profile definition

5.1. Identification of the Perimeter

When one conducts a risk analysis the first thing to do is define the Perimeter through the definition of scope and boundaries where the analysis is performed. The term Perimeter actually means the field of application of the planned assistance that risk analysis method will provide.

The Perimeter can be anything: software, service, IT process, physical environment, entire company, etc.

To better describe the Perimeter is suggested to model the reality using "objects" that the Migra methodology called Component, System and Macrodatum.

Component

The component is a resource (or entity) of the Perimeter which needs protection as it is potentially exposed to risk of threat. The components are also the elements that permit the analyst to fully describe the Perimeter, in their second level creation.

The concept of first and second level instance should be clarified at this point. The used terminology derives from the objects theory.

For the purposes of this document, first level instance is the identification of the concepts in terms of concrete types, but still in a generalized sense.


In fact these creations (places, offices, etc.) do not refer to a specific Perimeter (e.g.: a facility).

On the other hand, second level instance means the creation of components at the level of the specific Perimeter that the analyst must protect.

At the first level of instance, the degree of abstraction of the components is chosen by selecting a suitable middle road between an excessive and a too low abstraction, on the basis of the following criteria:

• the component must not represent such a basic entity, as not to permit the perception of the functionality at company level and, in particular, as regards the concept of protection (a brick would be too low a level, as a handle would be, but a boundary wall, a parking area, a corridor, or a room would probably be at the right level of abstraction);

• the component as identified should be correlated with one or more countermeasures in its need for protection;

• in theory the components do not have to be identified a priori and correlated with a library available to the user: however, if this is done, it will provide a series of benefits:

- homogeneity in their use and in their articulation in different protection projects and use by various analysts in the company or in different companies in the group;

- option to associate them with specific countermeasures (where the countermeasures are applied) and to corresponding vulnerabilities;

- option to assume a role of beneficiary of the primary or secondary promotion;

- help in creating a classification metric. System

The methodology provides for a components grouping level, called system, prior to the “Perimeter” one.

The definition of system is an aggregation of components, defined by the analyst each time, which are homogenous as regards criticality and need for protection, and forming part of the Perimeter in question. Such aggregations can be computer room, office buildings, earth stations, etc. characterized, for instance, by a common degree of criticality.

Therefore, the methodology allows the components to be aggregated into systems, and the systems can be aggregated into Perimeters.


In accordance with the level of criticality of the component, its level of exposure to the threat, and in relation to the technical and functional characteristics, specific countermeasures may be necessary for a specific component, which may be compared with those already existing.

The components can take on a final beneficiary role in the protection or be used to implement the countermeasures that benefit another component that is functionally correlated.

Macrodatum

Company data are assets that must be protected. For the purposes of the protection System, the information refers to a certain Perimeter and is organized into Macrodata.

A Macrodatum refers to a homogenous set of data as regards:

• seriousness of the impact on the company following loss if its Confidentiality, Integrity or Availability. These parameters are called security attributes;

• semantic affinity: they all belong to the same reference entity (e.g. employees registry, product schedules, etc.)

• purpose of treatment: they are used in the scope of a single company process or purpose (e.g. processing wages, creating a product, sales statistics, etc.)

• technological processing needs: they are localized in supports that are logically and functionally continuous and connected (e.g. data bases, cabinets, magnetic-optical supports, etc.)

For understand better is necessary to define what Confidentiality, Integrity and Availability means:

• Confidentiality: the guarantee that all the data are only made available for the processes that must process it, and only to the user who objectively needs it and is authorized to use it

• Integrity: the guarantee that all the data is the same as that originally entered into the information system or later changed in a legitimate manner

• Availability: the guarantee of availability of the data in accordance with the need for continuity of company processes and to comply with legal and non legal regulations which require historical conservation


One macrodatum can be used in different processes. Once the macrodatum managed by a resource (or a group of resources) is identified, it is not necessary to know what process it belongs to in order to create the protection measure to associate with the resource.

5.2. Information and Components Classification

In general terms, the classification of the Components is made to determine their importance (criticality) for the company and, if necessary, protect them.

The classification consists to evaluate directly or not, for each component, the security attributes: Confidentiality, Integrity, Availability.

To evaluate a component "directly" is enough to determine in term of high, medium, low how much each security attributes is important for the company and security. The direct classification is suggested when the Perimeter is huge and involve in hundreds of components.

The "indirect" classification is doing through the "information classification". In this case the component inheritance the criticality of the macrodata who manage or elaborate in term of Confidentiality, Integrity and Availability.

The estimation of the impact, the loss of the information Confidentiality, Integrity, or Availability would have on the company processes, is made by classifying the data. The classification of the data gives added value to sector/company data in the following sides:

• it permits an ordered and rational identification of the different data classes (macrodata) within the sector/company, associating the person in charge to each class for internal company purposes and legal purposes

• it assigns a criticality value to the grouped data (macrodata). This procedure is at the basis of the risk analyses and the countermeasure set planning pertinent to the macrodata.

As a result of the classification process, the criticality is carried out by using the questionnaire (see Appendix B - Macrodata classification questionnaire) and it is expressed by a trio of elements which can assume one of the values shown below, and thus determine the CIA criticality


class of the macrodatum: High, Medium, Low or Null/Not applicable (N/A) The last option is to be selected if a specific harmful consequence is considered as not pertinent or pertinent but with a close to zero possibility of it occurring. The macrodata must be classified before defining the relative protection measures. This classification is a fundamental preliminary step in the risk analysis, and it means that the protection measures can be precisely and effectively graduated. The classified macrodata can be associated with the single component that constitute the Perimeter systems under evaluation and give a criticality class called the component criticality class to each component. The criticality class of a component is expressed by a trio of elements which are equal to the maximum of the values of the corresponding elements of the trios that represent the criticality class of the macrodata associated with the component itself. Macrodata classification questionnaire

The questionnaire defines and use by the European Commission for the OCS risk analysis is shown below.

Date: yy.mm.dd Asset Owner: MACRODATUM: Code:

Impact estimate Parameters N. Queries N/A low medium high

1 Unauthorized access to personal data 2 Loss of competitiveness

3 Blackmailing and/or external retaliation Confidentiality

4 Disclosure of confidential information with loss of earnings or image

5 Alteration of the management control systems

6 Alteration of the administrative and accounting process

7 Business process alteration Integrity

8 Alteration of other company processes apart from the one in question

Availability 9 Interruption of management processes with efficiency loss


10 Interruption of mission processes with loss of earnings

11 Breach of legal obligations concerning data storage

12 Data and information re-loading

The data owner must fill out one questionnaire for each macrodatum identified, and indicate his evaluation of the seriousness of the harm (high, medium, low or null/not applicable) with a cross for each consequence considered pertinent to the macrodatum in question. The questionnaire should be filled out in accordance with the following: Date Note the date that the questionnaire is filled out and completed Data Owner Write the name of the person who is in charge of identifying the macrodata and filling out the questionnaire. Macrodatum name Write the name of the macrodatum that the evaluation is to be made on Macrodatum code Note the code of the macrodatum if any. Impact estimation The person, who fills in the questionnaire, must estimate the seriousness of the consequent harm analyzing the damaging consequences listed for each parameter (CIA). It should be made by putting an X in the relevant column corresponding to the High, Medium, Low or N/A value. The N/A (Not Applicable) option is selected when a specific harmful consequence is considered not pertinent or pertinent but the likelihood of being carried out is near zero. Queries It notes the case record of the harmful consequences that the seriousness of any consequent harm must be evaluated. For each of them a short explanation is shown below:


• Unauthorized access to personal data: it concerns civil sanctions and penalties, according to Privacy Laws, in which it is possible to incur for personal data confidentiality violation. Then, these events can threaten company image on its market;

• Loss of competitiveness: it concerns acts of confidential information appropriation, or industrial espionage, which can company weakening in comparison with competitors;

• Blackmailing and/or external retaliation: it concerns the compensation acts, also for profit, made by people external to the company who can use confidential information for their own business;

• Disclosure of confidential information with loss of earnings or image: it concerns the consequences, coming from no-authorized access to important macrodata for company mission, whose uncontrolled use can involve economic and/or image loss;

• Alteration of the management control systems: examined macrodatum alteration which can produce errors in the developing of management control process;

• Alteration of the administrative and accounting process: examined macrodatum violation which can produce changes to company balance and/or administration;

• Business process alteration: examined macrodatum violation which can produce changes to business processes with profit loss and/or image;

• Alteration of other company processes apart from the one in question: examined macrodatum violation which can spread to data in external elaborative chains (to which the examined macrodatum doesn’t belong to);

• Interruption of management processes with efficiency loss: it concerns the consequences coming from interruptions to operative processes of management control to which company operation efficiency;

• Interruption of mission processes with loss of earnings: it concerns the consequences on which the possible mission process interruptions depend. They can involve loss of profit and image (quality and reliability of the whole company system);

• Breach of legal obligations concerning data storage: it concerns data which, for civil, criminal and fiscal law, must be available for Authorities (Magistracy, Revenue Guard Corps, etc.);

• Data and information re-loading: it concerns the consequences coming from data loss, in absence of copy archives, which involves


the necessity of resorting to manual re-loading of the same data or rebuilding the elaborative chains which produced them.

Algorithm for the calculation of the criticality class In order to apportion the identified macrodata into criticality classes, the algorithm for the calculation of the criticality class must be applied to the questionnaires filled out by the macrodata owners. The algorithm is applied by imputing a value in the ‘seriousness of the harm’ column noted by the macrodata owner for each consequence, and then summing all these values in the vertical columns under the box “Partial sum”. The sum of the values of each parameter (Confidentiality, Integrity, Availability) will be that shows under the “Total” voice. The following illustrates a questionnaire and the related criticality threshold table:

Integrity Confidentiality Availability

N. Consequences

high

med

ium

low

N/A

U/E

high

med

ium

low

N/A

U/E

high

med

ium

low

N/A

U/E

1 Unauthorized access to personal data 100 50 25 0 -

2 Loss of competitiveness 100 50 25 0 -

3 Blackmailing and/or external retaliation 100 50 25 0 -


100 50 25 0 -


100 50 25 0 -


100 50 25 0 -

7 Business process alteration 100 50 25 0 -


100 50 25 0 -

9 Interruption of management processes with efficiency loss

100 50 25 0 -


100 50 25 0 -

11 Breach of legal obligations concerning data storage 100 50 25 0 -

12 Data and information re-loading 100 50 25 0 -

Partial Sum 200 50 0 100 50 200 Total 250 150 200


Criticality class Class range Null/Not Applicable 0 ≤ p < 50

Low 50 ≤ p < 150 Medium 150 ≤ p < 300

High 300 ≤ p

5.3. Estimation of the exposure to threats

Threat means the potential occurrence of one or more events or actions not desired which can cause both deliberate and accidental harms. The seriousness of the threat is proportional to the seriousness of the consequent harm. An agent (a hacker, a dishonest employee, a terrorist, etc.) is normally associated with the threat.

The following gives some examples of different types of threat:

• Spoofing Identity • Information disclosure • Denial of service • Elevation of privilege • Etc.

The threats are logically associated to each component of the Perimeter. In this way through the evaluation of threats is possible to determine the "threat exposure level" of the component.

In compliance with OWASP Threat Risk Modeling, MIGRA can uses a STRIDE method to "classified" threats.

STRIDE is a classification scheme for characterizing known threats according to the kinds of exploit that are used (or motivation of the attacker). The STRIDE acronym is formed from the first letter of each of the following categories.

Spoofing Identity “Identity spoofing” is a key risk for applications that have many users but provide a single execution context at the application and database level. In particular, users should not be able to become any other user or assume the attributes of another user.


Tampering with Data Users can potentially change data delivered to them, return it, and thereby potentially manipulate client-side validation, GET and POST results, cookies, HTTP headers, and so forth. The application should not send data to the user, such as interest rates or periods, which are obtainable only from within the application itself. The application should also carefully check data received from the user and validate that it is sane and applicable before storing or using it.

Repudiation Users may dispute transactions if there is insufficient auditing or recordkeeping of their activity. For example, if a user says, “But I didn’t transfer any money to this external account!”, and you cannot track his/her activities through the application, then it is extremely likely that the transaction will have to be written off as a loss.

Therefore, consider if the application requires non-repudiation controls, such as web access logs, audit trails at each tier, or the same user context from top to bottom. Preferably, the application should run with the user’s privileges, not more, but this may not be possible with many off-the-shelf application frameworks.

Information Disclosure Users are rightfully wary of submitting private details to a system. If it is possible for an attacker to publicly reveal user data at large, whether anonymously or as an authorized user, there will be an immediate loss of confidence and a substantial period of reputation loss. Therefore, applications must include strong controls to prevent user ID tampering and abuse, particularly if they use a single context to run the entire application.

Also, consider if the user’s web browser may leak information. Some web browsers may ignore the no caching directives in HTTP headers or handle them incorrectly. In a corresponding fashion, every secure application has a responsibility to minimize the amount of information stored by the web browser, just in case it leaks or leaves information behind, which can be used by an attacker to learn details about the application, the user, or to potentially become that user.

Finally, in implementing persistent values, keep in mind that the use of hidden fields is insecure by nature. Such storage should not be relied on to secure sensitive information or to provide adequate personal privacy safeguards.

Denial of Service Application designers should be aware that their applications may be subject to a denial of service attack. Therefore, the use of expensive resources such as large files, complex calculations, heavy-


duty searches, or long queries should be reserved for authenticated and authorized users, and not available to anonymous users.

For applications that do not have this luxury, every facet of the application should be engineered to perform as little work as possible, to use fast and few database queries, to avoid exposing large files or unique links per user, in order to prevent simple denial of service attacks.

Elevation of Privilege If an application provides distinct user and administrative roles, then it is vital to ensure that the user cannot elevate his/her role to a higher privilege one. In particular, simply not displaying privileged role links is insufficient. Instead, all actions should be gated through an authorization matrix, to ensure that only the permitted roles can access privileged functionality

To evaluate the "Threat Level Exposure" is possible to use a "direct classification, using high, medium and low to define the probability that a threat can happen, or a more detailed method called DREAD.

DREAD is a classification scheme for quantifying, comparing and prioritizing the amount of risk presented by each evaluated threat. The DREAD acronym is formed from the first letter of each category below.

DREAD modeling influences the thinking behind setting the risk rating, and is also used directly to sort the risks. The DREAD algorithm, shown below, is used to compute a risk value, which is an average of all five categories.

Risk_DREAD = (DAMAGE + REPRODUCIBILITY + EXPLOITABILITY + AFFECTED USERS + DISCOVERABILITY) / 5

The calculation always produces a number between 0 and 10; the higher the number, the more serious the risk.

Here are some examples of how to quantify the DREAD categories.

Damage Potential • If a threat exploit occurs, how much damage will be caused?

o 0 = Nothing o 5 = Individual user data is compromised or affected. o 10 = Complete system or data destruction

Reproducibility

• How easy is it to reproduce the threat exploit?


o 0 = Very hard or impossible, even for administrators of the application.

o 5 = One or two steps required, may need to be an authorized user.

o 10 = Just a web browser and the address bar is sufficient, without authentication.

Exploitability

• What is needed to exploit this threat? o 0 = Advanced programming and networking knowledge,

with custom or advanced attack tools. o 5 = Malware exists on the Internet, or an exploit is easily

performed, using available attack tools. o 10 = Just a web browser

Affected Users

• How many users will be affected? o 0 = None o 5 = Some users, but not all o 10 = All users

Discoverability

• How easy is it to discover this threat? o 0 = Very hard to impossible; requires source code or

administrative access. o 5 = Can figure it out by guessing or by monitoring network

traces. o 9 = Details of faults like this are already in the public domain

and can be easily discovered using a search engine. o 10 = The information is visible in the web browser address

bar or in a form.

At the end of the evaluation of the Risk_DREAD is necessary to convert the value obtained using the following table.

Risk_DREAD Threat Exposure Level0 Null

1≤ R_D ≤4 Low 5≤ R_D ≤7 Medium 8≤ R_D ≤10 High


5.4. Risk estimation

The risk, in this context, is the harm expected during a fixed time interval, if a threat comes off. The Risk level indicates the harms expressed in qualitative measure. Each component is associated, for every threat, to a risk level which is function of:

• asset value (represented by CIA Criticality of macrodata associated to a component);

• component exposure level to threat; • protection measures carried out to contrast the threat.

The methodology uses two risk level definitions: • the intrinsic level, evaluated without taking into account

countermeasure accomplishment state; • the residual level, evaluated taking into account the carried out

choices on the countermeasure accomplishment state. Each Component Intrinsic Risk is evaluated starting from the Exposure Level to the Threat and from the Component Criticality (C, I, A).

In particular, the value of the generic element X which represents the Intrinsic Risk Level related to a threat is evaluated through the following table.

Threat Exposure Level Intrinsic Risk

Null Low Medium High Null 0 0 0 0 Low 0 1 1 2

Medium 0 1 2 3 Component

High 0 2 3 3


5.5. Countermeasures identification and Protection Profile definition

Countermeasure is a measure or action taken to counter one or more threats, and is any technological or tactical solution or system designed to prevent an undesirable outcome in the process. The identification of countermeasures must to be compliant with the ISO2700k standard. The countermeasure description in depth level depends on how much the risk analysis is deep and how much the results must describe technical solution. Often the analysis is focused on the "detailed control" of ISO27002 but is possible, if the context have all the details, going in depth and having detailed countermeasures. Each countermeasure contributes to determine the "optimal protection profile" that is a checklist of countermeasures considered optimal to reduce the risk level estimated. For each countermeasure is then necessary to identify if the countermeasure is:

• Already well or partially implemented; • Not implemented

In the first case the countermeasure contributes to reduce the risk level totally o partially depending on how much the countermeasure is implemented. In the second case the countermeasure doesn't contribute to reduce the risk level. In this case the organization should decide if:

• Planning the implementation • Transferring the risk to another organization • Not implement the action and accept the risk.

Using this information about the "status" of the countermeasure is possible to recalculate the risk to obtain the residual level.


6. OCS RISK ANALYSIS

Following the European Citizens' Initiative regulation, the EC must provide Organisers of initiatives an open source web application to collect signatories' data regarding initiative statement. The tool will be available for download to be used by the Organisers. The application will enable the organisers and fellow citizens to support a given initiative in a more efficient manner as opposed to paper forms. The tool will also streamline both data collection and verification by the competent authorities. This application is called "Online Collection Software" (OCS). Referring to the "Technical specifications" at the point 2.1 the European Commission deliberate that the "Organiser provide documentation showing that they fulfill the requirements of standard ISO/IES 27001, short of adoption." In addition for that purpose the point 2.1 specified that is necessary: " (a) performed a full risk assessment, which indentifies the scope of the system,

highlights business impact in case of various braches in information assurance, enumerates the threats and vulnerabilities of the information system, produces a risk analysis document that also list countermeasures to avoid such threats and remedies that will be taken if a threat occurs, and finally draws up a prioritized list of improvements;

(b) designed and implemented measures for treating risks with regard to the

protection of personal data and the protection of family and private life and measures that will be taken in the case risk occurs;

(c) identified the residual risks in writing; (d) provide the organizational means to receive feedback on new threats and

security improvements" At the point 2.2 are also specify other requirements and in particular: "Organizers choose security controls based on the risk analysis in 2.1 (a) from the following standards: (1) ISO/IEC 27002;" Also suggest using the "ISO/IEC 27005" for doing the risk assessment "or another specific and suitable risk assessment methodology". An other reference is at the point (4) of the Regulation where is mentioned the other "standard" OWASP that also us recommend to use: "The Open


Web Application security Project's (OWASP) Top 10 2010 project provides an overview of the most critical web application security risks as well as tools for addressing these risks; the technical specifications therefore draw upon the findings of this project". In this context and with reference to what is described in the methodological chapter, is possible to assume that the MIGRA methodology, integrated with OWASP aspects, is compliant with the Technical Specification of EC Regulation. So, using MIGRA, in the following paragraphs we retrace the methodological steps applying the approach to the Online Collection Software developed by European Commission.

6.1. Identification of the Perimeter

The risk analysis goals are to assess the risks of the Online Collection Software developed by European Commission in line with the Technical Specification annex to Regulation No 1179/2011 of 17 November 2011 – Laying down technical specifications for online collection systems pursuant to Regulation (EU) No 211/2011 of the European Parliament and of the Council on the citizens' initiative. Only the "software level" of OCS is therefore the scope of the analysis and the field where the methodology will be applied. Are excluded by the risk analysis:

• ICT risk related to the platform where the software will be installed (for example hardware failure, unauthorized access to Operative System level, incorrect backup of database, etc.)

• Risk about activities of Organiser (for example loss of integrity of exported decrypted data, unauthorized use of encryption private key, wrong management of administrative credential, etc.)

For better understand which are the boundaries of the risk assessment is necessary to describe software architecture and data flow diagram. In this way will be possible to define better the scope and to proceed with the "asset identification" and the risk analysis model. The Online collection System is composed of the following components as illustrated in the following picture:

1. a Front-Office publicly accessible website - [OCT PUBLIC], the production version will be hosted by the ECI organiser at an ISP of his/her choice – this module will provide an electronic form for EU


citizens to sign up for an on going Citizen Initiative as a way of expressing their supports for that initiative.

2. a Back-Office application - [OCT ADMIN] website co-hosted with the first module - that will be used by initiative organisers for the follow-up of signatures, reporting, monitoring and exporting the collected data to the certifying authorities. It will also provide features to parameterize the Front-office module.

3. a Database where are stored all the data. In particular are stored XML initiative's details (public), citizens' personal data (encrypted) and administrative credential (hashed).

CITIZEN

ORGANISER

FILL-IN OCS WEB FORM in PUBLIC HOME PAGE

OCS VALIDATE ALL

INFORMATION

OCS DATABASE

ENCRYPTION

LOGIN USING USERNAME,

PASSWORD and “CHALLENG STRING”

ACCESS TO ADMIN

HOMEPAGE

MANAGE ACCOUNT

MANAGE SIGNATURES

MANAGE INITIATIVE DETAILS

REPORTING

EXPORTING The application uses an open source platform and it is developed in J2EE, The Java 2 Platform Enterprise Edition. Oracle is use like database platform during the development phase. Is necessary specifying that the application will be satisfy EC regulation of Cross platform compatibilities using open source platforms. So OCS is available on other platform and other Database "technology" like MySql, PostgreSQL, ect.

Is important to specify that the OCS is involved and supports users in different process:

• OCS deployment and security set-up through OCS code customization

• Manage initiative details (creation and update) using XML initiative detail file

• Citizen Initiative sign-up

• Manage signatures (partial or entire deletion, signature monitoring)


• Exporting collected data

• Secure logging to the administrative module

OCS deployment and security set-up through OCS code customization

In the phase of software deployment the Organiser has available:

• OCS code

• Admin username

• Admin Password

• Public Key

• Private Key

• Crypto tool able to manage encrypted information

Before deploying software Organiser uses a specific script and the "credential information" to customize the OCS software. In this way is possible to "configure" the OCS with the private admin username/password and the Public Key for the encryption functions.

After that Organiser can upload the OCS code to the web server supplied by server/service provider. In this way the OCS is deployed and ready for the first use and next configuration.

The "customization activities" presents in this process are managed directly by the Organiser. How the Organiser chooses the credential and preserves the private key is not a target of this risk analysis.

Storing and preserve integrity and confidentiality of Username/Password inside the Database is, instead, included in scope of this risk analysis.

Manage initiative details using XML initiative detail file

Organiser can download the XML Initiative Detail file from the European Commission Initiative web site, after having complete registration and validation steps.

The XML Initiative Detail file contains all the information about the Initiative: title, subject and description. It is important specify that all information about Initiative are public, so there aren't "data" in XML file that need protections.

To create or update the XML file it is necessary to use the ECI web site and download the new XML Initiative Detail file.


After that, it is necessary upload the XML file in OCS Database using the function presents in the OCS Administration Module. In this way the Initiative is created or updated also to the OCS, and it is accessible and readable to every citizens.

The Organiser activities about to create or update an Initiative are performing using the ECI web site. Also for downloading the XML Initiative Detail file. For this reason these tasks are not included in the risk analysis. Moreover the integrity preservation of XML file before the upload to OCS platform is "out of scope" of risk assessment.

Are included, instead, the tasks about uploading and storing the Initiative detailed in to database with particular attention to the integrity of the data.

Citizen Initiative sign-up

Using the OCS front-office graphics unit interface, Citizens can vote and sign-up Initiative. To do this Citizens must fill-in the form that OCS proposes. The form is different for every Member State and request to insert personal information like Name, Surname, Number of Identity Card, Name of the father, etc.

The access to the application is free and doesn't need registration or using username/password.

All the personal data are stored inside the database after the validation end the encryption phases.

CITIZEN

FILL-IN OCS WEB FORM in PUBLIC HOME PAGE

OCS VALIDATE ALL

INFORMATIONOCS

DATABASEENCRYPTION

The validation consist to verify that:

• all the data requested are present and congruent

• citizen has accepted privacy terms

• only real persons (not computers) have submitted the statement of support form

• Verify, after encryption, that citizen subscribed Initiative only once.


The encryption is a transparent task that consists to cipher all personal data before store it in to database. In this way all the information stored are not clear readable without the private key that only the Organiser hold on a "private pc".

All the process relative "Citizen Initiative sign-up" is included in scope of risk assessment. In particular is necessary that the data provided online are securely collected and stored.

Manage signatures

OCS support Organiser to monitoring the progress of sign collection or to correct wrong signature. To perform this, there are available specific functions that permit to:

• Display total distribution of signatures with possibility to display all numbers.

• Allow the user to formulate a periodic query or a country "view" (including all countries) or a combination of both with the possibility to export the respective result each time.

• Find specific signatures based on unique token. • Delete specific signatures based on unique token. • Delete all signatures based on unique token.

All "Manage signature" functionality are included in the scope of risk analysis because is necessary verify that integrity, confidentiality and Availability are not compromising the data stored in to database.

Exporting collected data

When Organiser have finished collecting the necessary statements of support for an initiative, he needs to ask the relevant national authority in each member state, to certify the number of valid statements of support collected for that country.

To do this, is necessary to export the data from database using function presents in the OCS Admin module.

The export permits to save the "encrypted database" in the provider file system. Using ftp or the more secure sftp the Organiser can download the encrypted file on own computer for the decryption task that is doing with a "desktop software" and using the Private Key. After that Organiser can send the data, in a secure mean, to the National Authority for getting certification.


All the activities are performed by the Organiser and so are out of scope of the Risk Assessment. The only aspect that is included in Risk Analysis is the "export function" because it is necessary to be secure that data are exported in a correct way preserving integrity and confidentiality.

Secure logging to the administrative module

The logging to the administrative module is performed using not only the administrative username and password but also another credential obtainable by the OCS and the Encryption Private Key.

ORGANISER

INSERTUSERNAME & PASSWORD

OCS SW GENERATE A “CHALLENGE

ENCRYPTION STRING”

“CHALLENGE RESPONSE” (Short

String) GENERATION

LOGIN TO DESKTOP

APPLICATIONS USING

PASSWORD

RIGHT USERNAME, PASSWORD and “SHORT

STRING” PERMIT TO ACCESS TO OCS ADMIN MODULE

ENCRYPTION PRIVATE KEY

Firstly is necessary to insert the Admin Username / Password. OCS generates automatically a "Challenge Encryption String" long over one hundred characters. Using the "desktop application" and the Encryption Private Key is possible to decrypt the string obtaining the "Challenge Response". Using this short string is possible to complete the authentication ad accede to the OCS Admin Module.

Organiser has responsibility to preserve administrative credential and Encryption Private Key, and how to use it. These aspects are out of scope of risk analysis. Only the algorithm to logging and to verify the correct authentication is included in the scope of risk assessment.

Component and Macrodata identification

After the analysis of the process/functionality of the OCS software is possible identify the "element" that creates the "Risk Analysis Model".


In compliance with the methodology described in the previous chapter, is now necessary to identify Components and Macrodatas.

Component Typology

Component Code

Component Name

Component Description

Database C_001 OCS Database

Database where are stored all treated data: XML initiative's details, citizens' personal data signatures, administrative credential, etc.

Web application C_002 OCS Front-

Office

Module that provide an electronic form for EU citizens to sign up for an on going Citizen Initiative as a way of expressing their supports for that initiative.

Web Application C_003 OCS Back-

Office

Module used by initiative organisers for the follow-up of signatures, reporting, monitoring and exporting the collected data to the certifying authorities.

Now is possible to identify the Macrodatas that are a homogenous set of data regarding seriousness of the impact, semantic affinity, purpose of treatment, technological processing needs as defined by MIGRA Methodology.


Macrodata Code

Macrodata Name Macrodata Description

M_001 XML Initiative Detail

Collection of data used to define Initiative details: title, subject, description, registration number, date of registration, information about Organiser and contact person, etc.

M_002 Citizens' Personals Data

Collection of data about citizens: first name, family name, father's name, permanent residence information, country, date and place of birth, document ID number, etc.

M_003 Administrative Credential

Credential used to access to OCS administrative module.

Macrodatas and Components are the elements that mixed together create the "risk assessment model". Below the reference scheme of the model used for the risk analysis:

OCS Database



Administrative Credential

OCS Front Office



OCS Back Office


Administrative Credential


6.2. Information and Components Classification

Using the Risk Assessment Model defined in the previous paragraph is now necessary to proceed with the classification step. As expected by the Methodology, components criticality estimation is indirectly made through the evaluation of the macrodata processed. In this way the component inherits macrodata criticality, estimated through the parameters Confidentiality, Integrity and Availability, respecting the “worst case” logic. Macrodata classification process allows getting the information criticality for each security attribute (Confidentiality, Integrity and Availability). Three information criticality classes, one for each security attribute, are the output of that process. The criticality is expressed through qualitative terms by a set of three elements that can assume the following value: high, medium, low, null. To doing the macrodata classification we use the questionnaire that the European Commission defined in methodology and chosen for the OCS risk analysis. For each macrodata are reported below the filled questionnaires completed of each detail. Is important specify that the answers to questionnaires are an average of different answers formulated by different persons interviewed during the risk assessment. In any case the detailed filled questionnaires of each person are reported in Annex A.


MACRODATUM: XML INITIATIVE DETAIL Code: M_001 Impact estimate

Parameters N. Queries N/A low medium high 1 Unauthorized access to personal data

2 Loss of competitiveness

3 Blackmailing and/or external retaliation

Confidentiality









Availability



MACRODATUM: CITIZENS' PERSONAL DATA Code: M_002 Impact estimate




Confidentiality









Availability



MACRODATUM: ADMINISTRATIVE CREDENTIAL Code: M_003 Impact estimate




Confidentiality









Availability


Analyzing the answers done is possible to observe that for each security parameter there is a question not applicable to the context. In particular the following questions are not applicable to the OCS risk analysis:

• N. 2 – Loss of competitiveness • N. 6 – Alteration of the administrative and accounting process • N. 11 – Breach of legal obligations concerning data storage

For these reasons, to correctly evaluate the answers done is opportune to review the Criticality threshold table in order to avoid doing a lower estimation of macrodatas criticality. Following the new table:

Criticality class Class range Null/Not Applicable 0 ≤ p < 37

Low 37 ≤ p < 112 Medium 112 ≤ p < 225

High 225 ≤ p


Using these answers and applying the algorithm for the calculation of the macrodata criticality class is possible to obtain the following results: Macrodatas Classification Macrodata Code Macrodata Name C I A

M_001 XML Initiative detail 25 225 75 M_002 Citizens' personal data 300 175 175 M_003 Administrative credential 200 175 150

In the table the letters C, I, A respectively stands for Confidentiality, Integrity, Availability, and the colours represent the criticality class:

• white = null/not applicable • green = low • yellow = medium • red = high

Using macrodata classification results and applying the inheritance algorithm to the Risk Assessment Model, is possible to define the criticality class of each component estimating the security parameters Confidentiality, Integrity and Availability, respecting the “worst case” logic. The following table summarizes these results: Components Classification Component Code Component Name C I A

C_001 OCS Database High High High C_002 OCS Front-Office High High High C_003 OCS Back-Office Medium High Medium

6.3. Estimation of the exposure to threat

Before performing the Risk Analysis it is necessary to estimate the threats/attacks exposure level for each component. Conforming to the STRIDE method explain in the methodology and having as reference the OWASP top ten vulnerabilities and the ISO 27001 security standard, is possible to identify the following threats. For every threat is reported:


• a short description that explain how the threat works • the STRIDE classification that specify which kind of consequences

are possible if the threat is performed • the list of components exposed to the threat

In particular are treated firstly all the Top 10 vulnerabilities/threats and following other specific threats that are applicable to the context. About the Top 10 vulnerabilities we anticipate that is possible that some of these are not applicable to the context/scope of the risk analysis. In this case is reported the reason that explain why the threat is non applicable. Injection (OWASP Top 10) Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data.

• SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server.

• This threat is applicable to the following components: o C_001 – OCS Database o C_002 – OCS Front-Office o C_003 – OCS Back-Office

Cross-Site Scripting (XSS) (OWASP Top 10) A Cross Site Scripting (XSS) occurs whenever an application takes data that originates from a user or program and sends it to the browser without validating or encoding the data. XSS allows hackers to execute scripts in the victim’s browser, which can hijack user sessions, deface web sites, redirect the user to malicious sites, or conduct phishing attacks.

• Cross-Site Scripting attacks are a type of injection problem and allow attacker to tamper with existing data

• This threat is applicable to the following components: o C_002 – OCS Front-Office o C_003 – OCS Back-Office

Broken Authentication and Session Management (OWASP Top 10) When application functions related to authentication and session management are not implemented correctly, hackers may be able to


compromise passwords, keys, and session tokens, or exploit other implementation flaws to assume other users’ identities. A session hijacking occurs when a hacker takes control of a user session after successfully obtaining or generating an authentication session ID. This is done by using captured, brute-forced or reverse-engineered session IDs to seize control of a legitimate user’s Web application session while that session is still in progress.

• Broken Authentication and Session Management attack allows attackers to spoof identity, tamper with existing data, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the application and database.

• This threat is applicable to the following components: o C_003 – OCS Back-Office

Insecure Direct Object References exploitation (OWASP Top 10) A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check, or other protection, hackers can manipulate these references to access unauthorized data.

• Normally this kind of threat is performed by "Path Traversal" attacks. Using these techniques is possible to access files and directories that are stored outside the web root folder. By browsing the application, the attacker looks for absolute links to files stored on the web server. By manipulating variables that reference files with “dot-dot-slash (../)” sequences and its variations, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration and critical system files, limited by system operational access control. This attack is also known as “dot-dot-slash”, “directory traversal”, “directory climbing” and “backtracking”.


Cross-Site Request Forgery (CSRF) (OWASP Top 10) A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.


• This threat is not applicable in to Risk Analysis Perimeter analyzed. To perform a CSRF attack is necessary also use social engineering techniques to force the users of a web application to execute actions of the attacker's choosing. The scope of the Risk Analysis doesn't include "users", "administrator" and in general "person" that use the application, but is focused only to analyse the web application.

Security Misconfiguration exploitation (OWASP Top 10) Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. All these settings should be defined, implemented, and maintained as many are not shipped with secure defaults. This includes keeping all software up to date, including all code libraries used by the application.

• This threat is not applicable in to Risk Analysis Perimeter analyzed because the configuration of server, database, web services, etc. are excluded by the scope of the analysis. This threat will be applicable in other risk analysis that include not only the application but also the system and the environment where the application is deployed.

Insecure Cryptographic Storage exploitation (OWASP Top 10) Many web applications do not properly protect sensitive data, such as personal data, authentication credentials, etx. with appropriate encryption or hashing. Attackers may steal or modify such weakly protected data to conduct identity theft or other crimes.

• Insecure Cryptographic Storage allows attackers to spoof identity, tamper with existing data, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable.


Failure to Restrict URL Access (OWASP Top 10) Many web applications check URL access rights before rendering protected links and buttons. However, applications need to perform similar access control checks each time these pages are accessed, or attackers will be able to forge URLs to access these hidden pages anyway.

• Insecure Cryptographic Storage allows attackers to spoof identity, tamper with existing data, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable.

• This threat is applicable to the following components:


o C_003 – OCS Back-Office Insufficient Transport Layer exploitation (OWASP Top 10) Applications frequently fail to authenticate, encrypt, and protect the confidentiality and integrity of sensitive network traffic. When they do, they sometimes support weak algorithms, use expired or invalid certificates, or do not use them correctly.

• Insufficient TLS exploitation could allows attackers to spoof identity, tamper with existing data, allows the complete disclosure of all data on the system if the credentials are discovered.


Unvalidated Redirects and Forwards exploitation (OWASP Top 10) Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.

• This kind of threat is possible if, for example, the application may give the attacker the ability to overwrite a specified file or run with a configuration controlled by the attacker. In this case the problem is referable how configure the web service and which kind of "permission" are set. For this reason the threat is to consider non applicable to the scope of the analysis.

Brute force attack During this type of attack, the attacker is trying to bypass security mechanisms while having minimal knowledge about them. Using one or more accessible methods: dictionary attack (with or without mutations), brute-force attack (with given classes of characters e.g.: alphanumerical, special, case (in)sensitive) the attacker is trying to achieve his/her goal. Considering a given method, number of tries, efficiency of the system, which conducts the attack and estimated efficiency of the system which is attacked, the attacker is able to calculate how long the attack will have to last.

• Brute force attack allows attackers to spoof identity, tamper with existing data, allows the complete disclosure of all data on the system if the credentials are discovered.



Cryptoanalysis Cryptanalysis is a process of finding weaknesses in cryptographic algorithms and using these weaknesses to decipher the ciphertext without knowing the secret key (instance deduction). Sometimes the weakness is not in the cryptographic algorithm itself, but rather in how it is applied that makes cryptanalysis successful.

• Cryptoanalysis attack allows attackers to spoof identity, tamper with existing data, allows the complete disclosure of all data on the system if the credentials are discovered.


Network Eavesdropping Network Eavesdropping or network sniffing is a network layer attack consisting of capturing packets from the network transmitted by others' computers and reading the data content in search of sensitive information like passwords, session tokens, or any kind of confidential information.

• Network Eavesdropping allows attackers to spoof identity, tamper with existing data, allows the complete disclosure of all data on the system if the credentials are discovered.


Unauthorized access Unauthorized access represent a "generic" form of threat by means of is possible to accede to application or database and collect information ad data in unauthorized manner. This is possible performing different types of attacks that permit to discover user/administrator credentials, to bypass the authentication form, to accede directly to the database, etc.

• Unauthorized access if performed allows attackers to spoof identity, tamper with existing data, allows the complete disclosure of all data on the system if the credentials are discovered.

• This threat is applicable to the following components: o C_001 – OCS Database o C_003 – OCS Back-Office


Application failure Application failure can compromise information security causing disruption of service, loss of information, loss of integrity, etc. This normally is caused by mistakes committed in application development or due to a superficial application test.

• Application failure, if performed, firstly can provoke denial of service and also can allows attackers to spoof identity, tamper with existing data, allows the complete disclosure of all data on the system.



For having a complete overviews the following table summarize the applicability of threats to each component.

Threat identification Components

Threats OCS Database

OCS Front Office

OCS Back Office

Injection Cross-Site Scripting (XSS) - Broken Authentication and Session Management - -

Insecure Direct Object References exploitation - -

Cross-Site Request Forgery (CSRF) - - -

Security Misconfiguration exploitation - - -


Failure to Restrict URL Access - -

Insufficient Transport Layer exploitation -

Unvalidated Redirects and Forwards exploitation - - -

Brute Force Attack - - Cryptoanalysis Network Eavesdropping - Unauthorized access - Application failure


After this analysis, necessary to individuate pertinent threats/attacks to Risk Analysis Perimeter, the following step is to evaluate each threat for each component. To do this the methodology proposes a DREAD approach that consists in the evaluation of following parameters:

• Damage Potential • Reproducibility • Exploitability • Affected Users • Discoverability

Before proceed with the threat evaluation is important to specify better how DREAD is applicable to the context e how the evaluation will be done. First of all a risk analysis methodology when is applied to an application imply to distinguish if the application is "in production" (so is already on-line, is operative, is used by users) or is "not deployed". In the last case the analysis is focused to the application architecture, to the data flow and to the choices performed to develop the application in a security manner. So is not important how the application environment is managed, which are the security risks to the other elements such as operative system, hardware availability and reliability, but is focused only to the application.

In this context is impossible to determine specific threats exposures depending on environmental factor, context where the application will be deploy, international interests to specific information or themes treated, etc. What is possible to do is to analyze the context with a statistical approach using trend and statistical analysis (for example of OWASP, WASC – Web Application Security Consortium, CERT Cyber Security Bulletin, etc.).

Using these statistical analysis, applied to the DREAD approach, is possible to determine and estimate threats exposure.

In the following table is reported the result of threat evaluation, taking in to consideration these parameters:

Damage Potential • If a threat exploit occurs, how much damage will be caused?

o 0 = Nothing o 5 = Individual user data is compromised or affected. o 10 = Complete system or data destruction


Reproducibility • How easy is it to reproduce the threat exploit?

o 0 = Very hard or impossible, even for administrators of the application.

o 5 = One or two steps required, may need to be an authorized user.

o 10 = Just a web browser and the address bar is sufficient, without authentication.

Exploitability

• What is needed to exploit this threat? o 0 = Advanced programming and networking knowledge,

with custom or advanced attack tools. o 5 = Malware exists on the Internet, or an exploit is easily

performed, using available attack tools. o 10 = Just a web browser

Affected Users

• How many users will be affected? o 0 = None o 5 = Some users, but not all o 10 = All users

Discoverability

• How easy is it to discover this threat? o 0 = Very hard to impossible; requires source code or

administrative access. o 5 = Can figure it out by guessing or by monitoring network

traces. o 9 = Details of faults like this are already in the public domain

and can be easily discovered using a search engine. o 10 = The information is visible in the web browser address

bar or in a form.


Threat evaluation

Components OCS Database OCS Front Office OCS Back Office Threats

D R E A D D R E A D D R E A DInjection 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10Cross-Site Scripting (XSS) 10 10 10 10 10 10 10 10 10 10Broken Authentication and Session Management 10 10 10 10 10

Insecure Direct Object References exploitation 10 10 10 10 10

Insecure Cryptographic Storage exploitation 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10

Failure to Restrict URL Access 10 10 10 10 10

Insufficient Transport Layer exploitation 0 10 5 10 5 0 10 5 10 5

Brute Force Attack 10 0 5 10 0 Cryptoanalysis 10 0 0 10 0 10 0 0 10 0 10 0 0 10 0 Network Eavesdropping 0 10 5 10 5 0 10 5 10 5 Unauthorized access 10 0 0 10 0 10 0 0 10 0 Application failure 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10

Applying the algorithm described in the methodology is possible to obtain the following results:

• Risk_DREAD: looking at the number result. This number derives by adding the value of the previous table and dividing the result by 5.

• Threat Exposure Level: looking at the color of the single cells. The colors are defined according to the table conversion described in the methodology, and considering:

o white = null/not applicable o green = low o yellow = medium o red = high


Risk DREAD and Threat Exposure Level

Components Threats OCS

Database OCS Front

Office OCS Back

Office Injection 10 10 10 Cross-Site Scripting (XSS) n.a. 10 10 Broken Authentication and Session Management n.a n.a 10

Insecure Direct Object References exploitation n.a. n.a. 10

Insecure Cryptographic Storage exploitation 10 10 10

Failure to Restrict URL Access n.a n.a 10

Insufficient Transport Layer exploitation n.a 6 6

Brute Force Attack n.a n.a 5 Cryptoanalysis 4 4 4 Network Eavesdropping n.a 6 6 Unauthorized access 4 n.a 4 Application failure 10 10 10 Before proceed to risk estimation is necessary define also the pertinences of each threat. This consists to define which security parameters (Confidentiality, Integrity and Availability) are compromised if a specific threat is performed. To do this is convenient to evaluate the impact of each threat and determine if Confidentiality, Integrity and Availability are affected. In the following table the check symbol put in evidence the pertinence of threats to each security parameter.

Threat pertinence Components Threats

C I A Injection Cross-Site Scripting (XSS) Broken Authentication and Session Management

Insecure Direct Object References exploitation


Insecure Cryptographic Storage exploitation Failure to Restrict URL Access Insufficient Transport Layer exploitation Brute Force Attack Cryptoanalysis Network Eavesdropping Unauthorized access Application failure

6.4. Risk estimation

The risk is the logical product between the probability that an event will occur and the consequent harm during a fixed time period. For each component is estimated a risk level correlated to each threat. For this reason the risk level is a function of:

• Asset value, represented by component criticality; • Threat exposure level.

Using "Risk Matrix" is possible to determine the "intrinsic risk" that represents the risk without considerate the countermeasures. This is the first step of risk calculation; the next one will be possible after the countermeasures analysis. So, applying "Risk Matrix" the intrinsic risk associated to each component and each threat is the following one.

OCS Database Intrinsic Risk Threats

C_Risk I_Risk A_Risk Threat_Risk Injection 3 3 6 Insecure Cryptographic Storage exploitation 3 3 6

Cryptoanalysis 2 2 4 Unauthorized access 2 2 2 6 Application failure 3 3 3 9 Component Risk 13 13 5 Tot. 31


OCS Front Office Intrinsic Risk Threats

C_Risk I_Risk A_Risk Threat_Risk Injection 3 3 6 Cross-Site Scripting (XSS) 3 3 6 Insecure Cryptographic Storage exploitation 3 3 6

Insufficient Transport Layer exploitation 3 3 6

Cryptoanalysis 2 2 4 Network Eavesdropping 3 3 Application failure 3 3 3 9 Component Risk 20 17 3 Tot. 40

OCS Back Office Intrinsic Risk Threats

C_Risk I_Risk A_Risk Threat_Risk Injection 3 3 6 Cross-Site Scripting (XSS) 3 3 6 Broken Authentication and Session Management 3 3 3 9

Insecure Direct Object References exploitation 3 3 6

Insecure Cryptographic Storage exploitation 3 3 6

Failure to Restrict URL Access 3 3 6

Insufficient Transport Layer exploitation 2 3 5

Brute Force Attack 2 3 5 Cryptoanalysis 1 2 3 Network Eavesdropping 2 2 Unauthorized access 1 2 1 4 Application failure 3 3 3 9 Component Risk 29 31 7 Tot. 67 Adding the total risk of each component is possible to determine the Intrinsic Risk Level of the Online Collection Software:

OCS_IntrinsicRisk = 138 risk units = 100% of OCS risk


In the following chart is graphically represented the contribution of each Component to OCS Intrinsic Risk.

48,5%OCS BACK

OFFICE

22,5%OCS DATABASE

29%OCS FRONT

OFFICE

6.5. Countermeasures identification and Protection Profile definition

To reduce Intrinsic Risk firstly is necessary to proceed to countermeasure identification steps. To do this the analysis takes in consideration these following documents:



techniques — Code of practice for information security management

• ISO/IEC 27001:2005 - Information technology — Security techniques — Information security management systems — Requirements



Countermeasure Identification

Threats Countermeasures Source and for more details

The system is free of any injection flaws such as Structured Query Language (SQL) queries, Lightweight Directory Access Protocol (LDAP) queries, XML Path Language (XPath) queries, Operating System (OS) commands or program arguments.

TS – point 2.7.1

All user input is validated. TS– point 2.7.1.a Data input to applications should be validated to ensure that this data is correct and appropriate.

ISO/IEC 27001:2005 Control 12.1.1 – Input data validation

Validation is performed at least by the server-side logic.

TS – point 2.7.1.b

All use of interpreters clearly separates untrusted data from the command or query. For SQL calls, this means using bind variables in all prepared statements and stored procedures, and avoiding dynamic queries.

TS – point 2.7.1.c

Use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.

CWE-89: Improper Neutralization of Special Elements used in an SQL Command

Process SQL queries using prepared statements, parameterized queries, or stored procedures. These features should accept parameters or variables and support strong typing. Do not dynamically construct and execute query strings within these features using "exec" or similar functionality, since you may re-introduce the possibility of SQL injection.


Injection

Run your code using the lowest privileges that are required to accomplish the necessary tasks. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment.



When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.


Ensure that error messages only contain minimal details that are useful to the intended audience, and nobody else. The messages need to strike the balance between being too cryptic and not being cryptic enough. They should not necessarily reveal the methods that were used to determine the error. Such detailed information can be used to refine the original attack to increase the chances of success. If errors must be tracked in some detail, capture them in log messages - but consider what could occur if the log messages can be viewed by attackers. Avoid recording highly sensitive information such as passwords in any form. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a username is valid or not. In the context of SQL Injection, error messages revealing the structure of a SQL query can help attackers tailor successful attack strings.


All user supplied input sent back to the browser is verified to be safe (via input validation).

TS – point 2.7.2.a

All user input is properly escaped before it is included in the output page.

TS – point 2.7.2.b)

Proper output encoding ensures that such input is always treated as text in the browser. No active content is used.

TS – point 2.7.2.c)

Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application.

CWE-79: Improper Neutralization of Input During Web Page Generation

Cross-Site Scripting (XSS)

To help mitigate XSS attacks against the CWE-79: Improper


user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie.

Neutralization of Input During Web Page Generation

The system has strong authentication and session management

TS – point 2.7.3

Credentials are always protected when stored using hashing or encryption.


Credentials cannot be guessed or overwritten through weak account management functions (e.g. account creation, change password, recover password, weak session identifiers (IDs)).


Session IDs and session data are not exposed in the Uniform Resource Locator (URL).


Session ID is never disclosed other in cookie headers, error messages, or logs.

OWASP ASVS – V3.6

Session IDs are not vulnerable to session fixation attacks.

TS – point 2.7.3.d

Session IDs timeout, which ensures that users log out.

TS – point 2.7.3.e

Session IDs are not rotated after successful login.

TS – point 2.7.3.f

Session ID is changed on login and on reauthentication.

OWASP ASVS – V3.7 –V3.8

Passwords, session IDs, and other credentials are sent only over Transport Layer Security (TLS).

TS – point 2.7.3.g

All password fields do not echo the user’s password when it is entered, and that password fields (or the forms that contain them) have auto complete disabled

OWASP ASVS – V2.2

Authentication and Session Management

Sessions timeout after an administratively-configurable maximum time period regardless of activity (an absolute timeout).

OWASP ASVS – V3.4

The system does not have insecure direct object references.

TS – point 2.7.4

For direct references to restricted resources, the application verifies that the user is authorized to access the exact resource requested.



If the reference is an indirect reference, the TS – point 2.7.4.b


mapping to the direct reference is limited to values authorized for the current user. Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.

CWE-639: Authorization Bypass Through User-Controlled Key

Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering


Make sure that directory browsing is disabled unless deliberately desired

OWASP ASVS – V4.5

Make sure that limitations on input and access imposed by the business on the application (such as transaction limits or sequencing of tasks) cannot be bypassed.


Make sure that all access control decisions can be logged and all failed decisions are logged.


Personal data in electronic format is encrypted when stored or transferred to the competent authorities of the Member States in accordance with Article 8 (1) of Regulation (EU) No 211/2011, the keys being managed and backed up separately.


Strong standard algorithms and strong keys are used in line with the recommendations of ECRYPT II. Key management is in place.


Passwords are hashed with a strong standard algorithm and an appropriate salt is used.


Passwords should be encrypted with keys that are at least 128 bits in length for adequate security

CWE-261: Weak Cryptography for Passwords

All keys and passwords are protected from unauthorized access.


Administrative credentials, personal data collected from signatories and its backup are secured via strong encryption algorithms.

TS – point 2.11


Signatories' personal data are only available in the system in encrypted format. For the purpose of data consultation or certification by the national authorities in accordance with Article 8 of Regulation (EU) No 211/2011, organisers may export the encrypted data.

TS – point 2.13


Clearly specify which data or resources are valuable enough that they should be protected by encryption. Require that any transmission or storage of this data/resource should use well-vetted encryption algorithms.

CWE-311: Missing Encryption of Sensitive Data

Compartmentalize your system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.




The cryptographic security policy should be contains at least following information:

• Definition of Cryptographic Module Security Policy

• Purpose of Cryptographic Module Security Policy

• Specification of a Cryptographic Module Security Policy

• Identification and Authentication Policy

• Access Control Policy • Physical Security Policy • Mitigation of Other Attacks Policy


Key management should be in place to support the organization’s use of cryptographic techniques.

ISO/IEC 17799:2005 ISO/IEC 27001:2005 Control 12.3.2 – Key Management

Make sure that cryptographic module failures are logged.

OWASP ASVS – V7.5

If external security mechanisms are used to provide authentication and authorization checks for page access, they need to be properly configured for every page.


If code level protection is used, code level protection needs to be in place for every required page.


Failure to Restrict URL Access

Make sure that the access control mechanism is enforced correctly at the server side on

CWE-285: Improper Authorization


every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page. One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page. The system requires the most current version of the Hypertext Transfer Protocol Secure (HTTPS) to access any sensitive resource using certificates that are valid, not expired, not revoked, and match all domains used by the site.


The system sets the 'secure' flag on all sensitive cookies.


The server configures the TLS provider to only support encryption algorithms in line with best practices. The users are informed that they must enable TLS support in their browser.


Make sure that TLS is used for all connections (including both external and backend connections) that are authenticated or that involve sensitive data or functions.


Encrypt the data with a reliable encryption scheme before transmitting.

CWE-319: Cleartext Transmission of Sensitive Information

Insufficient Transport Layer exploitation

When using web applications with SSL, use SSL for the entire session from login to logout, not just for the initial login page



OWASP ASVS – V2.3


OWASP ASVS – V2.7

Brute Force Attack

The administration part of the system is protected. If it is protected by single factor authentication, then the password is composed of a minimum of 10 characters, including at least one letter, one number and one special character. Alternatively two-

TS – point 2.7.3.h


factor authentication may be used. Select a well-vetted algorithm that is currently considered to be strong by experts in the field, and select well-tested implementations. As with all cryptographic mechanisms, the source code should be available for analysis.

CWE-327: Use of a Broken or Risky Cryptographic Algorithm

Design your software so that you can replace one cryptographic algorithm with another. This will make it easier to upgrade to stronger algorithms.


Cryptoanalysis

Periodically ensure that you aren't using obsolete cryptography. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong


Administrator access to the management interface of the online collection system has a short session time-out (maximum 15 minutes).

TS – point 2.19.3 Network Eavesdropping

Implement a secure channel, such as SSL, to exchange sensitive information, to prevents possibilities for an attacker with access to the network traffic to sniff packets from the connection and uncover the data


Signatories only have access to the data submitted during the session in which they complete the statement of support form. Once the statement of support form is submitted the above session is closed and the submitted data is not accessible anymore.

TS – point 2.12

Where online collection systems used for different citizens' initiatives share hardware and operating system resources, they do not share any data, including access/encryption credentials. In addition, this is reflected in the risk assessment and in the implemented countermeasures.

TS – point 2.8

The data provided by the signatories is only accessible to the database administrator.

TS – point 2.10

Applications run with the lowest set of privileges that they require to run.

TS – point 2.19.2

Unauthorized access

A database activity log is in place. The system makes sure that audit logs recording

TS – point 2.16


exceptions and other security-relevant events listed below may be produced and kept until the data is destroyed in accordance with Article 12(3) or (5) of Regulation (EU) No 211/2011. Logs are adequately protected, for instance by storage on encrypted media. Organisers/administrators regularly check the logs for suspicious activity. Log contents include at least a) Dates and times for log-on and log-off by organisers/administrators; b) Performed backups; c) All database administrator changes and updates. Make sure that each log event includes:

• a time stamp from a reliable source, • severity level of the event, • an indication that this is a security

relevant event (if mixed with other logs),

• the identity of the user that caused the event (if there is a user associated with the event),

• the source IP address of the request associated with the event,

• whether the event succeeded or failed, and

• a description of the event.

OWASP ASVS – V8.6


OWASP ASVS – V8.8



Data protection and privacy should be ensured as required in relevant legislation, regulations, and, if applicable, contractual clauses.

ISO/IEC 17799:2005 ISO/IEC 27001:2005 Control 15.1.4 - Data protection and privacy of personal information






The persistence of the data entered in the statement of support form is atomic. That is, once the user has entered all required details in the statement of support form, and validates his/her decision to support the initiative, the system either successfully commits all of the form data to the database, or, in case of error, fails by saving no data at all. The system informs the user of the success or failure of his/her request.

TS – point 2.14

Validation checks should be incorporated into applications to detect any corruption of information through processing errors or deliberate acts.

ISO/IEC 17799:2005 ISO/IEC 27001:2005 Control 12.2.2 – Control of internal processing

Requirements for ensuring authenticity and protecting message integrity in applications should be identified, and appropriate controls identified and implemented.

ISO/IEC 17799:2005 ISO/IEC 27001:2005 Control 12.2.3 – Message integrity

Data output from an application should be validated to ensure that the processing of stored information is correct and appropriate to the circumstances.

ISO/IEC 17799:2005 ISO/IEC 27001:2005 Control 12.2.4 – Output data validation





Application failure



To calculate the residual risk is necessary preliminarily analyze each countermeasure and defining the status using one of the following options:

Implemented: the countermeasure is already implemented/installed as Risk Analysis requires

Not Implemented: the countermeasure is not yet implemented/installed


Accepted risk: the risk is accepted and the countermeasure is not installed/implemented because its cost is higher than the specific contribution given to the Perimeter security

Planned: the countermeasure is not yet installed but its installation is planned

Not applicable: the countermeasure is not applicable in the considered environment.

In the following table are reported all countermeasures status, after having collected all information by "OCS development team".

STATUS OCS RISK ANALYSIS COUNTERMEASURE STATUS EVALUATION

AND RESIDUAL RISK CALCULATION

Threats Countermeasures Source and for

more details

Impl

emen

ted

Not

Impl

emen

ted

Acc

epte

d ri

sk

Plan

ned

Not

app

licab

le

Injection The system is free of any injection flaws such as Structured Query Language (SQL) queries, Lightweight Directory Access Protocol (LDAP) queries, XML Path Language (XPath) queries, Operating System (OS) commands or program arguments.

TS – point 2.7.1

x

Injection All user input is validated. TS– point 2.7.1.a x

Injection Data input to applications should be validated to ensure that this data is correct and appropriate.


x

Injection Validation is performed at least by the server-side logic.

TS – point 2.7.1.b x

Injection All use of interpreters clearly separates untrusted data from the command or query. For calls, this means using bind variables in all prepared statements and stored procedures, and avoiding dynamic queries.


x


Injection Use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.


x

Injection Process SQL queries using prepared statements, parameterized queries, or stored procedures. These features should accept parameters or variables and support strong typing. Do not dynamically construct and execute query strings within these features using "exec" or similar functionality, since you may re-introduce the possibility of SQL injection.


x

Injection Run your code using the lowest privileges that are required to accomplish the necessary tasks. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment.


x

Injection When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.


x


Injection Ensure that error messages only contain minimal details that are useful to the intended audience, and nobody else. The messages need to strike the balance between being too cryptic and not being cryptic enough. They should not necessarily reveal the methods that were used to determine the error. Such detailed information can be used to refine the original attack to increase the chances of success. If errors must be tracked in some detail, capture them in log messages - but consider what could occur if the log messages can be viewed by attackers. Avoid recording highly sensitive information such as passwords in any form. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a username is valid or not. In the context of SQL Injection, error messages revealing the structure of a SQL query can help attackers tailor successful attack strings.


x



TS – point 2.7.2.a x



TS – point 2.7.2.b) x



TS – point 2.7.2.c) x




x



To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie.


x

Broken Authentication and Session Management


TS – point 2.7.3

x




x




x




x



OWASP ASVS – V3.6

x




x




x




x


Session ID is changed on login and on reauthentication.

OWASP ASVS – V3.7 –V3.8 x





x



OWASP ASVS – V2.2

x



OWASP ASVS – V3.4

x



TS – point 2.7.4

x




x


If the reference is an indirect reference, the mapping to the direct reference is limited to values authorized for the current user.


x


Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.


x




x



OWASP ASVS – V4.5

x




x




x





x




x




x



CWE-261: Weak Cryptography for Passwords

x




x


Administrative credentials, personal data collected from signatories and its backup are secured via strong encryption algorithms.

TS – point 2.11

x



TS – point 2.13

x



CWE-311: Missing Encryption of Sensitive Data x








x


The cryptographic security policy should be contains at least following information:- Definition of Cryptographic Module Security Policy - Purpose of Cryptographic Module Security Policy - Specification of a Cryptographic Module Security Policy - Identification and Authentication Policy - Access Control Policy - Physical Security Policy - Mitigation of Other Attacks Policy


x


Key management should be in place to support the organization’s use of cryptographic techniques


x



OWASP ASVS – V7.5

x




x






Make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page. One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.


x


The system requires the most current version of the Hypertext Transfer Protocol Secure (HTTPS) to access any sensitive resource using certificates that are valid, not expired, not revoked, and match all domains used by the site.


x




x




x




x




x




x

Brute Force Attack


OWASP ASVS – V2.3 x


Brute Force Attack


OWASP ASVS – V2.7

x

Brute Force Attack

The administration part of the system is protected. If it is protected by single factor authentication, then the password is composed of a minimum of 10 characters, including at least one letter, one number and one special character. Alternatively two-factor authentication may be used.


x

Cryptoanalysis Select a well-vetted algorithm that is currently considered to be strong by experts in the field, and select well-tested implementations. As with all cryptographic mechanisms, the source code should be available for analysis.


x

Cryptoanalysis Design your software so that you can replace one cryptographic algorithm with another. This will make it easier to upgrade to stronger algorithms.


x

Cryptoanalysis Periodically ensure that you aren't using obsolete cryptography. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong

CWE-327: Use of a Broken or Risky Cryptographic Algorithm x

Network Eavesdropping


TS – point 2.19.3

x


Implement a secure channel, such as SSL, to exchange sensitive information, to prevents possibilities for an attacker with access to the network traffic to sniff packets from the connection and uncover the data


Unauthorized access

Signatories only have access to the data submitted during the session in which they complete the statement of support form. Once the statement of support form is submitted the above session is closed and the submitted data is not accessible

TS – point 2.12

x


anymore. Unauthorized access


TS – point 2.8

x

Unauthorized access


TS – point 2.10 x

Unauthorized access


TS – point 2.19.2 x

Unauthorized access

A database activity log is in place. The system makes sure that audit logs recording exceptions and other security-relevant events listed below may be produced and kept until the data is destroyed in accordance with Article 12(3) or (5) of Regulation (EU) No 211/2011. Logs are adequately protected, for instance by storage on encrypted media. Organisers/administrators regularly check the logs for suspicious activity. Log contents include at least a) Dates and times for log-on and log-off by organisers/administrators; b) Performed backups; c) All database administrator changes and updates.

TS – point 2.16

x

Unauthorized access

Make sure that each log event includes: - a time stamp from a reliable source, - severity level of the event, - an indication that this is a security relevant event (if mixed with other logs), - the identity of the user that caused the event (if there is a user associated with the event), - the source IP address of the request associated with the event, - whether the event succeeded or failed, and - a description of the event.

OWASP ASVS – V8.6

x

Unauthorized access




Unauthorized access



x

Unauthorized access



x

Unauthorized access



x

Unauthorized access



x

Application failure


TS – point 2.14

x


Application failure



x

Application failure



x

Application failure



x

Application failure



Application failure



x

Application failure



x

After "Countermeasure evaluation" step is possible to proceed to the Residual Risk calculus. To do this we have estimated the "contribution" of each countermeasure to reduce risk, assuming that all countermeasures have the same "weight". Is important to understand how countermeasures contributing to reduce the risk in correlation with the answer given.

If the countermeasure status is "Implemented" the countermeasure completely contrast the risk, so reducing the residual risk;

If the countermeasure status is "Not Implemented" or "Accepted risk" the countermeasure doesn't contrast the risk, so the residual risk doesn't change;


If the countermeasure status is "Planned" the countermeasure, in this time doesn't contrast the risk, so the residual risk doesn't change, but there's a forecast of reduction in the future;

If the countermeasure status is "Not Applicable" means that the countermeasure is not appropriate to this context. In this case the countermeasure doesn't take in consideration and it is necessary to review the reduction risk contribution of the other countermeasures to re-equilibrate the risk calculus.

In the following table are reported all details of Residual Risk calculation.


STATUS INTRINSIC RISK RESIDUAL RISK OCS RISK ANALYSIS COUNTERMEASURE STATUS

EVALUATION AND RESIDUAL RISK CALCULATION

Threats Countermeasures Source and for more details Im

plem

ente

d

Not

Impl

emen

ted

Acc

epte

d ri

sk

Plan

ned

Not

app

licab

le

NO

TE

OC

S D

atab

ase

OC

S Fr

ont O

ffic

e

OC

S Ba

ck O

ffic

e

OC

S D

atab

ase

OC

S Fr

ont O

ffic

e

OC

S Ba

ck O

ffic

e

Injection The system is free of any injection flaws such as Structured Query Language (SQL) queries, Lightweight Directory Access Protocol (LDAP) queries, XML Path Language (XPath) queries, Operating System (OS) commands or program arguments.

TS – point 2.7.1

x 0,6 0,6 0,6

Injection All user input is validated. TS– point 2.7.1.a x 0,6 0,6 0,6 Injection Data input to applications should

be validated to ensure that this data is correct and appropriate.


x 0,6 0,6 0,6

Injection Validation is performed at least by the server-side logic.

TS – point 2.7.1.b x 0,6 0,6 0,6


Injection All use of interpreters clearly separates untrusted data from the command or query. For the calls, this means using bind variables in all prepared statements and stored procedures, and avoiding dynamic queries.


x 0,6 0,6 0,6

Injection Use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.

CWE-89: Improper Neutralization of Special Elements used in an SQL Command x 0,6 0,6 0,6

Injection Process SQL queries using prepared statements, parameterized queries, or stored procedures. These features should accept parameters or variables and support strong typing. Do not dynamically construct and execute query strings within these features using "exec" or similar functionality, since you may re-introduce the possibility of SQL



injection. Injection Run your code using the lowest

privileges that are required to accomplish the necessary tasks. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment.


Injection When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.


x 0,6 0,6 0,6

Injection Ensure that error messages only contain minimal details that are useful to the intended audience, and nobody else. The messages need to strike the balance between being too cryptic and not being cryptic enough. They should not necessarily reveal the methods that were used to determine the error. Such detailed



information can be used to refine the original attack to increase the chances of success. If errors must be tracked in some detail, capture them in log messages - but consider what could occur if the log messages can be viewed by attackers. Avoid recording highly sensitive information such as passwords in any form. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a username is valid or not. In the context of SQL Injection, error messages revealing the structure of a SQL query can help attackers tailor successful attack strings.

"Injection" Risk 6 6 6 0 0 0 Cross-Site Scripting (XSS)


TS – point 2.7.2.a x 1,2 1,2



TS – point 2.7.2.b)x 1,2 1,2




TS – point 2.7.2.c)

x 1,2 1,2




x 1,2 1,2


To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie.


x 1,2 1,2

"Cross-Site Scripting" Risk 6 6 0 0




TS – point 2.7.3

x

0,75




x

0,75




x

0,75




x

0,75



OWASP ASVS – V3.6

x

0,75




x

0,75





x

0,75




x

0,75


Session ID is changed on login and on re-authentication.

OWASP ASVS – V3.7 –V3.8 x

0,75




x

it's organiser responsibility to configure application server in order to expose secure transport channels only



OWASP ASVS – V2.2

x

0,75



OWASP ASVS – V3.4

x

it's organiser responsibility to configure application server


in order to define session timeout

"Broken Authentication and Session Management" Risk 7,5 0 Insecure Direct Object References exploitation


TS – point 2.7.4

x does not apply for java code










Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.







x

does not apply for java code



OWASP ASVS – V4.5





x

does not apply for java code





"Insecure Direct Object References exploitation" Risk 0 0





x 0,46 0,46 0,46




x 0,46 0,46 0,46




x 0,46 0,46 0,46



CWE-261: Weak Cryptography for Passwords x 0,46 0,46 0,46




x 0,46 0,46 0,46


Administrative credentials, personal data collected from signatories and its backup are secured via strong encryption

TS – point 2.11

x 0,46 0,46 0,46


algorithms. Insecure Cryptographic Storage exploitation


TS – point 2.13

x 0,46 0,46 0,46



CWE-311: Missing Encryption of Sensitive Data x 0,46 0,46 0,46




x 0,46 0,46 0,46

Insecure Cryptographic

A policy on the use of cryptographic controls for

ISO/IEC 17799:2005 x 0,46 0,46 0,46 0,46 0,46 0,46


Storage exploitation

protection of information should be developed and implemented.

ISO/IEC 27001:2005 Control 12.3.1 - Policy on the use of cryptographic controls


The cryptographic security policy should be contains at least following information: - Definition of Cryptographic Module Security Policy - Purpose of Cryptographic Module Security Policy - Specification of a Cryptographic Module Security Policy - Identification and Authentication Policy - Access Control Policy - Physical Security Policy - Mitigation of Other Attacks Policy


x 0,46 0,46 0,46 0,46 0,46 0,46


Key management should be in place to support the organization’s use of cryptographic techniques


x 0,46 0,46 0,46




OWASP ASVS – V7.5

x 0,46 0,46 0,46

"Insecure Cryptographic Storage exploitation" Risk 6,00 6,00 6,00 0,92 0,92 0,92 Failure to Restrict URL Access



x 2



TS – point 2.7.8.b x 2



Make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page. One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.


x 2

"Failure to Restrict URL Access" Risk 6,00 0,00 Insufficient Transport Layer exploitation

The system requires the most current version of the Hypertext Transfer Protocol Secure (HTTPS) to access any sensitive resource using certificates that are valid, not expired, not revoked, and match all domains used by the site.


x

Insufficient Transport Layer




exploitation Insufficient Transport Layer exploitation



x




x




x




x

"Insufficient Transport Layer exploitation" Risk 0,00 0,00 0,00 0,00 Brute Force Attack

The account is locked for a period of time long enough if a maximum number of authentication attempts is

OWASP ASVS – V2.3

x 1,67 1,67


exceeded. Brute Force Attack


OWASP ASVS – V2.7

x 1,67 1,67

Brute Force Attack

The administration part of the system is protected. If it is protected by single factor authentication, then the password is composed of a minimum of 10 characters, including at least one letter, one number and one special character. Alternatively two-factor authentication may be used.


x 1,67

"Brute Force Attack" Risk 5,00 3,33 Cryptoanalysis Select a well-vetted algorithm

that is currently considered to be strong by experts in the field, and select well-tested implementations. As with all cryptographic mechanisms, the source code should be available for analysis.


x 1,33 1,33 1


Cryptoanalysis Design your software so that you can replace one cryptographic algorithm with another. This will make it easier to upgrade to stronger algorithms.


x 1,33 1,33 1

Cryptoanalysis Periodically ensure that you aren't using obsolete cryptography. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong


x 1,33 1,33 1

"Cryptoanalysis" Risk 4,00 4,00 3,00 0,00 0,00 0,00 Network Eavesdropping


TS – point 2.19.3

x

it's organiser responsibility to configure application server in order to define session timeout


Implement a secure channel, such as SSL, to exchange sensitive information, to prevents possibilities for an attacker with access to the network traffic to sniff packets from the connection


it's organiser responsibility to configure application server in order to expose secure transport


and uncover the data channels only "Network Eavesdropping" Risk 0,00 0,00 0,00 0,00 Unauthorized access

Signatories only have access to the data submitted during the session in which they complete the statement of support form. Once the statement of support form is submitted the above session is closed and the submitted data is not accessible anymore.

TS – point 2.12

x 0,55 0,36

Unauthorized access


TS – point 2.8

x 0,55 0,36

Unauthorized access


TS – point 2.10 x 0,55 0,36

Unauthorized access


TS – point 2.19.2 x 0,55 0,36


Unauthorized access


TS – point 2.16

x


Unauthorized access

Make sure that each log event includes: - a time stamp from a reliable source, - severity level of the event, - an indication that this is a security relevant event (if mixed with other logs), - the identity of the user that caused the event (if there is a user associated with the event), - the source IP address of the request associated with the event,- whether the event succeeded or failed, and - a description of the event.

OWASP ASVS – V8.6

x 0,55 0,36 0,55 0,36

Unauthorized access


OWASP ASVS – V8.8 x 0,55 0,36 0,55 0,36

Unauthorized access



x 0,55 0,36 0,55 0,36


Unauthorized access



x 0,55 0,36

Unauthorized access



x 0,55 0,36 0,55 0,36

Unauthorized access



x 0,55 0,36 0,55 0,36

"Unauthorized access" Risk 5,45 3,64 2,73 1,82


Application failure


TS – point 2.14

x 1,29 1,29 1,29

Application failure



x 1,29 1,29 1,29

Application failure



x 1,29 1,29 1,29


Application failure



x 1,29 1,29 1,29

Application failure



x 1,29 1,29 1,29 1,29 1,29 1,29

Application failure



x 1,29 1,29 1,29 1,29 1,29 1,29

Application failure



x 1,29 1,29 1,29 1,29 1,29 1,29

"Application failure" Risk 9,00 9,00 9,00 3,86 3,86 3,86


For having an overall view of results is good to compare Intrinsic and Residual risks using both Threat_Risk view and Component Risk view.

OCS Database Threats Intrinsic

Threat_Risk Residual

Threat_Risk Injection 6 0 Insecure Cryptographic Storage exploitation 6 0,92

Cryptoanalysis 4 0 Unauthorized access 5,45 2,73 Application failure 9 3,86 Component Risk 30,45 7,51

OCS Front Office Threats Intrinsic


Threat_Risk Injection 6 0 Cross-Site Scripting (XSS) 6 0 Insecure Cryptographic Storage exploitation 6 0,92

Insufficient Transport Layer exploitation 0 0

Cryptoanalysis 4 0 Network Eavesdropping 0 0 Application failure 9 3,86 Component Risk 31 4,78

OCS Back Office Threats Intrinsic


Threat_Risk Injection 6 0 Cross-Site Scripting (XSS) 6 0 Broken Authentication and Session Management 9 0

Insecure Direct Object References exploitation 6 0

Insecure Cryptographic Storage exploitation 6 0,92

Failure to Restrict URL Access 6 0


Insufficient Transport Layer exploitation 0 0

Brute Force Attack 5 3,33 Cryptoanalysis 3 0 Network Eavesdropping 0 0 Unauthorized access 3,64 1,82 Application failure 9 3,86 Component Risk 52,14 9,93

Intrinsic

Component Risk

Residual Component

Risk

Percentage Residual

Component RiskOCS Database 30,45 7,51 24,65%

OCS Front Office 31 4,78 15,42% OCS Back Office 52,14 9,93 19,05%

At the end of the analysis is possible to determine the "global" Residual Risk summing together the Residual Risk of each component:

OCS_ResidualRisk= 7,51+4,78+9,93= 22,22


Comparing the OCS_IntrinsicRisk (113,59 risk units) and the OCS_ResidualRisk is possible to determine the Residual Risk Percentage as follow:

=×= 100sicRisk OCS_IntrinalRisk OCS_Residu ualRisk %OCS_Resid 19,56%

In the following charts the details of Residual Risk Percentage of each component.

At the end of this Risk Analysis following is reported the contribution of each Component to OCS Residual Risk.


6.6. Compliance focus

The risk analysis performed allows assessing the levels of compliance compared to the Technical Specification and the Security Standard taken into account. Is important to specify that the levels of compliance is not applicable to all requirements of the Technical Specification or all the "controls" of the Standards, but only for what is taken into account during the analysis. For this reason would be more correct to speak of "partial compliance" with the standards and the Technical Specification. A "complete" compliance assessment is possible to performed only when the application will be deploy and the risk analysis/compliance analysis is done to the entire system, and not only focused to the application "layer". In any case, for the purposes of this risk analysis is also important to assess the overall level of compliance. The compliance analysis is done for each of following references:



techniques — Information security management systems — Requirements


The result is reported in the following table:

Security References % Compliance Technical Specification 100% CWE 100% FIPS PUB 140/2 0,00% ISO/IEC 27001:2005 54,55% OWASP ASVS 40,00%


Is important to notice that OCS is 100% compliant to the Technical Specification. Is important remember that this compliance analysis referring only to the “application level”, that is the scope level of this activity. Is an Organizer task to analyze the entire OCS system in terms of risks and compliance. About the other standards, and in particular ISO 27001/2005 and OWASP ASVS, is suggested to take seriously in consideration to implement what is proposed to contrast "Unauthorized access" and "Application failure". These are the two threats that are less "contrasted" and for this reason the intervention is more priority. About FIPS is possible to assume that performing an attack using "Insecure Cryptographic Storage exploitation" is very improbable, considering the technical characteristics of Cryptographic Algorithm adopted by OCS, so the intervention priority is considerable low.


7. ANNEX A

Date: 2012.01.17 Asset Owner: System Supplier MACRODATUM: XML INITIATIVE DETAIL Code: M_001


1 Unauthorized access to personal data



Confidentiality









Availability



Date: 2012.01.17 Asset Owner: System Supplier MACRODATUM: CITIZENS' PERSONAL DATA Code: M_002





Confidentiality









Availability



Date: 2012.01.17 Asset Owner: System Supplier MACRODATUM: ADMINISTRATIVE CREDENTIAL Code: M_003





Confidentiality









Availability



Date: 2012.01.18 Asset Owner: User Representative MACRODATUM: XML INITIATIVE DETAIL Code: M_001





Confidentiality









Availability



Date: 2012.01.18 Asset Owner: User Representative MACRODATUM: CITIZENS' PERSONAL DATA Code: M_002





Confidentiality









Availability



Date: 2012.01.18 Asset Owner: User Representative MACRODATUM: ADMINISTRATIVE CREDENTIAL Code: M_003





Confidentiality









Availability



8. ANNEX B

Scope of Annex B is to propose to Organiser a security approach to deploy OCS compliant to Security Standards, security best practices and obeying European Commission Regulation. In particular the references which Organisers should be taking in consideration are, at least, the following:

• Commission Implementing Regulation No 1179/2011 of 17 November 2011 – Laying down technical specifications for online collection systems pursuant to Regulation (EU) No 211/2011 of the European Parliament and of the Council on the citizens' initiative;

• Common Weakness Enumeration (CWE) and in particular "potential mitigations" that are proposed to "contrast" a specific threat-vulnerability;

• FIPS PUB 140-2 - Security requirements for cryptographic modules • ISO/IEC 17799:2005 - Information technology — Security

techniques — Code of practice for information security management

• ISO/IEC 27001:2005 - Information technology — Security techniques — Information security management systems — Requirements


Firstly is important to make Organiser aware of before deploy OCS service is necessary perform:

• A specific Risk Analysis to whole system. Risk analysis performed to OCS is only a part of entire system. The Organiser's Risk Analysis should be including also following aspects: hardware, environment, operative system, service configuration, back-up system, etc. This is necessary to having a complete overview to all security needs.

• A detailed Compliance Assessment should be performed to evaluating the system security compliance primarily respect to EC Regulation No 1179/2011 of 17 November 2011, but also respect standards applicable to context: for example ISO27001.

• A detailed Vulnerability Assessment should be performed to analyze vulnerabilities to all system. Vulnerability Assessment, in particular should be performed as white box and black box to simulating intrusion by internal/external attackers.


• A specific Penetration Test is suggested to evaluate how vulnerabilities are exploitable and to indentifying possible attack paths. Penetration test should be also proposing how to remediate to these vulnerabilities to making secure the system.

In addition to these analyzes, the organizers must be confident of putting in place all possible solutions to make sure the entire IT system. To do this is suggested to follow the following guidelines regarding the activities and things to check prior to deploy the OCS platform.

Verify that all requirements defined in the technical specification have been implemented. In particular: A database activity log is in place. The system makes sure that audit logs recording exceptions and other security-relevant events listed below may be produced and kept until the data is destroyed in accordance with Article 12(3) or (5) of Regulation (EU) No 211/2011. Logs are adequately protected, for instance by storage on encrypted media. Organisers/administrators regularly check the logs for suspicious activity. Log contents include at least a) Dates and times for log-on and log-off by organisers/administrators; b) Performed backups; c) All database administrator changes and updates.

TS – point 2.16



The system does not have insecure direct object references. TS – point 2.7.4 For direct references to restricted resources, the application verifies that the user is authorized to access the exact resource requested.




Proper security configuration is in place, which requires, at least, that: a) All software components are up-to-date, including the OS, web/application server, Data Base Management System (DBMS), applications, and all code libraries. b) OS and web/application server unnecessary services are disabled, removed, or not installed. c) Default account passwords are changed or disabled. d) Error handling is set up to prevent stack traces and other overly informative error messages from leaking. e) Security settings in the development frameworks and

TS – point 2.7.6


libraries are configured in accordance with best practices, such as the guidelines of OWASP. The system requires the most current version of the Hypertext Transfer Protocol Secure (HTTPS) to access any sensitive resource using certificates that are valid, not expired, not revoked, and match all domains used by the site.


The system sets the 'secure' flag on all sensitive cookies. TS – point 2.7.9.b The server configures the TLS provider to only support encryption algorithms in line with best practices. The users are informed that they must enable TLS support in their browser.


The DBMS used is up-to-date and continuously patched for newly discovered exploits

TS – point 2.15


TS – point 2.16

Physical security Whatever the type of hosting used, the machine hosting the application is properly protected, which provides: a) Hosting area access control and audit log; c) Physical protection of backup data due to theft or incidental misplacement; d) That the server hosting the application is installed in a secured rack.

TS – point 2.17

The system is hosted on an internet facing server installed on a demilitarized zone (DMZ) and protected by a Firewall.

TS – point 2.18.1

When relevant updates and patches of the Firewall product become public, then such updates or patches are installed expediently.

TS – point 2.18.2

All inbound and outbound traffic to the server (destined to the online collection system) is inspected by the Firewall rules and logged.

TS – point 2.18.3

The online collection system must be hosted on an adequately protected production network segment that is separated from segments used to host non-production

TS – point 2.18.4


systems such as development or testing environments. Local Area Network (LAN) security measures are in place such as: a) Layer 2 (L2) Access list / Port switch security; b) Unused switch ports are disabled; c) The DMZ is on a dedicated Virtual Local Area Network (VLAN)/LAN; d) No L2 trunking enabled on unnecessary ports.

TS – point 2.18.5


TS – point 2.19.3

When relevant updates and patches of the OS, the application runtimes, applications running on the servers, or anti-malware become public, then such updates or patches are installed expediently.

TS – point 2.19.4

Organiser client security For the sake of end-to-end security, the organisers take necessary measures to secure their client application/device that they use to manage and access the online collection system.

TS – point 2.20

Users run non-maintenance tasks (such as office automation) with the lowest set of privileges that they require to run

TS – point 2.20.1

When relevant updates and patches of the OS, any installed applications, or anti-malware become public, then such updates or patches are installed expediently.

TS – point 2.20.2

Verify that at least the security objective proposed by the Standard ISO27001 are implemented. Responsibility for asset All assets should be accounted for and have a nominated owner. Owners should be identified for all assets and the responsibility for the maintenance of appropriate controls should be assigned. The implementation of specific controls may be delegated by the owner as appropriate but the owner remains responsible for the proper protection of the assets.

ISO/IEC 27001:2005 Objective 7.1

Secure Areas Critical or sensitive information processing facilities should be housed in secure areas, protected by defined security perimeters, with appropriate security barriers and entry controls. They should be physically protected from unauthorized access, damage, and interference. The protection provided should be commensurate with the identified risks.


Equipment security ISO/IEC 27001:2005


Equipment should be protected from physical and environmental threats. Protection of equipment (including that used off-site, and the removal of property) is necessary to reduce the risk of unauthorized access to information and to protect against loss or damage. This should also consider equipment siting and disposal. Special controls may be required to protect against physical threats, and to safeguard supporting facilities, such as the electrical supply and cabling infrastructure.

Objective 9.2

Third party service delivery management The organization should check the implementation of agreements, monitor compliance with the agreements and manage changes to ensure that the services delivered meet all requirements agreed with the third party.


System planning and acceptance Advance planning and preparation are required to ensure the availability of adequate capacity and resources to deliver the required system performance. Projections of future capacity requirements should be made, to reduce the risk of system overload. The operational requirements of new systems should be established, documented, and tested prior to their acceptance and use.


Protection against malicious and mobile code Precautions are required to prevent and detect the introduction of malicious code and unauthorized mobile code. Software and information processing facilities are vulnerable to the introduction of malicious code, such as computer viruses, network worms, Trojan horses, and logic bombs. Users should be made aware of the dangers of malicious code. Managers should, where appropriate, introduce controls to prevent, detect, and remove malicious code and control mobile code.


Backup Routine procedures should be established to implement the agreed back-up policy and strategy for taking back-up copies of data and rehearsing their timely restoration.


Network security management The secure management of networks, which may span organizational boundaries, requires careful consideration to dataflow, legal implications, monitoring, and protection.Additional controls may also be required to protect sensitive information passing over public networks.


Media handling ISO/IEC 27001:2005


Media should be controlled and physically protected. Appropriate operating procedures should be established to protect documents, computer media (e.g. tapes, disks), input/output data and system documentation from unauthorized disclosure, modification, removal, and destruction.

Objective 10.7

Exchange of information Exchanges of information and software between organizations should be based on a formal exchange policy, carried out in line with exchange agreements, and should be compliant with any relevant legislation (see clause 15). Procedures and standards should be established to protect information and physical media containing information in transit.


Monitoring Systems should be monitored and information security events should be recorded. Operator logs and fault logging should be used to ensure information system problems are identified. An organization should comply with all relevant legal requirements applicable to its monitoring and logging activities. System monitoring should be used to check the effectiveness of controls adopted and to verify conformity to an access policy model.


User access management Formal procedures should be in place to control the allocation of access rights to information systems and services. The procedures should cover all stages in the life-cycle of user access, from the initial registration of new users to the final de-registration of users who no longer require access to information systems and services. Special attention should be given, where appropriate, to the need to control the allocation of privileged access rights, which allow users to override system controls.


Network access control Access to both internal and external networked services should be controlled. User access to networks and network services should not compromise the security of the network services by ensuring: a) appropriate interfaces are in place between the organization’s network and networks owned by other organizations, and public networks; b) appropriate authentication mechanisms are applied for users and equipment;



c) control of user access to information services in enforced.Operating system access control Security facilities should be used to restrict access to operating systems to authorized users. The facilities should be capable of the following: a) authenticating authorized users, in accordance with a defined access control policy; b) recording successful and failed system authentication attempts; c) recording the use of special system privileges; d) issuing alarms when system security policies are breached; e) providing appropriate means for authentication; f) where appropriate, restricting the connection time of users.


Application and information access control Security facilities should be used to restrict access to and within application systems. Logical access to application software and information should be restricted to authorized users. Application systems should: a) control user access to information and application system functions, in accordance with a defined access control policy; b) provide protection from unauthorized access by any utility, operating system software, and malicious software that is capable of overriding or bypassing system or application controls; c) not compromise other systems with which information resources are shared.


Security requirements of information system Information systems include operating systems, infrastructure, business applications, off-the-shelf products, services, and user-developed applications. The design and implementation of the information system supporting the business process can be crucial for security. Security requirements should be identified and agreed prior to the development and/or implementation of information systems. All security requirements should be identified at the requirements phase of a project and justified, agreed, and documented as part of the overall business case for an information system.


Cryptographic control A policy should be developed on the use of cryptographic controls. Key management should be in place to support the use of cryptographic techniques.


Security of system file Access to system files and program source code should be



controlled, and IT projects and support activities conducted in a secure manner. Care should be taken to avoid exposure of sensitive data in test environments. Technical vulnerability management Technical vulnerability management should be implemented in an effective, systematic, and repeatable way with measurements taken to confirm its effectiveness. These considerations should include operating systems, and any other applications in use.


Reporting information security events and weaknesses Formal event reporting and escalation procedures should be in place. All employees, contractors and third party users should be made aware of the procedures for reporting the different types of event and weakness that might have an impact on the security of organizational assets. They should be required to report any information security events and weaknesses as quickly as possible to the designated point of contact.


Management of information security incidents and improvements Responsibilities and procedures should be in place to handle information security events and weaknesses effectively once they have been reported. A process of continual improvement should be applied to the response to, monitoring, evaluating, and overall management of information security incidents. Where evidence is required, it should be collected to ensure compliance with legal requirements.


Information security aspects of business continuity management A business continuity management process should be implemented to minimize the impact on the organization and recover from loss of information assets (which may be the result of, for example, natural disasters, accidents, equipment failures, and deliberate actions) to an acceptable level through a combination of preventive and recovery controls. This process should identify the critical business processes and integrate the information security management requirements of business continuity with other continuity requirements relating to such aspects as operations, staffing, materials, transport and facilities. The consequences of disasters, security failures, loss of service, and service availability should be subject to a business impact analysis. Business continuity plans should be developed and implemented to ensure timely resumption of essential operations. Information security



should be an integral part of the overall business continuity process, and other management processes within the organization. Business continuity management should include controls to identify and reduce risks, in addition to the general risks assessment process, limit the consequences of damaging incidents, and ensure that information required for business processes is readily available. Compliance with legal requirements The design, operation, use, and management of information systems may be subject to statutory, regulatory, and contractual security requirements. Advice on specific legal requirements should be sought from the organization’s legal advisers, or suitably qualified legal practitioners. Legislative requirements vary from country to country and may vary for information created in one country that is transmitted to another country (i.e. trans-border data flow).


Compliance with security policies and standards, and technical compliance The security of information systems should be regularly reviewed. Such reviews should be performed against the appropriate security policies and the technical platforms and information systems should be audited for compliance with applicable security implementation standards and documented security controls.


Documents

Online Collection Software - Joinup.eu · Online Collection Software Page 13 / 127 Document Version 1.0 dated 14/02/2012 2. INTRODUCTION The main objective of the present document