SOA End to End Security

1. SOA End to End Security Department of Computer Science Purdue University West Lafayette, Indiana Program Manager: Asher Sinclair, AFRL/RISE Award No. FA8750-10-2-0152 09/27/2011 1

2. People Involved In the Project • Two Faculty Members • Ten graduate students 2

3. Outlines • Security Challenges in SOA • Problem Overview • Project Summary • Prototype Development • System Architecture and Baseline Scenario • Use Case Scenario • Service Domain Internals and Implementation • SOA Authentication Scheme (CAC/IDM) • WS-* Standard Integration • Trust Broker Subsystem • Service Registry • Taint Analysis Subsystem • Transition to Cloud Computing • Demo/Evaluation of the Proposed Solution (Security and Performance) • Schedule and Timeline • Future Tasks • Discussion • Appendixes (Publication) 3

4. Security Challenges in SOA • Authentication and authorization may not take place across intended end points • Intermediate steps of service execution might expose messages to hostile threats • External services are not verified or validated dynamically (Uninformed selection of services by user) • User has no control on external service invocation within an orchestration or through a service in another service domain • Violations and malicious activities in a trusted service domain remain undetected 4

5. SOA End to End Security Architecture 5

6. End to End Security Architecture Description Figure shows problems in end to end SOA security as follow: • In this figure the current Air Force infrastructure is shown above the red dashed line. In this architecture, all services are available in the local trusted service domain and everything is under the control of domain A. • Client at the edge platform decides to use a service from domain A. He will use his CAC (common access card) to authenticate into the system. • The security token is sent to the IDM (identity management system) for validation check. • If the user is authorized, IDM gives permission to the requested service (e.g. MX or mail service) for communication with user. • New security token (which is created temporarily for the current service session) is sent back to the user and user can use the service. • In a class of extended scenarios (use cases) the services in service domain A may want to use external services which are not in the same local trust boundary. In this case, other components come to the picture (below the dashed red line). This figure shows when service domain A (e.g. Air Force service portal) tries to access other governmental or public services (from external domains), it will lose track of end to end security. This figure shows that end points can be accessible to the client directly. We have addressed these issues by adding trust broker server and taint analysis modules (in external trusted service domains). 6

7. Use Case Scenario • An emergency response use case scenario is implemented to demonstrate the end-to-end secure service communication. In this scenario, a chemical spill near an air base is announced and there is a need to evacuate its workers safely. A service consumer/client will need three different services to gather the information necessary to announce the evacuation plan. • These services will include but it is not limited to; • a trusted local service that provides shelter locations in the city, • a public weather service for determining the chemical plume direction, and • a public timer web service that estimates the time required for workers to be evacuated to safety, which can possibly depend on another service. • This scenario is highly generic, and the involved services can be re-arranged in any order to demonstrate an end-to-end secure service communication. We are also evaluating other scenarios for complex service interactions. 7

8. Project Summary To address these challenges, we designed and implemented: • A comprehensive security architecture for SOA. • A novel service invocation control mechanism for SOA using dynamic taint analysis (TA) • A trust broker (TB) system that maintains trust and classifies services. TB is used for dynamic validation and verification of services and keeps track of history of service invocations. • functionality for using widely adopted web service WS-* standards (WS-Security, WS-Trust) for enterprise Air Force systems. • A secure end-to-end message origin authentication for web service client requests and web service providers to ensure confidentiality and integrity—even in the presence of man-in-the-middle attacks. This solution is based on CAC. • A prototype implementation of proposed approaches based on open source technologies that can be possibly integrated into existing government-off-the-shelf (GOTS) components in an operational environment. 8

9. System Architecture and SOA Baseline Scenario • UDDI Registry request • Forwarding the service list to Trust Broker and receive a categorized list • Invoking a selected service • Second invocation by service in domain A • Invoking a service in public service domain • End points (Reply to user) 9

10. Baseline Scenario Details • Steps: • Global UDDI Registry request • User receives a list of services related to the requested category • User sends a refined list of services to Trust Broker module • Trust Broker categorizes the list of services and returns a classified list • Trust categories: Certified, Trusted, Untrusted services • Service Request • User selects a service based on its criteria (QoS, Trust category of service, Security preference, etc.) and invokes that service. • User creates a session with Trust Broker and selected service in Trusted Domain A. (Trust sessions are shown with dashed lines) 10

11. Baseline Scenario Details (Cont.) • Trusted domain A will invoke another service in Trusted domain B. • Taint Analysis module will intercept the communications and reports any illegal external invocation • Trust session will be extended to this domain (a new trust link between domain A and trust broker) • Step four is repeated. • At this moment, an external service invocation to a public service is detected by Taint Analysis module • This will be reported to Trust Broker. Trust Broker will maintain the trustworthiness of this SOA service orchestration and if needed can stop it. • Service in service domain B invokes a service in an public (Maybe untrusted) domain C (Possibility of deploying Taint Analysis in this domain) • Service end points to user • The response of SOA invocation can be sent directly to the user 11

12. Solution Components: Service Domains 12

13. Service Domain Internals 13

14. Service Domain Internals • Gateways/Listeners: Clients accesses the services in each service domain using multiple protocols like HTTP, JMS, and Sockets. The list of accepted protocols, gateways and listeners is specified in ESB meta-data file (jboss-esb.xml). Upon receiving a service request, ESB server invokes the requested service such as weather service in our prototype. Each domain maintains a local registry. Local registry keeps track of available local services, which are available to other local services. These services need to contact a global registry or to be configured manually to access external services. • All services, in a specific service domain, are in the same ESB (Enterprise Service Bus). ESB is used for message passing. • JBoss ESB is configured to provide WS-* functionality to services. • Taint analysis module is used to monitor service invocations( information flow control monitoring) • In the current implementation, we support both HTTP and JMS protocols. But, any other standard protocol could be easily supported. 14

15. Primary Service Evacuation Timer web service • The evacuation timer web service takes as input the output from the Weather report web service. This service is invoked using a soap action. This is a locally deployed service that requires a remote service (weather report web service) for it complete its operation. The deployment is again through an ESB container. The final SOAP message reply from the Evacuation timer is returned back finally. • APIs • getExacuationTime() • GetEvacuationTimeResponse() 15

16. Outsourced Service Weather Report web service • This is an independent service which is deployed as part of its own ESB. This service can be deployed as an external service in a remote machine. Only the endpoints of the service are required for a client to communicate with this service. This web service includes a python script that uses Google Weather API to fetch the weather information for a given zip code. The response is sent back to the client invoking the web method. • APIs • getReport() • GetWeatherReportResponse() 16

17. Solution Components: Authentication 17

18. Authentication SOA Authentication Scheme (CAC/IDM) • Edge platform’s CAC certificate for service request authentication • CAC and IDM modules are parts of authentication mechanism • Embedding the certificate into WS-Security SOAP envelope 18

19. Authentication CAC-based Service Authentication • Set up SCR3310 Common Access Card Reader in Ubuntu 10.10 • Libraries/Packages installed • CoolKey – Linux driver support for CAC • pcsc tools – Middleware to access smart card • DoD Root Certification Authority Certificates • SCR3310 Device drivers for Linux • Integrating CAC authentication to the solution 19

20. Solution Components: Trust Broker 20

21. Trust Broker • Calculates trust for a given set of services: • Given a set of services identified with UDDI service keys, Trust Broker returns trust categories for all of those services as determined by the Trust Evaluation Subsystem. • Manages end to end user/service-invocation session. 21

22. Trust Broker Trust Evaluation Subsystem • Classification of services into Trust categories • Certified (supports WS-* specifications and has Taint Analysis Module) • Trusted (having Trust value above threshold) • Untrusted (having Trust value below threshold) • Trust calculation is based on parameters such as: • WS-* support specified in Service Level Agreement (SLA) • Trustworthiness of services in Orchestration specified in SLA • History of previous service runs (Using sessions) • Taint analysis feedback • User experience feedback 22

23. Trust Broker Trust Evaluation Subsystem • Calculating Trust • Using weighted moving average model • Recent feedbacks for a service are weighted more heavily than feedback further in the past • The trust value for a service S, with SLA L, getting feedback F at timet is updated using the equation: where α < 0.5 and β is evaluated based on the appropriate WS-* supported 23

24. Trust Broker Session Management Subsystem • Extending the Trust boundary • Manages end to end service invocation session • User creates a session with Trust Broker and selected service • Enforcing end to end Trust across different domains • Trust session extended to other service domains • Auditing service behavior including violation and malicious activities • Taint Analysis and user feedback to Trust Broker for updating Trust • Trust Maintenance 24

25. Trust Broker Trust Broker Implementation • Implemented as a Web Service in Java SE 6.0 • Uses a MYSQL database to store service trust and history as well as session specific information • Queries UDDI using a Ruddi client upon method invocation for calculating the trust value of a service, to obtain SLA including WS-* protocol compliance and service composition 25

26. Solution Components: Service Registry 26

27. Service Registry • Services publish to UDDI using jUDDI-Publish service API • Client and trust broker query service category using jUDDI-Inquiry service API • Implementation Details • UDDI Setup – Apache jUDDI v3.04 • UDDI Client – Ruddi • UDDI APIs • queryUDDI(serviceName) 27

28. Taint Analysis • What is Taint Analysis? • Related to IFC (Information Flow Control) • How it fits into solution for AFRL? • Independent of services (We do not need to change the services or access the source code of services) • Interception of Service execution (Service will remain transparent) 28

29. Taint Analysis • Using AOP (Aspect Oriented Programming) • Instrumenting classes based on predefined pointcuts • Low performance overhead (ideal solution) • How it works? • Load-time instrumentation • The whole Application server is under control • Granularity • Package/Class level • Method level • Field level • Instrumenting classes in action pipeline 29

30. Interaction of Taint Analysis and Trust Broker 30

31. Taint Analysis of Services 31

32. Taint Analysis • Where to put this module? • Two possible deployment options • Only in Trusted Service Domains • Detection of insider attacks • Detection of compromised services • Detection of outbound connections • In Public Domain • Enforcing service composition policies 32

33. Other Frameworks • Frameworks have been evaluated: • WALA (IBM) –Static (Shrike) and Dynamic (Dila) java bytecode analysis and instrumentation –High overhead • BCEL (Apache) • Java bytecode instrumentation • Static/high overhead • JavaSnoop • AOP • AspectJ • Spring AOP • Jboss AOP (Selected Framework) 33

34. WS-* Standards Support • WS-Security • The system prototype uses the Apache CXF Framework leveraging WSS4J to provide WS-Security functionalities. WSS4J security is triggered through interceptors that are added to the services and the client. These interceptors allow performing the WS-Security related processes including: passing authentication tokens between services; encrypting messages or parts of messages; and signing messages. • WS-Trust • WS-Trust defines the concept of a security token service (STS), a service that can issue, cancel, renew and validate security tokens, and specifies the format of security token request and response messages as well as ways to establish, assess the presence of, and broker trust relationships between participants in a secure message exchange 34

35. WS-* Standards Support • WS-Trust Elements • Security Token Service (STS)- a web service that issues, cancels, renews and validates security tokens as defined in the WS-Security specification. • Format of security token request and response messages. • Mechanisms for key exchange. • Implementation • We use the open source implementation of STS known as PicketLink by the JBoss community. It is an implementation of the WS-Trust Security Token Service. The PicketLink STS does not issue tokens of a specific type. Instead, it defines generic interfaces that allow multiple token providers to be plugged in. As a result, it can be configured to deal with various types of token, as long as a token provider exists for each token type. It is packaged as a war file and deployed as a regular service in the JBoss ESB. We have used in our implementation. 35

36. Lab Setup • All 4 lab machines running: • Ubuntu 10.10 • JBoss ESB Server 4.9 • Source Control (CVS) • Evaluation Tools: • SoapUI/LoadUI • Wireshark (sniffing) • TCPMon 36

37. Evaluation of the Proposed Solution • Security Evaluation • The implemented prototype will be evaluated in terms of its effectiveness in mitigating various attacks including the following attacks • XML Rewriting Attack • DoS Attack • Performance Evaluation • Response Time • Throughput 37

38. SOA Security Evaluation • We are evaluating the proposed prototype in terms of its effectiveness in mitigating various attacks • In-transit Sniffing or Spoofing • While information in SOAP message is in transit on the wire, various entities can see it • SOAP messages could be spoofed by various tools • Attack Scenarios • XML Rewriting Attack • Replay Attacks • They poison the SOAP messages and send them to a server with a forged client signature. • This attack can be lethal since an attacker spoofs a user’s identity • Denial of Service attack 38

39. XML Rewriting Attack Web service provider Attacker WS Client • Exploring how certain XML rewriting attacks can be detected by the Tainted Analysis component and Trust Broker • XML rewriting attack commonly refers to the class of attacks which involve in modifying the SOAP message. (Replay, Redirect, Man in the middle, multiple header etc.)

40. XML Rewriting Attack-Cont. • Basic Replay Attack: Replace the entire current message with an old message. (Assuming no security headers present) • Replay when security headers present : Replace the current SOAP body with an old SOAP body but keep the current SOAP body at the same time to satisfy the security validations. 40

41. Web Service A MethodCall( param ) { } XML Rewriting (Replay Attack) XML Rewriting Attack Web Service B Web Service C • Cache the messages and replay old messages on Web service A which will then make subsequent calls from A to have older session ID/ Message ID.

42. XML Rewriting Attack Generation • We extended TCPMon which is an Open source debugging utility for web service calls. • The tool listens on a specified port and collect the request and response messages. • Customized to intercept, change the SOAP message (redirect or replay) and resent to the receiver. • Examine how the Tainted analysis and Trust broker modules behave in this case.

43. Denial of Service Attack (DoS) • Study the effect of DoS attacks on different components • Trust Broker • Investigating the security implications of placing the TB under DoS attack • Application server • What happens of the trusted application server (but not services) is under DoS attack? • Services • How system behaves if services are under DoS attacks 43

44. SOA Performance Evaluation • The runtime performance of the implemented prototype is being evaluated in terms of the overhead caused by the various security components used in the system. • Tools • SOAPUI/LoadUI • The following measurements are being measured • System Throughput • Comparing the baseline setting (without taint analysis and trust broker) to the final secure setting • Investigating the effect of stress tests on the scalability of trust broker • Response Time • Quantifying the delay overhead due to use of taint analysis and trust broker • Measuring Evaluating the effect of system parameters ( e.g. timeouts, message sizes and frequency of sending messages) and determining optimal parameters 44

45. Cloud Computing • Software as a service: Shared computing resources that are virtualized and accessed as a service, through an API. • The cloud enables users in an organization to run applications by deploying them to the cloud, a virtual datacenter. 45

46. Why Cloud Computing? • Incremental Scalability: Cloud environments allow users to access additional compute resources on-demand in response to increased application loads • Agility:As a shared resource, the cloud provides flexible, automated management to distribute the computing resources among the cloud's users • Reliability and Fault-Tolerance: Cloud environments take advantage of the built-in redundancy of the large numbers of servers that make them up by enabling high levels of availability and reliability for applications that can take advantage of this. 46

47. Why Cloud Computing? (cont.) • Service-oriented: The cloud is a natural home for service-oriented applications, which need a way to easily scale as services get incorporated into other applications. • Utility-based: Users only pay for the services they use, either by subscription or transaction-based models. • Shared: By enabling IT resources to be consolidated, multiple users share a common infrastructure, allowing costs to be more effectively managed without sacrificing the security of each user's data. • SLA-driven: Clouds are managed dynamically based on service-level agreements that define policies like delivery parameters, costs, and other factors. 47

48. Transition to Cloud Computing • Had grant to use Yahoo’s Compute Cluster: • Hard to customize, lacking documentation, high down-time • Amazon EC2 Cloud was used to study the impact of migration of the proposed end-to-end security solution to the Cloud. • In this setting, service domains were placed in Amazon EC2 AMIs (Amazon Machine Instances) • We have conducted experiments to measure the performance impact of using cloud computing. • We installed and configured the following components in the Amazon Cloud (same configuration as on-site): • Jboss ESB Server and services • Trust Broker • UDDI 48

49. Experience with Moving to Cloud • Local IP address is not accessible IP address • Amazon Dynamic Address Translation • Instance IP vs. Public IP • Instance IP is not public, we need to bind Elastic IP with an instance for public access • Deployed applications need to acknowledge accessible IP and they take local IP as default accessible IP • Solution: Hard-coded EIP in source code • Multi-tenancy • Sharing resources hampers resource availability and performance estimation • Could pose additional security threats 49

50. Experience with Moving to Cloud • Need to make snapshot and store in S3 for each update • Each time you terminate your instance, it would erase all your changes on this instance. • Security Group configuration allows for restricted access to instances 50