1. Mr. Abdelkrim Boujraf, Unisys Mr. Andreas Schaad, SAP Research Mr. Mohammad Ashiqur Rahaman, SAP Research funded by EU Integrated Project R4eGov R4eGov Inter-Agency Collaboration – Security Performance Measurement

2. Evaluating WS * vs. SOAP Accounts R4eGov Inter-agency collaboration WS Performance Criteria AGENDA Evaluation Results

3. The problem…. The majority of eGovernment systems is and may have to remain heterogeneous. Their configuration and definition of processes is likely to remain under local administration. eGovernment interoperability in the EU follows an ad hoc approach and systems are only made interoperable when there is a shared purpose and some general legal guidelines. We believe the majority of systems to require the methodologies, systems and tools for achieving the maturity level of collaborative organisations. * Europol and Eurojust are SAP EU project partners but not SAP customers. The case study is for illustration / requirements engineering purposes only.

4. EU Interagency Collaboration - The reality…. During a routine check Spanish customs intercept a shipment of coffee containing cocaine in the harbour of Malaga. The container came from Caracas, Venezuela and was supposed to be transported by road to Antwerp and to be delivered to a trade company called BE. A number of persons are taken into custody, whilst investigations start….. The involved authorities (Europol and Eurojust)* need to collaborate in a quick and efficient manner. – European Arrest Warrant – Rogatory Letter – Joint Investigation Teams – …. They need to remain in control of their systems They need to follow local as well as EU-wide laws and agreements * Europol and Eurojust are SAP EU project partners but not SAP customers. The case study is for illustration / requirements engineering purposes only.

5. Europol and Eurojust Eurojust Eurojust National Members, Case Management Analysts EJN Secretariat, National Correspondents, EJN Contact Points National judicial authorities Europol Member States (MS) Analysis Work File Teams (AWFTs) Europol Liaison Officers (ELOs) Member States Liaison Bureaux (MS-LBx) Serious Crime Units (SCUs) / Analysis Unit (SC7) Liaison Officer Interpol / Washington DC * Europol and Eurojust are SAP EU project partners but not SAP customers. The case study is for illustration / requirements engineering purposes only.

6. Towards standardised collaboration processes * Europol and Eurojust are SAP EU project partners but not SAP customers. The case study is for illustration / requirements engineering purposes only. * Europol and Eurojust are SAP EU project partners but not SAP customers. The case study is for illustration / requirements engineering purposes only.

7. Requirements Local case management Exchange of documents Access Control on documents Traceability Chain of evidence European and Local Directives on Data Usage Collaboration agreements Can in parts be addressed by using OASIS WS* standards.

8. General WS Security Setup WS-Policy describes the capabilities and constraints on intermediaries and endpoints (e.g. required security tokens, supported encryption algorithms) WS-SecureConversation describes how to manage and authenticate a series of message exchanges Requester Web Service Security Token Service Policy Security Token Claims Policy Security Token Claims Security Token Claims WS-Security attaching signature and encryption headers / security tokens to SOAP messages e.g. X.509 certificates and Kerberos tickets, to messages WS-Trust describes a framework for trust models that enables Web services to trust other domains

9. Performance / A general Web Service invocation flow Some Performance Relevant Criteria (incomplete) –Methods for issuing, renewing, and validating security tokens; –Establishing security contexts for a conversation of messages. –Amending, Renewing, and cancelling the security contexts. –Computing and passing derived keys and session keys. –Verify Subjects / Security Attributes

10. Approach to Performance Measurement Our Problem: What can we measure performance against? No real benchmarks for WS* Performance Measurement. Our Approach: Build our own solution for defined purpose scope Measure WS* key performance indicators against this Our (simplified) requirements: Preservation of message confidentiality / integrity Handling of complex / large messages Focus on prevention of XML re-writing attacks Our Proposal: SOAP Account: Keeps record of SOAP message structure / elements. Requires small component to be deployed on each SOAP processing node.

11. SOAP Account: Message flow in the proposed technique

12. A SOAP request using a SOAP Account …… MIIEZzCCA9CgAwIBAgIQEmtJZc0... d5AOd..=....... e4EyW...= RST token is signed Receiver can verify 2 http://schemas.xmlsoap.org/ws/2005/02/sc/sct http://schemas.xmlsoap.org/ ws/2004/04/security/trust/Issue... SOAP Account added

13. Simulated SOAP, WS Policy, SOAP Account ……... …… …...... e4EyW...= … http://schemas.xmlsoap.org/ws/2005/02/sc/sct http://schemas.xml soap.org/ ws/2004/04/security /trust/Issue ….. SOAP WS Policy 2 SOAP Account 2695 bytes to 51551 bytes 388 bytes 197 bytes

14. Performance Criteria Request SOAP size vs. requestor Soap Account header size and Policy file size. SOAP Account size vs. Policy file size. Relative comparison of signature processing in both ends. Enforcement time of SOAP Account and Policy in sender (requestor). Enforcement time of SOAP Account and Policy in the receiver. XML rewriting attack detection time using SOAP Account and Policy. Results/Chart Comparison Criteria SOAP Size 2695 to 51551 bytes SOAP Account 197 bytes ~0.72% of SOAP Policy File 388 bytes ~1.42% of SOAP Scalability. ~15% more time in the Requestor Comparable enforcement time for both in the Requestor. ~15% less time in the Receiver ~1.50 % faster XML Rewriting Attack Detection using SOAP Account. SOAP Account is scalable. ~30% less Enforcement time using SOAP Account in the Receiver.  SOAP size > 4500 bytes..SOAP Account Enforcement Time ~ Policy Enforcement Time. 1. SOAP Account Processing. 2. Policy processing. 3. Signature Processing. 4. Attacker Simulation

15. Summary & Conclusion We presented a „real-world“ collaboration scenario and security requirements WS* can be deployed to satisfy some of these requirements WS* Security performance indicators Measure these indicators against our own SOAP account solution In summary, our solution is more performant due to being purpose-built for avoiding XML rewriting attacks (overly simplified). Not really „scientific“ approach but valuable lessons learnt on: Establishing a set of Security / Web Service Performance Indicators Implementation and Setup, Memory Consumption, Processing, Key Generation, Validation, Message Sizing etc. Current research work is focusing on XACML testing Overall goal is a general test tool suite for standards evaluation

16. Thank You & Questions abdelkrim.boujraf@be.unisys.com andreas.schaad@sap.com mohammad.ashiqur.rahaman@sap.com * Europol and Eurojust are SAP EU project partners but not SAP or Unisys customers. The case study is for illustration / requirements engineering purposes only.