COBIT

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.

Keep your change management process simple

This is a guest post by Laurence Anker, engagement manager, technology risk management, at Jefferson Wells International Inc.

The only constant in information technology today is change. The changes are broad and rapid across the domains of hardware, system software, application software, databases and data, telecom, networks, to name just a few. How well you manage and control change can be the difference between success and failure. In fact, the change management processes present significant and potentially costly risks to organizations. In a recessionary economy where decreases in IT spending and investment, combined with personnel reductions, are a fixture in the landscape, an efficient and effective mechanism surrounding your change management is more important than ever.

The fact that change management is a critical control does not mean that it needs to be complex. To the contrary, simple, well-designed controls are much more effective, and more likely to be performed consistently, than a complex, overengineered control. Regardless of whether your shop follows ISO, COBIT, ITIL or other guidance to control your change management process, it boils down to initiation, assessment, decision, execution and tracking and reporting. Let’s look at an example.

The problem

The client did not have a consistent change management process in place for a major program that utilized 150 resources. With multiple paths to request changes, both formal and informal, the organization was unable to maintain a comprehensive list of all requested changes. In turn, this impacted how their resources were utilizing their time and prioritizing their assignments. To further exacerbate the problem, key individuals supported the production environment and were hijacked for production issues, significantly impeding progress and schedules.

The symptoms

The organization had a rapidly growing backlog of requests, assigned projects were running late, resources were frustrated by the conflicting directions they were receiving, and the business community was unsatisfied with the level of service that IT was delivering.

The solution

To staunch the bleeding, the organization undertook a significant shift by establishing a Change Control Board (CCB) to oversee the change request process. While everyone was still allowed to initiate a request, it had to flow through the CCB for approval. The CCB would evaluate the cost, benefit and time estimates, as well as assess the risk to the organization (both by moving forward on the project and rejecting the project), and the potential impact to other projects that are already in process. The decision to approve, reject or postpone the request was now an informed decision based upon sound business logic. Approved projects would be given a budget and assigned the resources to move forward following the organization’s Project Life Cycle through build, test and promotion. To log, track, monitor and report the status of requests, the organization implemented Rational’s ClearQuest.

I will leave you with three key points to think about when instituting a change management process. First, the procedures, tools and formality will need to be “right-sized” for the size and culture of the organization. Second, tools are facilitators, not the solution. Organizations that expect to acquire and implement a tool or a Change Management Database as the silver bullet quickly learn that without the process and procedures that surround the tool, they are no better off at controlling and managing the change within the organization. And third, people are still the keystone to success. Communication and collaboration amongst the constituents throughout the organization are critical to making sure the right people have the right information at the right time to be able to make the right decision.

Laurence Anker has more than 30 years of experience supporting organizations’ IT requirements, addressing audit, control and security objectives, risk identification and mitigation, and business requirements definition. Anker led the insurance industry practice for Ernst & Young’s New York Information Systems Assurance and Advisory Services Group, was a senior manager at KPMG, and served as the EDP audit manager of North American operations for Swiss Reinsurance.

Prepare for compliance auditors: Encourage compliance with IT policies

This post is the second in a two-part series. The first post, “review policies and standards,” addressed the first step in preparing for the auditors. -Ed.

When we last left our hero and heroine, the lone IT operations manager, he or she was about to get a visit from the compliance auditors. Sound familiar? Only, unlike in that big upcoming squash or tennis match, you’re not sure which rule book they will be using to score the games. Unsure against what standard your IT operation would be judged, I advised:

Step 1: Get ahold of your company’s IT policies and standards.

Step 2: Reality check. Do they represent TODAY’s state of your IT operation?

For example, I pointed to your access control policy. Does it say, I asked, “Terminate access rights for all users within 24 hours of employment termination?” Is that really happening, 365 days a year, I queried? And pointed out seven common ways the operation can miss that 24-hour window.

But here’s the good news: If your IT policy said, “Terminate access rights for all users within one week (instead of 24 hours) of employment termination,” you’d get an A on the audit.

So, take Step 3: Revise your IT policies and standards to reflect TODAY’s reality. Don’t let staff companywide get in the habit of tolerating noncompliance with your policies because they are too ambitious in relation to your current compliance level. While you may be trying to set a higher standard to aspire to, there are better ways to do that. Instead, you are just setting yourself up for a BAD AUDIT.

“Sarah, how can you recommend a one-week standard for access termination?” I can just hear you say. The point is, of course I recommend you tighten up your operation and get that one week down to 24 to 48 hours. Just, don’t put it in your policies and standards until it is THERE. If you insist on doing this, it will only get you an “F” on your audit. And there’s nothing in COBIT dictating the time frame. You can determine your own time frame based on a series of factors. I’ll go over those another time, but they give you more leeway than you’d think. If you’ve followed these steps, take Step 4: Sleep easier at night.

If you have any questions about this strategy, let me know in the comments.

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.

IT compliance policies, standards and technical directives

“A day at the beach can turn into a hurricane fast.”

That’s the tagline Sarah Cortes chose for Inman TechnologyIT, her Cambridge, Massachusetts-based consultancy. What’s the context? Disaster recovery, security and preparation for IT compliance audits. I met Cortes at a meeting of the New England Tech Professionals LinkedIn group last night in Waltham, Massachusetts. She provided an overview of IT policies, standards and technical directives to a group of seasoned IT professionals before leading a discussion of how these frameworks relate to actual preparation.

Her presentation is embedded below.

I posted the following updates to @ITCompliance on Twitter while she spoke and engaged the audience.

• Cortes presenting on a true “alphabet soup” of standards/orgs: ISO/ISEC 27000, ITIL, NIST, PMBOK, TOGAF, CMMI for dev, SEI’s CMM & COBIT .
• Important note from Cortes: Many of the “standards” (like COBIT) are frameworks. Adopting them gives auditors a reference point.
• Excellent discussion here by IT pros of the difference between stating ISO/COBIT compliance & genuine quality in IT policy & processes.
• Discussion turning to ISACA technical directives & more granular IT processes & recommendations. Key reference: http://isaca.org
• Wrapping up; Cortes of Inman Tech moderated a useful discussion of compliance standards & audit concerns. http://twitpic.com/1prtm

Aside from the opportunity to meet a dozen enterprise IT professionals, the core of the SearchCompliance.com audience, I took away a number of insights that the tweets above highlight.

First, the number of standards and frameworks relevant to compliance is staggering. Compliance officers and CIOs have long since become well aware of the issue. When Cortes talked about ISO/ISEC 27000, her tongue-in-cheek comment was that 27000 referred to the number of standards it comprises.

Secondly, in Cortes’ eyes there’s a distinction between being compliant with a given framework, like COBIT or ITIL, and running a quality IT department that is prepared for a disaster and has consistently protected critical financial, health and intellectual property data. Demonstrated adherence to these frameworks, especially in documentation of internal processes and policies, will help when the compliance auditors come calling.

The latter part of the presentation ran through dozens of recommendations for given IT policies offered from the Information Systems Audit and Control Association (ISACA). As Cortes noted, the frameworks for security don’t offer specific advice for a given area. ISACA directives do. As I noted in the tweet, more information is available at http://isaca.org.

The final part of the night featured a wide-ranging discussion about life on the “front lines” of the IT department by engineers and administrators who had to mitigate data breaches, prepare for compliance audits and develop procedures to ensure compliance across multiple computing environments. Clearly, these tasks aren’t easy. If you’d like to tell us your story, please write to  editor at searchcompliance.com.

Thanks again to Cortes for allowing us to publish her presentation and to Dennis Comeau for the invitation to the meeting.

Windows compliance: Resources on data retention and data protection

As any CIO or compliance officer knows, compliance affects multiple parts of IT infrastructure and the organization as a whole. Strategy, security, storage, networking, records keeping and human resources are all part of the mix. As an editor at SearchCompliance.com, that means I scan the RSS feeds of all of TechTarget’s sites for relevant content, along with those of other compliance news sites from around the Web. Starting today, I’ll be posting a roundup of the resources I think you’ll find useful at this blog.

Recent research into the buying habits of you, our readers, showed that half of our midmarket CIOs are running Windows shops. That information comes as no shock to anyone. Most of the world lives on a Windows desktop, despite the recent inroads made by Mac OS X and Linux. There’s no question that heterogeneous computing environments are a concern for many a sysadmin. That said, Windows compliance is the crucial topic of the day.

So here’s a question for you: Are there unique issues that arise out of Windows compliance?

I’m certain that the answer is “yes” but I’d like to hear more about what system administrators, CCOs and CIOs are experiencing in their everyday working lives. Let me know what you think in the comments or at ahoward@techtarget.com.

In the meantime, here’s that roundup:

If you’re looking for a comprehensive resource, try The Windows Manager’s Guide to IT Compliance e-book. Chapter 1, for instance, offers best practices on establishing an event log audit trail, maintaining the event log, encrypting email or files and keeping an inventory of stored data. You can also download each of the three chapters separately:

• Keeping up with IT compliance
• Managing email server compliance
• Controlling access for file server compliance

Rebecca Herold has been a prolific contributor on the topic of Windows compliance as well. She’s an adjunct professor for the Norwich University Master of Science in Information Assurance program and is well into writing her 11th book. Her articles can be found at PrivacyGuidance.com, Realtime-ITcompliance.com and, of course, at SearchWinIT.com. (You’ll note she’s in our blogroll, down to the right.)

Earlier this month, Herold explained how to keep Windows shops in compliance with data protection laws. Protecting personally identifiable information is a key aspect of compliance in 2009, given new regulations coming down the (Mass) pike. Even if the Massachusetts data protection and encryption law deadline has been extended, it needs to be on your radar.

In past articles, Herold has also explored how to meet data retention compliance in a Windows environment. In her view, Windows managers must take an active role in learning data retention policies and creating procedures to support them.

Similarly, in her tip on meeting compliance requirements in a SharePoint Server environment, Rebecca suggests that before deploying SharePoint Server, IT managers should examine the compliance implications of using the collaboration tool in their Windows environment .

Herold also has written about how the service desk can help Windows shops meet SOX compliance objectives by using IT governance frameworks like COBIT and Microsoft Operations Framework.

Finally, if you’re still procrastinating on completing your IT compliance documentation, do it now.