Making use of distributed computing, such as service-oriented architecture (SOA) and integrated Web application services, means greater complexity and security design challenges for organizations and IT managers.
Open standards play a big role in developing and making better use of efficient and effective security measures as computing becomes more distributed, new threats emerge and organized Internet crime grows, as Part 1 of this series discusses.
While integral to the process of developing the methods and means to defend and protect information and telecommunications systems, open standards are not the “be all” and “do all” of the matter, however. Even more critical is how these standards are used by management along with security policies, procedures and associated efforts to educate employees, promote usage among business partners and monitor their networks for threats.
Part 2 continues to look at the security challenges posed by SOA, how development of some key security standards is progressing, and the approaches vendors and end users are taking as SOA and distributed computing continues to evolve and grow.
Simpler, Yet More Difficult
“Service-oriented architecture is basically a concept that allows applications to be created by metadata and standard data structure protocols such as XML (Extensible Markup Language). The promise of SOA is that an application can be created using a variety of modular components running on the same server or many distributed servers,” CipherOptics vice president of product management Scott Palmquist told TechNewsWorld.
SOA security issues are the same as those associated with the use of any distributed system, Palmquist noted. “How are confidentiality, integrity and availability assured? Confidentiality in the rightful access of data, [for example] the right data and the right user — application or human; integrity in that the data has not been wrongfully manipulated by an application or human; and availability in that the data and systems are indeed available when required.”
While SOA simplifies security in some respects, it compounds security issues in others, Palmquist explained. “SOA helps to simplify some of the security decision since common protocols such as XML for data structures, IP for communications and a common operating system — pick your favorite — are being used in the underlying infrastructure, hence fewer items to watch over.
“SOA compounds the security decision because many moving parts, as in modular programs, come together as the final application. IT and security staffs need to closely coordinate at the beginning of an SOA project in order to determine the appropriate mitigation of confidentiality, integrity and availability,” he said.
Open Security Standards
Open standards for distributed systems security services, such as SAML (Security Assertion Markup Language), XACML (Extensible Access Control Markup Language) and WS-Security, are being worked out by members of OASIS (Organization for the Advancement of Structured Information Standards).
Implementing new SOA and other distributed systems standards does not have to be a trade-off between insecurity and cost — and employing them will increase security, according to BEA Systems’ Hal Lockhart, co-chair of the OASIS technical advisory board and security services technical committees.
“Flexibility and reuse will require the use of the newer and more flexible standards: SAML for federated identity, XACML for fine-grained access control, WS-Security for sophisticated SOA applications,” Lockhart told TechNewsWorld. “Experience so far has been that the organizational, political and process difficulties in introducing these far outweigh the technical issues.”
Lockhart reported that SAML now includes a range of new profiles based on real world experiences. “I expect this process to continue. There are a large number of successful deployments around the world. Some governments are doing deployments with very large user bases — [in the] tens of millions.”
Work on the WS-Security standard is essentially complete, he added. “Customers can expect that if they do the relatively simple things that are common, they will not have much problem. If their use of WS-Security is complex or unusual, they may experience some interoperability problems. However, alternate models for identity federation are also emerging, including WS-Federation and Open-ID.”
Hashing Out New Standards
OASIS technical committee members are writing an extensive set of examples for WS-Security Policy, Lockhart continued. “It is fairly complex to understand and there is not a lot of field experience around using anything like it. Most people will get a copy of a simple policy provided by their vendor and make minor changes to it.”
The OASIS Digital Signature Services Extended (DSS-X) technical committee is carrying on with the development of a standard XML framework for managing the provisioning and allocation of identity information and system resources within and between organizations.
The original committee was disbanded because the members could not come to unanimous agreement on one of the intellectual property rights (IPR) modes mandated by OASIS rules by the April 15 deadline. The disagreement was a matter of principle and company policy, and not based on concerns about any specific technology or patent. The two or three members who dropped out claimed no patents or intellectual property rights related to the work of the DSS technical committee, Lockhart recounted.
“I think these standards are in good shape. Once we have a few more years of operational experience, we may need to come back and make changes. The challenge now is getting interoperable products out and tested and deploying real application environments. As I mentioned, the general experience has been that the non-technical aspects are more difficult than the technology,” Lockhart commented.
“While there are some hurdles obstructing development of the variety of security standards being developed for SOA, there are also workarounds for incorporating them into an SOA as well as tremendous overall industry progress in advancing standards and protocols,” added Sandy Carter, vice president of SOA & WebSphere strategy, channels and marketing at IBM.
Interoperability Issues
While Web services are often touted as the ideal solution to application interoperability and are indeed effective at integrating applications regardless of platform, vendor and programming language, they are not immune to interoperability problems, Carter noted.
“Most interoperability issues arise not from the base Web services specification which is quite mature and stable, but rather from the various [Web service specifications] and Web services extensions such as WS-Security. As these standards evolve, vendors must choose which draft specifications to support, and developers occasionally need to cope with incompatibility issues between different specifications,” Carter told TechNewsWorld.
More broadly speaking, it’s not SOA technology that creates security issues, but how organizations employ SOA in pursuit of the economic and competitive advantages that it offers “without accepting the need to write code that’s quite specific about what it permits — and no more,” Peter Coffee, director of platform research at Salesforce.com, told TechNewsWorld.
“Traditionally, code is written and debugged in terms of ‘do this correctly,’ and is considered ready to deploy when it meets that affirmative requirement; Robust and secure SOA requires that code be written to ‘do only these things,’ and do them correctly, which is a much more demanding discipline of design and testing.”
Modularity Minded
SOA can have significant benefits even if used only as a means of achieving modular design, Coffee continued. “An SOA approach implies construction and publication of a set of service interfaces, which other parts of an application can continue to use as long as those interface contracts are maintained — even if the internal mechanisms of a service are changed.
“This is a more loosely coupled, much less brittle approach than code-based interaction among internal data structures; it’s much like the advantages of object-oriented design, but even more so,” Coffee explained.
The modularity inherent in a well-designed and constructed SOA creates no new security issues as no new function is exposed to other systems or outside parties, according to Coffee. “What’s more exciting, though, in terms of return on investment through fast time-to-market and reusability of code, is the creation of libraries of services that are discoverable by other applications — a ‘marketplace’ SOA.”
Reusable libraries of code and open accessibility pose security risks, however. A code clearinghouse within an SOA “may expose capabilities through service interfaces to customers and supply-chain partners. When this happens, an intended provision of service can turn out to be a pathway of privilege escalation and attack,” Coffee noted.
It’s All in the Doing
Complying with any one security standard or the total number of standards supported alone is not sufficient to evaluate the effectiveness of SOA or Web application services platforms, Coffee pointed out.
“It’s important to understand that support for a security standard can not be equated with good security. In many cases, a security standard merely defines a framework that lets various schemes interoperate with each other — it doesn’t mean that any particular scheme is actually doing a good job.
“A fully compliant WS-Security implementation can still use weak crypto, or suffer from sloppy key administration, or store data in unencrypted repositories with inadequate physical security. Being secure is a state of practice, not just a list of supported standards that allow for doing things either well or badly.”
Loading ...
