A common statement an auditor hears is, “our IT department is mature; we have everything we need for an IT Audit.”

A common thought an auditor thinks is, “yeah, right.”

So which of these statements is more accurate? More importantly, which one increases or decreases risk?

Without creating a laundry list, let’s take a look from the auditors’ perspective by breaking down the components of compliance into five main domains:

• Logical Access
• Physical Access
• Operations
• Change Management
• System Development

In my last article, I introduced the concept of developing a “Culture of Compliance”  — something to keep in mind as we delve deeper into each section.

Logical Access

Logical access is the way people (employees, contractors, partners) gain access to the systems that process information. An auditor looks for clearly defined and followed processes.

In my experience, this is where IT needs to work with the whole organization on the core of logical access: user provisioning (my fellow contributor Ioana Bazavan Justus is authoring a great series on Identity Management).

Once defined, logical access must be certified with established tools or a manual effort. The ideal approach is a preventive control that flags segregation of duty access across application systems. Few organizations use this today, but I strongly urge the consideration and adoption of this capability. The more common approach is a “detective” control that works, but requires a significant budget and hours to complete. To be clear, “complete” means re-testing!

Access reviews need to include identification of administrative accounts (including who has access to these accounts) and validation if the level of access is actually required. I recommend not taking anyone’s word for this, test and document it. It is important to have a documented methodology of monitoring administrative accounts and logs to prove it.

Physical Access

Physical access covers access to buildings, data centers and other sensitive areas. The appropriate policies and reviews need to cover the entire process for new hire, transfers, terminations, contractors, vendors, etc. To be effective, this often requires cooperation with Human Resources (HR), Legal, and Compliance and possibly some business units.

Think like an auditor: once access to the data center is documented, reviewed (quarterly) and signed, the auditor(s) will generally pick a terminated IT staff member to audit.

This is where the “culture of compliance” comes in – rather than hoping the process works, it pays to establish an environment where employees take the right actions as a course of action. In this case, it means they log all entry by contractors, vendors and other guests and validate this list against an electronic record of entrance.

A quick sign of success is when even escorted coworkers are asked to sign a log file for entrance into the Data Center.

Operations

Operations are the lifeblood of the organization.

Many organizations have a facilities department separate from IT, which requires cooperation between teams. This is also a reason to have a single person drive the compliance and audit process – to streamline these connections and provide a measure of continuity.

Make sure vendor contracts are in order for the facilities/physical equipment such as fire suppression, heating/cooling and other support systems. When the culture understands the importance of protecting this information, each department will notify others of changes and work together to ensure updates and “coverage.”

Good auditors look to assess if the team has a handle on inventory or manages by incomplete spreadsheets with a hope of accuracy. This is an area where the use of automated discovery tools pays dividends.

Much ground to be covered here, and it must include the details of who, what, where and when of Job Scheduling. Changes to job scheduling is  a process, whether it is for changing frequencies, adding, deleting, and even emergency procedures.

Another area of focus: ensure backup processes are documented, reviewed,  and followed.

Think like an auditor: provide logging details, be ready to explain the job failures and how they are handled! If an auditor asks about failures and the response is “we have none,” it triggers (or should) a lot more questions.

Change Management

In general the key to change management/development is authorizations.

This starts from the top with project approval forums all the way down to and including authorization to put code into production. Each phase, QA, testing, and CM should define requirements, necessary documentations and authorizations. Where appropriate several levels of approvals is required.

Change control is not limited to applications.

Include network configuration (port address) changes and changes to OS configurations need to follow  the change control process. Emergency changes often fall through the cracks of standard procedures. Establish a process that allows flexibility to get the task completed but make sure you have post documentation, and verbal approvals documented after the fact.

System Development

Time to really consider, implement and/or follow SDLC documentation (need a starting point, check out:  http://www.shellmethod.com/refs/SDLC.pdf). Pay close attention to the two primary parties, the end user and developer parties and their responsibilities.

A simple question to start the process: does the current process, what people are actually doing, match what is documented?

In many cases – maybe even most – the answer is either no, or worse, “documentation, we don’t have documentation!” Larger, more mature organizations tend to have a dedicated quality assurance (QA) department that often engages in auditing or assessing the system development process.

In general, workflow applications are great but avoid the concept of “assumed authorizations”. The workflow better meet the documented levels of authorization.

Some people may sneer at the concept of “culture of compliance,” but their personal experiences don’t diminish the importance of engaging people in every aspect of the process – to the point where it is ingrained in the very culture of the organization. The reality is that compliance becomes a process, and the organizations that are focused on engaging their people are able to meet compliance goals without imposing (too many) additional burdens.

Quite simply, this is establishing, nurturing and supporting a culture of compliance.

By considering these five areas, it is possible to provide some structure and ask good, probing questions that lead to conversations that ultimately inform the decisions and actions of others. Change the way people think when developing and making system changes and 85% of your challenges will gradually melt away.

This is simple to test:

1 – Have a manager ask an SE to grant him admin rights, completed with a bit of a story. If the result is a change in access on the fly, there is an immediate opportunity to educate. In my experience, the education might be better as a discussion with questions, as opposed to scolding and “gotcha.” Connecting the person to the consequences of their actions – in their words – goes much further.

2- Ask the customer if they do post implementation testing. Does it meet the initial scope of the project? Are “lessons-learned” documented and kept on file.

3 – Ask the Data Center manager when the next scheduled fire suppressant equipment inspection is due. Not needed instantly but they should be able to produce a copy of the contract and last maintenance records.

What do you think?

Share your challenges, successes or questions about how to effectively drive your audit and compliance program in the comments below.

The concept of the audit, to some, may feel relatively new and immature. However, financial statements have been audited since the 1800s and regulated IT Audits got a footing in the 1970s. The challenge in making sense of audits is in the approach: are you driven by compliance and audits, or are you driving the audits and compliance?

In my experience, compliance and audits are more journey – and less road trip. The challenge in preparing for this journey is the murky starting point, winding roads and changing conditions that must be successfully navigated. And when finished, the reward is taking another lap.

Developing a “Culture of Compliance”

Day in and day out those who work in finance adhere to basic principles that over time have simply become habit. These basic principles are in part derived from the understanding that they will be audited against their actions. We, as IT experts, tend to have much more of a cowboy approach to getting work accomplished.  Now that IT is being held accountable we need to instill the same ideology of daily work ethics that is second nature in finance departments.

This concept of cultural development is awkward at best when considered in bits and bytes. While IT staff are experts in their fields, they often have difficulty in understanding why perceived red tape (commonly experienced as additional process to get code into production). For many, it just doesn’t make sense and feels more like an obstacle than a useful control.

Building the culture of compliance takes time, dedication, education, and influences some interesting debates. Yet the journey is rewarding and the results proof positive of the investment. Over the course of the next year, I’ll share my experiences learned over the last two decades to ease the journey for everyone.

Sell the concept, reap the benefits

Management responsibility – wait for it –  “must be driven from the top down.“ It’s quoted a lot, and for good reason. And I agree. The outcome of IT assessments, sometimes in combination with finance audits, has a direct impact on the bottom line.

Who would you rather do business with: a company who has process deficiencies and stated exceptions or one that passes the litmus test of standardized IT auditing?

Positive results are an endorsement that the organization is operating efficiently and more importantly securely. This endorsement should be used by your sales and marketing departments at every opportunity.

Building Support

Step one: find the right internal sponsor.  This sponsor should be the liaison to any audit firm partner. While IT management is needed to explain details of process, systems, and applications, they should not be on point. Often the best bet is a leader in finance. Building on years of experience, savvy finance management can simply save money.

Of course there are exceptions; mature IT organizations can fulfill this role with the understanding that it is critical to update senior finance management throughout any audit.

Should IT audit and compliance be managed internally?

This question needs to be asked regardless of the size of the organization. It is common practice to hire external audit firms (opposing) to prepare your organization for an IT audit. Independent assessments can help identify process deficiencies, help with documentation and, more importantly, ensure a smooth audit when it counts.

Quite simply, if you need to bring an organization into “compliance” within a predefined time frame external help may be your only option. If the decision (or only choice) is to manage this internally, then dedicated staff is essential. This team needs the expertise in systems, applications, security and perhaps more importantly the ability to communicate and educate others on why IT auditing is so important. We’ll explore this more in the future (and quite frankly, I’ve seen Michael in action, and he is the master of this  — and he makes it easy for others to do it, too).

One of the best tangible outcomes of this whole process is detailed documentation. Interesting how  there is never time to develop or update documentation; now the excuses are kicked and a valid reason exists. These policies, standards, and other documents are the foundation of the IT department, the keys to success.

What’s in it for me?

Develop this “Culture of Compliance” within the IT department and witness creative solutions being developed with the base principles of security and with forethought into what auditors really want, Who, What, When, and How!

Sound off

How have you developed a culture of compliance in your organization? Or has your compliance car skidded off the road along the path? Engage in the discussion in the comments and we’ll work on getting there together.

Identity Management (IDM), or Identity and Access Management (IAM), is a suite of products that work together (more or less cohesively) to manage users and their access/passwords across the enterprise. Most identity management product suites consist of three or sometimes four parts:

-        Role manager

-        Identity manager

-        Access manager

-        Audit manager (sometimes)

Although most product vendors have adopted similar terminology for their components, there is no true standard naming convention nor is there a requirement that vendors use the same name for their corresponding products. My experience is largely with Sun Microsystems’ identity management suite, but this product is not necessarily the right choice for everyone. I will try to remain as neutral as I can, but I ask your understanding if my terminology and examples tend towards what Sun uses.

The Bumpy Road to Consolidation

Have you ever wondered why there are so many components? Why not just make one product that does it all?

The answer lies in the history of identity management.

In the beginning…

… each of the components were stand-alone products created by niche start-ups.

Over time, the larger companies (the usual big players such as Sun, Oracle, IBM, etc.) took an interest in providing their own identity management solutions, and thus began buying out the start-ups and their products to build integrated suites. For example, Sun purchased Waveset as their identity manager and Vaau as their role manager. Oracle purchased Thor (identity manager), Oblix (access manager), and Bridgestream (role manager).

Does consolidation matter?

Consolidation of the marketplace has advantages and disadvantages.

On the plus side is one-stop-shop convenience, and one throat to choke when things go wrong. On the down side, you are stuck with what your vendor of choice offers – maybe their identity manager component is brilliant, but their role manager module just doesn’t meet your requirements.

Given the choice between a hot-and-cold suite or a lukewarm suite (i.e., one whose components are all just average), which do you select? You may also face pressure from management to stick with the vendor partner of choice – if you happen to be an IBM shop, management may be reticent to allow the introduction of HP’s identity management suite, even if it better meets your requirements.

We’ll address these and other product selection issues next December in the last article of this series, which focuses on requirements and product selection (if you need to know sooner, drop me a note and we can discuss). I bring it up now, however, because it’s important to think about what’s really important to your specific implementation as you go, so that when you get to requirements, you know how to prioritize and choose. Please keep an open mind – what you think is very important today may turn out to be less important as you dig deeper – and document your thoughts as you go!

Another big consideration of consolidation is internal interoperability. Just because all of the components are now sold by one vendor doesn’t mean that they are really integrated. It takes time for a company to truly fold in one of these modules. For example, Sun purchased Vaau as their role manager product about a year ago, yet there are still some interesting gaps in the ability of role manager and identity manager to interact.

The biggest consolidation is still pending: Oracle and Sun Microsystems are in process of merging (or trying to, anyway). Both companies currently offer a full-fledged identity management suite. If the merger does go through, what will happen to those products, and how will existing customers be impacted? I would be surprised if they kept both suites, but who knows?

The good news is that while the current round of consolidation is sorting itself out, there is plenty of foundational work to be done to prepare for the selection and implementation – especially with the process and data cleanups.

However, before we even embark on the detailed cleanups and process improvements necessary for success in Identity Management, it is important to take a moment to review the components of an identity management suite and ensure a common understanding and vocabulary. This matters not only for our time together, but also for each project considering identity management.

And Now… The Components!

So what are these things anyway – identity manager, role manager…? Let’s take a brief look at each.

Role Manager: the brains of the operation

The role manager module is where roles, rules, and hierarchies are stored. Except for the most basic actions, it is the role manager module that gathers information on existing users and decides what action should be taken for a particular user – what access they should receive, to which groups they should belong, what segregation of duties rules apply, and how to handle an approval vacancy. This information is particularly important for handling terminated and transferred users to maintain audit compliance.

Fully populating all of the information required to make role manager effective is one of the biggest challenges of identity management, but this is also where some of the greatest benefits are achieved.

It is important to note that role manager can store information even if it cannot be auto-provisioned/-deprovisioned. For example, you may choose to role-base your electronic devices (e.g., desktop vs laptop; cell phone vs smartphone) for manual provisioning/deprovisioning.

Identity Manager: the braun of the suite

The identity manager component typically interfaces with the target systems to initiate auto-provisioning and -deprovisioning workflows, synchronize passwords, execute bulk updates, etc. The identity manager module will trigger some actions on its own based on pre-determined workflows, or it will confer with role manager to execute more complex provisioning actions. Identity manager can be configured to execute workflow tasks automatically, or it can assign tasks to specific administrative personnel for manual action.

Access Manager: simplifying sign-on

In this case, access mostly refers to authentication – the access manager component is what facilitates “single sign-on,” although some modules also mediate authorization, thus the term “access” manager. Of course, as we all know, there really isn’t such a thing as true single sign-on (yet – maybe someday we’ll get there). Although we call it single sign-on, it would be more accurately termed “reduced sign-on.” In any case, when access manager is implemented with a target system, it allows centralized authentication (and possibly authorization) with a source of record such as LDAP or AD, to eliminate the need for individual local accounts and password files on each system.

Audit Manager: reams of eye candy for the auditors

The audit manager component is basically the reporting capability, and is somewhat optional. Some products offer this as a separate module. Other products might include this within identity manager or even role manager. Still others leave it up to the individual organization to integrate their identity management suite with their enterprise reporting tool and generate reports as desired. The reason this component is called audit manager is that when offered, it comes with a variety of out-of-the-box reports that are of particular interest to SOX, PCI, and other auditors.

Action speaks louder than words…

Each month, I suggest a few practices I have learned that will bring quick benefit. For this month, the actions are (theoretically) minimal, since this was an introductory article aimed at simply setting the stage. Still, there is work to be done!

1. Start an identity management journal. In this journal, document:
   1. Expectations of an identity management implementation: what needs to be accomplished? How long do you think it will take? (Hint: once you determine a timeframe, triple it, and you’ll be close =)
   2. What are the expected roadblocks? For example, any management or other influential people that are already leaning toward a specific product, or refuse to even consider a particular vendor? Knowing this information up-front will give you more time to build a strategy to influence, counteract, or otherwise prepare
2. Start considering the team:
   1. Is there anyone in the organization who has implemented an identity management solution before? If yes, ensure their availability to help guide the process
   2. Are there team members interested in learning? This is a great career growth opportunity for smart, hard-working team members that need a new challenge
   3. Does the existing access management team have the bandwidth to embark on process and data cleanups? Most of the up-coming work will naturally fall on them, but if they’re already overworked, it may present a problem. Remember, much of the cleanup work is highly labor-intensive, especially for large organizations. If significant resource constraints are expected, start fighting that battle now
3. Was any of the information in this article new or surprising? If so, spend a little extra time absorbing it or doing some online research.

I am here to help

Leave a comment or drop me a note to let me know how your effort is going. Does your journal reveal any interesting insights? Leave a comment to share with others or ask for guidance.

Welcome to the continuation of the Into the Breach: Protect Your Business by Managing People, Information and Risk audio series. (Click this link) to learn more about this how this book solves today’s challenges and pick up a complete copy. This series, underwritten by Configuresoft, now part of EMC, is the full and unabridged audio version of Into the Breach, written by Michael Santarcangelo and read by the author. Join us for a new chapter released on the first Tuesday of each month (there are 13 chapters total).

In chapter 3 : Breaking the Security Diet

Breaking the security diet is recognition that what happens in organizations today is more akin to a crash diet than a healthy approach to securing information. In this chapter, Michael reveals the high cost of this “fad diet” approach and shines a light on the new fad diet: encryption. However, there is a solution, and Michael explains how to break the fad diet, improve leadership and engage individuals. A pivotal chapter in the book, designed to create a fundamental change in the way organizations and individuals protect information.

Put the power of Into the Breach to work for you

After listening to this segment of Into the Breach, keep the energy going and support the shift in thinking and inspire behavior change by

1. Engage with Michael on twitter (http://twitter.com/catalyst)
2. Subscribe to The Security Catalyst podcast & blog to get more insights; ask a question and get an answer!