Audit

Managing e-discovery and compliance: What would Eliot Spitzer do?

E-discovery - or electronic discovery - has many technical aspects. Questions of available tools, case law, regulations and scope are critical. One of the most important and often overlooked elements, however, is managing e-discovery and compliance.

As a senior manager at Putnam Investments, bizarre coincidences and convergence of fate with the soon-to-be famous marked my tenure. Few chapters embodied all these elements as thoroughly as the following e-discovery anecdote, for reasons that are obvious now, but were less so in 2003.

On Monday, Nov. 3, 2003, Putnam Investments fired its CEO, Larry Lasser, following a probe into market timing. Eliot Spitzer, New York’s attorney general, and William Galvin, the Massachusetts state regulator, had brought significant pressure to bear regarding market timing charges.

Spitzer, then known best as U.S. Attorney for the Southern District of New York, issued a subpoena two weeks later for Putnam documents. In the process, he indicated that criminal charges were being considered. From that day onward, senior managers at Putnam had a critical new IT project: managing e-discovery and compliance.

Unlike other IT projects, which include a feasibility analysis, budgeting and decision-making process prior to kickoff, e-discovery really starts from subpoena receipt. Spitzer’s reputation for a “take-no-prisoners” approach to investigations and prosecutions, not atypical for situations many firms face during litigation, had implications for IT.

From the moment a subpoena is received, senior technology managers should be called in. From IT’s viewpoint, e-discovery then becomes a new IT project on the list that requires reprioritization of existing resources.

The first step in managing e-discovery is to assign an IT project manager. Given that this will be a high-risk project, a seasoned individual is required. That means either hiring a backfill candidate for an existing project, or cancellation or delay of exiting work. E-discovery is usually a good example of a project that has no real, measurable ROI. This is a handy data point for all those IT projects that you, the IT manager, have to argue for each year during the budgeting process. That process demands an ROI even for operating system, database and other major software upgrades, which are also projects that evade calculating an ROI.

The next step in managing e-discovery is stakeholder and requirements identification. While vendor or tool selection usually comes later in the process, for a specialized project like e-discovery, identifying requirements should be fast-tracked from Day One. Firms and experts specializing in e-discovery are crucial for this type of project, which typically will be handled only once in a company’s lifetime – you’re lucky. Your staff is likely to lack experience with e-discovery, a reality best addressed by selecting an advisor immediately after selecting a project manager.

In the next post, I will address how to adapt standard project management techniques to the e-discovery project.

Questions? Write to editor@searchcompliance.com or reply to @SecuritySources on Twitter.

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.

How do you align an IT risk assessment with COBIT controls?

[One of our readers, compliance officer Ramon de Bruijn, wrote to the editors of SearchCompliance.com at editor@searchcompliance.com last month looking for some advice. Specifically, he asked "What is the best way to implement a risk assessment in an IT department that aligns COBIT controls with risks?" In her first post for IT Compliance Advisor, Sarah Cortes, PMP, CISA, provides an answer to his question. -Ed.]

Implementing a risk assessment that will align the COBIT control framework with risks is a valuable undertaking and a smart way to approach the challenge. If approached with a working knowledge of COBIT, it should take no longer than any other risk assessment approach.

In the long run, it will likely shorten the overall cycle:

Risk assessment -> Recommendation -> Solution implementation -> Audit

This is because COBIT can provide a thorough checklist of potential risk areas that might otherwise be missed, requiring multiple passes or potential wasted effort implementing solutions to lower-priority risks, while ignoring those with a higher priority.

One thing to keep in mind is that COBIT controls are not just “in an IT department.” They include controls for business interruption and other business problems that have traditionally fallen to IT to deal with, rightly or wrongly.

The first step is to obtain a copy of COBIT controls, which you can do from ISACA.org or other sources on the Web.

The second step is to provide education, if necessary. Make sure key individuals in your organization have heard of COBIT and understand it is an internationally accepted standard. No need to worry anyone will know it better than you. Even auditors and CISA professionals can achieve only a moderate level of memorization of all aspects of COBIT. COBIT changes all the time. Technology in some areas moves beyond it in areas. In general, COBIT is too far-reaching for even the most seasoned IT professional to avoid re-reading and referring to it frequently when working with it.

After obtaining a copy and getting buy-in, the third step is to put it away. You need to ask yourself and others where the known risks to IT and business lie. This bottom-up approach is critical to avoiding “over-COBITING,” a common affliction.

Once you have carefully listened to IT professionals and others with respect to control weaknesses and the risks that actually “keep them up at night,’ you are ready to pull out your COBIT framework again. Review a fuller set of risks with those same individuals. See if that uncovers risks they may have missed the first time. This checkpoint is one benefit of COBIT.

Finally, you should document your risk assessment and note areas listed in COBIT that individuals in your organization did not consider worthy of note. Each COBIT area should be covered. If the risk included in COBIT is not prioritized in the risk assessment, a specific reason should be noted, along with the individual who decided to assume or dismiss that risk. This will come in handy later, trust me.

If you follow these steps, you will be further ahead than 99% of professionals and IT departments in your shoes. Good luck, and happy documentation!

Sarah Cortes is a senior technology manager with extensive experience in all aspects of delivering information technology systems and services to Fortune 500 firms in the financial services industry, as well as biotechnology, media and higher education. Sarah Cortes has managed numerous major Code Red business and system interruptions, including the 9/11 failover of trading, accounting and other critical business systems during Marsh McLennan’s WTC data center collapse. You can learn more her work at InmanTechnologyIT.