Rechercher Contactez-nous

Suivez-nous sur Twitter

Freely subscribe to our NEWSLETTER

Opinion

Securing Data beyond PCI in a SOA environment: Best Practices for Advanced Data Protection

December 2008 by Ulf Mattsson, CTO, Protegrity Corporation

New business models rely on open networks with multiple access points to conduct business in real time, driving down costs and speeding responses to revenue generating opportunities. That’s the good news. The bad news is that this modern business architecture is often riddled with vulnerabilities that can easily be exploited to gain unauthorized access to sensitive information.

To make life even more exciting, you can’t rely on traditional best practices like establishing strong boundaries around critical applications to secure SOAs or you’ll be defeating the features and flexibility that SOA brings to the enterprise.

Another attractive feature of SOAs is the use of standardized contracts and contract retrieval methods, which make life much easier for developers, authorized users and malicious hackers. Using a collection of freely available contract descriptions a hacker can target weakly authenticated or high-value services, easily penetrate an improperly secured SOA, eavesdrop on SOAP message traffic and see information that may be private. In addition, it is relatively easy to intercept a SOAP message in an unsecured SOA and reroute it or transform its content for purposes of mischief or fraud.

Layers of security — including integrated key management, identity management and policy-based enforcement as well as encryption are essential for a truly secure SOA. This article reviews a practical implementation of a transparent, risk-based management approach that can be used to lock down sensitive data utilizing policy driven encryption and key management for data-at-rest and in-transit across enterprise systems.

Evolving Data Threats

And although the IT community is interested in SOA because of its promise of efficiency and improved IT management, security problems are causing many to proceed slowly, or not at all, with actual SOA implementations. Major systems have typically been designed to protect against unauthorized use, intrusion, and viruses. Today, however, the issue has taken on even more seriousness in the wake of hacking-for-hire attacks and global viruses.

SOA’s inherent security problems stem from the ways in which the SOA replaces traditional security parameters with new, open standards. The security problem is twofold in that not only are the new standards completely open-no one owns them but they were also developed without security in mind. Web services were developed over a period of years by industry consensus as a way to, among other things, enable the creation of reusable code, simplify development, and streamline system integration. Specifically, XML, SOAP, WSDL, and UDDI are open standards that enable the transmission and description of data and procedure calls between systems. However, none of these open standards contain any inherent security aspects of their own. If left alone, they are completely non-secure. In fact, web services were designed to be able to move data efficiently through firewalls.

In the traditional security model, the system’s security apparatus, such as a firewall or virtual private network (VPN), screens out unauthorized (human) users. However, an SOA demands that the architecture be more flexible and open to access from multiple systems to facilitate reuse and composition of new applications. If the systems are exposed as services but a new security mechanism is not enforced, a hacker could configure a machine to impersonate a vendor’s system and make erroneous or fraudulent service calls.

While SOA security concerns abound, virtually all IT managers are realizing that they must soon identify and implement security solutions for SOAs because their developers are exposing applications as web services using the new generation of development tools. A pressing need exists, as noted in [1], to solve the security risks in the SOA.
Approaches to SOA security

It is critical to have a good understanding of the data flow in order to select the optimal protection approach at different points in the enterprise. By properly understanding the dataflow we can avoid quick fixes and point solutions and instead implement a protection strategy encompassing protection all the way from the data sources.

Careful analysis of use cases and the associated threats and attack vectors can provide a good starting point in this area. A continuous protection is an approach that safeguards information by cryptographic protection or other field level protection from point-of-creation to point-of deletion to keep sensitive data or data fields locked down across applications, databases, and files - including ETL data loading tools, FTP processes and EDI data transfers.

Security policy refers to the issues that arise around authentication and authorization. In general terms, any SOA security discussion is going to have a component of security policy. Message-level security is a group of technology issues that relate to the integrity of the actual web service that is traveling across the network. Message-level security is the necessary other half of security policy. Not only is this good business, it’s also becoming part of the law in such areas as privacy and regulatory compliance. Message-level security, which involves such technological functions as encryption, keys, certificates, and signatures tackles the challenges of securing the specific web service interaction from meddling and eavesdropping. The goal of SOA security in the context of governance is to provide assurance that the SOA can deliver verifiable data that will stand the test of an audit.

If you want your SOA to have robust security, where you are confident that the users of your web service are properly authenticated and that the information flowing back and forth between web service and their invoking applications is not read by unauthorized people, then you will almost certainly need to apply the powerful tool of encryption to your SOA security solution. Below is a description of how end-to-end data oriented encryption provides end-to-end field confidentiality across the enterprise data-flow, including the SOA layers, while WSS (Web Services Security), TLS and proxy only provide message-oriented or point-to-point confidentiality as noted in [1].

A Holistic Layered Approach to Security

We cannot rely on applications to do all the work for us or throw money at the data security problem and hope it will go away. A holistic layered approach to security is far more powerful than the fragmented practices present at too many companies. Think of your network as a municipal transit system – the system is not just about the station platforms; the tracks, trains, switches and passengers are equally critical components. Many companies approach security as if they are trying to protect the station platforms, and by focusing on this single detail they lose sight of the importance of securing the flow of information. It is critical to take time from managing the crisis of the moment to look at the bigger picture. One size doesn’t fit all in security so assess the data flow and risk environment within your company and devise a comprehensive plan to manage information security that dovetails with business needs. A data protection-driven holistic plan is the only way to truly secure data – it allows you to think strategically, act deliberately and get the absolute best return on your data security investment. Protecting the enterprise data flow is discussed in [2] and [4] is looking at security beyond PCI. Approaches to automatically shut down the local access to sensitive data in case the local system is stolen, cloned or compromised in some other way, as discussed in [15].

o Native database security mechanisms

Native database security mechanisms are very limited in defending successful data attacks. Authorized but malicious transactions can make a database useless by impairing its integrity and availability. Suites of the proposed solution may be deployed throughout a network, and their alarms managed, correlated, and acted on by remote or local subscribing security services, thus helping to address issues of decentralized management.

o Minimizing changes to applications and databases

Give careful consideration to the performance impact of implementing a data encryption solution. First, enterprises must adopt an approach to encrypting sensitive fields only. Such a solution allows the enforcement module to be installed with the file level, at the database table-space level, or at column level to meet different operations needs. It allows the encrypt/decrypt of data as the database process reads or writes to its database files. Decryption can usually be done in an application-transparent way with minimum impact to the operational environment.

o Encrypting data if a binary format is not desirable

Application code and database schemas are sensitive to changes in data type and data length. One formatting approach is called meta-complete data storage is a method of securely storing data so that the data contains information about the data and/or the encryption of the data, systems and methods of providing secure access to real world data through data transformations, and systems and methods of managing security parameters for data described in [16] addresses these demands with methods and systems of meta-complete data, i.e., "data that knows about itself." Such data may be transported throughout the enterprise and beyond without additional "baggage," allowing for quick and secure transport of data and requiring minimal modifications of existing data infrastructure. One approach to protect this information in application memory and in transit is to use masking or partially encrypt sensitive fields to hide the not needed bytes from exposure [7].

Any system that’s specifically built to support the effortless flow of data will also be eminently hackable — that’s just the nature of the security beast. SOA provides real benefits and creates real security threats. The article above is just an overview of some issues to consider when developing a plan to secure your SOA environment — it is not intended to be a comprehensive guide to locking down the world’s SOAs.
When developing your own risk-based holistic SOA security plan, make sure to factor in the demands of whatever regulations and standards affect your industry. Depending on how the enterprise uses SOA, it may also be vital to review security plans with partners, outsourcers, remote offices and anyone who has authorized access to the system — how have they handled security on their ends?

Additionally, it is important to develop a clear policy that details SOA governance — management, maintenance and accountability — because SOA security cannot be purchased off-the-shelf, it needs to be built and carefully maintained. Like all security, SOA defense is an unending work in progress.

References and Suggested Reading

[1] Security in a Loosely Coupled SOA Environment, by Eric Pulier and Hugh Taylor,
http://www.developer.com/design/article.php/10925_3605836_2.

[2] Protecting the enterprise data flow,

http://www.ulfmattsson.com

[3] Multi-layer system for privacy enforcement and monitoring of suspicious data access behaviour, February, 2006, United States Patent Application 20060259950

[4] Data Security for PCI and Beyond,

http://papers.ssrn.com/sol3/papers.cfm?abstract_id=974957

[5] NIST

(http://csrc.nist.gov/CryptoToolkit/modes/ In Special Publication 800-38A

[6]

http://usa.visa.com/merchants/risk_management/cisp_merchants.html

[7] Data type preserving encryption, November 2000, United States Patent 7,418,098

[8] A Real-time Intrusion Prevention System for Commercial Enterprise Databases,

http://ssrn.com/abstract=482282 .

[9] Payment Card Data - Know Your Defence Options,

http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1126002

[10] A partial encryption concept, http://ssrn.com/abstract=571422, and