During the past 15 years, software development has largely centered on the object-oriented paradigm, where data and code are bundled together into little blobs, inseparable in the object. The data often takes the form of attributes, and based on those attributes, the object takes action. An "object" is an independent mechanism, using its own data and code to perform a function.
Service-oriented architectures are a different paradigm for software development. With SOA, the code is distributed in different places on different machines, and the data moves between these systems so that it can operate. Author Hao He has a great analogy to help differentiate between the SOA and object-oriented views of the world: your CD player.*
Suppose you have a CD with some great tunes on it. To listen to music, you can use a variety of different CD players, like a big Hi-Fi stereo or a little portable CD player. There is only data on the CD, though, not code (For the most part, anyways. Some music companies have put code on a CD. Let's not forget that unfortunate Sony rootkit situation back in 2005). With multiple CD players in your life, you move the disc's data around, using CD players' services to listen to songs.
That's the idea of SOA. Data moves between different systems that provide a service. Applications are built out of collections of these services. If CDs acted like the object-oriented model, each CD would have the ability to play itself. You'd simply touch the CD, and music would spill out. That might sound like a cool feature, but it would increase the complexity of a CD, and you wouldn't be able to use a fancy Hi-Fi stereo that might give better sound than a self-playing disc.
With SOA, applications are typically stitched together using several programs. These programs, located on different machines, each provide a service. The data between the programs shoots back and forth, often in XML. The applications are built out of these little services, with a bunch of different vendors often providing the services. A single service, such as the map functionality of your favorite search engine, might then be a service that a bunch of different applications use. A fancy new touch-screen cell phone, a talking car GPS location finder and picnic-planning Web site might all be applications built on this underlying map service.
The user sees the application, but it is not always clear which services support that application, nor is it clear which organizations are providing those services.
So, getting back to your question, what does this mean to malware writers? The bad guys can now hunt for vulnerabilities in a variety of different services that support an application. If attackers find a flaw, they can exploit it. An attacker can corrupt or steal service data, contaminating all applications that rely on the compromised service. By hitting one vulnerable service, the bad guys can also distribute infections to all users of an application.
In the end, the SOA world provides fertile hunting ground for vulnerabilities, and attackers who exploit those vulnerabilities can spread malware and cause some serious damage. Watch for this attack vector to expand in the future.
*Our younger readers may not know what a compact disc (CD) is. Let me elaborate – in "ancient" times, music was distributed on physical media, such as wax, vinyl, magnetic tape and, ultimately, on plastic discs known as CDs. You may have seen these shiny metallic-looking plastic discs on your grandparents' shelf and wondered what they were.
This was first published in July 2007