ebXML Security Overview

The good news from a security aspect is that ebXML was conceived and designed from the ground up with security in mind, in contrast to other protocols or standards where security was never considered at all at the design stage. The bad news is that the requirements and details in the specifications have to be implemented correctly, methodically, and with the most rigorous attention to detail if ebXML is indeed to meet its security requirements.

Of the four major areas of ebXML previously discussed, it is reasonable to conclude that the major risks are going to occur in two of them: message and registry services. Business processes and collaboration agreements are largely inert from a security point of view, in that although these areas do carry risks, such risks are eliminated by correctly protected message and registry services.

Another important point to make, especially to those coming to ebXML from an EDI background, is that ebXML is intended to be run on a public network—not on the private, leased-line arrangement typically found in EDI. This exposes ebXML deployments to a new form of attack: the “mountaineer” hacker, who will attempt to sabotage, or at least investigate, any publicly exposed service simply because it’s there. It’s important to bear in mind that because information is going over a public network, we must assume that it can be read and altered in transit unless specific measures have been taken to prevent this.