Mapping Security to a Services Oriented Architecture

1
Mapping Security to a Services Oriented
Architecture

• Mark ONeill CTO, Vordel

2
About the speaker

• CTO of Vordel vendor of XML security products
  since 1999.
• Author of Web Service Security, published by
  Osborne/McGraw-Hill. Contributors include Phillip
  Hallam-Baker (Chief Scientist at VeriSign) and Ed
  Simon (XMLSec Inc, author of XML Signature
  specification)
• Contributing author of Hardening Network
  Security, published by Osborne/McGraw-Hill, 2005
• Published in XML Journal, Web Services Journal,
  PriceWaterhouseCoopers Cryptographic Journal of
  Excellence
• Background in EDI and in academic cryptography

3
A quote which puts the problem into context

• "I told them I wanted to make an HTTPS request
  that would be encrypted, and the firewall guys
  were fine with it. Even with SOAP, because of the
  uniqueness of the IDs and the cues we use, it's
  not easy to just write some random SOAP message
  and break in."
• http//www.eweek.com/print_article/0,3668,a27390
  ,00.asp

4
What Ill be speaking about

• What is a Services Oriented Architecture?
• A Whiteboard diagram
• How important are XML and SOAP to a SOA?
• How does security map to a Services Oriented
  Architecture?
• Transactional Embedding security tokens in XML
  messages
• Architectural Deploying security services
• XML-level New XML-based threats

5
First what is a Services Oriented
Architecture ?

• An SOA uses a Services Layer to hide underlying
  complexity
• Businesses can save money and time by developing
  against this Services Layer, rather than
  developing directly against an ERP/legacy layer
• Also known as a Business Interface Layer, or a
  Business Services Layer

6
How do you go about creating a Services Oriented
Architecture?

• Gartner define SODA as Services Oriented
  Development of
• Applications
• SODA has seven aspects
• Design. Focus on process-oriented design rather
  than component-based design. Process and workflow
  should be built into the design, not added later.
• Modeling. Using UML or similar. Includes modeling
  the structure and flow of business processes, as
  well as application modeling and technical
  modeling.
• Fabrication. The actual creation of service
  components. Includes not only XML, but also
  adapters and integration technology
• Assembly. Connecting service components together.
  May be achieved using a visual tool.
• Orchestration. After assembly, workflow defines
  how information and logic will flow through the
  process. Introduces state and flow control.
• Automation. Code generation to map from the model
  to the implementation. E.g. from scripts, or UML,
  or XML to EJB or .NET components.
• Variability and rapid application maintenance.
  Ensures that changes to composite systems does
  not break the rest of the system. Services must
  be able to adapt to multiple purposes or
  versions.
• Gartner predict that application development
  tools will evolve to
• include these seven SODA aspects.

7
Just how important are XML and SOAP for a
Services Oriented Architecture ?

• XML and SOAP are certainly a good excuse to
  implement a Services
• Oriented Architecture now, rather than doing it 5
  years ago.
• However, the concepts of a Services Oriented
  Architecture go beyond the
• implementation technologies used
• Services should be understandable by
  non-technical business people
• Implementation technologies can be changed,
  without breaking the interface
• Asynchronous messaging is preferable to
  tightly-coupled RPC styles of integration
• The most important feature of XML and SOAP is
  that fact that they are
• vendor-neutral and have no competition

8
How are Vordels customers using Web Services and
SOA?

• In Vordels customer base we see XML and Web
  Services being used for
• Transmitting and processing smartcard
  personalization files
• Accessing credit reports
• Outputting telecoms account information
• Document management in eGovernment
• In all cases, XML is used as a data format
  because it simplifies integration.
• Web Services technologies, such as SOAP and WSDL,
  are being used to create reusable interfaces on
  top of complex underlying systems
• These XML and Web Services projects are enabled
  by security

9
The security risks for an SOA

• Complexity!
• Web Services are designed to reduce complexity,
  but if youre not careful, they can become
  complex too. Unmanaged complexity breeds
  insecurity
• Unauthorized access
• Most cross-firewall Web Services are for
  closed-user-groups of partners. Therefore, access
  control is very important.
• XML-level threats
• XML introduces new threats such as XML Denial of
  Service

10
Transactional Security The architectural
challenge for SOA security

• Who is accessing this system? Can I map their
  identity to a local store?
• How did they authenticate? When did they
  authenticate?
• What are their entitlements?

?
11
Thinking in terms of the transaction

• An SOA means that users access business systems
  through multiple layers.
• This is why its necessary to bind the security
  context to XML messages.
• WS-Security and SAML are important technologies
  for achieving this.
• Then, at each layer, we have control

12
The risk of complexity

• Managing transactional security can become very
  complex very fast
• How I do control which application can access
  which Web Service?
• You could code/configure security policies in
  each Web Services platform and try to sync them
  up together
• Do you really want to do this?

Security policies are required here, here, here,
here, and here.( So is auditing, SLA
management, reporting, etc)
13
Security Services

• So, rather than coding the same security
  functionality in each platform, why not make use
  of Web Services?
• Authentication
• Username/Password AuthN (HTTP-Auth, WS-Security)
• Certificate Validation
• Token issuance (SAML)
• Authorization
• Integration with Web Access Control
• SAML AuthorizationDecisionQuery
• Audit
• Logging services
• Confidentiality and Privacy
• Encryption
• Digital Rights Management
• Content validation
• Threat scanning of XML
• Integrity
• OASIS Digital Signature Services (DSS),
  Time-stamping

14
What is the alternative to deploying reusable
Security Services?

• The alternatives to deploying reusable security
  services are
• Code and configure security rules in your Web
  Services platforms (.NET, J2EE, etc) and try
  to get them all to talk to each other
• Use multiple implementations of WS-Security,
  SAML, etc.
• Keep revisiting decisions on how to implement
  Web Services Security. Firstly at the XML
  Gateway, then at the application server, etc.
• With reusable Security Services, you get all of
  the advantages of Web Services, for security
  functionality.
• These Security Services can be used by an XML
  Gateway, and by code at the application server

15
Mapping Security to an XML transaction
Security of the user, data, and transaction is
added to the information flow This is the
deperimeterisation model
16
Defensive security Blocking new XML-level threats

• Weve looked at transactional security and at
  security services
• Now lets look at another side of security
  blocking content-based threats

17
Attacks moving up the stack

• Application Layer security has existed long
  before SOAP.
• Application Layer security for Web servers began
  with securing the Web server itself
• Patches, security updates
• Next came Web Application Security
• A Web application is a CGI-based application with
  which a user interacts using a web browser.
• Attacks include SQL Injection, Cross-Site
  Scripting, Cookie poisoning, changing URL
  parameters (e.g. trying to guess a session ID to
  get access to an online bank account)
• SOAP itself can be seen as a Web Application

18
New forms of Denial-of-service

• Preventing denial-of-service attacks
• XML introduces asymmetric Denial of Service
• A single XML message can cause damage to a naïve
  or misconfigured system

19
XML Denial-of-Service using DTD recursion

• Scenario
• DTDs are vulnerable to recursion attacks
• For example, the following DTD contains a
  recursively defined entity "x100" that would be
  expanded into the huge amount of 2100
  repetitions of the string "hello" by any XML 1.0
  standard compliant parser. This would cause
  excessive memory usage (and subsequent failure)
  and/or excessive CPU usage
• lt?xml version"1.0" encoding"utf-8"?gt
• lt!DOCTYPE foobar
• lt!ENTITY x0 "hello"gt
• lt!ENTITY x1 "x0x0"gt
• lt!ENTITY x2 "x1x1"gt
• lt!ENTITY x3 "x2x2"gt
• lt!ENTITY x4 "x3x3"gt
• ...
• lt!ENTITY x98 "x97x97"gt
• lt!ENTITY x99 "x98x98"gt
• lt!ENTITY x100 "x99x99"gt
• gt
• ltfoobargtx100lt/foobargt

20
XML Denial-of-Service using DTD recursion

• Platforms requiring patches for this attack were
• ColdFusion MX, Sybase EAServer, IBM WebSphere,
  Microsoft .NET.
• Impact
• Web Services platforms could be disabled by
  sending them a single SOAP message.
• Solution
• The SOAP specification states A SOAP message
  MUST NOT contain a Document Type Declaration"
  (http//www.w3.org/TR/SOAP/ Section 3).
• However, some SOAP-enabled products were
  vulnerable because they parsed DTDs. The solution
  is to not support DTDs in SOAP.

21
Replay Attacks

• Scenario
• A Web Service is being protected by an XML
  Gateway which scans incoming XML to make sure the
  messages are encrypted and signed.
• This system is vulnerable to a replay attack
  which simply replays a valid message, gaining
  unauthorized access.
• Impact Unauthorized access
• Solution
• The usage of timestamps to block replay attacks.
  WS-Security includes support for timestamps. A
  replayed message will include the same timestamp
  as the original message. This means that both
  messages must be discarded, because it cannot be
  established which message was the original, and
  which is the copy.
• Beware of any solution which claims this is
  secure because all incoming messages are
  signed.
• Caution
• Dont confuse replay attacks with flooding
  denial-of-service attacks.

22
Anatomy of a SQL Injection Attack

• ltSOAP-ENVEnvelope xmlnsSOAP-ENV"http//schemas.
  xmlsoap.org/soap/envelope/"gt
• ltSOAP-ENVHeadergtlt/SOAP-ENVHeadergt
• ltSOAP-ENVBody
• ltBookLookupsearchByIBSN xmlnsBookLookup"https/
  /www.books.com/Lookup"gt
• ltBookLookupIBSNgt' exec master..xp_cmdshell 'net
  user Joe pass /ADDltBookLookupIBSNgt
• lt/BookLookupsearchByIBSNgt
• lt/SOAP-ENVBodygtlt/SOAP-ENVEnvelopegt
• VB.NET code
• Set myRecordset myConnection.execute("SELECT
  FROM myBooksTable WHERE IBSN '"
  IBSN_Element_Text "'")
• Becomes
• SELECT FROM myTable WHERE IBSN exec
  master..xp_cmdshell 'net user Joe pass /ADD

23
Insecure management consoles

• Scenario Oracle 9i. In this default
  installation, the ability to deploy/un-deploy
  SOAP services is unrestricted and thus may pose a
  security threat especially in situations where
  the Oracle9iAS v.1.0.2.2 HTTP server might be
  accessed via the Internet. http//otn.oracle.com/
  deploy/security/pdf/ias_soap_alert.pdf
• Impact Web Services can be selectively disabled
  via the Web Service platform management console
• Solution Ensure that your Web Services platform,
  or indeed your Web Services security product,
  does not expose a management interface to
  untrusted parties.
• Caution Beware of security solutions which
  expose Web-based management interfaces to
  untrusted users

24
Putting it all together

• Services Oriented Architectures present security
  problems, which are not insurmountable. They
  require
• A solution which takes into account the full
  transaction
• A Security context from the user to the system
  they ultimately access
• Security Services
• Reusable security services which can be used
  across the enterprise
• For XML validation, signing, encryption, logging
• XML threat-blocking
• Awareness of new XML-based threats, and blocking
  these threats

25
Security and the Semantic Web
Syntactic Semantic
Confidentiality Privacy
Authentication Authorization
Licenses Permissions

• Confidentiality XML Encryption, WS-Security
• Privacy What must be protected not only during
  transmission but also after receipt
• Authentication SSL, WS-Security UsernameToken
  Profile, WS-Security X.509 profile
• Authorization Defining roles like Manager,
  defining membership of groups
• Licenses XRML, and others
• Permissions Defining usage of data, such as
  disclosure control, retention, destruction

26
Semantics missing from security

• In any given security context there are at least
  three primary actors
• 1) the User, 2) the Transaction, 3) The data.
• Security descriptors may be used to convey the
  security requirements of each actor
• There are some initiatives to annotate Web
  Services with security descriptors
• Syntactic WS-SecurityPolicy and
  WS-PolicyAttachment can be used to define a
  policy such as sign all input and include the
  public key, and Ill use that public key to
  encrypt the output I send back to you
  Transaction
• Semantic 2004 paper Authorization and Privacy
  for Semantic Web Services proposes attaching
  security information to OWL-S input and output
  parameters. Usere.g. using FOAF (Friend of a
  Friend) foafPerson to specify personal
  information is transmitted as encrypted data and
  never appears as output of a Web Service
• Syntactic XRML can be used to define limits on
  the ability to share a document Data
• Semantic Desktop software enforces this share
  permission e.g. blocking email forwarding

27
Vordels Products

• Vordels products address each stage of
• an organizations XML roadmap
• From initial design and testing, through the
• first Web Services deployments, finally to
• deploying a Services Oriented Architecture

Vordel SOAPbox is a Web Services security
testing application which is used by over 3500
registered users worldwide.
VordelSecure is an XML Gateway.
Architecturally, it is a reverse proxy,
detecting and blocking malicious traffic, and
only allowing XML from trusted sources.
VordelDirector is an enterprise XML Security
Server. It provides security services which are
used by security enforcement points around the
enterprise. Policies in VordelDirector are
enforced at proxies and at security agent
plug-ins.
28
What are the security requirements an XML Gateway?

• Access Control
• Authentication at both the transport layer and
  the XML layer
• Per-service authorization, even when multiple
  services are at the same URL
• Compliance with WS-Security, SAML, and other
  relevant standards
• XML threat-awareness
• Ensure that XML messages have valid format and
  content
• Ensure that SOAP attachments are of the
  appropriate format and size
• Block XML denial-of-service attempts
• Integration with existing security
  infrastructure
• Link to silos of identity information in LDAP
  directories and Active Directory
• Send alerts to enterprise monitoring tools
• Auditability
• Log all XML activity and provide a reporting
  interface
• Administration
• Allow policies to be updated without a
  requirement to edit code or edit XML

29
XML Security Server

• VordelDirector is an XML Security Server
• It provides a central point to manage XML
  security for the entire organisation
• APIs are provided in Java and C, and a SOAP
  interface is provided (of course!)
• Security services carried out by VordelDirector
  include signing, encryption/decryption, XML
  content analysis, SAML processing, and logging
• VordelDirector is available for Windows, Linux,
  and Solaris

30
Thank You !

• Mark ONeill
• CTO, Vordel
• mark.oneill_at_vordel.com
• www.vordel.com