May 18, 2009, 5:28 PM — Readers who, like me, live and breathe security will cringe when they read this sentence: My company plans to build a front-end Web service for our payroll and accounting system.
Internal financial systems are the most sensitive part of most companies' networks. Putting them in the direct line of fire of the menaces on the Internet is more than just potentially dangerous. It could be catastrophic. We're talking about data regulated by things like Sarbanes-Oxley and SB 1386. For a security guy like me, it's unthinkable that we would do anything to make such data more, rather than less, breachable.
But you'll really cringe when you hear what the project team had in mind before I was consulted. Their original idea was to simply install a couple of Web servers in our Internet DMZ and open up communication directly between them and our financial systems. Yikes! And would you believe that the application vendor recommends this approach? This is why security managers have their work cut out for them.
Trouble Ticket
At issue: Payroll and accounting are going to be Web-accessible.
Action plan: This project can't be stopped, but it can be modified smartly.
Putting the kibosh on this project was out of the question. Given the financial climate, this is a fast-track, high-profile effort seen as a necessity to streamline our ability to gather records from our customers and send payment information back and forth. Even delaying it wasn't an option.
There's more. Each customer using the Web front end will need log-in credentials, and their accounts will need to be added somewhere. The first idea was to simply add them to our internal user directory. But we have over a million customers!
Fortunately, since being briefed on this project, I've been able to educate everyone about what's at stake, from the project team on up to the CIO. What's happened since is a good example of the compromises that most security managers have to live with.
The Middle Ground
There's no way I could get the external parts of the accounting system separated from the rest of it, so a connection from the DMZ into our family jewels is unavoidable. But I have been able to get the team to re-architect the design so that more layers will be involved. The way it stands now, the front-end Web servers will talk to an interim application server instead of directly connecting to the core payroll application. That's basically the middle ground compared to the amount of separation I'd really like to see, but it is what the project can realistically accommodate.
Now we just have to figure out how to authenticate all those customers. We've nixed the idea of adding them to our internal directory. In that battle, I had plenty of support from our account management department, which didn't want the job of creating all those users. And in this case, our CIO was very understanding of the problems involved in mixing employees and nonemployees in the same user database. So we will be creating a new user directory exclusively for customers. There aren't many user directory products that can support 1 million-plus users, and very few of them are actively doing that in large companies today. We are evaluating some products that have large-scale capability, but the choices are limited.
Related Links
Other Columns by J.F. Rice:
* A timely idea for streamlining project approvals
* The economy takes a toll on security
* Layoffs put IT security on the back burner
We dodged a pretty big bullet in this project. In the rush to roll out customer automation, security was overlooked, and so was what's really good for the company, in my opinion. But reasoning prevailed, and we are on a much better path now. With ever more services being brought out to the Internet, the line between what's in the private space and what's published out to the world has become blurred. I think this means that the job of the security manager is only going to get harder over time.
This week's journal is written by a real security manager, "J.F. Rice," whose name and employer have been disguised for obvious reasons. Contact him at jf.rice@engineer.com.
Join in
To join in the discussions about security, go to computerworld.com/blogs/security
