IT auditing and controls - IT governance and controls

“IT Governance and Controls” or “IT Monitoring and Assurance Practices for Board and Senior Management”

Take your choice of titles of this article, but really it’s all about IT Governance.  Governance integrates best practices to ensure that the organization’s IT is aligned with, and supports, the business objectives; delivers value; manages risk associated with IT; manages its IT resources effectively and efficiently; and measures its own performance.

There are a number of reasons why IT Governance has become a significant issue within business organizations.  Some of the reasons are:

• The Board and Senior Management demand a better ROII (no that’s not a typo — it’s Return on Investment in IT)
• IT has an upward spiral when it comes to costs and expenditures
• Regulatory requirements are increasing daily
• Outsourcing is becoming as common a solution as in-housing
• Risks are becoming increasing more complex
• Businesses need to know how they’re doing compared to other like businesses

If you want to be a good IT auditor you will need to know that IT Governance has five (5) main focus areas and you will need to know what your role is in each of those areas.

First, the five main focus areas and a short definition of each:

• Strategic Alignment — IT’s goals are aligned with and supports the business goals and objectives
• Value Delivery — ensuring that IT delivers the promised benefits and concentrates on optimizing costs and proving the value of IT
• Risk Management — your job is to keep management aware of the risks the organization is facing with respect to IT, keeping in mind all the legal and regulatory requirements which surround IT
• Resource Management — in addition to optimizing costs, you will need to understand resource management, e.g. Are the IT assets being used effectively and efficiently?
• Performance Management — the Board and Senior Management like pictures. So you, as an auditor, need to understand what the Balanced Scorecard is, how it is used, and how to recommend its implementation, if it isn’t being used.

It’s all about “Tell them how you’re doing!”

Just as a short aside here, and you’ve seen this example in other articles I’ve written, let’s say you have on your Balanced Scorecard an item for the number of viruses detected and quarantined, and you have a corresponding element which shows the cost associated with a virus getting through and wreaking havoc on your internal systems.  It then becomes very easy to show why the budget line item for anti-virus software should be approved.

In IT Governance there are several frameworks which you will need to become familiar with:

• CobiT – developed by ISACA and ITGI to align IT with business.  It provides the tools to assess and measure the performance of 34 IT processes within a business.
• ISO/IEC 27001 – is a series of standards which provide guidance 12 areas and on 133 controls to be implemented within IT.
• NIST SP 800-53 – is the Recommended Security controls for Federal Information Systems and Organizations

CobiT’s main domains are:

• Plan and Organize
• Acquire and Implement
• Deliver and Support
• Monitor and Evaluate

Within “Plan and Organize” you will find 10 different processes:

• Define a Strategic IT Plan
• Define the Information Architecture
• Determine Technological Direction
• Define the IT Processes, Organization and Relationships
• Manage the IT Investment
• Communicate Management Aims and Direction
• Manage IT Human Resources
• Manage Quality
• Assess and Manage IT Risks
• Manage Projects

And then within each of these processes you will find several controls.  For example in PO9 - Assess and Manage IT Risks, you will find controls for:

• IT Risk Management Framework
• Establishment of Risk Content
• Event Identification
• Risk Assessment
• Risk Response
• Maintenance and Monitoring of a Risk Action Plan

Then if you take a closer look at “Event Identification” PO9.3, you will find that it says, “Identify events (an important realistic threat that exploits a significant applicable vulnerability) with  a potential negative impact on the goals or operations of the enterprise, including business, regulatory, legal, technology, trading partner, human resources and operations aspects.  Determine the nature of the impact and maintain this information.  Record and maintain relevant risks in a risk registry.

Then if you look deeper within PO9 you will find that CobiT has identified where the inputs for PO9 come from, in this case PO1, PO10, DS2, DS4, DS5, ME1 and ME4, and where the output from PO9 goes, specifically to Risk Assessment (PO1, DS4, DS5, DS12, ME4), Risk Reporting (ME4), IT-related risk management guidelines (PO6) and IT-related risk remedial action plans (PO4 & AI6).  You’ll also find a RACI (responsible, accountable, consulted, informed) chart with activities listed and cross-referenced to positions within the organization and the functions that position is assigned  (responsible, accountable, consulted, informed).  You’ll also find goals and metrics associated with each process.

Your job as an IT auditor, when the organization is using CobiT — or any framework for that matter— is to look at the processes and controls and to make an assessment of whether they are documented, implemented, and whether they are being measured for effectiveness.  In addition, you will want to determine if the personnel identified within the RACI chart are in fact being responsible, accountable, consulted and informed with regards to the activities associated with the process.

As I mentioned earlier, CobiT contains four domains, 34 processes, 210 controls, and the words “should” and “must” occur 170 times.   So you can imagine the size of your audit program if you’re going to check for DIM (documented, implemented, measured) for 210 controls and then check for evidence that 170 actions are taking place.

ISO/IEC 27001:2005(E) has five major areas as compared to CobiT’s four domains and they are:

• Information Security Management System (ISMS)
• Management Responsibility
• Internal ISMS audits
• Management Review of the ISMS
• ISMS Improvement

If you look closely at ISO/IEC 27001:2005(E) you will find that there are only four (4) required documented procedures:

• A documented procedure shall be established to define the management actions needed to – (and there are 10 individual items related to Control of Documents).
• The responsibilities and requirements for planning and conducting audits, and for reporting results and maintaining records (see 4.3.3) shall be defined in a documented procedure – (and this deals with the third bullet above “Internal ISMS Audits”)
• The documented procedure for corrective action shall define requirements for – (and there are six individual items related to Corrective Action)
• The documented procedure for preventive action shall define requirements for – (and there are six individual items related to Preventive Action)

That’s it, just four documented procedures required in ISO/IEC 27001:2005(E).  So, your saying to yourself how can this be?  Surely an ISMS has to have more than four documented procedures?  The catch is in the wording.

To become ISO certified for your ISMS, you are certified to the requirements of ISO27001.  If you look at the required documented procedures for ISO 27001 there are only four.  If however, you look at the first domain (Information Security Management System) and you look within at section 4.2: Establishing and managing the ISMS, and then still further at sub-paragraph j, you will find all the control objectives and controls listed in Appendix A must be addressed in a documented “Statement of Applicability,” which by the way isn’t the same thing as a documented procedure.

And, by the way, when you’re reading Appendix A, read the second paragraph of the intro carefully because it states: ISO/IEC 27002:2005(E) Clauses 5 through 15 provide implementation advice and guidance on best practice in support of the controls specified in A.5 to A.15.  Now here’s where it gets even more convoluted for the IT auditors.  If you look at A.14.1.2 you will find that it addresses Business Continuity and Risk Assessment.  Taking that information and going over to ISO/IEC 27005:2005(E) 14.1.2 you will find it says  “….This should be followed by a risk assessment….”  What isn’t exactly clear, but a knowledge of the ISO standards will give you, is that you need to go back to Section 4 in 27002 which is entitled “Risk Assessment and Treatment” which in turn will direct you to ISO27005:2008 entitled “Information Security Risk Management.”

But you say, wait a minute, Section 4 specifically says “…Examples of risk assessment methodologies are discussed in ISO/IEC TR 13335-3 (Guidelines for the Management of IT Security: Techniques for the Management of IT Security)…”  I acknowledge that is what is in Section 4. However, if you look at ISO27005, at the last paragraph on the FOREWORD page you will find the following; “This first edition of ISO/IEC 27005 cancels and replaces ISO/IEC TR 13335-3:1998….”  So you see, as an IT auditor, it not just taking things literally, but doing research to make sure you’re absolutely sure of the framework and all its iterations.

The objective of NIST Special Publication 800-53 – Recommended Security Controls for Federal Information Systems and Organizations is to provide a set of security controls that can satisfy the breadth and depth of security requirements levied on information systems and organizations and that is consistent with and complementary to other established information security standards.

These security controls are broken down into 18 different families.  Which are:

• Access Control (AC)
• Awareness and Training (AT)
• Audit and Accountability (AU)
• Security Assessment and Authorization (CA)
• Configuration Management (CM)
• Contingency Planning (CP)
• Identification and Authentication (IA)
• Incident Response (IR)
• Maintenance (MA)
• Media Protection (MP)
• Physical and Environmental Protection (PE)
• Planning (PL)
• Personnel Security (PS)
• Risk Assessment (RA)
• System and Services Acquisition (SA)
• System and Communications Protection (SC)
• System and Information Integrity (SI)
• Program Management (PM)

The structure of each of the controls is a control section, supplemental guidance section, a control enhancements section, references and a priority and baseline allocation section.

This document is very detailed in that is has specific assignments for actions to be taken.  However, if the organization that you are auditing is using NIST SP 800-53 as their framework, the questions you ask remain the same:

• Ask the client to tell you what they’re doing in terms of security, e.g. what controls do you have in place?
• Ask the client to show you that they are doing what they said they were going to do, e.g. show me examples of change control documentation.
• Ask the client to prove that they have monitored the control for effectiveness and efficiency, e.g. show me the logs that you reviewed and that the logs are reflecting invalid login attempts.

OK, so enough about frameworks, let’s move onto a few other topics before we close this article.

For IT Governance to be effective, it has to be managed and there needs to be two committees in place to provide this effectiveness.  The first is the IT strategy committee, which provides the high level guidance and focuses on current and future strategic IT issues, and the second is the IT Steering committee which focuses on implementation and oversees the day-to-day management of IT service delivery and IT projects.

The outcomes of security governance as I mentioned before are:

• Strategic Alignment
• Risk Management
• Value Delivery
• Performance measurement
• Resource Management
• Process integration

The only additional comments that I would add here are in the area of performance measurement.  Measure, monitor and report on information security processes to ensure that SMART (Specific, Measurable, Achievable, Relevant and Time-bound) objectives are achieved.

So as an IT auditor you need to test to see if the security controls that have been put in place are SMART.

IT Governance and Controls would not be complete without a few words about John Zachman.  John Zachman first published the Framework for Enterprise Architecture (FEA) in the late 1980s.  The Zachman FEA has horizontal representations for Scope, Enterprise model, Systems model, Technology model, and Detailed representation and then vertical representations for Data, Functional (Application), Network (Technology), People (Organization), Process (Workflow) and Strategy with the ultimate objective to complete al cells of the matrix.  Typically, organizations will approach FEA either from a Technology-driven perspective or from a Business-driven perspective.  In either case, you as an IT auditor need to understand that if you’re working with a Federal Government agency, the Feds take EA seriously and in fact, a Federal organization is required, by law, to develop an EA and set up an EA governance structure that ensures that the EA is referenced and maintained in the planning and budgeting activities of all systems.   The FEA (Federal Enterprise Architecture) was developed specifically for this purpose and can be seen if full detail at http://www.feapmo.gov/.

Until next time, happy reading.

Kenneth

P.S. You can find other articles related it IT Auditing and Controls here.