March 1, 2004
(Computerworld)
We're just finishing up the integration of an acquisition's poorly secured IT infrastructure into our information systems. We've disabled almost all external access to its network, except for two services.
The first is a virtual private network tunnel to allow employees to continue accessing the acquired firm's software development environment. The other service is the firm's file transfer protocol server, which we'll keep until we can migrate its content to our own FTP server. By the end of the week, my team and I hope to have all critical information and services migrated so we can shut down the other company's offices.
Now I can turn my attention back to our ongoing Sarbanes-Oxley Act compliance audit. Meeting this law's financial accounting and reporting requirements is the No. 1 priority of our executive staff -- and that's a great enforcement mechanism. Nobody wants to be responsible for the audit's failure, so people usually bend over backward to accommodate my requests once I say the magic words: "This is for the upcoming Sarbanes-Oxley audit."
I've completed a security standards document and am now assigning ownership of the 90 or so standards it contains to the appropriate functional units in the company.
For example, I developed several standards for data backup. Now I must ensure that the data center manager, who is responsible for our backup infrastructure, can prove that we comply with those standards.
The compliance-checking process is too time-consuming for me to accomplish alone, so I plan to assign compliance efforts to others in my department. There are many areas in which we don't meet requirements, but that's OK because the standards document can help us expedite compliance.
I've started regular meetings with our IT auditor, who has been concentrating on identifying what he calls "key controls." Sarbanes-Oxley requires us to create a "credible body of evidence" that attests to what we say we're doing. That evidence includes statements and documentation demonstrating that we're in compliance with our identified controls.
For example, if you process credit card information as we do and your policy states that you store credit card data in an encrypted field in an Oracle database, showing the auditor a copy of that policy isn't enough. You might need to run a script on the Oracle database that prints out the database fields with associated security controls. If you run this script on a daily or weekly basis and can show that the database administrator is regularly reviewing the reports, that's an acceptable control.
In a large company like ours that does most of its business by e-commerce, the number and complexity of needed controls is overwhelming. Most of them focus on financial matters. Since our Oracle database lives on a Unix server on the corporate network, which is administered by the IT group, the scope of the audit can be extensive. The reason for that is simple: What would be the use of protecting the Oracle database if we didn't also enforce strong authentication for administrative access to the Unix server on which the database is running?
We're supposed to identify the key controls sometime within the next few weeks. That's when the real work will start. Until then, I'll continue shaping my standards document.
Wireless Bypass
I've had to deal with several other issues over the past couple of weeks, including another in my never-ending series of problems with our wireless network. During a recent audit of the wireless infrastructure, I discovered that an employee has a company-provisioned access point at home. He also has the access point set to broadcast the Service Set Identification code, and he doesn't have encryption enabled. That wouldn't be a big deal except for the fact that he also has a Digital Subscriber Line connection that links directly into our corporate network.
Normally, home employees must use a VPN to connect to the corporate LAN, but this worker bypassed that requirement with his DSL link. As a result, anyone in his neighborhood with a wireless LAN card could use his access point to gain access to our network without any type of authentication whatsoever.
Fortunately, when he attached the access point to the corporate network, it automatically registered itself with our WLAN management system. We use Airwave Management Platform from AirWave Wireless Inc. in San Mateo, Calif. The tool lets us centrally manage all access points, so we shut his down immediately and notified him via e-mail. I do have one political worry: The user is a close associate of a company executive, so I'm sure I'll hear about this.
Elsewhere on the wireless front, I'm trying to find a way to provide a hot spot in our executive business center, which is visited by customers who need Internet access. The business need is justified, but we can't assume that customers will have any support for our security protocols.
We need to create a secure WLAN that gives customers Internet access but prevents unauthorized users from consuming our bandwidth. We'll probably use a system that incorporates a Web enabled sign-on and rotate the log-on credentials regularly.
About a year ago, we had looked at products from ReefEdge Networks Inc. in Fort Lee, N.J., to address a similar issue. I plan to take another look at its offerings, along with a few other products.
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: QuickLink a1590
To find a complete archive of our Security Manager's Journals, go online to
computerworld.com/secjournal.