SOA End to End Security

SOA End to End SecurityDepartment of Computer SciencePurdue University West Lafayette, Indiana Award No. FA8750-10-2-0152 Program Manager: Asher Sinclair, AFRL/RISE 09/27/20111People Involved In the ProjectTwo Faculty MembersTen graduate students2OutlinesSecurity Challenges in SOAProblem OverviewProject SummaryPrototype DevelopmentSystem Architecture and Baseline ScenarioUse Case ScenarioService Domain Internals and ImplementationSOA Authentication Scheme (CAC/IDM)WS-* Standard IntegrationTrust Broker SubsystemService RegistryTaint Analysis SubsystemTransition to Cloud ComputingDemo/Evaluation of the Proposed Solution (Security and Performance)Schedule and TimelineFuture TasksDiscussionAppendixes (Publication)3Security Challenges in SOAAuthentication and authorization may not take place across intended end points Intermediate steps of service execution might expose messages to hostile threatsExternal 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 domainViolations and malicious activities in a trusted service domain remain undetected4SOA End to End Security Architecture5End to End Security Architecture DescriptionFigure 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). 6Use Case ScenarioAn 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.7Project SummaryTo 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. 8System Architecture and SOA Baseline ScenarioUDDI Registry requestForwarding the service list to Trust Broker and receive a categorized listInvoking a selected serviceSecond invocation by service in domain AInvoking a service in public service domainEnd points (Reply to user)9Baseline Scenario DetailsSteps:Global UDDI Registry requestUser receives a list of services related to the requested categoryUser sends a refined list of services to Trust Broker moduleTrust Broker categorizes the list of services and returns a classified listTrust categories: Certified, Trusted, Untrusted servicesService RequestUser 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)10Baseline 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 invocationTrust 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 moduleThis 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 user11Solution Components: Service Domains12Service Domain Internals13Service Domain InternalsGateways/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.14Primary ServiceEvacuation Timer web serviceThe 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.APIsgetExacuationTime()GetEvacuationTimeResponse()15Outsourced ServiceWeather Report web serviceThis 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.APIsgetReport()GetWeatherReportResponse()16Solution Components: Authentication17AuthenticationSOA Authentication Scheme (CAC/IDM)Edge platform’s CAC certificate for service request authenticationCAC and IDM modules are parts of authentication mechanismEmbedding the certificate into WS-Security SOAP envelope18AuthenticationCAC-based Service AuthenticationSet up SCR3310 Common Access Card Reader in Ubuntu 10.10Libraries/Packages installedCoolKey – Linux driver support for CACpcsc tools – Middleware to access smart cardDoD Root Certification Authority CertificatesSCR3310 Device drivers for LinuxIntegrating CAC authentication to the solution19Solution Components: Trust Broker20Trust BrokerCalculates 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.21Trust BrokerTrust Evaluation SubsystemClassification 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 feedbackUser experience feedback 22Trust BrokerTrust Evaluation SubsystemCalculating TrustUsing weighted moving average modelRecent feedbacks for a service are weighted more heavily than feedback further in the pastThe trust value for a service S, with SLA L, getting feedback F at time t is updated using the equation: where α < 0.5 and β is evaluated based on the appropriate WS-* supported 23Trust BrokerSession Management Subsystem Extending the Trust boundaryManages end to end service invocation sessionUser creates a session with Trust Broker and selected serviceEnforcing end to end Trust across different domainsTrust session extended to other service domainsAuditing service behavior including violation and malicious activitiesTaint Analysis and user feedback to Trust Broker for updating Trust Trust Maintenance24Trust BrokerTrust Broker ImplementationImplemented as a Web Service in Java SE 6.0Uses a MYSQL database to store service trust and history as well as session specific informationQueries 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 composition25Solution Components: Service Registry26Service RegistryServices publish to UDDI using jUDDI-Publish service APIClient and trust broker query service category using jUDDI-Inquiry service APIImplementation DetailsUDDI Setup – Apache jUDDI v3.04UDDI Client – RuddiUDDI APIsqueryUDDI(serviceName)27Taint AnalysisWhat 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)28Taint AnalysisUsing AOP (Aspect Oriented Programming)Instrumenting classes based on predefined pointcutsLow performance overhead (ideal solution)How it works?Load-time instrumentationThe whole Application server is under controlGranularityPackage/Class levelMethod levelField levelInstrumenting classes in action pipeline29Interaction of Taint Analysis and Trust Broker30Taint Analysis of Services31Taint AnalysisWhere to put this module?Two possible deployment optionsOnly in Trusted Service DomainsDetection of insider attacksDetection of compromised servicesDetection of outbound connectionsIn Public DomainEnforcing service composition policies32Other FrameworksFrameworks have been evaluated:WALA (IBM) –Static (Shrike) and Dynamic (Dila) java bytecode analysis and instrumentation–High overheadBCEL (Apache)Java bytecode instrumentationStatic/high overheadJavaSnoopAOPAspectJSpring AOPJboss AOP (Selected Framework)33WS-* Standards SupportWS-SecurityThe 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-TrustWS-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 exchange34WS-* Standards SupportWS-Trust ElementsSecurity 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.ImplementationWe 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.35Lab Setup36All 4 lab machines running: Ubuntu 10.10JBoss ESB Server 4.9Source Control (CVS)Evaluation Tools:SoapUI/LoadUIWireshark (sniffing)TCPMon Evaluation of the Proposed SolutionSecurity EvaluationThe implemented prototype will be evaluated in terms of its effectiveness in mitigating various attacks including the following attacksXML Rewriting AttackDoS AttackPerformance EvaluationResponse TimeThroughput37SOA Security EvaluationWe are evaluating the proposed prototype in terms of its effectiveness in mitigating various attacksIn-transit Sniffing or SpoofingWhile information in SOAP message is in transit on the wire, various entities can see itSOAP messages could be spoofed by various tools Attack ScenariosXML Rewriting AttackReplay AttacksThey 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 identityDenial of Service attack38XML Rewriting AttackExploring how certain XML rewriting attacks can be detected by the Tainted Analysis component and Trust BrokerXML 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.)WS ClientAttackerWeb service providerXML 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.40XML Rewriting (Replay Attack)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.Web Service AMethodCall( param ) {}Web Service BWeb Service CXML RewritingAttackXML Rewriting Attack GenerationWe 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.Denial of Service Attack (DoS)Study the effect of DoS attacks on different componentsTrust BrokerInvestigating the security implications of placing the TB under DoS attack Application serverWhat happens of the trusted application server (but not services) is under DoS attack?ServicesHow system behaves if services are under DoS attacks43SOA Performance EvaluationThe runtime performance of the implemented prototype is being evaluated in terms of the overhead caused by the various security components used in the system.ToolsSOAPUI/LoadUIThe following measurements are being measuredSystem Throughput Comparing the baseline setting (without taint analysis and trust broker) to the final secure settingInvestigating the effect of stress tests on the scalability of trust brokerResponse TimeQuantifying the delay overhead due to use of taint analysis and trust brokerMeasuring Evaluating the effect of system parameters ( e.g. timeouts, message sizes and frequency of sending messages) and determining optimal parameters44Cloud ComputingSoftware 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.45Why Cloud Computing?Incremental Scalability: Cloud environments allow users to access additional compute resources on-demand in response to increased application loadsAgility: As a shared resource, the cloud provides flexible, automated management to distribute the computing resources among the cloud's usersReliability 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.46Why 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.47Transition to Cloud ComputingHad 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 servicesTrust Broker UDDI48Experience with Moving to CloudLocal IP address is not accessible IP addressAmazon Dynamic Address TranslationInstance IP vs. Public IPInstance IP is not public, we need to bind Elastic IP with an instance for public accessDeployed applications need to acknowledge accessible IP and they take local IP as default accessible IPSolution: Hard-coded EIP in source code Multi-tenancy Sharing resources hampers resource availability and performance estimation Could pose additional security threats49Experience with Moving to CloudNeed to make snapshot and store in S3 for each updateEach time you terminate your instance, it would erase all your changes on this instance.Security Group configuration allows for restricted access to instances50Cloud Setup – Baseline 51Cloud Setup – Taint Analysis 52Performance Measurement in the CloudMeasurements:System Throughput Comparing the baseline setting (without taint analysis and trust broker) to the final secure settingInvestigating the effect of stress tests on the scalability of trust brokerResponse TimeQuantifying the delay overhead due to use of taint analysis and trust brokerExperiment Setup:LoadUI client and Amazon machine instances in the east region (Virginia)Simultaneous requests to the same service by different number of threadsContinuous requests to the same service for a fixed time period (60 sec)53Exp1:Trust Broker Performance54Exp2: Taint Analysis Impact55Response Time for LAN Scenario56Provisioning Cloud Cost57 Demand Instances Provisioning Cloud Cost (cont.)58 Instances Provisioning Cloud Cost (cont.)59 Transfer Cloud Auto-Scaling (Elasticity)Provided by Amazon CloudWatch:Scales out Amazon EC2 instances seamlessly and automatically when demand increases.Sheds unneeded Amazon EC2 instances automatically to save money when demand subsides.Scales dynamically based on Amazon CloudWatch metrics, or predictably according to a defined schedule. 60Challenges/IssuesActive Bundle solutionActive bundle concept is prototyped based on a mobile agent framework (JADE)Discovered redundancy between capability of Active Bundles and JBoss ESBTaint AnalysisStandard solutions are mainly low level (OS level) and are not suitable for intercepting services in an application serverCurrent solutions for taint analysis are generally heavy weight and are not suitable for application serversWe decided to use AOP technology to overcome these challenges.Several AOP solutions availableAspectJ and Spring AOP are not suitable for current setting. (Level of granularity and performance)Jboss AOP finally selected for implementation in prototype. 61Challenges/Issues (cont.)Trust BrokerProne to DoS attacksCan become single point of failureFixing with Load Distribution and ClusteringWS-SecurityIntroduces significant delay in response time and computational overhead on services and trust broker62Schedule and Timeline63Demo ScenarioTwo evacuation timer services (ET1:certified, ET2:untrusted) and two weather report services (W1:certified, W2:untrusted)ET1 has dynamic service composition: For zipcodes < 20000, it invokes W2, for others W1ET2 always uses W2 for getting the weather reportAll communication is encrypted using WS-Security64End-to-End Security Demo65Attack Scenario Screenshots66Potential TasksOffloading the non-security-critical computation to the cloud Using TPMs along with taint analysis framework to provide a stronger security Providing active defense and attack-resiliency using cloud computing 67Discussion68Appx A. Papers (Under preparation)The Design and Implementation of End to End Security in Service Oriented ArchitectureEnabling End to End Security in Service Oriented Architecture Using Taint Analysis Security of Service Oriented Architecture in Cloud ComputingHarnessing the Power of Trust Management to Secure Service Oriented ArchitectureAdapting Web Service Security Standards for Securing Service Oriented ArchitectureSOA Security: Challenges and Solutions (A Survey Paper)69Appx. B: Published PapersB. Bhargava, P Angin, R. Sivakumar, M. Linderman, and M. Kang, A. Sinclair, A Trust- based Approach for Secure Data Dissemination in a Mobile Peer-to- Peer Network of UAVs, To appear in Special Session on Collaboration for Dynamic Resource Management in Mobile P2P Networks (CDRM 2011), International Conference on Collaboration Technologies and Systems (CTS 2011), May 2011, Philadelphia.N. Idika, B. Bhargava. A Kolmogorov Complexity Approach for Measuring Attack Path Complexity, in Proceedings of IFIP International Information Security (SEC 2011) conference, June 2011, Lucerne, Switzerland.P. Angin, B. Bhargava, R. Ranchal, N. Singh, L. Lilien, L. Othmane, M. Linderman. A User-Centric Approach for Privacy and Identity Management in Cloud Computing, in Proceedings of 29th IEEE Symposium on Reliable Distributed System (SRDS), Nov 2010, New Delhi, India.R. Ranchal, B. Bhargava, L. Othmane, L. Lilien, A. Kim, M. Kang, M. Linderman. Protection of Identity Information in Cloud Computing without Trusted Third Party, in Proceedings of Third International Workshop on Dependable Network Computing and Mobile Systems (DNCMS 2010) in conjunction with 29th IEEE Symposium on Reliable Distributed System (SRDS), Oct 2010, New Delhi, India.B. Bhargava, N. Singh, A. Sinclair, Privacy and Security in Cloud Computing through Identity Management: Microsoft Cardspace, appear in International Conference on Advances in Computing and Communication ICACC-11, April, 2011, India.70Appx. B: Published Papers (Cont.)T. Bao, Y. Zheng, Z. Lin, X. Zhang and D. Xu, Strict Control Dependence and Its Effect on Dynamic Information Flow Analyses ,International Symposium on Software Testing and Analysis, Trento, Italy, 2010Z. Lin, X. Zhang, and D. Xu, Convicting Remote Exploitable Vulnerabilities: An Efficient Input Provenance Based Approach, Proceedings of IEEE/IFIP International Conference on Dependable Systems and Networks, 2008.71