News
SOA Security Basics
Security for the service-oriented architecture (SOA) was described by Brian V. Cummings of
Tata Consultancy Services at the IBM SHARE conference this week.
In general, a company's data is always the security prize, and providing good security means managing a reasonable restriction to that data. The goal for security personnel is to balance security risks with the enablement of users, he said.
Cummings defined SOA according to IBM's definition, which is that SOA is an IT architectural style that supports service orientation. The trend is to use SOA as a way to integrate businesses using linked services. SOA involves publishing and discovering services. Applications are loosely coupled in an SOA and offered up as services, and, for that reason, the registry becomes an important concern for security in an SOA.
"We're starting to externalize those apps through the Registry [and] we're starting to publish information about how to use those apps [and] how to get information out of them," he said.
The general obscurity surrounding SOA doesn't ensure security anymore, he added.
"We used to be able to count on obscurity at some level for security. It wasn't a really reliable method, but it helped somewhat."
SOA throws additional confusion into the security world because of its new components, such as the enterprise service bus (ESB) and SOA registry. Other software components in an SOA that can entail security risks include the service broker and SOA supervisor, as well as adapters, infrastructure services and access abstraction capabilities.
Cummings emphasized the need to build security into SOA from the start.
"If you don't design security into your SOA from the beginning, you're going to have a horrible time trying to retrofit," he said. "It just won't work. And you're going to have an environment that's become more extensible, more open and ultimately more vulnerable to security risks."
SOA can be used to extend the enterprise, and that sometimes means letting customers into the system. For instance, retail companies such as Walmart are highly integrated with their suppliers.
SOA can also entail platform-to-platform interactions.
"Your job as a security person in providing security for your organization extends across platforms and may extend across enterprises," Cummings said. "If a supplier is accessing your data, if they are pulling data out your system for their own purposes, you have to make sure that they are treating that data with the same level of security that you do in your own systems."
Federating data access across organizations makes security even more difficult, he added. The idea is to federate identity management as a service, which aims to get everybody handled according to the same rules, policies and authentication requirements.
Currently, professional services firms are deeply involved in identity management projects right now, and it represents about 70 percent of Tata's professional services work in information management, Cummings said. Establishing a federation is about authenticating the user and building a security token that can be passed on to other applications that can sign the user on in the background. It's very simple in concept, but very difficult in the implementation, he added.
Another potential security vulnerability is the repository used in an SOA, which has executable program code. If somebody invokes a service, the repository says, "Yeah, you can execute that program." It grabs the code and starts executing, Cummings said. So if you can gain unauthorized access to the repository and manipulate it through a Trojan Horse or some other scheme, you can get executable program code that you might not be authorized to receive. That means that the attacker is getting access to data and can start modifying data, he added.
The ESB also presents problems from a security standpoint.
"Within an ESB, we are concerned with messaging security -- the authenticity of our messaging. Are they [the messages] coming from a reliable trusted source? Have they been modified? Are they intact? Have they been intercepted? I don't think you can assume any more that hackers haven't messed with your stuff."
An SOA supervisor is a key component in an SOA environment. Security concerns associated with the SOA supervisor include unauthorized modification of its capabilities or service disruption or degradation, which can happen through unauthorized modifications or manipulation of the code.
Overall, Cummings suggested that security monitoring is most important thing to do -- not just monitoring who has access, but lifecycle management monitoring too.
"The number one thing you can do with security is mind the store -- pay attention to what is going on in your environment ... In terms of value for the buck, monitoring is the best thing you can do," he said.
Monitoring essentially is a deterrent and can provide "forensic" evidence. However, there's a distinct difference between a good audit system and a forensic-capable one that can provide evidence that will stand up in court, he added.
Ultimately, Cummings said, you just have to have a very trusted relationship between the components of your SOA to ensure security.
About the Author
Kurt Mackie is senior news producer for 1105 Media's Converge360 group.