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.
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.
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.
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:
With many customers/projects, we have experienced large debates, misconceptions and even debacles related to security or the lack of thereof. So:
"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]:
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:
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:
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:
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]:
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:
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:
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, http://www.soapatterns.org/