Home > Security

Computerworld - If you're an information security manager, you have to apply security smarts to your information security model — sensible security that's in line with your organization's business, applicable legislation and available resources.

I put my company's security somewhere between that of universities and the Pentagon. We're not a bank, health care organization, government contractor or e-commerce company. But we do have quite a bit of intellectual property and thousands of employees whose personal data needs to be protected. And, of course, since we're a publicly traded company, we must comply with Sarbanes-Oxley. All in all, I consider myself reasonable when it comes to enforcing security. I don't want to make it hard to do business, but if there's a breach, I am the one who will be called on the carpet.

Any particular day might find me debating, arguing and reasoning with various IT and business units on information security matters. A recent situation was fairly typical.

We use SAP for a variety of critical business processes, including financial reporting. I recently learned that the SAP team wanted to create some generic system accounts so that SAP's support technicians could have access to our financial systems for troubleshooting purposes. The term "generic system accounts" coupled with the phrase "access to our financial systems" didn't sit well with me. A mile-long string of e-mails between me and the SAP team ensued.

When our engineers run into a problem they can't fix, they log a trouble ticket with SAP's online support system. The SAP technician who is assigned then contacts one of our SAP engineers to gain access to our SAP infrastructure. This works well between the hours of 8 a.m. and 5 p.m., but not at 2 a.m.

So our SAP team wants to include in the trouble ticket a generic user ID and password. The problem is that these accounts would have full administrative privileges for our SAP financials. What's more, the user ID and password would be sent out as unencrypted plain text. And it's not within my scope to vouch for the integrity and business processes of SAP.

Horns of a Dilemma

This was a predicament. If I denied the request, we might not be able to respond to all SAP problems in a timely manner. If I allowed it, there would be a risk that our financial data could be modified, which is a Sarbanes-Oxley issue.

In the spirit of being reasonable, I came up with a compromise. The generic accounts will have to be read-only. Sarbanes-Oxley controls require any changes to our financial systems to be approved by a manager, and I figured that there was no reason for an SAP technician to make a change to our environment without first consulting with our managers, no matter what the time of night. I also reasoned that any issue that was sufficiently critical to warrant a change would also warrant our on-call engineers going to the office or logging on remotely to handle the situation.

I'm not entirely satisfied with this compromise. However, it will serve while I ask the SAP team to look into a tool from SAP called Virsa Firefighter. It allows IT administrators to perform emergency activities outside their roles under a controlled and auditable environment. With Firefighter, we could control and assign a temporary ID and track and monitor activity by logging every keystroke the user typed.

The existence of this tool tells me that the folks at SAP see the same potential for problems in these situations that I do.

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.

Join in
To join in the discussions about security, go to computerworld.com/blogs/security

Read more about Security in Computerworld's Security Topic Center.