Introduction to IT Audit

Auditing is an evaluation of a person, organization, system, process, enterprise, project or product,

performed to ascertain the validity and reliability of information; and also to provide an assessment of
a systems internal controls. The goal of an audit is to express an opinion based on the work done
and since due to practical constraints, an audit provides only reasonable assurance that the
statement are free from material error and typically rely on statistical sampling.

IT auditing takes that one step further and evaluates the controls around the information with respect
to confidentiality, integrity, and availability. While a financial audit will attest to the validity and
reliability of information, the IT audit will attest to the confidentiality of the information, the integrity of
the information and in situations where availability is a key factor will also attest to the availability and
the ability to recover in the event of an incident.

One of the key factors in IT auditing and one that audit management struggles with constantly, is to
ensure that adequate IT audit resources are available to perform the IT audits. Unlike financial audits,
IT audits are very knowledge intensive, for example, if an IT auditor is performing a Web Application
audit, then they need to be trained in web applications; if they are doing an Oracle database audit,
they need to be trained in Oracle; if they are doing a Windows operating system audit, they need to
have some training in Windows and not just XP, theyll need exposure to Vista, Windows 7, Server
2003, Server 2008, IIS, SQL-Server, Exchange, etc.. As you can appreciate being an IT auditor
requires extensive technical training in addition to the normal auditor and project management
training.

Another factor that audit management faces is the actual management of the IT auditors, for not only
must they track time against audit objectives, audit management must allow for time to follow-up on
corrective actions taken by the client in response to previous findings and/or recommendations.

There are many different types of audits:

Financial audits
Operational audits
Integrated audits
Administrative audits
IT audits
Specialized audits
Forensic audits

The IT auditor will be involved with all of these except the financial audit. And when we talk about
extensive technical training and forensic IT auditing we are speaking about a significant investment in
time and money for an IT auditor to be qualified to do a forensic IT audit.

Since there is a limited amount of time and a limited amount of professional qualified IT auditors, IT
auditing is more and more moving to a risk-based audit approach which is usually adapted to develop
and improve the continuous audit approach.

But before we get into risk, lets take a look (briefly) at IT audits role within the organization. IT audits
role is to provide an opinion on the controls which are in place to provide confidentiality, integrity and
availability for the organizations IT infrastructure and data which supports the organizations business
processes. Now in order to do that there has to be some overall planning to determine which

1
business processes to audit. I mentioned before that IT auditing is moving towards a risk-based audit
approach and the planning process starts with a review of the organization and gaining an
understanding of the business. Typically this starts with a review of the Business Impact Analysis
(BIA) which the organization has prepared for all of its business functions, after which the
organization will have established ranking criteria and determined which functions are essential to the
business. Those essential functions will then have been ranked according to which ones are most
critical to the organization and the IT auditor can start at the top of the list. Now granted there are a lot
of other considerations which go into which functions to audit, including the last time an area was
audited, are there legal requirements which require annual audit/compliance statements, etc., but for
the time being starting at the top will assure management that the most critical business functions are
being reviewed by IT audit. There are some other reasons to use risk assessment to determine the
areas to be audited, including:
Enables management to effectively allocate limited audit resources
Ensures that relevant information has been obtained from all levels of management
Establishes a basis for effectively managing the IT audit department/function
Provides a summary of how the individual audit subject area is related to the overall
organization as well as to the business plans.

Now for some definitions before we go any further:

Audit risk the risk that information may contain a material error that may go undetected
during the course of the audit.
Inherent risk the risk that an error exists that could be material or significant when combined
with other errors encountered during the audit, assuming that there are no related
compensating controls. Inherent risks exist independent of an audit and can occur because of
the nature of the business. (e.g. if you build your data center in the basement of the building,
and the building is located in a flood plain, there is an inherent risk that your data center will
get flooded.) I know bad example; who would do that, but it helps explain the idea.
Control risk the risk that a material error exists that will not be prevented or detected in a
timely manner by the internal control systems. If for example, the internal control is a manual
review of computer logs, errors might not be detected in a timely manner simply due to the
volume of data in the computer logs.
Detection risk the risk that an IT auditor uses an inadequate test procedure and concludes
that material errors do not exist when, in fact, they do. For example, lets say youre using the
FREE version of a testing tool which does not contain all the vulnerability database entries and
you conclude there are no errors in a particular database, when in fact, there are, which you
would have found if you had been using an adequate test procedure. In this case, the full
blown version of a testing tool and not a demo version.

Audit objectives refer to the specific goals that must be accomplished by the IT auditor, and in
contrast, a control objective refers to how an internal control should function. Audit objectives most
often, focus on substantiating that the internal controls exist to minimize business risks, and that they
function as expected. As an example, in a financial audit, an internal control objective could be to
ensure that financial transactions are posted properly to the General Ledger, whereas the IT audit
objective will probably be extended to ensure that editing features are in place to detect erroneous
data entry.

So what is a control or an internal control? Lets take a look at some examples. Internal controls are
normally composed of policies, procedures, practices and organizational structures which are
implemented to reduce risks to the organization. There are two key aspects that controls should
2
address: that is, what should be achieved and what should be avoided. Controls are generally
classified as either preventive, detective or corrective. So first, preventive; the controls should, detect
problems before they arise such as a numeric edit check on a dollar data entry field. By not allowing
anything other than numeric characters you are preventing things like cross-site scripting or SQL
injection. Next detective controls; like exception reports from log files which show that an
unauthorized user was attempting to access data outside of their job requirements. Then finally,
corrective; something as simple as taking backups, so that in the event of a system failure, you can
correct the problem by restoring the database. The backup procedures being the corrective control.

When you look at business functions, one of the things an IT auditor should look for is where in the
process is there a potential for compromise of confidentiality, integrity or availability. For example, if
data is gathered via a web front-end which is then reformatted and sent to the database either for
storage or inquiry and then returned to the web front-end for redisplay to the user there a number of
control points to consider:
The web front-end itself, who has access and how are they authenticated
The connection between the web front-end and the database, how is this connection protected
The database, who is allowed to update, what data can be returned to the web front-end
The network, is traffic restricted to just the traffic required to support the web application

The list goes on and on but you get the point, there are a lot of control points to consider when
looking at a particular business function. In trying to determine all the control points, an IT auditor
must consider the system boundary which should be part of the Business Impact Analysis we
discussed earlier. And from that BIA, the IT auditor should be able to construct a data flow diagram
and to identify all the control points that will need to be reviewed as part of his/her audit.

Remember, our work is resource intensive and we have a limited amount of time, so taking a risk
based approach, we would review the control points that represent the greatest risk to the business.
And it is part of our job to identify the risks and to help management understand what the risk to the
business would be if a control at a specific point malfunctions and the information is compromised.

Definition of IT audit
An IT audit can be defined as any audit that encompasses review and evaluation of automated
information processing systems, related non-automated processes and the interfaces among them.
Planning the IT audit involves two major steps. The first step is to gather information and do some
planning the second step is to gain an understanding of the existing internal control structure. More
and more organizations are moving to a risk-based audit approach which is used to assess risk and
helps an IT auditor make the decision as to whether to perform compliance testing or substantive
testing. In a risk-based approach, IT auditors are relying on internal and operational controls as well
as the knowledge of the company or the business. This type of risk assessment decision can help
relate the cost-benefit analysis of the control to the known risk. In the Gathering Information step
the IT auditor needs to identify five items:
Knowledge of business and industry
Prior years audit results
Recent financial information
Regulatory statutes
Inherent risk assessments

A side note on Inherent risks, is to define it as the risk that an error exists that could be material or
significant when combined with other errors encountered during the audit, assuming there are no
3
related compensating controls. As an example, complex database updates are more likely to be
miswritten than simple ones, and thumb drives are more likely to be stolen (misappropriated) than
blade servers in a server cabinet. Inherent risks exist independent of the audit and can occur
because of the nature of the business.

In the Gain an Understanding of the Existing Internal Control Structure step, the IT auditor needs to
identify five other areas/items:
Control environment
Control procedures
Detection risk assessment
Control risk assessment
Equate total risk

Once the IT auditor has Gathered Information and Understands the Control then they are ready to
begin the planning, or selection of areas, to be audited. Remember one of the key pieces of
information that you will need in the initial steps is a current Business Impact Analysis (BIA), to assist
you in selecting the application which support the most critical or sensitive business functions.

Objectives of an IT audit
Most often, IT audit objectives concentrate on substantiating that the internal controls exist and are
functioning as expected to minimize business risk. These audit objectives include assuring
compliance with legal and regulatory requirements, as well as the confidentiality, integrity, and
availability (CIA no not the federal agency, but information security) of information systems and
data.

IT audit strategies
There are two areas to talk about here, the first is whether to do compliance or substantive testing
and the second is How do I go about getting the evidence to allow me to audit the application and
make my report to management? So what is the difference between compliance and substantive
testing? Compliance testing is gathering evidence to test to see if an organization is following its
control procedures. On the other hand substantive testing is gathering evidence to evaluate the
integrity of individual data and other information. For example, compliance testing of controls can be
described with the following example. An organization has a control procedure which states that all
application changes must go through change control. As an IT auditor you might take the current
running configuration of a router as well as a copy of the -1 generation of the configuration file for the
same router, run a file compare to see what the differences were; and then take those differences
and look for supporting change control documentation. Dont be surprised to find that network
admins, when they are simply re-sequencing rules, forget to put the change through change control.
For substantive testing, lets say that an organization has policy/procedure concerning backup tapes
at the offsite storage location which includes 3 generations (grandfather, father, son). An IT auditor
would do a physical inventory of the tapes at the offsite storage location and compare that inventory
to the organizations inventory as well as looking to ensure that all 3 generations were present.

The second area deals with How do I go about getting the evidence to allow me to audit the
application and make my report to management? It should come as no surprise that you need to:
Review IT organizational structure
Review IT policies and procedures
Review IT standards
Review IT documentation
4
 Review the organizations BIA
Interview the appropriate personnel
Observe the processes and employee performance
Examination, which incorporates by necessity, the testing of controls, and therefore includes
the results of the tests.
As additional commentary of gathering evidence, observation of what an individual actually does
versus what they are supposed to do, can provide the IT auditor with valuable evidence when it
comes to control implementation and understanding by the user. Also performing a walk-through can
give valuable insight as to how a particular function is being performed.

Application vs. general controls

General controls apply to all areas of the organization including the IT infrastructure and support
services. Some examples of general controls are:
Internal accounting controls
Operational controls
Administrative controls
Organizational security policies and procedures
Overall policies for the design and use of adequate documents and records
Procedures and practices to ensure adequate safeguards over access
Physical and logical security policies for all data centers and IT resources

Application controls refer to the transactions and data relating to each computer-based application
system; therefore, they are specific to each application. The objectives of application controls are to
ensure the completeness and accuracy of the records and the validity of the entries made to them.
Application controls are controls over IPO (input, processing, output) functions, and include methods
for ensuring that:
Only complete, accurate and valid data are entered and updated in an application system
Processing accomplishes the designed and correct task
The processing results meet expectations
Data is maintained

As an IT auditor, your tasks when performing an application control audit should include:
Identifying the significant application components; the flow of transactions through the
application (system); and to gain a detailed understanding of the application by reviewing all
available documentation and interviewing the appropriate personnel, such as system owner,
data owner, data custodian and system administrator.
Identifying the application control strengths and evaluating the impact, if any, of weaknesses
you find in the application controls
Developing a testing strategy
Testing the controls to ensure their functionality and effectiveness
Evaluating your test results and any other audit evidence to determine if the control objectives
were achieved
Evaluating the application against managements objectives for the system to ensure efficiency
and effectiveness.

IT audit control reviews

5
After gathering all the evidence the IT auditor will review it to determine if the operations audited are
well controlled and effective. Now this is where your subjective judgment and experience come into
play. For example, you might find a weakness in one area which is compensated for by a very strong
control in another adjacent area. It is your responsibility as an IT auditor to report both of these
findings in your audit report.

The audit deliverable

So whats included in the audit documentation and what does the IT auditor need to do once their
audit is finished. Heres the laundry list of what should be included in your audit documentation:
Planning and preparation of the audit scope and objectives
Description and/or walkthroughs on the scoped audit area
Audit program
Audit steps performed and audit evidence gathered
Whether services of other auditors and experts were used and their contributions
Audit findings, conclusions and recommendations
Audit documentation relation with document identification and dates (your cross-reference of
evidence to audit step)
A copy of the report issued as a result of the audit work
Evidence of audit supervisory review

When you communicate the audit results to the organization it will typically be done at an exit
interview where you will have the opportunity to discuss with management any findings and
recommendations. You need to be absolutely certain of:
The facts presented in the report are correct
The recommendations are realistic and cost-effective, or alternatives have been negotiated
with the organizations management
The recommended implementation dates will be agreed to for the recommendations you have
in your report.

Your presentation at this exit interview will include a high-level executive summary (as Sgt. Friday use
to say, just the facts please, just the facts). And for whatever reason, a picture is worth a thousand
words so do some PowerPoint slides or graphics in your report.

Your audit report should be structured so that it includes:

An introduction (executive summary)
The findings are in a separate section and grouped by intended recipient
Your overall conclusion and opinion on the adequacy of controls examined and any identified
potential risks
Any reservations or qualifications with respect to the audit
Detailed findings and recommendations

Finally, there are a few other considerations which you need to be cognizant of when preparing and
presenting your final report. Who is the audience? If the report is going to the audit committee, they
may not need to see the minutia that goes into the local business unit report. You will need to identify
the organizational, professional and governmental criteria applied such as GAO-Yellow Book, CobiT
or NIST SP 800-53. Your report will want to be timely so as to encourage prompt corrective action.

6
And as a final, final parting comment, if during the course of an IT audit, you come across a materially
significant finding, it should be communicated to management immediately, not at the end of the
audit.

What is a standard? Who defines standards? Where do we as IT auditors come into contact
with standards? Which framework should we use to do an IT audit and if there isnt one which
one should we recommend? -
In order to understand IT auditing and why we do IT auditing you need a brief history lesson. So this
post will be more history than anything else. Hopefully by the end of the article you will have an
appreciation for the different organizations and their individual standards and frameworks.

First, lets start with a definition: ISO/IEC Guide 2:1996, definition 3.2 defines a standard as:
A document established by consensus and approved by a recognized body that
provides for common and repeated use, rules, guidelines or characteristics for activities
or their results, aimed at the achievement of the optimum degree of order in a given
context.

There are several organizations which have their own definitions for standards as well as their own
definitions for how an audit should be conducted and what audit reports should be issued for IT
engagements. The first organization that I want to take a quick look at is the American Institute of
Certified Public Accounts or AICPA and its primary certification the CPA.

The AICPA and its predecessors have a history dating back to 1887, when the American Association
of Public Accountants (AAPA) was formed. In 1916, the American Association was succeeded by the
Institute of Public Accountants, at which time there was a membership of 1,150. The name was
changed to the American Institute of Accountants in 1917 and remained so until 1957, when it
changed to its current name of the American Institute of Certified Public Accountants. The American
Society of Certified Public Accountants was formed in 1921 and acted as a federation of state
societies. The Society was merged into the Institute in 1936 and, at that time, the Institute agreed to
restrict its future members to CPAs. This is key because the certification associated with the AICPA
which is IT specific is the Certified Information Technology Professional (CITP). In other words, if
someone want to be an IT auditor and have the CITP they must be a CPA. In my opinion, that means
they are a financial auditor first and an IT auditor second.

In 1968, the American Institute of Certified Public Accountants (AICPA) had the Big Eight (now the
Big Four) accounting firms participate in the development of EDP auditing. The result of this was the
release of Auditing & EDP. The book included how to document EDP audits and examples of how to
process internal control reviews. And from this came the Statement on Auditing Standards (SAS) No.
70. For service organizations, this is a widely recognized internal control auditing standard. A
service auditors examination performed in accordance with SAS No. 70 is widely recognized,
because it represents that a service organization has been through an in-depth audit of their control
objectives and control activities, which often include controls over information technology and related
processes.

Around this same time a small group of individuals with similar jobsauditing controls in the
computer systems that were becoming increasingly critical to the operations of their organizations
sat down to discuss the need for a centralized source of information and guidance in the field. In
1969, Stuart Tyrnauer, employed by the (then) Douglas Aircraft Company, incorporated the entity as
the EDP Auditors Association. EDP auditors formed the Electronic Data Processing Auditors
Association (EDPAA). The goal of the association was to produce guidelines, procedures and
7
standards for EDP audits. This was ISACAs start and in 1976 the association formed an education
foundation to undertake large-scale research efforts to expand the knowledge and value of the IT
governance and control field. The first work from this group was in 1977, when the first edition of
Control Objectives was published. This publication is now known as Control Objectives for
Information and related Technology (CobiT). CobiT is the set of generally accepted IT control
objectives for IT auditors. In 1994, EDPAA changed its name to Information Systems Audit and
Control Association (ISACA). ISACA now goes by its acronym only, to reflect the broad range of IT
governance professionals it serves.

Another organization is the Institute of Internal Auditors (IIA) which was established in 1941, and is an
international professional association and the internal audit professions global voice, recognized
authority, acknowledged leader, chief advocate, and principal educator. Members work in internal
auditing, risk management, governance, internal control, information technology audit, education, and
security.

Notice that we said the IIA is internal auditing, whereas AICPA and ISACA would most commonly be
referred to as external auditing or auditors. And lets dont forget the Feds.

The U.S. Government Accountability Office (GAO) is an independent, nonpartisan agency that works
for Congress. Often called the congressional watchdog, GAO investigates (read that as audits) how
the federal government spends taxpayer dollars. The mission of the GAO is to support the Congress
in meeting its constitutional responsibilities and to help improve the performance and ensure the
accountability of the federal government for the benefit of the American people. The GAO provides
Congress with timely information that is objective, fact-based, nonpartisan, non-ideological, fair, and
balanced.

Their work is done at the request of congressional committees or subcommittees or is mandated by

public laws or committee reports and supports congressional oversight by
auditing agency operations to determine whether federal funds are being spent efficiently and
effectively;
investigating allegations of illegal and improper activities;
reporting on how well government programs and policies are meeting their objectives;
performing policy analyses and outlining options for congressional consideration; and
issuing legal decisions and opinions, such as bid protest rulings and reports on agency rules.

Another organization which we need to look at is, COSO which was formed in 1985 to sponsor the
National Commission on Fraudulent Financial Reporting, an independent private-sector initiative
which studied the causal factors that can lead to fraudulent financial reporting. It also developed
recommendations for public companies and their independent auditors, for the SEC and other
regulators, and for educational institutions.

The National Commission was sponsored jointly by five major professional associations
headquartered in the United States: the American Accounting Association (AAA), the American
Institute of Certified Public Accountants (AICPA), Financial Executives International (FEI), The
Institute of Internal Auditors (IIA), and the National Association of Accountants (now the Institute of
Management Accountants [IMA]). Wholly independent of each of the sponsoring organizations, the
Commission contained representatives from industry, public accounting, investment firms, and the
New York Stock Exchange.

8
The original chairman of the National Commission was James C. Treadway, Jr., Executive Vice
President and General Counsel, Paine Webber Incorporated and a former Commissioner of the U.S.
Securities and Exchange Commission. Hence, the popular name Treadway Commission. COSOs
goal is to provide thought leadership dealing with three interrelated subjects: internal control,
enterprise risk management (ERM), and fraud deterrence.

In September 1992, the four volume report entitled Internal Control Integrated Framework was
released by COSO and later re-published with minor amendments in 1994. This report presented a
common definition of internal control and provided a framework against which internal control
systems may be assessed and improved. This report is one standard that U.S. companies use to
evaluate their compliance with FCPA. According to a poll by CFO Magazine released in 2006, 82% of
respondents claimed they used COSOs framework for internal controls. Other frameworks used by
respondents included COBIT, AS2 (Auditing Standard No. 2, PCAOB), and SAS 55/78 (AICPA).

The last organization that I want to take a quick look at is the IT Governance Institute which was
formed by ISACA to focus on original research on IT governance and related topics. The IT
Governance Institute (ITGI) was established in 1998 to advance international thinking and standards
in directing and controlling an enterprises information technology. Effective governance of IT helps
ensure that IT supports business goals, optimizes business investment in IT, and appropriately
manages IT-related risks and opportunities.

Ive talked about several different organizations: AICPA, IIA, ISACA, COSO, GAO, and ITGI. There
are different frameworks associated with each and some books published by each that you might
want to consider. First lets take a look at the major frameworks and there are three primary ones you
need to be familiar with.

COSO Integrated ERM Framework

ISACA & ITGIs CobiT
International Organization for Standardizations ISO27000 series
And although not a true framework, the Feds NIST SP 800 series of documents with particular
attention to NIST SP 800-53.

In 2001, COSO initiated a project, and engaged PricewaterhouseCoopers, to develop a framework

that would be readily usable by managements to evaluate and improve their organizations enterprise
risk management.

The period of COSOs frameworks development was marked by a series of high-profile business
scandals and failures where investors, company personnel, and other stakeholders suffered
tremendous loss. In the aftermath were calls for enhanced corporate governance and risk
management, with new law, regulation, and listing standards. The need for an enterprise risk
management framework, providing key principles and concepts, a common language, and clear
direction and guidance, became even more compelling. COSOs Enterprise Risk Management
Integrated Framework filled this need, and COSO expected that it will become widely accepted by
companies and other organizations and indeed all stakeholders and interested parties. And in truth
according to a poll by CFO Magazine released in 2006, 82% of respondents claimed they used
COSOs framework for internal controls.

COSO (and similar compliant frameworks) is generally accepted as the internal control framework for
enterprises. COBIT is the generally accepted internal control framework for IT.

9
On the other hand, CobiT, which is geared more towards IT controls, was developed by ITGI/ISACA.
If you look closely at the structure of CobiT you will see some of the maturity levels from SEI/CMM.
CobiT defines IT activities in a generic process model within four domains. (Plan and organize,
Acquire and Implement, Deliver and Support, and Monitor and Evaluate). Within those four domains
CobiT defines control objectives for all 34 processes. And within each process has defined six
general maturity levels. This is a very lengthy framework for IT and I will not try to do justice to it in a
short article here, rather, I would suggest that you or someone on your staff who is a member of
ISACA, order a copy and have as a reference for your group.

ISO/IEC 27000 series of standards from the International Organization of Standardization (and, yes I
know that is IOS not ISO, but dont know why the changed the sequence of letters) includes three of
note: 27001 which is the high-level document for Information Security Management Systemsthis by
the way is the one organizations can be certified too; ISO 27002 which is listing of all the security
framework to support the certification of ISO 27001; and ISO 27005 which is a detailed explanation of
Risk Management. If you look at Appendix A in ISO 27001 and compare it to ISO27002 you will find
it to be an abbreviated version. For the full details use ISO27002 which contains 12 sections, 39
objectives, 133 controls, and 1,033 Shoulds. By the way, the shoulds are things that you
SHOULD be doing.

And finally, with respect to frameworks there is NIST SP 800-53 Recommended Security Controls for
Federal Information Systems and Organizations. Whats interesting to note in 800-53 is that
Appendix H is a mapping of 800-53 to the ISO 27001 Appendix A standard. Whats interesting is that
if you are a U.S. Federal agency the language at the beginning of 800-53 takes away the framework
selection process by saying In accordance with the provisions of FISMA, the Secretary of Commerce
shall, on the basis of standards and guidelines developed by NIST, prescribe standards and
guidelines pertaining to federal information systems. The Secretary shall make standards compulsory
and binding to the extent determined necessary by the Secretary to improve the efficiency of
operation or security of federal information systems. Standards prescribed shall include information
security standards that provide minimum information security requirements and are otherwise
necessary to improve the security of federal information and information systems.

In other words, you will use NIST SP 800-53. But not to worry, the folks at NIST are re-writing some
of the SP 800 series so that it is alignment with ISO27001, Appendix A. And if youre still having
trouble deciding which framework to select, you should know that ISACA has published a MAPPING
of CobiT to ISO27001. So bottom line, everyone seems to be mapping to ISO27000 series, so I for
one will recommend to the organizations that I audit, that they should use ISO 27001 as their IT
security framework and COSO ERM framework for their non-IT internal controls.

Now some parting thoughts, books to have on your shelf, and certifications to aspire towards
obtaining.

As an IT auditor, youll want to have a copy of IIAs IPPF (International Professional Practices
Framework) on your desk. Thats more commonly known in auditing circles as the red book, which
isnt the same as the red book in IT circles. Youll also want to have a copy of GAOs Yellow Book, a
copy of ISACAs CobiT 4.1, and a copy of the ISO 27000 series (27001, 27002 and 27005).
Something on COSOs ERM framework would be nice to have, and you can download a copy from
their website. As a footnote on COSO, if someone can find the COSO CUBE, I would like to have
one for my office. From AICPA, print out a copy of the ITMS & CITP body of knowledge, in color, and
frame-it and put it in your bookcase. It makes for interesting conversation.

10
For the certifications, unless youre already a CPA theres no way of obtaining the CITP, if you are
then by all means expand and pick up this cert. From ISACA, youll want to consider CISA and if you
are doing internal IT audits youll also want to consider the CIA from the Internal Audit Association.
From the Internal Organization of Standardization youll most definitely want to have the ISO27001
Lead Auditor certification. This last one requires proof of performance of IT audits against the ISO
framework under the guidance of a certified ISO 27001 Lead Auditor. There are other certifications
within the IT security field, but these are the prime ones for IT auditors.

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 its all about IT Governance. Governance integrates
best practices to ensure that the organizations 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 thats not a typo its 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 theyre 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 ITs 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 isnt being used.

Its all about Tell them how youre doing!

Just as a short aside here, and youve seen this example in other articles Ive written, lets 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

11
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

CobiTs main domains are:

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

Within Plan and Organize you will find 10 different processes:

Define a Strategic IT Plan Communicate Management Aims and
Define the Information Architecture Direction
Determine Technological Direction Manage IT Human Resources
Define the IT Processes, Organization Manage Quality
and Relationships Assess and Manage IT Risks
Manage the IT Investment 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 Risk Response
Establishment of Risk Content Maintenance and Monitoring of a Risk
Event Identification Action Plan
Risk Assessment

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).
Youll 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). Youll 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

12
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 youre
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 CobiTs four domains and they are:
Information Security Management Internal ISMS audits
System (ISMS) Management Review of the ISMS
Management Responsibility 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)

Thats it, just four documented procedures required in ISO/IEC 27001:2005(E). So, youre 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 isnt the same thing as a documented procedure.

And, by the way, when youre 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 heres 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
isnt 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.

13
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 youre
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) Physical and Environmental Protection
Awareness and Training (AT) (PE)
Audit and Accountability (AU) Planning (PL)
Security Assessment and Authorization Personnel Security (PS)
(CA) Risk Assessment (RA)
Configuration Management (CM) System and Services Acquisition (SA)
Contingency Planning (CP) System and Communications Protection
Identification and Authentication (IA) (SC)
Incident Response (IR) System and Information Integrity (SI)
Maintenance (MA) Program Management (PM)
Media Protection (MP)

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 theyre 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, lets 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 Performance measurement
Risk Management Resource Management
Value Delivery Process integration

14
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 youre 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/.

Information Technology Basics

In its most basic form, information technology (IT), can be reduced down to IPO. No thats not an
Initial Public Offering, but rather Input-Processing-Output. Think of it this way, youre lying in bed,
sleeping, and your ears pick up a distinct ringing (INPUT). Your ears send a message to the brain
theres ringing going on out here. Your brain processing the signal (PROCESSING) and sends a
signal to your arm to reach out and hit the snooze button (OUTPUT). In its most basic form, IT takes
INPUT, runs it through some programs PROCESSING and then sends OUTPUT.

INPUT can take on many varied forms from data fields entered on a web-page to an analog circuit
sensing a rise in temperature in a room. PROCESSING can also come in many different forms
depending upon the program being executed or ran. OUTPUT can be as simple as a field in a file
being updated, to a payroll check, to a voluminous report being printed on a high speed printer.

Computers are generally categorized following several criteria, mainly based on their processing
power, size and architecture. Some common types of computers are: Supercomputers, Mainframes,
High-end and midrange servers, Personal computers (PCs), thin client computers, notebook/laptop
computers and then on to smart phones and personal digital assistants (PDAs). Now heres the
oddity; I had the opportunity of seeing a supercomputer at a major university, constructed entirely of
Apple MAC laptops. In my lifetime, the first mainframe I worked on had less memory, less disk
space, and less processing power than the laptop which I currently use to write these articles. It also
took up several thousand square feet of raised floor space and required special air conditioning,
humidity control, electrical control and so forth. My laptop on the other hand fits comfortably in my lap
while I sit in the lazy boy rocker writing this article. Disk storage too has dramatically been reduced
in size. Now I can buy a thumb drive with more storage capacity than an array of hard drives
attached to that old mainframe.

However, the IT audit issues remain the same, so lets get to some of those before I bore you
completely out of your skull.

15
Some of the key control points in todays IT environment which need to be identified and categorized
are those areas which directly affect confidentiality, integrity, and availability. For example, who has
access to the hardware, logical or physical? Who has access to the data and are they authorized to
make changes to the data? Whos reviewing those changes to the data to see if the change was
authorized? Let me re-introduce the principle of least privilege here. A person should only have
access to the data, systems, hardware, etc., that they need to be able to do their job, no more. This
access should be reviewed periodically, no less than annually and by all means when a change of
employment occurs. Thats confidentiality, now lets look at integrity. How do you know when you
receive an email, say an offer of employment letter with a substantial salary quoted, that the letter has
integrity? That the letter wasnt tampered with in-route to your inbox in your email. Here you are
thinking, WOW, they must be really impressed if theyre going to offer me that much money, when in
fact, one of your co-workers interrupted your email, made some modifications (increased the salary
by adding an extra zero at the end) and then forwarded it on to you. Ensuring that the email has not
been tampered with; ensuring that the calculations of your net pay are as they should be; are
examples of data integrity. Availability means just that, the data and/or system is available when it is
needed. As an IT auditor this means you want to look at disaster recovery plans, recovery time
objectives, recovery point objectives, and so forth but well get into DRP details in the seventh article.

Some of the basics of computer hardware architecture include the IPO as we discussed before. The I
and O are the Input/Output components and include such things as this keyboard Im typing on, or a
mouse, both of which are I only. That is they only input, whereas a touchscreen is both input and
output. On the O only side you have things like printers. Disk drives are examples of both input and
output devices. The P in IPO is the processing components typically referred to as a CPU or central
processing unit which consists of three primary pieces, an arithmetic logic unit (ALU), a control unit,
and an internal memory. Now there are a lot of other components of a computer and Im sure youve
heard of several, like motherboard (but youll never hear of a fatherboard), RAM, ROM, DRAM,
SDRAM and the letters go on and on. Memory comes in all different types and sizes and what you
need to know as an IT auditor is that even when powered off, some memory still contains sensitive
data and needs to be protected.

When we talk about hardware, several things come to mind that I as an IT auditor want to make sure
of. First, is the hardware being maintained, does the vendor still support the hardware or has it
reached EOL (end-of-life) and is unsupported, which can be interpreted as If it breaks it cant be
fixed, so Mr. Client youre out of luck because the system cant be recovered. Next, just like
software, the hardware has something called BIOS (Basic Input Output System) which is being
updated by the vendor, typically to support new functions and/or features. Your question, is, Is the
BIOS current, and is the BIOS protected? Why do you ask if it is protected? Because if a hacker
can get to the BIOS, they can alter the boot sequence, boot from a LINUX CD and copy all your
sensitive information off to a gigabyte thumb drive in less than ten minutes. Reboot your machine,
and youll have no evidence that the data has been copied, except an entry in the log that says the
machine was rebooted and that might not even be there if the hacker covers their tracks.

But enough about hardware, lets look at software, programming, and processing. This too must be
protected from malicious mischief. As an example let me use the following well-known example of a
disgruntled application programmer. This individual, who will remain unnamed had not gotten a pay
raise for the last two years, although in this economy thats not uncommon. Since this individual was
responsible for the payroll system, they added some code to the program which generated the
checks to do a simple thing. Each time the net amount ended in $.13 (thirteen cents), a second
check made out to this individuals alter ego would be added to the check run, then direct deposited
to a separate account at an out-of-state bank. Since this didnt happen every payroll if was almost a
16
year before the company discovered the error and still another year before they could identify the
guilty. So as an IT auditor, where is your concern? Unauthorized software changes, lack of change
management, lack of reconciliation (wait a minute thats the financial auditors job), separation of
duties (the individual had to add his own alter ego employee record to the master file and add the out-
of-state bank direct deposit). So you can see some of the concerns when it comes to software,
programming and processing.

Distributed systems and client/server technology offer the IT auditor some distinct challenges when it
comes to CIA (Confidentiality, Integrity, and Availability). Take for example a point-of-sale system in
a retail store; and lets suppose that the POS system allows for data entry even when connectivity to
the host server at home office is interrupted. How do you as an IT auditor ensure confidentiality of
the data (customer paid with a credit card) when the data is transmitted once the home office system
comes back online? How do you ensure integrity of the data being transmitted and last but not least
what do you need to check to make sure the local store system is available if the home office system
goes down? These are just a few of the considerations you as an IT auditor will need to be familiar
with in a distributed environment and in a client/server architecture. Just as an example of how easy
it is to social engineer a distributed system, consider this example. In the shoe department of a
retailer, the store clerk is signed on to the cash register; the customer asks the clerk to get a specific
size and style from the back room and states they are in a hurry and flashes a wad of cash, stating
Theres an extra $20 if you can hurry. The clerk literally runs to the back room, but forgot to sign off.
When they come back, not only is the customer gone, so is the cash from the cash drawer. The IT
audit concern? The obvious one here is security awareness training.

Youll hear a lot about man-in-the-middle (MITM) attacks as they relate to network connectivity and it
represents a real security issue. But thats just one aspect of network connectivity. Another better
even more common basic security issue is remote access. With the price of gasoline approaching
$4.50/gallon a lot of employee are putting pressure on their bosses to let them work from home, to
access the system remotely, and to let them take their company laptop home with them so they can
work more efficiently. OK, so put on your IT auditor hat and lets look at some issues:
Was remote access approved?
Is remote access via an encrypted communication link?
Is the laptop protected (key lock, hard disk encryption)?
Is there a screen saver and is it password protected?
Is two-factor authentication required to access the network?
Is network access restricted from known locations?
If modems are used is call-back employed?

When we talk about IT system maintenance, patch management, and security, we speak of change
management and configuration control. Are the systems being maintained and are patches being
applied (after they have been tested of course) in a timely manner? What is the security that
surrounds system maintenance? Can anyone, for example, update the anti-virus definition file? Who
checks to see if this is done, assuming that the end-user is the one responsible for updating the .dat
file? And the most basic and fundamental question of all, Do all and I repeat ALL changes go
through change management?

Remember, your IT technology audit strategy is to look at what the company says they are going to
do; then perform an audit to see if they are in fact doing what they said they were going to do;
including asking the company or auditee to prove that they did the action and then to report any
discrepancies to management. However, you should also keep in mind that it might be in the

17
companys best interest if you include in your report if something is not being done and it could
potentially affect the confidentiality, integrity, and availability of the companys systems and data.
Just because a company says, were not going to review login attempts because its a waste of time,
doesnt mean you shouldnt point out the risk of not doing this activity. After all, isnt that what IT
auditing is all about making management aware of the risks they are taking by doing or not doing a
particular action?

Internet and Web Technology

This article is going to attempt to tread the fine line between IT Auditing and Penetration Testing.
Remember as an IT Auditor, it is your job to ask the client to tell you what they are doing, then to ask
them to show you that they are in fact doing what they said they were going to do, and then to follow
that with testing to ensure that what they did was effective and efficient.

As a sample network architecture for Web-based applications, we might find the following:
What we see here is that the organization has placed a border router or edge router on the periphery
of their network. The next device that we see is a firewall which is configured to allow web traffic to
only go to the web server in the DMZ. The web server in the DMZ then communicates with the data
server in the internal network, retrieves the requested information and then sends it back to the user
on the internet. While you may ask about the other two servers in the DMZ, which might be an
Exchange server or a DNS server, this article will only look at the Web Server sitting in the DMZ.

So as an IT auditor lets examine (read that as audit) this diagram from an IT auditors perspective. A
typical conversation between the IT Auditor (John) and the client (Jane) could go something like this:

John: How did you architect your web application environment to protect your systems and data with
respect to confidentiality, integrity, and availability?

Jane: We placed a border router at the edge of our network to filter traffic, blocking unwanted inbound
traffic and stopping unauthorized outbound traffic.

Jane: We then placed a firewall immediately behind the border router and only allow inbound web traffic
on ports 80 and 443 and only to the destination IP address of the web server sitting in the DMZ. We also
added NATd to prevent an outsider from knowing the real IP Address of the internal network. The web
server is only allowed to communicate with the database server as this communication goes through
another set of ACEs (Access Control Entries) in the firewall configuration. The database server returns
the information only to the IP ADDR of the web server.

John: Show me the configuration files of the border router and the firewall.

John: How do you know that the configuration files are blocking and routing traffic according to the ACEs
in the configuration file?

Jane: We are using a third party tool called WireShark and sending packets designed to test the ACEs to
ensure they are working as designed.

John: Show me the WireShark reports.

If you follow the logic of the audit questions, you will notice that John is going down the road until he
has gathered sufficient evidence to state that the border router and firewall configurations in his
opinion are configured to perform as designed and meet industry best practices for firewall
configuration design. John might go on to state that he is using NIST SP 800-41 Guidelines of
Firewalls and Firewall Policy as his source of reference for industry best practices.

18
Just from the conversation above you will have already identified several risks, but let me point out
just a few:
Incorrect router/firewall configurations (not according to organization specifications)
Inadequate configurations (do not work as designed)
Ability for remote users to bypass the border router and firewall and get direct access to the
database server (e.g. via a modem installed for support)
Ability to spoof the internal IP Address and bypass the web server
Internal users who have malicious intent and by being internal do not go through the firewall
and/or border router
System administrators having unlimited direct access to the database
Developers not being adequately trained in secure coding techniques for web application
development

Some of the more obscure insider abuses could be things such as:
Collusion between an insider and an outsider (to wit, I (outsider) place an order for 3 new 53
color TVs, and my partner (insider) goes in and adjusts the item price from several thousand
dollars to $0.33 each. When the order is invoiced I pay $0.99 for 3 new 53 color TVs.
Unauthorized access by insider (maybe I change the delivery location to be my apartment,
instead of the real customers location)
Unauthorized customer record access (an insider can change the designation from customer
to employee, thereby entitling the order to receive the 25% employee discount).
Uncontrolled changes enough said
I talked a little about the network perimeter security above mentioning border/edge routers and
firewall and NAT (Network Address Translation). With all of these, you as an IT Auditor need
to remember your basic function in life is to ask the client to tell you what they are doing, then
ask them to show you they are doing what they said they were going to do and then to ask
them if it is effective and efficient. Once youve got all that information, it is also your job to
advise management of the risks involved with a particular design.

For example, if you look at a network design and you do not see any border router and no firewall and
the web server is connected directly to the internet, it is your job to advise management of the risks
associated with that design. It is NOT your job to re-design the network. Management, in their
infinite wisdom may choose to accept your advice, or they may choose to disregard your advice but
thats a whole another discussion.
Ive covered some of the risks and I want to mention just a couple of safeguards. First, as an IT
auditor you should be able to look at a network design and determine whether the architecture is
effective at protecting the confidentiality, integrity and availability of the systems and data or whether
it is not. You should also be prepared to demonstrate to management why the design is flawed. So
go download a couple of the open source tools, take the Web App Pen Testing course and do some
reading, so that you are familiar with and can demonstrate design flaws if asked. Second, as an IT
Auditor you should be able to look at a developers skill set, training, and coding examples to
determine if they are proficient in Secure Coding. If you say they are inadequately trained, you
should be able to substantiate that statement with examples from their code or by the demonstrated
lack of training. Again heres where the Web App Pen Testing course will come in handy for you.

For audit strategies for Internet and Web application, you will want to look for layered defense or
defense in depth. Routers, followed by firewalls, followed by DMZ, followed by NAT, accompanied by
NIDS and NIPS (Network Intrusion Detection system, Network Intrusion Prevention system), an
19
application firewall in front of the database server and maybe even HIDS and HIPS (host based
intrusion detection and prevention). And thats just the network defense. Well cover software and
hardware layered defense in a later article. And weve just briefly talked about people defense, that
is, training, training, training

Shared General Controls

Later on in this article, well talk about Business Impact Analysis (BIA) and its place within the
organization. At this point, when we want to talk about logical security, the BIA must have already
been completed; the system and data owners identified; and the primary and supporting assets
identified.

You will recall that the primary assets consist of two elements: 1) Business processes & activities and
2) Information. Its this second element which drives logical security and that, put simply is;
How is the access to the information to be controlled?
How is it to be secured?
Or even more basically, What is the logical security for this business process?

So lets look at logical security from an IT auditors perspective. As a starting point, in the auditors
interview of the client, they might state something like; Show me your most recent Business Impact
Analysis. Just as an aside notice that the auditor didnt ask, Do you have a Business Impact
Analysis? The last question is a simple yes/no question and can be responded to by the client with a
simple yes or no. The auditor did say Show me which requires the client to produce the BIA or to
state that one doesnt exist.

Just a couple of quick words about the BIA. Every organization should go through a process of
identifying all the business processes. Then once they have identified the processes they need to
identify the assets that support that process, both primary (processes and information) and secondary
(hardware, software, network, people, site and organization). Then they will need to identify the
criteria which determines whether the process is sensitive or not and do a process profile where they
identify key players like system owner, data owner, system administrator, data custodian and the like.
Then they will need to classify the data according to sensitivity not forgetting legal requirements
and they will wrap it up with the recovery time objective, recovery point objective and the system
boundary (who the system or data is shared with).

The next thing the IT auditor might say would be something like; I see in your BIA you have identified
Payroll as a business process. Show me the data classification which you did for all the data
elements within the Payroll process. Again notice the format of the question; state the obvious,
Payroll is a business process and then follow that with an action statement not a yes/no question.
In this case, again, Show me the data classification

Speaking of data classification, you as an IT auditor will also need to look at HOW the data
classification was done and how the data elements are classified. This is where your professional
judgment comes into play. You might want to consider having a copy of NIST SP 800-60 so that you
can cite industry best practices for classification of data.

Now that youve seen the data classification, what should you look for? The obvious next question is
logical access control. You should be saying things like, Show me the roles and responsibilities you
have established for the people who have access to the payroll information. And from this
information, you would ask, Show me who has access to each of these defined roles. From that
20
information you should be able determine if there is adequate separation of duties. Be sure to follow
this up with the question of, Show me which IT staff have access to the data files and what their
rights are. What were looking for is who, from a system point of view, has rwx or full control access
to the data.

Lets keep talking about access control for a few more lines, but lets bring encryption into the picture.
Access can be logical or physical and when it is logical it can be local or remote. In either of the
cases, that information needs to be protected while at rest and while in transit.

From an IT audit perspective lets look at just the remote logical access for a moment. Lets say that
when you look at the BIA you notice that part of the boundary statement includes remote access by
payroll administrative staff. Your question might take the form of, How is the information that is
accessed remotely by the payroll administrative staff encrypted? Here again I want you to notice the
particular framing of the question. Youre not asking if the data is encrypted which would be a yes/no
question but how is it encrypted. That requires the client to explain. Now Im sure at some point
someone will say they arent encrypting the data and that will cause you to go down a whole set of
other questions, but for this article, lets assume that the client says they are using CISCO VPN and
SecurID from RSA. So think for a second before you read on, what questions would you ask? Lets
look at VPN first:
Is the CISCO VPN client installed on company owned equipment or on the users personal
equipment (the risks are different)?
Is the CISCO device IOS current?
Who maintains the VPN configuration?
Where does the VPN tunnel terminate within the clients network and what are the protections
between the end of the tunnel and the payroll data files?

Nows lets look at some questions for SecurID from RSA.

Who controls the RSA server configuration?
Who controls the RSA SecurIDs?
Are you aware of the recent RSA data breach and what steps are you taking to address the
compromise announced by Lockheed?

That addresses the data while in transit, now lets see what we might ask to determine if encryption
is used for at rest data.
Do the remote devices have hard disk encryption installed?
What encryption standard is used for the payroll application data files?
How are hard copy documents which contain payroll data protected?

This should give you an idea of some questions to ask regarding encryption.
Lets stay with the payroll BIA process for a while longer and look at change management. What are
you concerned with? This is a real easy one any and all changes go through change control
period end of story. No exceptions. Not only do all changes go through change control, they need
to be tested, prior to being implemented into production and the changes need to be approved by
management, scheduled to be implemented at the appropriate time, etc. And if you have a COTS
payroll package (common off-the-shelf), then youll also need to make sure that the system has a
patch management process in place, and yes patches are changes and they too must go through
change control.

21
Can you imagine what management would say if the payroll manager said to their boss, The payroll
system is down and we wont be able to run payroll this pay period and it looks like it will be several
days/weeks/or a month before were back online. The boss is probably going to start firing people
indiscriminately starting with the payroll manager, most of the IT department, and then coming looking
for you the IT auditor because you didnt make them aware of the risk associated with not having a
BCP/DRP.

So lets get you some questions, so you dont have to worry about losing your job because you forgot
this area. The first question should be, Show me your current Business Continuity Plan and your
current Disaster Recovery Plan. And as soon as the client hands you those plans say, Now show
me the tests results of your most recent tests of the BCP and the DRP. And follow that without even
taking a breath by saying And also show me what you documented as Lessons Learned and where
the changes are to reflect those lessons learned in the BCP and DRP.

If the client doesnt have either of those plans or if they havent tested them, then you should
immediately make the payroll managers boss know, because this is one of those situations where
you have identified a risk that needs to be communicated immediately and not after the final audit
report is written. Be careful how you communicate, you dont want to be over zealous. Be calm and
state the facts, I have identified a significant deficiency within the payroll application which
represents a risk to the organization. What I have identified is there is no contingency plan in place
for processing payroll should the system which supports payroll become unavailable.

The payroll manager should hear this first and you should ask if the finding is correct. If the payroll
manager says the finding is correct then you need to say to the payroll manager that it represents a
significant deficiency and you have to report this to senior management as soon as possible. You
could even ask the payroll manager to call their boss to schedule the appointment and to accompany
you when you tell senior management. Im sure senior management will be more than just a little
concerned to find out they might not be getting paid.

So the last few lines cover a little of the audit strategy and hopefully sheds some light on some of the
shared general controls and IT audits involvement. Let me take just a few sentences and talk about
application control.

Application control, and in particular the payroll business process which I have been writing about is
a very good example to look at some basic application controls. I will not be discussing all the
application controls which deal with internal program calculations for taxes or net pay for those would
be more appropriate for the Financial Auditor, rather I will address only the access to the application.
For example, some of the things you want to look at are who has access to the source code; do all
changes go through change management; are all changes tested before being put into production; do
application developers have access to production source code; is there separation of duties when it
comes to test changes and moving source code between the development, test, and production
libraries; are changes logged (automatically); is QA performed on the changes; are the changes
current (in payroll, tax changes are time sensitive); is access to the production application data
restricted such that developers do not have access; if production data is used to populate the
development and test instances, is it sanitized before being used?

When I talk about application control, I would be remiss if I didnt at least mention the application
development environment. Some application departments are small (as in a single programmer I
have a client who has a staff of one), and some are very large where separation of duties is not even
an issue. Its in the smaller shops that you will need to be more cognizant of when youre doing your
22
application audit and remember that while it may appear they arent doing something, always ask if
there are compensating controls which you might see at first that would answer one of your
questions.

Application controls refers to the transactions and data relating to each computer-based application
system and are, therefore, specific to each such application. The objectives of application controls,
which may be manual or programmed, are to ensure the completeness and accuracy of the records
and the validity of the entries made therein.

Application controls are controls over the input, processing, and output functions. From the 30,000
foot view they include things like:
Ensure the input data is complete, accurate and valid
Ensure the internal processing produces the expected results
Ensure the processing accomplishes the desired tasks
Ensure output reports are protected from disclosure

From the close inspection view they include such things as:
Edit tests
Control totals/batch balancing
Reconciliation of accounts
Exception handling

Both automated controls and manual procedures should be used to ensure proper coverage. These
controls help ensure data accuracy, completeness, validity, verifiability, and consistency, and thus
ensure the confidentiality, integrity and availability of the application and its associated data.

So what is an application? Since, as weve said before, it is a computer-based system which

processes data for a specific business purpose. Lets give a few examples of some application
systems:
General Ledger Distribution Requirements Planning
Fixed Assets (DRP) and no thats not Disaster
Inventory Control Recovery Plan
Sales Human Resources
Manufacturing Resource Planning And, everyones favorite Payroll
(MRP)

Business applications have the same three basic risks as any other system which handles data and
they are confidentiality, integrity and availability.

Confidentiality from the point of view of a data breach or a release of data in violation of legal
regulations such as the Federal Privacy Act or FERPA or HIPAA.

Integrity from the point of view that the data can be relied upon for accuracy and availability from the
point of view that the data is available when it is needed.
When we talk about input controls for applications we must look at:
Input Authorization
Batch Controls and Balancing
Error Reporting and Handling
Batch Integrity in Online or Database systems
23
Authorization of input is just that, the data has been properly authorized to be input into the
application system. There are a number of different things to look for here, primarily things like
signatures on batch forms; online access controls; unique passwords; workstation identification and
source documents. In batch controls and balancing we might look at total monetary amount; total
items; total documents and hash totals. And specifically with batch balancing when some of the input
might be manually we want to make sure the manual totals are in agreement with the computer totals.
In error reporting and handling, we want to look for controls that determine what happens to a batch
that has an error, do we reject only the transaction; do we reject the whole batch; do we hold the
batch in suspense pending correction or do we just process the batch and flag the error? Some of
the input control techniques include things like a transaction log; reconciliation of data;
documentation; error correction procedures; anticipating; transmittal log; and cancellation of source
documents.

In processing controls we look at:

Data Validation and Editing Procedures
Processing Controls
Data File Control Procedures

For data validation, think SQL injection, and now you have a very clear picture of just one of the many
data validation edits. Data validation is meant to identify data errors, incomplete or missing data and
inconsistencies among related data items. Editing procedures are preventive controls designed to
keep bad data out of your database. ISACA lists several Data Validation Edits and Controls among
them are:
Sequence check Existence check
Limit check Key verification
Range check Check digit
Validity check Completeness check
Reasonableness check Duplicate check
Table lookups Logical Relationship check

Processing controls are there to ensure that the incoming data is processed according to Hoyle. No
Im not being facetious, as Hoyle established rules for playing cards and other games, so too, do
business process owners establish rules for how particular data is to be processed through the
application. Some of these processing controls include run-to-run totals; limit checks; and
reasonableness verification of calculated amounts.

In data file control procedures we look at such questions as, Are you sure the master file was
updated correctly? To this you would respond, We made a before image copy of the database, then
ran the update, and then ran an after image copy. We then compared the two images and yes the
update performed as expected. You will also run into the following other types of data file controls:
Parity checking File updating and maintenance
Transaction logs authorization
Version Usage

In output controls, the biggest concern is; Did the information distributed get to the appropriate
recipient? So as an auditor you will need to ask the questions; Where was the sensitive report
printed? Was distribution controlled? How long are the sensitive reports retained and are they stored

24
in a protected environment? And by that I mean are they protected from disclosure? (Thats another
name for confidentiality.)

The online world of transactions and databases present another and slightly different challenge for
applications. Since databases consist of many tables all interrelated, the updating is not just a single
table but several tables. Think commit and rollback, think failure during midstream, think I need to
recover. So how do we do that? We first write the transaction to a transaction log file and then we
start updating all the different tables. Once all the tables are updated successfully (atomicity), we set
a flag in the transaction log to say that particular transaction has been successfully applied. The
question becomes how long to keep the transaction log file and where should it be backed up?
These questions can best be answered by looking at the business impact analysis for the business
process, finding the supporting applications and then finding the recovery point objective (RPO) and
recovery time objective (RTO). For example, if you look at the RPO and find that the business
process owner has indicated a zero tolerance for data loss, you can be assured that transaction
logging will be taking place and that transaction logging will most probably be being mirrored to a hot
site. As an IT auditor it is your responsibility to determine if the application controls in place, satisfy
the requirements of the RPO and RTO in the business impact analysis.

A few other areas of concern for application control are how changes to data normally are controlled?
Normally they are through the application, however this needs to be checked. Application access
control mechanisms and built in application controls normally prevent unauthorized access to data.
These controls can be circumvented by direct access to data. For this reason, direct access to data
(specifically, write, change, and/or delete access) should be restricted and monitored.

So how do you test an application? There are a variety of techniques and my favorite is to write my
own Test Data and then run it through the Production system. But in order to accomplish this you
will need to insure the existence of an ITF (Integrated Test Facility). And lets not forget SDLC in our
discussion. When should you begin testing an application? As an auditor you will want to make sure
that you begin your testing of the application as soon as individual units are finished, and you can call
that pre-integration testing.

Applications are here to stay, some large (SAP, PeopleSoft) and some small (QuikBooks) but there
will always be applications and there should always be auditors to check that the controls are in place
to ensure CIA.

There are five different Online Auditing Techniques for online applications. They are:
Systems Control Audit Review File and Embedded Audit Modules (SCARF/EAM)
Snapshots
Audit hooks
Integrated Test Facility
Continuous and Intermittent Simulation

You would use SCARF/ERM when the complexity is very high and regular processing cannot be
interrupted. An ITF would be used when the complexity is high and it is not beneficial to use test
data. Snapshots give you an audit trail like taking a lot of snapshots and placing them end to end to
get a movie. CIS is for medium complexity when you have transaction meeting certain criteria which
need to be examined and audit hooks are for those low complexity tasks when you only need to look
at selected transactions or processes.
Infrastructure General Controls

25
For this last article on IT Auditing and Controls, I want to focus on information systems operations. Ill
talk a little about Management of IS Operations; IT Service Management; Infrastructure Operations;
Monitoring the Use of Resources; Change Management Process; Quality Assurance; and finally
Media Sanitization.

When we look at Management of IS Operations from an auditing perspective, we typically look at

three different areas; resource allocation; standards and procedures; and process monitoring. So
what are the roles and responsibilities of IS Management, IS Operations, and Information Security
from a management control viewpoint?

IS Management is really responsible for ensuring adequate resources are allocated to support IT
Operations. Theyre also responsible for planning the most efficient and effective use of those
resources; authorizing and monitoring IT resource usage based on corporate policy and monitoring
operations to ensure compliance with standards and procedures.

So as an IT auditor what should you be looking for? To see if IS Management is in fact doing the
things we just mentioned and can they provide proof that they are monitoring operations. IS
Management should be able to provide a timeline which includes monitoring activities and corrective
action taken to correct deviations from corporate standards, following by a repeat of the cycle, which
means theyre monitoring the corrections and taken additional corrective action if necessary.

IS Operations on the other hand has considerably more things to focus on than IS Management, in
that they are the ones responsible for the day-to-day running of IT operations. For example, they are
responsible for:
Job schedules Planning for equipment
Authorizing changes to job schedules replacement/upgrades
Reviewing changes to the network, Maintaining job accounting records and
system and applications audit trails
Ensuring that those changes do not Reviewing logs
negatively impact the normal processing Managing incidents
Monitoring system performance and Ensuring disaster recovery, regardless
resource utilization of the scale of the disaster
Monitoring SLAs

What I look for when auditing IS Operations are four things, job schedules and are they being
followed; SLAs and are they being monitored and reported; incidents and are they being recorded
and managed; and disaster recovery, specifically is the backup media valid? In other words could a
system be restored from the backup media, has it been tested?

Information Securitys role is to ensure that confidentiality, integrity and availability of data is
maintained. In addition, this groups role includes:
Monitoring the environment and security of the facility
Making sure that vulnerabilities are identified and resolved in a timely manner
Ensuring that security patches are identified and installed
Limiting logical and physical access to IT resources to those who require and are authorized to
access it

26
The basic auditing question here, is, are they doing the things that are included in their roles and
responsibilities? Remember as an IT auditor you need to Pull the Thread and see where it leads.
For instance, in this case you would ask if they are ensuring that security patches are identified and
installed. If they say NO then it becomes your responsibility to find out why. Is it because that
role/responsibility is not in their job description? Or is it because they dont have the resources
(training) to do that role? Or is it simply that they arent doing it? Remember Root Cause Analysis
because when you make your audit report and you state that Information Security is not ensuring that
security patches are identified and installed, you will need to also need to state what you found the
root cause to be, and thus have a basis for your recommendation. You might find that it wasnt in
their job description in which case you would state that and recommend that the job descriptions be
updated, the people trained, and that a follow-up audit be performed in 90 days to determine if
corrective action has been taken.

From an IT Service Management perspective the primary thing we want to look at are the service
level agreements (SLA) and whether performance is being measured and reported against the
requirements stated in the SLA. Some sources of information to consider in auditing this area might
include; exception reports, system and application logs, operator problem reports, and operator work
schedules.

Infrastructure operations are processes and activities that support and manage the entire IT
infrastructure, systems, applications and data, focusing on day-to-day activities. Some of the tasks
that you would expect IT operations staff to preform would be:
Executing and Monitoring scheduled jobs
Making sure backups run successfully
Participating in disaster recovery tests
Facilitating troubleshooting and incident handling

While this is not an exhaustive list, it does highlight some key areas of IT operations, namely daily
execution of the schedule, making sure backups are successful and handling incidents.

Monitoring use of resources includes a number of different things including authorized use, logging of
events, incident handling and problem management. When operations monitors the use of
resources, my experience has been that they are looking for anomalies, something out of the
ordinary; a file that runs out of disk space; a job that runs much longer than expected; a job that
aborts; a user that constantly calls to have their password reset; and so forth. All of these errors
should be logged regardless of whether they are application, system, operator, network,
telecommunication, hardware, or user errors.

So as an IT auditor some of the things you would expect to find in the error log would be:
Error date Status
Error code Resolution description
Error description Escalation date and time
Source of error
Initials of the individual responsible for
the entry and for the review of the entry

In the change management area, suffice it to say, nothing gets changed without management
approval (in writing). Nothing gets changed directly in production without having gone through test
and no programmer should have access to production. Now I realize that this is not always possible,
27
and in situations where shops are small and this isnt possible there should be compensating controls
which the IT auditor will need to look for. There should be a documented change
management/configuration control process which includes management sign-off. As a personal note,
I also require business process owner sign-off on all changes. How else are we going to align IT and
the business if the business process owner doesnt know what changes are being made to their
application? One of the easiest ways of ensuring integrity is to insert a QA (quality assurance) group
between development/test and production. And by assigning roles specific to the QA group you can
establish controls over who has access to production systems, data, and files and you can control
when changes are made and whether they have been properly authorized.

One final parting comment on infrastructure general controls that everyone seems to leave to the last,
and that is Sanitization or what happens when we no longer need that data, system, application or
piece of hardware. As an IT auditor you will want to make sure that the organization has a process in
place to remove all sensitive data before a piece of equipment is recycled or disposed of in any form.
It has been my experience to see the best (actual shredding of hard drives) to the not so good
(running the QUICK FORMAT command) when it comes to data sanitization. The most fun Ive had
with sanitization is the time when I was told that We recycle our computers to a local school and we
ask them to format the hard drive before they let the students use the computers.

Database Technology and Controls

A simple definition for what a database management system (DBMS) is, would be that it is a complex
set of software programs that control the organization, storage and retrieval of data in a database. It
also controls the security and integrity of the database.

This article will not attempt to give a detailed explanation of database technology, rather it will serve
to introduce the IT auditor to some of the concepts that will be necessary to be understood and
performed to support an audit of a DBMS.

But first, in order to understand DBMS there is some database terminology and definitions you will
need to understand:
Concurrency Control Refers to the class of controls used in database management systems
(DBMS) to ensure that transactions are processed in an atomic, consistent, isolated and
durable manner (ACID). This implies that only serial and recoverable schedules are permitted,
and that committed transactions are not discarded when undoing aborted transactions.
Data Structure The relationships among files in a database and among data items within
each file.
Database A stored collection of related data needed by organizations and individuals to meet
their information processing and retrieval requirements.
Database Administrator (DBA) An individual or department responsible for the security and
information classification of the shared data stored on a database system. This responsibility
includes the design, definition and maintenance of the database.
Database Specifications These are the requirements for establishing a database application.
They include field definitions, field requirements, and reporting requirements for the individual
information in the database.
Foreign Key A foreign key is a value that represents a reference to a tuple (a row in a table)
containing the matching candidate key value (in the relational theory it would be a candidate
key, but in real DBMS implementations it is always the primary key). The problem of ensuring
that the database does not include any invalid foreign key values is therefore known as the

28
 referential integrity problem. The constraint that values of a given foreign key must match
values of the corresponding candidate key is known as a referential constraint. The relation
(table) that contains the foreign key is referred as the referencing relation and the relations that
contain the corresponding candidate key as the referenced relation or target relation.
Normalization The elimination of redundant data.
Repository The central database that stores and organizes data.
Transaction log A manual or automated log of all updates to data files and databases.
Tuple A tuple is a row in a database table.

When we speak about Database Management Systems (DBMS), there are three basic types:
Hierarchical a database structured in a tree/root or parent/child relationship. Each parent
can have many children; however, each child may have only one parent.
Network the basic data modeling construct is called a set. A set is formed by an owner
record type, a member record type and a name. A member record type can have that role in
more than one set, so a multi-owner relationship is allowed. An owner record type can also be
a member or owner in another set. Usually, a set defines a 1:N relationship, although one-to-
one (1:1) is permitted. A disadvantage of the network model is that such structures can be
extremely complex and difficult to comprehend, modify or reconstruct in case of failure.
Relational This model is based on the set theory and relational calculations. A relational
database allows the definition of data structures, storage/retrieval operations and integrity
constraints. In such a database the data and relationships among these data are organized in
tables. A table is a collection of rows, also known as tuples, and each tuple in a table contains
the same number of columns. Columns, called domains or attributes, correspond to fields.
Tuples are equal to records in a conventional file structure.

Relational tables have the following characteristics:

Values are atomic
Each row is unique
Column values are of the same kind
The sequence of columns is insignificant
The sequence of rows is insignificant
Each column has a unique name

Some of the advantages of the relational model over the hierarchical and network model are that it is
easier:
For users to understand and implement a physical database system
To convert from other database structures
To implement projection and join operations
To create new relations for applications
To implement access control over sensitive data
To modify the data base

When auditing the controls of a database, the auditor would check to see that the following controls
have been implemented and maintained to ensure database integrity and availability:
Definition standards
Data backup and recovery procedures
Access controls
Only authorized personnel can update the database

29
 Controls to handle concurrent access problems such as multiple users trying to update the
same record at the same time
Controls to ensure the accuracy, completeness and consistency of data elements and
relationships.
Checkpoints to minimize data loss
Database re-organizations
Monitoring database performance
Capacity planning
Who can access the database without going through the application?

When we speak of who can access the database, we have already identified one of the major audit
concerns and that is what access does the DBA have? As everyone knows the DBA basically has
the keys to the kingdom and can do (read, write, change, delete) anything. What you have to make
sure of is that someone is watching. Someone is monitoring (logging) the actions the DBA takes.
And the DBA, doesnt have the ability to de-activate the log nor do they have access to the log.

It goes without saying that Access Control is the number one issue with database management
systems. That being said lets not forget to audit disaster recovery and restoration, patch
management, change management, incident logging and all the other issues an auditor should look
for.

There is another issue that auditors need to deal with when auditing DBMS and that is to perform
some type of data integrity testing. Data integrity testing is a set of substantive tests (NOTE:
Substantive not Compliance testing) that examines accuracy, completeness, consistency and
authorization of data presently held in a system. There are two common types of data integrity tests;
relational and referential. Relational integrity tests are performed at the data element and record-
based levels. It is enforced through data validation routines built into the application or by defining
the input condition constraints and data characteristics at the table definition in the database stage.
Sometimes it is a combination of both.

Referential integrity test define existence relationships between entities in different tables of a
database that needs to be maintained by the DBMS. Referential integrity checks involve ensuring
that all references to a primary key from another table actually exist in their original table.

With respect to data integrity in online transaction processing systems there are four online data
integrity requirements known collectively as the ACID principle. For those of you that are old enough
to remember ACID, congratulations, your brain isnt completed fried.

The A stands for atomicity and from a users perspective, a transaction is either completed in its
entirety or not at all.

The C stands for consistency. Basically, all integrity conditions in the database are maintained with
each transaction, taking the database from one consistent state into another consistent state.

The I stands for isolation. Each transaction is isolated from other transactions and hence each
transaction only accesses data that are part of a consistent database state.

The D stands for durability. If a transaction has been reported back to a user as complete, the
resulting changes to the database survive subsequent hardware of software failures.

30
As a parting comment, I would be remiss, if I didnt mention how the database was populated in a test
environment. As many times as I have audited databases, I have found that the production
environment was being copied to the test environment to ensure an accurate copy so that changes
would not fail once they were moved to production. At least that was the logical in the clients
explanation. What they fail to realize is that the security controls in test are significantly weaker that
they are in production and yet there is a mirror unprotected copy sitting there for all to see.

At least as an auditor, you should recommend that the data be sanitized before being used in test.

31