Rolando Carrasco

Rolando Carrasco


Rolando Carrasco is co-founder and CTO of Services & Processes Solutions. This company focuses on Fusion Middleware, specializing in Weblogic, SOA, BPM, Identity Management, ADF, Webcenter, and Coherence. Rolando previously worked for Oracle in the Product Management Division, and also in the pre-sales group in Latin America. He is an Oracle Service Oriented Architecture Infrastructure Implementation Certified Expert as well as Oracle BPM Implementation Certified Specialist. He has also been recognized as an Oracle ACE. Rolando is also a regular contributor for SOA Magazine and Oracle Technology Network (OTN), as well as leader of the Mexican Oracle User Group’s (ORAMEX) directive board.


rss  subscribe to this author

Tabata Jessica Pérez

Tabata Jessica Pérez


Mt. Tabata Jessica Pérez (MTIA) is an accomplished IT professional, specializing in Enterprise Architecture, SOA, BPM and Information Security. She graduated with honors as a systems engineer from IPN ESCOM in Mexico City and recently obtained a double Master’s degree in Information Technology Administration (ITAM, TELECOM Ecole de Management). Her recently published thesis verses on information security applied to SOA projects in the insurance sector. She currently works as an IT Architect in Nacional Monte de Piedad (Mexico City) and holds certifications in Java, Oracle, IT Methodologies and Information Security. Tabata has been a frequent speaker at conferences such as BSecure, Oracle OTN Tour and IPN Technology Week.


rss  subscribe to this author

Francisco Arturo Viveros

Francisco Arturo Viveros


Francisco Arturo Viveros is an outstanding professional currently based in Mexico City, with 11 years of experience in the development, design, architecture and delivery of IT Projects for a variety of industries. He is also a frequent technology blogger and regular speaker in technology conferences, both in Mexico and abroad. Arturo has several IT certifications, including Oracle IT Architecture SOA, Java Programmer & Web Component Developer and has been recently recognized as an Oracle ACE. He also has obtained the SOA Architecture and Cloud Architecture Certifications by Arcitura Inc. with honors, and is a certified trainer for both. Arturo is also a regular contributor for SOA Magazine and Oracle Technology Network (OTN), as well as part of the Mexican Oracle User Group’s (ORAMEX) directive board.


rss  subscribe to this author


The SOA Myth Busters Present: "SOA & Information Security" Published: June 10, 2015 • Service Technology Magazine Issue XC PDF


So, do you like working with and around SOA? That's great because so do we, and we've been doing it every single day since a long time ago. As SOA professionals, we've seen the concept grow, change and mature, bringing up new dimensions and technology with it.

We're Arturo Viveros and Rolando Carrasco, the SOA Myth Busters from Mexico, and through this series of articles, we will try and put to the test a number of questions, myths and urban legends regarding both Service Orientation & SOA Architectures in search of finding out which myths are true and which are not.


We would like to give a special thanks to our collaborator and friend Tabata Jessica Pérez. Without her hard work, contributions and insight, this article wouldn't have been possible.

About this Episode

In this installment, we will discuss one of the most neglected/overlooked themes when implementing SOA Architecture, and that is information security.

Everyone understands to some point that in the digital era, securing our data, information systems, and communications and so on is of the utmost importance. It is also very clear that these kinds of items can be very easily compromised by a number of threats and vulnerabilities.

After all, who hasn't heard in the news or elsewhere about cyber-attacks, identity theft, wiretapping, hacking, etc.? But what does this all have to do with SOA Architecture?

Taken from our experience collaborating in a vast number of SOA projects, here are a number of statements (or should we say misstatements?) we have commonly bumped into regarding SOA & Information Security:

  • Security is not a priority when designing / implementing an SOA Architecture.
  • Security requirements can be kicked forward until the end of projects and dealt with once the services are in production.
  • Including security considerations in the service's design, will only hinder performance and add undesirable overhead.
  • My web-services are already secure because I have enabled HTTPS communication.
  • My services will be fine unsecured until I decide to expose them to the internet.
  • We don't need to focus on SOA Security because vendor tools can take care of everything by themselves.
  • Penetration and vulnerability tests are unnecessary for SOA implementations.

With many customers/projects, we have experienced large debates, misconceptions and even debacles related to security or the lack of thereof. So:

  • How should we approach security as we are designing a SOA Architecture?
  • Are there any design patterns or methodologies to rely upon regarding this matter?
  • What about external-facing services, APIs, RESTful services, cloud integration, mobile or any scenario that involves communication outside an organization's trust boundary?
  • Which kinds of tools may be well-suited to help us overcome specific security concerns?
  • What are the risks of overlooking information security, and which benefits can be attained by avoiding such a practice?

The Myth:

"When designing and implementing an SOA Architecture, information security and service protection are secondary concerns. Furthermore, security-oriented vendor software can more than hold its own by mindlessly applying a bunch of simple configurations such as HTTPs transport, basic authentication, etc."

Let's Get Started

First and foremost, let's talk a little about information security and its importance in the context of IT environments. So, what do we mean by information?


"A collection of data that is specific and organized for a purpose and that is presented within a context can have both meaning and relevance, ultimately leading to an increase in understanding and a decrease in uncertainty." [REF-1]

It would be safe to say that for any kind of organization, information qualifies as one of its most important assets, one which must be managed carefully and protected at all costs; thus the need for a discipline such as information security:

"A set of policies, controls, processes and procedures put in place to secure the information digested and transmitted by an information system" [REF-2]

What are the consequences then, when information security fails or is rendered insufficient by a known threat such as a cybernetic attack?


Whilst these kinds of attacks are nothing new to the digital world, their reach has heightened to unthinkable levels, with the corresponding impact and repercussions often devastating.

Just in 2014, we had loads of top-secret information leaking from world governments and militia, as well as technology powerhouses brought to their knees by hackers (Sony Corporation comes to mind).


Price of Sony Corp's stock before and after last year's cyber-attack [REF-3]

So if those giants experienced and suffered the negative consequences of security breaches, even though their high level of awareness regarding this matter, what could then happen to smaller organizations that aren't as aware and thus constantly overlook security concerns?

A good example is the case of Staysure, a UK based insurance company, which in 2013 suffered a massive data breach, compromising more than 93,000 customers' private credit card data.

In that attack, encrypted payment card details of customers who purchased insurance from them before May 2012 were stolen, along with CVV details and customer names and addresses. Credit card details were encrypted, but the CVV number was in the clear text (not a good thing).


"The company had no policy or procedures in place to review and update IT security systems, and twice failed to update database software which could have prevented this incident. This left security flaws in the system, some for as long as five years, which hackers ultimately exploited to gain access to customer information." [REF-4]

It's pretty clear that ignoring information security requirements can prove very costly for organizations; furthermore, the inherent risks and threats tend to snowball over time until a critical mass is reached and all hell breaks loose. Once this point has been reached, damage control and implementation of countermeasures may result in exceedingly complex, suffocating and expensive projects.

So What Does This All Have to do With SOA?

Well, let's begin by revisiting some of the principles of Service Orientation [REF-5]:

  • service reusability
  • service abstraction
  • service discoverability
  • service composability

All of the characteristics above are focused on positioning services as the primary means through which solution logic is represented and potentially accessed by an array of distinct consumers.

Furthermore, the more a service inventory grows, the more its services become subject to participate as part of compositions, orchestrations, BPMS implementations or even cross-inventory and cloud integration scenarios:


The landscape displayed by the image above poses a unique set of security-related challenges that won't be easily addressed and solved by simple means. Security-wise, accomplishing a robust service oriented architecture requires a lot of specialized skill and effort that has to be put forward from the design phases and continued through the implementation, testing, release and monitoring of services.

This is not an easy thing to pull off, especially since service developers and technical leads rarely possess enough specific security knowledge, nor do they have the sensitivity or experience to identify potential security threats.

Here's where the role of the SOA Architect(s) becomes fundamental. He or she who beholds this role, must be aware and keen of the importance that security policies, controls and mechanisms hold regarding the well-being and sustainability of the information systems being designed and the information that will constantly flow through them.

When facing a tall task like this one, the first big question that comes to mind is: where do I start?

An apparently obvious but very often overlooked element that we should always keep in mind before attempting to deploy any security mechanism, is the information security model known as CIA triad (sometimes referred to as AIC triad) [REF-6].

This model was developed to help people think about important aspects of IT security and basically states that information must always comply with three basic characteristics, which ultimately comprise the most crucial components of security management within an organization:

  • confidentiality
  • integrity
  • availability

Also very important would be to have a preconceived list of the most common security threats regarding SOA Architecture and integration projects. Some examples of these well-known liabilities are:

  • malicious intermediaries (sniffers, eavesdroppers, redirecting and tampering agents, etc.)
  • overlapping trust boundaries (especially when cross-inventory composition or cloud integration are involved)
  • insufficient authorization (usually provoked by weak authentication and/or authorization protocols)
  • DoS (Denial of Service) / DDoS (Distribute Denial of Service) Attacks
  • SQL Injection
  • cross-site scripting
  • etc.

All of this information provides us with an initial context that will be very helpful in keeping our SOA security approach focused and purposeful.

Now that we are headed in the right direction comes the tricky part. Both service oriented architecture and information security can have very broad scopes, which can encompass several layers of the organization depending on the project's size and impact. This has the potential to introduce unforeseen complexity in our SOA initiative; in fact, it is at this exact point where a lot of SOA development teams usually decide to swipe the security concerns under the rug and move forward with a very poor security approach or none at all. However, it doesn't have to be this way, because this is also the point where methodologies and design patterns come into play.

Methodologies can be very helpful from a management perspective, and there are indeed several that may provide more than enough insight into security requirements and the appropriate way to incorporate them into an IT-driven project. Since we are talking about SOA projects, and for this article's sake, let's adhere to a recommendation which has brought us nice results within a number of medium to large initiatives:

In this case, we are proposing a TOGAF 9.1 and COBIT 5 combination [REF-7] to ensure:

  1. Focus in the development of new architectures
  2. Governance for the new recommendations
  3. Adherence to international IT security standards because TOGAF is based on ISO-27002

According to the methodology, the first step would be to assess information security's current status within the applications, business processes and domains impacted by the SOA project. This would require a detailed review of established controls and objectives which encompasses: interviews with personnel involved, documents and policies previously published, architectural guidelines, established processes, and any documents related to information security.

After acknowledging the IT security domains proposed by ISO27002 standard, the organization's maturity level can be determined according to the information security control's status. An example of what we just said might look like this [REF-8]:

Domain Initial Development Defined Managed Measurable
Security Policy x
Organizing Information Security x
Human Resources Security x
Asset Management x
Access Control x
Cryptography x
Communications and Operations Management x
Information Systems Acquisition, Development and Maintenance x
Information Security Incident Management x
Business Continuity Management x
Compliance x

Table 1 – Current Maturity Level

It would be very valuable to have this assessment finished before starting with the service development and composition activities; however, this is not always a feasible scenario. Depending on the progress and status of the project, vulnerability and penetration tests performed by a specialized service provider could also be needed in order to determine security breaches which may already be there.

It has been stated that security requirements can be well identified, managed and followed up on with the methodology's help. However, there seems to still be something missing from a straight up technical standpoint.

We know from experience that the prospect of becoming obliged to face added security requirements can be daunting for architects and developers, more so because these requirements need to be considered in their designs and subsequent implementations, testing plans and deployment strategies.

This is seemingly an uncomfortable and very trying situation, but also one that can be thoroughly mitigated by the adoption of well-documented design patterns and strategies. Let's give an example of this:

As we know, design patterns are nothing more than proven and reusable solutions for common problems within a given context in software design [REF-9], so for our example, take a look at the following statements.

Solving a Common Design Problem:

Within service compositions, data is often required to pass through one or more intermediaries. Point-to-point security protocols, such as those frequently used at the transport-layer, may allow messages containing sensitive information to be intercepted and viewed by such intermediaries [REF-10].

This very common problem can be easily taken care of with the implementation of the "Data Confidentiality" [REF-11] design pattern, which makes good use of the WS-Security standard's encryption capability:


In the image above, we can appreciate that Data Confidentiality protects the message while in transit between services and while in the possession of unauthorized intermediaries [REF-12].

This is obviously not the only design pattern related to security in a SOA environment. In fact, there is a whole list of them which are even categorized according to the scenario they may apply to best:

  • Service Security Patterns
    • Exception Shielding
    • Message Screening
    • Service Perimeter Guard
    • Trusted Subsystem
  • Service Interaction Security Patterns
    • Brokered Authentication
    • Data Confidentiality
    • Data Origin Authentication
    • Direct Authentication
  • And so on…

All of the patterns we just mentioned pertain to a specific body of knowledge [REF-13] which we hold on a particularly high regard, because it has applied very adequately on many of the SOA-related tasks which have been assigned to us in recent years. However, take in account that this is not the only reference available for this matter; there is a lot of available knowledge out there, so our advice here would be to take a look around, find a body of knowledge that is a good fit for your initiative(s) and rely upon it as opposed to trying to reinvent the wheel.

What About Vendor Software and Pre-packaged Tools?

This is an important matter, because there are a lot of tools and products out there that can help with the implementation and management of specific security requirements. The critical thing to keep in mind here, is that although the software may be powerful, it will never be able to achieve the organization's goals on its own, without the knowledge, skills and purpose we've already talked about.

On the bright side, best-of-breed vendor software is often based on many of the design patterns we just identified. So let's take a look at some alternatives which may commonly help organizations address well-known security concerns:

  • Identity Management System (IdM) – Refers to an information system, or to a set of technologies that can be used for enterprise or cross-network identity management. [REF-14] Additional terms are used synonymously with "identity management system" including:
    • Access governance system
    • Identity and access management system
    • Entitlement management system
    • User provisioning system

    Some vendor examples of this kind of technology are: Oracle's OIM/OAM, IBM's ITIM / ITAM.

  • Policy Management Software – Centralizes and defines the specific policy sets that will be used and enforced, the SLAs and alerts the services commit to, and the access profile and capacities granted to the service consumers. Examples: Oracle WSM, IBM TSPM, Akana Policy Manager.
  • Enterprise Gateways – Enables enterprises to leverage their existing Identity and Access Management investments by extending authentication, authorization and risk policies to mobile, cloud and enterprise solutions that involve publishing services for consumption. They are commonly designed to protect services without the need to alter the underlying backend applications, thereby providing a non-obtrusive way of securing business scenarios. Examples: Oracle API Gateway (OAG), Mulesoft's Secure Data Gateway (SDG).
  • Enterprise Service Bus – Most ESB's come with a limited though useful set of security-related capabilities, most of which are included in support of WS-* standards. This capabilities may include:
    • HTTPS transport protocol support
    • Authentication support (HTTP basic, SAML, X.509 certs, LDAP, etc.)
    • Payload encryption
    • Parameter, data structure, header (SOAP/HTTP) and schema validation
    • Etc.

    It is important to be careful here, because a very common mistake is assuming that the limited security features of an ESB / application server will suffice to comply with an entire SOA initiative's information security requirements, which is certainly not true and depending on the size and scope of the integration project can lead to seriously dangerous pitfalls. Some examples of vendor-specific ESB products: Oracle Service Bus (OSB), IBM Message Broker.

So, what would an architecture that manages to leverage a combination of these tools look like?



Information security should be considered as an integral component of a SOA Architecture, critical both to any organization's well-being as well as to most integration project's overall success. When it comes to addressing security requirements, methodologies and design patterns are the ways to go in order to do it in a simple, effective, orderly and standardized fashion.

Vendor-software can be very helpful for solving specific security concerns, however no product is a panache, nor will it solve things on its own. Correctly harnessing the power of these tools requires a knowledgeable and purposeful approach.

The role of the SOA Architect is fundamental in the design and implementation of adequately secured SOA components.

Overlooking and/or neglecting information security requirements in SOA-driven initiatives may not have much of an impact in the short term, but can eventually prove disastrous for the organization.

So, the myth:

"When designing and implementing a SOA Architecture, information security and service protection are secondary concerns. Furthermore, security-oriented vendor software can more than hold its own by mindlessly applying a bunch of simple configurations such as HTTPs transport, basic authentication, etc."

Has been successfully demythified.

We certainly hope that this body of work has been interesting, useful and enjoyable. Let's meet again in our next installment!


[REF-1], [REF-2], [REF-3], [REF-4] [REF-7] [REF-8] Pérez Ramírez, Tabata Jessica, MTIA (2015), "Estrategia de Seguridad de TI para el Proyecto Evolución Operativa y Tecnológica", Thesis for obtaining the degrees of: "MAESTRO EN TECNOLOGÍAS DE INFORMACIÓN Y ADMINISTRACIÓN" (ITAM, Mexico City, Mexico) and "MASTÈR SPÉCIALISÉ MANAGER TÉLÉCOM" (TELECOM Ecole de Management / TELECOM SudParis, Evry, France).

[REF-5] Erl, Thomas, "SOA Concepts, Technology and Design", U.S., February 2009.



[REF-10] [REF-11] [REF-12] [REF-13] Erl, Thomas, "SOA Design Patterns", U.S., April 2013,