In a recent survey by IDG, over 70% of respondents highlighted concern over security issues as the main reason for not rolling out web services. Mark O'Neill, chief technology officer of web services security specialist Vordel, admits that ensuring the integrity of web services data remains a considerable challenge.
Firewalls, intrusion detection systems, and secure socket layer (SSL), he says, provide security at the network and transport layers. However, web services also demand new security technologies for the three A's of access management: authentication, authorisation, and accounting – 'who you are', 'what you are allowed to access', and 'what you've done'.
The concepts of intrusion and harmful packets are familiar to anyone who has had to deal with network security. But an attack on publicly available web services could be more dangerous than, for example, an attack on a web site, because intruders are connecting straight into the interface, warns O'Neill: "They don't have to go behind anything to get to it." One such attack could be a 'ping of death' – an unexpectedly large packet.
As yet, few companies are exposing their web services to the public, which obviously lessens the overall security risk. "In the early days people assumed all web services would be public, but it wasn't realistic – it's not how business works," says O'Neill. "So most are behind a firewall or in a virtual private network… and are being used in a closed user group."
As a result, most current web services security products cater to demand for authentication, rather than preventing attacks. But because many web services are still in an early stage of implementation even trusted users can make potentially harmful mistakes, such as sending a malformed message or one which is difficult to process.
Similarly, a malicious individual gaining unauthorised access can become a "nightmare scenario", says O'Neill. "If someone gets through your access control, a valid message will do more damage because it will work and get a response," says O'Neill. Therefore, he says, web services authentication tools must control both who connects to the service and what they send.
Yet the fact that web services is still a new way of building applications means that there is a unique opportunity to build security into the technology from the start. This way, says O'Neill, developers can hopefully avoid the patchwork approach to software security employed in the current generation of applications.
Although some of the lessons learnt in securing traditional software remain valid, web services present new challenges. "In the past, to authenticate a sender you didn't have to look into the message," says O'Neill. "With web services, it gets more complicated. XML can be sent over any protocol so you have to encrypt the data itself – the underlying transport is considered untrustworthy."
But with this challenge comes additional benefits. Whereas a firewall just takes a snapshot of a transaction, embedded signatures allow for "transactional security" in web services. Messages can be tracked from sender to recipient, making for a clear audit trail that can satisfy stringent legislation such as the Sarbanes-Oxley Act.
"With web services, host-based endpoint security is built in from the ground up as design points," says O'Neill. Present security technologies such as SSL and HTTP-Auth are still relevant, he says, but with a well-managed move towards the service-oriented architecture (SOA), a loosely coupled future could also be a more secure future.