Troubling implications

I didn't like the sound of this. If what was needed was solely a once-per-day outbound connection for 15 minutes, we could put some server restrictions in place in order to prevent packets initiated from the external site from reaching our internal infrastructure. But the need to make connections throughout the day compromises our ability to restrict packet activity. Just because a VPN tunnel is encrypted doesn't mean that malicious activity can't be conducted within it. The VPN ensures only that the traffic from one point to another is encrypted and not changed. Furthermore, I can't vouch for the integrity of the third-party service provider's systems or any of its employees.

And there are other problems. Not only is our SAP server environment an integral part of our business, but these servers are included in our Sarbanes-Oxley audits. If we fail a SarbOx audit because we're not securing external connections, I could get in a lot of trouble. What's more, the external service provider is responsible for the policy that will be applied to the VPN client. We simply install the client, point it at the service provider's firewall and provide a user ID and password. We will have no idea what the configuration of the service provider's firewall is or any details regarding the policy that will be applied to our VPN connection.

I asked the engineer responsible for this initiative to get a hold of the service provider and ask for details on the configuration it will be using. I'm also contemplating having the SAP server in question placed on what I like to call a "dirty subnet." This would allow us to put a firewall between the SAP system that is used solely for U.S. Customs reporting and our critical SAP environment.

Fortunately, we have some time before the Customs Service officially terminates the dial-up connection, so we will be able to fully review the configuration and attempt to evaluate the service provider that the Customs Service has outsourced this infrastructure to.