US Customs becomes latest security issue

09.01.2006
One of my duties as the information security manager is to approve firewall change requests. With 17 firewalls throughout the world, reviewing such requests can take a lot of my time. I don't mind that, though, since that process makes me aware of some of the business functions within the company. For example, it was through the change-request process that I was made aware that we are required to report to the U.S. Customs Service information about the shipment of goods.

As I've mentioned, we manufacture hardware used in the manufacturing of semiconductors. We're required to notify the government just about every time we ship equipment to a foreign country.

We use SAP software to process our sales orders. It includes a U.S. Customs Management module to facilitate the printing of the required documents, and a more automated procedure, the Automated Export System (AES), for sending transit declarations electronically. We use AES, and that's the reason for this most recent change request.

Currently, we are using a dial-up connection to a U.S. Customs server hosted by a third party, since the Customs Service doesn't have the resources to host this reporting infrastructure. I learned about all of this when one day I reviewed a change request to open up our firewall to allow one of our SAP servers to establish a virtual private network (VPN) connection to an external server; the SAP server is located on our internal, protected network. I asked why one of our critical servers needed to make an outbound connection, and the engineer making the request explained that the Customs Service is discontinuing support of the dial- up method for transferring shipping information. Instead, we will need to use a VPN tunnel to transfer the required information.

After several rounds of e-mail messages with the engineer, I called a short meeting so that I could fully understand the requirement. (I do this often, whenever the e-mail thread for a particular topic amounts to a small novel.) I was thinking that if the only purpose of the VPN is to transfer information regarding shipments, then why couldn't we make a connection just once per day? I also wanted to know a little more about this VPN client.

I got my answers, and they made me uncomfortable. As it turns out, we will need to make a connection every half hour for 15 minutes. In addition, there is return traffic from the U.S. Customs server, which transmits acknowledgment reports back to us.

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.

Looking ahead

I've now been in my current position for almost six months. I've got a pretty good handle on our network infrastructure and the various points of contact within the business units. One of my resolutions for the new year is to conduct a complete firewall-access control list audit in order to fully understand what kinds of holes we have in our environment. It's definitely not an easy task, and finding the time to do this may be very challenging for me. I might hire a contractor for a few weeks to either conduct the audit for me or at least provide me with a meaningful picture of our firewall infrastructure.

What do you think?

This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com, or join the discussion in our forum at computerworld.com/forums.