IT Auditing, Second Edition Reviews
“This guidance will enable an auditor to properly determine the scope of the control
environment and residual risks. The authors present the information in an easy-toconsume but comprehensive format that generates both thought and action.”
—Kurt Roemer, Chief Security Strategist
Citrix
“IT Auditing, Second Edition is a must-have resource for auditors in today’s complex
computing world. This book is filled with the essential how-to guidance necessary to
effectively audit today’s technology.”
—Shawn Irving, Sr Manager IT Security Standards & Compliance
Southwest Airlines – Information Technology
“Traditional IT audits have focused on enterprise systems using enterprise-based tools. As
enterprise systems move to outsourced and cloud-based services, new cloud-based tools
are needed to audit these distributed systems. Either enterprise vendors will rewrite their
tools to address cloud-based systems or new and existing cloud-based tools will be used
to assist auditors with these distributed systems. The book gives good insights on how to
address these new challenges and provides recommendations on auditing cloud-based
services.”
—Matthew R. Alderman, CISSP, Director, Product Management
Qualys, Inc.
“An essential contribution to the security of Information Systems in the dawn of a
wide-spread virtualized computing environment. This book is crucial reading for anyone
responsible for auditing information systems.”
—Peter Bassill CISSP, CITP
ISACA Security Advisory Group and CISO of Gala Coral Group
“We used the first edition in the graduate IT Audit and Risk Management class during
the past year, and it was an outstanding resource for students with diverse backgrounds.
I am excited about the second edition as it covers new areas like cloud computing and
virtualized environments, along with updates to reflect emerging issues. The authors have
done a great job at capturing the essence of IT risk management for individuals with all
levels of IT knowledge.”
—Mark Salamasick, Director of Center for Internal Auditing Excellence
University of Texas at Dallas School of Management
“This book is indispensible. It is comprehensive, well laid out, and easy to follow, with
clear explanations and excellent advice for the auditor. This new edition is timely and will
be particularly useful for those encountering the latest developments of the industry as it
continues to evolve.”
—Mark Vincent, CISSP
ISO for Gala Coral Group
This page intentionally left blank
IT Auditing: Using
Controls to Protect
Information Assets
Second Edition
Chris Davis
Mike Schiller
with Kevin Wheeler
New York • Chicago • San Francisco • Lisbon
London • Madrid • Mexico City • Milan • New Delhi
San Juan • Seoul • Singapore • Sydney • Toronto
Copyright © 2011 by The McGraw-Hill Companies. All rights reserved. Except as permitted under the United States Copyright Act of 1976, no
part of this publication may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without the
prior written permission of the publisher.
ISBN: 978-0-07-174239-9
MHID: 0-07-174239-5
The material in this eBook also appears in the print version of this title: ISBN: 978-0-07-174238-2,
MHID: 0-07-174238-7.
All trademarks are trademarks of their respective owners. Rather than put a trademark symbol after every occurrence of a trademarked name,
we use names in an editorial fashion only, and to the benefit of the trademark owner, with no intention of infringement of the trademark. Where
such designations appear in this book, they have been printed with initial caps.
McGraw-Hill eBooks are available at special quantity discounts to use as premiums and sales promotions, or for use in corporate training
programs. To contact a representative please e-mail us at bulksales@mcgraw-hill.com.
Information has been obtained by McGraw-Hill from sources believed to be reliable. However, because of the possibility of human or
mechanical error by our sources, McGraw-Hill, or others, McGraw-Hill does not guarantee the accuracy, adequacy, or completeness of any
information and is not responsible for any errors or omissions or the results obtained from the use of such information.
TERMS OF USE
This is a copyrighted work and The McGraw-Hill Companies, Inc. (“McGrawHill”) and its licensors reserve all rights in and to the work. Use of
this work is subject to these terms. Except as permitted under the Copyright Act of 1976 and the right to store and retrieve one copy of the work,
you may not decompile, disassemble, reverse engineer, reproduce, modify, create derivative works based upon, transmit, distribute, disseminate,
sell, publish or sublicense the work or any part of it without McGraw-Hill’s prior consent. You may use the work for your own noncommercial
and personal use; any other use of the work is strictly prohibited. Your right to use the work may be terminated if you fail to comply with these
terms.
THE WORK IS PROVIDED “AS IS.” McGRAW-HILL AND ITS LICENSORS MAKE NO GUARANTEES OR WARRANTIES AS
TO THE ACCURACY, ADEQUACY OR COMPLETENESS OF OR RESULTS TO BE OBTAINED FROM USING THE WORK,
INCLUDING ANY INFORMATION THAT CAN BE ACCESSED THROUGH THE WORK VIA HYPERLINK OR OTHERWISE, AND
EXPRESSLY DISCLAIM ANY WARRANTY, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. McGraw-Hill and its licensors do not warrant or guarantee that the
functions contained in the work will meet your requirements or that its operation will be uninterrupted or error free. Neither McGraw-Hill nor
its licensors shall be liable to you or anyone else for any inaccuracy, error or omission, regardless of cause, in the work or for any damages
resulting therefrom. McGraw-Hill has no responsibility for the content of any information accessed through the work. Under no circumstances
shall McGraw-Hill and/or its licensors be liable for any indirect, incidental, special, punitive, consequential or similar damages that result from
the use of or inability to use the work, even if any of them has been advised of the possibility of such damages. This limitation of liability shall
apply to any claim or cause whatsoever whether such claim or cause arises in contract, tort or otherwise.
Stop Hackers in Their Tracks
Hacking Exposed,
6th Edition
Hacking Exposed
Malware & Rootkits
Hacking Exposed Computer
Forensics, 2nd Edition
24 Deadly Sins of
Software Security
Hacking Exposed Wireless,
2nd Edition
Hacking Exposed:
Web Applications, 3rd Edition
Hacking Exposed Windows,
3rd Edition
Hacking Exposed Linux,
3rd Edition
Hacking Exposed Web 2.0
IT Auditing,
2nd Edition
IT Security Metrics
Gray Hat Hacking,
3rd Edition
Available in print and ebook formats
Follow us on Twitter @MHComputing
REGULATIONS STANDARDS AND GUIDELINES
!CROSS COUNTRIES
OVERLAPPING CONTROLS
7EATHER THE #OMPLIANCE 3TORM
4HE 5NIFIED #OMPLIANCE &RAMEWORK IS THE ONLY
COMPLIANCE DATABASE THAT REDUCES THE REGULATORY
WHIRLWIND TO A MUCH SMALLER SET OF HARMONIZED
CONTROLS THAT CLEARLY SHOW THE MANY POINTS WHERE
GLOBAL STATE AND INDUSTRY REGULATIONS OVERLAP
-EETING YOUR COMPLIANCE REQUIREMENTS
HAS NEVER BEEN THIS STRAIGHTFORWARD
6ISIT OUR WEBSITE AND CHECK OUT THE 5#& FOR &REE
WWWUNIFIEDCOMPLIANCECOM
To *my Sarah* and our wonderful children Joshua, Caleb, and Kelsea.
This project is the culmination of far too many hours away from you.
Thank you for your incredible love and support. I love you!
—Chris
To Steph, Grant, and Kate—this book was possible
only because of your love, patience, and support.
I’m amazed every day by how lucky I am
and by the joy you bring to my life.
—Mike
ABOUT THE AUTHORS
Chris Davis, MBA, CISA, CISSP, CCNP, has trained and presented in information security, forensic analysis, hardware security design, auditing, and certification curriculum
for government, corporate, and university requirements. He was part of the writing
teams responsible for Hacking Exposed Computer Forensics (McGraw-Hill Professional,
2009, 2004), Anti-Hacker Toolkit (McGraw-Hill Professional, 2006, 2003), and the first
edition of IT Auditing (McGraw-Hill Professional, 2006). He also contributed to other
titles, such as Digital Crime and Forensic Science in Cyberspace (Idea Group Publishing,
2006) and Computer Security Handbook, 5th Edition (Wiley, 2009). His contributions
include projects and presentations for PCI-SSC Virtualization Special Interest Group,
ISACA, Spice World, SANS, Gartner, Harvard, Black Hat, CEIC, and 3GSM. He is an
adjunct professor for Southern Methodist University and has enjoyed positions at
Accudata Systems, ForeScout, and Texas Instruments. Chris holds a bachelor’s degree in
nuclear engineering technologies from Thomas Edison State College and a master’s in
business from the University of Texas at Austin, where he specialized in information
security. Chris served eight years in the U.S. Naval Submarine Fleet onboard the
“special projects” submarine NR-1 and the ballistic missile submarine USS Nebraska,
where delivery was guaranteed in 30 minutes or less.
Mike Schiller, CISA, has more than 15 years of experience in the IT audit field, including positions as the worldwide IT audit manager at Texas Instruments (TI) and as the IT
audit manager at The Sabre Group. He is an active speaker on IT auditing, including
conferences such as CACS, InfoSec World, and ASUG (Americas’ SAP Users’ Group),
and has been an instructor of IT audit curriculum at Southern Methodist University.
Mike is currently a leader of IT operations at Texas Instruments, with responsibility for
the company’s server, database, and storage infrastructure organization. He also has led
departments such as the company’s data center operations, IT asset management, central help desk, web application support, and PC support functions. In addition to his
years of experience in corporate management, Mike is also involved in leadership at his
church, Richardson East Church of Christ. He has a bachelor’s degree in business analysis from Texas A&M University. Mike enjoys watching baseball in his spare time and
has attended games in every major league stadium. His baseball allegiance is to the
Texas Rangers and Cincinnati Reds. Mike’s son, Grant, is a well-known baseball blogger
(see http://texasrangerstrades.blogspot.com) and was named 2005 Texas Rangers Fan
of the Year. Mike’s daughter, Kate, is a soon-to-be-famous artist.
About the Contributing Authors
Stacey Hamaker, CIA, CISA, is the president of Shamrock Technologies, which provides enterprise-class IT consulting to Fortune 500 companies, midsized firms, and the
public sector. Stacey has been heavily involved in regulatory compliance initiatives
since the inception of the Sarbanes-Oxley Act of 2002. She serves on the board of the
North Texas chapter of ISACA (formerly Information Systems Audit and Control Association) and is active in the Institute of Internal Auditors (IIA). Her numerous articles
on Enterprise and IT Governance have been published in such industry publications as
the IS Control Journal. Stacey’s speaking engagements span local, national, and international venues. She received her MBA in MIS from the University of Texas at Arlington
and her undergraduate degree in accounting from Marietta College in Ohio.
Aaron Newman is the founder and chief technology officer of Application Security, Inc.
(AppSecInc). Widely regarded as one of the world’s foremost database security experts,
Aaron coauthored the Oracle Security Handbook for Oracle Press and holds patents in database encryption and monitoring. Prior to founding AppSecInc, Aaron founded several
other companies in the technology area, including DbSecure, the pioneers in database
security vulnerability assessment, and ACN Software Systems, a database security consulting firm. Aaron has spent the last decade managing and designing database security solutions, researching database vulnerabilities, and pioneering new markets in database
security. Aaron has held several other positions in technology consulting with Price Waterhouse, Internet Security Systems, Intrusion Detection Inc., and Banker’s Trust.
Kevin Wheeler, CISA, CISSP, NSA IAM/IEM, is the founder and CEO of InfoDefense, an
information security consultancy. Kevin’s project and employment portfolio includes
organizations such as Bank of America, EDS, McAfee, Southern Methodist University,
and the State of Texas. He has performed information security audits and assessments
as well as information security design, computer incident response, business continuity
planning, and IT security training for both government and commercial entities in the
financial services, healthcare, and IT services industries. He holds a bachelor of business
administration degree from Baylor University and is an active member of ISSA, ISACA,
Infragard, the North Texas Electronic Crimes Task Force, and Greater Dallas Chamber
of Commerce.
About the Second Edition Technical Reviewers
Michael Cox currently works as a network security engineer for Texas Instruments,
where he has also worked as an IT auditor developing numerous audit programs and
automated audit tools. Prior to this, he worked as a network engineer for Nortel, and
he enjoys doing Linux sysadmin work whenever he can get it. Michael holds the CISSP
certification and has a bachelor of arts degree in history from Abilene Christian University. Michael also served as a technical reviewer for the first edition of this book.
Mike Curry, CISA, has more than 15 years of service at Texas Instruments, the last 12 of
which have been spent performing internal audits. Working as a Senior IT Auditor, he
is responsible for leading audits evaluating internal controls and security over operating systems, database management systems, networks, system applications and related
processes, and assessing compliance with relevant standards and regulations.
Vishal Mehra is currently responsible for the engineering and strategy of server, storage,
security, and database infrastructure at Texas Instruments and holds the title of senior
member of technical staff. He has worked at the company for more than 10 years and
has held numerous positions ranging from web application development, to complex
application/infrastructure architectures, to global infrastructure operations. As part of
his current role, Vishal is also heavily involved in operating system, computing, storage,
virtualization, and data protection strategies for Texas Instruments. Vishal has an MS in
computer science from University of Houston, Clear Lake.
About the First Edition Technical Reviewers
Barbara Anderson, CCSP, CISSP, CCNP, CCDP, has worked in the information technology industry as a network and server security professional for more than 12 years.
During that time, she has acted as a senior network security engineer, providing consulting and support for all aspects of network and security design. Barbara comes from
a strong network security background and has extensive experience in enterprise design, implementation, and lifecycle management. Barbara proudly served her country
for four years in the United States Air Force and has enjoyed successful positions at
EDS, SMU Fujitsu, ACS, and Fishnet Security. These experiences and interactions have
allowed her to become an expert in enterprise security, product deployment, and product training.
Tim Breeding, CISA, CGEIT, currently serves as senior director of U.S. Transformation
Systems at Wal-Mart Stores, Inc., where his responsibilities include ensuring U.S. business user engagement in the software development lifecycle and user readiness to receive major transformational systems. Previously, Tim served as the director of
information systems audit at Wal-Mart Stores, Inc. His responsibilities included oversight of project teams that assess information technology risks and mitigation strategies
from both an audit and consulting capacity. Prior to joining Wal-Mart, Tim served
Southwest Airlines as systems audit manager for more than 6 years. At Southwest Airlines, Tim presided over substantial growth of the IS audit function. Before joining
Southwest Airlines, Tim served more than 13 years in several capacities at Texas Instruments. His responsibilities included computer operations, software development, software quality assurance, and IS audit.
Subesh Ghose has worked for Texas Instruments for the past 13 years in various IT
roles. Starting in IT audit, he led audits reviewing the internal controls of various data
centers, ERP implementations, and infrastructure environments. As part of his role, he
was responsible for designing and implementing audit methodologies for various technical platforms and performing project reviews to provide internal control guidance
early in the project development lifecycle. Since then, he has managed functions in IT
security and security infrastructure, where he oversaw the architecture/process development for securing external collaborative engagements, development of security controls
in enterprise projects, and operations supporting Texas Instruments’ enterprise identity
management systems. Currently, Subesh manages the infrastructure supporting Texas
Instruments’ global manufacturing operations. Subesh has an MS in computer science
from Southern University.
Keith Loyd, CISSP, CISA, worked for 7 years in the banking industry, where he developed technology solutions for stringent legislative business requirements. He was responsible for implementing and testing networking solutions, applications, hardened
external-facing platforms, databases, and layered mechanisms for detecting intrusion.
After moving to Texas Instruments, Keith primarily dealt with vulnerability and quality
testing new applications and projects, worldwide incident response, and civil investigations. He earned a BS in information technology from Cappella University and an MS
in information assurance from Norwich University. Keith passed away after the first
edition of this book was published and is greatly missed.
CONTENTS AT A GLANCE
Part I
Audit Overview
...................................
Chapter 1
Building an Effective Internal IT Audit Function
Chapter 2
The Audit Process
PART II
1
...............
3
......................................
35
Auditing Techniques
................................
............................
61
Chapter 3
Auditing Entity-Level Controls
Chapter 4
Auditing Data Centers and Disaster Recovery
Chapter 5
Auditing Routers, Switches, and Firewalls
Chapter 6
Auditing Windows Operating Systems
Chapter 7
Auditing Unix and Linux Operating Systems
.................
171
Chapter 8
Auditing Web Servers and Web Applications
.................
219
Chapter 9
Auditing Databases
.....................................
237
.......................................
263
................
85
....................
119
......................
143
Chapter 10
Auditing Storage
Chapter 11
Auditing Virtualized Environments
Chapter 12
Auditing WLAN and Mobile Devices
Chapter 13
Auditing Applications
Chapter 14
Auditing Cloud Computing and Outsourced Operations
Chapter 15
Auditing Company Projects
PART III
63
..........................
279
.......................
295
....................................
315
.......
337
...............................
367
Frameworks, Standards, and Regulations
Chapter 16
Frameworks and Standards
Chapter 17
Regulations
Chapter 18
Risk Management
. . . . . . . . . . . . . . . . 391
...............................
393
............................................
415
.......................................
439
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
459
ix
This page intentionally left blank
CONTENTS
Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii
Part I
Chapter 1
Chapter 2
Audit Overview
...................................
Building an Effective Internal IT Audit Function
1
...............
3
Independence: The Great Myth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Consulting and Early Involvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Four Methods for Consulting and Early Involvement . . . . . . . . . . . . .
Early Involvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Informal Audits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Knowledge Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Self-Assessments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Final Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Relationship Building: Partnering vs. Policing . . . . . . . . . . . . . . . . . . .
Learning to Build Partnerships . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Role of the IT Audit Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Application Auditors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Extraction and Analysis Specialists . . . . . . . . . . . . . . . . . . .
IT Auditors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Forming and Maintaining an Effective IT Audit Team . . . . . . . . . . . . .
Career IT Auditors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IT Professionals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Career IT Auditors vs. IT Professionals: Final Thoughts . . . . . . .
Cosourcing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Maintaining Expertise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sources of Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Relationship with External Auditors . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
7
9
9
11
14
16
17
17
18
21
22
23
24
25
25
27
28
30
30
31
33
34
The Audit Process
......................................
35
Internal Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Types of Internal Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Internal Control Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Determining What to Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating the Audit Universe . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ranking the Audit Universe . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Determining What to Audit: Final Thoughts . . . . . . . . . . . . . . . .
35
36
37
38
38
40
42
xi
IT Auditing: Using Controls to Protect Information Assets, Second Edition
xii
PART II
Chapter 3
Chapter 4
Chapter 5
The Stages of an Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fieldwork and Documentation . . . . . . . . . . . . . . . . . . . . . . . . . .
Issue Discovery and Validation . . . . . . . . . . . . . . . . . . . . . . . . . .
Solution Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Report Drafting and Issuance . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Issue Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
43
46
47
48
52
58
59
59
Auditing Techniques
61
.....................................
Auditing Entity-Level Controls
............................
63
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Test Steps for Auditing Entity-Level Controls . . . . . . . . . . . . . . . . . . . .
Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Master Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auditing Entity-Level Controls . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
64
82
82
82
Auditing Data Centers and Disaster Recovery
................
85
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Center Auditing Essentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Physical Security and Environmental Controls . . . . . . . . . . . . . .
System and Site Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Center Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Disaster Preparedness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Test Steps for Auditing Data Centers . . . . . . . . . . . . . . . . . . . . . . . . . . .
Neighborhood and External Risk Factors . . . . . . . . . . . . . . . . . .
Physical Access Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Environmental Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Power and Electricity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fire Suppression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Center Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
System Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Backup and Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Disaster Recovery Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Master Checklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auditing Data Centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
85
87
88
89
89
89
90
93
98
100
103
106
111
112
113
115
116
116
Auditing Routers, Switches, and Firewalls
....................
119
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network Auditing Essentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OSI Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Routers and Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
119
120
120
121
122
124
Contents
xiii
Auditing Switches, Routers, and Firewalls . . . . . . . . . . . . . . . . . . . . . . .
General Network Equipment Audit Steps . . . . . . . . . . . . . . . . . .
Additional Switch Controls: Layer 2 . . . . . . . . . . . . . . . . . . . . . .
Additional Router Controls: Layer 3 . . . . . . . . . . . . . . . . . . . . . .
Additional Firewall Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tools and Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Master Checklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
General Network Equipment Audit Steps . . . . . . . . . . . . . . . . . .
Auditing Layer 2 Devices: Additional Controls for Switches . . .
Auditing Layer 3 Devices: Additional Controls for Routers . . . .
Auditing Firewalls: Additional Controls . . . . . . . . . . . . . . . . . . .
Chapter 6
Chapter 7
Auditing Windows Operating Systems
126
126
133
136
138
139
140
140
140
141
142
142
......................
143
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Windows Auditing Essentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Command-Line Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Essential Command-Line Tools . . . . . . . . . . . . . . . . . . . . . . . . . .
Common Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Server Administration Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performing the Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Test Steps for Auditing Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setup and General Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Review Services, Installed Applications, and Scheduled Tasks . .
Account Management and Password Controls . . . . . . . . . . . . . .
Review User Rights and Security Options . . . . . . . . . . . . . . . . . .
Network Security and Controls . . . . . . . . . . . . . . . . . . . . . . . . . .
Network Vulnerability Scanning and Intrusion Prevention . . . .
How to Perform a Simplified Audit of a Windows Client . . . . . . . . . .
Tools and Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Master Checklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auditing Windows Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auditing Windows Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
143
144
145
145
146
146
148
148
148
151
154
158
159
162
164
167
168
168
169
170
Auditing Unix and Linux Operating Systems
.................
171
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unix and Linux Auditing Essentials . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
File System Layout and Navigation . . . . . . . . . . . . . . . . . . . . . . .
File System Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Users and Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Test Steps for Auditing Unix and Linux . . . . . . . . . . . . . . . . . . . . . . . . .
Account Management and Password Controls . . . . . . . . . . . . . .
File Security and Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network Security and Controls . . . . . . . . . . . . . . . . . . . . . . . . . .
171
172
173
173
176
177
180
180
181
191
197
IT Auditing: Using Controls to Protect Information Assets, Second Edition
xiv
Chapter 8
Chapter 9
Audit Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Security Monitoring and General Controls . . . . . . . . . . . . . . . . .
Tools and Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Nessus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chkrootkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Crack and John the Ripper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tiger and TARA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Shell/Awk/etc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Master Checklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auditing Account Management and Password Controls . . . . . .
Auditing File Security and Controls . . . . . . . . . . . . . . . . . . . . . . .
Auditing Network Security and Controls . . . . . . . . . . . . . . . . . . .
Auditing Audit Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auditing Security Monitoring and General Controls . . . . . . . . .
207
210
212
212
213
213
213
213
213
214
215
215
216
216
217
217
Auditing Web Servers and Web Applications
.................
219
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Web Auditing Essentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
One Audit with Multiple Components . . . . . . . . . . . . . . . . . . . .
Part 1: Test Steps for Auditing the Host Operating System . . . . . . . . . .
Part 2: Test Steps for Auditing Web Servers . . . . . . . . . . . . . . . . . . . . . .
Part 3: Test Steps for Auditing Web Applications . . . . . . . . . . . . . . . . .
Additional Steps for Auditing Web Applications . . . . . . . . . . . .
Tools and Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Master Checklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auditing Web Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auditing Web Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
219
219
220
221
221
224
232
234
235
236
236
236
Auditing Databases
.....................................
237
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Database Auditing Essentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Common Database Vendors . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Database Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Test Steps for Auditing Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setup and General Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operating System Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Account and Permissions Management . . . . . . . . . . . . . . . . . . . .
Data Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Monitoring and Management . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tools and Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auditing Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Monitoring Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
237
238
238
241
245
246
247
249
255
256
258
258
258
259
Contents
xv
Master Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auditing Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 10
Chapter 11
Chapter 12
Auditing Storage
261
261
.......................................
263
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Storage Auditing Essentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Key Storage Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Key Storage Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Test Steps for Auditing Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setup and General Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Account Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Storage Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Additional Security Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Master Checklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
263
264
264
267
269
270
271
272
274
276
277
Auditing Virtualized Environments
..........................
279
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Commercial and Open Source Projects . . . . . . . . . . . . . . . . . . . .
Virtualization Auditing Essentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Test Steps for Auditing Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setup and General Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Account and Resource Provisioning and Deprovisioning . . . . .
Virtual Environment Management . . . . . . . . . . . . . . . . . . . . . . .
Additional Security Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hypervisors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Master Checklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
279
280
280
282
282
284
285
288
292
292
292
293
Auditing WLAN and Mobile Devices
.......................
295
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WLAN Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data-Enabled Mobile Devices Background . . . . . . . . . . . . . . . . .
WLAN and Mobile Device Auditing Essentials . . . . . . . . . . . . . . . . . . .
Test Steps for Auditing Wireless LANs . . . . . . . . . . . . . . . . . . . . . . . . . .
Part 1: WLAN Technical Audit . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part 2: WLAN Operational Audit . . . . . . . . . . . . . . . . . . . . . . . . .
Test Steps for Auditing Mobile Devices . . . . . . . . . . . . . . . . . . . . . . . . .
Part 1: Mobile Device Technical Audit . . . . . . . . . . . . . . . . . . . . .
Part 2: Mobile Device Operational Audit . . . . . . . . . . . . . . . . . .
Additional Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tools and Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Master Checklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auditing Wireless LANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auditing Mobile Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
295
295
298
298
299
299
304
306
307
309
311
311
312
312
312
312
IT Auditing: Using Controls to Protect Information Assets, Second Edition
xvi
Chapter 13
Chapter 14
Chapter 15
Auditing Applications
....................................
315
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Application Auditing Essentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generalized Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Test Steps for Auditing Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Input Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interface Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Audit Trails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Access Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Software Change Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backup and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Retention and Classification and User Involvement . . . . .
Operating System, Database, and Other Infrastructure
Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Master Checklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Application Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auditing Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
315
316
316
319
321
321
323
324
325
329
331
332
Auditing Cloud Computing and Outsourced Operations
333
334
334
334
.......
337
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IT Systems and Infrastructure Outsourcing . . . . . . . . . . . . . . . . .
IT Service Outsourcing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Other Considerations for IT Service Outsourcing . . . . . . . . . . . .
SAS 70 Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Test Steps for Auditing Cloud Computing and Outsourced
Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Preliminary and Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vendor Selection and Contracts . . . . . . . . . . . . . . . . . . . . . . . . . .
Data Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Legal Concerns and Regulatory Compliance . . . . . . . . . . . . . . . .
Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Master Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auditing Cloud Computing and Outsourced Operations . . . . .
337
338
343
344
345
Auditing Company Projects
346
346
349
351
358
362
364
365
365
...............................
367
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Project Auditing Essentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
High-Level Goals of a Project Audit . . . . . . . . . . . . . . . . . . . . . . .
Basic Approaches to Project Auditing . . . . . . . . . . . . . . . . . . . . .
Seven Major Parts of a Project Audit . . . . . . . . . . . . . . . . . . . . . .
Test Steps for Auditing Company Projects . . . . . . . . . . . . . . . . . . . . . . .
Overall Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Project Start-up: Requirements Gathering and Initial Design . .
Detailed Design and System Development . . . . . . . . . . . . . . . . .
Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
367
368
368
369
370
371
371
375
380
381
Contents
xvii
Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Project Wrap-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Master Checklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auditing Overall Project Management . . . . . . . . . . . . . . . . . . . . .
Auditing Project Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auditing Detailed Design and System Development . . . . . . . . .
Auditing Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auditing Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auditing Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Auditing Project Wrap-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PART III
Chapter 16
Chapter 17
Frameworks, Standards, and Regulations
Frameworks and Standards
384
386
387
387
387
388
388
389
389
389
390
390
. . . . . . . . . . . . . . . . 391
...............................
393
Introduction to Internal IT Controls, Frameworks, and Standards . . .
COSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
COSO Definition of Internal Control . . . . . . . . . . . . . . . . . . . . .
Key Concepts of Internal Control . . . . . . . . . . . . . . . . . . . . . . . .
Internal Control—Integrated Framework . . . . . . . . . . . . . . . . . .
Enterprise Risk Management—Integrated Framework . . . . . . . .
Relationship Between Internal Control and Enterprise
Risk-Management Publications . . . . . . . . . . . . . . . . . . . . . . . .
COBIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
COBIT Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IT Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IT Governance Maturity Model . . . . . . . . . . . . . . . . . . . . . . . . . .
The COSO-COBIT Connection . . . . . . . . . . . . . . . . . . . . . . . . . .
COBIT 5.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ITIL Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ISO 27001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ISO 27001 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NSA INFOSEC Assessment Methodology . . . . . . . . . . . . . . . . . . . . . . .
NSA INFOSEC Assessment Methodology Concepts . . . . . . . . . .
Pre-assessment Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
On-Site Activities Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Post-assessment Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Frameworks and Standards Trends . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
393
394
395
395
395
397
Regulations
............................................
415
An Introduction to Legislation Related to Internal Controls . . . . . . . .
Regulatory Impact on IT Audits . . . . . . . . . . . . . . . . . . . . . . . . . .
History of Corporate Financial Regulation . . . . . . . . . . . . . . . . .
415
416
416
400
401
401
403
404
405
405
407
408
408
409
410
410
410
411
411
411
412
IT Auditing: Using Controls to Protect Information Assets, Second Edition
xviii
The Sarbanes-Oxley Act of 2002 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SOX’s Impact on Public Corporations . . . . . . . . . . . . . . . . . . . . .
Core Points of the SOX Act . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SOX’s Impact on IT Departments . . . . . . . . . . . . . . . . . . . . . . . . .
SOX Considerations for Companies with Multiple Locations . .
Impact of Third-Party Services on SOX Compliance . . . . . . . . .
Specific IT Controls Required for SOX Compliance . . . . . . . . . .
The Financial Impact of SOX Compliance on Companies . . . . .
Gramm-Leach-Bliley Act . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GLBA Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Federal Financial Institutions Examination Council . . . . . . . . .
Privacy Regulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
California SB 1386 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
International Privacy Laws . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Privacy Law Trends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Health Insurance Portability and Accountability Act of 1996 . . . . . . .
HIPAA Privacy and Security Rules . . . . . . . . . . . . . . . . . . . . . . . .
The HITECH Act . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HIPAA’s Impact on Covered Entities . . . . . . . . . . . . . . . . . . . . . .
EU Commission and Basel II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Basel II Capital Accord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Payment Card Industry (PCI) Data Security Standard . . . . . . . . . . . . .
PCI Impact on the Payment Card Industry . . . . . . . . . . . . . . . . .
Other Regulatory Trends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 18
Risk Management
417
418
418
420
421
421
422
426
426
426
428
428
429
429
430
431
431
433
434
434
434
435
436
436
437
.......................................
439
Benefits of Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Risk Management from an Executive Perspective . . . . . . . . . . . . . . . . .
Addressing Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Quantitative vs. Qualitative Risk Analysis . . . . . . . . . . . . . . . . . .
Quantitative Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Elements of Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Practical Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Quantitative Risk Analysis in Practice . . . . . . . . . . . . . . . . . . . . .
Common Causes for Inaccuracies . . . . . . . . . . . . . . . . . . . . . . . .
Qualitative Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IT Risk Management Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Phase 1: Identify Information Assets . . . . . . . . . . . . . . . . . . . . . .
Phase 2: Quantify and Qualify Threats . . . . . . . . . . . . . . . . . . . .
Phase 3: Assess Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . .
Phase 4: Remediate Control Gaps . . . . . . . . . . . . . . . . . . . . . . . .
Phase 5: Manage Residual Risk . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary of Formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
439
439
440
440
441
441
442
443
443
445
445
446
449
454
456
458
458
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
459
FOREWORD
As I reviewed this book, which has been effectively updated to cover new and emerging
audit topics, I couldn’t help but reflect on the history of our great profession.
The word “audit” can be traced back in history to the Latin word auditio, meaning a
hearing, and the French word auditre, meaning audible. The concept of an audit as a means
of informing others about the health of businesses didn’t take hold until the 1700s,
with the advent of large trading “partnerships” such as the East India Company and the
Hudson’s Bay Company. Absentee owners and financiers wanted assurance on the safety of their investment.
The 1800s saw the invention of the steam engine, and huge industries arose with
the advent of railroads and easy shipment of goods over land. But all was not well, and
many railways in England failed. Investors wanted to know what caused this collapse
and what happened to their money. In the mid 1800s, William Welch Deloitte, who
specialized in railway bankruptcies, started the firm that, following a number of mergers and acquisitions, today bears only his name.
All the while, handwritten, double-entry bookkeeping—the key to modern accounting—was being dealt with in much the same manner for almost 500 years. But change
was on the horizon. Inventor Herman Hollerith devised a system of encoding data on
cards through a series of punched holes. This system proved useful in statistical work
and was used in the 1890 U.S. census. Hollerith also designed a means to “read” the
cards by passing them through electrical contacts. Closed circuits, which indicated hole
positions, could then be selected and counted. His Tabulating Machine Company,
incorporated in 1896, was a predecessor to the International Business Machines Corporation—today’s IBM.
Throughout the first few decades of the 1900s and up to the 1980s, punched cards
remained a widely used method to input data. Accounting machines were invented that
could read and accumulate numeric information using counter wheels to add and subtract numbers. This ability to electronically “read” data paved the way for computing in
the 1940s. It applied the idea of machines that could read and record numbers to the
field of scientific calculation previously dominated by logarithms and other tables of
functions and hand-operated machines for adding, subtracting, multiplying, and dividing numbers.
The information age was born, some say, with the invention of the digital computer ENIAC 1 in 1944. Although there is little evidence to support the alleged 1943
statement by Thomas J. Watson Jr., “I think there is a world market for maybe five computers,” IBM archives indicate that in a 1953 presentation to stockholders, his son,
Thomas J. Watson, Jr., then president of IBM, spoke about the new IBM 701 Electronic
Data Processing Machine and indicated that the company had identified “some 20
concerns that we thought could use such a machine.”
More than half a century later, we have seen unprecedented changes in the way
business is conducted. We quickly evolved from the pen-and-pencil world to machine
xix
IT Auditing: Using Controls to Protect Information Assets, Second Edition
xx
accounting, computers, the wired world, and now a wireless world. To perform meaningful audit work, the accounting profession quickly embraced computer technology—
first with new techniques such as flowcharting to assess and document computer
application processes and controls and shortly thereafter with the development of
generalized auditing software, such as the Haskins & Sells Auditape system in 1968 to
interrogate client computer files directly.
In the 1960s, auditors, through The Institute of Internal Auditors and the newly
formed EDP Auditors Association (now ISACA), further pushed the information technology audit envelope. At that time, there were only a few articles and three recognized
books on IT auditing, or as it was known in those days, electronic data processing
(EDP) auditing: Electronic Data Processing and Auditing by Felix Kaufman, Ph.D, CPA,
published in 1961; Auditing with the Computer by Wayne S. Boutell, Ph.D., CPA, published in 1965; and Auditing and EDP by Gordon Davis, Ph.D., published in 1968. I
have all three in my library! It is not often that one can read a number of articles and
three books and have absorbed the documented collective wisdom on a subject. That
was the way it was with EDP auditing at that time.
From the heady days of the 1960s when I joined the auditing profession, IT auditing has had to keep pace with the advent of new technologies, new risks, and new
threats. The profession of IT audit and control has grown to include many related activities and disciplines, such as risk management and security and value-based assessments, to mention a few. Yet, their roots still go back to IT auditing, and that is where
IT Auditing: Using Controls to Protect Information Assets, Second Edition, excels.
The challenges facing IT auditors today revolve around change—in technology, the
business environment, business risks, the legislative and regulatory environment, and
the knowledge and skills required to audit effectively in this evolving environment.
Today’s auditing environment involves cloud computing, virtualization, and, on the
horizon, the parallel universe and multicore processing. The role of the IT auditor must
change to match these new requirements and associated risks, and the IT auditor
must understand the business and the business risks to audit the business and its supporting applications effectively. Knowledge requirements are expanding, as are the
skills required to perform in the new environments.
Social networks, bring-your-own-technology, and portable media only serve to increase the risks facing business today. Social networks introduce risks of entities’ information being posted, blogs created, or inappropriate photos and other information
circulating in the public arena. Increasingly entities are requiring, encouraging, or permitting employees to use their own technology for business purposes. Mobile phones,
smart phones, tablets, netbooks, and other technologies are all finding their way into
the office environment. However, since they are personally owned, the entity has little
control over their content or use. Similarly risky are portable media, memory sticks,
camera cards that can be used to store data, and other devices expose the entity to potential loss of information and data.
IT Auditing: Using Controls to Protect Information Assets, Second Edition, meets the
challenge of capturing both the roots of IT auditing and the emerging technologies
and issues with which today’s auditors must familiarize themselves. The book provides
IT audit and assurance professionals with superb information on the profession of IT
Foreword
xxi
auditing. Its scope provides information for novice IT auditors as well as more seasoned
professionals. It covers areas frequently missed by providing a clear definition of IT
audit and the roles it can play, explaining what an appropriate mandate is and clarifying when IT audit should become involved.
The book starts out by explaining why to perform an IT audit, how to organize an IT
audit function and develop its mandate, and how to recruit skilled resources. Too many
books skip or gloss over these important topics. From beginning to end, the information
in IT Auditing, Second Edition is presented in a clear and concise manner. The notes
provide useful information to clarify comments or provide insight into performing audit work, furthering one’s career, or understanding the politics of business environments.
The audit checklists provide good “memory joggers” at the management level to help
ensure that the planning is appropriate and that the audit progresses as planned. The
“how” sections provide good detailed instruction on conducting specific IT audit work.
IT Auditing: Using Controls to Protect Information Assets, Second Edition covers a lot of
ground that is essential to the IT audit and assurance professional. It is an excellent
resource to help readers understand our rapidly changing profession.
Robert G. Parker, MBA, FCA, CA*CISA, CMC
Past International President, ISACA
November 20, 2010
Robert G. Parker, MBA, FCA, CA*CISA, CMC, is a retired Enterprise Risk Management partner from Deloitte & Touche, where he had responsibility for its privacy and
business continuity practices as well as internal risk management for the Canadian ERS
practice. A frequent author and presenter, he was international president of ISACA from
1986 to 1987 and continues to serve on various ISACA committees. He is the principal
architect of ISACA’s Information Technology Assurance Framework, a member of the
CICA’s Information Technology Advisory Committee, a member of the Board of
the University of Waterloo’s Centre for Information Systems Integrity and Assurance
(UW-CISA), and a member of the AICPA-CICA Privacy Task Force.
This page intentionally left blank
ACKNOWLEDGMENTS
We simply could not have done this without the help of many, many people. It was an
amazing challenge coordinating the necessary depth of corporate, legal, and technical
expertise across so many subjects. Many old and new friends; organizations such as
ISACA, NIST, and OWASP; and many others donated knowledge, time, techniques,
tools, and much more to make this project a success.
Writing this book required tireless hours of writing, research, and corroboration
among the authors, contributing authors, technical editors, industry peers, copy editors, layout team, and publisher leadership team while our loved ones took the brunt
of our efforts. It is only appropriate that we thank and acknowledge those that supported and carried us despite ourselves. We are truly grateful to each of you.
The wonderful and overworked team at McGraw-Hill is simply outstanding. We
sincerely appreciate your dedication, coaching, and long hours during the course of this
project. Megg Morin, this book is a result of your tireless dedication to the completion
of this project and your extreme patience. We look forward to working with you again
in the future. We would also like to extend a big round of thanks to Joya Anthony, our
acquisitions coordinator, for her coordination and work with the technical editors.
Thank you so much for being a part of this. We also would like to thank the wonderful
efforts of project editor LeeAnn Pickrell; copy editor Lisa Theobald; proofreader Martin
Benes; indexer Karin Arrigoni; editorial supervisor Jody McKenzie; production supervisor James Kussow; art director, cover, Jeff Weeks; and compositor and illustrator, Apollo
Publishing and Lyssa Wald.
A special thank you goes to Michael Cox, Mike Curry, and Vishal Mehra for their
deep technical reviews for the second edition. Your involvement truly made the difference. Your reviews were wonderful, detailed, and significant in providing a useful product for the readers. Additionally, thank you Robert G. Parker for taking the time to
deliver an incredible introduction to this work and to Michael Cangemi for the foreword
to the first edition. Your words are thoughtful, kind, and relevant, and they illustrate the
experience you have in this industry.
We also want to acknowledge and extend our thanks to the many people who were
involved with editing, reviewing, and publishing the first edition. Without your work
on the first edition, there would be no second edition. Thank you to our first edition
technical reviewers: Barbara Anderson, Tim Breeding, Michael Cox (who signed on for
a second tour of duty with this edition), Subesh Ghose, and Keith Loyd (we miss you,
Keith). And thank you to the fine folks at McGraw-Hill who played critical roles in the
first edition: Jane Brownlow, Jennifer Housh, Madhu Bhardwaj, Jim Madru, Ragini Pandey,
Kevin Broccoli, Janet Walden, George Anderson, and Jeff Weeks. Last but not least,
thank you to the contributing authors from the first edition: Stacey Hamaker, Aaron
Newman, and Kevin Wheeler.
xxiii
IT Auditing: Using Controls to Protect Information Assets, Second Edition
xxiv
We are truly grateful to four organizations that allowed us to borrow content. We
would like to thank the people at ISACA for bringing a cohesive knowledge set to the
auditing field and the CISA certification. There is still much work to be done, and we as
a team would like to encourage our peers to contribute to this wonderful knowledge
base. Likewise, thank you Jeff Williams and Mark Curphey for founding and contributing to OWASP. Your selfless investments are helping thousands of professionals worldwide, and many more that would never know where to start securing their websites.
Thank you. And thank you to NIST, specifically Peter Mell, for supporting this book and
allowing us to leverage some of your work in Chapter 14. The work you’re doing to
bring consistency and understanding to the subject of cloud computing and its security
are a benefit to all of us in the IT security and audit professions. And thank you Craig
Isaacs of the Unified Compliance Framework for allowing us to use your materials in
our book and a recent class at Southern Methodist University.
Finally, thank you to everyone who bought, read, used, and supported the first edition of this book. Special thanks to the folks at ISACA for recognizing our work by carrying it in your bookstore and to all of the professors (such as Mark Salamasick of the
University of Texas at Dallas) for selecting our book to supplement your courses. We
have been extremely honored and humbled by the response we received to the first edition and inspired to improve on our work with this second edition.
—Chris and Mike
Thank you, Sarah. This book would not exist without you. I’m thankful and blessed to
have you as my wife and look forward to the many wonderful years we have left. I love
you! Little Joshua, Caleb, and Kelsea: your mother and I love you so much. Not a day
goes by that we don’t think about sharing, teaching, and helping you to grow and
mature into your own. Thanks to our Lord and Savior for the many opportunities and
blessings you’ve so generously given us.
I also want to thank Mike Schiller. I always appreciate the opportunity to work with
you and learn from you. Your input greatly impacted the quality of the book, and your
selfless friendship and leadership has impacted me personally and professionally. I’m
grateful to have you as part of this project.
Through all of this project’s challenges, between the authors, contributors, reviewers, editors, layout team, and project managers, we pulled it off. I also want to thank
Anton Abaya, David Vance, and Stephen Lengel for their helpful insights. Thank each of
you for your generous time and reviews. Many of you balanced active work and home
lives to fit this into your schedule. Thank you for your tremendous help. The crew at
McGraw-Hill is a wonderful group to work with. I am grateful for your outstanding
guidance and continual support.
And finally, a special thank you goes to my father for passing along his interest in
how everything works and patiently answering my endless barrage of questions as a
child. Now that I have my own…I understand.
—Chris
Acknowledgments
xxv
I would like to thank my good friends Tim Breeding, Michael Cox, Mike Curry, Subesh
Ghose, and Vishal Mehra for helping with this book and making it better than we could
have made it on our own. You’re each not only outstanding technical professionals but
also outstanding friends.
I would also like to thank Chris Davis for his excellent work and for being my valued partner in this endeavor. I’m grateful for your friendship and always value the opportunity to work with and learn from you.
Thanks also to Megg Morin and Joya Anthony of McGraw-Hill for their support of
this project and dedication to making it happen. And I would like to express appreciation to Edward Dorsey, whose Unix auditing class (via the MIS Training Institute and
Automated Design Enterprises, Inc.) way back in 1997 was very influential to me and
inspired a lot of the content in Chapter 7.
To Shawn Irving, thank you for your continued friendship throughout the years and
for serving as an unofficial advisor for the second edition. The insights you provided
resulted in significant improvements to this edition.
I would also like to thank the many people who have worked on audit teams that I
managed. It was an honor to work with you, and there’s a piece of each of you in this
book. Thanks to Jon Mays and Nancy Jones, for putting up with me in my first management position; to Sally West and Andrea Khan, for enhancing my knowledge of project
auditing; to Chris Speegle, Steve Holt, Kylonnie Jackson, Dottie Vo, Dean Irwin, Gus
Coronado, Hans Baartmans, Prabha Nandakumar, and all the others who worked with
me on the TI teams I managed—it was a pleasure and I learned from you all.
Thanks to Kirk Tryon and Jay Blanchard, for being my friends and peers for so many
years. It was fun. A lot of our discussions are reflected in this book. Extra thanks to Kirk
for letting me pick your brain and helping me improve Chapter 1 for this edition.
Thanks also to Richard Hudson and Geoff Sloma for giving me the chance to learn and
grow as a manager.
Of course, thanks go to God and Jesus Christ for my salvation and for the many
blessings in my life.
Most of all, thanks to my family. To Mom and Dad, the perfect parents, for all your
love and guidance throughout my life. To David, for not only being a great brother, but
one of my best friends. To Kate, for all the energy and happiness you bring to my life.
Now that I’m done, I promise to play some extra Littlest Pet Shop with you. And I’ll take
you to Disney World, too. To Grant, my pal, for being patient about this book (even
when it was hard), for how proud you make me, and for how much fun we have together. I know it was frustrating to deal with all the time I was locked away in my office
yet again for this edition. Now that it’s over, I’ll play hockey or football in the game room
with you every day for two weeks. And the absolute biggest thanks go to my wonderful
wife, Stephanie, for believing in me and supporting me, for being my proofreader, and
for being my best friend. Every year, I’m more amazed by how lucky I am to have you as
my partner in life. I couldn’t have done this without you. To show my appreciation, I
promise not to sign up for any extracurricular activities for at least six months.
—Mike
This page intentionally left blank
INTRODUCTION
When we began writing this book, we had a fundamental tenet: Write a clear handbook
for creating the organization’s IT audit function and for performing their IT audits. We
wanted this book to provide more than checklists and textbook theories but instead to
provide real-life practical guidance from people who have performed IT audit work day
in and day out in real corporations. If we’ve been successful, reading this book will accomplish three objectives for the reader, above and beyond what can be obtained from
most IT auditing books and classes:
Guide the reader in how to perform the IT audit function in such a way that the
auditors maximize the value they provide to the company.
Part I of this book is dedicated to providing practical guidance on how to perform the
IT audit function in such a way that it will be considered an essential and respected
element of the company’s IT environment. This guidance is pulled from years of experience and best practices, and even the most experienced of IT auditors will find a
plethora of useful tools and techniques in those chapters.
Enable the reader to perform thorough audits of common IT topics, processes,
and technologies.
Part II of this book is dedicated to guiding the reader with practical, detailed advice on
not only what to do but also why and how to do it. Too many IT audit resources provide
bullet-oriented checklists without empowering the auditor with enough information to
understand why they’re performing that task or how exactly to accomplish the step.
Our goal is to fill that gap for the reader.
Give the reader exposure to IT audit standards and frameworks as well as the
regulations that are currently driving the IT audit profession.
Part III focuses on standards and frameworks such as COBIT, ITIL, and ISO 17799 as
well as regulations such as Sarbanes-Oxley, HIPAA, and PCI. Another goal of this section is to demystify risk assessment and management, which is required by most regulations.
A wealth of knowledge and resources for hardening systems and performing detailed penetration tests are available in other texts. That is not the focus of this book. In
our experience as auditors, we have been called on more often to judge the quality of
internal controls from an insider’s standpoint. Therefore, the majority of audit steps in
this book are written with the assumption that the auditor has full access to all configuration files, documentation, and information. This is not a hackers’ guidebook but
is instead a guidebook on how an auditor can assess and judge the internal controls
and security of the IT systems and processes at his or her company.
xxvii
IT Auditing: Using Controls to Protect Information Assets, Second Edition
xxviii
How This Book Is Organized
This book is organized into three parts. Part I, “Audit Overview,” helps you understand
the IT audit process, how to build and maintain an effective IT audit team, and how to
maximize the value of the IT audit function. Part II, “Auditing Techniques,” then helps
you understand what specific components or audit steps might be necessary for an
audit of a specific system or process. Finally, Part III, “Frameworks, Standards, and Regulations,” covers the frameworks, standards, regulations, and risks that govern the scope
of the audit function.
Audit Technique Chapters
Part II contains a series of suggested audit programs or techniques for commonly audited systems and processes. The chapters in this section are structured to help you
quickly digest the information that’s most useful to you.
Background
This part of the chapter contains information about the topic’s history or background
information that helps you acclimate to the subject matter.
Auditing Essentials
For chapters dealing with a specific technology, this part of the chapter describes getting
around within the technology and introduces you to basic concepts, commands,
and tools.
Test Steps
This is the meat of the chapters in Part II and provides details about what the auditor
should look for, why they should do so (that is, what risk is being addressed), and how
the step can be performed.
This is the audit step that should be performed The text immediately
following the step states why this step is important. This section states the reason why,
such as the risk and business need, the step should be performed.
How
This describes how to perform the step. We commonly use design elements such as tables and code listings to help you navigate the content.
This is an example code listing.
Tools and Technology
This section lists the tools used in the test steps and other tools not covered but mentioned as popular for more closely examining the technology. The purpose of this is to
provide in a shortened format some of the tools readers might want to consider as they
look further into the technology.
Introduction
xxix
Knowledge Base
This section provides a list of websites and books where readers can find more information about the topics covered in the chapter. We can’t discuss everything, but we can
point to other places where others discuss more than you could possibly want to know.
Master Checklist(s)
This check-boxed table summarizes the steps listed in the chapter. Similar to other
checklists, you may need to customize this checklist according to what makes sense to
you and what you consider to be your own high priorities.
A Final Word to Our Readers
Thank you for taking the time to read this book. Technology continues to evolve and
audit techniques need to evolve as well. In the years since the first edition of this book
was released in 2006, areas such as virtualization and cloud computing have matured
and entered the mainstream. In this second edition, you will find all-new chapters providing guidance on auditing cloud computing and outsourced operations, virtualization, and storage. In addition, all other chapters have been updated and enhanced to
reflect recent trends and advances.
We have put countless hours and enormous effort into creating something we hope
will be useful for you. Read this book all the way through, and then, when you are done
using it as a tutorial, you can keep it around as a reference. Auditing is a detail-oriented
job, and it is easy to get overwhelmed and overlook something. In addition, it is easy to
get in over your head. This book is a great place to start, learn, and expand on what you
know. We hope you enjoy reading this book as much as we enjoyed writing it. Good
luck in all your audits.
This page intentionally left blank
PART I
Audit Overview
QChapter 1
QChapter 2
Building an Effective Internal IT Audit Function
The Audit Process
This page intentionally left blank
CHAPTER
Building an Effective
Internal IT Audit Function
In this chapter we’ll discuss the purpose of internal audit departments and how they can
best be leveraged to provide a benefit to the company. We will discuss
• The audit department’s real mission
• The concept of independence and how to avoid misusing it
• How to add value beyond formal audits via consulting and early involvement
• How to enhance effectiveness by building relationships
• The role of the information technology (IT) audit and how to choose the correct focus
• How to build and maintain an effective IT audit team
The philosophies and guidance provided in this chapter form a foundation on which the
rest of the book is built. Although this first chapter is written from an internal auditor’s
perspective, the concepts and philosophies presented here can be adapted to guide
the external audit function as well. The rest of this book (certainly Part II) is essentially
internal/external auditor neutral.
Why Are We Here? (The Internal Audit
Department’s Mission)
Before you can develop an effective internal audit department, you must first come to
an understanding of the department’s purpose. Why does the internal audit department exist? What’s the end goal?
Is your purpose to issue reports? To raise issues? To make people look bad? To
show how smart you are and how dishonest, incompetent, and corrupt the rest of the
company is? To flex your muscles and show that you can do anything and tell on anyone because you report to the board of directors? Hopefully, it’s obvious that none of
these is an appropriate answer. Sadly, though, you will find that many (perhaps most)
internal audit departments function as if the answer is indeed one or more of the preceding examples. Many audit departments spend their existence in adversarial relationships with the rest of the company, keeping themselves comfortably removed
from, and “independent” of, everyone else. Unfortunately, such departments are missing the point by failing to realize the potential benefits that they could be providing to
their companies.
3
1
IT Auditing: Using Controls to Protect Information Assets, Second Edition
4
Most audit departments were formed by the company’s audit committee (a subset of
the board of directors) to provide the committee with independent assurance that internal controls are in place and functioning effectively. In other words, the audit committee
wants an objective group that will tell it what’s “really going on” in the company. The
committee wants someone it can trust to reveal all the evildoers who refuse to implement
internal controls. Internal audit departments usually report directly to the chairman of
the audit committee, so they feel protected from the repercussions that could result from
blowing the whistle on the hordes of dishonest managers within the company.
Despite the levity in the preceding paragraph, it is absolutely essential that the audit
committee have an internal audit function that can serve as their eyes and ears within
the company. This is critical for the committee to function and serve the company’s
shareholders. In addition, most companies’ audit departments also report to an executive within the company, such as the chief executive officer (CEO) or the chief financial
officer (CFO). Later in this chapter, we’ll discuss this reporting relationship; for now,
you should know that senior management, just like the audit committee, is interested
in the state of the company’s internal controls. From an IT perspective, the audit committee and senior management want honest answers to such questions as, “Are our
firewalls really secure?” and “Is our plan to collaborate and share networks with our
biggest rival going to expose us to any security concerns?” This is certainly an important
role for the audit department to play. However, this is not the whole picture.
Merely reporting issues accomplishes nothing, except to make people look bad, get
them fired, and create hatred of auditors. The real value comes when issues are addressed and problems are solved. In other words, reporting the issues is a means to an
end. In this context, the end result improves the state of internal controls at the company. Reporting them provides a mechanism by which the issues are brought to light
and can therefore receive the resources and attention needed to fix them. If I tell senior
management that I discovered a hole in the wall of our most important data center, it
may help in my goal of making myself look good at the expense of others, but the hole
is still there, and the company is still at risk. It’s when the hole is patched that I’ve actually done something that adds value to the company (and that’s true only if the company wasn’t already aware of and planning to fix the hole prior to my audit).
Therefore, the real mission of the internal audit department is to help improve the
state of internal controls at the company. Admittedly, this is accomplished by performing audits and reporting the results, but these acts provide no value in and of themselves. They provide value only when the internal control issues are resolved. This is an
important distinction to remember as you develop your approach to auditing and,
most important, to dealing with the people who are the “targets” of your audits.
NOTE The internal audit department’s goal should be to promote internal
controls and to help the company develop cost-effective solutions for
addressing issues. This requires a shift in focus from “reporting” to “improving.”
Like any other department, the audit department exists in order to add value
to the company via its specific area of expertise—in this case, its knowledge of
internal controls and how to evaluate them.
Chapter 1: Building an Effective Internal IT Audit Function
5
In summary, the internal audit department’s mission is twofold:
• To improve the state of internal controls at the company by promoting
internal controls and by helping the company identify control weaknesses
and develop cost-effective solutions for addressing those weaknesses.
The rest of this chapter will discuss how this mission can be accomplished most
effectively, specifically for the IT audit function.
NOTE The term internal controls is used frequently throughout this chapter.
Stated in the simplest terms, internal controls are mechanisms that ensure
the proper functioning of processes within the company. Every system and
process exists for some specific business purpose. The auditor must look
for risks that could impact the accomplishment of those purposes and then
ensure that internal controls are in place to mitigate those risks. Chapter 2
delves further into the meaning of this term.
Independence: The Great Myth
Independence is one of the cornerstone principles of an audit department. It is also one
of the biggest excuses used by audit departments to avoid adding value. Almost all audit
departments point to their independence as one of the keys to their success and the
reason that the audit committee can rely on them.
But what is independence really? According to Webster’s Universal College Dictionary,
independence is “the quality or state of being independent.” Since this is not very helpful, let’s look at the word independent, which Webster describes as “not influenced or
controlled by others; thinking or acting for oneself.” This definition fits with the concept that’s flaunted by most audit departments. Since they, at least partially, report to
the chairman of the audit committee, they believe that they are therefore not influenced or controlled by others. But this isn’t really true; let’s examine this a little closer.
Although the audit department reports to a member of the board of directors, in
almost every company, the audit director also reports to the company’s CFO or CEO
(Figure 1-1). The budget for the audit department is usually controlled by this executive, and so is the compensation paid to members of the audit department. It is hard to
see how a person can feel that he or she is not being influenced by these individuals. In
addition, the internal auditors generally work in the same building as their fellow employees, inevitably forming relationships outside the audit department. The auditors
have 401k plans just like all other employees, usually consisting largely of company
stock. Therefore, the success of the company is of prime interest to the auditors.
PART I
• To provide independent assurance to the audit committee (and senior
management) that internal controls are in place at the company and are
functioning effectively.
IT Auditing: Using Controls to Protect Information Assets, Second Edition
6
Audit committee
board of directors
CFO or CEO
Director of audits
(IT and finance)
IT audit
manager
Finance audit
manager
Auditor
IT audit team
Auditor
finance audit team
Auditor
IT audit team
Auditor
IT audit team
Auditor
finance audit team
Auditor
finance audit team
Figure 1-1 Audit team reporting structure
More important, as will be discussed later in this chapter, most successful audit
departments include some people who have joined the department from other areas in
the company and/or plan to rotate out of the audit department and into another area
of the company at some point. You can talk all you want about independence, but these
auditors know that if they tick off a lot of people, they’re going to have a tough time
finding another job in the company. If an IT auditor plans to move into the IT organization, it’s probably best if the chief information officer (CIO) doesn’t think that the auditor is an arrogant, know-nothing idiot.
It should be apparent by now that internal audit departments are not truly independent. Nevertheless, the core concept behind the independent auditor role is valid and
important. An auditor must not feel undue pressure to bury issues and must believe
that he or she will be allowed to “do the right thing.” This is where the relationship
with the board of directors comes into play. On those rare occasions when company
management truly refuses to do the right thing, the audit department must have the
ability to go to the board with some expectation of protection from management’s
wrath. This should be a tool used only as a last resort. Ultimately it is not healthy if the
auditors constantly have to go over management’s head.
NOTE The bottom line is this: As an auditor, you work for the company and
report to its management; therefore, you are not independent.
Chapter 1: Building an Effective Internal IT Audit Function
7
NOTE As an auditor, you need to show the board and senior management
that they could never hire an outside firm that would have the knowledge
of and relationships within the company that you do.You need to prove that
using your internal auditors offers the company a competitive advantage.
Otherwise, you’re just a bottom-line cost, and if management can perform
the function for a lower cost with another provider, that is what they’ll do.
Consulting and Early Involvement
There’s more to being an auditor than auditing. Although performing formal audits is
a critical and necessary function of the audit department, the cost of correcting issues
and adding controls post-implementation is significantly higher than the cost of doing
it right the first time. In terms of independence, there is no difference between providing
an assessment of a system or solution prior to implementation and providing an assessment after implementation. There is a difference, however, in how much value the auditor is adding to the company.
NOTE
Just like quality, internal controls need to be built in up front.
Unfortunately, many auditors use independence as an excuse not to add value and
not to provide opinions. You can be independent and still work side-by-side with your
fellow employees to help them as they develop a solution to an internal control problem. Being independent doesn’t mean that you can’t provide an assessment of controls
within a system prior to deployment. Time and time again, you’ll see internal audit
departments that refuse to provide guidance and input to teams that are developing
new systems or processes. They say that they can’t provide input on the controls within
the system because to do so means that they’ll no longer be independent. They say,
“How can you audit something if you’ve already signed off on the controls?” This is a
great way to avoid work, but it is utter nonsense.
PART I
It seems that objective is perhaps a more appropriate word than independent when
describing an internal auditor’s behavior. Objectivity requires that the auditor be unbiased and that he or she not be influenced by personal feelings or prejudice. Although
the internal auditor, by definition, is not really independent, it is fair to expect him or
her to be objective. Good auditors are able and willing to put their personal feelings
aside during an audit and view circumstances in an unbiased fashion.
To maximize their effectiveness, internal auditors should capitalize on their lack of
independence. In other words, instead of doing their best to sit in an ivory tower and pretend that they’re not part of the everyday business, they should leverage their knowledge
of the business. No external audit firm can bring the depth of knowledge of the company’s
operations to bear during audits that a properly constructed internal audit group can. If
you refuse to get involved and be a part of what’s going on in the company, and if you refuse to hire auditors with prior knowledge of the company’s business and operations, all
you’re doing is making it easy for management to outsource the audit function.
IT Auditing: Using Controls to Protect Information Assets, Second Edition
8
Many auditors are terrified when they are asked for a pre-implementation opinion.
What if they give bad advice? Then they are as responsible for the control failure as the
IT folks who implemented the system. Surely it’s better to say nothing and let the IT
people “sink or swim” on developing controls, right? The auditors always can audit
them later and tell them where they screwed up. This is a ridiculous scenario, but, unfortunately, it happens all the time. It’s wrong for the company, and it’s wrong for the
auditor. Auditors need to be willing to step up to the plate and provide input. Whether
you provide an opinion before implementation or after, you still should be providing
essentially the same input. How does providing such input this week damage your independence, whereas providing it next week (after implementation) doesn’t do the
same? There’s no logic to it.
Is there a chance that you might miss something or give bad advice with such upfront involvement? Of course. Just as there’s a chance during any traditional audit that
you might miss something or offer bad advice. There’s always a risk, but you need to get
over it and do your best.
NOTE A key question relates to the future independence (or objectivity)
of the auditor who performed the upfront consulting work. Can the auditor
be allowed to audit the system in the future? Or is this person compromised
by the fact that he or she signed off on the controls and won’t want to look
bad by admitting that something was missed? This is worth considering, but
we all need to reserve the right to “get smarter” and not apologize if a postimplementation audit results in an issue being raised that we didn’t consider
pre-implementation. The auditor who was involved before implementation
is going to be your most knowledgeable resource for a post-implementation
audit. It seems a shame not to use this resource. Who is better suited to
perform a detailed audit than the person who was involved with the project
team in the first place? If the auditor’s objectivity is questionable, you might
consider making him or her a team member but not the team leader. This will
provide an extra layer of review over the auditor’s work to ensure that the
person is not being unduly influenced by prior work.
When it comes to working with teams before implementation, some lines shouldn’t
be crossed. The auditor generally should be involved with the team in an advisory capacity, which can and should include being involved in detailed discussions regarding
how the internal controls are going to be designed. The auditor should not be afraid to
brainstorm with the team about how the controls should work. However, this should
not include actually executing the control, writing the code for implementing it, or
configuring the system. You can’t both own the control and audit it, but you should feel
comfortable providing as much input as possible regarding what the control should
look like. To do less is just limiting your ability to do what you are paid to do, which is
to improve the quality of the company’s internal controls.
Chapter 1: Building an Effective Internal IT Audit Function
9
Now that we’ve established that it’s okay to speak to your fellow employees about internal controls even when you’re not auditing them, let’s talk about some of the best ways
to do this. We will discuss four methods for promoting internal controls at the company outside of your formal audits:
• Early involvement
• Informal audits
• Knowledge sharing
• Self-assessments
Early Involvement
Any manufacturing firm will tell you that it’s cheaper to build quality into a product
than to try to add it after the fact. Internal controls are the same way: Once you’ve created a system, tested it, and implemented it, it is much more expensive to go back and
change it than if you had done it right the first time. As an auditor, you’re also much
more likely to encounter resistance after implementation. Everyone has moved on to
other projects, and none of them are motivated to go back and make changes to a completed project. On the other hand, if you can provide the internal control requirements
early in the process, they become just another part of the project scope to the implementers, and they don’t mind it so much (provided that the control requirements are
reasonable).
How you accomplish this differs by company, but every company should have some
sort of project approval or review process. (If your company doesn’t, you’ve got an issue
right there that needs to be addressed.) Try to shoehorn yourself into this process. Does
the project review group meet weekly or monthly? Try to get yourself invited to it. Even
better, if the company has a group of people or an organization that has to sign off at
various stages of a project before it can be implemented, ask to be part of the sign-off
group. Be bold about it. Forget about all that “independent auditor” stuff and be willing to sign your name to something and take some ownership in the company. Just
make it clear that your role is to provide input on the internal controls of the system or
technology and nothing else. There is, of course, the possibility that you will make a
mistake and sign off on the project; even though the system has internal control weaknesses, but that’s a chance you have to take. All the other approvers are putting their
names on the line, and you need to be willing to do the same, unless you are satisfied
with the ivory tower model of audit departments that minimizes their value.
You may run into some resistance as you try to take on this additional role. The IT
groups may not want you at their meetings, and they may not want to have to deal with
you during project implementation. This is especially true if you’re working for an audit
PART I
Four Methods for Consulting and
Early Involvement
IT Auditing: Using Controls to Protect Information Assets, Second Edition
10
department that has a history of adversarial relationships and/or hasn’t been successful
at displaying its value in the past. They may see you as someone to be avoided, not
someone to be invited to the table as a participant. You may need to begin by developing good relationships. Be sure to let the IT groups know that your motive isn’t to slow
anything down or stop anything; instead, you are expressing a willingness to step up to
the plate and help out. You shouldn’t suggest that you think they need your approval,
but let them know that you’d like to be part of the solution, not part of the problem.
Let them know that you might be auditing them some day and that you want to help
them build their system so that it will pass an audit when the time comes. Point out
that the company pays you to be an expert on internal controls and that you would like
to share that expertise with them during their project implementation so that you can
help them to build in the controls up front.
NOTE Nowhere can you add more value to the company than by early
involvement.
Early involvement is infinitely more cost-effective and efficient than after-the-fact
audits. If you can work your way into being involved in projects before implementation, and if you can prove the value of your involvement, you will find yourself getting
more requests than you ever imagined. It will be tempting to turn down some projects,
saying that they’re not important enough or don’t have any internal control impact, but
that would be a mistake. You don’t want to chase away people who are looking to be
educated on internal controls. If you are successful at your attempts to be invited to the
table, you will need to dedicate appropriate resources to make it work.
So what does it really mean to be involved in projects pre-implementation? Does it
mean that you have to perform a full audit on each and every project? Not at all. This
obviously would be impossible from a resource standpoint. Many auditors are confused about what they need to do when asked to provide input on a project. It seems
like a daunting task, and it is important to simplify it. From a conceptual standpoint,
it’s no different from planning a traditional audit. When you’re getting ready to execute
an audit, what do you do? You spend time understanding the system, technology, or
process that you’ll be auditing. You then think through the risks involved and determine what sorts of controls you expect to see to mitigate those risks.
This is exactly what you do with early involvement. It’s just like planning an audit.
You need to spend time understanding the syste...
Purchase answer to see full
attachment