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

Compliance fundamentals: Database logging, privileged access control

On April 10, 2009, 10,868 Social Security numbers at Penn State Erie, The Behrend College, were compromised by a detected intrusion. Last October’s data breach of 17 million records at T-Mobile, Deutsche Telekom ranks amongst the largest breaches in history, occurring almost two years after the infamous TJX breach. Given the nearly daily reports of data breaches, ensuring data privacy and preventing identity theft is at the top of the compliance project list for security and IT professionals and businesses everywhere.

These incidents have shifted a great deal of focus onto three types of IT initiatives:

Two of the most fundamental types of detection and control strategies, however, are often overlooked:

  • Database logging and its partner control,
  • Privileged access.

COBIT and most security frameworks consider these controls sine qua non. Unfortunately, neither fundamental is as sexy as IDS or hackers, and thus receive scant press attention.

Database logging is the practice of creating a record of direct access to high-risk data in high-risk databases. It excludes access through user interfaces, so it accurately filters out client or user access. Instead, it records all identities that directly access the data. This would include database administrators, possibly system administrators and likely anyone else who has been granted write privileges into your database.

Are you aware of everyone in your organization who has write access to your high-risk data in your high-risk databases? Do you doubt anyone could possibly have direct access to the banking deposit, withdrawal transactions or trading buys and sells in your firm’s Fortune 500 database?

Let me assure you, they do.

Every firm has individuals to whom this access has been granted. No firm could function without them. Senior business officials often react with outrage and tough talk about firing anyone granting such access to their IT staff. But the reality is that these senior officials should look more closely at both themselves and any budgeting choices that may have denied database upgrades that could have precluded the need for such access. Many institutions have not adequately invested in their applications and database upgrades. As a result, some hapless DBA is often left tasked with daily, high-risk manual database “fixes” to keep business running. The DBA is then blamed if problems crops up as a result.

There are many reasons firms can and do grant write access to IT staff. The primary reasons include:

  1. Legacy databases that “freeze” daily and have to be manually unlocked.
  2. New transaction types that aren’t adequately handled by applications, resulting in inaccurate data that require a manual “fix.”
  3. Access temporarily granted under an emergency change control and never revoked.

Monitoring privileged access is a fundamental compliance practice. Such monitoring that includes a daily automated report personally reviewed by the Information Security Officer (ISO) and signed off with his or her initials should be in your firm’s repertoire. Yes, a daily signature. This report alone will likely raise many useful questions. Once monitoring access is addressed, the daily database logging report should similarly be placed in front of the ISO’s daily for personal review and sign off.

In my next post, I’ll give specifics on how to build these reports so they actually capture the violation information you need. Nothing worse than the false security of a violation report that does not actually capture the required information. Your auditors will know the difference. So should you.

Reblog this post [with Zemanta]

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.