IT Auditing, management homework help

User Generated

FAF105

Business Finance

Description

Creating an Internal IT Audit Team

Remember that an IT audit is only as good as the team that performs the actual work. As such, you are tasked with creating an internal IT audit team this week. As you consider your team, you need to address the follow items:

  1. Identify the focus for the team.
  2. Select key positions from which to fill your team.
  3. Identify key traits or skill sets to look for in members.
  4. Consider outside assistance, such as consultants.
  5. Make an argument for or against co-sourcing.
  6. Determine how these audits will add value to the organization.

Look back to Chapter One of the textbook for help on the proper steps in creating an IT audit team successfully. Also refer Chapter 1 - 4 for inputs.

Your assignment is to write a 3- to 4-page paper that addresses each step above. Your paper must include at least two different sources. (Use credible sources, such as peer-reviewed articles, expert blogs, and the textbook.) Your well-written response should be formatted according to APA requirments, with any sources cited properly both inline and context.

Strict policy against plagiarism. Attached is the text book for your review.

Unformatted Attachment Preview

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
User generated content is uploaded by users for the purposes of learning and should be used following Studypool's honor code & terms of service.

Explanation & Answer

Attached.

Running head: CREATING AN INTERNAL IT AUDIT TEAM

Creating an Internal IT Audit Team
Names:
Institution:

1

CREATING AN INTERNAL IT AUDIT TEAM
Creating an internal IT audit team
An internal IT audit team has the mandate to monitor that all controls, guidelines, and
expectations of an organization in its information technology segment are met. According to
Davis, Schiller & Wheeler (2011), an internal audit team should be well chosen and highly
competitive so as to establish trust not just with the organizational management but between
the organization and other stakeholders as well. In this case, the initial step towards the
establishment of such a team is the establishment of a team’s focus and purpose, which should
then guide in identifying the roles of the team and consequently the various positions that
need to be filled within the team. Notably, the team’s composition might change from
organization to organization based on the structure and adoption of information technology as
well as the needs. At the same time, proper planning and role designation for the various
positions would help in identifying the competencies that each professional should hold.
Focus of the internal IT audit team
The main role...


Anonymous
Great! Studypool always delivers quality work.

Studypool
4.7
Trustpilot
4.5
Sitejabber
4.4

Similar Content

Related Tags