Oneill SOA
-
Upload
abhinav-shukla -
Category
Documents
-
view
214 -
download
0
Transcript of Oneill SOA
-
8/2/2019 Oneill SOA
1/32
Mapping Security to a Services Oriented Architecture
Mark ONeill CTO, Vordel
Open Group, April 2005
-
8/2/2019 Oneill SOA
2/32
Open Group, April 2005 2
About the speaker
CTO of Vordel vendor of XMLsecurity 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 In c, authorof XML Signatu re specification)
Contributing author of HardeningNetwork Security, published byOsborne/McGraw-Hil l, 2005
Published in XML Journal, WebServices Journal,PriceWaterhouseCoopersCryptographic Journal of Excellence
Background in EDI and in academiccryptography
-
8/2/2019 Oneill SOA
3/32
Open Group, April 2005 3
About Vordel
A vendor of XML securit y products since 1999.
Based in Dublin, London, and Boston
Customers include the European Union, theSpanish Government , Telefonica, Fortis,Experian, Ericsson, Bell Canada
Standards-based integration with identi ty-management tools
Vordel supports a wide range of open standards andspecifications and interoperates with many popularWeb Services platforms, making it a likely choice formany enterprises looking to protect their WebServices from unauthorized or malicious traffic. Jason Bloomberg - ZapThink
-
8/2/2019 Oneill SOA
4/32
Open Group, April 2005 4
Vordels User Conference
Speakers from Entrust , RSA Security, Softw are AG, QA Consultin g
Enterprise architects from Vordels customer base describe how theyhave integrated security into their Services Oriented Architectures
Tutorial on W eb Services Security included in confer ence fee
June 8-10 in Westbury Hotel, Dublin
-
8/2/2019 Oneill SOA
5/32
Open Group, April 2005 5
What I ll be speaking about
What is a Services Oriented Archit ecture?
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
-
8/2/2019 Oneill SOA
6/32
Open Group, April 2005 6
First what is a Services Oriented Architecture ?
An SOA uses a Services Layer to hide underlying complexity
Businesses can save money and time b y developing agai nst thi s ServicesLayer, rather than developi ng directly against an ERP/legacy layer
Also known as a Business Interf ace Layer, or a Business Services Layer
-
8/2/2019 Oneill SOA
7/32
Open Group, April 2005 7
How do you go about creating a Services Oriented Architecture?
Gartner defi ne SODA as Services Oriented Development ofApplications
SODA has seven aspects:
1 . D es ig n . Focus on process-oriented design rather than component-based design. Processand workflow should be built into the design, not added later.
2 . Model l ing. Using UML or similar. Includes modelling the structure and flow of bus inessprocesses, as well as application modelling and technical modelling.
3 . Fabr i ca t ion . The actual creation of service components. Includes not only XML, but alsoadapters and integration technology
4 . Assembly. Connecting service components together. May be achieved using a visual tool.5 . Orches t ra t ion . After assembly, workflow defines how information and logic will flow
through the process. Introduces state and flow control.6 . A ut o m at i o n. Code generation to map from the model to the implementation. E.g. from
scripts, or UML, or XML to EJB or .NET components.7. 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 multiplepurposes or versions.
Gartner predict t hat applicat ion development tools wil l evolve toinclude t hese seven SODA aspects.
-
8/2/2019 Oneill SOA
8/32
Open Group, April 2005 8
Just how important are XML and SOAP for a Services Oriented Architecture ?
XML and SOAP are certainl y a good excuse to implement a ServicesOriented Architecture now, rather t han doing i t 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 arevendor-neutral and have no competi t ion
-
8/2/2019 Oneill SOA
9/32
Open Group, April 2005 9
The security risks for an SOA
1 . Compl ex i t y ! Web Services are designed to reduce complexity, but if youre not careful, they can
become complex too. Unmanaged complexity breeds insecurity
2. Unauthorized access Most cross-firewall Web Services are for closed-user-groups of partners. Therefore,
access control is very important.
3. XML-level threats XML introduces new threats such as XML Denial of Service
-
8/2/2019 Oneill SOA
10/32
Open Group, April 2005 10
Transactional Security The architectural challenge for SOA security
Who is accessing this system? Can I m ap their id entit y to a local store?
How did t hey authenticate? When did they authenticate?
What are their enti t lements?
?
-
8/2/2019 Oneill SOA
11/32
Open Group, April 2005 11
Thinking in terms of t he transaction
An SOA means that users access business systems through mu ltipl e layers.
This is why it s 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
-
8/2/2019 Oneill SOA
12/32
Open Group, April 2005 12
Security tokens inside an XML message
In t his message,security tokens arehighlighted inyellow.
We see a SAMLAuthenticat ion assert ion,digital ly signed along withthe SOAP body.
[ screenshot f romVordel SOAPboxapplicat ion free
download fromwww.vordel .com ]
-
8/2/2019 Oneill SOA
13/32
Open Group, April 2005 13
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 syncthem 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)
-
8/2/2019 Oneill SOA
14/32
Open Group, April 2005 14
Security Services
So, rather than coding the same security functionality in each platform, whynot m ake use of Web Services?Authenticat ion
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
I n t e g r i t y OASIS Digital Signature Services (DSS), Time-stamping
-
8/2/2019 Oneill SOA
15/32
Open Group, April 2005 15
So how is this im plemented?
At each point w here you must consume or send XML, also apply security
Where?
At the perimeter (XML Gateway)At the Web Service endpoint (application server)
Security Services simply means deploying security functionality as WebServices that ar e on t ap as part of an SOA.
-
8/2/2019 Oneill SOA
16/32
Open Group, April 2005 16
The Security Bus
When a security context flows with XML messages through an SOA, throughthe use of security services, it can be thought of as a Security Bus
-
8/2/2019 Oneill SOA
17/32
Open Group, April 2005 17
What is the alternative to deploying reusable Security Services?
The alternat ives to deploying reu sable securit y 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 r eusable Securit y Services, you get all of t he advantages of WebServices, for security functionality.
These Security Services can be used by an XML Gateway, and b y code atthe application server
-
8/2/2019 Oneill SOA
18/32
Open Group, April 2005 18
Defensive security: Blocking new XML-level thr eats
Weve looked at transactional security and at security services
Now lets look at another side of securi ty blocking content-based threats
-
8/2/2019 Oneill SOA
19/32
Open Group, April 2005 19
STRIDE Threat model - thinking about security in terms of threats
Developed by Michael Howard and David LeBlanc in Microsoft
Documented in Writin g Secure Code [ Microsoft Press]
The first step is to draw the data flow for a system and then identify which threat s apply at
each system entity, and at each link between entities
STRIDE stands for:SpoofingTamperingRepudiationI nformation disclosureDenial of serviceElevation of Privilege
Then apply a "DREAD" category to assess each threat from 1 to 10:Damage potentialReproducibilityExploitability (How much effort and skill is needed to execute attack?Affected users (How many users would be affected?)Discoverability (Assume a vulnerability will be discovered)
Calculate the average to arrive at a DREAD number for each threat
-
8/2/2019 Oneill SOA
20/32
Open Group, April 2005 20
STRIDE and DREAD for Services Oriented Architect ure
Spoofing of data between the Web ServicesTampering of XML data in transit, or in storageRepudiation of the end user, or the owner of the portalI nformation disclosure at the Web Service, or from the audit logs
Denial Of Service at the Web ServiceElevation of Privilege e.g. if the Web Service, or the Web Services platform,
includes backdoors
The good news is that Web Services attacks tend to be specific to acertain Web Service, so the Reproducibility ( the R in DREAD) may below
The bad news is that Web Service are often a Royal Road int o backoffice systems, the Damage potential (the D in DREAD) may be high
-
8/2/2019 Oneill SOA
21/32
Open Group, April 2005 21
Attacks moving up the stack
Application Layer securit y has existed long before SOAP.
Application Layer security for Web servers began with securing the Webserver 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 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 Appli cation
-
8/2/2019 Oneill SOA
22/32
Open Group, April 2005 22
New forms of Denial-of-service
Preventing denial-of-service attacks
Blocking unwanted message storms Blocking messages which are designed to cause processing problems These can be intentional, as well as unintentional E.g. State of Georgia Web Services case study
"We brought down a mainframe, legacy systems usually must undergo somepreparation to handle the additional queries. "That's definitely a problem because thosesystems aren't designed to have that kind of load. Instead of batch processes, we havecitizens hitting the same processes or same services."http://www.govtech.net/magazine/story.php?id=66547
-
8/2/2019 Oneill SOA
23/32
Open Group, April 2005 23
SQL Injection
Web Application SQL In jection Att acks
Inserting SQL statements into web forms in order to force a database toreturn inappropriate data, or to produce an error which reveals databaseaccess information.
Web Services SQL Injecti on Attacks
For Web Services, this category of attack translates into manipulating data ina SOAP message to include SQL statements which will be interpreted by aback-end database.
-
8/2/2019 Oneill SOA
24/32
Open Group, April 2005 24
Anatomy of a SQL Injection Attack
-
8/2/2019 Oneill SOA
25/32
Open Group, April 2005 25
Anatomy of a SQL Injection Attack
-
8/2/2019 Oneill SOA
26/32
Open Group, April 2005 26
Defending against a SQL injection attack
Ensure the format of incoming SOAP parameters using an XML Schema
-
8/2/2019 Oneill SOA
27/32
Open Group, April 2005 27
Replay Attacks
Scenario: A Web Service is being protected by an XML Gateway which scans incoming XML to make surethe messages are encrypted and signed.
This system is vulnerable to a replay attack which simply replays a valid message, gainingunauthorized 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 thatboth messages must be discarded, because it cannot be established which message was theoriginal, and which is the copy.
Beware of any solution which claims this is secure because all incoming messagesare signed.
Caution:Dont confuse replay attacks with flooding denial-of-service attacks.
-
8/2/2019 Oneill SOA
28/32
Open Group, April 2005 28
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 beexpanded into the huge amount of 2^100 repetitions of the string "hello" by any XML 1.0standard compliant parser. This would cause excessive memory usage (and subsequent failure)and/or excessive CPU usage:
...
]>&x100;
-
8/2/2019 Oneill SOA
29/32
Open Group, April 2005 29
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 SOAPmessage.
Solution:The SOAP specification states A SOAP message MUST NOT contain a Document TypeDeclaration" (http://www.w3.org/TR/SOAP/ Section 3).
However, some SOAP-enabled products were vulnerable because they parsed DTDs. Thesolution is to not support DTDs in SOAP.
-
8/2/2019 Oneill SOA
30/32
Open Group, April 2005 30
Putting it all together
Services Oriented Architectures present security problems, which are notinsurmountable. They require:
A solution which t akes into account t he full t ransaction
- The Security Bus - 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 Authentication, Authorization, XML validation, signing, encryption, logging
XML threat-blocking
- Awareness of new XML-based threats, and blocking these threats
-
8/2/2019 Oneill SOA
31/32
Open Group, April 2005 31
Real-life examples
Large North American telco:
Vordel and Entrust deployed Web Services security and Web Access Control side-by-side. Browser traffic and SOAP traffic are managed using the same policy set.
European public utility company:
Vordel deployed security for a .NET infrastructure, performing access managementand XML threat analysis.(controlling who can access the systems, and what they send into the systems).
More details at:http://www.vordel.com/customers/case_studies.html
Or ask me after this talk!
-
8/2/2019 Oneill SOA
32/32
Open Group, April 2005 32
Thank You !
Mark ONeill
CTO, Vordel
www.vordel .com