News Stay informed about the latest enterprise technology news and product updates.

Database logging and privileged access control

Ship captains have long started their days by initialing log entries. As a former senior security executive at a financial services firm with $500 billion in assets under management and over 20,000 employees, my day would start similarly. Each morning, I’d take responsibility for reviewing lists of accounts with privileged access to high-risk data.

Captain's LogbookWhat defines “privilege” in the world of security access is really the ability to “write” or alter a database. It also includes the ability to alter the audit trail documenting who has “write” access. “High-risk” data includes customer balances and transaction values, for example. This morning ritual of personally reviewing privileged access should be a part of a compliance program before you attempt database logging. Both are fundamental controls that everyone should have in place. Reports that document identities that have privileged access need to be designed and implemented. Operational procedures for review and follow-up on those reports need to be put in place.

Every morning, automated reports would appear in my inbox based on tightly defined criteria. I reviewed them, printed them, signed them, and had them filed. Auditors checked these randomly several times a year. Once a week, I reviewed similar reports signed by my subordinates, my VPs, reflecting use of emergency IDs, temporary IDs, vendor IDs, and privileged transactions. In other words, even before the Sarbanes-Oxley Act (SOX) required senior executives to take a more proactive role in security, I was starting my business day the same way, monitoring the list of those with the keys to the company’s crown jewels, so to speak.

My daily morning executive-level review of high-risk access should tell you a few things:

  1. Even at an enormous firm, the number of privileged IDs with access to high-risk data should be short enough for a busy executive to personally review
  2. It is both feasible and reasonable for senior executives to personally review this information and record that they have done so
  3. Anyone can expect this kind of review may be taking place in any major organization handling high-risk data, although it is not as universal as it should be

There are no specific standards or frameworks telling you how to create these reports or what to include. Don’t waste your time on a fool’s errand searching for detailed technical guidelines. COBIT and SOX frameworks indicate only that this type of review in general should be defined by each organization and put into place. Whether it is daily, weekly, or monthly, and what exactly it includes, will be up to each organization, compliance officer and CISO, depending on its businesses and risks.

Here are some general considerations for specifying these reports:

  1. The number of individuals with write access to this data should be zero. If someone needs regular access to unlock or fix operational issues, you should know those people by name very well and they should number no more than three.
  2. Revoke privileges after resolution. Anyone who was granted write access to resolve an issue should have had the privilege revoked after an issue was resolved. Thus, the only names showing up on your report would and should be individuals continuing to resolve issues which cross the timeframe of the running of the report, which should be timed around 3a.m. every day.
  3. Turn off audit switches in identities. Don’t forget to include identities in your review that have the ability to turn “audit” on and off for each database or account. Unless you include this privilege, individuals can turn “audit” off prior to access and turn it on again immediately afterwards. You will have no idea of any change. Which means:
  4. Include all changes to “audit” status in the prior 24 hours in the privileged transaction report: Was audit turned on or off?
  5. Review emergency access for IDs. Did anyone check out an emergency ID with high privileges? Was it checked back in? Does it correspond to a change management ticket reflecting a valid reason for the use of the emergency ID?

Please feel free to comment or write to with any questions on these types of controls.

Reblog this post [with Zemanta]

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.