Driving Compliance: What We Have versus What We Need

By Jim McFee

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.