Successful AS2 communications require a balancing act between two conflicting demands: your infrastructure has to be open enough to talk with your trading partners, but secure enough to keep out intruders and repel attacks. The familiar firewall is the tool of choice to resolve this, but it still requires that you tell your trading partner which ports are open. This could expose your network to security lapses on their end. Fortunately, there are several options available to minimize or eliminate this risk.
An obvious solution is to restrict incoming traffic only to the known IP addresses of your trading partners. While this is a good start, some other problems present themselves. Smaller companies may not have static IP addresses, and even larger ones sometimes have to change addresses due to network maintenance or server migrations. Adjusting the firewall to these changes requires the intervention of network security staff, who may not always be able to operate on your timetable. Furthermore, it still leaves you vulnerable to malicious traffic that is actually originating from your trading partner’s network, or someone else who has spoofed their address.
A more thorough solution is to obscure what ports are open on your firewall even to your trading partners. This can be done by adding specialized screening software, like a proxy server, to a machine outside the firewall in the so-called ‘Demilitarized Zone’, or DMZ. This software could be set to listen to the port your trading partners are sending to and forward it to the different address and ports open on your firewall while keeping them anonymous.
This set up can also protect against malicious traffic that’s actually coming from your partner by filtering the connections to make sure they’re legitimate. For example, it could check not just the originating IP, but restrict all non-AS2 traffic by looking for AS2 header information. If that information is missing or doesn’t match the filter criteria, the connection is refused. Another advantage of such an application is that you can usually monitor activity and make changes in the filtering criteria without having to involve your IT staff.
To protect against spoofing, consider using two-way SSL authentication for your transactions. In this format, the server (receiver) not only verifies its identity to the client (sender), but the client has to prove its identity to the server. This can be combined with the steps above, but be aware that two-way SSL is not as widely supported yet and some of your trading partners might not be able to handle it.
Finally, a word of caution: it can be tempting to multiply your network security with redundant filters and firewalls-within-firewalls, but this can be dangerous. At some point you’ll hit a plateau where security improvement becomes negligible and the smallest changes can cause massive headaches for both your trading partners and your IT department. It’s better to consider the situation of your company and the requirements of your partners and work from there than to drown your b2b communications in overly complex and inflexible security protocols.