A Petri Net Based XML Firewall Security Model for Web Services Invocation

1. 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 http://www.cis.umassd.edu/~hxu/ CIS Dept., UMass Dartmouth

2. 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 CIS Dept., UMass Dartmouth

3. 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. CIS Dept., UMass Dartmouth

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

5. 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). CIS Dept., UMass Dartmouth

6. Server Machines Internet Firewall Client Machines Conventional 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 CIS Dept., UMass Dartmouth

7. 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. CIS Dept., UMass Dartmouth

8. 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. CIS Dept., UMass Dartmouth

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

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

11. 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, M0) 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); M0: P --> {0, 1, 2, 3, …} is the initial marking. CIS Dept., UMass Dartmouth

12. An Example t2 P1 P2 t3 t1 P5 P3 t4 t5 P4 CIS Dept., UMass Dartmouth

13. Login_Request User_Access _Request Access_ Request Access_Denied Get_Login_ Request Ready_To_ Accept_Request Request_ Details Create_Request Logout Username_ Password Computational _Logic Dispatch_Request Check_User_DB Req_for _WS1 User_DB Req_for _WS2 Init/Result Not_Valid Failure XML_FW XML_FW Valid Req_for _WS Req_for _WS Access Denied Access Denied WS_Req Get_User_ Details Accept _Result WS_Req FW_ Result User_Details FW_ Result WS_Logic WS_Logic Petri Net Model of an Application CIS Dept., UMass Dartmouth

14. Start_Authorization UserInfo_DB WS_Request Check_If_Existing Application User_Request Valid_User _Request Existing_User Assign_Role First_Time _User Fetch_State _Info Role_DB BG_Check_DB State_DB User_Role Create_ Session Fetch_ Policy Background_ Check StateInfo Update_ Databases Computational_ Logic Policy_DB Check_ Passed Init/Result Check_ _Failed Access_Request Accept _Result Create_UserSpace Access _Failed FW_ Result Access_ Denied Permission_Result UserSpace (Username, Permissions, Session) Fail Check_Permission Pass Accept_WS_Response WS_Logic Petri Net Model of XML Firewall CIS Dept., UMass Dartmouth

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

16. 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 CIS Dept., UMass Dartmouth

17. 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). CIS Dept., UMass Dartmouth

18. 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:  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33toks:  1  0  0 0  0 0  1  1 0  0 1  0  0 0  1  1 0  0 1  1 1  1 0 0  0 0  0 1  0  1  0  0 0 CIS Dept., UMass Dartmouth

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

20. 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). CIS Dept., UMass Dartmouth

21. 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. CIS Dept., UMass Dartmouth

22. 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. CIS Dept., UMass Dartmouth

23. Questions ?? Thank you for your attention! The slides for this talk may be downloaded from http://www.cis.umassd.edu/~hxu CIS Dept., UMass Dartmouth