d6.1.1 security assessment report

Security Assessment Report

Peter Hannay, Zubair Baig, Sean Meyer, Matthew Peacock,Mike Johnstone, Patty Vogel, Aleatha Shanley, Malik Feroze(ECU), Dhouha Ayed, Cyrille Martins (THA), Myrthe van

Delft, Jerry den Hartog (TU/e)

This project has received fundingfrom the European UnionsSeventh Framework Programme forresearch, technological developmentand demonstration under grantagreement no: 611659

FP7-ICT 611659 AU2EU Deliverable D6.1.1

October 21, 2015 Security Assessment Report 2

Project Information

Authentication and Authorisation for Entrusted Unions

Project number: 611659Strategic objective: ICT-2013.1.4.eStarting date: 2013-12-01Ending date: 2015-11-30Website: http://au2eu.eu/

Document Information

Title: Security Assessment ReportID: D6.1.1 Type: R Dissemination level: PU

Month: M22 Release date: 30.September.2015

Deliverable Description

Provides formal validation of security design, as well as practical security validation of theimplementation in the pilots

Contributors, Editor & Reviewer Information

Contributors(persons(partner): Chapters)

Cyrille Martins, Dhouha Ayed(THA): Chapters 4, 5, 6, 8Peter Hannay, Zubair Baig, Sean Meyer, Aleatha Shanley,Mike Johnstone, Patty Vogel(ECU): Chapters 2-4, 6, 8Matthew Peacock, Mike Johnstone, Zubair Baig, Malik Fer-oze(ECU): Chapters 7, 8Jerry den Hartog(TU/e): Chapters 1-5,7,8Myrthe van Delft(TU/e): Chapters 5,8

Editor (person/partner) Jerry den Hartog/TU/eReviewer (person/partner) Dieter Sommer/IBM, John Zic/CSO

http://au2eu.eu/


Release History

Releasenumber

Dateissued

Milestone* SVNversion

Release description / changesmade

0.1 Nov 2014 PCOS First outline, testing plan

0.2 May 2015 PCOS Updated testing documentation

0.3 7-9-2015 Proposed Draft for internal review

0.4 15-9-2015 Revised Updated draft for internal review

1.0 30-9-2015 External Version for submission to the EC

* The project uses a multi-stage internal review and release process, with defined milestones.Milestone names include abbreviations/terms as follows:

1. PCOS: Planned Content and Structure (describes planned contents of different sec-tions);

2. Intermediate: Document is approximately 50% complete review checkpoint;

3. External: For release to commission and reviewers;

4. Proposed: Document authors submit for internal review;

5. Revised: Document authors produce new version in response to internal reviewer com-ments;

6. Approved: Internal project reviewers accept the document;

7. Released: Project Technical Manager/Coordinator release to Commission Services;



AU2EU Consortium

Full Name Abbreviated Name Country

Technische Universiteit Eindhoven TU/e Netherlands

Philips Electronics Nederland B.V. PRE Netherlands

Bicore Services B.V. BIC Netherlands

NEC Europe LTD NEC United Kingdom

IBM Research GMBH IBM Switzerland

Deutsches Rotes Kreuz DRK Germany

Thales Communications & Security SAS THA France

Commonwealth Scientific and IndustrialResearch Organisation

CSO Australia

Edith Cowan University ECU Australia

Royal Melbourne Institute of Technology RMI Australia

University of New South Wales NSW Australia

Macquarie University MQ Australia

Table 1: Consortium Members


Table of Contents

List of Figures 10

List of Tables 11

1 Executive Summary 12

2 About this Document 132.1 Role of the Deliverable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2 Relationship to other AU2EU Deliverables . . . . . . . . . . . . . . . . . . . . . 132.3 Relationship to other Versions of this Deliverable . . . . . . . . . . . . . . . . . 142.4 Structure of this Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Objectives to Secure the Architecture 153.1 High level communication model . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2 Evaluation goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2.2 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2.3 Non-repudiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.4 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.5 Evaluation effecting multiple attributes . . . . . . . . . . . . . . . . . . 183.2.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3 System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Verification, Testing and Monitoring Methodology 214.1 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1.1 Protocol analysis for privacy . . . . . . . . . . . . . . . . . . . . . . . . . 224.1.2 Policy Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2.1 Web Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2.2 Source Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2.3 Communications Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.3 Bug Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3.1 XSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3.2 SQL Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3.3 CSRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3.4 Broken Authentication or Session Management . . . . . . . . . . . . . . 264.3.5 Command Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

7


4.3.6 Insecure Direct Object References . . . . . . . . . . . . . . . . . . . . . 274.3.7 Data Leakage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3.8 Use of vulnerable functions . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.4 Automated Test Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.4.1 IBM Security AppScan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.4.2 Other Automated Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.5 Manual Test Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.5.1 Information System Security Assessment Framework (ISSAF) . . . . . . 304.5.2 Open Web Application Security Project (OWASP) . . . . . . . . . . . . 314.5.3 Test Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.5.4 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.5.5 Enumeration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.5.6 Exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.6 Run-time monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5 Verification 345.1 Protocol analysis for privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.1.1 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.1.2 Use case: Australian Biosecurity Incident Response (BIR) . . . . . . . . 365.1.3 Modeling the AU2EU authentication authorisation protocol . . . . . . . 375.1.4 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.1.5 The TRIPLEX implementation . . . . . . . . . . . . . . . . . . . . . . . 445.1.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2 Policy Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.2.1 AAL Policy Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.2.2 Performance evaluation of the XACML policy validation tool . . . . . . 56

6 Results of Testing 596.1 Auditing of authorisation solution deployed for the pilots . . . . . . . . . . . . . 61

6.1.1 authorisation service security risk analysis . . . . . . . . . . . . . . . . . 616.1.2 Web application scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.1.3 Network scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.1.4 Manual penetration testing . . . . . . . . . . . . . . . . . . . . . . . . . 706.1.5 Security auditing conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 71

7 Security monitoring: Intrusion detection 747.1 Importance of IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747.2 A Semantic Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7.2.1 General Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757.2.2 Instantiation in the AAL domain . . . . . . . . . . . . . . . . . . . . . . 777.2.3 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817.2.4 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827.2.5 Performance Metrics and Evaluation Methods . . . . . . . . . . . . . . . 837.2.6 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837.2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847.2.8 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847.2.9 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85



7.3 A State Based Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857.3.1 Timed Net Condition Event Systems . . . . . . . . . . . . . . . . . . . . 85

7.4 AAL Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877.4.1 T-NCES of AAL Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 887.4.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

7.5 Input Stream Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 927.5.1 Proposed Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 937.5.2 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947.5.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 957.5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967.5.5 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

7.6 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

8 Conclusions and Recommendations 998.1 Relation to the requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 998.2 Testing Challenges, Timeline & Partner Requirements . . . . . . . . . . . . . . 100

8.2.1 ECU Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018.2.2 CSIRO Pilot Timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018.2.3 CSIRO Pilot Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 1018.2.4 DRK Pilot Timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1028.2.5 DRK Pilot Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 102

8.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Bibliography 105

A XACML policy for AAL pilot 108

B TRIPLEX files and usability 140B.1 Protocols files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140B.2 Instantiation file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141B.3 TRIPLEX findings and recommendations . . . . . . . . . . . . . . . . . . . . . 145


List of Figures

3.1 Communications model for gaining access to a protected resource . . . . . . . . 15

5.1 AU2EU protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.2 Australian Biosecurity Incident Response example flow from [12, Figure 2 ] . . . 395.3 AU2EU protocol deployed in the BIR pilot . . . . . . . . . . . . . . . . . . . . . 465.4 Triplex protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.5 Triplex data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.6 Triplex knowledge matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.7 Analysis solution principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.8 XACML Analyzer GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.9 Validating the behavior of the policy . . . . . . . . . . . . . . . . . . . . . . . . 555.10 Validating the completeness of the policy . . . . . . . . . . . . . . . . . . . . . . 565.11 Searching for conflicts in the policy . . . . . . . . . . . . . . . . . . . . . . . . . 575.12 ASP XACML tool resolution times . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.1 EBIOS methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616.2 Architecture of the authorisation service . . . . . . . . . . . . . . . . . . . . . . 626.3 Nessus web application scanning results . . . . . . . . . . . . . . . . . . . . . . 686.4 Extract of Nessus network scan results . . . . . . . . . . . . . . . . . . . . . . . 696.5 XACML Injection test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706.6 Request test with big random string payload . . . . . . . . . . . . . . . . . . . . 716.7 PDP challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

7.1 Distribution of bins in the normal traffic with different binning schemes, withthreshold t = 0.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7.2 AAL Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887.3 T-NCES of emergency token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897.4 T-NCES of magnetic strip sensor . . . . . . . . . . . . . . . . . . . . . . . . . . 897.5 T-NCES of electricity usage sensor . . . . . . . . . . . . . . . . . . . . . . . . . 907.6 T-NCES of base station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917.7 T-NCES of full scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

10

List of Tables

1 Consortium Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

5.1 Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.2 CCP units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.3 Service providers permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.4 DRK Employees permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.1 Bug Report Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596.2 Overview of found vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . 606.3 Supporting assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.4 Feared events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.5 Target of Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.6 Common vulnerabilities applicable to the target . . . . . . . . . . . . . . . . . . 656.7 Threat scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.8 Threats / Feared events matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.9 Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.10 Risks and security objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.11 PDP tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.1 Examples of elementary features derived from the frameworks instantiation onModbus-TCP and Bacnet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

7.2 Summary of the datasets used for evaluation. . . . . . . . . . . . . . . . . . . . 827.3 Summary of the detection results. . . . . . . . . . . . . . . . . . . . . . . . . . . 837.4 Features selected for the instantiation of the framework on (i) Modbus-TCP

(ii) BACnet datasets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867.5 Analysis of reachability graphs for device level models . . . . . . . . . . . . . . 927.6 Performance Metrics for Scheme without Spinbox (where TP, FP, TN and FN

are True Positive, False Positive, True Negative and False Negative, respectively). 957.7 Performance Metrics for Scheme with Spinbox . . . . . . . . . . . . . . . . . . . 957.8 A Comparison of Results with other Schemes (MLP, RTF and FS are Multi-

Layered Perceptrons, Rank Time Features and Feature Selector, respectively). . 96

11

Chapter 1

Executive Summary

The AU2EU architecture with its integrated authentication and authorisation frameworkserves as a foundation for building secure and privacy preserving collaborative applications.As such evaluating the security offered by this framework and applications built with it isessential. The goal of this document is thus to provide a security assessment methodology forany deployment of the AU2EU architecture and illustrate it by applying this methodology tothe pilot settings. The assessment focusses on AU2EU innovations and not on the commoditytechnologies.

We evaluate this security from different perspectives, focussing on deployments and usecases in the pilot environments. We build a formal model to analyse the security and privacyguarantees offered and determine the personal information different coalitions of participantsare able to derive. We also study policies for the pilot use cases using the XML tools developedin Workpackage WP3. In addition to the formal analysis we also do an evaluation of thedeployment of the framework. We provide a penetration testing plan for AU2EU deploymentsand apply it on the pilot deployments. We cover the risks identified for the authorisationsolution for the pilots and give preliminary results of ongoing wider tests covering the entirepilot deployments. Finally we consider the run-time security of a deployment, focusing ontechniques for monitoring the framework for intrusions.

The three different perspectives together form a comprehensive security assessment method-ology. As AU2EU deployments will be collaborations where multiple authorities need to es-tablish trust and rely on each other, the responsibilities for the security assessment need to beclearly defined. We recommend that collaboration agreements also cover an assessment planwhich identifies responsible parties and provides the required permissions, e.g. for penetrationtesting.

The importance of testing is confirmed by vulnerabilities found by the ongoing testing.Yet, taking into account that the pilot implementations are prototypes and with the cave-atthat further testing is still ongoing, the illustration of the evaluation methodology in the pilotsettings does not reveal any blocking security problems for the pilot deployments.

12

Chapter 2

About this Document

Security assessment report: Provides formal validation of security design, as well as practicalsecurity validation of the implementation in the pilots [month 22]

2.1 Role of the Deliverable

This deliverable (D6.1.1) is a core deliverable of the AU2EU Project that provides a securityevaluation methodology for AU2EU deployments, with an emphasis on the eAuthenticationand eAuthorisation framework. It also demonstrates this methodology by evaluating thesecurity of the pilots from different perspectives. The security evaluation considers three mainperspectives; verification of design principles and deployment decisions with formal techniques,testing of the deployed system with state of the art penetration testing and risk analysistechniques, and finally, run time security monitoring. In addition to these techniques standard,commodity, security technologies should be deployed such as secured connections (SSL/TLS),firewalls, etc. These existing technologies are not target of either the pilot deployment or thisevaluation as we focus on the innovative aspects of the AU2EU framework. Together all thesetechniques provide a multi-layer, defense in depth security approach.

2.2 Relationship to other AU2EU Deliverables

As a security assessment of the AU2EU architecture and its deployment, this deliverableis related to most of the other deliverables. We highlight some links to other deliverables:Deliverable D6.1.1 relies on the results of deliverable D1.4.1 (Reference Architecture for eAu-thentication and eAuthorisation), which provides details of the implementation of D2.2.1(eAuthentication platform implementation V1). This deliverable will be heavily impacted byD1.4.1 as the defined audit procedure is based on the reference architecture provided. Theverification uses, amongst others, tools described in D3.3.1 (eAuthorization Architecture andPlatform Implementation). It also considers the use cases given in deliverable D1.1.1 (De-tailed descriptions of use cases) and the specific deployment of the AU2EU architecture in thepilot setting as described in D2.3.1(Adjusted eAuthentication platform for the pilots), D3.4.1(Adjusted authorization platform for the pilots) and D5.1.1 (Integrated eAuthentication andeAuthorization platform V1).

The consolidated Security Assessment Report will provide the basis for security relatedrevisions to the authentication and authorization improved implementations and their use in

13


the pilot settings. Thus D6.1.1 has direct impact on the following:

D2.2.2 eAuthentication platform implementation V2

D3.3.2 Improved eAuthorization architecture and platform implementation

D5.1.2 Integrated eAuthentication and eAuthorization platform V2

2.3 Relationship to other Versions of this Deliverable

Not applicable.

2.4 Structure of this Document

This document provides detail of the security assessment of the AU2EU eAuthentication andeAuthorisation platforms The structure of this is as follows:

Initially (Chapter 3) the objectives of security are defined, inspired for a large part bythose defined in the D2.2.1 deliverable [9]. These objectives are analysed and formed intoconditions which can be evaluated through penetration testing, validation or run-time moni-toring. Subsequently the system model is analysed and defined in a manner which allows fordetermination of implemented and utilised technologies and the communication paths betweenthese items. An evaluation methodology with three perspectives is defined in Chapter 4 as aresult of the considerations in Chapter 3. In Chapter 5 the verification evaluation perspectiveis illustrated by analysing privacy implication of protocols and the effects of selected accesscontrol policies. In Chapter 6 the testing evaluation perspective is illustrated by performingrisk analysis and penetration testing for the authorisation components of the pilots. We alsopresent preliminary results for wider testing of the full pilot deployments which is still ongoing.In Chapter 7 the run-time monitoring approach is illustrated in the area of building automa-tion (ambient intelligence), inspired by the Ambient Assisted Living (AAL) pilot setting. Wealso consider techniques to enhance monitoring for web-services.

Subsequently the output of these tests will be documented and provided. Finally we con-clude by comparing the security evaluation with the requirements, summarizing the resultsand providing recommendations based on issues identified during evaluation. The implemen-tation and adoption of these recommendations is out of scope of this deliverable and will behandled in the applicable work unit.


Chapter 3

Objectives to Secure the Architecture

The overall goal of the AU2EU project is to enable trusted collaborations by providing anintegrated eAuthentication and eAuthorisation framework. Yet to enable trust, this frameworkitself needs to be secure and trustworthy. The diversity in server types, configurations andcommunication message formats in the architecture drafted as part of the D1.4.1, D2.1.1,D2.2.1 and D3.3.1 deliverables, demands a fool-proof security solution, to thwart any attemptsby the adversary-class to compromise the system. Such a system needs to combine AU2EUinnovations with existing standard commodity security technologies.

As mentioned in Chapter 2 commodity technologies are not the focus of the pilots nor thisdeliverable. Where they are not essential to demonstrate the innovation of the framework, thelimited developer resources are instead focused on key AU2EU innovations. Thus the pilotprototypes may not implement all these commodity techniques. Any production deployment(AU2EU or otherwise) will incorporate these technologies. Thus in our evaluation approachwe assume them to be in place, even if they are not implemented in the pilot prototypes. Acheck that such commodity technology is correctly setup is part of a general evaluation yetis standard and thus will receive only limited attention in this deliverable. For example, weidentify Man in the Middle attacks as potential risks yet, see also Threats part of Section 6.1.1,for the pilots we do not consider this threat on a connection that (in any normal deployment)uses TLS, such as that between a user (agent) and an SP.

Figure 3.1: Communications model for gaining access to a protected resource

15


3.1 High level communication model

The interaction points between different parties form potential entry points for an attacker.Several channels of communication were identified in the architecture. These are listed at ahigh level in figure 3.1.

1. User - IdP: The user needs to obtain credentials issued by the IdP to authenticate tothe relying party controlling the protected resource. The User authenticates to the IdPusing the method established by the IdP, which then issues a new credential to theuser asserting the users attributes that the IdP provides. We assume the IdP providesRESTful services (see Deliverable D2.1.1, [8, Section 4.1 ] for details.) Internally the IdPwill typically maintain an LDAP service to store the users attributes.

Reference Architecture (general) from D1.4.1 [7, Figure 17 ]

In AU2EU the user can use an additional service, the User Agent, to store these creden-tials. (See Deliverable D2.1.1, [8, Section 3.3 ] for details.) To enable the User Agent isinvolved in the issuing of credentials and the user also authenticates to the User Agent,using any existing authentication method supported by the User Agent, such as SAML.(See Deliverable D2.1.1, [8, Section 8 ] and Deliverable D2.2.1, [9, Section 6 ] for details.)

2. User - Protected Resource: The user, or the User Agent acting on behalf of the user,obtains the authentication policy from the server provider and creates a presentationtoken proving possession of the required attributes using the credentials provided by theIdP. This token authenticates the user to the SP. (See Deliverable D3.3.1, [10, Figure 5Integrated architecture] for details.) Upon successful authentication, the user shall beprovided with an appropriate level of access to the protected resource.

3. Service Provider - Protected Resource: The protected resource receives authenticationinformation from the SP using standard commodity methods such as through HTTPheaders.

3.2 Evaluation goals

With the above communication model in mind we categorise the security goals that need to beachieved within this model, along with resulting evaluation requirements. Several evaluation



requirement are shared by different categories are listed at the end. (In Section 8.1 we comparethese goals, and our methodology to evaluate against them, with the AU2EU requirements.)

3.2.1 Confidentiality

Confidentiality of the communicated message is essential as they contain security criticalinformation (e.g. session keys), as well as confidential and private information. In orderto evaluate how well a deployment maintains confidentiality of all messages communicatedbetween the various entities, it is essential that a penetration attempt be made to retrieve dataof interest from all messages in transit. As part of the penetration testing plan, an attemptto retrieve user-specific information from messages communicated through one or more of theabove communication channels, shall be carried out. As part of the verification, informationderivable from the communication will be investigated to see what, possibly confidential,information is inherently revealed and how this effects the users privacy.

3.2.2 Integrity

Messages that are transmitted between any two communicating entities of the architecturemay be accessed, exfiltrated1, modified, and re-injected into the communication stream. Ofparticular significance are the messages that are communicated between the service providerand the protected resource. An attacker may be able to directly obtain unintended rights onthe protected resource if the integrity of this communication is not ensured. In the penetrationtesting, attempts shall be made to retrieve and decipher messages of varying types on all thecommunication pathways listed above. To evaluate integrity of communications based on theinformation that can be retrieved one needs to consider common attacks against integrity andthe mechanisms used to achieve integrity. Using well-established mechanisms is advised andformal validation of non commodity protection mechanisms should be performed. Given avalid certificate, message integrity can be verified at the destination end through the use ofa Message Authentication Code (MAC). A MAC is a simple concatenation of the message tobe transmitted, with a secret key shared between the sender and the receiver, hashed usinga standard hash function such as MD-5 or SHA-1/SHA-2. A message is appended with theMAC, and sent to the destination, where the MAC of the received message is recomputed andcompared against the received MAC, for verification. An adversary should not be able to getthe key or a MAC for a malicious message. For example, an adversary may attempt a replayattack, wherein a stale message is replayed by the adversary, to disrupt routine communicationactivity. Ensuring freshness, for instance by including a time stamp with the current time in amessage before transmission will help prevent a replay attack. (Using timestamps assumes thesystems share a notion of current time. Thus practically there may still be a small window ofopportunity caused by needing to allow for variations in timestamps due to e.g. transmissiondelays and discrepancies between the clocks of the systems involved.) Message integrity canalso be affected through a man-in-the-middle attack, wherein the attacker can portray itselfas a legitimate and intended destination, capture valid data, modify the same, before relayingit through to the actual destination. The procedure is repeated in the opposite direction aswell. For an MIM attack to successfully run, the adversary needs to control an unprotectedconnection or needs to compromise an initial key exchange between both parties intending tocommunicate (IdP-SP, SP-user, user-resource, resource-SP).

1i.e. transfered elsewhere without authorization



3.2.3 Non-repudiation

A service provider must be registered in the system and the protected resource must be fully-capable to verify the origin of a received message. Repudiation of any actions on the partof a service provider must be avoidable, and at the very least identifiable. Accountability ofall user actions in the system can be maintained through the use of various authenticationtechniques that rely on private or secret keys, known only to the rightful owners. This allowsgenerating non-repudiable evidence (e.g. signed messages) which should then be stored (forexample in the form of an audit trail). In order to test the capability of the system to identifynon-repudiation attempts, penetration test plans will be crafted and tested to conceal sourceinformation and follow procedural actions against sensitive components of the architecture.Examples of procedures that will be tested include: modification of access logs, forgery ofIdP and SP certificates, spoofing of IP addresses, and exploiting SSL vulnerabilities on theIdP-Protected Resource channel.

3.2.4 Availability

The availability of resources of the architecture has to be ensured through deployment ofappropriate security controls. In particular, the IdP and the SP must be configured to handlelarge volumes of user requests for protected resource access, that may arise through either aflash crowd, or through a deliberate Denial of Service Attack launched by the adversary. Aspart of the penetration testing plan, several traffic generation scripts will be written to craftvalid requests for protected resource-access, destined towards the IdP and the SP. In effect,the attack vectors will be attempting to stress-test the critical resources of the architectureagainst such attacks.

3.2.5 Evaluation effecting multiple attributes

Policies need to be validated to ensure they assign the correct permissions as their correctnessdirectly affects confidentiality, integrity and availability. Run-time monitoring in turn aims todetect different attacks, which could be aimed at any of the above security goals. It should beable to detect new attacks, for example ones that were not yet known when the penetrationtesting was performed.

3.2.6 Summary

Summarising the evaluation requirement above we can say formal verification of policies andof any non-commodity components should be performed to protect against architectural log-ical attacks. The underlying purpose of the penetration testing plan is to ascertain that theproposed system architecture deployment is protected against exploits of diverse types, thatan adversary may use to gain access to a system, and in effect, acquire/modify/delete sensi-tive information held by the protected resource. Finally monitoring should be performed toevaluate the security at run-time.

3.3 System Model

Above we gave a high level communication model and security goals to be achieved. Here weaim to give a more specific list of exploits that need to be protected against. To do this we



need to make some assumptions about the systems that are used in the AU2EU deploymentbeing tested. As evident from the communication model introduced in the Section 3.1 as ageneral system model we assume a client-server model. We assume utilities on the SP will bemade available through RESTful services and communication between the different parties,client (& User Agent), SP, IdP is assumed to use TLS protected connections. The protectedresource is a web service that provides certain services to an end-user through the SP. Thebase software likely to be used by the SP and IdP includes Tomcat and Apache with C/C++,Java and Javascript being used to implement web service functionality.

The user typically consumes services through a client that is a typical web browser.Through the client the user authenticates to the User Agent. While legacy authenticationtechnologies such as Shibboleth may be used for authenticating the client to the IdP, whenthe user places credentials in the User Agent, and to authenticate the user to the User Agent,the AU2EU authentication and authorisation is used between the User Agent and the SPwhen attempting to access the protected resource.

A User Agent uses a token (see D2.2.1 [9]) generated from credentials issued by an identityprovider (IdP) to authenticate a user to a service provider (SP) with the goal of consumingprotected resources. The (Policy Enforcement Point of the) SP will authorise (see D3.3.1 [10])a user requests according to policies expressed in XACML format. The authentication token,generated by the (User Agent of the) client, expresses a claim about the clients attributesalong with cryptographic evidence validating the claim. This evidence is checked to establishvalidated user attributes which are compared to requirements for the resource stated in theXACML policy.

The SP is assumed to maintain a database storing information required for verificationsuch as the public keys for IdPs it trusts to issue user attributes. In addition, nonce values cre-ated for validating end-user authentication attempts are also stored within the same database.Finally other received user information, such as certificate attributes and user-specific infor-mation will be stored here. The IdP will, in addition, have an LDAP repository for storinguser attributes.

Based on the above basic system model and the security objectives given in the previoussection we identify some concrete evaluation goals as well as several threats and vulnerabilitiesto guard against. The XACML policies are key for correct authorisation of the protectedresource. XACML policies are expressive and link rights to attributes, such as those extractedfrom a token. However, they tend to be verbose (see Appendix A) and can also be quitecomplex. As such validation of XACML policies is needed.

All communicating parties rely on RESTful web services, and therefore, relevant exploitswill be run to analyse the resilience of the implementation against penetration attemptsthrough the deployed REST services. As an architecture the use of RESTful web-servicesis a standard model thus architectural validation should focus on specific combination of pro-tocols/parties in a deployment. Considering the presence of a Tomcat server, various exploitsagainst Tomcat will be run and the responses of the server will be analysed. The use of cookiesfor maintaining client access patterns, can be exploited through modifying and/or tamperingof cookies intended for storage within a client. As many of the webservices rely on a database,corresponding attacks such as SQL injection need to be considered. In particular, the followingexploits will be run (not necessarily in the order listed):

Certificate forgery

Tomcat Manage bugs



SSL vulnerabilities (against TLS v1.0)

Spoofed IP addresses of IdP/SP

Man-in-the-middle attacks

Wireshark for traffic analysis (encrypted or otherwise)

Test communications to protected resources i.e., hidden data

Cross Site Scripting (XSS)

SQL injection

CSRF

Cookie Modification/Tampering

JavaScript Injection

Metadata Poisoning/Enumeration

The points for security evaluation identified are addressed in the remainder of this documentaccording to the methodology described in the next chapter.


Chapter 4

Verification, Testing and MonitoringMethodology

The security evaluation strategy for a deployment of the AU2EU architecture is three-foldand thus examines the system from several viewpoints. First we consider formal techniquesto evaluate scenarios running in the AU2EU deployment and the policies being used in thesedeployments. Next security testing of the system should be performed which we demonstrateby testing of an actual (pilot) deployment. Finally these analyses are complemented with run-time monitoring to discover intrusion attempts. We discuss intrusion detection techniquessuitable for the AU2EU deployments and specifically its pilots.

4.1 Verification

From a high level perspective, correctness of the AU2EU authentication and authorisationflow, run by Web Services and having users connected through links secured with standardtechnologies (SSL, HTTPS) does not differ much from security of a standard XACML de-ployment. A Policy Decision Point (PDP) is used to determine permission based on policiesspecified in terms of attributes of the subject (i.e. the user), action to be performed, theresource and the environment. Of course these policies need to be validated to ensure theycorrectly capture the intended meaning (see Section 4.1.2 & Section 5.2). Identification andauthentication of the user and credentials in the form of SAML assertions are a commonlyused methods to establish and validate the subjects attributes. In the AU2EU frameworkauthentication is performed by Idemix anonymous credentials through the Attribute-BasedCredential Engine (ABCE), see D2.2.1 [9, Section 4 ], which also establishes and validatessubject attributes, though without requiring that the user is uniquely identified. Idemix [13]credentials can by now also be considered well established technology, for example formingthe basis of Direct Anonymous Attestation used by Trusted Platform Modules. As anonymityis revocable, the use of anonymous credentials also does not negatively impact accountability.The XACML PDP, in turn, is agnostic to how attributes are validated; any source of validatedattributes is equivalent from this perspective.

For authorisation the additional steps for providing the presentation policy do not affectthe validity of the check done by the PDP. What should be checked what the effect is of theinformation exchanged as part of the AU2EU authentication-authorisation flow itself. Doesthis reveal confidential information and/or affect the privacy of the user?

21


Thus from a correctness of authorisation perspective AU2EU authorisation is no differentthan any standard XACML approach. We focus on assessing the actual deployment andimplementation through the penetration testing. In the verification we focus on the twopoints noted above: leakage of confidential information inherent in the protocols used andevaluation of the policies with respect to their intended meaning.

4.1.1 Protocol analysis for privacy

One main benefit of the AU2EU authentication-authorisation framework is that it allows theuse of revocable anonymous credentials; users need only demonstrate (properties of) the at-tributes required rather than reveal their identity. This improves confidentiality of information(e.g. not revealing the assignment of experts to an incident to other parties) or privacy (notrevealing a user consumes a particular service). Still, if information used in the protocolsreveals additional information about the parties involved (e.g. allowing one to link sessionsof two different protocol runs) part of this advantage is lost. We analyse a scenario in thebiosecurity incident response [5, Section 4 ] setting with TRIPLEX [41], a tool designed todetermine information revealed by communication protocols.

4.1.2 Policy Evaluation

As mentioned above, correctness of the policies used is essential; as they directly determinethe permissions that users have, any mistake in the policies will directly affects confidentiality(e.g. when an unintended read permissions is given), integrity (for an unintended write per-mission) and/or availability (for a missing intended permission). XACML policies can becomecomplex, especially in the collaborative settings for which the AU2EU framework is intended.Thus a way is needed to support a policy administrator in evaluating the effect a given set ofpolicies has. In Deliverable D3.3.1 [10] we already described the tools developed to evaluatepolicies. Here we check performance of these tools to ensure they are suitable for analysis ofuse case pilots and demonstrate their use on policies from the pilots, in particular the AALpilot.

4.2 Testing

Testing will be broken up into three main sections, web auditing, source code auditing andcommunications auditing. Web auditing will primarily be a black box penetration test, whileweb source will be reviewed within source audit. Black box penetration testing is used toemulate how real world attackers would approach a web based attack, it is not an exhaus-tive test of all vulnerabilities however can serve as a reference of the difficulty of web basedvulnerability exploits of the system.

Testing involves both automated tools and manual testing. Automated testing involvestools to automate tasks that are complex and/or repetitive. Automated testing involves offthe shelf tools as well as custom scripts created for testing relevant components. Off the shelftools include OWASP ZAP [34], IBM AppScan [25], Burp Suite [37], W3AF [42], SQLmap [16]and XSS-Proxy [4].



4.2.1 Web Auditing

Web auditing starts with enumeration, which involves fingerprinting the web server to deter-mine if the version of software being run on the web server (NodeJS, PHP, MySQL, MongoDBetc.) is vulnerable to particular attacks and which ports are being used, of the discovery ofwhat web pages are linked to publicly, if there are resources that are publicly accessible but notlinked to (administrator panels, path traversal etc.), if there are indicators that attempts havebeen made to mitigate vulnerabilities (such as CSRF tokens) and if there is any informationleakage through metadata or detailed errors on invalid input. Tools used in the enumerationprocess include Burp Suite, W3AF, OWASP ZAP and whatserver.

Web authentication mechanisms will be tested to determine if authentication mechanismsare functioning correctly (only login when valid username/password combination is given)and to determine if the authentication mechanism is vulnerable to attacks such as SQL in-jection. Web authorisation systems will also be tested to ensure that user roles are properlyenforced (i.e., to ensure regular users cant access administration panels). As the system usesa RESTful API, both regular HTTP POST/GET requests as well as requests such as HTTPPUT/DELETE requests as well as arbitrary undefined request types. Different request typeswill be tested manually by setting HTTP headers, authentication mechanism checking will beautomated through OWASP ZAP, SQLmap and custom scripting, authorisation check will bedone using a mixture of manual browsing and automated testing using OWASP ZAP or BurpSuite.

Accounts registration will be tested to ensure that all identity requirements are met beforeaccount creation and that when a password is chosen, it complies to a minimum standard.Account provisioning will be tested to ensure that a user A cannot provision user B such thatuser B has a higher access level than user A. Account de-provisioning will also be tested toensure that details linked to the account such as credential wallets are handled appropriately.

Default credentials will be tested to determine if well known username/password com-binations are in use. Account lockout mechanisms will be tested to ensure that passwordbrute-forcing is mitigated. This testing will be automated through the hydra application orcustom scripting.

Session management will be tested to ensure that session keys are not easily guessable,session keys are not fixed, sessions expire after a set amount of time and what occurs when auser logs out. This testing is done manually by determining how long session keys are, howthey are generated (if it is not random), attempting to set session keys before logging in andseeing how long an inactive user remains logged in.

Cross Site Scripting (XSS) and Cross Site Request Forgery (CSRF) vulnerabilities will betested. This includes ensuring that output from the database is correctly escaped and thatforms include CSRF tokens and that CSRF tokens are properly checked server-side afte rtheform is submitted. XSS and CSRF testing will be done through automated testing usingOWASP ZAP and XSS-Proxy while manual testing by attempting to inject code and bypassCSRF checks.

Injection will also be attempted where possible such as forms and GET variables, such asXML injection, Server-Side Includes (SSI) injection, code injection, command injection andbuffer overflow.

Business logic will also be tested to ensure that if steps in a process are deliberately skipped,the application behaves correctly by either forcing the user to go back to missed steps or tore-start the process.



4.2.2 Source Auditing

Source auditing will be broken into automated and manual testing. Source code auditing isundertaken to reveal vulnerabilities that may not be obvious in black box penetration testingand to ensure that a minimum standard of coding is met. Automated testing will occur beforemanual testing so that manual testing can focus on code quality and potential vulnerabilitiesnot found by automated testing.

Automated Source Auditing IBM AppScan will be used to test the application bothstatically (source code) and dynamically (running binaries).

Lint applications will be utilised to flag potentially vulnerable code. Lint applications(e.g., splint for C code) statically analyse source code for coding mistakes, use of potentiallyvulnerable functions and code that may be susceptible to buffer overflow. There are manylint applications, most of which only analyse a single programming language, relevant lintprograms will be used depending on the program language being analysed.

Manual Source Auditing Manual source code auditing will be done to examine the qualityof code that has been written, to ensure coding standards are met and to find vulnerabilitiesthat automated tools have not picked up. The manual source code review will look at usercontrolled string and buffers and ensure the application ensure correct bounds checking andescaping to prevent some injections and overflows. Logic will also be checked to ensure thatsteps in the authentication and authorisation mechanisms cannot be skipped.

Manual review will also determine if connections to back end databases and programs aredone securely (eg. TCP connections encrypted) as well as ensure there are procedures in placeto validate user input against and escape database output. Calls to potentially vulnerablefunctions such as exec and eval will also be looked at to check that the application ensuresinput into vulnerable functions is safe. If regular expressions are used to validate or escapeinput/output, manual review will ensure that the expressions are not vulnerable (expressionscheck for start and end of string when needed etc.).

4.2.3 Communications Auditing

Communications auditing comprises of testing whether communications between server andclient is encrypted, communications between system components are encrypted, if communi-cations protocols can be renegotiated to disable or degrade encryption, if commands can beinjected during communication.

Communications auditing will utilise Wireshark to capture and analyse traffic betweenclient and server to determine communication protocols. Man in the Middle (MitM) attackswill utilise ettercap to intercept protocol negotiation to downgrade or remove encryption aswell as attempt to perform command injection. Man in the Middle attacks will occur betweenserver and client as well as in between system components.



4.3 Bug Classes

4.3.1 XSS

Definition: Cross Site Scripting (XSS) is a web application vulnerability which occurs whenan attacker injects a scripting language such as JavaScipt into a data field which will be viewedat another time. When the data is viewed, for example by a user through a web browser, thescripting language is interpreted by the web browser and the malicious code is executed client-side.

Impacts: XSS can lead to an attacker using functionality in the application as other users(if the scripting is shown to other users), however it can also be used to include other maliciousscripts from third parties or redirect to malicious websites. Functionality that may be usedfraudulently include changing user details or use of features restricted to administrators.

Mitigation: user controlled data should always be escaped before output, this could beconverting special characters to HTML entities or by removing scripting language identifierscompletely (such as script tags)

4.3.2 SQL Injection

Definition: SQL injection (SQLi) is a vulnerability that is common in web applicationswhich occurs when data is input to a SQL query where the input data is made to alter theSQL query being performed.

Impacts: SQLi can effect all security objectives (availability, integrity, confidentiality, non-repudiation, authentication) can include breaking authentication/authorisation mechanisms,information leakage and data tampering/destruction.

Mitigation: SQLi can be mitigated by escaping input which is passed to SQL functions,however escaping input can sometimes be bypassed if not done correctly. The best approachto mitigate SQLi is to use parameterised queries (aka prepared statements), which separatesSQL from data, preventing data from being interpreted as SQL.

4.3.3 CSRF

Definition: Cross Site Request Forgery is a vulnerability which occurs when a user browsesto a malicious website (or a website which has malicious code on it) which uses scripts whichrun client-side to make fraudulent requests to trusted websites where the user is authenticated.This can be accomplished because web browsers always send identifying cookies when makingrequests, so even when malicious JavaScript code makes a requests to a trusted website, thebrowser identifies itself and the server handles the request as if it were a legitimate requestmade by the user.

Impacts: CSRF allows attackers to forge requests as if they were legitimate users. Thismainly compromises non-repudiation, as users can claim that their actions may have been aCSRF attacker, but can also effect data integrity.



Mitigation: CSRF tokens can be set by the server and sent when the user requests a form,the user then submits the form along with the token. This works because the token is notguessable and only visible to the user, not by JavaScript on other websites.

4.3.4 Broken Authentication or Session Management

Definition: If an application grants access to a user with invalid credentials, if sensitiveauthentication data such as passwords are stored insecurely or if weak authenticating data isallowed, then the authentication mechanism is considered broken.

If session identifiers are not expired properly, destroyed properly on logout, exposed orregenerated before and after login (new session identifier issued) then the session managementsystem is considered broken.

Impacts: Broken authentication and incorrect session management may allow any attackerto gain access to restricted resources and functionality. Confidentiality and non-repudiationare compromised, depending on what the functionality is, integrity, availability may also becompromised.

Mitigation: analyse methods which are used for authentication and thoroughly test mech-anisms. When storing authentication data such as passwords, ensure that they are saltedwith a unique, random value (unique per user) and hashed using a secure algorithm (such asblowfish). The application should enforce a minimum standard for passwords to ensure thatguessable passwords cannot be used to brute force the authentication method.

Sessions must be properly handled by the application, identifiers destroyed upon logout,destroyed when they expire and be re-issued before and after login. Session identifiers shouldnot be exposed anywhere, they should only be used in secure cookies and session cookies setto HTMLonly if possible.

4.3.5 Command Injection

Definition: Command Injection is when unfiltered data is used in a function which executesa query, this can be an OS level execution such as exec() or a language specific execution suchas eval().

Impacts: Depending on the type and context of command injection, the impacts couldbe limited to the application or it could compromise the security of the entire server thatthe application resides on. Command injection can affect all aspects of security (availability,integrity, confidentiality, non-repudiation, authentication).

Mitigation: user controlled data should only be passed to execution functions when there isno alternative. If user controlled data is to be used in an execution function, careful attentionshould be paid to proper escaping methods and the use of white-list filters (for example, onlyallow a-z characters).



4.3.6 Insecure Direct Object References

Definition: An insecure direct object reference occurs when an object is accessible by a userwhich should not have access to the object. This is usually due to trusting user controlledvariables (such as POST and GET variables) and using these variables to determine whichobject to display without ensuring that the user is authorised to view the object.

Impacts: Insecure direct object references compromises confidentiality, by revealing re-sources to unauthorised users, however as these resources may be web pages that administrateusers or control data, integrity and availability are also compromised.

Definition: every reference to an object, where the object is to be viewed by only authorisedusers, should be checked to ensure that the requesting user has access.

4.3.7 Data Leakage

Definition: Data leakage may occur from displaying software version numbers, debug infor-mation, excessive information in error messages, information about a closed source back endand developer comments to users.

Impacts: Data leakage is a compromise of confidentiality. Data leakage is often used to gaininformation about a target and may aid an attacker in compromising the system.

Mitigation: Users should not be able to see information that is not needed for correctfunctionality of an application. Code comments should be stripped out before displayingto users, error messages should be generic or give an error code which can be reported toa developer while not revealing any more information than is necessary, debug informationshould be stripped or turned off for production environments.

4.3.8 Use of vulnerable functions

Definition: Some programming languages and libraries include functions that have knownvulnerabilities. For example the C function strcpy() which is vulnerable to buffer overflowattacks, PHPs unserialize function which can be used for object injection or JavaScripts evalfunction which when user controlled data is passed to it can be exploited

Impacts: Depending on the function and the context the function is used, the impacts arevaried. For example buffer overflows with the C function strcpy() may result in an attackergaining a shell on a server, or may just result in a denial of service.

Mitigation: After a language has been chosen, research should be undertaken to deter-mine potentially vulnerable functions and use them with caution, as well as ensuring userdata is escaped/filtered appropriately. Static analysis tools such as IBM AppScan Source,VisualCodeGrepp, RIPS and ScanJS are able to point out vulnerable functions that are inuse.



4.4 Automated Test Procedure

4.4.1 IBM Security AppScan

IBM Security AppScan will be run against each component in each pilot to determine if thereare security vulnerabilities that may be present. AppScan Standard will be used to performa dynamic audit, while AppScan Source will be used to statically analyse source code.

IBM Security AppScan Standard

A valid username and password is required to ensure the comprehensiveness of this test. Createa new comprehensive scan in IBM Security AppScan Standard. Complete forms to ensure onecomponent is tested at a time. A login method should be recorded when prompted by thescan configuration wizard. Use the complete pre-defined test policy and start a full automaticscan.

Once the scan is complete, the issues tab will list all issues found during the currentscan. These issues are to be reviewed, as not all issues reported are of concern during currenttesting (such as non-use of SSL) and some issues may be false positives. Issues that are ofconcern will be replicated manually, reported and fixed. Manual replication of issues not onlyallows vulnerabilities to be verified but to allow exploits to be demonstrated which allowsstakeholders to determine the impact of the vulnerability.

Example 1 - Verifying Vulnerability: Using IBM Security AppScan Standard, initialscans of the IBM credential wallet demo, showed that sessions were not invalidated after logoutand that old session ids were still able to use the system. This vulnerability makes sessionhigh-jacking easier and needs to be tested to ensure that this vulnerability is exploitable andnot a false positive.

To test this claim, Burp Suite was used as an intercepting proxy to capture and manipulatecookies that carry the session id. While Burp was running and intercepting traffic, validcredentials were used to log in a user, once logged in the session cookie was noted and the userlogged out (which assigned a new session cookie). The page was refreshed and burp was usedto set the session cookie value to the first value which was assigned to the logged in user, thesession was still valid and as such an attacker could use old valid session ids to impersonateothers.

Example 2 - False Positive: Using IBM Security AppScan Standard, initial scans ofthe IBM credential wallet demo, showed that login error messages could be used for accountenumeration, this is normally attributed to detailed error messages on a failed login attemptwhich can help an attacker determine which users are present on the system. Messages suchas "Password for user X" and "user not found" instead of "invalid username or password" arecommon examples.

Using a browser, a real username and incorrect password is used and error message noted,then an incorrect username and password is entered, the error message is the same, indicatingthat there is no difference in message if the user does or does not exist. Upon closer inspectionof AppScan report, the scan first attempted to use a fake username in the register user formand then used the same "fake" username to login, as this user was now valid and the loginsuccessful, the page differed from an unsuccessful login, causing a false error.



IBM Security AppScan Source

IBM Rational AppScan Source Edition will be used to analyse application source code inan attempt to detect programming errors which cause vulnerabilities or use of vulnerablefunctions.

Example - Information Leakage: During initial scans of IBM Idemix with IBM App-Scan Source Edition, a single information leak vulnerability was found in five different loca-tions. Upon further inspection of the source code it was found that if a certain exception wasthrown a stack trace would be printed, leaking information.

4.4.2 Other Automated Tools

Intercepting Proxies

OWASP ZAP and Burp Suite are Java based intercepting proxies, which analyse data sentbetween the browser and server and performs automated tests to determine if certain vul-nerabilities are present. These tools will be used in addition to IBM AppScan to allow for abroader coverage of vulnerabilities and scan types.

For both tools, an internet browser needs to be set to forward all requests through theintercepting proxy which is located at localhost:8080. When testing VMs, the network inter-faces of each VM needs to be set to bridged.

The following is based on OWASP ZAP, as Burp vulnerability scanning is only availablein the Professional version.

Once the browser is set-up to forward requests through ZAP and the ZAP applicationstarted, the tester browses to the site to be tested. The site should now be listed in ZAP,where automated test attacks can be automated.

First the site will be spidered, i.e. an automated webcrawler will visit webpages of thesite and will recursively follow links to other local webpages that it finds in these pages,to build a list of every resource. During the spider process, ZAP may generate alerts ifpotential vulnerabilities are found, such as missing HTTP headers. GET/POST fields thatmay be susceptible to exploits, such as SQL injection are marked for fuzzing. In fuzzinglarge amounts of random data (fuzz) is entered into the field being tested. The fuzzing isperformed on the marked fields by sending the correspondign HTTP GET/POST requestsand the results are displayed by the tool. These results are then reviewed to determine ifexploit was successful.

VisualCodeGrepp

VisualCodeGrepp (VCG) is an application which searches through source code to look for theuse of vulnerable functions. VCG also highlights functions that could be used in insecure ways.VCG scans produce a much larger list of potential vulnerabilites than IBM AppScan Source,as it highlights functions that may be used unsafely, but are not necessarily used unsafely inthe source code being scanned. Despite a large report which contains many false positives,some results, especially those highlighted as a high security risk, warrant investigation.

Example 1 - Unsafe function used: Initial scans on Idemix source code shows thatthe java.util.Random, which generates randomness which may not have sufficient entropy for



creation of e.g. cryptographic keys or nounces, was being used instead of the cryptographicallysecure java.security.SecureRandom.

Example 2 - False Positive: Initial scans on Idemix source code shows that the xorfunction is being used in several files, which is marked as unsafe because some developers usexor to obfuscate data in a trivial manner. Upon inspection the xor function is not being usedto obfuscate data, and that the xor function is used in a method override which is not usedin any current code.

4.5 Manual Test Procedure

In this section we briefly describe the selected penetration testing frameworks used in this workand outline the methodology to be used to test the AAL and Biosecurity pilot implementations.

Business objectives and project scope influence the selection of a particular framework ormethodology when initiating a penetration testing project. There are a diverse range of pen-etration testing methodologies and frameworks that are currently available for use promotedacross industry and academia. Each exhibits unique characteristics and takes a distinct ap-proach to a penetration testing project, but there are common elements which can be drawnfrom all. Shared phases identified across methodologies and frameworks are predominately:planning and preparation, information gathering, vulnerability identification, exploitation,maintaining access and reporting. Though not limited to these phases, generally a penetra-tion test will more than likely entail these phases in one form or another.

We considered nine currently available penetration testing methodologies and frameworksfor this project, viz., Information System Security Assessment Framework (ISSAF), OpenSource Security Testing Methodology Manual (OSSTMM), NIST 800-115, Open Web Applica-tion Security Project (OWASP), Building Security in Maturity Model (BSIMM), PenetrationTesting Framework 0.59 (PTF), Penetration Testing Execution Standard (PTES), MetasploitFramework (MSF) and Browser Exploitation Framework (BeEF). We selected ISSAF andOWASP as being the best-aligned to the objectives of this project.

4.5.1 Information System Security Assessment Framework (ISSAF)

ISSAF is an open source, peer-reviewed, penetration testing framework created by the OpenInformation Systems Security Group (OISSG). ISSAF is described as a framework and en-capsulates multiple methodologies throughout the approximately 845 pages (draft 0.2.1B).ISSAF is a detailed and comprehensive framework covering a variety of domains whereby eachhas its own methodology. Domain areas include, but are not limited to, password securitytesting, switch and router security, firewall security, intrusion detection systems assessments,VPN security, web application security, and windows security. Though not all domains arelisted here, suffice to say that ISSAF attempts to cover all possible phases of a penetrationtest from conception to completion. The penetration testing methodology of the frameworkis divided into three primary phases, namely; planning and preparation, assessment, and re-porting and clean up. One advantage of ISSAF in particular is that the distinct relationshipbetween the tasks and their associated tools for each task are shown, in addition screenshotsof expected outputs are provided coupled with explanations of the how and why each taskis performed. The ISSAF is large in comparison to other frameworks but assumes that anorganisation will delete superfluous material before use. One potential disadvantage of ISSAFis that it has not been updated since 2006, thus, it references out-dated systems and tools.



Nonetheless, its generic nature, level of detail and domain coverage provides significant utilityover other penetration testing frameworks.

4.5.2 Open Web Application Security Project (OWASP)

OWASP is a not-for-profit organisation focused on improving software security. OWASP pro-vides numerous tools, guides and testing methodologies for cyber security under the opensource license. The OWASP Testing Framework details tasks and techniques appropriate forvarious phases of the software development lifecycle focussed on developing software withsecurity in mind, rather than finding vulnerabilities after development. The OWASP Test-ing Framework is approximately 224 pages divided into three primary sections namely; theOWASP testing framework for web application development, the web application testingmethodology, and reporting. The OWASP Testing Framework encapsulates the Web Ap-plication Methodology (section four) that provides a strong focus on web applications. Themethodology can be used independently, or in conjunction with the testing framework; inother words, use the framework to build a web application with security in mind followed bya penetration test (web application methodology) to test the design. The OWASP method-ology for Web Applications brings together tools and techniques used for each phase of thepenetration test however it does not provide details of each tool, instead, assumes knowledgeof tools and techniques. The recommended tools for each phase are detailed throughout; inaddition web links to relevant information of tools and technique are offered to assist with anyknowledge gaps that might exist. What is unique about this methodology is the discussionon protocol behaviour. It further shows what results might be expected from a test. The webapplication methodology has a solid structure that outlines each test in detail, namely: phasesummary, objective, how to test, recommended tools, references and/or whitepapers, and re-mediation. The tests cover both client-side and server-side testing and examples are provided.OWASP additionally provides a project called WEBGOAT that enables penetration testersto load a vulnerable website in a controlled environment and test these techniques against alive system.

In summary, the OWASP Testing Framework has a strong focus on web application securitythroughout the software development lifecycle opposed to ISSAF, which is aimed at securitytesting an entire system (not just web applications), thus OWASP and ISSAF provide anexcellent counterpoint to one another in terms of penetration test completeness.

4.5.3 Test Methodology

We plan to test each pilot implementation with both penetration testing frameworks. Thismethodology has two benefits, first, cross-validation and second, coverage. By using twodistinct penetration testing frameworks that share common phases, we aim to validate theresults found by one framework with the results found in the other. This ascribes a level ofassurance about the results that would not be possible otherwise. Given that the frameworkshave clearly different foci, it is possible that a vulnerability missed by one will be found bythe other. This difference in coverage is likely to be effective because of the diverse nature ofthe two pilot implementations.



4.5.4 Discovery

Initially a number of discovery processes are conducted in order to gather what informationcan be found without heavy interaction. This phase would generally consist of analysis viasearch engine results, DNS queries, WHOIS queries and other information gathering throughpublic information sources. However in the case of the AU2EU prototype services none ofthese are publicly advertised and as such the discovery phase has been deemed out of scopefor this evaluation.

4.5.5 Enumeration

The enumeration phase of evaluation is concerned with the interactive examination of thenetwork services running on the prototype systems. The goal is information gathering anddetermining the presence of misconfiguration or potential vulnerabilities. Information gath-ered during this phase may be the basis of vulnerability reports or confirmation during theexploitation phase may be required. Service fingerprinting is conducted in order to determinethe specifics of the services running on the target system as well as the nature of the systemas a whole, including details such as the operating system that is running on the target host,patch levels of services and so on. One such example of this is web server fingerprinting, therecommended tool for fingerprinting is netcat. In addition to netcat, socat is used if thegiven target interface implements SSL/TLS. In this testing the client connects to the serverand issues a variety of commands in order to illicit server responses which may reveal detailsof the service configuration or software.

4.5.6 Exploitation

A modified systems analysis approach is implemented during the exploitation phase which isfed by the information from discovery and enumeration phases. In this analysis the variouspoints of input for the application are identified. In the case of a web services these inputswould be the HTTP request elements, including referrer field, header, HTTP verb, parameters,host information, reverse DNS for originating IP, POST values, cookies, etc. With each ofthese a variety of submissions are explored with the goal of determining how the variation ofthese inputs impacts the output of the application. As the impact of these inputs are identifiedthe handling of such is considered in order to craft an input which will result in unintendedbehaviour being exhibited by the service under test. The goal of this phase is to identify thepresence of vulnerabilities with the potential to undermine the security of the service.

4.6 Run-time monitoring

Use of advanced security architectures such as that offered by AU2EU and verification andtesting of design and deployment are essential steps in achieving a secure system. Yet there isno foolproof solution; risk of misuse will always remain. For example, ambient systems such asbuilding automation typically focus on functionality, relying on firewalls to protect a relativelytrusted but mostly unprotected internal network from attackers on an outside network (theInternet). Yet relying only on perimeter security is insufficient in these conditions. Besidesany breach of the perimeter exposing the entire network an infected/malicious device within



the network can be very problematic as it may have unrestricted access. Defense in depth byuse of additional security measures, such as intrusion detection systems, is advisable.

Effective intrusion detection systems, especially those able to detect previously unknownattacks, require customization and tuning to take into account the characteristics of a specificdeployment environment. In Chapter 7 we illustrate the applicability of IDS systems to(building) control systems as an example inspired by the AAL pilot setting.


Chapter 5

Verification

5.1 Protocol analysis for privacy

Communication systems deal with ever increasing amounts of personal information. EU pri-vacy laws require such systems to satisfy the data minimisation principle. That is, systemshave to be designed to ensure that actors within such systems collect and store only the mini-mal amount of personal information needed to fulfil their task. (Note that data minimisationconcerns the knowledge of insiders when the system operates normally rather than the knowl-edge of attackers who attempt to disrupt its operation.) The AU2EU framework supports dataminimisation by using of privacy-enhancing communication protocols which employ crypto-graphic primitives such as anonymous credentials to ensure minimal leakage of information.In this way we aim to ensure that participants learn as little as possible, even when they tryto combine information from different sources to build profiles. Understanding exactly whatprivacy guarantees different protocols offer is important, e.g., for system designers that wantto use privacy-enhancing protocols, or for system administrators that want to select whatsystem to use. However, it is typically not straightforward for non-cryptography experts toobtain such an understanding. Analysing a combination of protocols involving multiple actorswhich may collude to build user profiles is not a trivial task.

To support the analyst in analysing privacy implications of a given scenario we applyTRIPLEX [41]. The motivation for selecting this framework is that it is design specifically forthe goal of analysing data minimization and privacy properties, has support for anonymouscredentials and treats cryptographic primitives at a symbolic, conceptual level allowing anal-ysis without needed to understand the details of the cryptographic primitives used and comeswith a graphical interface for specifying scenarios and viewing analysis results.

We evaluate a scenario in the Biosecurity Incident Response pilot domain, evaluating whatpersonal data is revealed to the different coalitions of parties within this AU2EU deploymentsetting. The Australian Biosecurity Incident Response (BIR) pilot setting considers the pro-cedure used in Australia to handle possible outbreaks of exotic diseases, designed specificallyto ensure a strong position for the agricultural industry. We will quickly summarize this pro-cedure, and present how the AU2EU protocol would allow privacy preserving authorisation forusers to connect with the meetings which are an integral part of the protocol. Next, we willdemonstrate several specific scenarios of BIR. Then we will discuss how the AU2EU protocoland these scenarios can be used as input for TRIPLEX, a framework developed for analyzingprivacy properties.

34


Finally, we will discuss the results obtained from TRIPLEX, as well evaluate the practi-cality and usefulness of the tool itself; is it sufficiently expressive to capture the scenarios yeton the other hand simple enough that it does not need extensive cryptographic expertise touse.

5.1.1 Preliminaries

In this section we briefly describe the TRIPLEX tool and the main ideas of the underly-ing framework. We refer to [40] for further information on the underlying framework. TheTRIPLEX framework is designed to analyse relevant privacy aspects of privacy-enhancingprotocols in a specified scenario that may involve several actors and protocol instances (of dif-ferent protocols). Messages are annotated with to whom information refers and the analysisdetermines what, possibly privacy-sensitive, information is revealed to different parties. Themain principles used are:

Dolev-Yao Model of Cryptography: A standard Dolev-Yao black-box model is used tocapture the functionality of cryptographic primitives and operations used in commu-nication protocols, without needing to consider the details of the cryptographic prim-itives used. Protocol description and analysis happens at an abstract, symbolic level.The TRIPLEX tool provides built-in support for several standard (e.g., symmetric andasymmetric encryption, digital signatures, hashes) and advanced (e.g., zero-knowledgeproofs, anonymous credentials) primitives, and allows extension.

A Three-Layer Model of Information: To allow abstract reasoning over information usedin different contexts a three layered representation of data is used. The information layer,describes the information (e.g. this is age of actor c). The object layer describes thecontext in which data is observed (e.g. instance 2 of protocol ). Finally the contentslayer, is the data used to represent the information within the protocol (e.g. age=18).

Coalition Graphs of colluding actors; as actors may collude to build more comprehensiveuser profiles, coalition graphs are built to visually represent the knowledge on a datasubject that different coalitions can obtain. For a given scenario these are automaticallyderived from the three-layer representation of the knowledge.

Abstract protocols are formed using four types of abstract items:

Role (r): a role is used to describe which actions/items belong to the same agent whena session of the abstract protocol is run between agents;

Identifier (ID): an identifier is a name that uniquely identifies an agent; an agent mayhave multiple identifiers; this type of items includes keys;

Data (D): data that belong to a specific agent, e.g. age;

Global data (G): data that do not belong to any specific agent, e.g. nonces.

From these items the protocol message terms are built:

E ::= id{r, ID} | data{r,D} | globalData{G} | [E1, . . . , En] |pk(E) | cred(E1, E2, E3, E4, E5) | . . .



The basic terms are an identifier linked to role r, a data item regarding role r and global datanot related to any specific agent. Terms can be combined using different primitives to createtuples ([E1, . . . , En]), public keys (pk(E)), anonymous credentials (cred(E1, E2, E3, E4, E5)),etc. In a protocol (see e.g. Figure 5.4) such messages are sent from some identity to anotheridentity (e.g. "ip{r}", note that we link the identity to the role played in the protocol butdo not need to state it is an identifier here as this is the only data type allowed in a from/tofield).

In addition to the abstract protocols a scenario is defined which captures the agents, theiridentities and data items about them, their keys and any relevant global data items. Withina scenario one can define the initial knowledge, i.e. what the different agents know about thescenario. This initial knowledge describes what data and identifiers that the different agentsknow but also what they know about the relation of these data items. For example, an agentmay know that two data items are related, allowing that agent to link occurences of one withoccurences of the other data item.

Finally, an instantiation describes an actual sequences of protocol executions. It compriseswhich protocols are run, howoften, who plays which role in each protocol run and what data isused in those runs. With the concrete instantiation in place, the TRIPLEX tool can analysewhich items agents can link. It can show information derivable by different coalitions in agraph as explained above. Also, it can validate specific properties about agents (not) beingdetectable and data items (not) being linkable.

5.1.2 Use case: Australian Biosecurity Incident Response (BIR)

In this section, we will give a quick overview of the lifecycle of an Emergency Animal Disease(EAD) in an BIR use case. For more details the interested reader is referred to [5, Section 4 ].

One of the keys to Australias agricultural productivity and related export trade is itsfreedom from exotic diseases. To facilitate the nations disease free status, the AustralianFederal Government, along with State Governments and with key industries and researchgroups constituted a not-for-profit company, Animal Health Australia (AHA). Each each stateand territory government has responsibility for the reporting and responding to any EADincidents within its borders, supported by its own EAD legislation.

When an EAD occurs, the following order of operations is maintained. Anyone who eitherknows of, or suspects that an EAD is in progress, must by law notify the relevant organization.Furthermore, the public are encouraged to notify a hotline by phone in case of any suspicion.The investigation phase is then started, during which veterinary field officers are send toinvestigate, and if required, take samples for testing. A formal report is written, which is usedto determine the likelihood of an EAD.

If this likelihood is determined to be large enough, then the EAD is escalated to alertphase. During this phase the EAD is checked once more for validity. Next, if the EADrequires intervention, the EAD is escalated to operational phase.

During the operational phase, an EAD Response Plan is produced (EADRP), which needsto be approved, and its cost-sharing arrangements are analyzed. When the EADRP is ap-proved, it is the EADRP is initiated, after which its progress is closely monitored. Whensufficient progress has been made, the EAD is escalated to the final phase: stand-down. Thisis either the result of a successful and complete execution of the operational phase, when theEAD was confirmed, or of a transition from the alert phase if the EAD was unconfirmed.

This overview is not complete, in particular the exact responsibilities and agreements for



the varying organizations participating in the handling of an EAD is omitted. In DeliverableD1.1.1[5], a more complete overview of may be found. The most important thing to take noteof, which is not addressed by this overview, is that there are a large number of organizationsand persons involved with the handling of an EAD. Since these organizations are often notphysically close, and it would be beneficial to have access to information as well as tools duringthe meetings, a method for setting up meetings was developed which allowed this.

This method makes use of the CSIRO Collaboration Platform (CCP). A CCP unit is aworkstation which allows users to log in to a meeting and view the resources associated withthe meeting. Furthermore, it allows users that meet the given prerequisites to handle thecorresponding equipment associated with the meeting.

5.1.3 Modeling the AU2EU authentication authorisation protocol

For the purpose of this an

d6.1.1 security assessment report

Documents