This will be the last [at least for a while] post in the SOA Security Series, and I want to conclude by sharing my vision and some recommendations and best practices (most of them fairly common sense) that I have noticed, stole and otherwise accumulated while working in this field. But before we start, I would like to fill the gap that I left in my earlier postings by never providing a

Definition of Secure SOA

Secure SOA is an approach to implement SOA which by design ensures trust throughout the SOA ecosystem (including services, consumers, composite applications and infrastructure) by addressing some or all of the following security aspects:

• Authentication
• Authorization
• Integrity
• Confidentiality
• Accountability (monitoring, logging, audit, non-repudiation)
• Identity (federation, provisioning, trust brokering)
• Security Policies

It is also worth mentioning that I firmly believe that Secure SOA is best viewed as a specific case of Governed SOA.

Common SOA Security Requirements

I have a dream that all SOA Security platforms, implementations and mechanisms will be:

• Agile – able to change at business speeds
• Policy-driven – giving all stakeholders freedom to change their mind
• Not client- or service-bound – applicable outside the individual domains of control
• Usage- and context-sensitive – allowing service providers and their agents the freedom to have different security for different circumstances
• Granularly applicable – not forcing the adopters to deal with the all-or-nothing dilemma
• Brownfield-friendly – can be retrofitted into existing environments without requiring heroic efforts or causing unnecessary disruptions
• Centrally controlled
• Ubiquitous – not limited to a single technology, platform, protocol, transport or product
• Extendable – affording everyone the freedom to add
  • new mechanisms
  • new Aspects (censorship, throttling, privacy)
  • new providers
  • new kinds of relationships (federations, aggregations, delegation, trust, etc.)
  • support of new standards and specifications
  • defense against new threats
  • ... and utilize new capabilities (HSM, accelerators)

Recommendations for Building Secure SOA

• Enterprise-grade SOA Security can not be bought – it has to be architected, implemented and maintained. Do not confuse Software Security with Security Software.
• Do not address SOA Security in isolation as a point solution, but try to address it as one of the aspects of a comprehensive governance solution in conjunction with QoS, versioning, lease and other governance aspects.
• Avoid redundancy and duplication – look for a solution that can delegate governance functionality to your existing infrastructure and governance solutions (e.g. security and identity packages).
• Do not look for easy fixes (like applying security at the perimeter or relying on transport layer security) and magic bullet solutions – real security takes work.
• SOA ≠ Web Services so do not settle for a solution which artificially limits the scope of security and governance to that technology.
• To ensure wide adoption of SOA across your enterprise, do not make service consumers and producers bear most of the compliance burden – your solution should be able to take care of most things.
• Do not let your security solution undo the main benefit of SOA by re-coupling service consumers and producers to each other, policies, etc.
• Vendors are involved in an arms race of standard compliance. Do not be fooled by a lengthy checklist of supported standards – it does not guarantee better interoperability or security. And standards will change. Look for a solution which gives you freedom to choose which standards to support and when to support them – seek a solution which gives you freedom to change your mind!
• Do not delay implementing security until “phase 2”
• Beware of those (clients, colleagues, partners, etc.) who believe they are secure
• Do not assume it is someone else's job
• Do not forget that SOA Security is still a kind of security, so all the regular principles apply:
  • Defense in depth
  • Threat analysis
  • Assumption vulnerabilities
  • Weakest point
  • All traditional threats still exist
• And never forget that common sense!

Please bookmark with social media, your votes are noticed and appreciated: