Your SlideShare is downloading. ×‐
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply‐


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1.     DRAFT 30 September 2008     Cyber Security KTN   SOA security stakeholder concerns analysis    www.cybersecurity‐         Dr. Ulrich Lang, Rudolf Schreiner  ObjectSecurity Ltd.  contact@secure‐      Service Oriented Architecture (SOA) as an approach (or buzzword?) promises unprecedented IT flexibility and reuse.  However, so far there is a lot of confusion about what SOA actually means in business and technical terms (“Same Old  Architecture”?) and what it is good for (“SOA what?” like in “so what?”), what the technical and business show‐ stoppers are, what the best adoption roadmap is etc.  Unclear security implications are often high on the list of issues raised that slow down SOA rollouts. There are many  reasons for the (real and perceived) security and assurance problems of SOA, including immaturity of security  standards and technologies, unpredictability and unmanageability etc. Defence faces particular SOA security  challenges because traditional assurance accreditation standards (e.g. Common Criteria accreditation of complete  systems) cannot easily be used to accredit SOA assurance.   Just like the numerous SOA definitions, there are numerous SOA security concerns that may differ for each  stakeholder in the “SOA puzzle”: industry, government, vendors, security experts, consultants, analysts etc. There is  also an abundance of literature, most of it biased towards specific aspects, stakeholders, approaches, products etc.  Concerns can be about business case, technology, governance, accreditation, deployment, return‐on‐investment,  future‐proofing, hype vs. reality etc.  The purpose of this document is to produce a level of common understanding about the main SOA security concerns.  It summarises the security concerns of both the end‐user side (i.e. organisations that try to use SOA) and the  vendor/provider side (i.e. SOA integrators, vendors, universities/educators, consultancies etc.). It is intended to  provide a broad understanding about the main SOA security concerns that will help all stakeholders come closer to  SOA roll‐outs, products and education that include appropriate security.          Please look at the project wiki‐  (contributions highly encouraged)  ObjectSecurity Ltd. St John’s Innovation Centre Cowley Road Cambridge CB4 0WS England Tel: +44 (0) 1223 420 252 Fax: +44 (0) 1223 420 844 Email: ObjectSecurity LLC Plug & Play Tech Center, 530 University Ave, Palo Alto, CA 94301, USA, Tel. +1-650-515-3391, Fax +1-360-933-9591, Email:, © 2008 ObjectSecurity Ltd. – all rights reserved – redistribution only permitted in an unchanged form with all logos and copyrights included. Logos/trademarks are the property of their respective owners 
  • 2. 1 Contents  1  Contents  2  2  SOA  3  2.1  SOA definitions  3  2.2  Business benefits  4  2.3  Technical benefits  4  2.4  Pick & choose?  5  3  SOA security  6  3.1  SOA security concepts  6  3.2  SOA security complexities  6  3.3  What are really the main SOA security concerns?  8  4  SOA security compliance  11  4.1  Why is compliance relevant for SOA?  11  4.2  Compliance examples  11  4.3  SOA compliance drivers  11  4.4  Common compliance elements  13  4.5  SOA security compliance challenges  14  4.5.1  Sustainable compliance and dynamic/agile business and IT environments  14  4.5.2  Challenge ‐ Aligning business compliance requirements and IT enforcement/monitoring  14  4.5.3  Security policy management for SOA  14  4.6  How to procure SOA security?  15  4.6.1  Roadmap towards model‐driven SOA security policy management  15  4.6.2  SOA security and defence procurement  16  5  APPENDIX – SOA SECURITY CASE STUDIES  17  6  APPENDIX – SOA security solutions approaches and examples  18  7  Executive summary & conclusion  19  8  APPENDIX  ‐ Further information  20  8.1  General resources  20  8.2  Vendor resources:  20  9  APPENDIX – Survey analysis details  21  10  APPENDIX – Original document and project overview  22  10.1  Planned project purpose  22  10.2  Planned project approach  22  10.3  Fact‐finding document purpose  22  10.4  Project scope  22  10.5  Outputs – for the KTN, UK PLC, government, and academia  23  10.6  Approach – Workshops, surveys  23  10.7  Project timetable  23  10.8  ObjectSecurity’s role  23    ObjectSecurity Ltd. St John’s Innovation Centre Cowley Road Cambridge CB4 0WS England Tel: +44 (0) 1223 420 252 Fax: +44 (0) 1223 420 844 Email: ObjectSecurity LLC Plug & Play Tech Center, 530 University Ave, Palo Alto, CA 94301, USA, Tel. +1-650-515-3391, Fax +1-360-933-9591, Email:,
  • 3. 2 SOA   Service Oriented Architecture (SOA) as a buzzword promises unprecedented IT flexibility and reuse. However, so far  there is a lot of confusion about what SOA actually means in business and technical terms and what it is good for,  what the technical and business show‐stoppers are, what the best adoption roadmap is etc. While actual SOA  implementations in many organisations today still seem to be early stages, the view is often voiced that “doing  nothing” is probably more expensive than “doing something”. While a recent Gartner CIO survey showed “SOA” only  as #10 top priority, the same survey showed several potential SOA business benefits higher up on the list. This could  potentially be interpreted as “SOA fatigue”.   2.1 SOA definitions  SOA in general means different things to different people. Some vendors market SOA as a mere technology solution  based on XML web services based applications (ridiculed as “Same Old Architecture” by others). Others again  advocate SOA as an IT architectural style that can range from a simple portal‐based web service solution, over loosely  coupled interacting web services, to a full‐fledged Business Process Model (BPM) driven, orchestrated agile IT  environment (with the downside of high complexity). Others again consider SOA mainly a business‐led style of  “bringing IT back to the business” where the goal is to give the business more control over the IT resources needed to  do their business. Other sources (mostly advocacy groups) take a purely business‐driven view of IT transformation that  is based on business benefits and return‐on‐investment. Various industry consortia now also provide their definitions  and reference models (e.g. the OASIS SOA Reference Model).  Other exemplary definitions found on the internet include1  • A system for linking resources on demand. In an SOA, resources are made available to other participants  in the network as independent services ...  • A SOA defines how two or more entities interact in such a way as to enable one entity to perform a unit  of work on behalf of another entity. The unit of work is referred to as a service, and the service  interactions are defined using a well‐defined description language. ...  • A software design that integrates business functions. Users are able to decide the information which is to  be shared between the functions. SOA is therefore more flexible and more loosely coupled than ERP and  generally more suitable for service rather than manufacturing companies.  • A paradigm for design, development, deployment and management of a loosely coupled business  application infrastructure. ...  • An architecture, the aim of which is to achieve a loose connection between integrated systems. From a  common public Danish perspective, the integration of IT systems across public and private organisations  is part of the vision of digital administration.  • Essentially a collection of services. These services communicate with one another. The communication  can involve either simple data passing or it can involve two or more services coordinating some activity.  ...  • An approach to enable better software reuse. Instead of all applications implementing the same business  functionality over and over again, for example credit card checks or payments, such functionality is  implemented as service and then used by other business processes implementations and services.    SOA seems to have been originally based on the concept of a service in a strict sense. One component provides a  service, another component uses this services. This is done as invocations on remote interfaces and implemented, i.e.  with Web Services, J2EE or CORBA. Unfortunately, it became very common to call data centric, network centric or  message driven systems service oriented as well. The relationship between the terms “service” and “process” is also                                                                    1‐US&defl=en&q=define:SOA&sa=X&oi=glossary_definition&ct=title  ObjectSecurity Ltd. St John’s Innovation Centre Cowley Road Cambridge CB4 0WS England Tel: +44 (0) 1223 420 252 Fax: +44 (0) 1223 420 844 Email: ObjectSecurity LLC Plug & Play Tech Center, 530 University Ave, Palo Alto, CA 94301, USA, Tel. +1-650-515-3391, Fax +1-360-933-9591, Email:,
  • 4. not well defined. While these unclear terminologies produce a lot of confusion, it turns out that SOA even in the strict  sense of synchronous service invocations and the other non‐invocation based technologies share the same main  security problems, e.g. the necessity to deal with complex, agile and flexible systems. This is caused by the high level  of distribution of the systems and complex interactions of components, compared to client/server or 3‐tier  architectures.  The actual communication patterns and technologies play a minor role, and it is in fact planned to use  multiple different middleware technologies for larger SOA deployments.  As a basis for further discussion, this document attempts to provisionally structure the different aspects of Service  Oriented Architecture (SOA) as follows.  2.2 Business benefits  It is obvious that SOA will only be adopted if it either has clear business benefits. Aspects related to business benefits  include:  • Agility, cost‐saving:   the IT environment can respond quicker and cheaper to organisational changes, for example new  markets, services and products.  • Cost‐saving/ROI:   running legacy IT systems (i.e. investments) can be reused as services and enabled for integrated IT  solutions that support the business better  • “Future‐proofness”/ROI:   business invests in a general architecture that allows future IT to be integrated into the existing fabric  without disruptive costs  • Reusability/ROI:  The same functionality is implemented once as a service and then reused in other applications.  • Business‐led ownership, aligned business and IT:   IT architecture is a business concern, rather than a siloed IT department concern. Investments, benefits  (and mistakes!) are therefore clearly justifiable to the business. Business Process Management (BPM)  driven SOA is an example of a big (maybe too ambitious?) vision of connecting the business and IT in a  structured way.  2.3 Technical benefits  It is also possible to justify SOA from technical benefits, e.g. integrators can deploy SOA without the customer’s  specific commitment in order to provide the best or most cost‐effective solution to the end‐customer. Some  technology benefits include:  • Reduced complexity:   Wrapping all systems into consistent, standardised service2 interfaces (e.g. XML) with interface  definitions in standardised registries/repositories (e.g. WSDL/UDDI based) and standard protocols  potentially helps the IT department to deal with the complexity of today’s ever‐growing interconnected  IT environments.   • Easier changes:  Consistent interfaces and protocols can simplify reconfiguration and adaptation to changing  requirements  • Easier reuse and integration of new systems:  Consistent interfaces and protocols can also help with this.                                                                    2  Looking at the IT world in terms of services can be seen as a relatively arbitrary design decision which probably comes from previous  object/component‐oriented middleware approaches. One could also look at the IT world purely data‐centric or process‐centric.  ObjectSecurity Ltd. St John’s Innovation Centre Cowley Road Cambridge CB4 0WS England Tel: +44 (0) 1223 420 252 Fax: +44 (0) 1223 420 844 Email: ObjectSecurity LLC Plug & Play Tech Center, 530 University Ave, Palo Alto, CA 94301, USA, Tel. +1-650-515-3391, Fax +1-360-933-9591, Email:,
  • 5. • Consolidated view:  If tied into a business‐driven architecture (e.g. BPM SOA), a consolidated architectural view can  potentially be achieved, which will support the other benefits.  2.4 Pick & choose?  A SOA definition could “pick & choose” some or all of the following features:  • IT services with standards‐based interfaces (potentially XML based)  • standard protocols for communications (potentially XML based)  • standards‐based registries/repositories store service information (e.g. location, interface etc.),  potentially using UDDI/WSDL XML standards  • Support for flexible on‐the‐fly service orchestration, e.g. using BPEL  • Support for model‐driven specification of information models, service models and business processes,  and other functional and non‐functional (e.g. security) business and IT environment aspects, e.g. using  BPM/BPMN/UML      ObjectSecurity Ltd. St John’s Innovation Centre Cowley Road Cambridge CB4 0WS England Tel: +44 (0) 1223 420 252 Fax: +44 (0) 1223 420 844 Email: ObjectSecurity LLC Plug & Play Tech Center, 530 University Ave, Palo Alto, CA 94301, USA, Tel. +1-650-515-3391, Fax +1-360-933-9591, Email:,
  • 6. 3 SOA security  Unclear security implications are often cited high on the list of issues raised that slow down SOA adoption or limit the  benefits of SOA. For example, Aberdeen Group’s March 07 benchmark report “Management and Governance:  Planning for an Optimized Application Lifecycle” identified the establishment of operational security, governance, and  management as the top challenge (44%) in managing an SOA lifecycle. The fact that security issues are different from  older IT came second (39%).  There are many reasons for the (real and perceived) security and assurance problems of SOA, including immaturity of  security standards and technologies, unpredictability and unmanageability, hard to carry out traditional assurance  accreditation (e.g. Common Criteria) etc.  3.1 SOA security concepts  Just like the numerous SOA definitions, there are numerous SOA security concerns that may differ for each  stakeholder in the “SOA puzzle”: industry, government, vendors, security experts, consultants, analysts etc. There is  also an abundance of literature, most of it biased towards specific aspects, stakeholders, approaches, products etc.  Concerns can be about business case, technology, governance, accreditation, deployment, return‐on‐investment,  future‐proofing, hype vs. reality etc.  From an abstract perspective, the basic SOA security requirements do not seem to differ much from those of other IT  environments:  • Confidentiality, integrity:   Information usage, storage, and transmission, as well as access to IT resources, may need to be governed  • Availability:   Availability of the IT resources to the business may be  desirable or necessary  • Accountability:  Usage of resources and information may need to be governed e.g. to demonstrate regulatory compliance  • Manageability:  IT security should be manageable without undue complexity/cost, which can be hard in large,  unstructured, heterogeneous IT environments  3.2 SOA security complexities  However, SOA may introduce (or make evident) a number of additional complexities related to security, including:  • Heterogeneity:  Security in large IT environments may mean that many different security technologies have to be  deployed to meet specific requirements. These security technologies also might have to protect different  middleware platforms.  • Multi layer protection:  The assets have to be protected as various layers and at different places. For example, to enforce the  confidentiality of data it might be necessary to use file access control, encryption of backup files,  database access control, middleware layer access control, transport layer encryption and IP filtering.   • Agile security:  Security is harder in agile/changing IT environments such as agile SOA. Mechanisms and policies need to  be constantly kept coherent with the actual high level security policies, and operational and functional  requirements. This makes a protection and also accreditation of complete applications a great challenge,  because there are no static systems anymore.   Agility is a key selling point of SOA, but security policy management is impacted heaviest by SOA agility.  This is because many traditional security policy management systems will typically implement a static  security policy for a static system.   ObjectSecurity Ltd. St John’s Innovation Centre Cowley Road Cambridge CB4 0WS England Tel: +44 (0) 1223 420 252 Fax: +44 (0) 1223 420 844 Email: ObjectSecurity LLC Plug & Play Tech Center, 530 University Ave, Palo Alto, CA 94301, USA, Tel. +1-650-515-3391, Fax +1-360-933-9591, Email:,
  • 7. This approach does not work for SOA because the particular deployment is not known at design time,  but is rather flexibly orchestrated ‘on the fly’ using BPM workflow tools (in the long‐term vision of SOA).  Security policies can therefore also not easily be specified at design‐time, and policies will need to be  updated every time the SOA deployment changes.  • Defence assurance accreditation of agile SOA environments:  This is an open question. As noted before, the accreditation notion of ‘system’ and ‘system of systems’  for SOA environments are quite fuzzy. Assurance accreditation (e.g. Common Criteria) therefore needs a  changed approach for SOA security, and model‐driven security has been proposed as a potential step in  the right direction.  • Opened‐up information sources (de‐perimeterisation):  In SOA, many previously siloed (and thus easier‐to‐secure) information resources are typically made  available on the network as service to enable SOA integration, instead of monolithic applications; this  move has obvious significant security implications because a much better, more fine‐grained level of  security may be required and the protection cannot be implemented in the application itself anymore.  • High complexity of interactions:  Single business process are not implemented as monolithic applications anymore, but as complex  interactions of many services. This greatly increases the complexity of protection and the related security  policies. A single action of a user now results in sequences of service interactions, which all have to be  protected based on fine grained security policies and context information. Human administrators are  normally not able to define security policies with sufficient correctness and assurance.  • Manageability:  Security policies typically get large, complex, unwieldy, and  frequently changing. SOA security needs to  have good security policy management support designed in from the beginning to ensure cost‐ effectiveness and trustworthiness into the security. This includes unified and automatic policy updates to  keep to enforce a consistent security policy and a central notification of relevant events.  • Security architecture:  In more “evolved” versions of SOA, the security architecture needs to be aligned with business security  requirements (e.g. business processes) to make sure all stakeholders are “on the same page” with  respect to their security requirements.  • Technology driven security:  Today, security is looked at from a technology driven perspective, in terms of firewall and cryptography.  It is necessary to “bring security to the business level”, to think in terms of services, resources and high  level security intent.  • Who is responsible for security?  In most enterprises, the responsibility for security is scattered to different departments, e.g. the  networking department runs firewalls and VPNs, the application developers implement application level  security and so on.   • Security standards and technologies are in a flux:  A particular complexity of SOA security is that “vendors and committees have thrown a bewildering  plethora of immature or incompatible security specs and solutions at us”3. There are numerous SOA/XML  related consortia that all standardise overlapping specifications. There is little overarching architecture  and/or harmonisation. This results in significant SOA security roll‐out complexity.  • Insufficient security infrastructures:  In the past, organisations made considerable investments into security infrastructures like identity  management. These infrastructures might not meet the requirements of SOA anymore.                                                                    3‐oriented/?p=925  ObjectSecurity Ltd. St John’s Innovation Centre Cowley Road Cambridge CB4 0WS England Tel: +44 (0) 1223 420 252 Fax: +44 (0) 1223 420 844 Email: ObjectSecurity LLC Plug & Play Tech Center, 530 University Ave, Palo Alto, CA 94301, USA, Tel. +1-650-515-3391, Fax +1-360-933-9591, Email:,
  • 8. • Regulatory requirements:  Business applications have to meet specific regulatory requirements. In monolithic applications, the  security requirements derived from these regulatory requirements were hard coded. This is not possible  anymore. It is also hard to drive coherent business‐driven compliance requirements into the IT  infrastructure, and maintain compliance in the face of SOA agility. Regulatory compliance requirements  will drive a lot of the need for SOA security, because both SOA and regulatory compliance happen to  coincide timing‐wise.  • Separation of concerns:  In monolithic systems, the enforcement of complex security policies was mostly hard coded. In SOA  based systems, it is not possible to hard code security enforcement anymore, since this would be an  obstacle to service reuse. Now a separation of concerns is required, the service implements pure  business functionality, and complex security policies now have to be enforced in a different way. Using  standard security systems like identity management, this might be difficult to impossible.  • Cross domain issues:  SOA applications can span multiple organisations which normally do not fully trust each other. Also,  organisations will provide services for other organisations, like in the grid vision. This leads to many  additional regulatory and security issues.  • Availability of human resources:  Is sufficiently skilled personnel available? This is esp. doubtable because in the past not even much more  simple systems were sufficiently protected.  • How is SOA security related to overall enterprise security?  Does SOA security require specific security architectures and systems? Or can SOA security be well  embedded into overall enterprise wide security. For example, is a single security architecture able to  support SOA and also data driven, message driven and event driven architectures as well? Or how does  SOA security relate to the other layers, e.g. does it add complexity to other infrastructure security?  • Integration with Intrusion Detection Systems (IDS):  With the introduction of SOA, the traffic both on internal networks and gateways to the outside world is  becoming much more complex. This greatly complicates the use of network based Intrusion Detection  Systems, because it is now much harder to separate suspicious from legitimate traffic.   • Security monitoring:   How can compliance at any point in time be monitored and demonstrated in a way humans understand?  This is hard, especially in cross‐platform, agile SOA environments.  • Externalised security enforcement:  To enable reuse and agility, security enforcement should be done external to the application logic (e.g.  on the middleware and/or below). This is sometimes hard to achieve, especially for legacy systems that  contain hardcoded security features .  3.3 What are really the main SOA security concerns?  This question forms the central part of the discussion (workshops, document feedback, wiki etc.). One main purpose  of this project is to ensure that the wider community has more of an understanding of the real SOA security concerns.  The KTN and wider community are highly encouraged to provide further examples of SOA security aspects.   Concerns that need to be answered include:  • It is clear that SOA security is a relevant problem – but are we asking the right questions?  • Is SOA security really perceived as a show‐stopper?  • Why is SOA security difficult or perceived as difficult?  • What approaches and solutions are out there?  ObjectSecurity Ltd. St John’s Innovation Centre Cowley Road Cambridge CB4 0WS England Tel: +44 (0) 1223 420 252 Fax: +44 (0) 1223 420 844 Email: ObjectSecurity LLC Plug & Play Tech Center, 530 University Ave, Palo Alto, CA 94301, USA, Tel. +1-650-515-3391, Fax +1-360-933-9591, Email:,
  • 9. • Who is to be responsible for security of SOA applications?  • Does SOA security require specific training and education?  • Where is SOA security today? Does it meet end‐user requirements?  • Where will SOA security be in 1, 2, 5, 10 years? Will SOA still be around? Will it deliver?  • Does SOA security fit into the future trends and developments in security? Can it be reused for data  centric or message oriented systems as well, or does it require specific security architectures?  • Where are the standards going? Will they consolidate, or will there be a “next best thing” instead?  • How can we document, demonstrate, or even prove that the SOA is secure, especially if it is rapidly  changing (e.g. Common Criteria)?  • How can SOA security be governed well (within an overall SOA governance approach)    The SOA security concerns identified in this initial document were used as a basis for an online survey located at‐ The findings from the survey are used as input for the final document.  The questions asked were:  • What best describes your organisation's primary role in the context of SOA? Please note that this survey is  aimed at end‐user organisations that plan to adopt SOA.   • Which vertical market do you operate in or offer your products/services to?   • What is your primary job role?   • How many employees has your organisation?   • How IT savvy do you rate your organisation?   • How far has your organisation progressed today with the adoption of SOA?   • Which architectural features are planned as part of our organisation's SOA adoption?   • Who in your organisation is responsible for SOA adoption and/or governance?   • Do you observe tangible benefits from your SOA adoption today?   • Where do you see your SOA adoption five years from now?   • Where do you see your organisation's SOA adoption 10 years from now?   • How important is security for your organisation, taking into account risks, benefits, and costs?   • How much do you think SOA adoption impacts the overall security of your organisation?   • Does security play a role in your SOA adoption roadmap?   • How are you planning to adopt security for SOA in your organisation?   • Budget: Do you have a budget for SOA security, i.e. does your organisation's management buy into SOA  security?   • How large is your organisation's budget for SOA security approximately over the next 3 years?   • How will you measure return on investment (ROI) for SOA security?   • Who controls the budget and the process, i.e. who procures SOA security products/services in your  organisation?   • Do you feel that product vendors sufficiently address security concerns in their SOA products?  ObjectSecurity Ltd. St John’s Innovation Centre Cowley Road Cambridge CB4 0WS England Tel: +44 (0) 1223 420 252 Fax: +44 (0) 1223 420 844 Email: ObjectSecurity LLC Plug & Play Tech Center, 530 University Ave, Palo Alto, CA 94301, USA, Tel. +1-650-515-3391, Fax +1-360-933-9591, Email:,
  • 10. • How do you rate the importance of the following security aspects to the success of SOA security and SOA in  general?   • What does SOA primarily mean to you from a technical perspective? Please choose the most relevant.   • Which architectural paradigms are you planning to use for your SOA applications?   • Which middleware platforms are you planning to use for the development of your SOA applications?    • Which modeling language are you planning to use, if any?   • Which modelling tools are you planning to use, if any?   • Top‐down: How are you planning to drive business security (+ compliance/privacy/regulatory) requirements  down into the IT department and across the IT landscape?   • Bottom‐up: How are you planning to demonstrate security compliance across the IT landscape up into the  business?   • BPM‐driven SOA: Business Process Management (BPM) is being advocated as a potential model‐driven,  process‐led approach to managing the SOA service/IT layer using process models (often also using BPEL  process orchestration). Some benefits include: agility & reuse, and closer alignment of the business side and  the IT side in the organisation. What are your views on BPM‐driven SOA.   • Model‐driven engineering: Are you planning to build or integrate your applications using model‐driven  approaches (model driven engineering, OMG Model Driven Architecture, model‐driven integration)?    • Are you aware that model‐driven, process‐led approaches are forecasted to become mainstream within 5  years, as a result of increasingly unmanageable IT environments?   • Are you aware of model‐driven security as a way of managing security tied in with model‐driven, process‐led  approaches?   • Are you aware that model‐driven security is forecasted to become mainstream (as a way to simplify policy  management) by piggybacking on model‐driven, process‐led approaches, and to have significant business  impact?   • How are you planning to deal with the increasing business need for IT agility?   • How are you planning to deal with disentangling legacy environments and integrating them into the SOA?   • Is assurance (and potentially certifications/accreditations, e.g. Common Criteria) an issue for you when you  adopt SOA security?   • Would you like us to contact you to discuss any feedback you may have? If so, please enter your email  address (it will not be used for any other purpose!).   • Please enter any other feedback you have about this survey and the project as a whole.         ObjectSecurity Ltd. St John’s Innovation Centre Cowley Road Cambridge CB4 0WS England Tel: +44 (0) 1223 420 252 Fax: +44 (0) 1223 420 844 Email: ObjectSecurity LLC Plug & Play Tech Center, 530 University Ave, Palo Alto, CA 94301, USA, Tel. +1-650-515-3391, Fax +1-360-933-9591, Email:,
  • 11. 4 SOA security compliance  Compliance with regulations and best practice guidelines are one of the main current drivers for SOA security in a  number of industries, including healthcare, financial, and government. Simply put, compliance can be defined as “the  process of adhering to a set of established guidelines or rules established by external bodies such as government  agencies or by internal corporate policies.” (source: O’Grady, 20044). In the context of security, compliance plays an  important role because it forces organisations to deal with security more than maybe pure commercial incentives  would do. In many industries there is a significant price to pay for non‐compliance, both in terms of penalty fees,  compensation, and consequential losses such as damaged reputation and brand.  In order to effective, security compliance requirements need to be dealt with proactively and as an ongoing concern.  Also it is important to realise that security compliance is not only about technology, but also – and very importantly –  about people and processes.  4.1 Why is compliance relevant for SOA?  As such there is no direct correlation between compliance and SOA, except that requirements for both coincide at this  point in time. As a result, SOA security needs to be designed to support current compliance needs.  4.2 Compliance examples  In this section we will consider quite a broad scope, ranging from regulatory compliance over non‐regulatory best  practice guidelines to assurance accreditation (which can be viewed as a form of regulatory compliance). Examples  taken from within that broad scope include:    • UK Data Protection Act and Freedom of Information Act 2000  • EU Data Protection Directive  • Sarbanes‐Oxley (SOX),  Combined Code (the SOX equivalent in the UK), and JSOX (the Japanese version of  SOX)  • Health Insurance Portability and Accountability Act (HIPAA)  • Common Criteria as an example of defence assurance accreditation  • PCI DSS ‐ Payment Card Industry Data Security Standards  • Basel II for financial sector risk mitigation; it is designed to allow the market to have a better picture of the  overall risk position of the bank  • Defence architecture frameworks (like MODAF, DODAF and NAF) are related to compliance and play an  important role in the development and acquisition of defence systems. These architectures are expressed  using standard metamodels and include a large number of ‘views’ that describe a system in great detail (e.g.  interactions between nodes). It is quite possible that these models will also be used for the development of  SOA systems. A MODAF MOF meta‐model is already available5, and MOD could use it for SOA orchestration  purposes.  4.3 SOA compliance drivers  The implementation of SOA compliance is driven by a number of goals, including the following (non‐exhaustive list):                                                                    4  Stephen O’Grady. SOA Meets Compliance: Compliance Oriented Architecture, 2004  5  ObjectSecurity Ltd. St John’s Innovation Centre Cowley Road Cambridge CB4 0WS England Tel: +44 (0) 1223 420 252 Fax: +44 (0) 1223 420 844 Email: ObjectSecurity LLC Plug & Play Tech Center, 530 University Ave, Palo Alto, CA 94301, USA, Tel. +1-650-515-3391, Fax +1-360-933-9591, Email:,
  • 12.   • Minimise the risk of non‐compliance and the associated damage caused (e.g. cost, reputation, loss of  competitive advantage)  • Achieve the required compliance at the lowest cost possible  • Get a compliance “stamp” for marketing purposes (esp. for best practice guidelines)  • Achieve sustainable compliance, to make sure investments in the compliance do not evaporate after changes  to the business or IT (e.g. support “SOA agility”). Compliance is particularly hard to deal with in distributed IT  environments that are “agile”, i.e. get reconfigured regularly. The current architectural style for agile  distributed software applications is Service Oriented Architecture (SOA). One concept behind SOA is to  specify and manage application interactions in an abstract model that bridges the gap between the business  (business processes, workflows, BPM etc.) and IT (platforms like web services, databases etc.). In such model  driven SOA environments, enterprise architects specify work‐flows in Business Process Modelling (BPM)  suites, which are used to orchestrate underlying modular IT services. One of the main benefits is that the IT  environment can be reconfigured easily to reflect changes in the business. For compliance enforcement and  monitoring, SOA agility poses a major complexity because security policies (both for compliance enforcement  and monitoring) will have to be updated each time the IT environment gets reconfigured.  Carrying out such  policy updates manually each time the SOA gets reconfigured is clearly un‐workable because this would be  too costly, too slow, and too error‐prone. So again, a suitable technology approach is required to  automatically update compliance enforcement and monitoring whenever the SOA changes.  • Achieve “real‐time” compliance monitoring to detect and mitigate non‐compliance before damage occurs  • Assign and delegate accountability, ownership and responsibilities  • Align business and IT security compliance requirements in such a way that business compliance requirements  are (ideally automatically and “real‐time”) driven down into IT enforcement, and IT security compliance  monitoring is (again ideally automatically and “real‐time”) brought back up to the business functions. It is one  major difficulty of implementing such regulations is caused the fact that they are expressed at a high level of  abstraction that is organisation‐centric, business‐centric, information‐centric, legal aspects centric and  human‐centric. Regulations are not IT centric, nor expressed in IT terms. This means that the abstract and  high level policy requirements defined by the regulations need to be translated into compliance and security  policies that the IT security infrastructure can enforce. Carrying out this mapping process manually is time  consuming, maintenance‐intensive, costly, and error‐prone. An automated, reliable technology approach is  required to solve these issues.  • Take business processes and people into account – security compliance is normally not just about technology  • Be able to verify and demonstrate (e.g. document) compliance to auditors, or evaluators in the case of  Common Criteria. It is a major difficulty is related to compliance monitoring. How can an organisation  demonstrate sufficiently that it complies with these organisation‐centric, information‐centric and human‐ centric and legal regulations and governance standards? And how can attempted compliance violations be  detected early on and prevented before damage is caused? Doing this manually, as suggested by many  survey‐based compliance tools is too slow, costly, and error‐prone. How can this be done in an automated  way that is cost effective, timely, reliable, and automatic? Again, a suitable technology approach is required.  • Enable auditing as required for demonstrating compliance  • Achieve traceability (“repeatability”) of processes rather than ad‐hoc, non‐deterministic behaviours, i.e. how  trustworthy is the link between the regulation or governance standard on the high layer of abstraction, and  its IT enforcement and monitoring on the low layer of abstraction is. This trustworthiness is relevant for  defence accreditation (e.g. Common Criteria) and many other safety and assurance standards. This is an  especially important factor for agile systems, because accreditation of a static system (the normal way to  achieve accreditation) is not possible.  ObjectSecurity Ltd. St John’s Innovation Centre Cowley Road Cambridge CB4 0WS England Tel: +44 (0) 1223 420 252 Fax: +44 (0) 1223 420 844 Email: ObjectSecurity LLC Plug & Play Tech Center, 530 University Ave, Palo Alto, CA 94301, USA, Tel. +1-650-515-3391, Fax +1-360-933-9591, Email:,
  • 13. 4.4 Common compliance elements  There is clearly a level of overlap between some security compliance regulations. For example, many regulations  across different industries are concerned with the usage and retention of sensitive information (e.g. HIPAA, Data  Protection Act). In a study in 2004, O’Grady6 identified a number of compliance modules, and they believe that the  following services assembled in varying combinations can address the majority of enterprise and governmental  compliance challenges. These services represent a foundation for their modular compliance initiatives (“Compliance  Oriented Architecture”).  While it is beyond the scope of this document to analyse each of these compliance aspects and whether the choices  are correct, complete and most suitable, it illustrates an interesting approach to dealing with the growing regulatory  compliance burden and complexity.  This approach is particularly relevant to SOA because it allows security compliance for particular services to be  designed to support relevant compliance modules, which can then be flexibly reused when designing a SOA security  compliance architecture.    Service    Description    Example    Access Control    Establishes control over access to specific assets and resources according to   Patient records are accessible only to authorized care providers  established rules and processes via authentication and authorization  for HIPAA compliance (Health Care)   elements; prevents unauthorized access and changes   Analytics    Suite of functions encompassing tasks such as data mining and drill down,   Operational data is monitored and analyzed according to Basel II  reporting, querying, measurement, etc   metrics (Finance)    Archive/Backup    Stores long‐term data for cost, convenience, or disaster recovery purposes    Figures such as Work In Progress (WIP) and inventory metrics are  transferred to offsite tape to prevent loss in the event of an event  affecting the primary datacenter (Manufacturing)    Auditing    Establishes and maintains precise asset history, including creation,   Can be used for forensic purposes to establish a document’s  alteration, renaming, date copied, etc.   chain of custody (Legal)    Collaboration    Enables synchronous or asynchronous communication between individuals,   For public companies, internal finance workers collaborate with  teams or organizations working on the same or related business tasks   external auditing and legal staff members to produce SEC filing  documents such as a 10K (Legal/Government)    Conflict Resolution    Mechanism by which conflicting requirements are automatically identified   Addresses situations such as when HIPAA mandates that its  and resolved according to preset requirements, or if necessary escalated for  retention schedule supersedes those mandated by a US State,  external manual review.   except in cases where state requirements exceed HIPAA’s  (Healthcare)    Destruction    Provides for secure destruction of materials that have reached the end of   At the end of the SEC mandatory retention period, broker/dealer  their useful and/or mandated lifespan   orders are securely destroyed (Finance)   Disposition   Mechanism for determining the disposition – or requirements – for a   Workers can designate a file as a record, and assign it a  Management   particular asset   disposition in years to satisfy DoD 5015.2 (Government)    Indexing    Crawls through asset stores and indexes them for easier browsing, search   Retained drawings, requirements and specifications for a  and retrieval   manufactured component are crawled and indexed to ease the  litigation discovery process (Manufacturing)    Information Integration  Provides the ability to unify disparate data sources and types to create a   Different data sources and repositories are connected and  virtual data source composed of two or more data sources of record   accessed to provide the customer information profile as required  by the PATRIOT Act (Insurance)    Monitoring    Watch specific assets or resources for specific actions, events or conditions,   For public companies, data stores are monitored for  often using an agent‐based approach.   unauthorized and/or inappropriate access indicative of fraud  (Publicly Held Firms)    Notarization    Attests to and certifies basic asset creation elements such as author, date   FDA submissions may be notarized prior to their submission for  created   the purposes of complying with Title 21 CFR 11 (Pharmaceutical)    Policy Engine    Translates human language policy information into machine readable and   Firms can ensure that Gramm‐Leach‐Bliley compliant privacy  actionable instructions and rule sets   policies are implemented and adhered to across their  infrastructure (Finance)   Process Registry    A directory of available compliance related services and the compliance   Patient record application can seek out and access retention  problems they map to; the registry should allow for automated discovery and  services dynamically for compliance storage purposes (Health                                                                    6  Stephen O’Grady. SOA Meets Compliance: Compliance Oriented Architecture, 2004  ObjectSecurity Ltd. St John’s Innovation Centre Cowley Road Cambridge CB4 0WS England Tel: +44 (0) 1223 420 252 Fax: +44 (0) 1223 420 844 Email: ObjectSecurity LLC Plug & Play Tech Center, 530 University Ave, Palo Alto, CA 94301, USA, Tel. +1-650-515-3391, Fax +1-360-933-9591, Email:,
  • 14. description of compliance functions. UDDI and or ebXML will potentially  Care)  underpin the registry approach.    Retention    Ensures that assets are retained at a minimum for their required lifespan,   Agencies can comply with DoD 5015.2 regulations regarding  and are not deleted, lost or corrupted prior to their scheduled end of life   document retention and disposition (Government)    Retrieval    Supported by Indexing and Tagging, provides for retrieval of asset based   Firms can comply with email discovery by retrieving only assets  search or browse based retrieval as required   related to the specific request made (Legal)    Tagging    Mechanism for attaching and storing metadata to assets for later   CAD/CAM drawings may be tagged with descriptive metadata  consumption and manipulation   including date created, product usage, raw material type, etc  (Engineering)    Version Control    For iteratively developed assets, provides for documented version capture of  For public companies, provides capture at each stage of  asset at each stage in its lifecycle   collaboratively developed assets like SEC submissions (Publicly  Held Firms)    Workflow    Implements established business processes to provide clear, repeatable   Provides clear, repeatable process for processing Criminal  procedures that can be controlled   Offender Record Information (CORI) requests (Education)    Table Compliance Modules (source: S. O’Grady, SOA Meets Compliance)  4.5 SOA security compliance challenges  Many of the challenges of implementing effective compliance echo the complexities of SOA security . In particular:  4.5.1  Sustainable compliance and dynamic/agile business and IT environments  It is important to ensure that investments in SOA compliance are reusable and do not “evaporate” after SOA changes.  One approach is to specify requirements in models and drive them down into enforcement, with as much automation  of the process as possible save costs and to enable quick updates. This approach is called Model Driven Security (see  below).  4.5.2 Challenge ‐ Aligning business compliance requirements and IT enforcement/monitoring  Ultimately the business drives security compliance requirements, so it is critical for SOA security to close the loop  between business requirements and IT implementation/enforcement. This is hard when the system and/or business  processes change dynamically. Again, Model Driven Security can help solve these issues.  4.5.3 Security policy management for SOA  Defining and managing compliance requirements for SOA can be difficult because of the complexity of the networked  system, its dynamicity (agility) nature, the many stakeholders involved etc.  Model Driven Security (MDS7) is an innovative technology approach that can help solve these problems. MDS can be  defined as the tool supported process of modelling security requirements at a high level of abstraction, and using  other information sources available about the functional aspects of the system (produced by other stakeholders).  These inputs, which are expressed in Domain Specific Languages (DSL), are then transformed into enforceable security  rules with as little human intervention as possible. MDS explicitly also includes the run‐time security management  (e.g. entitlements/authorisations), i.e. run‐time enforcement of the policy on the protected IT systems, dynamic policy  updates and the integrated monitoring of policy violations.  In the first step of MDS, regulations and governance standards are modelled as a high‐level security policy in a model‐ driven security tool (such as ObjectSecurity’s OpenPMF 2.0). These models are then translated into low‐level security  policies that are enforced across the entire SOA environment (e.g. through local plug‐ins integrated into the  middleware or at a domain boundary). The local plug‐ins also deal with the monitoring of compliance/security‐ relevant events. If tied into the SOA BPM suite and the SOA middleware (e.g. web application server), Model Driven  Security can automatically update the compliance enforcement and monitoring whenever the SOA application  changes.                                                                    7  ObjectSecurity Ltd. St John’s Innovation Centre Cowley Road Cambridge CB4 0WS England Tel: +44 (0) 1223 420 252 Fax: +44 (0) 1223 420 844 Email: ObjectSecurity LLC Plug & Play Tech Center, 530 University Ave, Palo Alto, CA 94301, USA, Tel. +1-650-515-3391, Fax +1-360-933-9591, Email:,
  • 15. Model‐driven security management (as outlined at has the following benefits:   • Model driven security regulates information flows and resource access between different systems (or  software services/components) and users in a fine‐grained, policy‐driven way across a potentially large,  heterogeneous IT environment. Furthermore, it ensures that security policy updates caused by IT agility, i.e.  changes to the IT environment, can be managed without a maintenance cost explosion. All this helps reduce  the security management effort.  • Another core benefit is that model‐driven security management helps align business security requirements  (including regulatory and best‐practice security requirements) and policy‐driven technical IT security  enforcement. This means that security requirements, which can be captured in an undistorted, abstract way  close to human/business thinking, can be automatically transformed into technology‐centric IT security  enforcement. This reduces the cost and effort of security policy definition and maintenance. The automated  technology approach also improves the traceability from requirements to enforcement and improves  assurance, because human administration errors are minimised.  • In addition, the model‐driven security approach can tie security requirements into the overall business  enterprise architecture, which ensures that the needs of the business are reflected.  MDS is an emerging hot topic that is forecasted to become mainstream and have “significant impact” in ca. 5 years  (source: Gartner), piggybacking on the mainstream of model‐driven, process‐led approaches (source: Gartner).  Furthermore, a number of significant end users and vendors have worked with the authors because of the significance  of model‐driven security for their projects, including US Navy, US Air Force, UK Ministry of Defence, BAA Heathrow  Airport, a large German enterprise software vendor, and others. It was also used in the development of a prototype of  secure air traffic management systems (ATM) in preparation of SESAR, the European Single European Sky ATM  Research programme coordinated by Eurocontrol.   4.6 How to procure SOA security?  It is important to have a clear roadmap towards SOA security. This roadmap needs to be tied in with the general SOA  adoption roadmap, to ensure that the rest of the adoption does not put show‐stoppers onto SOA security. It is also  important to have a gradual adoption strategy to avoid a costly, internally unsellable “big bang” rollout. Also existing  infrastructure needs to be reused wherever possible.  4.6.1 Roadmap towards model‐driven SOA security policy management  There is little doubt that model‐driven approaches in general will become mainstream over the coming years (in  whatever form). This is because IT complexity in today’s complex, interconnected, ever‐changing, ever‐faster world  has become unmanageable, and it has always been human nature to try to find an abstraction in order to be able to  easier deal with that complexity. It may not be what we see as model‐driven approaches today, but it will be based on  the same idea of finding a human‐understandable, simplified abstraction layer to the underlying complexity.  On the other hand, pervasive changes to IT and business staff behaviour and technology has always posed a  formidable adoption hurdle. However, industry analysts such as Gartner forecast model‐driven approaches to become  mainstream within five years, based on high‐profile, big‐vendor pushes (e.g. Microsoft “Oslo” initiative). Model‐driven  security will then be a feature with obvious benefits in the overall architecture.  Irrespective of that, the adoption of model‐driven security does not have to wait for model‐driven approaches to  become mainstream. Instead, a non‐intrusive gradual adoption roadmap is possible, starting with authorisation  management as a policy‐driven add‐on to today’s identity management (IdM) deployments. While not model‐driven,  such authorization management (integrated with IdM) can help bridge the time until full model‐driven security gets  adopted.   While a number of authorization management solutions (mostly XACML based) are available today, only OpenPMF 2.0  provides the upgrade roadmap towards model‐driven security. The most complete deployment of OpenPMF model‐ driven security is a scenario where a model‐driven security tool is used as an enterprise‐wide security management  tool that ties in with enterprise architecture (incl. BPM) , model‐driven integration, model‐driven engineering. Such a  pervasive deployment would do away with the many different and incompatible ways of managing security  ObjectSecurity Ltd. St John’s Innovation Centre Cowley Road Cambridge CB4 0WS England Tel: +44 (0) 1223 420 252 Fax: +44 (0) 1223 420 844 Email: ObjectSecurity LLC Plug & Play Tech Center, 530 University Ave, Palo Alto, CA 94301, USA, Tel. +1-650-515-3391, Fax +1-360-933-9591, Email:,
  • 16. infrastructure, and thus provide significant benefits, including cost‐saving and manageability. An additional benefit of  such a deployment is that the end customer “owns” the security policy model, and is therefore in a position to  outsource most of the IT and IT security infrastructure “plumbing” to vendors and integrators without losing control  and in‐house security expertise. The authors call this highly beneficial adoption scenario an ”enterprise‐wide security  ecosystem management”.  4.6.2 SOA security and defence procurement  Two potential approaches to the adoption of MDS for MOD SOA are to either adopt MDS as a strategic security  management framework (beyond SOA) independently of SOA adoption, or adopt MDS gradually as a SOA enabler as  and when needed. The choice is probably mostly political. Either way, further research is needed to ensure SOA agility  can be enabled while achieving SOA accreditation.                ObjectSecurity Ltd. St John’s Innovation Centre Cowley Road Cambridge CB4 0WS England Tel: +44 (0) 1223 420 252 Fax: +44 (0) 1223 420 844 Email: ObjectSecurity LLC Plug & Play Tech Center, 530 University Ave, Palo Alto, CA 94301, USA, Tel. +1-650-515-3391, Fax +1-360-933-9591, Email:,
  • 17. 5 APPENDIX – SOA SECURITY CASE STUDIES  This section will include case studies of SOA environments. All contributions are highly encouraged. Please contact  contact@secure‐ if you have any case studies that you would like to contribute.  So far, ObjectSecurity has contributed an air traffic management related case study that highlights the security  complexity of today’s distributed IT landscapes.      ObjectSecurity Ltd. St John’s Innovation Centre Cowley Road Cambridge CB4 0WS England Tel: +44 (0) 1223 420 252 Fax: +44 (0) 1223 420 844 Email: ObjectSecurity LLC Plug & Play Tech Center, 530 University Ave, Palo Alto, CA 94301, USA, Tel. +1-650-515-3391, Fax +1-360-933-9591, Email:,
  • 18. 6 APPENDIX – SOA security solutions approaches and examples  This section will include solutions approaches for SOA security. All contributions are highly encouraged. Please contact  contact@secure‐ if you have any solutions approaches or solutions examples that you would like to contribute.  So far, ObjectSecurity has contributed healthcare related solutions approach and example based on their OpenPMF  ( product and the model‐driven security ( approach.        ObjectSecurity Ltd. St John’s Innovation Centre Cowley Road Cambridge CB4 0WS England Tel: +44 (0) 1223 420 252 Fax: +44 (0) 1223 420 844 Email: ObjectSecurity LLC Plug & Play Tech Center, 530 University Ave, Palo Alto, CA 94301, USA, Tel. +1-650-515-3391, Fax +1-360-933-9591, Email:,
  • 19. 7 Executive summary & conclusion    <to be added end of November>    ObjectSecurity Ltd. St John’s Innovation Centre Cowley Road Cambridge CB4 0WS England Tel: +44 (0) 1223 420 252 Fax: +44 (0) 1223 420 844 Email: ObjectSecurity LLC Plug & Play Tech Center, 530 University Ave, Palo Alto, CA 94301, USA, Tel. +1-650-515-3391, Fax +1-360-933-9591, Email:,
  • 20. 8 APPENDIX  ‐ Further information  8.1 General resources‐  www.cybersecurity‐  www.soa‐‐Security‐Kompendium.pdf  8.2 Vendor resources:      <please contribute any resource links you may have or know of>  ObjectSecurity Ltd. St John’s Innovation Centre Cowley Road Cambridge CB4 0WS England Tel: +44 (0) 1223 420 252 Fax: +44 (0) 1223 420 844 Email: ObjectSecurity LLC Plug & Play Tech Center, 530 University Ave, Palo Alto, CA 94301, USA, Tel. +1-650-515-3391, Fax +1-360-933-9591, Email:,
  • 21. 9 APPENDIX – Survey analysis details    <to be added end of November>  ObjectSecurity Ltd. St John’s Innovation Centre Cowley Road Cambridge CB4 0WS England Tel: +44 (0) 1223 420 252 Fax: +44 (0) 1223 420 844 Email: ObjectSecurity LLC Plug & Play Tech Center, 530 University Ave, Palo Alto, CA 94301, USA, Tel. +1-650-515-3391, Fax +1-360-933-9591, Email:,
  • 22. 10 APPENDIX – Original document and project overview  10.1 Planned project purpose  The purpose of this project is to produce a level of common understanding about the main SOA security concerns in  different domains, e.g. business, defence or critical infrastructure. The final report will summarise the security  concerns of both the end‐user side (i.e. organisations that try to use SOA) and the vendor/provider side (i.e. SOA  integrators, vendors, universities/educators, consultancies etc.). The final report is intended as a vendor‐independent  public resource that reflects a broad range of concerns from all involved stakeholders. It is intended to provide a  broad understanding about the main SOA security concerns that will help all stakeholders come closer to SOA roll‐ outs, products and education that include appropriate security.  The aim is to include as many relevant concerns as possible using a process that is as open and inclusive as possible.  To achieve this, the project purpose is also open to discussion (within the project scope) by the KTN.  10.2 Planned project approach  This project is run as open as possible. The KTN circulates an initial fact‐finding document, then run several  consultation workshops with end‐users, suppliers (products, solutions, services, training/education), and analysts to  collect their views on SOA security concerns. The KTN set up an informational website and a blog/wiki etc. area where  we will facilitate additional dialogue between interested parties. The KTN will also connect with various suitable SOA  industry consortia to solicit input. In addition, the KTN will set up an on‐going online survey (located at‐ to assess how UK stakeholders see SOA security and SOA in general. The findings from the survey will be  used as input for the final document.  The purpose is twofold: firstly to get as broad as possible input to ensure the deliverable accurately captures real  problems and solutions from all angles (business, vendors, science, market etc.); secondly, to facilitate the creation of  a SOA security community across the UK and across all stakeholders involved.  10.3 Fact‐finding document purpose  The purpose of this document is to “set the scene” for the discussion within the KTN, the wider community and the  workshops. The document offers a first range of definitions of SOA, and a first number of SOA security concerns. This  document is circulated to the community for feedback and input. This will allow all stakeholders to provide their  views.   The reason for this approach is because one problem related to SOA security is that there are many different aspects,  views, and opinions, which results in quite a bit of confusion in the end‐user community. Because of the underlying  lack of consensus of what SOA means, the fact‐finding document will also collected different views about SOA  definitions. This is an important part because some SOA security concerns will obviously depend on the particular  chosen definition of SOA.  The collected input will form the basis for further scoping/de‐scoping and the approach.   10.4 Project scope  As mentioned above, there is a lot of confusion about what SOA actually means in business and technical terms  (“Same Old Architecture”?) and what it is good for (“SOA what?” like in “so what?”), what the technical and business  show‐stoppers are, what the best adoption roadmap is etc.   This initial document does not restrict the definition of the term SOA or the list of security concerns.  Depending on  the feedback from the community, the final report will be either broad (if many different views are presented) or deep  (if there is a topical convergence).  ObjectSecurity Ltd. St John’s Innovation Centre Cowley Road Cambridge CB4 0WS England Tel: +44 (0) 1223 420 252 Fax: +44 (0) 1223 420 844 Email: ObjectSecurity LLC Plug & Play Tech Center, 530 University Ave, Palo Alto, CA 94301, USA, Tel. +1-650-515-3391, Fax +1-360-933-9591, Email:,
  • 23. 10.5 Outputs – for the KTN, UK PLC, government, and academia  The deliverable will be a publicly report about SOA security concerns (depending on update, also a community website  that will be handed over to the KTN, and hopefully also an interactive UK stakeholder SOA security community.  The document will help end‐users identify what is important from a security perspective when rolling out SOA.  Vendors and universities will benefit from an improved understanding of the real business concerns of SOA security,  so they can better align their products and research with end‐user requirements.  10.6 Approach – Workshops, surveys  This project will be run as open as possible. We will run several consultation workshops with end‐users, suppliers  (products, solutions, services, training/education), and analysts to collect their views on SOA security concerns. We  will also set up an on‐going online survey to assess how UK stakeholders see SOA security and SOA in general. We will  set up an informational website and a blog/wiki etc. area where we will facilitate additional dialogue between  interested parties. We will also connect with various suitable SOA industry consortia to solicit input.  The purpose is twofold: firstly we want to get as broad as possible input to ensure the deliverable accurately captures  real problems and solutions from all angles (business, vendors, science, market etc.); secondly, we want to facilitate  the creation of a SOA security community across the UK and across all stakeholders involved.  10.7 Project timetable  The project will be based around the following key dates:  • 31 June   Circulate short introductory paper with provisional definitions, goals, issues, solutions, market maturity  and direction assessment etc. to the KTN and the wider community to invite feedback    • 20 August – 15 September   1‐day SOA “consumers” workshop: End‐user SOA security workshop – discuss end‐user concerns  (without vendor focus) with government (civilian/defence), industry, and analysts/experts  • 20 August – 15 September   1‐day SOA “suppliers” workshop: SOA security vendor workshop – discuss solutions and concerns  (product focussed, training focussed), e.g. problems to get SOA adopted; suppliers incl.  analysts/experts/universities etc.  • 01 October  Circulate draft deliverable of the final report that takes all input into account, circulate to KTN for  feedback  • 14 November  Finalised report handed over to KTN  • 04 December  Findings presented at KTN Christmas event in Bletchley Park  The project wiki, webpage, and mailing list will be available throughout the project.  10.8 ObjectSecurity’s role  Although ObjectSecurity’s offerings include SOA security, ObjectSecurity’s staff will act as an independent facilitator  because the benefits of the project can be expected to be maximised if the final report fairly reflects the inputs of the  entire community. Particular vendor/supplier/educator products and services will only be mentioned if necessary for  the discussion, or e.g. if a general SOA security product/services catalogue is deemed appropriate by the community.  This initial fact‐finding document reflects ObjectSecurity’s assessment of the subject area. It is produced to “set the  scene” and to foster further discussion to reflect the wider community’s views in the final report. ObjectSecurity’s  ObjectSecurity Ltd. St John’s Innovation Centre Cowley Road Cambridge CB4 0WS England Tel: +44 (0) 1223 420 252 Fax: +44 (0) 1223 420 844 Email: ObjectSecurity LLC Plug & Play Tech Center, 530 University Ave, Palo Alto, CA 94301, USA, Tel. +1-650-515-3391, Fax +1-360-933-9591, Email:,
  • 24. team is qualified for this project because it is currently involved as the security consultant (and potential vendor) in a  number of SOA projects, and has therefore first‐hand experience in the issues and concerns that need to be  addressed. ObjectSecurity:  • has real‐world market experience in SOA security procurement (from a vendor & consultant perspective)  • has internationally acclaimed scientific and technical competence in the area of SOA security,  middleware  • has several thousand related business connections to end‐users (government and commercial) and  vendors  • has a useful track record in a number of SOA projects both as a consultant and vendor  • has significant experience in running SOA security workshops similar to the ones proposed for this  project  • has some in‐house assurance accreditation knowhow (e.g. understanding of Common Criteria)  • has significant experience in the development of SOA security related documents that cover both  business/technical breadth and technical depth        ObjectSecurity Ltd. St John’s Innovation Centre Cowley Road Cambridge CB4 0WS England Tel: +44 (0) 1223 420 252 Fax: +44 (0) 1223 420 844 Email: ObjectSecurity LLC Plug & Play Tech Center, 530 University Ave, Palo Alto, CA 94301, USA, Tel. +1-650-515-3391, Fax +1-360-933-9591, Email:,