XML and Web Services Security: How Can We Protect XML-based B2B Systems?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Introduction
Security is one of the biggest concerns for anyone who wants to do business on the Internet. How can we protect XML documents that are exchanged with our business partners from eavesdropping? How can we make sure that received XML documents have not been changed since they were created? The designers of XML and Web services are working hard to provide appropriate protections to address security concerns. There is a series of XML security standards that can constitute basic building blocks for secure XML solutions. Emerging specifications of Web services security use these building blocks to address end-to-end security of Web services. In this article, I explain these security standards and try to put them into a wider picture.
Information Security In General
Before getting into each technology, however, I want to draw your attention to the general landscape of information security. It is often said that information security is not an event, but a process (I encourage you to read Secrets and Lies: Digital Security in a Networked World by Bruce Schnier, (Wiley, 2000,ISBN 0-471-25311-1). There is no single point in time when you can say "The system has been secured, and I can forget about it from now on." Attackers are creative: They come up with new forms of attack every day, some of which have never been considered by the security community.
Security Is Process
By saying "security is process," I mean that the following steps should be continuously repeated:
Assess risk. First, you must identify resources (or information assets) to be protected. The resource could be IT infrastructure resources such as servers and networks, or application programs and business processes such as online order entry systems, or even the brand image of your company. Then, identify what kind of threats are possible to these resources, and assess the potential damage caused by these threats.
Create policy. After the risk assessment is done, you have to define your policy. There is no way to guarantee a 100% secure system. You have to decide which risks to mitigate by implementing security countermeasures, which risks to accept, and which risks should be transferred to somebody else (for example, having insurance coverage).
Implement countermeasures. After your security policy is in place, implementing countermeasures should be relatively straightforward. Pick appropriate technologies and procedures, and implement them.
Repeat. Go back to Step 1, and repeat the process all over again.
A Countermeasure Is Process
Security countermeasures should also be defined as a process. In this case, the process consists of attack prevention, attack detection, and reaction to the detected attack. Many security technologies, including the ones that I describe in the rest of this article, focus on preventive measures such as firewalls, encryption, and authentication. However, it is sometimes more effective and more efficient to implement appropriate detection and reaction procedures against attacks (instead of completely preventing the attacks). In the real world, your home probably does not have an unbreakable steel front door but you may have burglar alarms wired to the nearest police station. These are detection and reaction measures, not prevention measures. So a good security countermeasure is a process, that is, a procedure consisting of a balanced mix of prevention, detection, and reaction measures.
The technologies described in the rest of this article are building blocks that can be used for implementing preventive countermeasures for XML and Web services. Keep in mind that these technologies should be used in conjunction with appropriate logging, auditing, and recovery procedures.