log files

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.

What 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 editor@searchcompliance.com with any questions on these types of controls.

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:

• malware detection and remediation
• vulnerability scanning
• intrusion detection services (IDSes)

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.