10/09/2006CIS Dept., UMass Dartmouth1 A Petri Net Based XML Firewall Security Model for Web Services Invocation Prof. Haiping Xu Concurrent Software Systems Laboratory Computer and Information Science Department University of Massachusetts Dartmouth

10/09/2006CIS Dept., UMass Dartmouth2 Outline  Web Services and XML Firewall  XML Firewall Architecture  Introduction to Petri Nets  Petri Net Models for XML Firewall  Formal Analysis of Petri Net Models  Conclusions and Future Work

10/09/2006CIS Dept., UMass Dartmouth3 Introduction to Web Services  Web Services are Internet-based software components that support open, XML-based standards and communication protocols.  A Web Service is a software component defined using WSDL, registered using UDDI, and invoked using SOAP.  Web Services make software functionality available over the Internet.

10/09/2006CIS Dept., UMass Dartmouth4 Web Services Roles  Service Provider  Service Provider implements the service and makes it available on the internet.  Service Requester  Service Requester utilizes an existing web service by opening a network connection and sending a request.  Service Broker  Service Broker is centralized directory of the web services.

10/09/2006CIS Dept., UMass Dartmouth5 Security Issues in Web Services Invocation  A very common way of accessing web services is to remotely invoke web services.  A service provider may be under attack if a consumer uses a false identity to invoke a web service. a consumer accesses a web service without properly assigned permissions. a consumer attempts to corrupt a web service by attacking the service provider (e.g., using a denial of service attack).

10/09/2006CIS Dept., UMass Dartmouth6 Conventional Firewall  Firewall:  Firewall: a fireproof wall used as a barrier to prevent the spread of a fire.  Firewall: a component that limits network access.  Types of firewalls packet filtering application proxy personal firewall Server Machines Firewall Client Machines Internet

10/09/2006CIS Dept., UMass Dartmouth7 Why XML Firewall ?  A conventional firewall typically does not block port 80 used by HTTP, so malicious web service requests cannot be blocked. does not support parsing or validating XML data. does not support authentication and authorization for web services access.  An XML firewall can control access to web services rather than simply to filter untrusted addresses. inspect a complete XML message including its head and data segments. support authentication and authorization for web services invocation.

10/09/2006CIS Dept., UMass Dartmouth8 Features of the XML Firewall  Grant only those users who are properly authenticated and authorized for access of web services.  Use role base access control (RBAC) for authorization.  Develop security policies by identifying security threats.  Develop policy rules based on system state.  Examine the contents of the incoming traffic.

10/09/2006CIS Dept., UMass Dartmouth9 Protecting Service Provider XML Firewall Request Application Logic Web Service 1 Web Service n Admin Policy Change Request User Interface … Response Request User State Info Service Provider Response Application (Service Consumer)

10/09/2006CIS Dept., UMass Dartmouth10 XML Firewall Architecture User LoginComputational Logic [valid user] authenticate user [valid] [invalid] Assign Role UserinfoDB Create User Space StateDB PolicyDB Access Request Invoke Service Web Service 1Web Service n Return Results check_ permissions [access passed] RoleDB [access denied] … XML Firewall Application

10/09/2006CIS Dept., UMass Dartmouth11 Introduction to Petri Net  “Three-in-one” capability of Petri net models [Murata 1989] Graphical representation Mathematical description Simulation tool  Definition: A Petri net is a 4-tuple, PN = (P, T, F, M 0 ) where P = {P1, P2, …, Pm} is a finite set of places; T = {t1, t2, …, tn} is a finite set of transitions; F  (P x T)  (T x P) is a set of arcs (flow relation); M 0 : P --> {0, 1, 2, 3, …} is the initial marking.

10/09/2006CIS Dept., UMass Dartmouth12 An Example P4 P2 P5 t1 t5 t3 t4 t2 P1 P3

10/09/2006CIS Dept., UMass Dartmouth13 Petri Net Model of an Application

10/09/2006CIS Dept., UMass Dartmouth14 Petri Net Model of XML Firewall

10/09/2006CIS Dept., UMass Dartmouth15 Adding Policy Change Interface

10/09/2006CIS Dept., UMass Dartmouth16 Formal Analysis of the XML Firewall Model  To help ensure a correct design that meets certain specifications  To meet certain requirements such as liveness, deadlock freeness and concurrency  Use Petri net tool: INA (Integrated Net Analyzer) Verifying structural properties Verifying behavioral properties Detecting design errors

10/09/2006CIS Dept., UMass Dartmouth17 Formal Analysis for the Application Model Deciding structural boundedness The net is structurally bounded. The net is bounded. Computation of the reachability graph States generated: 238 The net has no dead transitions at the initial marking. The net has no dead reachable states. The net is safe. Liveness test: Computing the strongly connected components The net is live. The net is live, if dead transitions are ignored. The net is live and safe. The net is reversible (resetable).

10/09/2006CIS Dept., UMass Dartmouth18 Formal Analysis for the XML Firewall Model Deciding structural boundedness The net is structurally bounded. The net is bounded. Computation of the reachability graph States generated: 126 Write the state numbers of the dead states? Y/N Y The net has dead reachable states. The net is not live. The net is not live and safe. The net is not reversible (resetable). The deadlock-trap-property is not valid. The net has no dead transitions at the initial marking. The net is not live, if dead transitions are ignored. The net is safe. The dead states are shown as follows State nr. 39 P.nr: toks:

10/09/2006CIS Dept., UMass Dartmouth19 Corrected XML Firewall Model Start_Authorization Access_Request Create_ Session Fail User_Request Computational_ Logic Init/Result WS_Request Check_If_Existing First_Time _User Existing_User Perform_ Background_ Check BG_Check_DB Check_ _Failed Check_ Passed Update_ Databases Role_DB Assign_Role Fetch_State _Info User_Role Policy_DB Fetch_ Policy Create_UserSpace UserSpace (Username, Permissions, Session) Check_Permission Pass Access _Failed WS_Logic Accept _Result Accept_WS_Response FW_ Result UserInfo_DB StateInfo Valid_User _Request Access_ Denied State_DB Application Permission_Result Change_Policy_ Request New_Policy Check_Conflict Reject_Policy Computational_ Logic Init/Result Policy_Change Interface Administrator Update_PolicyAccept_Policy Sync Decision

10/09/2006CIS Dept., UMass Dartmouth20 Formal Analysis for the Corrected XML Firewall Model Deciding structural boundedness The net is structurally bounded. The net is bounded. Computation of the reachability graph States generated: 84 The net has no dead transitions at the initial marking. The net has no dead reachable states. The net is safe. Liveness test: Computing the strongly connected components The net is live. The net is live, if dead transitions are ignored. The net is live and safe. The net is reversible (resetable).

10/09/2006CIS Dept., UMass Dartmouth21 Concluding Comments  An architectural design of the role-based XML firewall has been proposed.  Petri net based formal models for XML firewall have been developed.  Used existing Petri net tools to formally analyze XML firewall models.  Design errors, such as deadlocks, can be automatically detected.

10/09/2006CIS Dept., UMass Dartmouth22 Future Work  Refine the Petri net model of the XML firewall for detailed design.  Use case study, such as health care application, to illustrate how to design security policies.  Develop a prototype of the XML firewall based on the Petri net based formal model to show the feasibility of our approach.

10/09/2006CIS Dept., UMass Dartmouth23 Questions ?? Thank you for your attention! The slides for this talk may be downloaded from