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

• Mihir M. Ayachit
• Advisor Dr. Haiping Xu

2
Outline

• Web Services
• Web Services Security
• Petri Nets
• Our Approach to XML Firewall
• XML Firewall Architecture
• RBAC and SBAC
• Petri Net Models for XML Firewall
• Analysis of Petri Net Models
• Prototype Implementation

3
Web Services

• Web Services are Internet-based software
  components that support open, XML-based standards
  and communication protocols. Web services are
  available over the Internet, and can be
  dynamically incorporated into different
  applications.
• A Web Service is a software component defined
  using WSDL, registered using UDDI, and invoked
  using SOAP which is a XML-based standard
  communication protocol exposed over the Internet.
  
• Web Services make software functionality
  available over the Internet so that programs like
  PHP, ASP, JSP, JavaBeans which can make a request
  to a program running on another server (e.g., a
  web service) and use that programs response in a
  website or other application

4
Web Services Roles

• Service Provider This is the provider of the
  service. The service provider implements the
  service and makes it available on the internet.
• Service Requester This is the consumer of the
  web service. The requestor utilizes an existing
  web service by opening a network connection and
  sending a request.
• Service Broker This is the logically
  centralized directory of the services where
  developers can publish new service.

5
Web Services Security

• A firewall is simply defined as a collection of
  components placed between two networks to protect
  a private network from unauthorized intrusion.
• Firewalls have long been a major component of
  corporate security. But in case of web services,
  they may provide no security at all, because they
  can only filter at the packet level, and can't
  examine the contents of messages.

6
Web Services Security

• Why XML Firewall ? ? ?
• In case of web services, conventional firewalls
  fail to provide the security from malicious
  attacks This is because web services use the
  SOAP protocol over HTTP, whose port is typically
  not blocked by conventional firewall.
• Even with a properly installed firewall to help
  secure the servers data, XML data may be passed
  through the networks web port 80 since current
  firewalls do not have the ability to parse or
  validate the XML data.
• Hackers can potentially insert SQL and Windows
  executable code inside an XML packet and poorly
  written applications may leave some method for
  the code to be executed.
• Conventional firewalls typically only filter
  malicious messages at the packet level without
  examining the contents of messages.

7
Our Approach of XML Firewall

• Develop security policies by identifying security
  threats, and to develop a general framework that
  enforces access restrictions.
• The access to web services is only granted to
  those users who are authenticated and authorized
  to have access to the service.
• To achieve this, we propose a XML firewall
  security model that use role base access control
  (RBAC).
• The role-based access not only depends on the
  users identity, it also depends on the current
  state of the system. The XML firewall defines
  certain policy rules that specify the users
  access to the web services based on the system
  state
• XML firewall can also examine the contents of the
  incoming traffic, understands the content and
  takes suitable actions, for example, either to
  let the traffic in or to block it.

8
Petri Nets

• The classical Petri net is a directed bipartite
  graph with two node types called places and
  transitions. The nodes are connected via directed
  arcs .
• Tokens are used to specify information or
  conditions in the places.
• Definition A Petri net is a triple (P,T,F)
• P is a finite set of places,
• T is a finite set of transitions,
• F (P x T) U (T x P) is a set of arcs.

9
Petri Nets

• Why Petri Nets ? ? ?
• It is a promising tool for describing and
  studying information processing systems that are
  characterized as being concurrent, asynchronous,
  distributed, and parallel in nature
• As a graphical tool, Petri nets can be used as a
  visual communication aid similar to flow chars,
  block diagrams and networks.
• Tokens are used to simulate the dynamic and
  concurrent activities of systems.
• It is possible to do a formal analysis of Petri
  net models using analysis tools available in the
  market.

10
XML Firewall for Web Services

• The XML based firewall security model consists of
  three major components an application, the XML
  firewall and web services.

11
Role Based Access System

• In computer systems security Role-Based Access
  Control (RBAC) is an approach to restricting
  system access to authorized users.
• Access decisions are based on the roles that
  individual users have as part of an organization.
• A user is the potential user who intends the use
  of the application. A user is given a unique
  identity. Each user has given at least one role.
  Roles maintain a list of services that users, who
  are assigned the roles, have permission to
  execute.
• The decision to grant permission to invoke a
  service depends on whether the role has requested
  service granted to it and whether the role
  satisfies all of the minimum access requirements.

12
State Based Authorization Control

• SBAC In this type of system, The policy
  assignment considers not only who the user is
  but also where the user is and what users
  state is. Hence the user access is granted by
  users current status.
• In the state based authorization control system,
  factors such as time, physical location, previous
  history, number of requests per minute are taken
  in to account for making a decision.
• For example, a user is blocked to use a service
  after 5 p.m. although he is allowed to log in to
  the system. In this case, time is the state
  information.
• Advantage The state information gives more
  dynamic control over the access restrictions and
  hence added security.

13
XML Firewall Architecture

• Important components of the XML firewall
  architecture.

14
XML Firewall Model
15
XML Firewall Model
16
XML Firewall Model
17
XML Firewall Model Analysis

• Reachability In a Petri net N with initial
  marking M0, denoted as (N, M0), a marking Mn is
  said to be reachable from a marking M0 if there
  exists a sequence of firings that transforms M0
  to Mn.
• Boundedness A Petri net (N, M0), is said to be
  k-bounded or simply bounded if the number of
  tokens in each place does not exceed a finite
  number k for any marking reachable from M0. A
  Petri net (N, M0) is said to be safe if it is
  1-bounded.
• Liveness A Petri net (N, M0), is said to be live
  if for any marking M that is reachable from M0,
  it is possible to ultimately fire any transition
  of the net by progressing some further firing
  sequence.
• Reversibility A Petri net (N, M0) is said to be
  reversible if, for each marking M that is
  reachable from the initial marking M0, M0 is
  reachable from M.

18
Analysis using INA tool

• With our Application model as an input to the INA
  tool, the INA tool produces following results
• 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).

19
Analysis using INA tool

• With our XML Firewall model as an input to the
  INA tool, the INA tool produces following
  results
• Deciding structural boundedness
• The net is structurally bounded.
• The net is bounded.
• Computation of the reachability graph
• States generated 34
• 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).

20
Analysis using INA tool

• With our XML Firewall model for Changing Policy
  Base as an input to the INA tool, the INA tool
  produces following results
• 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

21
Analysis using INA tool
22
Analysis using INA tool

• With our new XML Firewall model for changing
  policy as an input to the INA tool, the INA tool
  produces following results
• 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).

23
Prototype Implementation

• For showing the feasibility of our approach, we
  decided to implement a small prototype for health
  care application

XML Firewall Prototype
24
Prototype Implementation

• Health Care Application
• Web Service Prescription Web Service.
• Functions Write/Read/Add/Delete/Email
  Prescription.
• Roles Doctor, Nurse , Patient
• Permissions Doctor All
• Nurse Read/Email.
• Patient Email
• Monitor the number of requests coming in from the
  user per minute.

25
Screen Shots
26
References

• H. Feinstein R. Sandhu, E. Coyne and C. Youman,
  Role-based access control models, IEEE
  Computer, 29(2)3847, 1996.
• E. B. Fernandez, Two Patterns for Web Services
  Security, Proceedings of the 2004 Intl.
  Symposium on Web Services and Applications
  (ISWS'04), Las Vegas, NV, June 21-24, 2004.
• E. B. Fernandez, M. M. Larrondo-Petrie, N.
  Seliya, N. Delessy-Gassant, and M. Schumacher, A
  Pattern Language for Firewalls, In M.
  Schumacher, E. B. Fernandez, D. Hybertson, F.
  Buschmann, and P. Sommerlad (Eds.), Security
  Patterns, Wiley 2005.
• Guangsen Zhang, Manish Parashar, Context-aware
  Dynamic Access Control for Pervasive
  Applications, Proceedings of  the Communication
  Networks and Distributed Systems Modeling and
  Simulation Conference (CNDS 2004),  2004 Western
  MultiConference (WMC),  San Diego, CA, USA,
  January 2004.
• L. Giuri and P. Iglio, Role templates for
  content-based access control, Proceedings of the
  Second ACM Workshop on Role Based Access Control,
  Virginia, USA, 1997.
• Allen D. Forum Systems' XWall Web Services
  Firewal, Retrieved April 29, 2004, from
  http//www.networkmagazine.com/shared/article/show
  Article.jhtml?articleId18900090

27
Thank You !!!